FACULDADE ALVORADA

CURSO DE BACHARELADO EM SISTEMAS DE INFORMAO

Francisco David Costa de Oliveira

SISDESK - Sistema de Service Desk voltado para

desenvolvimento de software

Orientadora: Profa. Mestra Elizabeth dArrochella Teixeira

Braslia DF,
Dezembro de 2010

ii

FRANCISCO DAVID COSTA DE OLIVEIRA

SISDESK - Sistema de Service Desk voltado para

desenvolvimento de software

Trabalho de Concluso de Curso apresentado

Banca Examinadora, como exigncia parcial para
a obteno do ttulo de Bacharelado em Sistemas
de Informao e Sociedade de Ensino
Tecnologia, Educao e Cultura

Orientadora: Profa. Mestre Elizabeth dArrochella Teixeira

Braslia DF,
Dezembro de 2010

iii

iv

EPGRAFE

At as mais altas torres comearam do cho...

Provrbio Chins.

RESUMO
As empresas de TI (Tecnologia da Informao) tm se preocupado cada vez
mais com a qualidade de entrega de servios e entendem a importncia que a alta
disponibilidade da Tecnologia da Informao traz aos seus negcios. Desta forma,
buscam solues inovadoras e pioneiras de mercado, fazendo com que a demanda
de produtividade seja atendida atravs de solues com alto valor agregado,
integradas, customizadas, reduzindo custos, tornando a rea de Tecnologia da
Informao um aliado vital ao seu negcio. Uma das formas de atingir este objetivo
implementando o gerenciamento de servios de TI. Este trabalho mostra um estudo
referente aos processos da ITIL (Information Technology Infrastructure Library) e
apresenta a implementao de um sistema de Service Desk.

Palavras-Chave: ITIL. Central de Servios. Incidente. Solicitao de Mudana.

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 - Grfico 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 Solicitao ....................................................................................... 69
Figura 10 - Adicionar Soluo ................................................................................... 69
Figura 11 - Cadastro de Problema ............................................................................ 70
Figura 12 - Cadastro de Usurio ............................................................................... 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 Usurio ................................................................................ 53
Tabela 5 - UC03 Manter Incidente ............................................................................ 54
Tabela 6 UC04 Manter Mudana ........................................................................... 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_FUNCO ......................................................................................... 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

International Organization for Standardization

ISSO
ITIL
JDBC

Information Technology Infrastructure Library

Java DataBase Connectivity

LDAP

Lightweight Directory Access Protocol

ODBC

Open Database Connectivity

OMC

Object Management Group

OOSE
PHP

Object-Oriented Software Engineering

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 Informao

UML

Unified Model Language

10

SUMRIO

1. Introduo ........................................................................................................... 13
1.1. Tema................................................................................................................... 14
1.2. Justificativa ......................................................................................................... 14
1.3. Formulao do Problema.................................................................................... 15
1.4. Objetivos ............................................................................................................. 16
1.4.1.

Geral ............................................................................................................ 16

1.4.2.

Especficos ................................................................................................... 16

1.5. Organizao do Trabalho ................................................................................... 17

2. Anlise Institucional ............................................................................................ 18
2.1. Empresa e seu Negcio...................................................................................... 18
2.1.1.

Organograma da Empresa ........................................................................... 18

2.2. Descries das Necessidades ............................................................................ 19

2.3. Sistemas de Informao Existente na Empresa ................................................. 19
2.4. Normas de Funcionamento................................................................................. 19
2.5. Ambiente Tecnolgico Existente ......................................................................... 20
3. Cronograma ........................................................................................................ 21
4. Referencial Terico ............................................................................................. 22
4.1. Linguagem de Programao............................................................................... 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.

Concepo ................................................................................................ 30

4.3.2.2.

Elaborao ................................................................................................ 30

11

4.3.2.3.

Construo................................................................................................ 31

4.3.2.4.

Transio .................................................................................................. 31

4.4. UML (Unified Model Language) .......................................................................... 32

4.4.1.

Orientao a Objetos ................................................................................... 33

4.4.1.1.

Objetos...................................................................................................... 34

4.4.1.2.

Classes ..................................................................................................... 34

4.4.1.3.

Herana .................................................................................................... 35

4.4.1.4.

Polimorfismo ............................................................................................. 35

4.4.1.5.

Coeso...................................................................................................... 36

4.4.2.

Diagramas .................................................................................................... 36

4.4.2.1.

Diagramas de Classes .............................................................................. 37

4.4.2.2.

Diagramas de Colaborao ...................................................................... 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 Seqncia .......................................................................... 39

4.4.2.7.

Diagramas de Atividade ............................................................................ 39

4.4.2.8.

Diagramas de Interao ............................................................................ 40

4.4.2.9.

Diagramas de Implantao ....................................................................... 40

4.4.2.10.

Diagramas de Grfico de Estados ......................................................... 41

4.5. Information Technology Infrastructure Library - ITIL ........................................... 41

4.5.1.

Central de Servios (Service Desk).............................................................. 42

4.5.2.

Gerenciamento de Incidentes ...................................................................... 43

4.5.3.

Gerenciamento de Problema ....................................................................... 43

4.5.4.

Gerenciamento de Nvel de Servio ............................................................. 44

4.6. ISO/IEC 20.000 ................................................................................................... 44

5. Proposta do Novo Sistema ................................................................................. 46
5.1. Descrio do Sistema Proposto .......................................................................... 46
5.2. Resultados Esperados ........................................................................................ 47
5.3. Restries 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. Documentao de Anlise .................................................................................. 49

6.1. Viso Macro dos Atores ...................................................................................... 49
6.2. Identificao dos Atores...................................................................................... 49
6.3. Lista dos Casos de Uso ...................................................................................... 50
6.4. Diagrama de Caso de Uso.................................................................................. 51
6.5. Descrio Detalhada dos Casos de Uso ............................................................ 52
6.6. Diagrama de Classes.......................................................................................... 59
6.7. Modelo de Entidade e Relacionamento .............................................................. 60
6.8. Especificao 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.
6.10.1.

Especificaes Fsicas ................................................................................. 68

Layout das Principais Telas da Aplicao ................................................. 68

6.11.

Help on-line .................................................................................................. 71

6.12.

Segurana Fsica e Lgica ........................................................................... 71

6.12.1.

Norma de Segurana Fsica ..................................................................... 71

6.12.2.

Norma de Segurana Lgica .................................................................... 71

7. Plano de Implantao ......................................................................................... 73

8. Concluso ........................................................................................................... 74
9. Referencias Bibliogrficas .................................................................................. 75

13

1.

Introduo
Segundo MAGALHES e PINHEIRO (2007), a cada dia que passa, as

organizaes tornam-se mais dependentes da Tecnologia da Informao a fim de

satisfazer seus objetivos estratgicos e para atender s necessidades do negcio
em que atuam. Uma rea de TI (Tecnologia da Informao) que no considerar os
objetivos estratgicos da organizao em que se insere como os seus prprios
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 estratgia de negcio de seus clientes, condio
bsica para a venda de servios sob demanda.

Ainda segundo MAGALHES e PINHEIRO (2007), o Gerenciamento de

Servios de Tecnologia da Informao o instrumento pelo qual a rea pode iniciar
a adoo de uma postura pr-ativa em relao ao atendimento das necessidades da
organizao, contribuindo para evidenciar a sua participao na gerao de valor. O
Gerenciamento de Servio de TI visa alocar adequadamente os recursos disponveis
e gerenci-los de forma integrada, fazendo com que a qualidade do conjunto seja
percebida pelos seus clientes e usurios, evitando-se a ocorrncia de problemas na
entrega e na operao dos servios de Tecnologia da Informao.

Para MAGALHES e PINHEIRO (2007), organizaes consideradas lderes

em suas indstrias esto deixando de ser organizaes puramente focadas em
custo para se tornarem organizaes focadas em valor. Isto pode ser constatado
pela atual prtica da troca dos indicadores de desempenho derivados da estratgia
da organizao e que permitem a monitorao do desempenho na execuo de sua
estratgia, a partir de diversas perspectivas, alm da financeira, tradicionalmente
utilizada. Hoje, as organizaes j esto mais maduras e tomam decises que levam
em conta no apenas custo, mas a criticidade de cada processo da rea de TI para
a gerao de valor para a organizao. O Gerenciamento de Servio de TI , de
forma resumida, o gerenciamento da integrao entre pessoas, processos e
tecnologias, componentes de um servio de TI focados nas necessidades dos
clientes e de modo alinhado estratgia de negcio da organizao, visando o

14

alcance de objetivos de custos e desempenho pelo estabelecimento de acordos de

nvel de servio entre a rea de TI e as demais reas de negcio da organizao.

MAGALHES 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 terceirizao, baseia-se na experincia coletiva
de inmeros praticantes do Gerenciamento de Servios de TI de organizaes
privadas e pblicas de todo o mundo. Esta a razo pela qual vem se tornando um
padro na rea de Gerenciamento de Servios de TI, adotada por organizaeslderes em seus segmentos de atuao em escala mundial. A eficincia, a eficcia, a
efetividade e a economicidade no suporte aos servios de TI so fatores crticos
para o sucesso no alcance dos objetivos estratgicos traados pela organizao.

1.1. Tema

O Sistema de Service Desk (SISDESK) um sistema que atua como ponto

nico de contato entre o provedor de servios de TI e os clientes, onde so
cadastrados incidentes e solicitaes de mudanas, possibilitando assim, um melhor
gerenciamento dos servios de TI.

1.2. Justificativa

Conforme MAGALHES e PINHEIRO (2007), a Central de Servios uma

funo e no um processo, essencial para a implementao do Gerenciamento de
Servios de TI. Mais do que um ponto de suporte aos usurios, a Central de
Servios a principal interface entre a rea de TI e os usurios dos seus servios.
Ela responsvel pela primeira impresso que a rea de TI dar aos seus usurios
quando da necessidade de interao, quer seja para a solicitao de um servio ou
esclarecimento sobre o modo de interao com o servio de TI ou para comunicao
de um erro.

As normas internacionais relacionadas com a Gesto de Servios de TI

permitem a colaborao de organizaes 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
organizao demonstrar aos seus clientes e investidores que opera com integridade
negocial e segurana, e que promove uma cultura de melhoramento contnuo da
qualidade no mbito da Gesto de Servios de TI [1].

Com intuito de implementar a ISO 20.000 para um melhor gerenciamento de

seus servios de TI e fornecer um atendimento de qualidade s solicitaes dos
clientes, a empresa Dave Systems (Empresa Fictcia) necessita de uma ferramenta
de apoio gerencial de servios de TI que incremente velocidade ao atendimento e
melhore o suporte aos usurios de seus servios. Para esse fim, o sistema
SISDESK ser desenvolvido de forma a suprir estas necessidades.

Em um futuro prximo, a empresa Dave Systems (Empresa Fictcia) estuda

a possibilidade de aquisio da certificao ISO 20.000, e utilizar o SISDESK como
ferramenta de apoio para obteno e manuteno da certificao ISO 20.000.

1.3. Formulao do Problema

O controle dos incidentes gerados pelos sistemas desenvolvidos pela Dave

