FACULDADE ALVORADA CURSO DE BACHARELADO EM SISTEMAS DE INFORMAO

Francisco David Costa de Oliveira

SISTEMA DE SERVICE DESK VOLTADO PARA DESENVOLVIMENTO DE SOFTWARE (SISDESK)

Orientador: M Elizabeth dArrochella Teixeira

Braslia DF,

ii

FRANCISCO DAVID COSTA DE OLIVEIRA

SISTEMA DE SERVICE DESK VOLTADO PARA DESENVOLVIMENTO DE SOFTWARE (SISDESK)

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

Orientador: M Elizabeth dArrochella Teixeira

Braslia DF,

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 API FTF HTML IEC HTTP IMAP ISSO ITIL JDBC LDAP ODBC OMC OOSE PHP POP RTF RUP SISDESK SLA TI UML

Asymmetric Digital Subscriber Line Application Programming Interface Finalization Task Force Hipertext Markup Language International Electrotechnical Commission HiperText Transfer Protocol Internet Message Protocol International Organization for Standardization Information Technology Infrastructure Library Java DataBase Connectivity Lightweight Directory Access Protocol Open Database Connectivity Object Management Group Object-Oriented Software Engineering HiperText Preprocessor Post Office Protocol Revision Task Force Rational Unified Process Sistema de Service Desk Service Level Agreement Tecnologia da Informao 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. 1.4.2. Geral ............................................................................................................ 16 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. 4.1.2. 4.1.3. Java.............................................................................................................. 22 PHP .............................................................................................................. 24 Delphi ........................................................................................................... 25

4.2. Banco de Dados ................................................................................................. 25 4.2.1. 4.2.2. 4.2.3. Oracle........................................................................................................... 26 PostgreSQL.................................................................................................. 26 MySQL ......................................................................................................... 27

4.3. RUP (Rational Unified Process) .......................................................................... 28 4.3.1. 4.3.2. 4.3.2.1. 4.3.2.2. Desenvolvimento Iterativo ............................................................................ 28 Fases do RUP .............................................................................................. 29 Concepo ................................................................................................ 30 Elaborao ................................................................................................ 30

11

4.3.2.3. 4.3.2.4.

Construo................................................................................................ 31 Transio .................................................................................................. 31

4.4. UML (Unified Model Language) .......................................................................... 32 4.4.1. 4.4.1.1. 4.4.1.2. 4.4.1.3. 4.4.1.4. 4.4.1.5. 4.4.2. 4.4.2.1. 4.4.2.2. 4.4.2.3. 4.4.2.4. 4.4.2.5. 4.4.2.6. 4.4.2.7. 4.4.2.8. 4.4.2.9. 4.4.2.10. Orientao a Objetos ................................................................................... 33 Objetos...................................................................................................... 34 Classes ..................................................................................................... 34 Herana .................................................................................................... 35 Polimorfismo ............................................................................................. 35 Coeso...................................................................................................... 36 Diagramas .................................................................................................... 36 Diagramas de Classes .............................................................................. 37 Diagramas de Colaborao ...................................................................... 37 Diagramas de Objetos .............................................................................. 37 Diagramas de Componentes .................................................................... 38 Diagramas de Caso de Uso ...................................................................... 38 Diagramas de Seqncia .......................................................................... 39 Diagramas de Atividade ............................................................................ 39 Diagramas de Interao ............................................................................ 40 Diagramas de Implantao ....................................................................... 40 Diagramas de Grfico de Estados ......................................................... 41

4.5. Information Technology Infrastructure Library - ITIL ........................................... 41 4.5.1. 4.5.2. 4.5.3. 4.5.4. Central de Servios (Service Desk).............................................................. 42 Gerenciamento de Incidentes ...................................................................... 43 Gerenciamento de Problema ....................................................................... 43 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. 6.8.2. 6.8.3. 6.8.4. 6.8.5. 6.8.6. 6.8.7. 6.8.8. 6.8.9. 6.8.10. 6.8.11. 6.8.12. 6.8.13. Tabela SD_ANEXOINCIDENTE .................................................................. 61 Tabela SD_ANEXOMUDANCA .................................................................... 61 Tabela SD_ESTADOMUDANCA ................................................................. 62 Tabela SD_FUNCAO ................................................................................... 62 TABELA SD_IMPACTO ............................................................................... 63 Tabela SD_INCIDENTE ............................................................................... 63 Tabela SD_MATRIZPRIORIDADE ............................................................... 64 Tabela SD_MUDANCA ................................................................................ 64 Tabela SD_MUDANCAESTADO ................................................................. 65 Tabela SD_NIVELMUDANCA ................................................................... 65 Tabela SD_PRIORIDADE ......................................................................... 65 Tabela SD_TECNICO ............................................................................... 66 Tabela SD_URGENCIA ............................................................................ 67

