Sistema de Service Desk
76
FACULDADE ALVORADA CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO Francisco David Costa de Oliveira SISTEMA DE SERVICE DESK VOLTADO PARA DESENVOLVIMENTO DE SOFTWARE (SISDESK) Orientador: Mª Elizabeth d’Arrochella Teixeira Brasília – DF,
-
Upload
david-oliveira -
Category
Documents
-
view
58 -
download
0
Transcript of Sistema de Service Desk
FACULDADE ALVORADA
CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
Francisco David Costa de Oliveira
SISTEMA DE SERVICE DESK VOLTADO PARA DESENVOLVIMENTO DE SOFTWARE
(SISDESK)
Orientador: Mª Elizabeth d’Arrochella Teixeira
Brasília – DF,
ii
FRANCISCO DAVID COSTA DE OLIVEIRA
SISTEMA DE SERVICE DESK VOLTADO PARA
DESENVOLVIMENTO DE SOFTWARE
(SISDESK)
Trabalho de Conclusão de Curso apresentado à
Banca Examinadora, como exigência parcial para a obtenção do título de Bacharelado em Sistemas
de Informação e à Sociedade de Ensino Tecnologia, Educação e Cultura
Orientador: Mª Elizabeth d’Arrochella Teixeira
Brasília – DF,
iii
iv
EPÍGRAFE
“Até as mais altas torres começaram do chão...”
Provérbio Chinês.
v
RESUMO
As empresas de TI (Tecnologia da Informação) têm se preocupado cada vez
mais com a qualidade de entrega de serviços e entendem a importância que a alta
disponibilidade da Tecnologia da Informação traz aos seus negócios. Desta forma,
buscam soluções inovadoras e pioneiras de mercado, fazendo com que a demanda
de produtividade seja atendida através de soluções com alto valor agregado,
integradas, customizadas, reduzindo custos, tornando a área de Tecnologia da
Informação um aliado vital ao seu negócio. Uma das formas de atingir este objetivo é
implementando o gerenciamento de serviços de TI. Este trabalho mostra um estudo
referente aos processos da ITIL (Information Technology Infrastructure Library) e
apresenta a implementação de um sistema de Service Desk.
Palavras-Chave: ITIL; Central de Serviços; Incidente; Solicitação de Mudança.
vi
ABSTRACT
IT companies have been getting concerned increasingly with quality of
service delivery and understand the importance that the high availability of
information technology brings to business. Thus, they seek innovative solutions and
pioneering market, causing the demand is met through productivity solutions with
high added value, integrated, customized, reducing costs, making the area of
information technology a vital ally to your business. One way of achieving this goal is
by implementing the management of IT services. This work shows a study related to
ITIL processes and shows the implementation of a system aimed at the Service Desk
management services.
Keywords: ITIL; Service Desk; Incident; Change Request
vii
LISTA DE FIGURAS
Figura 1 - Organograma da Empresa ........................................................................ 18
Figura 2 - Gráfico de Baleia....................................................................................... 29
Figura 3 - Diagrama de Casos de Usos .................................................................... 51
Figura 4 - Diagrama de Classe .................................................................................. 59
Figura 5 - Modelo de Entidade e Relacionamento .................................................... 60
Figura 6 - Árvore do Sistema ..................................................................................... 67
Figura 7 - Tela de Login ............................................................................................ 68
Figura 9 - Nova Solicitação ....................................................................................... 69
Figura 10 - Adicionar Solução ................................................................................... 69
Figura 11 - Cadastro de Problema ............................................................................ 70
Figura 12 - Cadastro de Usuário ............................................................................... 70
viii
LISTA DE TABELAS
Tabela 1 - Cronograma ............................................................................................. 21
Tabela 2 - Lista de Caso de Uso ............................................................................... 50
Tabela 3 - UC01 Efetuar Login .................................................................................. 52
Tabela 4 – UC2 Manter Usuário ................................................................................ 53
Tabela 5 - UC03 Manter Incidente ............................................................................ 54
Tabela 6 – UC04 Manter Mudança ........................................................................... 56
Tabela 7 - UC05 Manter Problema ............................................................................ 57
Tabela 8 - SD_ANEXOINCIDENTE .......................................................................... 61
Tabela 9 - SD_ANEXOMUDANCA ............................................................................ 61
Tabela 10 - SD_ESTADOMUDANCA ....................................................................... 62
Tabela 11 - SD_FUNCÃO ......................................................................................... 62
Tabela 12 - SD_INCIDENTE ..................................................................................... 63
Tabela 13 - SD_ MATRIZPRIORIDADE .................................................................... 64
Tabela 14 - SD_MUDANCA ...................................................................................... 64
Tabela 15 - SD_MUDANCAESTADO ....................................................................... 65
Tabela 16 - SD_NIVELMUDANCA ............................................................................ 65
Tabela 17 - SD_PRIORIDADE .................................................................................. 66
Tabela 18 - SD_TECNICO ........................................................................................ 66
Tabela 19 - SD_URGENCIA ..................................................................................... 67
ix
LISTA DE ABREVIATURAS
ADSL Asymmetric Digital Subscriber Line
API Application Programming Interface
FTF Finalization Task Force
HTML Hipertext Markup Language
IEC International Electrotechnical Commission
HTTP HiperText Transfer Protocol
IMAP Internet Message Protocol
ISSO International Organization for Standardization
ITIL Information Technology Infrastructure Library
JDBC Java DataBase Connectivity
LDAP Lightweight Directory Access Protocol
ODBC Open Database Connectivity
OMC Object Management Group
OOSE Object-Oriented Software Engineering
PHP HiperText Preprocessor
POP Post Office Protocol
RTF Revision Task Force
RUP Rational Unified Process
SISDESK Sistema de Service Desk
SLA Service Level Agreement
TI Tecnologia da Informação
UML Unified Model Language
10
SUMÁRIO
1. Introdução ........................................................................................................... 13
1.1. Tema................................................................................................................... 14
1.2. Justificativa ......................................................................................................... 14
1.3. Formulação do Problema .................................................................................... 15
1.4. Objetivos ............................................................................................................. 16
1.4.1. Geral ............................................................................................................ 16
1.4.2. Específicos ................................................................................................... 16
1.5. Organização do Trabalho ................................................................................... 17
2. Análise Institucional ............................................................................................ 18
2.1. Empresa e seu Negócio...................................................................................... 18
2.1.1. Organograma da Empresa ........................................................................... 18
2.2. Descrições das Necessidades ............................................................................ 19
2.3. Sistemas de Informação Existente na Empresa ................................................. 19
2.4. Normas de Funcionamento ................................................................................. 19
2.5. Ambiente Tecnológico Existente ......................................................................... 20
3. Cronograma ........................................................................................................ 21
4. Referencial Teórico ............................................................................................. 22
4.1. Linguagem de Programação ............................................................................... 22
4.1.1. Java .............................................................................................................. 22
4.1.2. PHP .............................................................................................................. 24
4.1.3. Delphi ........................................................................................................... 25
4.2. Banco de Dados ................................................................................................. 25
4.2.1. Oracle ........................................................................................................... 26
4.2.2. PostgreSQL .................................................................................................. 26
4.2.3. MySQL ......................................................................................................... 27
4.3. RUP (Rational Unified Process) .......................................................................... 28
4.3.1. Desenvolvimento Iterativo ............................................................................ 28
4.3.2. Fases do RUP .............................................................................................. 29
4.3.2.1. Concepção ................................................................................................ 30
4.3.2.2. Elaboração ................................................................................................ 30
11
4.3.2.3. Construção ................................................................................................ 31
4.3.2.4. Transição .................................................................................................. 31
4.4. UML (Unified Model Language) .......................................................................... 32
4.4.1. Orientação a Objetos ................................................................................... 33
4.4.1.1. Objetos...................................................................................................... 34
4.4.1.2. Classes ..................................................................................................... 34
4.4.1.3. Herança .................................................................................................... 35
4.4.1.4. Polimorfismo ............................................................................................. 35
4.4.1.5. Coesão...................................................................................................... 36
4.4.2. Diagramas .................................................................................................... 36
4.4.2.1. Diagramas de Classes .............................................................................. 37
4.4.2.2. Diagramas de Colaboração ...................................................................... 37
4.4.2.3. Diagramas de Objetos .............................................................................. 37
4.4.2.4. Diagramas de Componentes .................................................................... 38
4.4.2.5. Diagramas de Caso de Uso ...................................................................... 38
4.4.2.6. Diagramas de Seqüência .......................................................................... 39
4.4.2.7. Diagramas de Atividade ............................................................................ 39
4.4.2.8. Diagramas de Interação ............................................................................ 40
4.4.2.9. Diagramas de Implantação ....................................................................... 40
4.4.2.10. Diagramas de Gráfico de Estados ......................................................... 41
4.5. Information Technology Infrastructure Library - ITIL ........................................... 41
4.5.1. Central de Serviços (Service Desk).............................................................. 42
4.5.2. Gerenciamento de Incidentes ...................................................................... 43
4.5.3. Gerenciamento de Problema ....................................................................... 43
4.5.4. Gerenciamento de Nível de Serviço ............................................................. 44
4.6. ISO/IEC 20.000 ................................................................................................... 44
5. Proposta do Novo Sistema ................................................................................. 46
5.1. Descrição do Sistema Proposto .......................................................................... 46
5.2. Resultados Esperados ........................................................................................ 47
5.3. Restrições do Sistema Proposto ......................................................................... 47
5.4. Resultados Esperados ........................................................................................ 47
5.5. Áreas Afetadas Pelo Novo Sistema .................................................................... 48
5.6. Banco de Dados ................................................................................................. 48
12
6. Documentação de Análise .................................................................................. 49
6.1. Visão Macro dos Atores ...................................................................................... 49
6.2. Identificação dos Atores ...................................................................................... 49
6.3. Lista dos Casos de Uso ...................................................................................... 50
6.4. Diagrama de Caso de Uso .................................................................................. 51
6.5. Descrição Detalhada dos Casos de Uso ............................................................ 52
6.6. Diagrama de Classes.......................................................................................... 59
6.7. Modelo de Entidade e Relacionamento .............................................................. 60
6.8. Especificação das Tabelas ................................................................................. 61
6.8.1. Tabela SD_ANEXOINCIDENTE .................................................................. 61
6.8.2. Tabela SD_ANEXOMUDANCA .................................................................... 61
6.8.3. Tabela SD_ESTADOMUDANCA ................................................................. 62
6.8.4. Tabela SD_FUNCAO ................................................................................... 62
6.8.5. TABELA SD_IMPACTO ............................................................................... 63
6.8.6. Tabela SD_INCIDENTE ............................................................................... 63
6.8.7. Tabela SD_MATRIZPRIORIDADE ............................................................... 64
6.8.8. Tabela SD_MUDANCA ................................................................................ 64
6.8.9. Tabela SD_MUDANCAESTADO ................................................................. 65
6.8.10. Tabela SD_NIVELMUDANCA ................................................................... 65
6.8.11. Tabela SD_PRIORIDADE ......................................................................... 65
6.8.12. Tabela SD_TECNICO ............................................................................... 66
6.8.13. Tabela SD_URGENCIA ............................................................................ 67
6.9. Árvore do Sistema .............................................................................................. 67
6.10. Especificações Físicas ................................................................................. 68
6.10.1. Layout das Principais Telas da Aplicação ................................................. 68
6.11. Help on-line .................................................................................................. 71
6.12. Segurança Física e Lógica ........................................................................... 71
6.12.1. Norma de Segurança Física ..................................................................... 71
6.12.2. Norma de Segurança Lógica .................................................................... 71
7. Plano de Implantação ......................................................................................... 73
8. Conclusão ........................................................................................................... 74
9. Referencias Bibliográficas .................................................................................. 75
13
1. Introdução
Segundo MAGALHÃES e PINHEIRO (2007), a cada dia que passa, as
organizações tornam-se mais dependentes da Tecnologia da Informação a fim de
satisfazer seus objetivos estratégicos e para atender às necessidades do negócio
em que atuam. Uma área de TI (Tecnologia da Informação) que não considerar os
objetivos estratégicos da organização em que se insere como os seus próprios
objetivos, será uma área de TI que deseja apenas ser um simples provedor de
tecnologia, haja vista que até mesmo os provedores de tecnologia, atualmente,
tendem a preocupar-se com a estratégia de negócio de seus clientes, condição
básica para a venda de serviços sob demanda.
Ainda segundo MAGALHÃES e PINHEIRO (2007), o Gerenciamento de
Serviços de Tecnologia da Informação é o instrumento pelo qual a área pode iniciar
a adoção de uma postura pró-ativa em relação ao atendimento das necessidades da
organização, contribuindo para evidenciar a sua participação na geração de valor. O
Gerenciamento de Serviço de TI visa alocar adequadamente os recursos disponíveis
e gerenciá-los de forma integrada, fazendo com que a qualidade do conjunto seja
percebida pelos seus clientes e usuários, evitando-se a ocorrência de problemas na
entrega e na operação dos serviços de Tecnologia da Informação.
Para MAGALHÃES e PINHEIRO (2007), organizações consideradas líderes
em suas indústrias estão deixando de ser organizações puramente focadas em
custo para se tornarem organizações focadas em valor. Isto pode ser constatado
pela atual prática da troca dos indicadores de desempenho derivados da estratégia
da organização e que permitem a monitoração do desempenho na execução de sua
estratégia, a partir de diversas perspectivas, além da financeira, tradicionalmente
utilizada. Hoje, as organizações já estão mais maduras e tomam decisões que levam
em conta não apenas custo, mas a criticidade de cada processo da área de TI para
a geração de valor para a organização. O Gerenciamento de Serviço de TI é, de
forma resumida, o gerenciamento da integração entre pessoas, processos e
tecnologias, componentes de um serviço de TI focados nas necessidades dos
clientes e de modo alinhado à estratégia de negócio da organização, visando o
14
alcance de objetivos de custos e desempenho pelo estabelecimento de acordos de
nível de serviço entre a área de TI e as demais áreas de negócio da organização.
MAGALHÃES e PINHEIRO (2007) ainda afirmam que a ITIL (Information
Technology Infrastructure Library), criada a partir da necessidade de padronizar os
processos da área de TI visando à terceirização, baseia-se na experiência coletiva
de inúmeros praticantes do Gerenciamento de Serviços de TI de organizações
privadas e públicas de todo o mundo. Esta é a razão pela qual vem se tornando um
padrão na área de Gerenciamento de Serviços de TI, adotada por organizações-
líderes em seus segmentos de atuação em escala mundial. A eficiência, a eficácia, a
efetividade e a economicidade no suporte aos serviços de TI são fatores críticos
para o sucesso no alcance dos objetivos estratégicos traçados pela organização.
1.1. Tema
O Sistema de Service Desk (SISDESK) é um sistema que atua como ponto
único de contato entre o provedor de serviços de TI e os clientes, onde são
cadastrados incidentes e solicitações de mudanças, possibilitando assim, um melhor
gerenciamento dos serviços de TI.
1.2. Justificativa
Conforme MAGALHÃES e PINHEIRO (2007), a Central de Serviços é uma
função e não um processo, essencial para a implementação do Gerenciamento de
Serviços de TI. Mais do que um ponto de suporte aos usuários, a Central de
Serviços é a principal interface entre a área de TI e os usuários dos seus serviços.
Ela é responsável pela primeira impressão que a área de TI dará aos seus usuários
quando da necessidade de interação, quer seja para a solicitação de um serviço ou
esclarecimento sobre o modo de interação com o serviço de TI ou para comunicação
de um erro.
As normas internacionais relacionadas com a Gestão de Serviços de TI
permitem a colaboração de organizações internacionais e fornecem diretrizes
15
valiosas que contribuem para o estabelecimento da credibilidade das empresas. A
ISO (International Organization for Standardization) 20.000, permite a uma
organização demonstrar aos seus clientes e investidores que opera com integridade
negocial e segurança, e que promove uma cultura de melhoramento contínuo da
qualidade no âmbito da Gestão de Serviços de TI [1].
Com intuito de implementar a ISO 20.000 para um melhor gerenciamento de
seus serviços de TI e fornecer um atendimento de qualidade às solicitações dos
clientes, a empresa Dave Systems (Empresa Fictícia) necessita de uma ferramenta
de apoio gerencial de serviços de TI que incremente velocidade ao atendimento e
melhore o suporte aos usuários de seus serviços. Para esse fim, o sistema
SISDESK será desenvolvido de forma a suprir estas necessidades.
Em um futuro próximo, a empresa Dave Systems (Empresa Fictícia) estuda
a possibilidade de aquisição da certificação ISO 20.000, e utilizar o SISDESK como
ferramenta de apoio para obtenção e manutenção da certificação ISO 20.000.
1.3. Formulação do Problema
O controle dos incidentes gerados pelos sistemas desenvolvidos pela Dave
Systems (Empresa Fictícia) são cadastrados em um sistema desenvolvida pela
mesma chamada Help. No Help são cadastrados os chamados para correção ou
solicitação de mudança no sistema, permitindo o acompanhamento da demanda e a
visualização na íntegra de todos os envolvidos no chamado. Porém, para o intuito da
empresa Dave Systems, que é viabilizar a entrega e o suporte de serviços focados
nas necessidades dos clientes, a empresa percebeu que sua ferramenta de controle
de incidentes, o Help, não atendia às suas exigências. O Help não possui relatórios
para geração de métricas, o que dificulta as tomadas de decisões para determinados
assuntos gerenciais. A base de dados possui dados inconsistentes, o que gera
conflitos de informações para os usuários. Outra falha grave do sistema, é que o
mesmo permite que técnicos, que receberam um chamado para resolução de um
incidente, tenham privilégios para encaminhar a demanda para outros técnicos sem
antes retorná-la para o Analista do Incidente, que é o dono do chamado, com o
16
motivo pelo qual o mesmo foi devolvido. Dessa forma perde-se o controle sobre o
incidente podendo ficar dias tramitando entre técnicos sem nenhuma solução
implementada para o problema.
Com o atual sistema, algumas demandas com grau de dificuldade alta são
deixadas de lado para que outras demandas de nível de dificuldade menor sejam
implementadas. Dessa forma, algumas solicitações demoram mais do que o previsto
para serem executadas e, conseqüentemente, atrasando a resolução das
solicitações e gerando insatisfação por parte do cliente.
1.4. Objetivos
Logo abaixo estão descritos os objetivos a serem alcançados pelo sistema
proposto, obtendo uma visão tanto de forma macro como de forma específica de
seus objetivos.
1.4.1. Geral
Desenvolver um sistema que facilite o controle das solicitações para agilizar
o restabelecimento da operação normal dos serviços dentro do SLA (Service Level
Agreement) definido com o cliente, minimizando o impacto nos negócios causados
por falhas de TI e o atendimento de possíveis mudanças a serem realizadas nos
serviços prestados pela empresa.
1.4.2. Específicos
Os objetivos específicos do sistema proposto são: fornecer um ponto único
com a área de TI para os clientes dos serviços de TI; Prover um suporte técnico para
o atendimento das solicitações cadastradas pelos clientes da empresa; Ajudar a
identificar e a reduzir o custo de propriedade dos serviços prestados; Gerar
indicadores gerenciais para o auxilio de tomadas de decisão;
17
1.5. Organização do Trabalho
Abaixo está descrita a forma como o trabalho está organizado:
O capítulo 1 descreve de uma forma geral o tema proposto e a justificativa
da escolha do tema e o problema que a ser resolvido.
O capítulo 2 faz referência à instituição para a qual será destinada a
implementação do sistema contendo o organograma da empresa, as necessidades
do sistema e o ambiente tecnológico existente.
O capítulo 3 descreve todo o cronograma das atividades realizadas no
desenvolvimento do projeto.
O capítulo 4 descreve o referencial teórico das tecnologias utilizadas no
desenvolvimento do projeto.
O capítulo 5 faz referência ao sistema proposto, resultados esperados,
restrições do sistema e as áreas afetadas pelo sistema.
O capítulo 6 descreve a documentação de análise do projeto, assim como a
visão macro dos atores, identificação dos atores, lista de casos de uso e diagrama
de caso de uso.
O capítulo 7 descreve a forma como será implantado o sistema.
O capítulo 8 descreve a conclusão do trabalho realizado.
O capítulo 9 descreve todo o referencial teórico utilizada no desenvolvimento
do trabalho realizado.
18
2. Análise Institucional
2.1. Empresa e seu Negócio
A empresa Dave Systems (Empresa Fictícia) foi fundada em 1982 com
intuito de atender com qualidade e eficiência uma área carente dentro da
administração pública, porém fundamental para boa gestão do dinheiro público. No
decorrer desses anos tornou-se líder nacional no desenvolvimento e implantação de
soluções de gestão de materiais e de patrimônio. A empresa, desde o princípio,
preocupou-se em trazer inovações para o mercado de tecnologia da informação. A
solução de gestão oferecida pela Dave Systems, inclui ainda todo o serviço de
verificação e consistência da base de dados, ou seja, o levantamento in loco (no
lugar) dos bens permanentes dos órgãos, com metodologia e equipe especializada.
2.1.1. Organograma da Empresa
Logo abaixo é mostrado o organograma geral da Dave Systems (Empresa
Fictícia).
Figura 1 - Organograma da Empresa
19
2.2. Descrições das Necessidades
A empresa carece de um controle sobre as solicitações demandadas à sua
fábrica de software fazendo com que os gerentes das equipes de desenvolvimento
percam muito tempo em análises de chamados para levantamento de dados que os
dê suporte à geração de indicadores e métricas.
Atualmente o sistema que controla as atividades de desenvolvimento de
serviços prestados pela empresa, não contempla de forma eficiente e eficaz as
necessidades da mesma, realizando apenas o cadastro de demandas, atribuição da
demanda ao colaborador que desenvolverá o trabalho e finalização do chamado
quando a demanda estiver implementada.
Para suprir as necessidades da empresa Dave Systems (Empresa Fictícia),
o Sistema de Service Desk (SISDESK) será desenvolvido baseado nas melhores
práticas de gestão de serviço da Information Technology Infrastructure Library (ITIL),
com a atenção voltada para a obtenção da certificação ISO 20.000.
2.3. Sistemas de Informação Existente na Empresa
A empresa Dave Systems (Empresa Fictícia) desenvolveu o sistema ASI que
tem por finalidade propiciar realização do inventário dos bens móveis por meio de
um aparelho de leitura óptica de código de barras possibilitando o armazenamento
dos dados coletados no sistema desenvolvido.
2.4. Normas de Funcionamento
Para que se possa fazer uso do sistema, há algumas exigências a serem
considerados: o usuário deverá possuir cadastro na intranet local; o usuário deverá
possuir login no sistema; o usuário deverá possuir nível de acesso previamente
cadastrado; O deverá passar por treinamento para que possa interagir de forma
correta com as diversas situações do sistema.
20
2.5. Ambiente Tecnológico Existente
Em sua estrutura, a Dave Systems (Empresa Fictícia) possui em torno de
180 computadores sendo 25 servidores, desde firewall à máquina de backup e 30
servidores virtualizados. A rede é mista com wireless, cabeamento estruturado e
ligação via fibra óptica. Os servidores de aplicação utilizam o sistema operacional
Linux e os servidores de banco de dados utilizam o sistema operacional Windows. O
firewall utilizado é baseado em Freebsd (Freebsd é um sistema operacional livre do
tipo unix) e o controlador de domínio é o OPENLDAP (OPENLDAP é um software
livre de código aberto que implementa o protocolo de rede LDAP). Conta com
internet ADSL (Asymmetric Digital Subscriber Line) disponibilizada 24 horas por dia
e 7 dias por semana, possui sala para treinamentos e departamento para digitalizar
e imprimir documentos.
21
3. Cronograma
O cronograma é a disposição gráfica do tempo que será gasto na realização
de um trabalho ou projeto, de acordo com as atividades a serem cumpridas. Serve
para auxiliar no gerenciamento e controle das atividades, permitindo de forma rápida
a visualização de seu andamento [2].
Abaixo o cronograma do planejamento utilizado no desenvolvimento do
sistema.
Tabela 1 - Cronograma
ETAPAS MAR/10 ABR/10 MAI/10 JUN/10 JUL/10 AGO/10 SET/10 OUT/10 NOV/10 DEZ/10
Definição do Problema
Delimitação do Tema
Pesquisa Bibliográfica
Levantamento Teórico
Definição da metodologia
Planejamento de ações
Levantamento de Requisitos
Análise (def. casos de uso)
Escrever a monografia
Projeto
Implementação
Implantação
Apresentação da monografia
Acertos após apresentação
Entrega final
22
4. Referencial Teórico
Para o desenvolvimento deste trabalho foram estudados os conceitos em
RUP (Rational Unified Process) para os processos de engenharia de software e a
UML (Unified Modeling Language) para a modelagem do sistema. A Linguagem de
Programação Java, foi utilizada para desenvolvimento do sistema. Em relação ao
gerenciamento de serviço, ITIL (Information Technology Infrastructure Library) foi
estudada e implantada nesse trabalho. O Oracle Express foi escolhido como a base
de dados do sistema.
4.1. Linguagem de Programação
ANDRADRE (2007) define que o computador é uma super calculadora,
capaz de realizar cálculos muito mais rápido do que humanos, mas para isso
devemos dizer para o computador o que deve ser calculado e como deve ser
calculado. Os computadores interpretam tudo como números em base binária, ou
seja, só entendem zero e um, tornando assim as linguagens de programação um
meio de comunicação inteligível entre computadores e humanos.
Logo abaixo, teremos uma abordagem sobre algumas linguagens de
programação utilizadas no setor de informática atualmente.
4.1.1. Java
Segundo DEITEL H. e DEITEL P. (2005) os microprocessadores têm um
impacto profundo em dispositivos inteligentes eletrônicos voltados para o
consumidor. Reconhecendo isso, a Sun Microsystems, financiou um projeto de
pesquisa corporativa interna com o codinome Green, que resultou no
desenvolvimento de uma linguagem baseada em C++ que seu criador o chamou de
Oak e que posteriormente foi trocado para Java. A Sun anunciou o Java
formalmente em 1995 em uma importante conferência em maio de 1995. Java é uma
linguagem orientada a objeto, independente de plataforma e segura. A programação
orientada a objeto é uma metodologia de desenvolvimento de software que um
23
programa é percebido como um grupo de objetos que trabalham juntos. Java
disponibiliza a concorrência para o programador de aplicativos por meio de suas
APIs (Application Programming Interface). O programador especifica os aplicativos
que contêm threads de execução, em que cada thread designa uma parte de um
programa que pode executar concorrentemente com outras threads. Essa
capacidade, chamada multithreading, fornece capacidades poderosas para o
programador de Java.
Conforme CADENHEAD e LEMAY (2005). Java permite a neutralidade de
plataforma, que significa a capacidade de um programa executar sem modificações
em diferentes ambientes de computação. Os programas Java são compilados para
um formato chamado bytecode, que é executado por qualquer sistema operacional,
softwares ou qualquer dispositivo com interpretador Java. O Windows, Solaris, Linux
e Apple Macintosh.
Com Java podemos também, desenvolver programas para executar em
navegadores e serviços da Web, desenvolver aplicativos no lado servidor, combinar
aplicativos ou serviço para criar outros aplicativos altamente personalizados, entre
outras vantagens [3].
Para GONÇALVES (2007), trabalhar com banco de dados em aplicações
Web é um fato muito comum no desenvolvimento de um sistema. O Java possui
uma API chamada JDBC (Java DataBase Connectivity) que consiste em um
conjunto de classes e interfaces escritas em Java que oferecem um suporte
completo para programação com banco de dados. Por ser escrita em Java, a API
JDBC também independe de plataforma para a sua utilização.
Ainda segundo GONÇALVES (2007), as bibliotecas da linguagem Java
contêm várias classes que implementam diversos mecanismos de entrada e saída,
acesso à Internet, manipulação de strings em alto nível, poderosas estruturas de
24
dados, utilitários diversos e um conjunto completo de classes para implementação
de interfaces gráficas. A documentação da linguagem, chamada Javadoc, está
disponível gratuitamente e possui um padrão de organização estruturada como
documento HTML (Hipertext Markup Language). Os desenvolvedores de frameworks
e componentes costumam utilizar este padrão de documentação para documentar
seus códigos. Isto facilita em muito tanto o trabalho em equipe quanto a reutilização
de código de terceiros em outras implementações. Além disto, junto com o
compilador Java vem um aplicativo para geração de JavaDoc do código que você
acabou de implementar.
Por ser uma linguagem que possui neutralidade, segurança, conexão com
os principais bancos de dados do mercado, documentação da linguagem e ser
multitarefa, Java foi escolhido como a linguagem de programação a ser utilizada no
desenvolvimento do SISDESK.
4.1.2. PHP
Segundo CONVERSE e PARK (2001), PHP é uma linguagem de criação de
scripts com código-fonte aberto embutido em HTML do lado do servidor da Web,
compatível com os mais importantes servidores da Web. PHP significa: Hypertext
Preprocessor (pré-processador de hipertexto), originalmente chamado de Personal
Home Page Tools. O PHP permite embutir fragmentos de códigos em páginas
normais de HTML – código que é interpretado como suas páginas e fornecido a
usuários. É uma linguagem que suporta as funcionalidades para definir classes e
objetos, tornando-se assim orientada a objetos.
Ainda segundo Converse e Park, o PHP é executado de forma nativa em
cada versão no UNIX e Windows. Também é compatível com os importantes
servidores da Web como o HTTP Apache para UNIX Windows, Microsoft Internet
Information Server e Netscape. O PHP não é suportado na plataforma Macintosh.
Dessa forma, a linguagem de programação não pode ser considerada uma
linguagem multi-plataforma.
25
A conectividade de banco de dados é especialmente forte, com suporte de
unidade nativa para a maioria dos bancos de dados, além do ODBC. Suporta
também, um número grande de protocolos importantes como POP3, IMAP, LDAP.
4.1.3. Delphi
Segundo SWAN (1997), o Delphi é uma linguagem de programação para
aplicativos rápidos, adequado para criação de protótipos do Windows e aplicativos
profissionais que competem em velocidade e eficiência. Delphi inclui poderosos
recursos orientados a objeto, sem tornar a linguagem muito complicada, permite a
criação de aplicações para sistemas operacionais, como templates e experts de
aplicações e formulários, que aumentam muito a produtividade. Possuem classes e
objetos, tratamento de exceções, programação multithread, programação modular e
vínculo dinâmico e estático.
Como dito anteriormente, Delphi é uma linguagem de programação modular
e o módulo básico é denominado unidade. Para compilar um programa em Delphi, é
preciso um arquivo-fonte de programa e quaisquer unidades adicionais na forma de
fonte ou objeto.
Conforme LISCHNER (2000) Delphi possui três variedades de diretivas de
compilador: chaves, parâmetro e compilação condicional. Uma chave é um flag
Booleano: Um recurso pode estar ativado ou desativado. Um parâmetro oferece
informações, como um nome de arquivo ou o tamanho da pilha. A compilação
condicional lhe permite definir condições e compilar seletivamente partes de um
arquivo-fonte dependendo das condições definidas. Um programa em Delphi é
semelhante a um programa do Pascal tradicional, no entanto, os programas em
Delphi são curtos, pois o trabalho real ocorre em uma ou mais unidades separadas.
4.2. Banco de Dados
Segundo DEITEL H. e DEITEL P. (2005), um banco de dados é uma coleção
organizada de dados. Um sistema de gerenciamento de banco de dados fornece
26
mecanismos para armazenar, organizar, recuperar e modificar dados para muitos
usuários
4.2.1. Oracle
Segundo ABBEY, COREY, ABRAMSON (2000), o Oracle é um repositório
para volumes de dados muito grande e fornece aos usuários um acesso rápido a
esses dados. Possui o particionador de dados que consiste em dividir grandes
volumes mais gerenciáveis e reunidos de forma transparente quando os sistemas
funcionam e as sessões de usuário processam consultas. O Oracle fornece a
integridade de dados, ou seja, se, enquanto um usuário está alterando dados dentro
de um banco de dados, uma falha de qualquer espécie ocorrer, o banco de dados
tem a capacidade de desfazer ou retroceder qualquer operação suspeita. Os
sofisticados mecanismos de segurança controlam o acesso de dados sigilosos
através do uso de uma variedade de privilégios. Os usuários recebem direitos para
ver, modificar e criar dados de acordo com os nomes que usam para se conectar
com o banco de dados.
A empresa Oracle lançou em novembro de 2005, a uma nova edição do
Oracle, o Oracle Express Edition 10g. Trata-se de uma versão gratuita que possui o
mesmo "núcleo" das demais versões, ou seja, uma aplicação que roda na versão do
Oracle Database Standard Edition Server release 2, sua aplicação também irá
funcionar com Oracle Express Edition 10g. Por ser compatível com toda a família de
produtos do Oracle, ele permite aos usuários a facilidade de começar com uma
solução básica e ir mudando para outras versões quando necessário. Permite ainda
que os desenvolvedores tirem total proveito do Oracle Application Express para
rápido desenvolvimento e implementação de aplicativos baseados na Web. [4]
4.2.2. PostgreSQL
O PostgreSQL é um poderoso sistema gerenciador de banco de dados
objeto-relacional de código aberto. É executado em todos os grandes sistemas
operacionais, incluindo Linux e Windows. É totalmente compatível com ACID, tem
27
suporte completo a chaves estrangeiras, junções, visões, gatilhos e procedimentos
armazenados. Inclui a maior parte dos tipos de dados do ISO SQL:1999, incluindo
INTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, e
TIMESTAMP. Suporta também o armazenamento de objetos binários, incluindo
figuras, sons ou vídeos [5].
Como um banco de dados de nível corporativo, o PostgreSQL; possui
funcionalidades sofisticadas como o controle de concorrência multiversionado,
recuperação em um ponto no tempo, tablespaces, replicação assíncrona,
transações agrupadas, cópias de segurança, um sofisticado planejador de consultas
e registrador de transações seqüencial para tolerância a falhas. Suporta conjuntos
de caracteres internacionais, codificação de caracteres multibyte, Unicode e sua
ordenação por localização, sensibilidade a caixa (maiúsculas e minúsculas) e
formatação. PostgreSQL é altamente escalável, tanto na quantidade enorme de
dados que pode gerenciar, quanto no número de usuários concorrentes que pode
acomodar. Existem sistemas ativos com o PostgreSQL em ambiente de produção
que gerenciam mais de 4TB de dados [5].
O código fonte do PostgreSQL está disponível sob a licença de fonte aberta
mais liberal: a licença BSD.
4.2.3. MySQL
Segundo SANTOS (2005) MySQL é um banco de dados relacional,
desenvolvido para plataformas Linux–like, OS/2, Windows. Sendo um software de
livre distribuição para plataformas não-Windows que o utilizam em um servidor Web.
Ainda segundo SANTOS (2005) o MySQL é um servidor multiusuário,
multitarefa, compatível com o padrão SQL, linguagem essa amplamente utilizada
para manipulação de dados em RDBMS (Banco de dados Relacionais), sendo
considerada um ferramenta de manipulação de base de dados de tamanho
moderado. A principais características que destacam MySQL são: sua velocidade
28
proporcionada pela sua implementação leve que não inclui na totalidade o suporte
as instruções SQL; sua natureza de distribuição gratuita; facilidade de integração
com servidor Web e linguagens de programação de desenvolvimento de sites
dinâmico.
4.3. RUP (Rational Unified Process)
Para KRUCHTEN (2003), o Rational Unified Process (também chamado de
processo RUP) é um processo de engenharia de software. Ele oferece uma
abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro
de uma organização de desenvolvimento. Sua meta é garantir a produção de
software de alta qualidade que atenda às necessidades dos usuários dentro de um
cronograma e de um orçamento previsíveis. Amadureceu durante os anos, e reflete
a experiência coletiva das muitas pessoas e companhias que hoje compões a rica
herança da Rational Software. O RUP incorpora mais material nas áreas de
engenharia de dados, modelagem de negócio, gerenciamento de projeto e
gerenciamento de configuração, o último como resultado de uma fusão com Pure-
Atria.
KRUCHTEN (2003) ainda afirma que o RUP fornece uma abordagem
disciplinada para assumir tarefas e responsabilidades dentro de uma organização de
desenvolvimento. Seu objetivo é assegurar a produção de software de alta qualidade
que satisfaça as necessidades de seus usuários finais dentro de prazo e orçamento
previsíveis. Pode ser adaptada e estendida para compor as necessidades de uma
organização que o esteja adotando.
4.3.1. Desenvolvimento Iterativo
Um projeto que usa o desenvolvimento iterativo tem um ciclo de vida que
consiste em várias iterações. Uma iteração incorpora um conjunto quase seqüencial
de atividades em modelagem de negócios, requisitos, análise e design,
implementação, teste e implantação, em várias proporções, dependendo do local em
que ela está localizada no ciclo de desenvolvimento. As iterações nas fases de
29
iniciação e de elaboração se concentram nas atividades de gerenciamento,
requisitos e design. As iterações na fase de construção se concentram no design, na
implementação e no teste. E as iterações na fase de transição e concentram no teste
e na implantação. O gerenciamento das iterações deve ser do tipo timebox, isto é, a
programação de uma iteração deve ser considerada fixa e o escopo do conteúdo da
iteração gerenciado ativamente para atender a essa programação [6].
4.3.2. Fases do RUP
KRUTCHEN (2003) explica que a partir de uma perspectiva de
gerenciamento, o ciclo de vida de software do Rational Unified Process (RUP) é
dividido em quatro fases seqüenciais, cada uma concluída por um marco principal,
ou seja, cada fase é basicamente um intervalo de tempo entre dois marcos
principais.
Logo abaixo, é exibido o gráfico de baleias, onde é mostrado verticalmente
as disciplinas do desenvolvimento de software. Nas colunas, são mostradas as fases
e o esforço em cada uma delas.
Figura 2 - Gráfico de Baleia
30
4.3.2.1. Concepção
Para KRUCHTEN (2003) na fase de concepção, o foco está em entender os
requisitos globais e determinar a extensão do esforço de desenvolvimento. Para
projetos que visam melhorias em um sistema existente, a fase de iniciação é mais
rápida, mas ainda se concentra em assegurar que o projeto seja compensatório e
que seja possível fazê-lo.
Dentre as atividades da fase de concepção, devemos formular a extensão
do projeto, que quer dizer, captar o contexto e os requisitos mais importantes e
restrições de forma que possa derivar critérios de aceitação para o produto final.
Outra atividade é planejar e preparar um caso de uso de negócio e avaliar
alternativas para gerenciamento de risco, fornecendo pessoal, plano de projeto e
intercâmbio entre custo, prazo e rentabilidade. E por fim, KRUCHTEN (2003) explica
que se deve sintetizar uma arquitetura candidata, avaliar intercâmbios em projeto e
avaliar decisões de fazer/comprar/reutilizar, de forma que custo, prazo e recursos
possam ser calculados.
4.3.2.2. Elaboração
A meta da fase de elaboração é criar a baseline para a arquitetura do
sistema, desenvolver o plano de projeto e eliminar os elementos de alto risco do
projeto, a fim de fornecer uma base estável para o esforço da fase de construção.
Na fase de elaboração, um protótipo executável de arquitetura é construído em uma
ou mais iterações dependendo da extensão, tamanho, risco e novidade do projeto
programação [6].
Na fase de elaboração, um protótipo executável de arquitetura é construído
em uma ou mais iterações, dependendo da extensão, tamanho risco e novidade do
projeto. No mínimo, este esforço deveria endereçar os casos de uso críticos
identificados na fase de concepção, que tipicamente expõe os riscos técnicos
principais do projeto.
31
Embora um protótipo evolutivo de um componente de qualidade de produção
sempre seja a meta, isto não exclui o desenvolvimento de um ou mais protótipos de
propaganda para mitigar um determinado risco ou explorar alguns intercâmbios entre
projeto e requisitos. Nem é regra um estudo de viabilidade ou demonstrações a
investidores, clientes e usuários finais.
Conforme KRUCHTEN (2003) os objetivos primários da fase de elaboração
são: definir, validar e delinear a arquitetura tão rápida quanto possível de ser
realizada; delinear a visão; delinear um plano de alta-fidelidade para a fase de
construção; demonstrar que a arquitetura de linha de base suportará esta visão, a
um custo razoável num tempo razoável.
4.3.2.3. Construção
KRUCHTEN (2003) explica que durante a fase de construção, todos os
componentes restantes e características da aplicação são desenvolvidos e
integrados ao produto, e todas as características são completamente testadas. A
fase de construção é, de certo modo, um processo industrial no qual é colocada
ênfase em gerenciar recursos e controlar operações para aperfeiçoar custos, prazos
e qualidade. Muitos projetos são grandes o suficiente para que sejam gerados
incrementos de construção paralelos. Estas atividades paralelas podem apressar
significativamente a disponibilidade de lançamentos de desenvolvimentos; eles
também podem aumentar a complexidade de gerenciamento de recurso e
sincronização de fluxo. Os objetivos primários da fase de construção incluem:
minimizar custos de desenvolvimento e aperfeiçoando recursos; Alcançar a
qualidade adequada tão rápida quanto possível de ser realizada.
4.3.2.4. Transição
O foco da Fase de Transição é assegurar que o software esteja disponível
para seus usuários finais. A Fase de Transição pode atravessar várias iterações e
32
inclui testar o produto em preparação para release e ajustes pequenos com base no
feedback do usuário. Nesse momento do ciclo de vida, o feedback do usuário deve
priorizar o ajuste fino do produto, a configuração, a instalação e os problemas de
usabilidade; todos os problemas estruturais mais graves devem ter sido trabalhado
muito antes no ciclo de vida do projeto. No fim do ciclo de vida da Fase de
Transição, os objetivos devem ter sido atendidos e o projeto deve estar em uma
posição para fechamento. Em alguns casos, o fim do ciclo de vida atual pode
coincidir com o início de outro ciclo de vida no mesmo produto, conduzindo à nova
geração ou versão do produto. Para outros projetos, o fim da Transição pode
coincidir com uma liberação total dos artefatos a terceiros que poderão ser
responsáveis pela operação, manutenção e melhorias no sistema liberado [6].
Essa Fase de Transição pode ser muito fácil ou muito complexa,
dependendo do tipo de produto. Um novo release de um produto de mesa existente
pode ser muito simples, ao passo que a substituição do sistema de controle do
tráfego aéreo de um país pode ser excessivamente complexa.
4.4. UML (Unified Model Language)
Conforme BOOCH, RUMBAUGH e JACOBSON (2005) os esforços para
criação da UML se iniciaram oficialmente em outubro de 1994, quando Rumbaugh
se juntou a Booch na Rational. O foco inicial do projeto era a unificação dos métodos
Booch e OMT(Object Modeling Technique). O esboço da versão 0.8 do Método
Unificado (como então era chamado) foi lançado em lançado em outubro de 1995.
Na mesma época Jacobson se associou à Rational e o escopo do projeto da UML foi
expandido com a finalidade de incorporar o OOSE (Object-Oriented Software
Engineering). Por vários anos, a manutenção da UML foi assumida pela RTF
(Revision Task Force) do OMG (Object Management Group), que produziu as
versões 1.3, 1.4 e 1.5. De 2000 a 2003, um novo e maior grupo de parceiros
produziu e atualizou a especificação da UML, versão 2.0. A versão foi revista por um
FTF (Finalization Task Force) coordenada por Bran Selic, da empresa IBM, e a
versão oficial da UML 2.0 foi adotada pelo OMG no início de 2005.
33
BOOCH, RUMBAUGH e JACOBSON (2005) explicam que a UML é uma
linguagem-padrão para a elaboração da estrutura de projetos de software. Ela
poderá ser empregada para a visualização, a especificação, a construção e a
documentação de artefatos que façam uso de sistemas complexos de software. A
UML é adequada para a modelagem de sistemas, cuja abrangência poderá incluir
sistemas de informação coorporativos a serem distribuídos a aplicações em Web e
até sistemas complexos embutidos de tempo real. Segundo Furlan (1998), a UML é
a linguagem padrão para especificar, visualizar, documentar e construir artefatos de
um sistema e pode ser utilizada com todos os processos ao longo do ciclo de
desenvolvimento e através de diferentes tecnologias de implementação.
4.4.1. Orientação a Objetos
Segundo MATOS (2003), a proposta da orientação à objetos é permitir que
os programadores organizem os programas da mesma forma que nossas mentes
enxergam os problemas: não como um conjunto de espaços de memória, mas como
um conjunto de coisas que fazem parte do problema. O interessante neste ponto de
vista é que o programador não será mais obrigado a abstrair do problema variáveis e
suas respectivas organizações, mas imaginar o problema como um grande conjunto
de objetos. Dessa forma é necessário haver uma modificação na maneira como
enxergamos os programas. Não é permitido neste paradigma, orientar a solução dos
problemas de acordo com as funções identificadas no problema, mas de acordo com
o que existe no escopo do problema: objetos.
FURLAN (1998), afirma que um objeto é uma ocorrência específica
(instância) de uma classe e é similar a uma entidade no modelo relacional somente
até o ponto onde representa uma coleção de dados relacionados com um tema em
comum. Furlan, explica ainda que a tecnologia de objetos oferece modularidade de
seus elementos podendo-se tornar um subconjunto existente e integrá-lo de uma
maneira diferente em outra parte do sistema. Objetos permitem ser combinados ou
utilizados separadamente, pois, em tese, apresentam baixa dependência externa e
34
alta coesão interna de seus componentes, o que permite promover substituições
sem afetar interconexões ou interferir com a operação dos demais objetos.
4.4.1.1. Objetos
Segundo FURLAN (1998) do ponto de vista de abstração, os objetos tentam
não separar o que até então vinha sendo separado: dados e funções. Um objeto é
uma entidade concreta, apesar de ser uma concepção abstrata. Trata-se de um
agrupamento de características e ações desta entidade. Essas características são
agrupadas de forma que possamos identificar outros objetos parecidos. Por outro
lado, suas ações ajudam também a classificar outras entidades como objetos
semelhantes a ele.
PENDER (2004) define objeto como a representação de uma entidade
específica no mundo real. Diz também que, pode ser uma entidade física ou
intangível, com os propósitos de promover o entendimento do mundo real e suportar
uma base prática para uma implementação computacional.
4.4.1.2. Classes
Segundo PAGE-JONES (2000), uma classe é uma estrutura a partir do qual
são criados objetos. Cada objeto tem a mesma estrutura e comportamento da classe
na qual ele teve origem.
SANTOS (2003) define que classes são estruturas orientadas a objeto para
conter, para um determinado modelo, os dados que devem ser representados e as
operações que devem ser efetuadas com estes dados. Classes são escritas com os
recursos e regras para implementação dos modelos, mas em muitos casos as
classes são somente moldes ou formas que representam os modelos abstratamente.
Um objeto ou uma instância é uma materialização da classe, e assim pode ser
usado para representar e executar operações. Para que dados ou instâncias
possam ser manipulados, é necessária a criação de referências a estes objetos, que
são basicamente variáveis do tipo de classe.
35
Conforme SANTOS (2003), os dados contidos em uma classe são
conhecidos como campos ou atributos daquela classe. Cada campo deve ter um
nome e ser de um tipo. Valores contidos dentro de uma classe são chamados de
variáveis, sendo que campos representam dados encapsulados em uma classe, e
variáveis representam valores auxiliares necessários ao funcionamento dos métodos
na classe. As operações contidas em uma classe são chamadas de métodos dessa
classe. Métodos são geralmente chamados ou executados explicitamente a partir de
outros trechos de código na classe que o contém ou a partir de outras classes.
4.4.1.3. Herança
Segundo Furlan (1998), herança é o mecanismo de reutilização de atributos
e operações definidos em classes gerais por classes mais específicas, podendo ser
usada para expressar tanto generalização como associação. Pode-se organizar tipos
similares de classes de objetos em categorias hierárquicas, onde é permitida à
classe de menor nível, que é uma especialização ou extensão de outra classe,
compartilhar atributos e operações de classes superiores na hierarquia.
SANTOS (2003) diz que o mecanismo de reaproveitamento por herança
permite a reutilização de classes já existentes com instâncias de novas classes. As
classes originais ficam assim contidas nas classes novas.
É a partir da herança que surge o conceito de classes abstratas, as quais
são idealizadas para serem moldes de eventuais subclasses, as quais irão adicionar
sua estrutura e comportamento, geralmente sobrepondo operações. Permite
especificar atributos e operações comuns a várias classes uma única vez com a
possibilidade de modificar-los à luz das necessidades das classes herdeiras.
4.4.1.4. Polimorfismo
Segundo PAGE-JONES (2000), o termo polimorfismo é originário do grego e
significa "muitas formas" (poli = muitas, morphos = formas). A palavra polimorfismo
36
origina-se de duas palavras gregas que significam respectivamente, muitas e forma.
Algo que é polifórmico, portanto, apresenta a propriedade de assumir muitas formas.
PAGE-JONES (2000) explica ainda que polimorfismo é a habilidade pela qual uma
única operação ou nome de atributo pode ser definido em mais de uma classe e
assumir implementações diferentes em cada uma dessas classes.
Para PENDER (2004), polimorfismo é a capacidade de escolher
dinamicamente o método para uma operação durante a execução, dependendo do
tipo de objeto que responde à solicitação. Pender complementa dizendo que
polimorfismo significa muitas maneiras de realizar a mesma coisa.
Para SANTOS (2003), o mecanismo de herança permite a criação de
classes a partir de outras já existentes com relações é-um-tipo-de, de forma que, a
partir de uma classe genérica, classes mais especializadas possam ser criadas.
Polimorfismo permite a manipulação de instâncias de classes que herdam de uma
mesma classe ancestral de forma unificada.
4.4.1.5. Coesão
Segundo PENDER (2004), coesão é uma medida de como as partes de um
objeto dão suporte à mesma finalidade. A coesão mede dois fatores: como a
finalidade do objeto é bem definida e se cada parte do objeto contribui diretamente
para cumprir sua finalidade. Alta coesão significa que um objeto possui uma
finalidade bem definida e tudo no objeto contribui diretamente para essa finalidade.
Baixa coesão significa ou que a finalidade do objeto é ambígua ou que nem todas as
partes do objeto contribuem diretamente para a finalidade do objeto, ou ambos.
4.4.2. Diagramas
FURLAN (1998) afirma que usando a UML, é possível construir modelos a
partir de blocos de construção básicos, como classes, interfaces, componentes, nós,
dependências, generalizações e associações. Diagramas são meios para
visualização desses blocos de construção. Um diagrama é uma apresentação
37
gráfica de um conjunto de elementos, geralmente representados como um gráfico
conectado de vértices (itens) e arcos (relacionamentos).
De acordo com Furlan, modelar um sistema complexo é uma tarefa
extensiva sendo necessária a descrição de vários aspectos diferentes incluindo o
funcional, não funcional e organizacional. Cada visão é descrita em um número de
diagramas que contém informação enfatizando um aspecto particular do sistema.
4.4.2.1. Diagramas de Classes
Segundo BOOCH, RUMBAUGH e JACOBSON (2005), um diagrama de
classes mostra um conjunto classes, interfaces e colaborações e seus
relacionamentos. São os diagramas mais encontrados em sistemas de modelagem
orientados a objetos. Esses diagramas são utilizados para ilustrar a visão estática do
projeto de um sistema. Um diagrama de classes é apenas um tipo especial de
diagrama e compartilha as mesmas propriedades de todos os outros diagramas –
um nome e um conteúdo gráfico que são uma projeção em um modelo.
4.4.2.2. Diagramas de Colaboração
Conforme PAGE-JONES (2000), no diagrama de colaboração da UML, os
objetos que interagem por meio de mensagens aparecem como caixas padrões da
UML, com cada uma delas portando o nome de um objeto. Cada objeto é
identificado com o nome que os outros objetos utilizam para enviar-lhe uma
mensagem, uma vez que os objetos não têm realmente os seus próprios nomes. Em
outras palavras, um objeto destinatário adota o nome da variável no objeto
remetente que detém o identificador do objeto destinatário.
4.4.2.3. Diagramas de Objetos
Segundo GUEDES 2007, um diagrama de objetos mostra um conjunto de
objetos e seus relacionamentos. Esses diagramas são utilizados para ilustrar as
estruturas de dados, registros estáticos de instâncias dos itens encontrados nos
38
diagramas de classes. Os diagramas de objetos fazem a modelagem de instâncias
de itens contidos em diagramas de classes. A modelagem de estruturas dos objetos
envolve um retrato dos objetos de um sistema em um determinado momento.
Para FURLAN (1998) diagrama de colaboração é descendente direto do
diagrama de objeto, do gráfico de interação de objeto e várias outras fontes. Uma
colaboração é uma visão de um conjunto de elementos de modelagem relacionados
para um propósito particular em apoio a interações. Assim, um diagrama de
colaboração mostra ma interação organizada em torno de objetos e seus vínculos
formando uma base de padrões.
4.4.2.4. Diagramas de Componentes
Segundo FURLAN (1998) um diagrama de componente é um gráfico de
componentes conectados por relacionamentos de dependência de onde também
podem ser associados componentes a outros por retenção física que representa
relacionamentos de composição. Exibe as organizações e dependências entre
componentes com o propósito de modelar a visão de implementação dos módulos
de software executáveis com identidade e interface bem-definida de um sistema e
seus relacionamentos. Para cada elemento lógico no modelo, geralmente existe um
padrão que mapeia um artefato de implementação.
Furlan ainda afirma que um componente representa uma unidade de código
de software (fonte, binário ou executável) e pode ser usado para expor o compilador
e dependências de run-time, incluindo sua localização em nós. É desenhado como
um retângulo maior e derivado do método de Booch para representar um módulo.
4.4.2.5. Diagramas de Caso de Uso
Este é o diagrama mais geral e informal da UML, sendo utilizado
principalmente para auxiliar no levantamento e análise dos requisitos, em que são
determinadas as necessidades do usuário, e na compreensão do sistema como um
39
todo, embora venha a ser consultado durante todo o processo de modelagem e sirva
de base para todos os outros diagramas (GUEDES, 2007).
Conforme BOOCH, RUMBAUGH e JACOBSON (2005) os diagramas de
caso de uso são importantes para visualizar, especificar e documentar o
comportamento de um elemento. Esses diagramas fazem com que sistemas,
subsistemas e classes fiquem acessíveis e compreensíveis, por apresentarem uma
visão externa sobre como esses elementos podem ser utilizados no contexto.
Mostram um conjunto de casos de uso e atores e seus relacionamentos. Diagrama
de caso de uso é faz com que sistemas, subsistemas e classes fiquem acessíveis e
compreensíveis, por apresentarem uma visão externa sobre como esses elementos
podem ser utilizados no contexto.
4.4.2.6. Diagramas de Seqüência
Diagrama de seqüência é um diagrama de interação que dá ênfase à
ordenação temporal de mensagens. Um diagrama de seqüência mostra um conjunto
de papéis e as mensagens enviadas e recebidas pelas instâncias que representam
os papéis. O Diagrama de Seqüência preocupa-se com a ordem temporal em que as
mensagens são trocadas entre os objetos envolvidos em um determinado processo.
Em geral, baseia-se em um Caso de Uso definido pelo diagrama de mesmo nome e
apóia-se no Diagrama de Classes para determinar os objetos das classes envolvidas
em um processo, bem como os métodos disparados entre os mesmos. (GUEDES,
2007).
4.4.2.7. Diagramas de Atividade
Segundo FURLAN (1998) um diagrama de atividades mostra o fluxo de uma
atividade para outra em um sistema. Uma atividade mostra um conjunto de
atividades, o fluxo seqüencial ou ramificado de uma atividade para outra e os objetos
que realizam ou sofrem ações. Os diagramas de atividades são utilizados para fazer
a modelagem da função de um sistema e dão ênfase ao fluxo de controle na
40
execução de um comportamento com o propósito de estudar os fluxos dirigidos por
processamento interno, descrevendo as atividades desempenhadas em uma
operação.
4.4.2.8. Diagramas de Interação
BOOCH, RUMBAUGH e JACOBSON (2005) afirmam que os diagramas de
interação são utilizados para fazer a modelagem dos aspectos dinâmicos do
sistema. Na maior parte, isso envolve a modelagem de instâncias concretas ou
prototípicas de classes, interfaces, componentes e nós, juntamente com as
mensagens que são trocadas entre eles, tudo isso no contexto de aparecer sozinhos
para visualizar, especificar, construir e documentar a dinâmica de uma determinada
sociedade de objetos ou podem ser utilizados para fazer a modelagem de um
determinado fluxo de controle de um caso de uso.
Um diagrama de interação mostra uma interação formada por um conjunto
de objetos e seus relacionamentos, incluindo as mensagens que poderão ser
trocadas entre eles.
4.4.2.9. Diagramas de Implantação
Segundo FURLAN (1998), a UML fornece o diagrama de implantação para
mostrar a organização do hardware e a ligação do software aos dispositivos físicos.
Um diagrama de implantação denota vários dispositivos de hardware e interfaces
físicas determinados por seu estereótipo, como processador, impressora, memória,
disco e assim por diante.
FURLAN (1998) ainda afirma que a UML fornece notações avançadas e
semânticas quando uma modelagem mais complexa é requerida, ainda que algumas
dessas notações sejam destinadas a cobrir casos particulares e outras a estender a
UML de um modo controlado para apoiar modelagem do sistema global. Diagrama
de implantação expõe a configuração de elementos de run-time e componentes de
software, processos e objetos que neles se mantêm. Trata-se de um gráfico de nós
41
conectados por associações de comunicação. Os nós podem conter instâncias de
componentes que, por sua vez, podem conter classes, bibliotecas ou executáveis.
4.4.2.10. Diagramas de Gráfico de Estados
Segundo BOOCH, RUMBAUGH e JACOBSON (2005) um diagrama de
gráfico de estados mostra máquina de estados, dando ênfase ao fluxo de controle
de um estado para outro. Uma máquina de estados é um comportamento que
especifica as seqüências de estados pelos quais um objeto passa durante seu
tempo de vida em resposta a eventos, juntamente com suas respostas a esses
eventos. Um estado é uma condição ou situação na vida de um objeto durante a
qual ele satisfaz a alguma condição, realiza alguma atividade ou aguarda algum
evento. Um evento é uma especificação de uma ocorrência de um estímulo capaz de
ativar uma transição de estado.
BOOCH, RUMBAUGH e JACOBSON (2005) explicam ainda que uma
transição é um relacionamento entre dois estados, indicando que um objeto no
primeiro estado realizará certas ações e entrará no segundo estado quando um
evento especificado ocorrer e as condições especificadas estão satisfeitas. Uma
atividade é uma execução não-atômica em andamento em uma máquina de
estados. Uma ação é uma computação atômica executável que resulta em uma
alteração do estado do modelo ou no retorno de um valor.
4.5. Information Technology Infrastructure Library - ITIL
Segundo MAGALHÃES e PINHEIRO (2007) a ITIL é composta por um
conjunto das melhores práticas para a definição dos processos necessários ao
funcionamento de uma área de TI. Descreve a base para a organização dos
processos da área de TI, visando à sua orientação para o Gerenciamento de
Serviços de TI. As diversas práticas reunidas descrevem os objetivos, atividades
gerais, pré-requisitos necessários e resultados esperados dos vários processos, os
quais podem ser incorporados dentro das áreas de TI.
42
Para FRY (2003) é importante entender que os processos do ITIL não irão
tornar uma infra-estrutura “pobre” de TI em uma infra-estrutura “rica” de TI da noite
para o dia. Seus benefícios podem ser significantes, porém adaptar-se às melhores
práticas e processos não é tão fácil. Isto leva tempo, planejamento e principalmente
comprometimento.
Conforme MAGALHAES e PINHEIRO (2007) a ITIL não define os processos
a serem implantados na área de TI, não é uma metodologia para implementar
processos de Gestão de Serviços de TI – é um framework flexível que permite
adaptar-se para ir ao encontro das necessidades específicas, demonstra as
melhores práticas que podem ser utilizadas para esta definição. Tais práticas, por
sua vez, podem ser adotadas do modo que melhor puder atender às necessidades
de cada organização.
A seguir, serão descritos os processos da ITIL que serão utilizados nesse
trabalho.
4.5.1. Central de Serviços (Service Desk)
MAGALHÃES e PINHEIRO (2007) afirmam que a Central de Serviços,
também conhecida como Service Desk, é uma função e não um processo, essencial
para a implementação do Gerenciamento dos Serviços de TI. A Central de Serviços
atua como Ponto Único de Contato entre os usuários e os clientes dos serviços de TI
e os diversos processos relacionados com o Gerenciamento dos Serviços de TI.
Suas principais atividades são: o atendimento às chamadas, não importando o meio
de comunicação utilizado pelos usuários e clientes dos serviços de TI, e aos eventos
recebidos da equipe de supervisão da infra-estrutura de TI, visando a sua correta
classificação, além do encaminhamento para o processo de gerenciamento
adequado.
Destaca-se, ainda, como objetivo, garantir o encerramento do maior número
de incidentes e consultas dentro do seu nível de atendimento no processo de
43
Gerenciamento de Incidente, evitando a sobrecarga das demais equipes que atuam
no processo.
4.5.2. Gerenciamento de Incidentes
MAGALHÃES e PINHEIRO (2007) dizem que um incidente é qualquer
evento que não faz parte do funcionamento-padrão de um serviço de TI e que
causa, ou pode causar uma interrupção do serviço ou uma redução do seu nível de
desempenho. Na maioria das vezes, um incidente reportado refere-se à interrupção
do serviço de TI.
Ainda segundo MAGALHÃES e PINHEIRO (2007), o processo de
gerenciamento de incidente tem por objetivo assegurar que, depois da ocorrência de
um incidente, o serviço de TI afetado tenha restaurada a sua condição original de
funcionamento o mais breve possível, minimizando os impactos decorrentes do
efeito sobre o nível de serviço ou, até mesmo, da indisponibilidade total. A central de
serviços é a área responsável pelo atendimento dos usuários e registro dos
incidentes, passando a zelar por eles durante todo o seu ciclo de vida,
independentemente da área em que estejam sendo atendidos.
4.5.3. Gerenciamento de Problema
Segundo MAGALHÃES e PINHEIRO (2007), incidentes que se repetem
indefinidamente e para os quais não se fornece nenhuma solução definitiva, faz com
que os clientes da área de TI percam a confiança na capacidade da equipe de
suporte aos serviços de TI, deteriorando a imagem desta área perante a
organização. Tal fato, também atinge o moral dos integrantes da equipe de suporte
aos serviços de TI que se vêem reiteradamente tendo que resolver os mesmos
incidentes, onerando a sua capacidade de resolver novos acidentes e aumentar sua
contribuição para a organização. Todos os registros de problemas devem ser
relacionados a todos os registros de incidentes associados para ajudar o
gerenciamento de problema a determinar o impacto que tais problemas relacionados
44
a incidentes têm sobre o negócio. O principal objetivo do processo de
Gerenciamento de Problema é minimizar o impacto adverso no negócio dos
incidentes e problemas decorrentes de erros conhecidos relacionados com a infra-
estrutura de TI, prevenindo a repetição de incidentes relacionados com estes erros
conhecidos.
4.5.4. Gerenciamento de Nível de Serviço
Segundo MAGALHÃES e PINHEIRO (2007), o gerenciamento de nível de
serviço é a metodologia disciplinada e os procedimentos proativos utilizados para
garantir que níveis adequados de serviços serão entregues para todos os usuários
de TI de acordo com as prioridades do negócio e a um custo aceitável, acordado
com o cliente. A missão da equipe de gerenciamento de nível de serviço é manter e
gradualmente melhorar a qualidade dos serviços de TI, executando um ciclo
constante de acordar, monitorar, informar os êxitos dos serviços de TI e incitar ações
para erradicar um serviço de TI de baixo desempenho na relação custo/benefício ou
que não tenha mais importância para negócio, promovendo uma melhor relação
entre a área de TI e a organização.
4.6. ISO/IEC 20.000
MAGALHÃES e PINHEIRO (2007) afirmam que a ISO (International
Organization for Standardization) e IEC (International Electrotechnical Commission)
fazem parte do sistema especializado para padronização mundial. Entidades
nacionais que são membros da ISO ou IEC participam do desenvolvimento de
Padrões Internacionais através de comitês técnicos estabelecidos pela respectiva
organização para lidar com campos específicos de atividade técnica. A norma
ISO/IEC 20.000 foi desenvolvida para responder às necessidades de uma audiência
global e fornecer um entendimento comum do Gerenciamento de Serviços de TI em
todo o mundo. Esta norma está baseada na BS 15.000, que é uma norma britânica e
foi o primeiro padrão mundial orientado especificamente para o Gerenciamento de
Serviços de TI. A ISO/IEC 20.000 está dividida em duas partes: a ISO/IEC 20.000-
1:2005 e a ISO/IEC 20.000-2:2005.
45
Segundo MAGALHÃES e PINHEIRO (2007), dois dos maiores desafios
enfrentados pelas áreas de TI em relação ao gerenciamento dos serviços de TI são:
conseguir a atenção e o compromisso por parte da alta direção da organização e
garantir a aceitação e a adoção de um processo de Gerenciamento de Mudança por
toda a organização. Estas resistências são consideravelmente reduzidas nas
organizações registradas como certificadas ISO e que pretendem utilizar a norma
ISO/IEC 20.000 como um passo à frente para obterem uma certificação específica
no Gerenciamento de Serviços de TI. Neste tipo de cenário, a existência de um ciclo
de melhoria contínua envolve todos os stakeholders da organização. Ao mesmo
tempo, melhora a transparência, contribuindo para o aprimoramento do sistema de
gerenciamento da qualidade das operações da organização.
Ainda segundo MAGALHÃES e PINHEIRO (2007), a ISO/IEC 20.000-1:2005
é um documento de 16 páginas, publicado pela ISO, contém as especificações para
o Gerenciamento de Serviços de TI. Fornece os requisitos do gerenciamento de
serviços de TI na organização. Os índices da ISO/IEC 20.000-1:2005 são: Escopo;
Termos e Definições; Requisitos para um Sistema de Gerenciamento; Planejamento
e Implementação do Gerenciamento de Serviço; Planejamento e Implementação de
Serviços Novos ou Alterados; Processos de Entrega de Serviços; Processos de
Relacionamento; Processos de Resolução; Processos de Controle; Processo de
Gerenciamento de Liberação. A ISO/IEC 20.000-2:2005 é um documento de 34
páginas que apresenta o código de prática para o Gerenciamento de Serviços de TI.
Fornece orientação para os auditores internos e assistências aos prestadores de
serviços que planejam melhorias no serviço ou que querem preparar-se para
auditorias em relação à norma ISO/IEC 20.000-1:2005. Os índices da ISO/IEC
20.000-2:2005 são: Escopo; Termos e Definições; O sistema de gerenciamento;
Planejamento e Implementação do gerenciamento de Serviços; Processos de
Entrega de Serviços; Processos de Relacionamento; Processos de Resolução;
Processos de Controle; Processos de Gerenciamento de Liberação.
46
5. Proposta do Novo Sistema
Um sistema que interaja principalmente com o processo de gerenciamento
de incidente, executando, inclusive, parte das atividades deste processo, pelo
atendimento às chamadas originadas de erros percebidos pelos usuários na
interação com os serviços de TI. Prover uma interface para outras atividades
relacionadas com as demais necessidades dos usuários do sistema como
requisições de mudança, contratos de manutenção e solicitações de serviços.
Minimizar o impacto adverso no negócio dos incidentes e problemas
decorrentes de erros conhecidos relacionados com os serviços prestados pela
equipe de TI.
5.1. Descrição do Sistema Proposto
Desenvolver um sistema voltado para o gerenciamento de serviços de TI
prestado pela empresa Dave Systems (Empresa Fictícia) tendo o gerenciamento de
incidentes como o principal foco, de forma que torne a central de serviços à área
responsável pelo atendimento dos usuários e registro dos incidentes, passando a
zelar durante todo o ciclo de vida do incidente.
O sistema permitirá o cadastro de solicitações através de um canal de
comunicação. A comunicação poderá ser via e-mail, telefone ou qualquer outro meio
definido entre o provedor do serviço e o cliente. O analista de suporte fará o
cadastro das demandas e/ou à verificação para solução de um incidente. O analista
de incidente terá o controle das demandas enquanto a mesma estiver sendo
implementada e será responsável pelo feedback ao Analista de Suporte.
De posse de todo o serviço catalogado no sistema, os diretores facilmente
geram indicadores para tomada de decisão e/ou métricas para acompanhamento da
estratégia do negócio.
47
5.2. Resultados Esperados
Com a utilização do SISDESK, espera-se que haja um maior controle sobre
os incidentes e solicitações de mudanças cadastradas pelos clientes gerando,
assim, um incremento da velocidade de atendimento e a melhoria do índice de
satisfação dos clientes dos serviços de TI. Espera-se também, a melhora no
gerenciamento da informação para tomada de decisão relativa aos serviços
prestados aos clientes de TI.
5.3. Restrições do Sistema Proposto
A priori, o sistema terá o seu funcionamento apenas para a intranet da Dave
Systems. O sistema obriga ao usuário possuir login e senha e um tipo de perfil
associado a sua conta para que seja definido o nível de acesso ao sistema proposto.
Serão utilizados dados fictícios para alimentação da base de dados do
projeto, dessa forma, os dados reais da Dave Systems (Empresa Fictícia) serão
preservados.
Neste momento as matérias da ITIL que serão utilizadas para o
desenvolvimento do sistema são: gerenciamento de incidente, gerenciamento de
problema, gerenciamento de mudança e gerenciamento de nível de serviço.
5.4. Resultados Esperados
A relação custo x benefício de um sistema é questionada por vários fatores.
Redução com ligações telefônicas e identificação de erros visando à diminuição do
tempo da solução de um problema resulta em atenuar custos trazendo benefícios
lucrativos a empresa.
O sistema oferece vários benefícios como soluções mais rápidas, ambiente
único acessado por todos para cadastrar problemas e consultar soluções, assim
como identificar através de estatísticas as áreas mais problemáticas onde
48
necessitam de acompanhamento específico, sendo assim, diminuindo custos através
de tempo de produção.
Relatórios são emitidos periodicamente indicando a relação de problemas e
soluções para medir problemas e identificar erros relacionados em cada área para
direcionar decisões.
5.5. Áreas Afetadas Pelo Novo Sistema
Na empresa Dave Systems (Empresa Fictícia) as áreas que inicialmente
serão afetadas pelo novo sistema serão a gerência de suporte, gerência de projetos,
coordenação de análise, coordenação de desenvolvimento e diretores de TI.
5.6. Banco de Dados
A empresa para qual está sendo desenvolvido o SISDEK, utiliza o Oracle
como banco de dados. Partindo deste princípio, o banco de dados Oracle Express
10 g será utilizado para implementação do sistema evitando dessa forma, conflitos
no momento da implantação do software.
49
6. Documentação de Análise
Logo abaixo estão descritos os atores do sistema, identificando suas
funções dentro do mesmo. Está relaciona a lista de caso de uso que será
implementada no sistema, assim como é demonstrado o diagrama de casos de uso
e suas devidas especificações detalhadas. Neste tópico também é demonstrado
modelo de entidade e relacionamento, o diagrama de classes e a especificação das
tabelas do banco de dados.
6.1. Visão Macro dos Atores
O SISDESK possuirá os seguintes atores em seu sistema: Analista de
Suporte, Analista de Incidente, Técnico e Administrador.
6.2. Identificação dos Atores
O ator Analista de Suporte é responsável por criar um registro de incidente
com as informações disponíveis sobre o mesmo. Consiste em receber o registro de
incidente, seja ele por telefone, fax ou email, e criar o registro no gerenciamento de
incidente.
O ator Analista de Incidente é responsável por fornecer rapidamente uma
boa análise de um incidente e/ou uma solução para ela, a fim de restabelecer o
serviço perturbado o mais rápido possível. Esse papel será desenvolvido pelo
Analista de Sistema.
O Ator Gerente de Incidentes é responsável pela qualidade e a integridade
do processo de gerenciamento de incidente. Esta pessoa é a interface com outros
gerentes de processos.
O ator Técnico é responsável pela implementação de uma solução tanto
para um serviço interrompido quanto para uma solicitação de mudança. Esse papel
50
poderá ser realizado por Desenvolvedores, Administradores de Dados, Analista de
Banco de Dados ou Web Designers.
O ator Administrador é responsável pelo cadastro e exclusão de usuários no
sistema. Tem acesso a todos os módulos do sistema. Esta pessoa define, no perfil
de cada usuário, os módulos e as funcionalidades permitidas ao perfil agregado ao
usuário do sistema.
6.3. Lista dos Casos de Uso
Exposto abaixo a tabela com a lista de casos de uso do sistema.
Tabela 2 - Lista de Caso de Uso
Código Casos de Uso
UC01 Efetuar Login
UC02 Manter Usuário
UC03 Manter Incidente
UC04 Manter Mudança
UC05 Manter Problema
51
6.4. Diagrama de Caso de Uso
Exposto abaixo o diagrama de caso de uso do sistema.
uc Primary Use Cases
ServiceDesk
Usuario
Manter Incidente
Manter Problema
Manter Mudança
Manter Usuário
Admin
Efetuar Login
Figura 3 - Diagrama de Casos de Usos
52
6.5. Descrição Detalhada dos Casos de Uso
Abaixo é mostrada a especificação de caso de uso das funcionalidades do
sistema proposto.
UC01 – Efetuar Login
Tabela 3 - UC01 Efetuar Login
Nome UC01- Efetuar Login
Objetivo Efetuar Login.
Atores Administrador;
Usuários Cadastrados.
Dados Consumidos Login e senha.
Dados Produzidos Acesso ao sistema.
Prioridade Alta.
Pré-condições Possuir cadastro no sistema.
Pós-condições N/A
Fluxo Principal
Efetuar login.
Ator Sistema
Informar login e senha. Valida as informações do usuário e senha.
Se os dados estiverem OK, o sistema carrega a
página inicial. Se os dados estiverem incorretos, a aplicação retorna uma mensagem de erro.
Receber mensagem
Se a mensagem foi de erro, reinicie o processo do
fluxo principal.
Se a mensagem foi de sucesso, encerre o Fluxo
Fluxo Alternativo 1
N/A
53
UC03 – Manter Usuário
Tabela 4 – UC2 Manter Usuário
Nome UC03- Manter Usuário
Objetivo Cadastrar usuário no sistema.
Atores Administrador;
Usuários Cadastrados.
Dados Consumidos Nome, função, email e técnico.
Dados Produzidos Usuários Cadastrados.
Prioridade Alta.
Pré-condições Possuir cadastro no sistema;
Estar logado no sistema.
Pós-condições N/A
Fluxo Principal – Cadastrar Usuário
Ator Sistema
Acessar a página de cadastro de usuário. O sistema carrega a pagina para cadastrar um
novo usuário.
Preencher as informações relativas ao cadastro de usuário e clica no botão gravar.
O sistema valida as informações da tela. Se os
dados estiverem OK, armazená-los na tabela SD_TECNICO e enviar mensagem de operação realizada com sucesso. Se os dados não estiverem OK, enviar mensagem de erro.
Receber mensagem.
Se a mensagem foi de erro, reinicie o processo do
fluxo principal.
Se a mensagem foi de sucesso, encerre o Fluxo.
Fluxo Alternativo 1 – Consultar Usuário
Ator Sistema
Acessar a página de consulta de usuário. O sistema lista todos os usuários cadastrados.
Selecionar o registro. O sistema carrega na tela os dados do registro selecionado.
Fluxo Alternativo 2 – Alterar Usuário
Ator Sistema
Acessar a página de usuário. O sistema lista todos os usuários cadastrados.
Selecionar o item a ser modificado. O sistema carrega para a tela as informações referentes ao usuário selecionado.
Alterar as informações e clica no botão Gravar. O sistema valida as informações da tela. Se os
dados estiverem OK, armazená-los na tabela SD_TECNICO e enviar mensagem de operação
54
realizada com sucesso. Se os dados não estiverem OK, enviar mensagem de erro.
Receber mensagem.
Se a mensagem foi de erro, reinicie o processo do
fluxo alternativo 2.
Se a mensagem foi de sucesso, encerre o Fluxo
Fluxo Alternativo 3 – Excluir Usuário
Ator Sistema
Acessar a página de usuário. O sistema lista todos os usuários cadastrados.
Selecionar o item a ser excluído. O sistema carrega para a tela as informações referentes ao usuário selecionado.
Clicar no botão excluir. O sistema exclui os dados da base de dados e
envia mensagem de operação realizada com
sucesso.
Receber mensagem.
UC04 – Manter Incidente
Tabela 5 - UC03 Manter Incidente
Nome UC04- Manter Incidente
Objetivo Cadastrar Novo incidente no Sistema.
Atores Administrador;
Usuários Cadastrados.
Dados Consumidos Responsável, solicitante, impacto, nível, urgência, categoria, assunto,
descrição, data de abertura, data de conclusão.
Dados Produzidos Incidente cadastrado.
Prioridade Alta.
Pré-condições Possuir cadastro no sistema;
Estar logado no sistema.
Pós-condições Não se Aplica.
Fluxo Principal – Cadastrar Incidente
Ator Sistema
Acessar a página de cadastro de
Incidente do sistema.
O sistema carrega a pagina principal de incidente.
Preencher as informações relativas ao incidente e
clica no botão gravar.
O sistema valida as informações da tela. Se os
dados estiverem OK, armazená-los na tabela SD_INCIDENTE e enviar mensagem de operação.
Se os dados não estiverem OK, enviar mensagem
55
de erro.
Receber mensagem.
Se a mensagem foi de erro, reinicie o processo do
fluxo principal.
Se a mensagem foi de sucesso, encerre o Fluxo
Fluxo Alternativo 1 – Consultar Incidente
Ator Sistema
Acessar a página de incidente. O sistema lista todos os incidentes cadastrados.
Selecionar o registro. O sistema carrega na tela o registro selecionado.
Fluxo Alternativo 2 – Alterar Incidente
Ator Sistema
Acessar a página de incidente. O sistema lista todos os incidentes cadastrados.
Selecionar o item a ser modificado. O sistema carrega para a tela as informações referentes ao incidente selecionado.
Alterar as informações e clica no botão gravar. O sistema valida as informações da tela. Se os
dados estiverem OK, armazená-los na tabela SD_INCIDENTE e enviar mensagem de operação realizada com sucesso. Se os dados não estiverem OK, enviar mensagem de erro.
Receber mensagem.
Se a mensagem foi de erro, reinicie o processo do
fluxo alternativo 2.
Se a mensagem foi de sucesso, encerre o Fluxo
Fluxo Alternativo 3 – Excluir Incidente
Ator Sistema
Acessar a página de incidentes. O sistema lista todos os incidentes cadastrados.
Selecionar o item a ser excluído. O sistema carrega para a tela o incidente
selecionado.
Excluir o incidente e clica no botão Gravar. O sistema exclui os dados da base de dados e
envia mensagem de operação realizada com
sucesso.
Receber mensagem.
56
UC05 – Manter Mudança
Tabela 6 – UC04 Manter Mudança
Nome UC05- Manter Mudança
Objetivo Cadastrar Nova Mudança no Sistema.
Atores Administrador;
Usuários Cadastrados.
Dados Consumidos Responsável, impacto, solicitante, urgência, categoria, descrição, assunto,
Data de abertura, previsão de conclusão, data de inicio previsto, data início
Atendimento, impacto.
Dados Produzidos Mudança cadastrada.
Prioridade Média.
Pré-condições Possuir cadastro no sistema;
Estar logado no sistema.
Pós-condições Não se Aplica.
Fluxo Principal – Cadastrar Mudança
Ator Sistema
Acessar a página de cadastro de Mudança do
sistema.
O sistema carrega a pagina principal de mudança.
Preencher as informações relativas às mudanças e clica no botão gravar
O sistema valida as informações da tela. Se os
dados estiverem OK, armazená-los na tabela SD_MUDANCA e enviar mensagem de operação realizada com sucesso. Se os dados não estiverem OK, enviar mensagem de erro.
Receber mensagem.
Se a mensagem foi de erro, reinicie o processo do
fluxo principal.
Se a mensagem foi de sucesso, encerre o Fluxo
Fluxo Alternativo 1 – Consultar Mudança
Ator Sistema
Acessar a página de mudança. O sistema lista todas as mudanças cadastradas.
Selecionar o registro. O sistema carrega na tela o registro selecionado.
Fluxo Alternativo 2 – Alterar Mudança
Alterar Mudança
Ator Sistema
Acessar a página de mudança. O sistema lista todas as mudanças cadastradas.
Selecionar a mudança a ser modificada. O sistema carrega para a tela as informações referentes à mudança selecionada.
Alterar as informações e clica no botão gravar. O sistema valida as informações da tela. Se os
dados estiverem OK, armazená-los na tabela SD_MUDANCA e enviar mensagem de operação
57
realizada com sucesso. Se os dados não estiverem OK, enviar mensagem de erro.
Receber mensagem.
Se a mensagem foi de erro, reinicie o processo do
fluxo alternativo 2.
Se a mensagem foi de sucesso, encerre o Fluxo
Fluxo Alternativo 3 – Excluir Mudança
Ator Sistema
Acessar a página de mudança. O sistema lista todas as mudanças cadastradas.
Selecionar a mudança à ser excluída. O sistema carrega para a tela o registro
selecionado.
Excluir a mudança e clica no botão gravar. O sistema exclui os dados da base de dados e
envia mensagem de operação realizada com
sucesso.
Receber mensagem.
UC06 – Manter Problema
.
Tabela 7 - UC05 Manter Problema
Nome UC06- Manter Problema
Objetivo Cadastrar Problema.
Atores Administrador;
Usuários Cadastrados.
Dados Consumidos Responsável, impacto, solicitante, urgência, categoria, descrição, assunto,
Data de abertura, previsão de conclusão, data de inicio previsto, data início
Atendimento, impacto.
Dados Produzidos Problema cadastrado.
Prioridade Alta.
Pré-condições Possuir cadastro no sistema;
Usuário estar logado no sistema.
Pós-condições Não se aplica.
Fluxo Principal – Cadastrar Problema
Ator Sistema
Acessar a página de cadastro de Problema. O sistema carrega a pagina de cadastro do
problema.
Preencher as informações relativas ao problema e
clicar no botão gravar.
O sistema valida as informações da tela. Se os
dados estiverem OK, armazená-los na tabela SD_PROBLEMA e enviar mensagem de operação realizada com sucesso. Se os dados não estiverem OK, enviar mensagem de erro.
58
Receber mensagem.
Se a mensagem foi de erro, reinicie o processo do
fluxo principal.
Se a mensagem foi de sucesso, encerre o Fluxo
Fluxo Alternativo 1 – Consultar Problema
Consulta de Problema.
Ator Sistema
Acessar a página de problema. O sistema lista todos os problemas cadastrados.
Selecionar o registro. O sistema carrega na tela o registro selecionado.
Fluxo Alternativo 2 – Alterar Problema
Ator Sistema
Acessar a página de problema. O sistema lista todos os problemas cadastrados.
Selecionar o problema a ser modificado. O sistema carrega para a tela as informações referentes ao problema selecionado.
Alterar as informações e clica no botão gravar. O sistema valida as informações da tela. Se os
dados estiverem OK, armazená-los na tabela SD_PROBLEMA e enviar mensagem de operação realizada com sucesso. Se os dados não estiverem OK, enviar mensagem
de erro.
Receber mensagem.
Se a mensagem foi de erro, reinicie o processo do
fluxo alternativo 2.
Se a mensagem foi de sucesso, encerre o Fluxo
Fluxo Alternativo 3 – Excluir Problema
Ator Sistema
O usuário acessa a página de problema. O sistema lista todos os problemas cadastrados.
O usuário seleciona o problema a ser modificado. O sistema carrega para a tela o problema
selecionado.
Excluir o problema e clica no botão excluir. O sistema exclui os dados da base de dados e
envia mensagem de operação realizada com
sucesso.
Receber mensagem.
59
6.6. Diagrama de Classes
Existem três tipos de perspectivas oferecidas no desenvolvimento de um
diagrama de classe: Perspectiva conceitual, que representa os conceitos do domínio
em estudo. Essa é uma perspectiva voltada para o cliente; Perspectiva de
especificação, que foca nas principais interfaces e métodos da arquitetura e não
como na forma que eles serão implementados. Essa perspectiva é voltada para
pessoas que não necessitam do detalhamento do desenvolvimento; Perspectiva de
implementação, que aborda a forma como será o sistema será implementado. Essa
é uma perspectiva voltada para a equipe de desenvolvimento.
Na implementação do trabalho proposto, será utilizada a perspectiva de
especificação. Na figura abaixo é mostrado o diagrama de classe do sistema.
class System
SOLICITACAO
+ alterar(Objeto) : void {query}
+ consultar(Objeto) : void {query}
+ excluir(Objeto) : void {query}
+ gravar(Objeto) : void {query}
INCIDENTE
+ getters() : Incidente {query}
+ setters() : void {query}
MUDANCA
+ getters() : EstadoMudanca {query}
+ setters() : void {query}
PROBLEMA
+ getters() : EstadoProblema {query}
+ setters() : void {query}
TECNICO
+ getters() : Tecnico {query}
+ setters() : void {query}
FUNCAO
+ getters() : void
Figura 4 - Diagrama de Classe
60
6.7. Modelo de Entidade e Relacionamento
Abaixo é mostrado o modelo de entidade e relacionamento utilizado no
desenvolvimento do sistema.
Figura 5 - Modelo de Entidade e Relacionamento
61
6.8. Especificação das Tabelas
6.8.1. Tabela SD_ANEXOINCIDENTE
Esta tabela é utilizada para armazenar os anexos do incidente.
Tabela 8 - SD_ANEXOINCIDENTE
ATRIBUTOS TIPO DO DADO CHAVE PRIMÁRIA CHAVE ESTRANGEIRA DESCRIÇÃO
ID_ANEXOINCIDENTE Long Sim Identificador
ID_INCIDENTE Long Sim Identificador da tabela SD_INCIDENTE.
NM_NOME varchar(500)
Campo utilizado para
especificar o nome com
o qual deseja identificar
cada anexo do
incidente.
DS_DESCRICAO varchar(2000)
Campo utilizado para armazenar a descrição do anexo de forma que ajude a compreender detalhes do anexo.
ANEXO_BLOB BLOB Campo utilizado para armazenar o anexo.
6.8.2. Tabela SD_ANEXOMUDANCA
Tabela utilizada para separar os anexos referentes à mudança.
Tabela 9 - SD_ANEXOMUDANCA
ATRIBUTOS TIPO DO DADO CHAVE PRIMÁRIA CHAVE ESTRANGEIRA DESCRIÇÃO
ID_ANEXOMUDANCA Long Sim Identificador
ID_MUDANCA Long Sim Identificador da tabela SD_MUDANCA
DS_DESCRICAO varchar(50) Campo utilizado para descrição do anexo
NM_NOME varchar(500) Campo utilizado para armazenar o nome do anexo
NM_TIPO Varchar(50) Campo utilizado para armazenar o tipo do anexo. Tipo de anexo: CADASTRO - Anexo do tipo principal. IMPACTO - Anexo do impacto ROLLOUT - Anexo do ROLL_OUT BACKOUT - Anexo do BACK_OUT REVISAO - Anexo da REVISAO
ANEXO_BLOB BLOB Campo utilizado para armazenar o anexo.
62
6.8.3. Tabela SD_ESTADOMUDANCA
Tabela utilizada para armazenar os estados da mudança.
Tabela 10 - SD_ESTADOMUDANCA
ATRIBUTOS TIPO DO DADO CHAVE
PRIMÁRIA CHAVE ESTRANGEIRA DESCRIÇÃO
ID_ESTADOMUDANCA Long Sim Identificador
NM_NOME Varchar (500) Armazena o nome único com o qual deseja identificar cada estado de mudança.
NM_TEMPORIZADOR Varchar (50) Armazena o tempo gasto na implementação da mudança
DS_DESCRICAO Varchar(2000) Armazena a descrição do estado da mudança de forma que ajude a compreender cada estado.
6.8.4. Tabela SD_FUNCAO
Tabela utilizada para armazenar a função do técnico dentro do sistema.
Tabela 11 - SD_FUNCÃO
ATRIBUTOS TIPO DO DADO CHAVE
PRIMÁRIA CHAVE ESTRANGEIRA DESCRIÇÃO
ID_FUNCAO Long Sim Identificador
NM_NOME Varchar (500) Armazena o nome único com o qual deseja identificar cada função de um técnico. Ex: Analista, Desenvolvedor, DBA, entre outras funções.
DS_DESCRICAO Varchar(2000) Armazena a descrição de cada função de forma que ajude a compreender cada função
63
6.8.5. TABELA SD_IMPACTO
ATRIBUTOS TIPO DO DADO CHAVE
PRIMÁRIA CHAVE ESTRANGEIRA DESCRIÇÃO
ID_IMPACTO Long Sim Identificador
NM_NOME Varchar (500) Armazena o nome único com o qual deseja identificar cada impacto de uma solicitação. Ex: Afeta o setor financeiro; Afeta o setor de almoxarifado.
DS_DESCRICAO Varchar(2000) Armazena a descrição de cada impacto de forma que ajude a compreender cada impacto.
6.8.6. Tabela SD_INCIDENTE
Tabela utilizada para armazenar incidentes.
Tabela 12 - SD_INCIDENTE
ATRIBUTOS TIPO DO DADO CHAVE
PRIMÁRIA CHAVE ESTRANGEIRA DESCRIÇÃO
ID_INCIDENTE Long Sim Identificador
ID_RESPONSAVEL Long Sim Identificador da tabela SD_RESPONSAVEL
DS_SOLICITANTE Long Identificador da tabela SD_SOLICITANTE
ID_IMPACTO Long Sim Identificador da tabela SD_IMPACTO
ID_MODO Long Sim Identificador da tabela SD_MODO
ID_NIVEL Long Sim Identificador da tabela SD_NIVEL
ID_URGENCIA Long Sim Identificador da tabela SD_URGENCIA
ID_CATEGORIA Long Sim Identificador da tabela SD_CATEGORIA
NM_ASSUNTO Varchar(500) Armazena o assunto relacionado ao incidente cadastrado
DS_RESOLUCAO Varchar(800) Descrição da solução do incidente
DS_DESCRICAO Varchar(2000) Armazena a descrição do incidente
DT_ABERTURA Date Armazena a data de abertura do incidente
DT_PREVCONCLUSAO Date Armazena a data de previsão de resolução do incidente
DT_INICIOPREVISTA Date Armazena a data prevista para o início da resolução do incidente
DT_INICIOATENDIMENTO Date Armazena a data real do início do atendimento
64
6.8.7. Tabela SD_MATRIZPRIORIDADE
Tabela utilizada para armazenar a prioridade com base no impacto e urgência.
Tabela 13 - SD_ MATRIZPRIORIDADE
ATRIBUTOS TIPO DO DADO CHAVE PRIMÁRIA CHAVE ESTRANGEIRA DESCRIÇÃO
ID_IMPACTO Long Sim Identificador da tabela SD_IMPACTO
ID_PRIORIDADE Long Sim Identificador da tabela SD_PRIORIDADE
ID_URGENCIA Long Sim Identificador da tabela SD_URGENCIA
6.8.8. Tabela SD_MUDANCA
Tabela utilizada para armazenar as solicitações de mudanças.
Tabela 14 - SD_MUDANCA
ATRIBUTOS TIPO DO DADO CHAVE
PRIMÁRIA CHAVE
ESTRANGEIRA DESCRIÇÃO
ID_MUDANCA Long Sim Identificador
ID_MODO Long Sim Identificador da tabela SD_MODO
ID_RESPONSAVEL Long Sim Identificador da tabela SD_TECNICO
ID_NIVELMUDANCA Long Sim Identificador da tabela SD_NIVELMUDANCA.
ID_IMPACTO Long Sim Identificador da tabela SD_IMPACTO
ID_SOLICITANTE Long Sim Identificador da tabela SD_SOLICITANTE
ID_URGENCIA Long Sim Identificador da tabela SD_SOLICITANTE
ID_CATEGORIA Long Sim Identificador da tabela SD_CATEGORIA
NM_DESCRICAO Varchar(50) Armazena a descrição da mudança
NM_ASSUNTO Varchar(2000) Armazena o assunto da mudança
DT_ABERTURA Date Armazena a data de abertura da mudança
DT_PREVISAOCONCLUSAO Date Armazena a data de abertura da mudança
DT_INICIOPREVISTA Date Armazena a data de previsão de início do atendimento da mudança
DT_INICIOATENDIMENTO Date Armazena a data real de início do atendimento.
NM_RESOLUCAO Varchar(500) Descreve a resolução da mudança
NM_IMPACTO Varchar(4000) Descreve o impacto que a mudança poderá causar
NM_PLANOROLLOUT Varchar(4000) Plano que definirá qual estratégia utilizada para atender
65
a mudança NM_PLANOBACKOUT Varchar(4000) Plano que definirá
qual estratégia utilizada para solucionar um problema ocorrido com a implementação da mudança
NM_LISTAVERIFICACAO Varchar(4000) Lista utilizada para verificar o atendimento das tarefas
NM_REVISAO Varchar(4000) Revisar a mudança realizada
6.8.9. Tabela SD_MUDANCAESTADO
Tabela utilizada para armazenar a associação entre as entre as tabelas
SD_MUDANCA e SD_ESTADOMUDANCA.
Tabela 15 - SD_MUDANCAESTADO
ATRIBUTOS TIPO DO DADO CHAVE
PRIMÁRIA CHAVE ESTRANGEIRA DESCRIÇÃO
ID_MUDANCAESTADO Long Sim Identificador.
ID_ESTADOMUDANCA Long Sim Identificador da tabela SD_ESTADOMUDANCA
ID_MUDANCA Long Sim Identificador da tabela SD_MUDANCA
6.8.10. Tabela SD_NIVELMUDANCA
Tabela utilizada para armazenar a classificação dos níveis de mudança.
Tabela 16 - SD_NIVELMUDANCA
ATRIBUTOS TIPO DO DADO CHAVE PRIMÁRIA CHAVE ESTRANGEIRA DESCRIÇÃO
ID_NIVELMUDANCA Long Sim Identificador
NM_NOME Varchar(500) Campo utilizado para especificar o nome único com o qual deseja identificar cada nível de mudança.
DS_DESCRICAO Varchar(2000) Campo utilizado para
descrever o nível de
mudança.
6.8.11. Tabela SD_PRIORIDADE
Tabela utilizada para armazenar a importância atribuída a um pedido.
66
Tabela 17 - SD_PRIORIDADE
ATRIBUTOS TIPO DO DADO CHAVE PRIMÁRIA CHAVE ESTRANGEIRA DESCRIÇÃO
ID_PRIORIDADE Long Sim Identificador
NM_NOME Varchar(500) É onde deve especificar o nome único com o qual deseja identificar cada prioridade
NM_COR Varchar(50) Define a cor da prioridade
DS_DESCRICAO Varchar(2000) Ajuda a compreender a prioridade
6.8.12. Tabela SD_TECNICO
Tabela utilizada para armazenar os técnicos que estarão envolvidos no
processo de desenvolvimento de software. Nesta tabela conterá também a
equipe de suporte que fará o primeiro contato com cliente.
Tabela 18 - SD_TECNICO
ATRIBUTOS TIPO DO DADO CHAVE
PRIMÁRIA CHAVE ESTRANGEIRA DESCRIÇÃO
ID_TECNICO Long Sim Identificador
ID_FUNCAO Long Sim Identificador da tabela SD_FUNCAO
NM_LOGIN Varchar(50) Login utilizado para
conectar na aplicação.
NM_SENHA Varchar(50) Campo utilizado para armazenar a senha do técnico
NM_CUSTOPORMNUTO Number(8,2) Campo utilizado para armazenar custo da tarefa realizada pelo técnico
NM_EMAIL Varchar(50) Campo utilizado para armazenar o email do técnico.
NM_NOME Varchar(100) Campo utilizado para armazenar o nome
67
6.8.13. Tabela SD_URGENCIA
Tabela utilizada para armazenar a velocidade necessária para resolução de um
incidente.
Tabela 19 - SD_URGENCIA
ATRIBUTOS TIPO DO DADO CHAVE
PRIMÁRIA CHAVE ESTRANGEIRA DESCRIÇÃO
ID_URGENCIA Long Sim Identificador
NM_NOME Varchar(50) É onde deve especificar o nome único com o qual deseja identificar cada urgência
DS_DESCRICAO Varchar(2000) Ajuda a compreender a urgência
6.9. Árvore do Sistema
Segue abaixo uma representação gráfica da estrutura do sistema proposto.
A árvore foi criada como modelo de mapa mental, pois, facilita a visualização,
memorização e compreensão da estrutura do sistema.
Figura 6 - Árvore do Sistema
68
6.10. Especificações Físicas
Logo abaixo serão mostradas as telas do sistema proposto, o Help on-line e
a segurança física e lógica com as suas devidas normas.
6.10.1. Layout das Principais Telas da Aplicação
A seguir, serão mostradas o protótipo das principais telas do sistema
proposto. As telas de edição usarão as mesmas de cadastro, portanto serão
mostradas apenas as telas de cadastro.
Abaixo é mostrada a tela utilizada para efetuar o login no sistema.
Figura 7 - Tela de Login
69
Em seguida, é mostrada a tela para cadastro de uma nova solicitação. O
usuário determinará se a solicitação é uma Incidente ou um Problema.
Figura 8 - Nova Solicitação
Ao clicar em „Adicionar Solução‟ a tela abaixo é apresenta para a descrição
da solução da solicitação.
Figura 9 - Adicionar Solução
70
Abaixo é apresentada a tela de cadastro de problema:
Figura 10 - Cadastro de Problema
O protótipo abaixo retrata a tela de cadastro do usuário.
Figura 11 - Cadastro de Usuário
71
6.11. Help on-line
O Help on-line é um mecanismo de ajuda e suporte ao usuário para utilizar e
operar o sistema. O mesmo disponibiliza um tópico de ajuda para a navegação e
utilização do software. A opção „Ajuda‟ se encontra na parte superior das telas do
sistema com o formato do sinal de interrogação indicando a ferramenta de ajuda.
6.12. Segurança Física e Lógica
Para que a segurança de um sistema obtenha êxito em seu funcionamento é
necessário que seus dados, assim como seus servidores e outros equipamentos
sejam protegidos. Segurança física é impedir o acesso não autorizado a
equipamentos e segurança lógica é impedir o acesso das informações de um
sistema. Todos que fazem uso das informações do sistema proposto devem ter
acesso conforme definição de cada perfil do usuário. Vários fatores deverão ser
analisados na segurança física e lógica, a fim de se obter uma proteção máxima do
sistema e de seus equipamentos.
6.12.1. Norma de Segurança Física
As normas de segurança física têm como objetivo zelar e guardar o servidor
de aplicação e servidor de banco de dados, onde deverá ser mantido de forma
isolada de outros recursos de informática, como também deverá ser protegido de
incêndios, desabamentos, relâmpagos, acesso indevido de pessoas, furto e outros
fatores que possam causar danos ao mesmo. Dessa forma, a Dave Systems possui
um setor chamado COINF (Coordenadoria de Infraestrutura), que implementa todas
as normas citadas acima.
6.12.2. Norma de Segurança Lógica
Segurança lógica é a forma como o sistema deverá ser protegido no nível de
sistema operacional. Deverão existir normas de políticas de segurança para definir o
acesso das informações no sistema. Todo usuário deve ter uma identificação única,
72
pessoal e intransferível, qualificando-o, inequivocamente, como responsável por
qualquer atividade desenvolvida sob esta identificação.
O sistema proposto define tipos de perfis conforme cada tipo de atuação
dentro da empresa. Permite a correta identificação de um usuário para lhe conferir
acesso de acordo com seu perfil. Possibilitam especificar as ações permitidas e
níveis de privilégio diferenciados para cada usuário através do estabelecimento de
políticas de uso.
73
7. Plano de Implantação
A finalidade do Plano de Implantação é garantir que o sistema alcance seus
usuários com sucesso. O Plano de Implantação fornece uma agenda detalhada de
eventos, pessoas responsáveis e dependências de evento necessárias para garantir
a mudança bem-sucedida para o novo sistema. A implantação deve minimizar o
impacto da mudança na equipe do cliente, no sistema de produção e na rotina geral
dos negócios (RUP, 2010).
O servidor de aplicação para o ambiente de produção definido, de forma que
haja as mínimas condições de funcionamento do sistema é possuir uma maquina
com o processador Intel Core 2 Duo, 4 gigabyte de memória, Apache Tomcat 6 ou
uma versão superior, Java 5 ou uma versão superior.
Para o banco de dados, a configuração mínima é conter um computador que
possua um processador Intel Core 2 Duo, 8 gigabyte de memória, Sistema
Operacional – Windows e Oracle 10g XE.
74
8. Conclusão
Muitas instituições possuem demandas internas de serviços que precisam ser
registradas, analisadas e executadas, para que dessa forma tenham um ponto único
de controle dos serviços prestados. Partindo desse princípio foi desenvolvido um
projeto de gerenciamento de serviços voltado exclusivamente para o
desenvolvimento de software, que será implantado na empresa Dave Systems
(Empresa Fictícia).
O trabalho desenvolvido visa centralizar os serviços internos prestados, a
geração de relatórios gerenciais, a substituição do atual sistema devido a sua
inconsistência de dados e a utilização do mesmo para a implantação da ISO/IEC
20000.
Como resultado obteve-se um sistema capaz de atender e gerenciar os
incidentes abordando todas as demandas, classificando e ordenando-os conforme o
tipo de incidente possibilitando a centralização na tomada de decisão, assim como o
seu gerenciamento.
Atualmente o sistema dá ênfase a implementação as disciplinas de
Gerenciamento de Incidente, Gerenciamento de Problema e Gerenciamento de
Mudança e o desenvolvimento de um Service Desk. Como trabalhos futuros, serão
implementados as disciplinas de Gerenciamento de Configuração, Gerenciamento
de Nível de Serviço e Gerenciamento de Liberação ficando a cargo da equipe de
desenvolvimento da empresa Dave Systems (Empresa Fictícia).
75
9. Referencias Bibliográficas
[1] BMC SOFTWARE. ISO 20000: O que deve uma organização fazer? Disponível em: <http://documents.bmc.com/products/documents/49/68/64968/64968.pdf>. Acessado em 29 de Junho de 2010. [2] SEBRAE. Programação e Controle de Produção. Disponível em: <http://www.sebraesp.com.br/faq/produtividade/programacao_controle_producao/cronograma>. Acessado em 25 de maio de 2010. [3] SUN. JAVA. Disponível em <http://www.java.com/ >. Acessado em 03 de Abril de 2010. [4] DEVMEDIA, Oracle Free. Disponível em: <http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=2317>. Acessado em 03 de Junho de 2010. [5] POSTGRESQL, site oficial. Sobre o PostgreSQL. Disponível em: <http://www.postgresql.org.br/sobre>. Acessado em 26 de junho de 2010. [6] RUP, Rational Unified Process. Melhor Prática: Desenvolva iterativamente. Disponível em: <http://www.wthreex.com/rup/manuals/intro/im_bp1.htm>. Acessado em 05 de abril de 2010. [7] UML, Unified Model Language. Diagrama de Classes. Disponível em:<http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/diagramas/classes/classes1.htm > ABBEY, Michael; COREY, Michael J.; ABRAMSON, Ian. Oracle 8i Guia Introdutório. Rio de Janeiro: Campus, 2000. ABBEY, Michael; COREY, Michael J. Oracle, Guia do Usuário. São Paulo: Makron Books, 1997. ANDRADE, Gabriel. O Que são Linguagens de Programação. <http://www.infoescola.com/informatica/o-que-sao-linguagens-de-programacao>. Acessado em 29 de abril de 2010. BOOCH, Grandy; RUMBAUGH, James; JACOBSON, Ivar; UML Guia do Usuário. Rio de Janeiro: Campus, 2005. CADERNHEAD, Rogers; LEMMAY, Laura. Aprenda Java em 21 Dias. Rio de Janeiro: Campus, 2005. CONVERSE, Tim; PARK, Joyce. PHP 4 a Bíblia. Rio de Janeiro: Campus, 2001. DEITEL, Harvey M.; DEITEL, Paul J. Java Como Programar. São Paulo: Pearson Prentice Hall 6° Edição, 2005
76
FRY, Malcolm. The Goals of ITIL: Exploring the goals of Service Management. Sunnyvale, USA: Remedy, 2003. FURLAN, José Davi. Modelagem de Objetos Através da UML. São Paulo: Makron, 1998. GONÇALVES, Edson. Desenvolvendo Aplicações Web com NetBeans IDE 5.5. Rio de Janeiro: Ciência Moderna, 2007. GUEDES, Gilleanes. UML 2 Guia Prático. São Paulo: Novatec 2007. LISCHNER, Ray. Delphi. O Guia Essencial. Rio de Janeiro: Campus, 2000 KRUCHTEN, Philippe. Introdução ao RUP RATIONL UNIFIED PROCESS. Rio de Janeiro: Moderna, 2003. MAGALHÃES, Ivan Luizio; PINHEIRO, Walfrido Brito. Gerenciamento de Serviços de TI na Prática, Uma abordagem com base na ITIL. São Paulo: Novatec, 2007. MATOS, Alexandre Veloso. UML, Prático e Descomplicado. São Paulo: Érica, 2002. PAGE-JONES, Meilir. Fundamento do Desenho Orientado a Objeto Com UML. Makron Books, 2000. PENDER, Tom. UML a Bíblia. Campus 2004. SANTOS, Lucas Lopes. MySQL. Disponível em: < http://www.malima.com.br/article_read.asp?id=142> Acessado em 26 de abril de 2010. SANTOS, Rafael. INTRODUÇÃO À PROGRAMAÇÃO ORIENTDA A OBJETOS USANDO JAVA. São Paulo: Campus, 2003. SHEPHERD, George. ASP.NET Passo a Passo. São Paulo: Bookmark, 2006. SWAN, Tom. Delphi, Bíblia do Programador. São Paulo: IDG BOOKS 3° Edição, 1997.