Systems (Empresa Fictcia) so cadastrados em um sistema desenvolvida pela
mesma chamada Help. No Help so cadastrados os chamados para correo ou
solicitao de mudana no sistema, permitindo o acompanhamento da demanda e a
visualizao na ntegra de todos os envolvidos no chamado. Porm, para o intuito da
empresa Dave Systems, que viabilizar a entrega e o suporte de servios focados
nas necessidades dos clientes, a empresa percebeu que sua ferramenta de controle
de incidentes, o Help, no atendia s suas exigncias. O Help no possui relatrios
para gerao de mtricas, o que dificulta as tomadas de decises para determinados
assuntos gerenciais. A base de dados possui dados inconsistentes, o que gera
conflitos de informaes para os usurios. Outra falha grave do sistema, que o
mesmo permite que tcnicos, que receberam um chamado para resoluo de um
incidente, tenham privilgios para encaminhar a demanda para outros tcnicos 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 tcnicos sem nenhuma soluo
implementada para o problema.

Com o atual sistema, algumas demandas com grau de dificuldade alta so

deixadas de lado para que outras demandas de nvel de dificuldade menor sejam
implementadas. Dessa forma, algumas solicitaes demoram mais do que o previsto
para serem executadas e, conseqentemente, atrasando a resoluo das
solicitaes e gerando insatisfao por parte do cliente.

1.4. Objetivos

Logo abaixo esto descritos os objetivos a serem alcanados pelo sistema

proposto, obtendo uma viso tanto de forma macro como de forma especfica de
seus objetivos.

1.4.1.

Geral

Desenvolver um sistema que facilite o controle das solicitaes para agilizar

o restabelecimento da operao normal dos servios dentro do SLA (Service Level
Agreement) definido com o cliente, minimizando o impacto nos negcios causados
por falhas de TI e o atendimento de possveis mudanas a serem realizadas nos
servios prestados pela empresa.

1.4.2.

Especficos

Fornecer um ponto nico com a rea de TI para os clientes dos servios de

TI; Prover um suporte tcnico para o atendimento das solicitaes cadastradas pelos
clientes da empresa; Ajudar a identificar e a reduzir o custo de propriedade dos
servios prestados; Gerar indicadores gerenciais para o auxilio de tomadas de
deciso;

17

1.5. Organizao do Trabalho

Abaixo est descrita a forma como o trabalho est organizado:

O captulo 1 descreve de uma forma geral o tema proposto e a justificativa

da escolha do tema e o problema que a ser resolvido.
O captulo 2 faz referncia instituio para a qual ser destinada a
implementao do sistema contendo o organograma da empresa, as necessidades
do sistema e o ambiente tecnolgico existente.
O captulo 3 descreve todo o cronograma das atividades realizadas no
desenvolvimento do projeto.
O captulo 4 descreve o referencial terico das tecnologias utilizadas no
desenvolvimento do projeto.
O captulo 5 faz referncia ao sistema proposto, resultados esperados,
restries do sistema e as reas afetadas pelo sistema.
O captulo 6 descreve a documentao de anlise do projeto, assim como a
viso macro dos atores, identificao dos atores, lista de casos de uso e diagrama
de caso de uso.
O captulo 7 descreve a forma como ser implantado o sistema.
O captulo 8 descreve a concluso do trabalho realizado.
O captulo 9 descreve todo o referencial terico utilizada no desenvolvimento
do trabalho realizado.

18

2.

Anlise Institucional
2.1. Empresa e seu Negcio

A empresa Dave Systems (Empresa Fictcia) foi fundada em 1982 com

intuito de atender com qualidade e eficincia uma rea carente dentro da
administrao pblica, porm fundamental para boa gesto do dinheiro pblico. No
decorrer desses anos tornou-se lder nacional no desenvolvimento e implantao de
solues de gesto de materiais e de patrimnio. A empresa, desde o princpio,
preocupou-se em trazer inovaes para o mercado de tecnologia da informao. A
soluo de gesto oferecida pela Dave Systems, inclui ainda todo o servio de
verificao e consistncia da base de dados, ou seja, o levantamento in loco (no
lugar) dos bens permanentes dos rgos, com metodologia e equipe especializada.

2.1.1.

Organograma da Empresa

Logo abaixo mostrado o organograma geral da Dave Systems (Empresa

Fictcia).

Figura 1 - Organograma da Empresa

19

2.2. Descries das Necessidades

A empresa carece de um controle sobre as solicitaes demandadas sua

fbrica de software fazendo com que os gerentes das equipes de desenvolvimento
percam muito tempo em anlises de chamados para levantamento de dados que os
d suporte gerao de indicadores e mtricas.

Atualmente o sistema que controla as atividades de desenvolvimento de

servios prestados pela empresa, no contempla de forma eficiente e eficaz as
necessidades da mesma, realizando apenas o cadastro de demandas, atribuio da
demanda ao colaborador que desenvolver o trabalho e finalizao do chamado
quando a demanda estiver implementada.

Para suprir as necessidades da empresa Dave Systems (Empresa Fictcia),

o Sistema de Service Desk (SISDESK) ser desenvolvido baseado nas melhores
prticas de gesto de servio da Information Technology Infrastructure Library (ITIL),
com a ateno voltada para a obteno da certificao ISO 20.000.

2.3. Sistemas de Informao Existente na Empresa

A empresa Dave Systems (Empresa Fictcia) desenvolveu o sistema ASI que

tem por finalidade propiciar realizao do inventrio dos bens mveis por meio de
um aparelho de leitura ptica de cdigo 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 exigncias a serem

considerados: o usurio dever possuir cadastro na intranet local; o usurio dever
possuir login no sistema; o usurio dever possuir nvel de acesso previamente
cadastrado; O dever passar por treinamento para que possa interagir de forma
correta com as diversas situaes do sistema.

20

2.5. Ambiente Tecnolgico Existente

Em sua estrutura, a Dave Systems (Empresa Fictcia) possui em torno de