6.9. rvore do Sistema .............................................................................................. 67 6.10. 6.10.1. 6.11. 6.12. 6.12.1. 6.12.2. Especificaes Fsicas ................................................................................. 68 Layout das Principais Telas da Aplicao ................................................. 68 Help on-line .................................................................................................. 71 Segurana Fsica e Lgica ........................................................................... 71 Norma de Segurana Fsica ..................................................................... 71 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

Os objetivos especficos do sistema proposto so: 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 o codinome Green, que resultou no

desenvolvimento de uma linguagem baseada em C++ que seu criador o chamou de Oak e que posteriormente foi trocado para Java. A Sun anunciou o Java formalmente em 1995 em uma importante 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

34

alta coeso interna de seus componentes, o que permite promover substituies sem afetar interconexes ou interferir com a operao dos demais objetos. 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.

35

Conforme SANTOS (2003), os dados contidos em uma classe so conhecidos como campos ou atributos daquela classe. Cada campo deve ter um 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

36

origina-se de duas palavras gregas que significam respectivamente, muitas e forma. Algo que polifrmico, portanto, apresenta a propriedade de assumir muitas formas. 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 e associaes. Diagramas so meios para

visualizao desses blocos de construo. Um diagrama uma apresentao

37

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

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 e colaboraes e 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

38

diagramas de classes. Os diagramas de objetos fazem a modelagem de instncias 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

39

todo, embora venha a ser consultado durante todo o processo de modelagem e sirva de base para todos os outros diagramas (GUEDES, 2007).

Conforme BOOCH, RUMBAUGH e JACOBSON (2005) os diagramas de caso de uso 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

40

execuo de um comportamento com o propsito de estudar os fluxos dirigidos por 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 UC01 UC02 UC03 UC04 UC05

Casos de Uso Efetuar Login Manter Usurio Manter Incidente Manter Mudana 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 Objetivo Atores Dados Consumidos Dados Produzidos Prioridade Pr-condies Ps-condies UC01- Efetuar Login Efetuar Login. Administrador; Usurios Cadastrados. Login e senha. Acesso ao sistema. Alta. Possuir cadastro no sistema. N/A Fluxo Principal Efetuar login. Ator Informar login e senha. Sistema 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 Objetivo Atores Dados Consumidos Dados Produzidos Prioridade Pr-condies Ps-condies UC03- Manter Usurio Cadastrar usurio no sistema. Administrador; Usurios Cadastrados. Nome, funo, email e tcnico. Usurios Cadastrados. Alta. Possuir cadastro no sistema; Estar logado no sistema. N/A Fluxo Principal Cadastrar Usurio Ator Acessar a pgina de cadastro de usurio. Sistema 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 Acessar a pgina de consulta de usurio. Selecionar o registro. Sistema O sistema lista todos os usurios cadastrados. O sistema carrega na tela os dados do registro selecionado. Fluxo Alternativo 2 Alterar Usurio Ator Acessar a pgina de usurio. Selecionar o item a ser modificado. Alterar as informaes e clica no boto Gravar. Sistema O sistema lista todos os usurios cadastrados. O sistema carrega para a tela as informaes referentes ao usurio selecionado. O sistema valida as informaes da tela. Se os dados estiverem OK, armazen-los na tabela SD_TECNICO e enviar mensagem de operao

54

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 Usurio Ator Acessar a pgina de usurio. Selecionar o item a ser excludo. Clicar no boto excluir. Sistema O sistema lista todos os usurios cadastrados. O sistema carrega para a tela as informaes referentes ao usurio selecionado. 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 Objetivo Atores Dados Consumidos Dados Produzidos Prioridade Pr-condies Ps-condies UC04- Manter Incidente Cadastrar Novo incidente no Sistema. Administrador; Usurios Cadastrados. Responsvel, solicitante, impacto, nvel, urgncia, categoria, assunto, descrio, data de abertura, data de concluso. Incidente cadastrado. Alta. Possuir cadastro no sistema; Estar logado no sistema. No se Aplica. Fluxo Principal Cadastrar Incidente Ator Acessar a pgina de cadastro de Incidente do sistema. Preencher as informaes relativas ao incidente e clica no boto gravar. Sistema O sistema carrega a pagina principal de incidente. 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

55

de erro. Receber mensagem. Se a mensagem foi de erro, reinicie o processo do fluxo principal. Se a mensagem foi de sucesso, encerre o Fluxo Fluxo Alternativo 1 Consultar Incidente Ator Acessar a pgina de incidente. Selecionar o registro. Sistema O sistema lista todos os incidentes cadastrados. O sistema carrega na tela o registro selecionado. Fluxo Alternativo 2 Alterar Incidente Ator Acessar a pgina de incidente. Selecionar o item a ser modificado. Alterar as informaes e clica no boto gravar. Sistema O sistema lista todos os incidentes cadastrados. O sistema carrega para a tela as informaes referentes ao incidente selecionado. 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 Acessar a pgina de incidentes. Selecionar o item a ser excludo. Excluir o incidente e clica no boto Gravar. Sistema O sistema lista todos os incidentes cadastrados. O sistema carrega para a tela o incidente selecionado. 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 Objetivo Atores Dados Consumidos UC05- Manter Mudana Cadastrar Nova Mudana no Sistema. Administrador; Usurios Cadastrados. Responsvel, impacto, solicitante, urgncia, categoria, descrio, assunto, Data de abertura, previso de concluso, data de inicio previsto, data incio Atendimento, impacto. Mudana cadastrada. Mdia. Possuir cadastro no sistema; Estar logado no sistema. No se Aplica. Fluxo Principal Cadastrar Mudana Ator Acessar a pgina de cadastro de Mudana do sistema. Sistema O sistema carrega a pagina principal de mudana.

Dados Produzidos Prioridade Pr-condies Ps-condies

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 Acessar a pgina de mudana. Selecionar o registro. Sistema O sistema lista todas as mudanas cadastradas. O sistema carrega na tela o registro selecionado. Fluxo Alternativo 2 Alterar Mudana Alterar Mudana Ator Acessar a pgina de mudana. Selecionar a mudana a ser modificada. Alterar as informaes e clica no boto gravar. Sistema O sistema lista todas as mudanas cadastradas. O sistema carrega para a tela as informaes referentes mudana selecionada. 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 Acessar a pgina de mudana. Selecionar a mudana ser excluda. Excluir a mudana e clica no boto gravar. Sistema O sistema lista todas as mudanas cadastradas. O sistema carrega para a tela o registro selecionado. 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 Objetivo Atores Dados Consumidos UC06- Manter Problema Cadastrar Problema. Administrador; Usurios Cadastrados. Responsvel, impacto, solicitante, urgncia, categoria, descrio, assunto, Data de abertura, previso de concluso, data de inicio previsto, data incio Atendimento, impacto. Problema cadastrado. Alta. Possuir cadastro no sistema; Usurio estar logado no sistema. 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.

Dados Produzidos Prioridade Pr-condies Ps-condies

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 Acessar a pgina de problema. Selecionar o registro. Sistema O sistema lista todos os problemas cadastrados. O sistema carrega na tela o registro selecionado. Fluxo Alternativo 2 Alterar Problema Ator Acessar a pgina de problema. Selecionar o problema a ser modificado. Alterar as informaes e clica no boto gravar. Sistema O sistema lista todos os problemas cadastrados. O sistema carrega para a tela as informaes referentes ao problema selecionado. 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 O usurio acessa a pgina de problema. O usurio seleciona o problema a ser modificado. Excluir o problema e clica no boto excluir. Sistema O sistema lista todos os problemas cadastrados. O sistema carrega para a tela o problema selecionado. 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 + getters() : void + +

TECNICO getters() : Tecnico {query} setters() : void {query}

SOLICITACAO + + + + alterar(Objeto) : void {query} consultar(Objeto) : void {query} excluir(Objeto) : void {query} gravar(Objeto) : void {query}

INCIDENTE + + getters() : Incidente {query} setters() : void {query} + +

MUDANCA getters() : EstadoMudanca {query} setters() : void {query} + +

PROBLEMA getters() : EstadoProblema {query} setters() : void {query}

Figura 4 - Diagrama de Classe

60

6.7. Modelo de Entidade e Relacionamento Abaixo mostrado o modelo de entidade e relacionamento utilizado no desenvolvimento do sistema.

Figura 5 - Modelo de Entidade e Relacionamento

61

6.8. 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 CHAVE ESTRANGEIRA DESCRIO Identificador Identificador da tabela SD_INCIDENTE. Campo utilizado para especificar o nome com

ID_ANEXOINCIDENTE ID_INCIDENTE

Long Long

Sim Sim

NM_NOME

varchar(500)

o qual deseja identificar cada incidente. Campo utilizado para armazenar a descrio do anexo de forma que ajude a compreender detalhes do anexo. Campo utilizado para armazenar o anexo. anexo do

DS_DESCRICAO ANEXO_BLOB

varchar(2000) BLOB

6.8.2.

Tabela SD_ANEXOMUDANCA

Tabela utilizada para separar os anexos referentes mudana.

Tabela 9 - SD_ANEXOMUDANCA
ATRIBUTOS TIPO DO DADO CHAVE PRIMRIA CHAVE ESTRANGEIRA 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.

ID_ANEXOMUDANCA ID_MUDANCA DS_DESCRICAO NM_NOME NM_TIPO

Long Long varchar(50) varchar(500) Varchar(50)

Sim Sim

ANEXO_BLOB

BLOB

62