180 computadores sendo 25 servidores, desde firewall mquina de backup e 30
servidores virtualizados. A rede mista com wireless, cabeamento estruturado e
ligao via fibra ptica. Os servidores de aplicao 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 domnio o OPENLDAP (OPENLDAP um software
livre de cdigo 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 disposio grfica do tempo que ser gasto na realizao

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 rpida
a visualizao de seu andamento [2].
Abaixo o cronograma do planejamento utilizado no desenvolvimento do
sistema.

Tabela 1 - Cronograma
ETAPAS
MAR/10
Definio
do
Problema
Delimitao do
Tema
Pesquisa
Bibliogrfica
Levantamento
Terico
Definio
da
metodologia
Planejamento
de aes
Levantamento
de Requisitos
Anlise
(def.
casos de uso)
Escrever
a
monografia
Projeto
Implementao
Implantao
Apresentao
da monografia
Acertos aps
apresentao
Entrega final

ABR/10

MAI/10

JUN/10

JUL/10

AGO/10

SET/10

OUT/10

NOV/10

DEZ/10

22

4.

Referencial Terico
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
Programao Java, foi utilizada para desenvolvimento do sistema. Em relao ao
gerenciamento de servio, 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 Programao

ANDRADRE (2007) define que o computador uma super calculadora,

capaz de realizar clculos muito mais rpido 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 nmeros em base binria, ou
seja, s entendem zero e um, tornando assim as linguagens de programao um
meio de comunicao inteligvel entre computadores e humanos.

Logo abaixo, teremos uma abordagem sobre algumas linguagens de

programao utilizadas no setor de informtica atualmente.

4.1.1.

Java

Segundo DEITEL H. e DEITEL P. (2005) os microprocessadores tm um

impacto profundo em dispositivos inteligentes eletrnicos voltados para o
consumidor. Reconhecendo isso, a Sun Microsystems, financiou um projeto de
pesquisa

corporativa

interna

com

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 conferncia em maio de 1995. Java uma
linguagem orientada a objeto, independente de plataforma e segura. A programao
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 concorrncia para o programador de aplicativos por meio de suas
APIs (Application Programming Interface). O programador especifica os aplicativos
que contm threads de execuo, 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 modificaes
em diferentes ambientes de computao. Os programas Java so 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 tambm, desenvolver programas para executar em

navegadores e servios da Web, desenvolver aplicativos no lado servidor, combinar
aplicativos ou servio para criar outros aplicativos altamente personalizados, entre
outras vantagens [3].

Para GONALVES (2007), trabalhar com banco de dados em aplicaes

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 programao com banco de dados. Por ser escrita em Java, a API
JDBC tambm independe de plataforma para a sua utilizao.

Ainda segundo GONALVES (2007), as bibliotecas da linguagem Java

contm vrias classes que implementam diversos mecanismos de entrada e sada,
acesso Internet, manipulao de strings em alto nvel, poderosas estruturas de

24

dados, utilitrios diversos e um conjunto completo de classes para implementao

de interfaces grficas. A documentao da linguagem, chamada Javadoc, est
disponvel gratuitamente e possui um padro de organizao estruturada como
documento HTML (Hipertext Markup Language). Os desenvolvedores de frameworks
e componentes costumam utilizar este padro de documentao para documentar
seus cdigos. Isto facilita em muito tanto o trabalho em equipe quanto a reutilizao
de cdigo de terceiros em outras implementaes. Alm disto, junto com o
compilador Java vem um aplicativo para gerao de JavaDoc do cdigo que voc
acabou de implementar.

Por ser uma linguagem que possui neutralidade, segurana, conexo com
os principais bancos de dados do mercado, documentao da linguagem e ser
multitarefa, Java foi escolhido como a linguagem de programao a ser utilizada no
desenvolvimento do SISDESK.

4.1.2.

PHP

Segundo CONVERSE e PARK (2001), PHP uma linguagem de criao de

scripts com cdigo-fonte aberto embutido em HTML do lado do servidor da Web,
compatvel 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 cdigos em pginas
normais de HTML cdigo que interpretado como suas pginas e fornecido a
usurios. 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 verso no UNIX e Windows. Tambm compatvel com os importantes
servidores da Web como o HTTP Apache para UNIX Windows, Microsoft Internet
Information Server e Netscape. O PHP no suportado na plataforma Macintosh.
Dessa forma, a linguagem de programao
linguagem multi-plataforma.

no pode ser considerada uma

25

A conectividade de banco de dados especialmente forte, com suporte de

unidade nativa para a maioria dos bancos de dados, alm do ODBC. Suporta
tambm, um nmero grande de protocolos importantes como POP3, IMAP, LDAP.

4.1.3.

Delphi

Segundo SWAN (1997), o Delphi uma linguagem de programao para

aplicativos rpidos, adequado para criao de prottipos do Windows e aplicativos
profissionais que competem em velocidade e eficincia. Delphi inclui poderosos
recursos orientados a objeto, sem tornar a linguagem muito complicada, permite a
criao de aplicaes para sistemas operacionais, como templates e experts de
aplicaes e formulrios, que aumentam muito a produtividade. Possuem classes e
objetos, tratamento de excees, programao multithread, programao modular e
vnculo dinmico e esttico.

Como dito anteriormente, Delphi uma linguagem de programao modular

e o mdulo bsico 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 trs variedades de diretivas de

compilador: chaves, parmetro e compilao condicional. Uma chave um flag
Booleano: Um recurso pode estar ativado ou desativado. Um parmetro oferece
informaes, como um nome de arquivo ou o tamanho da pilha. A compilao
condicional lhe permite definir condies e compilar seletivamente partes de um
arquivo-fonte dependendo das condies definidas. Um programa em Delphi
semelhante a um programa do Pascal tradicional, no entanto, os programas em
Delphi so 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 coleo

organizada de dados. Um sistema de gerenciamento de banco de dados fornece

26

mecanismos para armazenar, organizar, recuperar e modificar dados para muitos

usurios

4.2.1.

Oracle

Segundo ABBEY, COREY, ABRAMSON (2000), o Oracle um repositrio

para volumes de dados muito grande e fornece aos usurios um acesso rpido a
esses dados. Possui o particionador de dados que consiste em dividir grandes
volumes mais gerenciveis e reunidos de forma transparente quando os sistemas
funcionam e as sesses de usurio processam consultas. O Oracle fornece a
integridade de dados, ou seja, se, enquanto um usurio est alterando dados dentro
de um banco de dados, uma falha de qualquer espcie ocorrer, o banco de dados
tem a capacidade de desfazer ou retroceder qualquer operao suspeita. Os
sofisticados mecanismos de segurana controlam o acesso de dados sigilosos
atravs do uso de uma variedade de privilgios. Os usurios 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 lanou em novembro de 2005, a uma nova edio do

Oracle, o Oracle Express Edition 10g. Trata-se de uma verso gratuita que possui o
mesmo "ncleo" das demais verses, ou seja, uma aplicao que roda na verso do
Oracle Database Standard Edition Server release 2, sua aplicao tambm ir
funcionar com Oracle Express Edition 10g. Por ser compatvel com toda a famlia de
produtos do Oracle, ele permite aos usurios a facilidade de comear com uma
soluo bsica e ir mudando para outras verses quando necessrio. Permite ainda
que os desenvolvedores tirem total proveito do Oracle Application Express para
rpido desenvolvimento e implementao de aplicativos baseados na Web. [4]

4.2.2.

PostgreSQL

O PostgreSQL um poderoso sistema gerenciador de banco de dados

objeto-relacional de cdigo aberto. executado em todos os grandes sistemas
operacionais, incluindo Linux e Windows. totalmente compatvel com ACID, tem

27

suporte completo a chaves estrangeiras, junes, vises, 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 tambm o armazenamento de objetos binrios, incluindo
figuras, sons ou vdeos [5].

Como um banco de dados de nvel corporativo, o PostgreSQL; possui

funcionalidades sofisticadas como o controle de concorrncia multiversionado,
recuperao em um ponto no tempo, tablespaces, replicao assncrona,
transaes agrupadas, cpias de segurana, um sofisticado planejador de consultas
e registrador de transaes seqencial para tolerncia a falhas. Suporta conjuntos
de caracteres internacionais, codificao de caracteres multibyte, Unicode e sua
ordenao por localizao, sensibilidade a caixa (maisculas e minsculas) e
formatao. PostgreSQL altamente escalvel, tanto na quantidade enorme de
dados que pode gerenciar, quanto no nmero de usurios concorrentes que pode
acomodar. Existem sistemas ativos com o PostgreSQL em ambiente de produo
que gerenciam mais de 4TB de dados [5].

O cdigo fonte do PostgreSQL est disponvel sob a licena de fonte aberta

mais liberal: a licena BSD.

4.2.3.

MySQL

Segundo SANTOS (2005) MySQL um banco de dados relacional,

desenvolvido para plataformas Linuxlike, OS/2, Windows. Sendo um software de
livre distribuio para plataformas no-Windows que o utilizam em um servidor Web.

Ainda segundo SANTOS (2005) o MySQL um servidor multiusurio,

multitarefa, compatvel com o padro SQL, linguagem essa amplamente utilizada
para manipulao de dados em RDBMS (Banco de dados Relacionais), sendo
considerada um ferramenta de manipulao de base de dados de tamanho
moderado. A principais caractersticas que destacam MySQL so: sua velocidade

28

proporcionada pela sua implementao leve que no inclui na totalidade o suporte

as instrues SQL; sua natureza de distribuio gratuita; facilidade de integrao
com servidor Web e linguagens de programao de desenvolvimento de sites
dinmico.

4.3. RUP (Rational Unified Process)

Para KRUCHTEN (2003), o Rational Unified Process (tambm 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 organizao de desenvolvimento. Sua meta garantir a produo de
software de alta qualidade que atenda s necessidades dos usurios dentro de um
cronograma e de um oramento previsveis. Amadureceu durante os anos, e reflete
a experincia coletiva das muitas pessoas e companhias que hoje compes a rica
herana da Rational Software. O RUP incorpora mais material nas reas de
engenharia de dados, modelagem de negcio, gerenciamento de projeto e
gerenciamento de configurao, o ltimo como resultado de uma fuso com PureAtria.

KRUCHTEN (2003) ainda afirma que o RUP fornece uma abordagem

disciplinada para assumir tarefas e responsabilidades dentro de uma organizao de
desenvolvimento. Seu objetivo assegurar a produo de software de alta qualidade
que satisfaa as necessidades de seus usurios finais dentro de prazo e oramento
previsveis. Pode ser adaptada e estendida para compor as necessidades de uma
organizao que o esteja adotando.

4.3.1.

Desenvolvimento Iterativo

Um projeto que usa o desenvolvimento iterativo tem um ciclo de vida que

consiste em vrias iteraes. Uma iterao incorpora um conjunto quase seqencial
de atividades em modelagem de negcios, requisitos, anlise e design,
implementao, teste e implantao, em vrias propores, dependendo do local em
que ela est localizada no ciclo de desenvolvimento. As iteraes nas fases de

29

iniciao e de elaborao se concentram nas atividades de gerenciamento,

requisitos e design. As iteraes na fase de construo se concentram no design, na
implementao e no teste. E as iteraes na fase de transio e concentram no teste
e na implantao. O gerenciamento das iteraes deve ser do tipo timebox, isto , a
programao de uma iterao deve ser considerada fixa e o escopo do contedo da
iterao gerenciado ativamente para atender a essa programao [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 seqenciais, cada uma concluda por um marco principal,
ou seja, cada fase basicamente um intervalo de tempo entre dois marcos
principais.

Logo abaixo, exibido o grfico de baleias, onde mostrado verticalmente

as disciplinas do desenvolvimento de software. Nas colunas, so mostradas as fases
e o esforo em cada uma delas.

Figura 2 - Grfico de Baleia

30

4.3.2.1.

Concepo

Para KRUCHTEN (2003) na fase de concepo, o foco est em entender os

requisitos globais e determinar a extenso do esforo de desenvolvimento. Para
projetos que visam melhorias em um sistema existente, a fase de iniciao mais
rpida, mas ainda se concentra em assegurar que o projeto seja compensatrio e
que seja possvel faz-lo.

Dentre as atividades da fase de concepo, devemos formular a extenso

do projeto, que quer dizer, captar o contexto e os requisitos mais importantes e
restries de forma que possa derivar critrios de aceitao para o produto final.
Outra atividade planejar e preparar um caso de uso de negcio e avaliar
alternativas para gerenciamento de risco, fornecendo pessoal, plano de projeto e
intercmbio entre custo, prazo e rentabilidade. E por fim, KRUCHTEN (2003) explica
que se deve sintetizar uma arquitetura candidata, avaliar intercmbios em projeto e
avaliar decises de fazer/comprar/reutilizar, de forma que custo, prazo e recursos
possam ser calculados.

4.3.2.2.

Elaborao

A meta da fase de elaborao 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 estvel para o esforo da fase de construo.
Na fase de elaborao, um prottipo executvel de arquitetura construdo em uma
ou mais iteraes dependendo da extenso, tamanho, risco e novidade do projeto
programao [6].

Na fase de elaborao, um prottipo executvel de arquitetura construdo

em uma ou mais iteraes, dependendo da extenso, tamanho risco e novidade do
projeto. No mnimo, este esforo deveria enderear os casos de uso crticos
identificados na fase de concepo, que tipicamente expe os riscos tcnicos
principais do projeto.

31

Embora um prottipo evolutivo de um componente de qualidade de produo

sempre seja a meta, isto no exclui o desenvolvimento de um ou mais prottipos de
propaganda para mitigar um determinado risco ou explorar alguns intercmbios entre
projeto e requisitos. Nem regra um estudo de viabilidade ou demonstraes a
investidores, clientes e usurios finais.

Conforme KRUCHTEN (2003) os objetivos primrios da fase de elaborao

so: definir, validar e delinear a arquitetura to rpida quanto possvel de ser
realizada; delinear a viso; delinear um plano de alta-fidelidade para a fase de
construo; demonstrar que a arquitetura de linha de base suportar esta viso, a
um custo razovel num tempo razovel.

4.3.2.3.

Construo

KRUCHTEN (2003) explica que durante a fase de construo, todos os

componentes restantes e caractersticas da aplicao so desenvolvidos e
integrados ao produto, e todas as caractersticas so completamente testadas. A
fase de construo , de certo modo, um processo industrial no qual colocada
nfase em gerenciar recursos e controlar operaes para aperfeioar custos, prazos
e qualidade. Muitos projetos so grandes o suficiente para que sejam gerados
incrementos de construo paralelos. Estas atividades paralelas podem apressar
significativamente a disponibilidade de lanamentos de desenvolvimentos; eles
tambm podem aumentar a complexidade de gerenciamento de recurso e
sincronizao de fluxo. Os objetivos primrios da fase de construo incluem:
minimizar custos de desenvolvimento e aperfeioando recursos; Alcanar a
qualidade adequada to rpida quanto possvel de ser realizada.

4.3.2.4.

Transio

O foco da Fase de Transio assegurar que o software esteja disponvel

para seus usurios finais. A Fase de Transio pode atravessar vrias iteraes e

32

inclui testar o produto em preparao para release e ajustes pequenos com base no
feedback do usurio. Nesse momento do ciclo de vida, o feedback do usurio deve
priorizar o ajuste fino do produto, a configurao, a instalao 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
Transio, os objetivos devem ter sido atendidos e o projeto deve estar em uma
posio para fechamento. Em alguns casos, o fim do ciclo de vida atual pode
coincidir com o incio de outro ciclo de vida no mesmo produto, conduzindo nova
gerao ou verso do produto. Para outros projetos, o fim da Transio pode
coincidir com uma liberao total dos artefatos a terceiros que podero ser
responsveis pela operao, manuteno e melhorias no sistema liberado [6].

Essa Fase de Transio pode ser muito fcil 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 substituio do sistema de controle do
trfego areo de um pas pode ser excessivamente complexa.

4.4. UML (Unified Model Language)

Conforme BOOCH, RUMBAUGH e JACOBSON (2005) os esforos para

criao da UML se iniciaram oficialmente em outubro de 1994, quando Rumbaugh
se juntou a Booch na Rational. O foco inicial do projeto era a unificao dos mtodos
Booch e OMT(Object Modeling Technique). O esboo da verso 0.8 do Mtodo
Unificado (como ento era chamado) foi lanado em lanado 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 vrios anos, a manuteno da UML foi assumida pela RTF
(Revision Task Force) do OMG (Object Management Group), que produziu as
verses 1.3, 1.4 e 1.5. De 2000 a 2003, um novo e maior grupo de parceiros
produziu e atualizou a especificao da UML, verso 2.0. A verso foi revista por um
FTF (Finalization Task Force) coordenada por Bran Selic, da empresa IBM, e a
verso oficial da UML 2.0 foi adotada pelo OMG no incio de 2005.

33

BOOCH, RUMBAUGH e JACOBSON (2005) explicam que a UML uma

linguagem-padro para a elaborao da estrutura de projetos de software. Ela
poder ser empregada para a visualizao, a especificao, a construo e a
documentao de artefatos que faam uso de sistemas complexos de software. A
UML adequada para a modelagem de sistemas, cuja abrangncia poder incluir
sistemas de informao coorporativos a serem distribudos a aplicaes em Web e
at sistemas complexos embutidos de tempo real. Segundo Furlan (1998), a UML
a linguagem padro 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 atravs de diferentes tecnologias de implementao.

4.4.1.

Orientao a Objetos

Segundo MATOS (2003), a proposta da orientao objetos permitir que

os programadores organizem os programas da mesma forma que nossas mentes
enxergam os problemas: no como um conjunto de espaos de memria, mas como
um conjunto de coisas que fazem parte do problema. O interessante neste ponto de
vista que o programador no ser mais obrigado a abstrair do problema variveis e
suas respectivas organizaes, mas imaginar o problema como um grande conjunto
de objetos. Dessa forma necessrio haver uma modificao na maneira como
enxergamos os programas. No permitido neste paradigma, orientar a soluo dos
problemas de acordo com as funes identificadas no problema, mas de acordo com
o que existe no escopo do problema: objetos.

FURLAN (1998), afirma que um objeto uma ocorrncia especfica

(instncia) de uma classe e similar a uma entidade no modelo relacional somente
at o ponto onde representa uma coleo 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 dependncia externa e
alta coeso interna de seus componentes, o que permite promover substituies
sem afetar interconexes ou interferir com a operao dos demais objetos.

34

4.4.1.1.

Objetos

Segundo FURLAN (1998) do ponto de vista de abstrao, os objetos tentam

no separar o que at ento vinha sendo separado: dados e funes. Um objeto
uma entidade concreta, apesar de ser uma concepo abstrata. Trata-se de um
agrupamento de caractersticas e aes desta entidade. Essas caractersticas so
agrupadas de forma que possamos identificar outros objetos parecidos. Por outro
lado, suas aes ajudam tambm a classificar outras entidades como objetos
semelhantes a ele.

PENDER (2004) define objeto como a representao de uma entidade

especfica no mundo real. Diz tambm que, pode ser uma entidade fsica ou
intangvel, com os propsitos de promover o entendimento do mundo real e suportar
uma base prtica para uma implementao computacional.

4.4.1.2.

Classes

Segundo PAGE-JONES (2000), uma classe uma estrutura a partir do qual

so criados objetos. Cada objeto tem a mesma estrutura e comportamento da classe
na qual ele teve origem.

SANTOS (2003) define que classes so estruturas orientadas a objeto para

conter, para um determinado modelo, os dados que devem ser representados e as
operaes que devem ser efetuadas com estes dados. Classes so escritas com os
recursos e regras para implementao dos modelos, mas em muitos casos as
classes so somente moldes ou formas que representam os modelos abstratamente.
Um objeto ou uma instncia uma materializao da classe, e assim pode ser
usado para representar e executar operaes. Para que dados ou instncias
possam ser manipulados, necessria a criao de referncias a estes objetos, que
so basicamente variveis do tipo de classe.
Conforme SANTOS (2003), os dados contidos em uma classe so
conhecidos como campos ou atributos daquela classe. Cada campo deve ter um

35

nome e ser de um tipo. Valores contidos dentro de uma classe so chamados de

variveis, sendo que campos representam dados encapsulados em uma classe, e
variveis representam valores auxiliares necessrios ao funcionamento dos mtodos
na classe. As operaes contidas em uma classe so chamadas de mtodos dessa
classe. Mtodos so geralmente chamados ou executados explicitamente a partir de
outros trechos de cdigo na classe que o contm ou a partir de outras classes.

4.4.1.3.

Herana

Segundo Furlan (1998), herana o mecanismo de reutilizao de atributos

e operaes definidos em classes gerais por classes mais especficas, podendo ser
usada para expressar tanto generalizao como associao. Pode-se organizar tipos
similares de classes de objetos em categorias hierrquicas, onde permitida
classe de menor nvel, que uma especializao ou extenso de outra classe,
compartilhar atributos e operaes de classes superiores na hierarquia.

SANTOS (2003) diz que o mecanismo de reaproveitamento por herana

permite a reutilizao de classes j existentes com instncias de novas classes. As
classes originais ficam assim contidas nas classes novas.

a partir da herana que surge o conceito de classes abstratas, as quais

so idealizadas para serem moldes de eventuais subclasses, as quais iro adicionar
sua estrutura e comportamento, geralmente sobrepondo operaes. Permite
especificar atributos e operaes comuns a vrias 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 originrio do grego e

significa "muitas formas" (poli = muitas, morphos = formas). A palavra polimorfismo
origina-se de duas palavras gregas que significam respectivamente, muitas e forma.
Algo que polifrmico, portanto, apresenta a propriedade de assumir muitas formas.

36

PAGE-JONES (2000) explica ainda que polimorfismo a habilidade pela qual uma
nica operao ou nome de atributo pode ser definido em mais de uma classe e
assumir implementaes diferentes em cada uma dessas classes.

Para

PENDER

(2004),

polimorfismo

capacidade

de escolher

dinamicamente o mtodo para uma operao durante a execuo, dependendo do

tipo de objeto que responde solicitao. Pender complementa dizendo que
polimorfismo significa muitas maneiras de realizar a mesma coisa.

Para SANTOS (2003), o mecanismo de herana permite a criao de

classes a partir de outras j existentes com relaes -um-tipo-de, de forma que, a
partir de uma classe genrica, classes mais especializadas possam ser criadas.
Polimorfismo permite a manipulao de instncias de classes que herdam de uma
mesma classe ancestral de forma unificada.

4.4.1.5.

Coeso

Segundo PENDER (2004), coeso uma medida de como as partes de um

objeto do suporte mesma finalidade. A coeso mede dois fatores: como a
finalidade do objeto bem definida e se cada parte do objeto contribui diretamente
para cumprir sua finalidade. Alta coeso significa que um objeto possui uma
finalidade bem definida e tudo no objeto contribui diretamente para essa finalidade.
Baixa coeso significa ou que a finalidade do objeto ambgua 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, possvel construir modelos a

partir de blocos de construo bsicos, como classes, interfaces, componentes, ns,
dependncias,

generalizaes

associaes.

Diagramas

so

meios

para

visualizao desses blocos de construo. Um diagrama uma apresentao

grfica de um conjunto de elementos, geralmente representados como um grfico
conectado de vrtices (itens) e arcos (relacionamentos).

37

De acordo com Furlan, modelar um sistema complexo uma tarefa

extensiva sendo necessria a descrio de vrios aspectos diferentes incluindo o
funcional, no funcional e organizacional. Cada viso descrita em um nmero de
diagramas que contm informao 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

colaboraes

seus

relacionamentos. So os diagramas mais encontrados em sistemas de modelagem

orientados a objetos. Esses diagramas so utilizados para ilustrar a viso esttica 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 contedo grfico que so uma projeo em um modelo.

4.4.2.2.

Diagramas de Colaborao

Conforme PAGE-JONES (2000), no diagrama de colaborao da UML, os

objetos que interagem por meio de mensagens aparecem como caixas padres 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 no tm realmente os seus prprios nomes. Em
outras palavras, um objeto destinatrio adota o nome da varivel no objeto
remetente que detm o identificador do objeto destinatrio.

4.4.2.3.

Diagramas de Objetos

Segundo GUEDES 2007, um diagrama de objetos mostra um conjunto de

objetos e seus relacionamentos. Esses diagramas so utilizados para ilustrar as
estruturas de dados, registros estticos de instncias dos itens encontrados nos
diagramas de classes. Os diagramas de objetos fazem a modelagem de instncias

38

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 colaborao descendente direto do
diagrama de objeto, do grfico de interao de objeto e vrias outras fontes. Uma
colaborao uma viso de um conjunto de elementos de modelagem relacionados
para um propsito particular em apoio a interaes. Assim, um diagrama de
colaborao mostra ma interao organizada em torno de objetos e seus vnculos
formando uma base de padres.

4.4.2.4.

Diagramas de Componentes

Segundo FURLAN (1998) um diagrama de componente um grfico de

componentes conectados por relacionamentos de dependncia de onde tambm
podem ser associados componentes a outros por reteno fsica que representa
relacionamentos de composio. Exibe as organizaes e dependncias entre
componentes com o propsito de modelar a viso de implementao dos mdulos
de software executveis com identidade e interface bem-definida de um sistema e
seus relacionamentos. Para cada elemento lgico no modelo, geralmente existe um
padro que mapeia um artefato de implementao.

Furlan ainda afirma que um componente representa uma unidade de cdigo

de software (fonte, binrio ou executvel) e pode ser usado para expor o compilador
e dependncias de run-time, incluindo sua localizao em ns. desenhado como
um retngulo maior e derivado do mtodo de Booch para representar um mdulo.

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 anlise dos requisitos, em que so
determinadas as necessidades do usurio, e na compreenso do sistema como um
todo, embora venha a ser consultado durante todo o processo de modelagem e sirva
de base para todos os outros diagramas (GUEDES, 2007).

39

Conforme BOOCH, RUMBAUGH e JACOBSON (2005) os diagramas de

caso de uso so importantes para visualizar, especificar e documentar o
comportamento de um elemento. Esses diagramas fazem com que sistemas,
subsistemas e classes fiquem acessveis e compreensveis, por apresentarem uma
viso 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 acessveis e
compreensveis, por apresentarem uma viso externa sobre como esses elementos
podem ser utilizados no contexto.

4.4.2.6.

Diagramas de Seqncia

Diagrama de seqncia um diagrama de interao que d nfase

ordenao temporal de mensagens. Um diagrama de seqncia mostra um conjunto
de papis e as mensagens enviadas e recebidas pelas instncias que representam
os papis. O Diagrama de Seqncia preocupa-se com a ordem temporal em que as
mensagens so 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
apia-se no Diagrama de Classes para determinar os objetos das classes envolvidas
em um processo, bem como os mtodos 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 seqencial ou ramificado de uma atividade para outra e os objetos
que realizam ou sofrem aes. Os diagramas de atividades so utilizados para fazer
a modelagem da funo de um sistema e do nfase ao fluxo de controle na
execuo de um comportamento com o propsito de estudar os fluxos dirigidos por

40

processamento interno, descrevendo as atividades desempenhadas em uma

operao.
4.4.2.8.

Diagramas de Interao

BOOCH, RUMBAUGH e JACOBSON (2005) afirmam que os diagramas de

interao so utilizados para fazer a modelagem dos aspectos dinmicos do
sistema. Na maior parte, isso envolve a modelagem de instncias concretas ou
prototpicas de classes, interfaces, componentes e ns, juntamente com as
mensagens que so trocadas entre eles, tudo isso no contexto de aparecer sozinhos
para visualizar, especificar, construir e documentar a dinmica 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 interao mostra uma interao formada por um conjunto

de objetos e seus relacionamentos, incluindo as mensagens que podero ser
trocadas entre eles.

4.4.2.9.

Diagramas de Implantao

Segundo FURLAN (1998), a UML fornece o diagrama de implantao para

mostrar a organizao do hardware e a ligao do software aos dispositivos fsicos.
Um diagrama de implantao denota vrios dispositivos de hardware e interfaces
fsicas determinados por seu esteretipo, como processador, impressora, memria,
disco e assim por diante.

FURLAN (1998) ainda afirma que a UML fornece notaes avanadas e

semnticas quando uma modelagem mais complexa requerida, ainda que algumas
dessas notaes sejam destinadas a cobrir casos particulares e outras a estender a
UML de um modo controlado para apoiar modelagem do sistema global. Diagrama
de implantao expe a configurao de elementos de run-time e componentes de
software, processos e objetos que neles se mantm. Trata-se de um grfico de ns

41

conectados por associaes de comunicao. Os ns podem conter instncias de

componentes que, por sua vez, podem conter classes, bibliotecas ou executveis.

4.4.2.10.

Diagramas de Grfico de Estados

Segundo BOOCH, RUMBAUGH e JACOBSON (2005) um diagrama de

grfico de estados mostra mquina de estados, dando nfase ao fluxo de controle
de um estado para outro. Uma mquina de estados um comportamento que
especifica as seqncias 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 condio ou situao na vida de um objeto durante a
qual ele satisfaz a alguma condio, realiza alguma atividade ou aguarda algum
evento. Um evento uma especificao de uma ocorrncia de um estmulo capaz de
ativar uma transio de estado.

BOOCH, RUMBAUGH e JACOBSON (2005) explicam ainda que uma

transio um relacionamento entre dois estados, indicando que um objeto no
primeiro estado realizar certas aes e entrar no segundo estado quando um
evento especificado ocorrer e as condies especificadas esto satisfeitas. Uma
atividade uma execuo no-atmica em andamento em uma mquina de
estados. Uma ao uma computao atmica executvel que resulta em uma
alterao do estado do modelo ou no retorno de um valor.

4.5. Information Technology Infrastructure Library - ITIL

Segundo MAGALHES e PINHEIRO (2007) a ITIL composta por um

conjunto das melhores prticas para a definio dos processos necessrios ao
funcionamento de uma rea de TI. Descreve a base para a organizao dos
processos da rea de TI, visando sua orientao para o Gerenciamento de
Servios de TI. As diversas prticas reunidas descrevem os objetivos, atividades
gerais, pr-requisitos necessrios e resultados esperados dos vrios processos, os
quais podem ser incorporados dentro das reas de TI.

42

Para FRY (2003) importante entender que os processos do ITIL no iro

tornar uma infra-estrutura pobre de TI em uma infra-estrutura rica de TI da noite
para o dia. Seus benefcios podem ser significantes, porm adaptar-se s melhores
prticas e processos no to fcil. Isto leva tempo, planejamento e principalmente
comprometimento.

Conforme MAGALHAES e PINHEIRO (2007) a ITIL no define os processos

a serem implantados na rea de TI, no uma metodologia para implementar
processos de Gesto de Servios de TI um framework flexvel que permite
adaptar-se para ir ao encontro das necessidades especficas, demonstra as
melhores prticas que podem ser utilizadas para esta definio. Tais prticas, por
sua vez, podem ser adotadas do modo que melhor puder atender s necessidades
de cada organizao.

A seguir, sero descritos os processos da ITIL que sero utilizados nesse

trabalho.

4.5.1.

Central de Servios (Service Desk)

MAGALHES e PINHEIRO (2007) afirmam que a Central de Servios,

tambm conhecida como Service Desk, uma funo e no um processo, essencial
para a implementao do Gerenciamento dos Servios de TI. A Central de Servios
atua como Ponto nico de Contato entre os usurios e os clientes dos servios de TI
e os diversos processos relacionados com o Gerenciamento dos Servios de TI.
Suas principais atividades so: o atendimento s chamadas, no importando o meio
de comunicao utilizado pelos usurios e clientes dos servios de TI, e aos eventos
recebidos da equipe de superviso da infra-estrutura de TI, visando a sua correta
classificao, alm do encaminhamento para o processo de gerenciamento
adequado.

Destaca-se, ainda, como objetivo, garantir o encerramento do maior nmero

de incidentes e consultas dentro do seu nvel 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

MAGALHES e PINHEIRO (2007) dizem que um incidente qualquer

evento que no faz parte do funcionamento-padro de um servio de TI e que
causa, ou pode causar uma interrupo do servio ou uma reduo do seu nvel de
desempenho. Na maioria das vezes, um incidente reportado refere-se interrupo
do servio de TI.

Ainda segundo MAGALHES e PINHEIRO (2007), o processo de

gerenciamento de incidente tem por objetivo assegurar que, depois da ocorrncia de
um incidente, o servio de TI afetado tenha restaurada a sua condio original de
funcionamento o mais breve possvel, minimizando os impactos decorrentes do
efeito sobre o nvel de servio ou, at mesmo, da indisponibilidade total. A central de
servios a rea responsvel pelo atendimento dos usurios 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 MAGALHES e PINHEIRO (2007), incidentes que se repetem

indefinidamente e para os quais no se fornece nenhuma soluo definitiva, faz com
que os clientes da rea de TI percam a confiana na capacidade da equipe de
suporte aos servios de TI, deteriorando a imagem desta rea perante a
organizao. Tal fato, tambm atinge o moral dos integrantes da equipe de suporte
aos servios de TI que se vem reiteradamente tendo que resolver os mesmos
incidentes, onerando a sua capacidade de resolver novos acidentes e aumentar sua
contribuio para a organizao. 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 tm sobre o negcio. O principal objetivo do processo de

Gerenciamento de Problema minimizar o impacto adverso no negcio dos
incidentes e problemas decorrentes de erros conhecidos relacionados com a infraestrutura de TI, prevenindo a repetio de incidentes relacionados com estes erros
conhecidos.

4.5.4.

Gerenciamento de Nvel de Servio

Segundo MAGALHES e PINHEIRO (2007), o gerenciamento de nvel de

servio a metodologia disciplinada e os procedimentos proativos utilizados para
garantir que nveis adequados de servios sero entregues para todos os usurios
de TI de acordo com as prioridades do negcio e a um custo aceitvel, acordado
com o cliente. A misso da equipe de gerenciamento de nvel de servio manter e
gradualmente melhorar a qualidade dos servios de TI, executando um ciclo
constante de acordar, monitorar, informar os xitos dos servios de TI e incitar aes
para erradicar um servio de TI de baixo desempenho na relao custo/benefcio ou
que no tenha mais importncia para negcio, promovendo uma melhor relao
entre a rea de TI e a organizao.

4.6. ISO/IEC 20.000

MAGALHES e PINHEIRO (2007) afirmam que a ISO (International

Organization for Standardization) e IEC (International Electrotechnical Commission)
fazem parte do sistema especializado para padronizao mundial. Entidades
nacionais que so membros da ISO ou IEC participam do desenvolvimento de
Padres Internacionais atravs de comits tcnicos estabelecidos pela respectiva
organizao para lidar com campos especficos de atividade tcnica. A norma
ISO/IEC 20.000 foi desenvolvida para responder s necessidades de uma audincia
global e fornecer um entendimento comum do Gerenciamento de Servios de TI em
todo o mundo. Esta norma est baseada na BS 15.000, que uma norma britnica e
foi o primeiro padro mundial orientado especificamente para o Gerenciamento de
Servios de TI. A ISO/IEC 20.000 est dividida em duas partes: a ISO/IEC 20.0001:2005 e a ISO/IEC 20.000-2:2005.

45

Segundo MAGALHES e PINHEIRO (2007), dois dos maiores desafios

enfrentados pelas reas de TI em relao ao gerenciamento dos servios de TI so:
conseguir a ateno e o compromisso por parte da alta direo da organizao e
garantir a aceitao e a adoo de um processo de Gerenciamento de Mudana por
toda a organizao. Estas resistncias so consideravelmente reduzidas nas
organizaes registradas como certificadas ISO e que pretendem utilizar a norma
ISO/IEC 20.000 como um passo frente para obterem uma certificao especfica
no Gerenciamento de Servios de TI. Neste tipo de cenrio, a existncia de um ciclo
de melhoria contnua envolve todos os stakeholders da organizao. Ao mesmo
tempo, melhora a transparncia, contribuindo para o aprimoramento do sistema de
gerenciamento da qualidade das operaes da organizao.

Ainda segundo MAGALHES e PINHEIRO (2007), a ISO/IEC 20.000-1:2005

um documento de 16 pginas, publicado pela ISO, contm as especificaes para
o Gerenciamento de Servios de TI. Fornece os requisitos do gerenciamento de
servios de TI na organizao. Os ndices da ISO/IEC 20.000-1:2005 so: Escopo;
Termos e Definies; Requisitos para um Sistema de Gerenciamento; Planejamento
e Implementao do Gerenciamento de Servio; Planejamento e Implementao de
Servios Novos ou Alterados; Processos de Entrega de Servios; Processos de
Relacionamento; Processos de Resoluo; Processos de Controle; Processo de
Gerenciamento de Liberao. A ISO/IEC 20.000-2:2005 um documento de 34
pginas que apresenta o cdigo de prtica para o Gerenciamento de Servios de TI.
Fornece orientao para os auditores internos e assistncias aos prestadores de
servios que planejam melhorias no servio ou que querem preparar-se para
auditorias em relao norma ISO/IEC 20.000-1:2005. Os ndices da ISO/IEC
20.000-2:2005 so: Escopo; Termos e Definies; O sistema de gerenciamento;
Planejamento e Implementao do gerenciamento de Servios; Processos de
Entrega de Servios; Processos de Relacionamento; Processos de Resoluo;
Processos de Controle; Processos de Gerenciamento de Liberao.

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 usurios na
interao com os servios de TI. Prover uma interface para outras atividades
relacionadas com as demais necessidades dos usurios do sistema como
requisies de mudana, contratos de manuteno e solicitaes de servios.

Minimizar o impacto adverso no negcio dos incidentes e problemas

decorrentes de erros conhecidos relacionados com os servios prestados pela
equipe de TI.

5.1. Descrio do Sistema Proposto

Desenvolver um sistema voltado para o gerenciamento de servios de TI

prestado pela empresa Dave Systems (Empresa Fictcia) tendo o gerenciamento de
incidentes como o principal foco, de forma que torne a central de servios rea
responsvel pelo atendimento dos usurios e registro dos incidentes, passando a
zelar durante todo o ciclo de vida do incidente.

O sistema permitir o cadastro de solicitaes atravs de um canal de

comunicao. A comunicao poder ser via e-mail, telefone ou qualquer outro meio
definido entre o provedor do servio e o cliente. O analista de suporte far o
cadastro das demandas e/ou verificao para soluo de um incidente. O analista
de incidente ter o controle das demandas enquanto a mesma estiver sendo
implementada e ser responsvel pelo feedback ao Analista de Suporte.

De posse de todo o servio catalogado no sistema, os diretores facilmente

geram indicadores para tomada de deciso e/ou mtricas para acompanhamento da
estratgia do negcio.

47

5.2. Resultados Esperados

Com a utilizao do SISDESK, espera-se que haja um maior controle sobre

os incidentes e solicitaes de mudanas cadastradas pelos clientes gerando,
assim, um incremento da velocidade de atendimento e a melhoria do ndice de
satisfao dos clientes dos servios de TI. Espera-se tambm, a melhora no
gerenciamento da informao para tomada de deciso relativa aos servios
prestados aos clientes de TI.

5.3. Restries do Sistema Proposto

A priori, o sistema ter o seu funcionamento apenas para a intranet da Dave

Systems. O sistema obriga ao usurio possuir login e senha e um tipo de perfil
associado a sua conta para que seja definido o nvel de acesso ao sistema proposto.

Sero utilizados dados fictcios para alimentao da base de dados do

projeto, dessa forma, os dados reais da Dave Systems (Empresa Fictcia) sero
preservados.

Neste momento as matrias da ITIL que sero utilizadas para o

desenvolvimento do sistema so: gerenciamento de incidente, gerenciamento de
problema, gerenciamento de mudana e gerenciamento de nvel de servio.

5.4. Resultados Esperados

A relao custo x benefcio de um sistema questionada por vrios fatores.

Reduo com ligaes telefnicas e identificao de erros visando diminuio do
tempo da soluo de um problema resulta em atenuar custos trazendo benefcios
lucrativos a empresa.

O sistema oferece vrios benefcios como solues mais rpidas, ambiente

nico acessado por todos para cadastrar problemas e consultar solues, assim
como identificar atravs de estatsticas as reas mais problemticas onde

48

necessitam de acompanhamento especfico, sendo assim, diminuindo custos atravs

de tempo de produo.

Relatrios so emitidos periodicamente indicando a relao de problemas e

solues para medir problemas e identificar erros relacionados em cada rea para
direcionar decises.

5.5. reas Afetadas Pelo Novo Sistema

Na empresa Dave Systems (Empresa Fictcia) as reas que inicialmente

sero afetadas pelo novo sistema sero a gerncia de suporte, gerncia de projetos,
coordenao de anlise, coordenao 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 princpio, o banco de dados Oracle Express
10 g ser utilizado para implementao do sistema evitando dessa forma, conflitos
no momento da implantao do software.

49

6.

Documentao de Anlise
Logo abaixo esto descritos os atores do sistema, identificando suas

funes 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 especificaes detalhadas. Neste tpico tambm demonstrado
modelo de entidade e relacionamento, o diagrama de classes e a especificao das
tabelas do banco de dados.

6.1. Viso Macro dos Atores

O SISDESK possuir os seguintes atores em seu sistema: Analista de

Suporte, Analista de Incidente, Tcnico e Administrador.

6.2. Identificao dos Atores

O ator Analista de Suporte responsvel por criar um registro de incidente

com as informaes disponveis 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 responsvel por fornecer rapidamente uma

boa anlise de um incidente e/ou uma soluo para ela, a fim de restabelecer o
servio perturbado o mais rpido possvel. Esse papel ser desenvolvido pelo
Analista de Sistema.

O Ator Gerente de Incidentes responsvel pela qualidade e a integridade

do processo de gerenciamento de incidente. Esta pessoa a interface com outros
gerentes de processos.

O ator Tcnico responsvel pela implementao de uma soluo tanto

para um servio interrompido quanto para uma solicitao de mudana. Esse papel

50

poder ser realizado por Desenvolvedores, Administradores de Dados, Analista de

Banco de Dados ou Web Designers.

O ator Administrador responsvel pelo cadastro e excluso de usurios no

sistema. Tem acesso a todos os mdulos do sistema. Esta pessoa define, no perfil
de cada usurio, os mdulos e as funcionalidades permitidas ao perfil agregado ao
usurio 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

Cdigo

Casos de Uso

UC01

Efetuar Login

UC02

Manter Usurio

UC03

Manter Incidente

UC04

Manter Mudana

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

Efetuar Login

Manter Incidente

Admin
Usuario

Manter Problema

Manter Mudana

Manter Usurio

Figura 3 - Diagrama de Casos de Usos

52

6.5. Descrio Detalhada dos Casos de Uso

Abaixo mostrada a especificao 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;
Usurios Cadastrados.

Dados Consumidos

Login e senha.

Dados Produzidos

Acesso ao sistema.

Prioridade

Alta.

Pr-condies

Possuir cadastro no sistema.

Ps-condies

N/A
Fluxo Principal

Efetuar login.
Ator

Sistema

Informar login e senha.

Valida as informaes do usurio e senha.

Se os dados estiverem OK, o sistema carrega a
pgina inicial. Se os dados estiverem incorretos, a
aplicao 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 Usurio

Tabela 4 UC2 Manter Usurio

Nome

UC03- Manter Usurio

Objetivo

Cadastrar usurio no sistema.

Atores

Administrador;
Usurios Cadastrados.

Dados Consumidos

Nome, funo, email e tcnico.

Dados Produzidos

Usurios Cadastrados.

Prioridade

Alta.

Pr-condies

Possuir cadastro no sistema;

Estar logado no sistema.

Ps-condies

N/A
Fluxo Principal Cadastrar Usurio
Ator

Sistema

Acessar a pgina de cadastro de usurio.

O sistema carrega a pagina para cadastrar um

novo usurio.

Preencher as informaes relativas ao cadastro de O sistema valida as informaes da tela. Se os

usurio e clica no boto gravar.
dados estiverem OK, armazen-los na tabela
SD_TECNICO e enviar mensagem de operao
realizada com sucesso. Se os dados no 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 Usurio
Ator

Sistema

Acessar a pgina de consulta de usurio.

O sistema lista todos os usurios cadastrados.

Selecionar o registro.

O sistema carrega na tela os dados do registro

selecionado.
Fluxo Alternativo 2 Alterar Usurio
Ator

Sistema

Acessar a pgina de usurio.

O sistema lista todos os usurios cadastrados.

Selecionar o item a ser modificado.

O sistema carrega para a tela as informaes

referentes ao usurio selecionado.

Alterar as informaes e clica no boto Gravar.

O sistema valida as informaes da tela. Se os

dados estiverem OK, armazen-los na tabela
SD_TECNICO e enviar mensagem de operao
realizada com sucesso. Se os dados no estiverem
OK, enviar mensagem de erro.

54

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 Usurio
Ator

Sistema

Acessar a pgina de usurio.

O sistema lista todos os usurios cadastrados.

Selecionar o item a ser excludo.

O sistema carrega para a tela as informaes

referentes ao usurio selecionado.

Clicar no boto excluir.

O sistema exclui os dados da base de dados e

envia mensagem de operao 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;
Usurios Cadastrados.

Dados Consumidos

Responsvel, solicitante, impacto, nvel, urgncia, categoria, assunto,

descrio, data de abertura, data de concluso.

Dados Produzidos

Incidente cadastrado.

Prioridade

Alta.

Pr-condies

Possuir cadastro no sistema;

Estar logado no sistema.

Ps-condies

No se Aplica.
Fluxo Principal Cadastrar Incidente
Ator

Sistema

Acessar a pgina de cadastro de

Incidente do sistema.

O sistema carrega a pagina principal de incidente.

Preencher as informaes relativas ao incidente e

clica no boto gravar.

O sistema valida as informaes da tela. Se os

dados estiverem OK, armazen-los na tabela
SD_INCIDENTE e enviar mensagem de operao.
Se os dados no estiverem OK, enviar mensagem
de erro.

Receber mensagem.

55

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 pgina 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 pgina de incidente.

O sistema lista todos os incidentes cadastrados.

Selecionar o item a ser modificado.

O sistema carrega para a tela as informaes

referentes ao incidente selecionado.

Alterar as informaes e clica no boto gravar.

O sistema valida as informaes da tela. Se os

dados estiverem OK, armazen-los na tabela
SD_INCIDENTE e enviar mensagem de operao
realizada com sucesso. Se os dados no 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 pgina de incidentes.

O sistema lista todos os incidentes cadastrados.

Selecionar o item a ser excludo.

O sistema carrega para a tela o incidente

selecionado.

Excluir o incidente e clica no boto Gravar.

O sistema exclui os dados da base de dados e

envia mensagem de operao realizada com
sucesso.

Receber mensagem.

56

UC05 Manter Mudana

Tabela 6 UC04 Manter Mudana
Nome

UC05- Manter Mudana

Objetivo

Cadastrar Nova Mudana no Sistema.

Atores

Administrador;
Usurios Cadastrados.

Dados Consumidos

Responsvel, impacto, solicitante, urgncia, categoria, descrio, assunto,

Data de abertura, previso de concluso, data de inicio previsto, data incio
Atendimento, impacto.

Dados Produzidos

Mudana cadastrada.

Prioridade

Mdia.

Pr-condies

Possuir cadastro no sistema;

Estar logado no sistema.

Ps-condies

No se Aplica.
Fluxo Principal Cadastrar Mudana
Ator

Sistema

Acessar a pgina de cadastro de Mudana do

sistema.

O sistema carrega a pagina principal de mudana.

Preencher as informaes relativas s mudanas e O sistema valida as informaes da tela. Se os

clica no boto gravar
dados estiverem OK, armazen-los na tabela
SD_MUDANCA e enviar mensagem de operao
realizada com sucesso. Se os dados no 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 Mudana
Ator

Sistema

Acessar a pgina de mudana.

O sistema lista todas as mudanas cadastradas.

Selecionar o registro.

O sistema carrega na tela o registro selecionado.

Fluxo Alternativo 2 Alterar Mudana

Alterar Mudana
Ator

Sistema

Acessar a pgina de mudana.

O sistema lista todas as mudanas cadastradas.

Selecionar a mudana a ser modificada.

O sistema carrega para a tela as informaes

referentes mudana selecionada.

Alterar as informaes e clica no boto gravar.

O sistema valida as informaes da tela. Se os

dados estiverem OK, armazen-los na tabela
SD_MUDANCA e enviar mensagem de operao

57

realizada com sucesso. Se os dados no 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 Mudana
Ator

Sistema

Acessar a pgina de mudana.

O sistema lista todas as mudanas cadastradas.

Selecionar a mudana ser excluda.

O sistema carrega para a tela o registro

selecionado.

Excluir a mudana e clica no boto gravar.

O sistema exclui os dados da base de dados e

envia mensagem de operao realizada com
sucesso.

Receber mensagem.

UC06 Manter Problema

.
Tabela 7 - UC05 Manter Problema
Nome

UC06- Manter Problema

Objetivo

Cadastrar Problema.

Atores

Administrador;
Usurios Cadastrados.

Dados Consumidos

Responsvel, impacto, solicitante, urgncia, categoria, descrio, assunto,

Data de abertura, previso de concluso, data de inicio previsto, data incio
Atendimento, impacto.

Dados Produzidos

Problema cadastrado.

Prioridade

Alta.

Pr-condies

Possuir cadastro no sistema;

Usurio estar logado no sistema.

Ps-condies

No se aplica.
Fluxo Principal Cadastrar Problema
Ator

Acessar a pgina de cadastro de Problema.

Sistema
O sistema carrega a pagina de cadastro do
problema.

Preencher as informaes relativas ao problema e O sistema valida as informaes da tela. Se os

clicar no boto gravar.
dados estiverem OK, armazen-los na tabela
SD_PROBLEMA e enviar mensagem de operao
realizada com sucesso. Se os dados no 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 pgina 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 pgina de problema.

O sistema lista todos os problemas cadastrados.

Selecionar o problema a ser modificado.

O sistema carrega para a tela as informaes

referentes ao problema selecionado.

Alterar as informaes e clica no boto gravar.

O sistema valida as informaes da tela. Se os

dados estiverem OK, armazen-los na tabela
SD_PROBLEMA e enviar mensagem de operao
realizada com sucesso. Se os dados no 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 usurio acessa a pgina de problema.

O sistema lista todos os problemas cadastrados.

O usurio seleciona o problema a ser modificado.

O sistema carrega para a tela o problema

selecionado.

Excluir o problema e clica no boto excluir.

O sistema exclui os dados da base de dados e

envia mensagem de operao realizada com
sucesso.

Receber mensagem.

59

6.6. Diagrama de Classes

Existem trs tipos de perspectivas oferecidas no desenvolvimento de um

diagrama de classe: Perspectiva conceitual, que representa os conceitos do domnio
em estudo. Essa uma perspectiva voltada para o cliente; Perspectiva de
especificao, que foca nas principais interfaces e mtodos da arquitetura e no
como na forma que eles sero implementados. Essa perspectiva voltada para
pessoas que no necessitam do detalhamento do desenvolvimento; Perspectiva de
implementao, que aborda a forma como ser o sistema ser implementado. Essa
uma perspectiva voltada para a equipe de desenvolvimento.

Na implementao do trabalho proposto, ser utilizada a perspectiva de

especificao. Na figura abaixo mostrado o diagrama de classe do sistema.

class System

FUNCAO
+

TECNICO

getters() : void

+
+

getters() : Tecnico {query}

setters() : void {query}

SOLICITACAO
+
+
+
+

INCIDENTE
+
+

getters() : Incidente {query}

setters() : void {query}

alterar(Objeto) : void {query}

consultar(Objeto) : void {query}
excluir(Objeto) : void {query}
gravar(Objeto) : void {query}

MUDANCA
+
+

getters() : EstadoMudanca {query}

setters() : void {query}

Figura 4 - Diagrama de Classe

PROBLEMA
+
+

getters() : EstadoProblema {query}

setters() : void {query}

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. Especificao 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 PRIMRIA

ID_ANEXOINCIDENTE

Long

Sim

ID_INCIDENTE

Long

CHAVE ESTRANGEIRA

Sim

DESCRIO
Identificador
Identificador da tabela
SD_INCIDENTE.
Campo utilizado para
especificar o nome com

NM_NOME

o qual deseja identificar

varchar(500)

cada

anexo

do

incidente.

DS_DESCRICAO

varchar(2000)

ANEXO_BLOB

BLOB

6.8.2.

Campo utilizado para

armazenar a descrio
do anexo de forma que
ajude a compreender
detalhes do anexo.
Campo utilizado para
armazenar o anexo.

Tabela SD_ANEXOMUDANCA

Tabela utilizada para separar os anexos referentes mudana.

Tabela 9 - SD_ANEXOMUDANCA
ATRIBUTOS

TIPO DO DADO

CHAVE PRIMRIA

ID_ANEXOMUDANCA
ID_MUDANCA

Long
Long

Sim

DS_DESCRICAO

varchar(50)

NM_NOME

varchar(500)

NM_TIPO

Varchar(50)

ANEXO_BLOB

BLOB

CHAVE ESTRANGEIRA

Sim

DESCRIO
Identificador
Identificador da tabela
SD_MUDANCA
Campo utilizado para
descrio do anexo
Campo utilizado para
armazenar o nome do
anexo
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
Campo utilizado para
armazenar o anexo.

62

6.8.3.

Tabela SD_ESTADOMUDANCA

Tabela utilizada para armazenar os estados da mudana.

Tabela 10 - SD_ESTADOMUDANCA
ATRIBUTOS

TIPO DO DADO

ID_ESTADOMUDANCA
NM_NOME

Long
Varchar (500)

NM_TEMPORIZADOR

Varchar (50)

DS_DESCRICAO

Varchar(2000)

6.8.4.

CHAVE
PRIMRIA

CHAVE ESTRANGEIRA

Sim

DESCRIO
Identificador
Armazena o nome
nico com o qual
deseja identificar
cada estado de
mudana.
Armazena o tempo
gasto na
implementao da
mudana
Armazena a
descrio do estado
da mudana de forma
que ajude a
compreender cada
estado.

Tabela SD_FUNCAO

Tabela utilizada para armazenar a funo do tcnico dentro do sistema.

Tabela 11 - SD_FUNCO
ATRIBUTOS

TIPO DO DADO

ID_FUNCAO
NM_NOME

Long
Varchar (500)

DS_DESCRICAO

Varchar(2000)

CHAVE
PRIMRIA

Sim

CHAVE ESTRANGEIRA

DESCRIO
Identificador
Armazena o nome
nico com o qual
deseja identificar
cada funo de um
tcnico. Ex: Analista,
Desenvolvedor, DBA,
entre outras funes.
Armazena a
descrio de cada
funo de forma que
ajude a compreender
cada funo

63

6.8.5.

TABELA SD_IMPACTO

ATRIBUTOS

ID_IMPACTO
NM_NOME

Long
Varchar (500)

DS_DESCRICAO

Varchar(2000)

6.8.6.

CHAVE
PRIMRIA

TIPO DO DADO

CHAVE ESTRANGEIRA

Sim

DESCRIO
Identificador
Armazena o nome
nico com o qual
deseja identificar
cada impacto de uma
solicitao. Ex: Afeta
o setor financeiro;
Afeta o setor de
almoxarifado.
Armazena a
descrio de cada
impacto de forma que
ajude a compreender
cada impacto.

Tabela SD_INCIDENTE

Tabela utilizada para armazenar incidentes.

Tabela 12 - SD_INCIDENTE
ATRIBUTOS

TIPO DO DADO

CHAVE
PRIMRIA

CHAVE ESTRANGEIRA

ID_INCIDENTE
ID_RESPONSAVEL

Long
Long

Sim

DS_SOLICITANTE

Long

ID_IMPACTO

Long

Sim

ID_MODO

Long

Sim

ID_NIVEL

Long

Sim

ID_URGENCIA

Long

Sim

ID_CATEGORIA

Long

Sim

NM_ASSUNTO

Varchar(500)

DS_RESOLUCAO

Varchar(800)

DS_DESCRICAO

Varchar(2000)

DT_ABERTURA

Date

DT_PREVCONCLUSAO

Date

DT_INICIOPREVISTA

Date

DT_INICIOATENDIMENTO

Date

Sim

DESCRIO
Identificador
Identificador da tabela
SD_RESPONSAVEL
Identificador da tabela
SD_SOLICITANTE
Identificador da tabela
SD_IMPACTO
Identificador da tabela
SD_MODO
Identificador da tabela
SD_NIVEL
Identificador da tabela
SD_URGENCIA
Identificador da tabela
SD_CATEGORIA
Armazena o assunto
relacionado ao
incidente cadastrado
Descrio da soluo
do incidente
Armazena a
descrio do
incidente
Armazena a data de
abertura do incidente
Armazena a data de
previso de resoluo
do incidente
Armazena a data
prevista para o incio
da resoluo do
incidente
Armazena a data real
do incio do
atendimento

64

6.8.7.

Tabela SD_MATRIZPRIORIDADE

Tabela utilizada para armazenar a prioridade com base no impacto e urgncia.

Tabela 13 - SD_ MATRIZPRIORIDADE
ATRIBUTOS

TIPO DO DADO

CHAVE PRIMRIA

CHAVE ESTRANGEIRA

ID_IMPACTO

Long

Sim

ID_PRIORIDADE

Long

Sim

ID_URGENCIA

Long

Sim

6.8.8.

DESCRIO
Identificador da tabela
SD_IMPACTO
Identificador da tabela
SD_PRIORIDADE
Identificador da tabela
SD_URGENCIA

Tabela SD_MUDANCA

Tabela utilizada para armazenar as solicitaes de mudanas.

Tabela 14 - SD_MUDANCA
ATRIBUTOS

TIPO DO DADO

CHAVE
PRIMRIA

CHAVE
ESTRANGEIRA

DESCRIO
Identificador

ID_MUDANCA
ID_MODO

Long
Long

Sim

ID_RESPONSAVEL

Long

Sim

ID_NIVELMUDANCA

Long

Sim

ID_IMPACTO

Long

Sim

ID_SOLICITANTE

Long

Sim

ID_URGENCIA

Long

Sim

ID_CATEGORIA

Long

Sim

NM_DESCRICAO

Varchar(50)

NM_ASSUNTO

Varchar(2000)

DT_ABERTURA

Date

DT_PREVISAOCONCLUSAO

Date

DT_INICIOPREVISTA

Date

DT_INICIOATENDIMENTO

Date

NM_RESOLUCAO

Varchar(500)

NM_IMPACTO

Varchar(4000)

NM_PLANOROLLOUT

Varchar(4000)

Sim

Identificador da tabela
SD_MODO
Identificador da tabela
SD_TECNICO
Identificador da tabela
SD_NIVELMUDANCA.
Identificador da tabela
SD_IMPACTO
Identificador da tabela
SD_SOLICITANTE
Identificador da tabela
SD_SOLICITANTE
Identificador da tabela
SD_CATEGORIA
Armazena a descrio
da mudana
Armazena o assunto
da mudana
Armazena a data de
abertura da mudana
Armazena a data de
abertura da mudana
Armazena a data de
previso de incio do
atendimento da
mudana
Armazena a data real
de incio do
atendimento.
Descreve a resoluo
da mudana
Descreve o impacto
que a mudana
poder causar
Plano que definir
qual estratgia
utilizada para atender

65

NM_PLANOBACKOUT

Varchar(4000)

NM_LISTAVERIFICACAO

Varchar(4000)

NM_REVISAO

Varchar(4000)

6.8.9.

a mudana
Plano que definir
qual estratgia
utilizada para
solucionar um
problema ocorrido
com a implementao
da mudana
Lista utilizada para
verificar o atendimento
das tarefas
Revisar a mudana
realizada

Tabela SD_MUDANCAESTADO

Tabela utilizada para armazenar a associao entre as entre as tabelas

SD_MUDANCA e SD_ESTADOMUDANCA.
Tabela 15 - SD_MUDANCAESTADO
ATRIBUTOS

TIPO DO DADO

ID_MUDANCAESTADO
ID_ESTADOMUDANCA

Long
Long

ID_MUDANCA

Long

6.8.10.

CHAVE
PRIMRIA

CHAVE ESTRANGEIRA

DESCRIO
Identificador.

Sim
Sim
Sim

Identificador da tabela
SD_ESTADOMUDANCA
Identificador da tabela
SD_MUDANCA

Tabela SD_NIVELMUDANCA

Tabela utilizada para armazenar a classificao dos nveis de mudana.

Tabela 16 - SD_NIVELMUDANCA
ATRIBUTOS

TIPO DO DADO

ID_NIVELMUDANCA
NM_NOME

Long
Varchar(500)

DS_DESCRICAO

Varchar(2000)

CHAVE PRIMRIA

Sim

CHAVE ESTRANGEIRA

DESCRIO
Identificador
Campo utilizado para
especificar o nome
nico com o qual
deseja identificar cada
nvel de mudana.
Campo utilizado para
descrever o nvel de
mudana.

6.8.11.

Tabela SD_PRIORIDADE

Tabela utilizada para armazenar a importncia atribuda a um pedido.

66

Tabela 17 - SD_PRIORIDADE
ATRIBUTOS

TIPO DO DADO

ID_PRIORIDADE
NM_NOME

Long
Varchar(500)

NM_COR

Varchar(50)

DS_DESCRICAO

Varchar(2000)

6.8.12.

CHAVE PRIMRIA

CHAVE ESTRANGEIRA

Sim

DESCRIO
Identificador
onde deve
especificar o nome
nico com o qual
deseja identificar cada
prioridade
Define a cor da
prioridade
Ajuda a compreender
a prioridade

Tabela SD_TECNICO

Tabela utilizada para armazenar os tcnicos que estaro envolvidos no

processo de desenvolvimento de software. Nesta tabela conter tambm a
equipe de suporte que far o primeiro contato com cliente.

Tabela 18 - SD_TECNICO
ATRIBUTOS

TIPO DO DADO

ID_TECNICO
ID_FUNCAO

Long
Long

NM_LOGIN

Varchar(50)

CHAVE
PRIMRIA

CHAVE ESTRANGEIRA

Sim
Sim

DESCRIO
Identificador
Identificador da tabela
SD_FUNCAO
Login utilizado para
conectar na aplicao.

NM_SENHA

Varchar(50)

NM_CUSTOPORMNUTO

Number(8,2)

NM_EMAIL

Varchar(50)

NM_NOME

Varchar(100)

Campo utilizado para

armazenar a senha do
tcnico
Campo utilizado para
armazenar custo da
tarefa realizada pelo
tcnico
Campo utilizado para
armazenar o email do
tcnico.
Campo utilizado para
armazenar o nome

67

6.8.13.

Tabela SD_URGENCIA

Tabela utilizada para armazenar a velocidade necessria para resoluo de um

incidente.
Tabela 19 - SD_URGENCIA
ATRIBUTOS

TIPO DO DADO

ID_URGENCIA
NM_NOME

Long
Varchar(50)

DS_DESCRICAO

Varchar(2000)

CHAVE
PRIMRIA

CHAVE ESTRANGEIRA

Sim

DESCRIO
Identificador
onde deve
especificar o nome
nico com o qual
deseja identificar
cada urgncia
Ajuda a compreender
a urgncia

6.9. rvore do Sistema

Segue abaixo uma representao grfica da estrutura do sistema proposto.

A rvore foi criada como modelo de mapa mental, pois, facilita a visualizao,
memorizao e compreenso da estrutura do sistema.

Figura 6 - rvore do Sistema

68

6.10.

Especificaes Fsicas

Logo abaixo sero mostradas as telas do sistema proposto, o Help on-line e

a segurana fsica e lgica com as suas devidas normas.

6.10.1.

Layout das Principais Telas da Aplicao

A seguir, sero mostradas o prottipo das principais telas do sistema

proposto. As telas de edio usaro as mesmas de cadastro, portanto sero
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 solicitao. O

usurio determinar se a solicitao uma Incidente ou um Problema.

Figura 8 - Nova Solicitao

Ao clicar em Adicionar Soluo a tela abaixo apresenta para a descrio

da soluo da solicitao.

Figura 9 - Adicionar Soluo

70

Abaixo apresentada a tela de cadastro de problema:

Figura 10 - Cadastro de Problema

O prottipo abaixo retrata a tela de cadastro do usurio.

Figura 11 - Cadastro de Usurio

71

6.11.

Help on-line

O Help on-line um mecanismo de ajuda e suporte ao usurio para utilizar e

operar o sistema. O mesmo disponibiliza um tpico de ajuda para a navegao e
utilizao do software. A opo Ajuda se encontra na parte superior das telas do
sistema com o formato do sinal de interrogao indicando a ferramenta de ajuda.

6.12.

Segurana Fsica e Lgica

Para que a segurana de um sistema obtenha xito em seu funcionamento

necessrio que seus dados, assim como seus servidores e outros equipamentos
sejam protegidos. Segurana fsica impedir o acesso no autorizado a
equipamentos e segurana lgica impedir o acesso das informaes de um
sistema. Todos que fazem uso das informaes do sistema proposto devem ter
acesso conforme definio de cada perfil do usurio. Vrios fatores devero ser
analisados na segurana fsica e lgica, a fim de se obter uma proteo mxima do
sistema e de seus equipamentos.

6.12.1.

Norma de Segurana Fsica

As normas de segurana fsica tm como objetivo zelar e guardar o servidor

de aplicao e servidor de banco de dados, onde dever ser mantido de forma
isolada de outros recursos de informtica, como tambm dever ser protegido de
incndios, desabamentos, relmpagos, 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 Segurana Lgica

Segurana lgica a forma como o sistema dever ser protegido no nvel de

sistema operacional. Devero existir normas de polticas de segurana para definir o
acesso das informaes no sistema. Todo usurio deve ter uma identificao nica,

72

pessoal e intransfervel, qualificando-o, inequivocamente, como responsvel por

qualquer atividade desenvolvida sob esta identificao.

O sistema proposto define tipos de perfis conforme cada tipo de atuao

dentro da empresa. Permite a correta identificao de um usurio para lhe conferir
acesso de acordo com seu perfil. Possibilitam especificar as aes permitidas e
nveis de privilgio diferenciados para cada usurio atravs do estabelecimento de
polticas de uso.

73

7.

Plano de Implantao
A finalidade do Plano de Implantao garantir que o sistema alcance seus

usurios com sucesso. O Plano de Implantao fornece uma agenda detalhada de

eventos, pessoas responsveis e dependncias de evento necessrias para garantir
a mudana bem-sucedida para o novo sistema. A implantao deve minimizar o
impacto da mudana na equipe do cliente, no sistema de produo e na rotina geral
dos negcios (RUP, 2010).

O servidor de aplicao para o ambiente de produo definido, de forma que

haja as mnimas condies de funcionamento do sistema possuir uma maquina
com o processador Intel Core 2 Duo, 4 gigabyte de memria, Apache Tomcat 6 ou
uma verso superior, Java 5 ou uma verso superior.

Para o banco de dados, a configurao mnima conter um computador que

possua um processador Intel Core 2 Duo, 8 gigabyte de memria, Sistema
Operacional Windows e Oracle 10g XE.

74

8.

Concluso
Muitas instituies possuem demandas internas de servios que precisam ser

registradas, analisadas e executadas, para que dessa forma tenham um ponto nico
de controle dos servios prestados. Partindo desse princpio foi desenvolvido um
projeto

de

gerenciamento

de

servios

voltado

exclusivamente

para

desenvolvimento de software, que ser implantado na empresa Dave Systems

(Empresa Fictcia).

O trabalho desenvolvido visa centralizar os servios internos prestados, a

gerao de relatrios gerenciais, a substituio do atual sistema devido a sua
inconsistncia de dados e a utilizao do mesmo para a implantao 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 centralizao na tomada de deciso, assim como o
seu gerenciamento.

Atualmente o sistema d nfase a implementao as disciplinas de

Gerenciamento de Incidente, Gerenciamento de Problema e Gerenciamento de
Mudana e o desenvolvimento de um Service Desk. Como trabalhos futuros, sero
implementados as disciplinas de Gerenciamento de Configurao, Gerenciamento
de Nvel de Servio e Gerenciamento de Liberao ficando a cargo da equipe de
desenvolvimento da empresa Dave Systems (Empresa Fictcia).

75

9.

Referencias Bibliogrficas

[1] BMC SOFTWARE. ISO 20000: O que deve uma organizao fazer? Disponvel
em: <http://documents.bmc.com/products/documents/49/68/64968/64968.pdf>.
Acessado em 29 de Junho de 2010.
[2] SEBRAE. Programao e Controle de Produo. Disponvel em:
<http://www.sebraesp.com.br/faq/produtividade/programacao_controle_producao/cro
nograma>. Acessado em 25 de maio de 2010.
[3] SUN. JAVA. Disponvel em <http://www.java.com/ >. Acessado em 03 de Abril de
2010.
[4] DEVMEDIA, Oracle Free. Disponvel 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. Disponvel em:
<http://www.postgresql.org.br/sobre>. Acessado em 26 de junho de 2010.
[6] RUP, Rational Unified Process. Melhor Prtica: Desenvolva iterativamente.
Disponvel 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. Disponvel
em:<http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/diagramas/classes/cl
asses1.htm >
ABBEY, Michael; COREY, Michael J.; ABRAMSON, Ian. Oracle 8i Guia
Introdutrio. Rio de Janeiro: Campus, 2000.
ABBEY, Michael; COREY, Michael J. Oracle, Guia do Usurio. So Paulo: Makron
Books, 1997.
ANDRADE, Gabriel. O Que so Linguagens de Programao.
<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 Usurio.
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 Bblia. Rio de Janeiro: Campus, 2001.
DEITEL, Harvey M.; DEITEL, Paul J. Java Como Programar. So Paulo: Pearson
Prentice Hall 6 Edio, 2005

76

FRY, Malcolm. The Goals of ITIL: Exploring the goals of Service Management.
Sunnyvale, USA: Remedy, 2003.
FURLAN, Jos Davi. Modelagem de Objetos Atravs da UML. So Paulo: Makron,
1998.
GONALVES, Edson. Desenvolvendo Aplicaes Web com NetBeans IDE 5.5.
Rio de Janeiro: Cincia Moderna, 2007.
GUEDES, Gilleanes. UML 2 Guia Prtico. So Paulo: Novatec 2007.
LISCHNER, Ray. Delphi. O Guia Essencial. Rio de Janeiro: Campus, 2000
KRUCHTEN, Philippe. Introduo ao RUP RATIONL UNIFIED PROCESS. Rio de
Janeiro: Moderna, 2003.
MAGALHES, Ivan Luizio; PINHEIRO, Walfrido Brito. Gerenciamento de Servios de
TI na Prtica, Uma abordagem com base na ITIL. So Paulo: Novatec, 2007.
MATOS, Alexandre Veloso. UML, Prtico e Descomplicado. So Paulo: rica,
2002.
PAGE-JONES, Meilir. Fundamento do Desenho Orientado a Objeto Com UML.
Makron Books, 2000.
PENDER, Tom. UML a Bblia. Campus 2004.
SANTOS, Lucas Lopes. MySQL. Disponvel em: <
http://www.malima.com.br/article_read.asp?id=142> Acessado em 26 de abril de
2010.
SANTOS, Rafael. INTRODUO PROGRAMAO ORIENTDA A OBJETOS
USANDO JAVA. So Paulo: Campus, 2003.

SHEPHERD, George. ASP.NET Passo a Passo. So Paulo: Bookmark, 2006.

SWAN, Tom. Delphi, Bblia do Programador. So Paulo: IDG BOOKS 3 Edio,

1997.