6.8.3.

Tabela SD_ESTADOMUDANCA

Tabela utilizada para armazenar os estados da mudana.

Tabela 10 - SD_ESTADOMUDANCA
ATRIBUTOS TIPO DO DADO CHAVE PRIMRIA CHAVE ESTRANGEIRA 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.

ID_ESTADOMUDANCA NM_NOME

Long Varchar (500)

Sim

NM_TEMPORIZADOR

Varchar (50)

DS_DESCRICAO

Varchar(2000)

6.8.4.

Tabela SD_FUNCAO

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

Tabela 11 - SD_FUNCO
ATRIBUTOS TIPO DO DADO CHAVE PRIMRIA 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

ID_FUNCAO NM_NOME

Long Varchar (500)

Sim

DS_DESCRICAO

Varchar(2000)

63

6.8.5.

TABELA SD_IMPACTO
CHAVE PRIMRIA

ATRIBUTOS

TIPO DO DADO

CHAVE ESTRANGEIRA

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.

ID_IMPACTO NM_NOME

Long Varchar (500)

Sim

DS_DESCRICAO

Varchar(2000)

6.8.6.

Tabela SD_INCIDENTE

Tabela utilizada para armazenar incidentes.

Tabela 12 - SD_INCIDENTE
ATRIBUTOS TIPO DO DADO CHAVE PRIMRIA CHAVE ESTRANGEIRA 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

ID_INCIDENTE ID_RESPONSAVEL DS_SOLICITANTE ID_IMPACTO ID_MODO ID_NIVEL ID_URGENCIA ID_CATEGORIA NM_ASSUNTO DS_RESOLUCAO DS_DESCRICAO DT_ABERTURA DT_PREVCONCLUSAO DT_INICIOPREVISTA

Long Long Long Long Long Long Long Long Varchar(500) Varchar(800) Varchar(2000) Date Date Date

Sim Sim

Sim Sim Sim Sim Sim

DT_INICIOATENDIMENTO

Date

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 DESCRIO Identificador da tabela SD_IMPACTO Identificador da tabela SD_PRIORIDADE Identificador da tabela SD_URGENCIA

ID_IMPACTO ID_PRIORIDADE ID_URGENCIA

Long Long Long

Sim Sim Sim

6.8.8.

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 ID_RESPONSAVEL ID_NIVELMUDANCA ID_IMPACTO ID_SOLICITANTE ID_URGENCIA ID_CATEGORIA NM_DESCRICAO NM_ASSUNTO DT_ABERTURA DT_PREVISAOCONCLUSAO DT_INICIOPREVISTA

Long Long Long Long Long Long Long Long Varchar(50) Varchar(2000) Date Date Date

Sim Sim Sim Sim Sim Sim Sim Sim

DT_INICIOATENDIMENTO NM_RESOLUCAO NM_IMPACTO NM_PLANOROLLOUT

Date Varchar(500) Varchar(4000) Varchar(4000)

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 NM_REVISAO

Varchar(4000) Varchar(4000)

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

6.8.9.

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 CHAVE PRIMRIA CHAVE ESTRANGEIRA DESCRIO Identificador.

ID_MUDANCAESTADO ID_ESTADOMUDANCA ID_MUDANCA

Long Long Long

Sim Sim Sim

Identificador da tabela SD_ESTADOMUDANCA Identificador da tabela SD_MUDANCA

6.8.10.

Tabela SD_NIVELMUDANCA

Tabela utilizada para armazenar a classificao dos nveis de mudana.

Tabela 16 - SD_NIVELMUDANCA
ATRIBUTOS TIPO DO DADO CHAVE PRIMRIA 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.

ID_NIVELMUDANCA NM_NOME

Long Varchar(500)

Sim

DS_DESCRICAO

Varchar(2000)

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 CHAVE PRIMRIA CHAVE ESTRANGEIRA 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

ID_PRIORIDADE NM_NOME

Long Varchar(500)

Sim

NM_COR DS_DESCRICAO

Varchar(50) Varchar(2000)

6.8.12.

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 CHAVE PRIMRIA CHAVE ESTRANGEIRA DESCRIO Identificador Identificador da tabela SD_FUNCAO Login utilizado para conectar na aplicao.

ID_TECNICO ID_FUNCAO NM_LOGIN NM_SENHA NM_CUSTOPORMNUTO

Long Long Varchar(50) Varchar(50) Number(8,2)

Sim Sim

NM_EMAIL NM_NOME

Varchar(50) 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 CHAVE PRIMRIA CHAVE ESTRANGEIRA DESCRIO Identificador onde deve especificar o nome nico com o qual deseja identificar cada urgncia Ajuda a compreender a urgncia

ID_URGENCIA NM_NOME

Long Varchar(50)

Sim

DS_DESCRICAO

Varchar(2000)

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 o

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.