SisDesk - Sistema de Service-Desk voltado para desenvolvimento de software
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

SisDesk - Sistema de Service-Desk voltado para desenvolvimento de software

  • 5,992 views
Uploaded on

As empresas de TI (Tecnologia da Informação) têm se preocupado cada vez mais com a qualidade de entrega de serviços e entendem a importância que a alta disponibilidade da Tecnologia da Informação......

As empresas de TI (Tecnologia da Informação) têm se preocupado cada vez mais com a qualidade de entrega de serviços e entendem a importância que a alta disponibilidade da Tecnologia da Informação traz aos seus negócios. Desta forma, buscam soluções inovadoras e pioneiras de mercado, fazendo com que a demanda de produtividade seja atendida através de soluções com alto valor agregado, integradas, customizadas, reduzindo custos, tornando a área de Tecnologia da Informação um aliado vital ao seu negócio. Uma das formas de atingir este objetivo é implementando o gerenciamento de serviços de TI. Este trabalho mostra um estudo referente aos processos da ITIL (Information Technology Infrastructure Library) e apresenta a implementação de um sistema de Service Desk.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
5,992
On Slideshare
5,992
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
216
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. FACULDADE ALVORADA CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO Francisco David Costa de OliveiraSISDESK - Sistema de Service Desk voltado para desenvolvimento de software Orientadora: Profa. Mestra Elizabeth d’Arrochella Teixeira Brasília – DF, Dezembro de 2010
  • 2. ii FRANCISCO DAVID COSTA DE OLIVEIRASISDESK - Sistema de Service Desk voltado para desenvolvimento de software Trabalho de Conclusão de Curso apresentado à Banca Examinadora, como exigência parcial para a obtenção do título de Bacharelado em Sistemas de Informação e à Sociedade de Ensino Tecnologia, Educação e Cultura Orientadora: Profa. Mestre Elizabeth d’Arrochella Teixeira Brasília – DF, Dezembro de 2010
  • 3. iii
  • 4. ivEPÍGRAFE “Até as mais altas torres começaram do chão...” Provérbio Chinês.
  • 5. v RESUMO As empresas de TI (Tecnologia da Informação) têm se preocupado cada vezmais com a qualidade de entrega de serviços e entendem a importância que a altadisponibilidade da Tecnologia da Informação traz aos seus negócios. Desta forma,buscam soluções inovadoras e pioneiras de mercado, fazendo com que a demandade produtividade seja atendida através de soluções com alto valor agregado,integradas, customizadas, reduzindo custos, tornando a área de Tecnologia daInformação um aliado vital ao seu negócio. Uma das formas de atingir este objetivo éimplementando o gerenciamento de serviços de TI. Este trabalho mostra um estudoreferente aos processos da ITIL (Information Technology Infrastructure Library) eapresenta a implementação de um sistema de Service Desk.Palavras-Chave: ITIL. Central de Serviços. Incidente. Solicitação de Mudança.
  • 6. vi ABSTRACT IT companies have been getting concerned increasingly with quality ofservice delivery and understand the importance that the high availability ofinformation technology brings to business. Thus, they seek innovative solutions andpioneering market, causing the demand is met through productivity solutions withhigh added value, integrated, customized, reducing costs, making the area ofinformation technology a vital ally to your business. One way of achieving this goal isby implementing the management of IT services. This work shows a study related toITIL processes and shows the implementation of a system aimed at the Service Deskmanagement services.Keywords: ITIL. Service Desk. Incident. Change Request.
  • 7. vii LISTA DE FIGURASFigura 1 - Organograma da Empresa........................................................................ 18Figura 2 - Gráfico de Baleia....................................................................................... 29Figura 3 - Diagrama de Casos de Usos .................................................................... 51Figura 4 - Diagrama de Classe.................................................................................. 59Figura 5 - Modelo de Entidade e Relacionamento .................................................... 60Figura 6 - Árvore do Sistema..................................................................................... 67Figura 7 - Tela de Login ............................................................................................ 68Figura 9 - Nova Solicitação ....................................................................................... 69Figura 10 - Adicionar Solução ................................................................................... 69Figura 11 - Cadastro de Problema ............................................................................ 70Figura 12 - Cadastro de Usuário ............................................................................... 70
  • 8. viii LISTA DE TABELASTabela 1 - Cronograma ............................................................................................. 21Tabela 2 - Lista de Caso de Uso ............................................................................... 50Tabela 3 - UC01 Efetuar Login .................................................................................. 52Tabela 4 – UC2 Manter Usuário ................................................................................ 53Tabela 5 - UC03 Manter Incidente ............................................................................ 54Tabela 6 – UC04 Manter Mudança ........................................................................... 56Tabela 7 - UC05 Manter Problema............................................................................ 57Tabela 8 - SD_ANEXOINCIDENTE .......................................................................... 61Tabela 9 - SD_ANEXOMUDANCA ............................................................................ 61Tabela 10 - SD_ESTADOMUDANCA ....................................................................... 62Tabela 11 - SD_FUNCÃO ......................................................................................... 62Tabela 12 - SD_INCIDENTE ..................................................................................... 63Tabela 13 - SD_ MATRIZPRIORIDADE .................................................................... 64Tabela 14 - SD_MUDANCA ...................................................................................... 64Tabela 15 - SD_MUDANCAESTADO ....................................................................... 65Tabela 16 - SD_NIVELMUDANCA ............................................................................ 65Tabela 17 - SD_PRIORIDADE .................................................................................. 66Tabela 18 - SD_TECNICO ........................................................................................ 66Tabela 19 - SD_URGENCIA ..................................................................................... 67
  • 9. ix LISTA DE ABREVIATURASADSL Asymmetric Digital Subscriber LineAPI Application Programming InterfaceFTF Finalization Task ForceHTML Hipertext Markup LanguageIEC International Electrotechnical CommissionHTTP HiperText Transfer ProtocolIMAP Internet Message ProtocolISSO International Organization for StandardizationITIL Information Technology Infrastructure LibraryJDBC Java DataBase ConnectivityLDAP Lightweight Directory Access ProtocolODBC Open Database ConnectivityOMC Object Management GroupOOSE Object-Oriented Software EngineeringPHP HiperText PreprocessorPOP Post Office ProtocolRTF Revision Task ForceRUP Rational Unified ProcessSISDESK Sistema de Service DeskSLA Service Level AgreementTI Tecnologia da InformaçãoUML Unified Model Language
  • 10. 10 SUMÁRIO1. Introdução ........................................................................................................... 131.1. Tema................................................................................................................... 141.2. Justificativa ......................................................................................................... 141.3. Formulação do Problema.................................................................................... 151.4. Objetivos ............................................................................................................. 161.4.1. Geral ............................................................................................................ 161.4.2. Específicos ................................................................................................... 161.5. Organização do Trabalho ................................................................................... 172. Análise Institucional ............................................................................................ 182.1. Empresa e seu Negócio...................................................................................... 182.1.1. Organograma da Empresa ........................................................................... 182.2. Descrições das Necessidades ............................................................................ 192.3. Sistemas de Informação Existente na Empresa ................................................. 192.4. Normas de Funcionamento................................................................................. 192.5. Ambiente Tecnológico Existente ......................................................................... 203. Cronograma ........................................................................................................ 214. Referencial Teórico ............................................................................................. 224.1. Linguagem de Programação............................................................................... 224.1.1. Java.............................................................................................................. 224.1.2. PHP .............................................................................................................. 244.1.3. Delphi ........................................................................................................... 254.2. Banco de Dados ................................................................................................. 254.2.1. Oracle........................................................................................................... 264.2.2. PostgreSQL .................................................................................................. 264.2.3. MySQL ......................................................................................................... 274.3. RUP (Rational Unified Process) .......................................................................... 284.3.1. Desenvolvimento Iterativo ............................................................................ 284.3.2. Fases do RUP .............................................................................................. 294.3.2.1. Concepção ................................................................................................ 304.3.2.2. Elaboração ................................................................................................ 30
  • 11. 114.3.2.3. Construção................................................................................................ 314.3.2.4. Transição .................................................................................................. 314.4. UML (Unified Model Language) .......................................................................... 324.4.1. Orientação a Objetos ................................................................................... 334.4.1.1. Objetos...................................................................................................... 344.4.1.2. Classes ..................................................................................................... 344.4.1.3. Herança .................................................................................................... 354.4.1.4. Polimorfismo ............................................................................................. 354.4.1.5. Coesão...................................................................................................... 364.4.2. Diagramas .................................................................................................... 364.4.2.1. Diagramas de Classes .............................................................................. 374.4.2.2. Diagramas de Colaboração ...................................................................... 374.4.2.3. Diagramas de Objetos .............................................................................. 374.4.2.4. Diagramas de Componentes .................................................................... 384.4.2.5. Diagramas de Caso de Uso ...................................................................... 384.4.2.6. Diagramas de Seqüência .......................................................................... 394.4.2.7. Diagramas de Atividade ............................................................................ 394.4.2.8. Diagramas de Interação ............................................................................ 404.4.2.9. Diagramas de Implantação ....................................................................... 404.4.2.10. Diagramas de Gráfico de Estados ......................................................... 414.5. Information Technology Infrastructure Library - ITIL ........................................... 414.5.1. Central de Serviços (Service Desk).............................................................. 424.5.2. Gerenciamento de Incidentes ...................................................................... 434.5.3. Gerenciamento de Problema ....................................................................... 434.5.4. Gerenciamento de Nível de Serviço ............................................................. 444.6. ISO/IEC 20.000 ................................................................................................... 445. Proposta do Novo Sistema ................................................................................. 465.1. Descrição do Sistema Proposto .......................................................................... 465.2. Resultados Esperados ........................................................................................ 475.3. Restrições do Sistema Proposto ......................................................................... 475.4. Resultados Esperados ........................................................................................ 475.5. Áreas Afetadas Pelo Novo Sistema .................................................................... 485.6. Banco de Dados ................................................................................................. 48
  • 12. 126. Documentação de Análise .................................................................................. 496.1. Visão Macro dos Atores ...................................................................................... 496.2. Identificação dos Atores...................................................................................... 496.3. Lista dos Casos de Uso ...................................................................................... 506.4. Diagrama de Caso de Uso.................................................................................. 516.5. Descrição Detalhada dos Casos de Uso ............................................................ 526.6. Diagrama de Classes.......................................................................................... 596.7. Modelo de Entidade e Relacionamento .............................................................. 606.8. Especificação das Tabelas ................................................................................. 616.8.1. Tabela SD_ANEXOINCIDENTE .................................................................. 616.8.2. Tabela SD_ANEXOMUDANCA .................................................................... 616.8.3. Tabela SD_ESTADOMUDANCA ................................................................. 626.8.4. Tabela SD_FUNCAO ................................................................................... 626.8.5. TABELA SD_IMPACTO ............................................................................... 636.8.6. Tabela SD_INCIDENTE ............................................................................... 636.8.7. Tabela SD_MATRIZPRIORIDADE ............................................................... 646.8.8. Tabela SD_MUDANCA ................................................................................ 646.8.9. Tabela SD_MUDANCAESTADO ................................................................. 656.8.10. Tabela SD_NIVELMUDANCA ................................................................... 656.8.11. Tabela SD_PRIORIDADE ......................................................................... 656.8.12. Tabela SD_TECNICO ............................................................................... 666.8.13. Tabela SD_URGENCIA ............................................................................ 676.9. Árvore do Sistema .............................................................................................. 676.10. Especificações Físicas ................................................................................. 686.10.1. Layout das Principais Telas da Aplicação ................................................. 686.11. Help on-line .................................................................................................. 716.12. Segurança Física e Lógica ........................................................................... 716.12.1. Norma de Segurança Física ..................................................................... 716.12.2. Norma de Segurança Lógica .................................................................... 717. Plano de Implantação ......................................................................................... 738. Conclusão ........................................................................................................... 749. Referencias Bibliográficas .................................................................................. 75
  • 13. 131. Introdução Segundo MAGALHÃES e PINHEIRO (2007), a cada dia que passa, asorganizações tornam-se mais dependentes da Tecnologia da Informação a fim desatisfazer seus objetivos estratégicos e para atender às necessidades do negócioem que atuam. Uma área de TI (Tecnologia da Informação) que não considerar osobjetivos estratégicos da organização em que se insere como os seus própriosobjetivos, será uma área de TI que deseja apenas ser um simples provedor detecnologia, haja vista que até mesmo os provedores de tecnologia, atualmente,tendem a preocupar-se com a estratégia de negócio de seus clientes, condiçãobásica para a venda de serviços sob demanda. Ainda segundo MAGALHÃES e PINHEIRO (2007), o Gerenciamento deServiços de Tecnologia da Informação é o instrumento pelo qual a área pode iniciara adoção de uma postura pró-ativa em relação ao atendimento das necessidades daorganização, contribuindo para evidenciar a sua participação na geração de valor. OGerenciamento de Serviço de TI visa alocar adequadamente os recursos disponíveise gerenciá-los de forma integrada, fazendo com que a qualidade do conjunto sejapercebida pelos seus clientes e usuários, evitando-se a ocorrência de problemas naentrega e na operação dos serviços de Tecnologia da Informação. Para MAGALHÃES e PINHEIRO (2007), organizações consideradas líderesem suas indústrias estão deixando de ser organizações puramente focadas emcusto para se tornarem organizações focadas em valor. Isto pode ser constatadopela atual prática da troca dos indicadores de desempenho derivados da estratégiada organização e que permitem a monitoração do desempenho na execução de suaestratégia, a partir de diversas perspectivas, além da financeira, tradicionalmenteutilizada. Hoje, as organizações já estão mais maduras e tomam decisões que levamem conta não apenas custo, mas a criticidade de cada processo da área de TI paraa geração de valor para a organização. O Gerenciamento de Serviço de TI é, deforma resumida, o gerenciamento da integração entre pessoas, processos etecnologias, componentes de um serviço de TI focados nas necessidades dosclientes e de modo alinhado à estratégia de negócio da organização, visando o
  • 14. 14alcance de objetivos de custos e desempenho pelo estabelecimento de acordos denível de serviço entre a área de TI e as demais áreas de negócio da organização. MAGALHÃES e PINHEIRO (2007) ainda afirmam que a ITIL (InformationTechnology Infrastructure Library), criada a partir da necessidade de padronizar osprocessos da área de TI visando à terceirização, baseia-se na experiência coletivade inúmeros praticantes do Gerenciamento de Serviços de TI de organizaçõesprivadas e públicas de todo o mundo. Esta é a razão pela qual vem se tornando umpadrão na área de Gerenciamento de Serviços de TI, adotada por organizações-líderes em seus segmentos de atuação em escala mundial. A eficiência, a eficácia, aefetividade e a economicidade no suporte aos serviços de TI são fatores críticospara o sucesso no alcance dos objetivos estratégicos traçados pela organização. 1.1. Tema O Sistema de Service Desk (SISDESK) é um sistema que atua como pontoúnico de contato entre o provedor de serviços de TI e os clientes, onde sãocadastrados incidentes e solicitações de mudanças, possibilitando assim, um melhorgerenciamento dos serviços de TI. 1.2. Justificativa Conforme MAGALHÃES e PINHEIRO (2007), a Central de Serviços é umafunção e não um processo, essencial para a implementação do Gerenciamento deServiços de TI. Mais do que um ponto de suporte aos usuários, a Central deServiços é a principal interface entre a área de TI e os usuários dos seus serviços.Ela é responsável pela primeira impressão que a área de TI dará aos seus usuáriosquando da necessidade de interação, quer seja para a solicitação de um serviço ouesclarecimento sobre o modo de interação com o serviço de TI ou para comunicaçãode um erro. As normas internacionais relacionadas com a Gestão de Serviços de TIpermitem a colaboração de organizações internacionais e fornecem diretrizes
  • 15. 15valiosas que contribuem para o estabelecimento da credibilidade das empresas. AISO (International Organization for Standardization) 20.000, permite a umaorganização demonstrar aos seus clientes e investidores que opera com integridadenegocial e segurança, e que promove uma cultura de melhoramento contínuo daqualidade no âmbito da Gestão de Serviços de TI [1]. Com intuito de implementar a ISO 20.000 para um melhor gerenciamento deseus serviços de TI e fornecer um atendimento de qualidade às solicitações dosclientes, a empresa Dave Systems (Empresa Fictícia) necessita de uma ferramentade apoio gerencial de serviços de TI que incremente velocidade ao atendimento emelhore o suporte aos usuários de seus serviços. Para esse fim, o sistemaSISDESK será desenvolvido de forma a suprir estas necessidades. Em um futuro próximo, a empresa Dave Systems (Empresa Fictícia) estudaa possibilidade de aquisição da certificação ISO 20.000, e utilizar o SISDESK comoferramenta de apoio para obtenção e manutenção da certificação ISO 20.000. 1.3. Formulação do Problema O controle dos incidentes gerados pelos sistemas desenvolvidos pela DaveSystems (Empresa Fictícia) são cadastrados em um sistema desenvolvida pelamesma chamada Help. No Help são cadastrados os chamados para correção ousolicitação de mudança no sistema, permitindo o acompanhamento da demanda e avisualização na íntegra de todos os envolvidos no chamado. Porém, para o intuito daempresa Dave Systems, que é viabilizar a entrega e o suporte de serviços focadosnas necessidades dos clientes, a empresa percebeu que sua ferramenta de controlede incidentes, o Help, não atendia às suas exigências. O Help não possui relatóriospara geração de métricas, o que dificulta as tomadas de decisões para determinadosassuntos gerenciais. A base de dados possui dados inconsistentes, o que geraconflitos de informações para os usuários. Outra falha grave do sistema, é que omesmo permite que técnicos, que receberam um chamado para resolução de umincidente, tenham privilégios para encaminhar a demanda para outros técnicos semantes retorná-la para o Analista do Incidente, que é o dono do chamado, com o
  • 16. 16motivo pelo qual o mesmo foi devolvido. Dessa forma perde-se o controle sobre oincidente podendo ficar dias tramitando entre técnicos sem nenhuma soluçãoimplementada para o problema. Com o atual sistema, algumas demandas com grau de dificuldade alta sãodeixadas de lado para que outras demandas de nível de dificuldade menor sejamimplementadas. Dessa forma, algumas solicitações demoram mais do que o previstopara serem executadas e, conseqüentemente, atrasando a resolução dassolicitações e gerando insatisfação por parte do cliente. 1.4. Objetivos Logo abaixo estão descritos os objetivos a serem alcançados pelo sistemaproposto, obtendo uma visão tanto de forma macro como de forma específica deseus objetivos. 1.4.1. Geral Desenvolver um sistema que facilite o controle das solicitações para agilizaro restabelecimento da operação normal dos serviços dentro do SLA (Service LevelAgreement) definido com o cliente, minimizando o impacto nos negócios causadospor falhas de TI e o atendimento de possíveis mudanças a serem realizadas nosserviços prestados pela empresa. 1.4.2. Específicos Fornecer um ponto único com a área de TI para os clientes dos serviços deTI; Prover um suporte técnico para o atendimento das solicitações cadastradas pelosclientes da empresa; Ajudar a identificar e a reduzir o custo de propriedade dosserviços prestados; Gerar indicadores gerenciais para o auxilio de tomadas dedecisão;
  • 17. 17 1.5. Organização do Trabalho Abaixo está descrita a forma como o trabalho está organizado: O capítulo 1 descreve de uma forma geral o tema proposto e a justificativada escolha do tema e o problema que a ser resolvido. O capítulo 2 faz referência à instituição para a qual será destinada aimplementação do sistema contendo o organograma da empresa, as necessidadesdo sistema e o ambiente tecnológico existente. O capítulo 3 descreve todo o cronograma das atividades realizadas nodesenvolvimento do projeto. O capítulo 4 descreve o referencial teórico das tecnologias utilizadas nodesenvolvimento do projeto. O capítulo 5 faz referência ao sistema proposto, resultados esperados,restrições do sistema e as áreas afetadas pelo sistema. O capítulo 6 descreve a documentação de análise do projeto, assim como avisão macro dos atores, identificação dos atores, lista de casos de uso e diagramade caso de uso. O capítulo 7 descreve a forma como será implantado o sistema. O capítulo 8 descreve a conclusão do trabalho realizado. O capítulo 9 descreve todo o referencial teórico utilizada no desenvolvimentodo trabalho realizado.
  • 18. 182. Análise Institucional 2.1. Empresa e seu Negócio A empresa Dave Systems (Empresa Fictícia) foi fundada em 1982 comintuito de atender com qualidade e eficiência uma área carente dentro daadministração pública, porém fundamental para boa gestão do dinheiro público. Nodecorrer desses anos tornou-se líder nacional no desenvolvimento e implantação desoluções de gestão de materiais e de patrimônio. A empresa, desde o princípio,preocupou-se em trazer inovações para o mercado de tecnologia da informação. Asolução de gestão oferecida pela Dave Systems, inclui ainda todo o serviço deverificação e consistência da base de dados, ou seja, o levantamento in loco (nolugar) dos bens permanentes dos órgãos, com metodologia e equipe especializada. 2.1.1. Organograma da Empresa Logo abaixo é mostrado o organograma geral da Dave Systems (EmpresaFictícia). Figura 1 - Organograma da Empresa
  • 19. 19 2.2. Descrições das Necessidades A empresa carece de um controle sobre as solicitações demandadas à suafábrica de software fazendo com que os gerentes das equipes de desenvolvimentopercam muito tempo em análises de chamados para levantamento de dados que osdê suporte à geração de indicadores e métricas. Atualmente o sistema que controla as atividades de desenvolvimento deserviços prestados pela empresa, não contempla de forma eficiente e eficaz asnecessidades da mesma, realizando apenas o cadastro de demandas, atribuição dademanda ao colaborador que desenvolverá o trabalho e finalização do chamadoquando a demanda estiver implementada. Para suprir as necessidades da empresa Dave Systems (Empresa Fictícia),o Sistema de Service Desk (SISDESK) será desenvolvido baseado nas melhorespráticas de gestão de serviço da Information Technology Infrastructure Library (ITIL),com a atenção voltada para a obtenção da certificação ISO 20.000. 2.3. Sistemas de Informação Existente na Empresa A empresa Dave Systems (Empresa Fictícia) desenvolveu o sistema ASI quetem por finalidade propiciar realização do inventário dos bens móveis por meio deum aparelho de leitura óptica de código de barras possibilitando o armazenamentodos dados coletados no sistema desenvolvido. 2.4. Normas de Funcionamento Para que se possa fazer uso do sistema, há algumas exigências a seremconsiderados: o usuário deverá possuir cadastro na intranet local; o usuário deverápossuir login no sistema; o usuário deverá possuir nível de acesso previamentecadastrado; O deverá passar por treinamento para que possa interagir de formacorreta com as diversas situações do sistema.
  • 20. 20 2.5. Ambiente Tecnológico Existente Em sua estrutura, a Dave Systems (Empresa Fictícia) possui em torno de180 computadores sendo 25 servidores, desde firewall à máquina de backup e 30servidores virtualizados. A rede é mista com wireless, cabeamento estruturado eligação via fibra óptica. Os servidores de aplicação utilizam o sistema operacionalLinux e os servidores de banco de dados utilizam o sistema operacional Windows. Ofirewall utilizado é baseado em Freebsd (Freebsd é um sistema operacional livre dotipo unix) e o controlador de domínio é o OPENLDAP (OPENLDAP é um softwarelivre de código aberto que implementa o protocolo de rede LDAP). Conta cominternet ADSL (Asymmetric Digital Subscriber Line) disponibilizada 24 horas por diae 7 dias por semana, possui sala para treinamentos e departamento para digitalizare imprimir documentos.
  • 21. 213. Cronograma O cronograma é a disposição gráfica do tempo que será gasto na realizaçãode um trabalho ou projeto, de acordo com as atividades a serem cumpridas. Servepara auxiliar no gerenciamento e controle das atividades, permitindo de forma rápidaa visualização de seu andamento [2]. Abaixo o cronograma do planejamento utilizado no desenvolvimento dosistema. Tabela 1 - Cronograma ETAPAS MAR/10 ABR/10 MAI/10 JUN/10 JUL/10 AGO/10 SET/10 OUT/10 NOV/10 DEZ/10Definição doProblemaDelimitação doTemaPesquisaBibliográficaLevantamentoTeóricoDefinição dametodologiaPlanejamentode açõesLevantamentode RequisitosAnálise (def.casos de uso)Escrever amonografiaProjetoImplementaçãoImplantaçãoApresentaçãoda monografiaAcertos apósapresentaçãoEntrega final
  • 22. 224. Referencial Teórico Para o desenvolvimento deste trabalho foram estudados os conceitos emRUP (Rational Unified Process) para os processos de engenharia de software e aUML (Unified Modeling Language) para a modelagem do sistema. A Linguagem deProgramação Java, foi utilizada para desenvolvimento do sistema. Em relação aogerenciamento de serviço, ITIL (Information Technology Infrastructure Library) foiestudada e implantada nesse trabalho. O Oracle Express foi escolhido como a basede dados do sistema. 4.1. Linguagem de Programação ANDRADRE (2007) define que o computador é uma super calculadora,capaz de realizar cálculos muito mais rápido do que humanos, mas para issodevemos dizer para o computador o que deve ser calculado e como deve sercalculado. Os computadores interpretam tudo como números em base binária, ouseja, só entendem zero e um, tornando assim as linguagens de programação ummeio de comunicação inteligível entre computadores e humanos. Logo abaixo, teremos uma abordagem sobre algumas linguagens deprogramação utilizadas no setor de informática atualmente. 4.1.1. Java Segundo DEITEL H. e DEITEL P. (2005) os microprocessadores têm umimpacto profundo em dispositivos inteligentes eletrônicos voltados para oconsumidor. Reconhecendo isso, a Sun Microsystems, financiou um projeto depesquisa corporativa interna com o codinome Green, que resultou nodesenvolvimento de uma linguagem baseada em C++ que seu criador o chamou deOak e que posteriormente foi trocado para Java. A Sun anunciou o Javaformalmente em 1995 em uma importante conferência em maio de 1995. Java é umalinguagem orientada a objeto, independente de plataforma e segura. A programaçãoorientada a objeto é uma metodologia de desenvolvimento de software que um
  • 23. 23programa é percebido como um grupo de objetos que trabalham juntos. Javadisponibiliza a concorrência para o programador de aplicativos por meio de suasAPIs (Application Programming Interface). O programador especifica os aplicativosque contêm threads de execução, em que cada thread designa uma parte de umprograma que pode executar concorrentemente com outras threads. Essacapacidade, chamada multithreading, fornece capacidades poderosas para oprogramador de Java. Conforme CADENHEAD e LEMAY (2005). Java permite a neutralidade deplataforma, que significa a capacidade de um programa executar sem modificaçõesem diferentes ambientes de computação. Os programas Java são compilados paraum formato chamado bytecode, que é executado por qualquer sistema operacional,softwares ou qualquer dispositivo com interpretador Java. O Windows, Solaris, Linuxe Apple Macintosh. Com Java podemos também, desenvolver programas para executar emnavegadores e serviços da Web, desenvolver aplicativos no lado servidor, combinaraplicativos ou serviço para criar outros aplicativos altamente personalizados, entreoutras vantagens [3]. Para GONÇALVES (2007), trabalhar com banco de dados em aplicaçõesWeb é um fato muito comum no desenvolvimento de um sistema. O Java possuiuma API chamada JDBC (Java DataBase Connectivity) que consiste em umconjunto de classes e interfaces escritas em Java que oferecem um suportecompleto para programação com banco de dados. Por ser escrita em Java, a APIJDBC também independe de plataforma para a sua utilização. Ainda segundo GONÇALVES (2007), as bibliotecas da linguagem Javacontêm várias classes que implementam diversos mecanismos de entrada e saída,acesso à Internet, manipulação de strings em alto nível, poderosas estruturas de
  • 24. 24dados, utilitários diversos e um conjunto completo de classes para implementaçãode interfaces gráficas. A documentação da linguagem, chamada Javadoc, estádisponível gratuitamente e possui um padrão de organização estruturada comodocumento HTML (Hipertext Markup Language). Os desenvolvedores de frameworkse componentes costumam utilizar este padrão de documentação para documentarseus códigos. Isto facilita em muito tanto o trabalho em equipe quanto a reutilizaçãode código de terceiros em outras implementações. Além disto, junto com ocompilador Java vem um aplicativo para geração de JavaDoc do código que vocêacabou de implementar. Por ser uma linguagem que possui neutralidade, segurança, conexão comos principais bancos de dados do mercado, documentação da linguagem e sermultitarefa, Java foi escolhido como a linguagem de programação a ser utilizada nodesenvolvimento do SISDESK. 4.1.2. PHP Segundo CONVERSE e PARK (2001), PHP é uma linguagem de criação descripts com código-fonte aberto embutido em HTML do lado do servidor da Web,compatível com os mais importantes servidores da Web. PHP significa: HypertextPreprocessor (pré-processador de hipertexto), originalmente chamado de PersonalHome Page Tools. O PHP permite embutir fragmentos de códigos em páginasnormais de HTML – código que é interpretado como suas páginas e fornecido ausuários. É uma linguagem que suporta as funcionalidades para definir classes eobjetos, tornando-se assim orientada a objetos. Ainda segundo Converse e Park, o PHP é executado de forma nativa emcada versão no UNIX e Windows. Também é compatível com os importantesservidores da Web como o HTTP Apache para UNIX Windows, Microsoft InternetInformation Server e Netscape. O PHP não é suportado na plataforma Macintosh.Dessa forma, a linguagem de programação não pode ser considerada umalinguagem multi-plataforma.
  • 25. 25 A conectividade de banco de dados é especialmente forte, com suporte deunidade nativa para a maioria dos bancos de dados, além do ODBC. Suportatambém, um número grande de protocolos importantes como POP3, IMAP, LDAP. 4.1.3. Delphi Segundo SWAN (1997), o Delphi é uma linguagem de programação paraaplicativos rápidos, adequado para criação de protótipos do Windows e aplicativosprofissionais que competem em velocidade e eficiência. Delphi inclui poderososrecursos orientados a objeto, sem tornar a linguagem muito complicada, permite acriação de aplicações para sistemas operacionais, como templates e experts deaplicações e formulários, que aumentam muito a produtividade. Possuem classes eobjetos, tratamento de exceções, programação multithread, programação modular evínculo dinâmico e estático. Como dito anteriormente, Delphi é uma linguagem de programação modulare o módulo básico é denominado unidade. Para compilar um programa em Delphi, épreciso um arquivo-fonte de programa e quaisquer unidades adicionais na forma defonte ou objeto. Conforme LISCHNER (2000) Delphi possui três variedades de diretivas decompilador: chaves, parâmetro e compilação condicional. Uma chave é um flagBooleano: Um recurso pode estar ativado ou desativado. Um parâmetro ofereceinformações, como um nome de arquivo ou o tamanho da pilha. A compilaçãocondicional lhe permite definir condições e compilar seletivamente partes de umarquivo-fonte dependendo das condições definidas. Um programa em Delphi ésemelhante a um programa do Pascal tradicional, no entanto, os programas emDelphi são curtos, pois o trabalho real ocorre em uma ou mais unidades separadas. 4.2. Banco de Dados Segundo DEITEL H. e DEITEL P. (2005), um banco de dados é uma coleçãoorganizada de dados. Um sistema de gerenciamento de banco de dados fornece
  • 26. 26mecanismos para armazenar, organizar, recuperar e modificar dados para muitosusuários 4.2.1. Oracle Segundo ABBEY, COREY, ABRAMSON (2000), o Oracle é um repositóriopara volumes de dados muito grande e fornece aos usuários um acesso rápido aesses dados. Possui o particionador de dados que consiste em dividir grandesvolumes mais gerenciáveis e reunidos de forma transparente quando os sistemasfuncionam e as sessões de usuário processam consultas. O Oracle fornece aintegridade de dados, ou seja, se, enquanto um usuário está alterando dados dentrode um banco de dados, uma falha de qualquer espécie ocorrer, o banco de dadostem a capacidade de desfazer ou retroceder qualquer operação suspeita. Ossofisticados mecanismos de segurança controlam o acesso de dados sigilososatravés do uso de uma variedade de privilégios. Os usuários recebem direitos paraver, modificar e criar dados de acordo com os nomes que usam para se conectarcom o banco de dados. A empresa Oracle lançou em novembro de 2005, a uma nova edição doOracle, o Oracle Express Edition 10g. Trata-se de uma versão gratuita que possui omesmo "núcleo" das demais versões, ou seja, uma aplicação que roda na versão doOracle Database Standard Edition Server release 2, sua aplicação também iráfuncionar com Oracle Express Edition 10g. Por ser compatível com toda a família deprodutos do Oracle, ele permite aos usuários a facilidade de começar com umasolução básica e ir mudando para outras versões quando necessário. Permite aindaque os desenvolvedores tirem total proveito do Oracle Application Express pararápido desenvolvimento e implementação de aplicativos baseados na Web. [4] 4.2.2. PostgreSQL O PostgreSQL é um poderoso sistema gerenciador de banco de dadosobjeto-relacional de código aberto. É executado em todos os grandes sistemasoperacionais, incluindo Linux e Windows. É totalmente compatível com ACID, tem
  • 27. 27suporte completo a chaves estrangeiras, junções, visões, gatilhos e procedimentosarmazenados. Inclui a maior parte dos tipos de dados do ISO SQL:1999, incluindoINTEGER, NUMERIC, BOOLEAN, CHAR, VARCHAR, DATE, INTERVAL, eTIMESTAMP. Suporta também o armazenamento de objetos binários, incluindofiguras, sons ou vídeos [5]. Como um banco de dados de nível corporativo, o PostgreSQL; possuifuncionalidades sofisticadas como o controle de concorrência multiversionado,recuperação em um ponto no tempo, tablespaces, replicação assíncrona,transações agrupadas, cópias de segurança, um sofisticado planejador de consultase registrador de transações seqüencial para tolerância a falhas. Suporta conjuntosde caracteres internacionais, codificação de caracteres multibyte, Unicode e suaordenação por localização, sensibilidade a caixa (maiúsculas e minúsculas) eformatação. PostgreSQL é altamente escalável, tanto na quantidade enorme dedados que pode gerenciar, quanto no número de usuários concorrentes que podeacomodar. Existem sistemas ativos com o PostgreSQL em ambiente de produçãoque gerenciam mais de 4TB de dados [5]. O código fonte do PostgreSQL está disponível sob a licença de fonte abertamais liberal: a licença BSD. 4.2.3. MySQL Segundo SANTOS (2005) MySQL é um banco de dados relacional,desenvolvido para plataformas Linux–like, OS/2, Windows. Sendo um software delivre distribuição para plataformas não-Windows que o utilizam em um servidor Web. Ainda segundo SANTOS (2005) o MySQL é um servidor multiusuário,multitarefa, compatível com o padrão SQL, linguagem essa amplamente utilizadapara manipulação de dados em RDBMS (Banco de dados Relacionais), sendoconsiderada um ferramenta de manipulação de base de dados de tamanhomoderado. A principais características que destacam MySQL são: sua velocidade
  • 28. 28proporcionada pela sua implementação leve que não inclui na totalidade o suporteas instruções SQL; sua natureza de distribuição gratuita; facilidade de integraçãocom servidor Web e linguagens de programação de desenvolvimento de sitesdinâmico. 4.3. RUP (Rational Unified Process) Para KRUCHTEN (2003), o Rational Unified Process (também chamado deprocesso RUP) é um processo de engenharia de software. Ele oferece umaabordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentrode uma organização de desenvolvimento. Sua meta é garantir a produção desoftware de alta qualidade que atenda às necessidades dos usuários dentro de umcronograma e de um orçamento previsíveis. Amadureceu durante os anos, e refletea experiência coletiva das muitas pessoas e companhias que hoje compões a ricaherança da Rational Software. O RUP incorpora mais material nas áreas deengenharia de dados, modelagem de negócio, gerenciamento de projeto egerenciamento de configuração, o último como resultado de uma fusão com Pure-Atria. KRUCHTEN (2003) ainda afirma que o RUP fornece uma abordagemdisciplinada para assumir tarefas e responsabilidades dentro de uma organização dedesenvolvimento. Seu objetivo é assegurar a produção de software de alta qualidadeque satisfaça as necessidades de seus usuários finais dentro de prazo e orçamentoprevisíveis. Pode ser adaptada e estendida para compor as necessidades de umaorganização que o esteja adotando. 4.3.1. Desenvolvimento Iterativo Um projeto que usa o desenvolvimento iterativo tem um ciclo de vida queconsiste em várias iterações. Uma iteração incorpora um conjunto quase seqüencialde atividades em modelagem de negócios, requisitos, análise e design,implementação, teste e implantação, em várias proporções, dependendo do local emque ela está localizada no ciclo de desenvolvimento. As iterações nas fases de
  • 29. 29iniciação e de elaboração se concentram nas atividades de gerenciamento,requisitos e design. As iterações na fase de construção se concentram no design, naimplementação e no teste. E as iterações na fase de transição e concentram no testee na implantação. O gerenciamento das iterações deve ser do tipo timebox, isto é, aprogramação de uma iteração deve ser considerada fixa e o escopo do conteúdo daiteração gerenciado ativamente para atender a essa programação [6]. 4.3.2. Fases do RUP KRUTCHEN (2003) explica que a partir de uma perspectiva degerenciamento, o ciclo de vida de software do Rational Unified Process (RUP) édividido em quatro fases seqüenciais, cada uma concluída por um marco principal,ou seja, cada fase é basicamente um intervalo de tempo entre dois marcosprincipais. Logo abaixo, é exibido o gráfico de baleias, onde é mostrado verticalmenteas disciplinas do desenvolvimento de software. Nas colunas, são mostradas as fasese o esforço em cada uma delas. Figura 2 - Gráfico de Baleia
  • 30. 30 4.3.2.1. Concepção Para KRUCHTEN (2003) na fase de concepção, o foco está em entender osrequisitos globais e determinar a extensão do esforço de desenvolvimento. Paraprojetos que visam melhorias em um sistema existente, a fase de iniciação é maisrápida, mas ainda se concentra em assegurar que o projeto seja compensatório eque seja possível fazê-lo. Dentre as atividades da fase de concepção, devemos formular a extensãodo projeto, que quer dizer, captar o contexto e os requisitos mais importantes erestrições de forma que possa derivar critérios de aceitação para o produto final.Outra atividade é planejar e preparar um caso de uso de negócio e avaliaralternativas para gerenciamento de risco, fornecendo pessoal, plano de projeto eintercâmbio entre custo, prazo e rentabilidade. E por fim, KRUCHTEN (2003) explicaque se deve sintetizar uma arquitetura candidata, avaliar intercâmbios em projeto eavaliar decisões de fazer/comprar/reutilizar, de forma que custo, prazo e recursospossam ser calculados. 4.3.2.2. Elaboração A meta da fase de elaboração é criar a baseline para a arquitetura dosistema, desenvolver o plano de projeto e eliminar os elementos de alto risco doprojeto, a fim de fornecer uma base estável para o esforço da fase de construção.Na fase de elaboração, um protótipo executável de arquitetura é construído em umaou mais iterações dependendo da extensão, tamanho, risco e novidade do projetoprogramação [6]. Na fase de elaboração, um protótipo executável de arquitetura é construídoem uma ou mais iterações, dependendo da extensão, tamanho risco e novidade doprojeto. No mínimo, este esforço deveria endereçar os casos de uso críticosidentificados na fase de concepção, que tipicamente expõe os riscos técnicosprincipais do projeto.
  • 31. 31 Embora um protótipo evolutivo de um componente de qualidade de produçãosempre seja a meta, isto não exclui o desenvolvimento de um ou mais protótipos depropaganda para mitigar um determinado risco ou explorar alguns intercâmbios entreprojeto e requisitos. Nem é regra um estudo de viabilidade ou demonstrações ainvestidores, clientes e usuários finais. Conforme KRUCHTEN (2003) os objetivos primários da fase de elaboraçãosão: definir, validar e delinear a arquitetura tão rápida quanto possível de serrealizada; delinear a visão; delinear um plano de alta-fidelidade para a fase deconstrução; demonstrar que a arquitetura de linha de base suportará esta visão, aum custo razoável num tempo razoável. 4.3.2.3. Construção KRUCHTEN (2003) explica que durante a fase de construção, todos oscomponentes restantes e características da aplicação são desenvolvidos eintegrados ao produto, e todas as características são completamente testadas. Afase de construção é, de certo modo, um processo industrial no qual é colocadaênfase em gerenciar recursos e controlar operações para aperfeiçoar custos, prazose qualidade. Muitos projetos são grandes o suficiente para que sejam geradosincrementos de construção paralelos. Estas atividades paralelas podem apressarsignificativamente a disponibilidade de lançamentos de desenvolvimentos; elestambém podem aumentar a complexidade de gerenciamento de recurso esincronização de fluxo. Os objetivos primários da fase de construção incluem:minimizar custos de desenvolvimento e aperfeiçoando recursos; Alcançar aqualidade adequada tão rápida quanto possível de ser realizada. 4.3.2.4. Transição O foco da Fase de Transição é assegurar que o software esteja disponívelpara seus usuários finais. A Fase de Transição pode atravessar várias iterações e
  • 32. 32inclui testar o produto em preparação para release e ajustes pequenos com base nofeedback do usuário. Nesse momento do ciclo de vida, o feedback do usuário devepriorizar o ajuste fino do produto, a configuração, a instalação e os problemas deusabilidade; todos os problemas estruturais mais graves devem ter sido trabalhadomuito antes no ciclo de vida do projeto. No fim do ciclo de vida da Fase deTransição, os objetivos devem ter sido atendidos e o projeto deve estar em umaposição para fechamento. Em alguns casos, o fim do ciclo de vida atual podecoincidir com o início de outro ciclo de vida no mesmo produto, conduzindo à novageração ou versão do produto. Para outros projetos, o fim da Transição podecoincidir com uma liberação total dos artefatos a terceiros que poderão serresponsáveis pela operação, manutenção e melhorias no sistema liberado [6]. Essa Fase de Transição pode ser muito fácil ou muito complexa,dependendo do tipo de produto. Um novo release de um produto de mesa existentepode ser muito simples, ao passo que a substituição do sistema de controle dotráfego aéreo de um país pode ser excessivamente complexa. 4.4. UML (Unified Model Language) Conforme BOOCH, RUMBAUGH e JACOBSON (2005) os esforços paracriação da UML se iniciaram oficialmente em outubro de 1994, quando Rumbaughse juntou a Booch na Rational. O foco inicial do projeto era a unificação dos métodosBooch e OMT(Object Modeling Technique). O esboço da versão 0.8 do MétodoUnificado (como então era chamado) foi lançado em lançado em outubro de 1995.Na mesma época Jacobson se associou à Rational e o escopo do projeto da UML foiexpandido com a finalidade de incorporar o OOSE (Object-Oriented SoftwareEngineering). Por vários anos, a manutenção da UML foi assumida pela RTF(Revision Task Force) do OMG (Object Management Group), que produziu asversões 1.3, 1.4 e 1.5. De 2000 a 2003, um novo e maior grupo de parceirosproduziu e atualizou a especificação da UML, versão 2.0. A versão foi revista por umFTF (Finalization Task Force) coordenada por Bran Selic, da empresa IBM, e aversão oficial da UML 2.0 foi adotada pelo OMG no início de 2005.
  • 33. 33 BOOCH, RUMBAUGH e JACOBSON (2005) explicam que a UML é umalinguagem-padrão para a elaboração da estrutura de projetos de software. Elapoderá ser empregada para a visualização, a especificação, a construção e adocumentação de artefatos que façam uso de sistemas complexos de software. AUML é adequada para a modelagem de sistemas, cuja abrangência poderá incluirsistemas de informação coorporativos a serem distribuídos a aplicações em Web eaté sistemas complexos embutidos de tempo real. Segundo Furlan (1998), a UML éa linguagem padrão para especificar, visualizar, documentar e construir artefatos deum sistema e pode ser utilizada com todos os processos ao longo do ciclo dedesenvolvimento e através de diferentes tecnologias de implementação. 4.4.1. Orientação a Objetos Segundo MATOS (2003), a proposta da orientação à objetos é permitir queos programadores organizem os programas da mesma forma que nossas mentesenxergam os problemas: não como um conjunto de espaços de memória, mas comoum conjunto de coisas que fazem parte do problema. O interessante neste ponto devista é que o programador não será mais obrigado a abstrair do problema variáveis esuas respectivas organizações, mas imaginar o problema como um grande conjuntode objetos. Dessa forma é necessário haver uma modificação na maneira comoenxergamos os programas. Não é permitido neste paradigma, orientar a solução dosproblemas de acordo com as funções identificadas no problema, mas de acordo como que existe no escopo do problema: objetos. FURLAN (1998), afirma que um objeto é uma ocorrência específica(instância) de uma classe e é similar a uma entidade no modelo relacional somenteaté o ponto onde representa uma coleção de dados relacionados com um tema emcomum. Furlan, explica ainda que a tecnologia de objetos oferece modularidade deseus elementos podendo-se tornar um subconjunto existente e integrá-lo de umamaneira diferente em outra parte do sistema. Objetos permitem ser combinados ouutilizados separadamente, pois, em tese, apresentam baixa dependência externa ealta coesão interna de seus componentes, o que permite promover substituiçõessem afetar interconexões ou interferir com a operação dos demais objetos.
  • 34. 34 4.4.1.1. Objetos Segundo FURLAN (1998) do ponto de vista de abstração, os objetos tentamnão separar o que até então vinha sendo separado: dados e funções. Um objeto éuma entidade concreta, apesar de ser uma concepção abstrata. Trata-se de umagrupamento de características e ações desta entidade. Essas características sãoagrupadas de forma que possamos identificar outros objetos parecidos. Por outrolado, suas ações ajudam também a classificar outras entidades como objetossemelhantes a ele. PENDER (2004) define objeto como a representação de uma entidadeespecífica no mundo real. Diz também que, pode ser uma entidade física ouintangível, com os propósitos de promover o entendimento do mundo real e suportaruma base prática para uma implementação computacional. 4.4.1.2. Classes Segundo PAGE-JONES (2000), uma classe é uma estrutura a partir do qualsão criados objetos. Cada objeto tem a mesma estrutura e comportamento da classena qual ele teve origem. SANTOS (2003) define que classes são estruturas orientadas a objeto paraconter, para um determinado modelo, os dados que devem ser representados e asoperações que devem ser efetuadas com estes dados. Classes são escritas com osrecursos e regras para implementação dos modelos, mas em muitos casos asclasses são somente moldes ou formas que representam os modelos abstratamente.Um objeto ou uma instância é uma materialização da classe, e assim pode serusado para representar e executar operações. Para que dados ou instânciaspossam ser manipulados, é necessária a criação de referências a estes objetos, quesão basicamente variáveis do tipo de classe. Conforme SANTOS (2003), os dados contidos em uma classe sãoconhecidos como campos ou atributos daquela classe. Cada campo deve ter um
  • 35. 35nome e ser de um tipo. Valores contidos dentro de uma classe são chamados devariáveis, sendo que campos representam dados encapsulados em uma classe, evariáveis representam valores auxiliares necessários ao funcionamento dos métodosna classe. As operações contidas em uma classe são chamadas de métodos dessaclasse. Métodos são geralmente chamados ou executados explicitamente a partir deoutros trechos de código na classe que o contém ou a partir de outras classes. 4.4.1.3. Herança Segundo Furlan (1998), herança é o mecanismo de reutilização de atributose operações definidos em classes gerais por classes mais específicas, podendo serusada para expressar tanto generalização como associação. Pode-se organizar tipossimilares de classes de objetos em categorias hierárquicas, onde é permitida àclasse de menor nível, que é uma especialização ou extensão de outra classe,compartilhar atributos e operações de classes superiores na hierarquia. SANTOS (2003) diz que o mecanismo de reaproveitamento por herançapermite a reutilização de classes já existentes com instâncias de novas classes. Asclasses originais ficam assim contidas nas classes novas. É a partir da herança que surge o conceito de classes abstratas, as quaissão idealizadas para serem moldes de eventuais subclasses, as quais irão adicionarsua estrutura e comportamento, geralmente sobrepondo operações. Permiteespecificar atributos e operações comuns a várias classes uma única vez com apossibilidade de modificar-los à luz das necessidades das classes herdeiras. 4.4.1.4. Polimorfismo Segundo PAGE-JONES (2000), o termo polimorfismo é originário do grego esignifica "muitas formas" (poli = muitas, morphos = formas). A palavra polimorfismoorigina-se de duas palavras gregas que significam respectivamente, muitas e forma.Algo que é polifórmico, portanto, apresenta a propriedade de assumir muitas formas.
  • 36. 36PAGE-JONES (2000) explica ainda que polimorfismo é a habilidade pela qual umaúnica operação ou nome de atributo pode ser definido em mais de uma classe eassumir implementações diferentes em cada uma dessas classes. Para PENDER (2004), polimorfismo é a capacidade de escolherdinamicamente o método para uma operação durante a execução, dependendo dotipo de objeto que responde à solicitação. Pender complementa dizendo quepolimorfismo significa muitas maneiras de realizar a mesma coisa. Para SANTOS (2003), o mecanismo de herança permite a criação declasses a partir de outras já existentes com relações é-um-tipo-de, de forma que, apartir de uma classe genérica, classes mais especializadas possam ser criadas.Polimorfismo permite a manipulação de instâncias de classes que herdam de umamesma classe ancestral de forma unificada. 4.4.1.5. Coesão Segundo PENDER (2004), coesão é uma medida de como as partes de umobjeto dão suporte à mesma finalidade. A coesão mede dois fatores: como afinalidade do objeto é bem definida e se cada parte do objeto contribui diretamentepara cumprir sua finalidade. Alta coesão significa que um objeto possui umafinalidade bem definida e tudo no objeto contribui diretamente para essa finalidade.Baixa coesão significa ou que a finalidade do objeto é ambígua ou que nem todas aspartes do objeto contribuem diretamente para a finalidade do objeto, ou ambos. 4.4.2. Diagramas FURLAN (1998) afirma que usando a UML, é possível construir modelos apartir de blocos de construção básicos, como classes, interfaces, componentes, nós,dependências, generalizações e associações. Diagramas são meios paravisualização desses blocos de construção. Um diagrama é uma apresentaçãográfica de um conjunto de elementos, geralmente representados como um gráficoconectado de vértices (itens) e arcos (relacionamentos).
  • 37. 37 De acordo com Furlan, modelar um sistema complexo é uma tarefaextensiva sendo necessária a descrição de vários aspectos diferentes incluindo ofuncional, não funcional e organizacional. Cada visão é descrita em um número dediagramas que contém informação enfatizando um aspecto particular do sistema. 4.4.2.1. Diagramas de Classes Segundo BOOCH, RUMBAUGH e JACOBSON (2005), um diagrama declasses mostra um conjunto classes, interfaces e colaborações e seusrelacionamentos. São os diagramas mais encontrados em sistemas de modelagemorientados a objetos. Esses diagramas são utilizados para ilustrar a visão estática doprojeto de um sistema. Um diagrama de classes é apenas um tipo especial dediagrama e compartilha as mesmas propriedades de todos os outros diagramas –um nome e um conteúdo gráfico que são uma projeção em um modelo. 4.4.2.2. Diagramas de Colaboração Conforme PAGE-JONES (2000), no diagrama de colaboração da UML, osobjetos que interagem por meio de mensagens aparecem como caixas padrões daUML, com cada uma delas portando o nome de um objeto. Cada objeto éidentificado com o nome que os outros objetos utilizam para enviar-lhe umamensagem, uma vez que os objetos não têm realmente os seus próprios nomes. Emoutras palavras, um objeto destinatário adota o nome da variável no objetoremetente que detém o identificador do objeto destinatário. 4.4.2.3. Diagramas de Objetos Segundo GUEDES 2007, um diagrama de objetos mostra um conjunto deobjetos e seus relacionamentos. Esses diagramas são utilizados para ilustrar asestruturas de dados, registros estáticos de instâncias dos itens encontrados nosdiagramas de classes. Os diagramas de objetos fazem a modelagem de instâncias
  • 38. 38de itens contidos em diagramas de classes. A modelagem de estruturas dos objetosenvolve um retrato dos objetos de um sistema em um determinado momento. Para FURLAN (1998) diagrama de colaboração é descendente direto dodiagrama de objeto, do gráfico de interação de objeto e várias outras fontes. Umacolaboração é uma visão de um conjunto de elementos de modelagem relacionadospara um propósito particular em apoio a interações. Assim, um diagrama decolaboração mostra ma interação organizada em torno de objetos e seus vínculosformando uma base de padrões. 4.4.2.4. Diagramas de Componentes Segundo FURLAN (1998) um diagrama de componente é um gráfico decomponentes conectados por relacionamentos de dependência de onde tambémpodem ser associados componentes a outros por retenção física que representarelacionamentos de composição. Exibe as organizações e dependências entrecomponentes com o propósito de modelar a visão de implementação dos módulosde software executáveis com identidade e interface bem-definida de um sistema eseus relacionamentos. Para cada elemento lógico no modelo, geralmente existe umpadrão que mapeia um artefato de implementação. Furlan ainda afirma que um componente representa uma unidade de códigode software (fonte, binário ou executável) e pode ser usado para expor o compiladore dependências de run-time, incluindo sua localização em nós. É desenhado comoum retângulo maior e derivado do método de Booch para representar um módulo. 4.4.2.5. Diagramas de Caso de Uso Este é o diagrama mais geral e informal da UML, sendo utilizadoprincipalmente para auxiliar no levantamento e análise dos requisitos, em que sãodeterminadas as necessidades do usuário, e na compreensão do sistema como umtodo, embora venha a ser consultado durante todo o processo de modelagem e sirvade base para todos os outros diagramas (GUEDES, 2007).
  • 39. 39 Conforme BOOCH, RUMBAUGH e JACOBSON (2005) os diagramas decaso de uso são importantes para visualizar, especificar e documentar ocomportamento de um elemento. Esses diagramas fazem com que sistemas,subsistemas e classes fiquem acessíveis e compreensíveis, por apresentarem umavisão externa sobre como esses elementos podem ser utilizados no contexto.Mostram um conjunto de casos de uso e atores e seus relacionamentos. Diagramade caso de uso é faz com que sistemas, subsistemas e classes fiquem acessíveis ecompreensíveis, por apresentarem uma visão externa sobre como esses elementospodem ser utilizados no contexto. 4.4.2.6. Diagramas de Seqüência Diagrama de seqüência é um diagrama de interação que dá ênfase àordenação temporal de mensagens. Um diagrama de seqüência mostra um conjuntode papéis e as mensagens enviadas e recebidas pelas instâncias que representamos papéis. O Diagrama de Seqüência preocupa-se com a ordem temporal em que asmensagens são trocadas entre os objetos envolvidos em um determinado processo.Em geral, baseia-se em um Caso de Uso definido pelo diagrama de mesmo nome eapóia-se no Diagrama de Classes para determinar os objetos das classes envolvidasem um processo, bem como os métodos disparados entre os mesmos. (GUEDES,2007). 4.4.2.7. Diagramas de Atividade Segundo FURLAN (1998) um diagrama de atividades mostra o fluxo de umaatividade para outra em um sistema. Uma atividade mostra um conjunto deatividades, o fluxo seqüencial ou ramificado de uma atividade para outra e os objetosque realizam ou sofrem ações. Os diagramas de atividades são utilizados para fazera modelagem da função de um sistema e dão ênfase ao fluxo de controle naexecução de um comportamento com o propósito de estudar os fluxos dirigidos por
  • 40. 40processamento interno, descrevendo as atividades desempenhadas em umaoperação. 4.4.2.8. Diagramas de Interação BOOCH, RUMBAUGH e JACOBSON (2005) afirmam que os diagramas deinteração são utilizados para fazer a modelagem dos aspectos dinâmicos dosistema. Na maior parte, isso envolve a modelagem de instâncias concretas ouprototípicas de classes, interfaces, componentes e nós, juntamente com asmensagens que são trocadas entre eles, tudo isso no contexto de aparecer sozinhospara visualizar, especificar, construir e documentar a dinâmica de uma determinadasociedade de objetos ou podem ser utilizados para fazer a modelagem de umdeterminado fluxo de controle de um caso de uso. Um diagrama de interação mostra uma interação formada por um conjuntode objetos e seus relacionamentos, incluindo as mensagens que poderão sertrocadas entre eles. 4.4.2.9. Diagramas de Implantação Segundo FURLAN (1998), a UML fornece o diagrama de implantação paramostrar a organização do hardware e a ligação do software aos dispositivos físicos.Um diagrama de implantação denota vários dispositivos de hardware e interfacesfísicas determinados por seu estereótipo, como processador, impressora, memória,disco e assim por diante. FURLAN (1998) ainda afirma que a UML fornece notações avançadas esemânticas quando uma modelagem mais complexa é requerida, ainda que algumasdessas notações sejam destinadas a cobrir casos particulares e outras a estender aUML de um modo controlado para apoiar modelagem do sistema global. Diagramade implantação expõe a configuração de elementos de run-time e componentes desoftware, processos e objetos que neles se mantêm. Trata-se de um gráfico de nós
  • 41. 41conectados por associações de comunicação. Os nós podem conter instâncias decomponentes que, por sua vez, podem conter classes, bibliotecas ou executáveis. 4.4.2.10. Diagramas de Gráfico de Estados Segundo BOOCH, RUMBAUGH e JACOBSON (2005) um diagrama degráfico de estados mostra máquina de estados, dando ênfase ao fluxo de controlede um estado para outro. Uma máquina de estados é um comportamento queespecifica as seqüências de estados pelos quais um objeto passa durante seutempo de vida em resposta a eventos, juntamente com suas respostas a esseseventos. Um estado é uma condição ou situação na vida de um objeto durante aqual ele satisfaz a alguma condição, realiza alguma atividade ou aguarda algumevento. Um evento é uma especificação de uma ocorrência de um estímulo capaz deativar uma transição de estado. BOOCH, RUMBAUGH e JACOBSON (2005) explicam ainda que umatransição é um relacionamento entre dois estados, indicando que um objeto noprimeiro estado realizará certas ações e entrará no segundo estado quando umevento especificado ocorrer e as condições especificadas estão satisfeitas. Umaatividade é uma execução não-atômica em andamento em uma máquina deestados. Uma ação é uma computação atômica executável que resulta em umaalteração do estado do modelo ou no retorno de um valor. 4.5. Information Technology Infrastructure Library - ITIL Segundo MAGALHÃES e PINHEIRO (2007) a ITIL é composta por umconjunto das melhores práticas para a definição dos processos necessários aofuncionamento de uma área de TI. Descreve a base para a organização dosprocessos da área de TI, visando à sua orientação para o Gerenciamento deServiços de TI. As diversas práticas reunidas descrevem os objetivos, atividadesgerais, pré-requisitos necessários e resultados esperados dos vários processos, osquais podem ser incorporados dentro das áreas de TI.
  • 42. 42 Para FRY (2003) é importante entender que os processos do ITIL não irãotornar uma infra-estrutura “pobre” de TI em uma infra-estrutura “rica” de TI da noitepara o dia. Seus benefícios podem ser significantes, porém adaptar-se às melhorespráticas e processos não é tão fácil. Isto leva tempo, planejamento e principalmentecomprometimento. Conforme MAGALHAES e PINHEIRO (2007) a ITIL não define os processosa serem implantados na área de TI, não é uma metodologia para implementarprocessos de Gestão de Serviços de TI – é um framework flexível que permiteadaptar-se para ir ao encontro das necessidades específicas, demonstra asmelhores práticas que podem ser utilizadas para esta definição. Tais práticas, porsua vez, podem ser adotadas do modo que melhor puder atender às necessidadesde cada organização. A seguir, serão descritos os processos da ITIL que serão utilizados nessetrabalho. 4.5.1. Central de Serviços (Service Desk) MAGALHÃES e PINHEIRO (2007) afirmam que a Central de Serviços,também conhecida como Service Desk, é uma função e não um processo, essencialpara a implementação do Gerenciamento dos Serviços de TI. A Central de Serviçosatua como Ponto Único de Contato entre os usuários e os clientes dos serviços de TIe os diversos processos relacionados com o Gerenciamento dos Serviços de TI.Suas principais atividades são: o atendimento às chamadas, não importando o meiode comunicação utilizado pelos usuários e clientes dos serviços de TI, e aos eventosrecebidos da equipe de supervisão da infra-estrutura de TI, visando a sua corretaclassificação, além do encaminhamento para o processo de gerenciamentoadequado. Destaca-se, ainda, como objetivo, garantir o encerramento do maior númerode incidentes e consultas dentro do seu nível de atendimento no processo de
  • 43. 43Gerenciamento de Incidente, evitando a sobrecarga das demais equipes que atuamno processo. 4.5.2. Gerenciamento de Incidentes MAGALHÃES e PINHEIRO (2007) dizem que um incidente é qualquerevento que não faz parte do funcionamento-padrão de um serviço de TI e quecausa, ou pode causar uma interrupção do serviço ou uma redução do seu nível dedesempenho. Na maioria das vezes, um incidente reportado refere-se à interrupçãodo serviço de TI. Ainda segundo MAGALHÃES e PINHEIRO (2007), o processo degerenciamento de incidente tem por objetivo assegurar que, depois da ocorrência deum incidente, o serviço de TI afetado tenha restaurada a sua condição original defuncionamento o mais breve possível, minimizando os impactos decorrentes doefeito sobre o nível de serviço ou, até mesmo, da indisponibilidade total. A central deserviços é a área responsável pelo atendimento dos usuários e registro dosincidentes, passando a zelar por eles durante todo o seu ciclo de vida,independentemente da área em que estejam sendo atendidos. 4.5.3. Gerenciamento de Problema Segundo MAGALHÃES e PINHEIRO (2007), incidentes que se repetemindefinidamente e para os quais não se fornece nenhuma solução definitiva, faz comque os clientes da área de TI percam a confiança na capacidade da equipe desuporte aos serviços de TI, deteriorando a imagem desta área perante aorganização. Tal fato, também atinge o moral dos integrantes da equipe de suporteaos serviços de TI que se vêem reiteradamente tendo que resolver os mesmosincidentes, onerando a sua capacidade de resolver novos acidentes e aumentar suacontribuição para a organização. Todos os registros de problemas devem serrelacionados a todos os registros de incidentes associados para ajudar ogerenciamento de problema a determinar o impacto que tais problemas relacionados
  • 44. 44a incidentes têm sobre o negócio. O principal objetivo do processo deGerenciamento de Problema é minimizar o impacto adverso no negócio dosincidentes e problemas decorrentes de erros conhecidos relacionados com a infra-estrutura de TI, prevenindo a repetição de incidentes relacionados com estes errosconhecidos. 4.5.4. Gerenciamento de Nível de Serviço Segundo MAGALHÃES e PINHEIRO (2007), o gerenciamento de nível deserviço é a metodologia disciplinada e os procedimentos proativos utilizados paragarantir que níveis adequados de serviços serão entregues para todos os usuáriosde TI de acordo com as prioridades do negócio e a um custo aceitável, acordadocom o cliente. A missão da equipe de gerenciamento de nível de serviço é manter egradualmente melhorar a qualidade dos serviços de TI, executando um cicloconstante de acordar, monitorar, informar os êxitos dos serviços de TI e incitar açõespara erradicar um serviço de TI de baixo desempenho na relação custo/benefício ouque não tenha mais importância para negócio, promovendo uma melhor relaçãoentre a área de TI e a organização. 4.6. ISO/IEC 20.000 MAGALHÃES e PINHEIRO (2007) afirmam que a ISO (InternationalOrganization for Standardization) e IEC (International Electrotechnical Commission)fazem parte do sistema especializado para padronização mundial. Entidadesnacionais que são membros da ISO ou IEC participam do desenvolvimento dePadrões Internacionais através de comitês técnicos estabelecidos pela respectivaorganização para lidar com campos específicos de atividade técnica. A normaISO/IEC 20.000 foi desenvolvida para responder às necessidades de uma audiênciaglobal e fornecer um entendimento comum do Gerenciamento de Serviços de TI emtodo o mundo. Esta norma está baseada na BS 15.000, que é uma norma britânica efoi o primeiro padrão mundial orientado especificamente para o Gerenciamento deServiços de TI. A ISO/IEC 20.000 está dividida em duas partes: a ISO/IEC 20.000-1:2005 e a ISO/IEC 20.000-2:2005.
  • 45. 45 Segundo MAGALHÃES e PINHEIRO (2007), dois dos maiores desafiosenfrentados pelas áreas de TI em relação ao gerenciamento dos serviços de TI são:conseguir a atenção e o compromisso por parte da alta direção da organização egarantir a aceitação e a adoção de um processo de Gerenciamento de Mudança portoda a organização. Estas resistências são consideravelmente reduzidas nasorganizações registradas como certificadas ISO e que pretendem utilizar a normaISO/IEC 20.000 como um passo à frente para obterem uma certificação específicano Gerenciamento de Serviços de TI. Neste tipo de cenário, a existência de um ciclode melhoria contínua envolve todos os stakeholders da organização. Ao mesmotempo, melhora a transparência, contribuindo para o aprimoramento do sistema degerenciamento da qualidade das operações da organização. Ainda segundo MAGALHÃES e PINHEIRO (2007), a ISO/IEC 20.000-1:2005é um documento de 16 páginas, publicado pela ISO, contém as especificações parao Gerenciamento de Serviços de TI. Fornece os requisitos do gerenciamento deserviços de TI na organização. Os índices da ISO/IEC 20.000-1:2005 são: Escopo;Termos e Definições; Requisitos para um Sistema de Gerenciamento; Planejamentoe Implementação do Gerenciamento de Serviço; Planejamento e Implementação deServiços Novos ou Alterados; Processos de Entrega de Serviços; Processos deRelacionamento; Processos de Resolução; Processos de Controle; Processo deGerenciamento de Liberação. A ISO/IEC 20.000-2:2005 é um documento de 34páginas que apresenta o código de prática para o Gerenciamento de Serviços de TI.Fornece orientação para os auditores internos e assistências aos prestadores deserviços que planejam melhorias no serviço ou que querem preparar-se paraauditorias em relação à norma ISO/IEC 20.000-1:2005. Os índices da ISO/IEC20.000-2:2005 são: Escopo; Termos e Definições; O sistema de gerenciamento;Planejamento e Implementação do gerenciamento de Serviços; Processos deEntrega de Serviços; Processos de Relacionamento; Processos de Resolução;Processos de Controle; Processos de Gerenciamento de Liberação.
  • 46. 465. Proposta do Novo Sistema Um sistema que interaja principalmente com o processo de gerenciamentode incidente, executando, inclusive, parte das atividades deste processo, peloatendimento às chamadas originadas de erros percebidos pelos usuários nainteração com os serviços de TI. Prover uma interface para outras atividadesrelacionadas com as demais necessidades dos usuários do sistema comorequisições de mudança, contratos de manutenção e solicitações de serviços. Minimizar o impacto adverso no negócio dos incidentes e problemasdecorrentes de erros conhecidos relacionados com os serviços prestados pelaequipe de TI. 5.1. Descrição do Sistema Proposto Desenvolver um sistema voltado para o gerenciamento de serviços de TIprestado pela empresa Dave Systems (Empresa Fictícia) tendo o gerenciamento deincidentes como o principal foco, de forma que torne a central de serviços à árearesponsável pelo atendimento dos usuários e registro dos incidentes, passando azelar durante todo o ciclo de vida do incidente. O sistema permitirá o cadastro de solicitações através de um canal decomunicação. A comunicação poderá ser via e-mail, telefone ou qualquer outro meiodefinido entre o provedor do serviço e o cliente. O analista de suporte fará ocadastro das demandas e/ou à verificação para solução de um incidente. O analistade incidente terá o controle das demandas enquanto a mesma estiver sendoimplementada e será responsável pelo feedback ao Analista de Suporte. De posse de todo o serviço catalogado no sistema, os diretores facilmentegeram indicadores para tomada de decisão e/ou métricas para acompanhamento daestratégia do negócio.
  • 47. 47 5.2. Resultados Esperados Com a utilização do SISDESK, espera-se que haja um maior controle sobreos incidentes e solicitações de mudanças cadastradas pelos clientes gerando,assim, um incremento da velocidade de atendimento e a melhoria do índice desatisfação dos clientes dos serviços de TI. Espera-se também, a melhora nogerenciamento da informação para tomada de decisão relativa aos serviçosprestados aos clientes de TI. 5.3. Restrições do Sistema Proposto A priori, o sistema terá o seu funcionamento apenas para a intranet da DaveSystems. O sistema obriga ao usuário possuir login e senha e um tipo de perfilassociado a sua conta para que seja definido o nível de acesso ao sistema proposto. Serão utilizados dados fictícios para alimentação da base de dados doprojeto, dessa forma, os dados reais da Dave Systems (Empresa Fictícia) serãopreservados. Neste momento as matérias da ITIL que serão utilizadas para odesenvolvimento do sistema são: gerenciamento de incidente, gerenciamento deproblema, gerenciamento de mudança e gerenciamento de nível de serviço. 5.4. Resultados Esperados A relação custo x benefício de um sistema é questionada por vários fatores.Redução com ligações telefônicas e identificação de erros visando à diminuição dotempo da solução de um problema resulta em atenuar custos trazendo benefícioslucrativos a empresa. O sistema oferece vários benefícios como soluções mais rápidas, ambienteúnico acessado por todos para cadastrar problemas e consultar soluções, assimcomo identificar através de estatísticas as áreas mais problemáticas onde
  • 48. 48necessitam de acompanhamento específico, sendo assim, diminuindo custos atravésde tempo de produção. Relatórios são emitidos periodicamente indicando a relação de problemas esoluções para medir problemas e identificar erros relacionados em cada área paradirecionar decisões. 5.5. Áreas Afetadas Pelo Novo Sistema Na empresa Dave Systems (Empresa Fictícia) as áreas que inicialmenteserão afetadas pelo novo sistema serão a gerência de suporte, gerência de projetos,coordenação de análise, coordenação de desenvolvimento e diretores de TI. 5.6. Banco de Dados A empresa para qual está sendo desenvolvido o SISDEK, utiliza o Oraclecomo banco de dados. Partindo deste princípio, o banco de dados Oracle Express10 g será utilizado para implementação do sistema evitando dessa forma, conflitosno momento da implantação do software.
  • 49. 496. Documentação de Análise Logo abaixo estão descritos os atores do sistema, identificando suasfunções dentro do mesmo. Está relaciona a lista de caso de uso que seráimplementada no sistema, assim como é demonstrado o diagrama de casos de usoe suas devidas especificações detalhadas. Neste tópico também é demonstradomodelo de entidade e relacionamento, o diagrama de classes e a especificação dastabelas do banco de dados. 6.1. Visão Macro dos Atores O SISDESK possuirá os seguintes atores em seu sistema: Analista deSuporte, Analista de Incidente, Técnico e Administrador. 6.2. Identificação dos Atores O ator Analista de Suporte é responsável por criar um registro de incidentecom as informações disponíveis sobre o mesmo. Consiste em receber o registro deincidente, seja ele por telefone, fax ou email, e criar o registro no gerenciamento deincidente. O ator Analista de Incidente é responsável por fornecer rapidamente umaboa análise de um incidente e/ou uma solução para ela, a fim de restabelecer oserviço perturbado o mais rápido possível. Esse papel será desenvolvido peloAnalista de Sistema. O Ator Gerente de Incidentes é responsável pela qualidade e a integridadedo processo de gerenciamento de incidente. Esta pessoa é a interface com outrosgerentes de processos. O ator Técnico é responsável pela implementação de uma solução tantopara um serviço interrompido quanto para uma solicitação de mudança. Esse papel
  • 50. 50poderá ser realizado por Desenvolvedores, Administradores de Dados, Analista deBanco de Dados ou Web Designers. O ator Administrador é responsável pelo cadastro e exclusão de usuários nosistema. Tem acesso a todos os módulos do sistema. Esta pessoa define, no perfilde cada usuário, os módulos e as funcionalidades permitidas ao perfil agregado aousuário do sistema. 6.3. Lista dos Casos de Uso Exposto abaixo a tabela com a lista de casos de uso do sistema. Tabela 2 - Lista de Caso de Uso Código Casos de Uso UC01 Efetuar Login UC02 Manter Usuário UC03 Manter Incidente UC04 Manter Mudança UC05 Manter Problema
  • 51. 516.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 Mudança Manter Usuário Figura 3 - Diagrama de Casos de Usos
  • 52. 52 6.5. Descrição Detalhada dos Casos de Uso Abaixo é mostrada a especificação de caso de uso das funcionalidades dosistema proposto.UC01 – Efetuar Login Tabela 3 - UC01 Efetuar LoginNome UC01- Efetuar LoginObjetivo Efetuar Login.Atores Administrador; Usuários Cadastrados.Dados Consumidos Login e senha.Dados Produzidos Acesso ao sistema.Prioridade Alta.Pré-condições Possuir cadastro no sistema.Pós-condições N/A Fluxo PrincipalEfetuar login. Ator SistemaInformar login e senha. Valida as informações do usuário e senha. Se os dados estiverem OK, o sistema carrega a página inicial. Se os dados estiverem incorretos, a aplicação retorna uma mensagem de erro.Receber mensagemSe a mensagem foi de erro, reinicie o processo dofluxo principal.Se a mensagem foi de sucesso, encerre o Fluxo Fluxo Alternativo 1N/A
  • 53. 53UC03 – Manter Usuário Tabela 4 – UC2 Manter UsuárioNome UC03- Manter UsuárioObjetivo Cadastrar usuário no sistema.Atores Administrador; Usuários Cadastrados.Dados Consumidos Nome, função, email e técnico.Dados Produzidos Usuários Cadastrados.Prioridade Alta.Pré-condições Possuir cadastro no sistema; Estar logado no sistema.Pós-condições N/A Fluxo Principal – Cadastrar Usuário Ator SistemaAcessar a página de cadastro de usuário. O sistema carrega a pagina para cadastrar um novo usuário.Preencher as informações relativas ao cadastro de O sistema valida as informações da tela. Se osusuário e clica no botão gravar. dados estiverem OK, armazená-los na tabela SD_TECNICO e enviar mensagem de operação realizada com sucesso. Se os dados não estiverem OK, enviar mensagem de erro.Receber mensagem.Se a mensagem foi de erro, reinicie o processo dofluxo principal.Se a mensagem foi de sucesso, encerre o Fluxo. Fluxo Alternativo 1 – Consultar Usuário Ator SistemaAcessar a página de consulta de usuário. O sistema lista todos os usuários cadastrados.Selecionar o registro. O sistema carrega na tela os dados do registro selecionado. Fluxo Alternativo 2 – Alterar Usuário Ator SistemaAcessar a página de usuário. O sistema lista todos os usuários cadastrados.Selecionar o item a ser modificado. O sistema carrega para a tela as informações referentes ao usuário selecionado.Alterar as informações e clica no botão Gravar. O sistema valida as informações da tela. Se os dados estiverem OK, armazená-los na tabela SD_TECNICO e enviar mensagem de operação realizada com sucesso. Se os dados não estiverem OK, enviar mensagem de erro.
  • 54. 54Receber mensagem.Se a mensagem foi de erro, reinicie o processo dofluxo alternativo 2.Se a mensagem foi de sucesso, encerre o Fluxo Fluxo Alternativo 3 – Excluir Usuário Ator SistemaAcessar a página de usuário. O sistema lista todos os usuários cadastrados.Selecionar o item a ser excluído. O sistema carrega para a tela as informações referentes ao usuário selecionado.Clicar no botão excluir. O sistema exclui os dados da base de dados e envia mensagem de operação realizada com sucesso.Receber mensagem.UC04 – Manter Incidente Tabela 5 - UC03 Manter IncidenteNome UC04- Manter IncidenteObjetivo Cadastrar Novo incidente no Sistema.Atores Administrador; Usuários Cadastrados.Dados Consumidos Responsável, solicitante, impacto, nível, urgência, categoria, assunto, descrição, data de abertura, data de conclusão.Dados Produzidos Incidente cadastrado.Prioridade Alta.Pré-condições Possuir cadastro no sistema; Estar logado no sistema.Pós-condições Não se Aplica. Fluxo Principal – Cadastrar Incidente Ator SistemaAcessar a página de cadastro de O sistema carrega a pagina principal de incidente.Incidente do sistema.Preencher as informações relativas ao incidente e O sistema valida as informações da tela. Se osclica no botão gravar. dados estiverem OK, armazená-los na tabela SD_INCIDENTE e enviar mensagem de operação. Se os dados não estiverem OK, enviar mensagem de erro.Receber mensagem.
  • 55. 55Se a mensagem foi de erro, reinicie o processo dofluxo principal.Se a mensagem foi de sucesso, encerre o Fluxo Fluxo Alternativo 1 – Consultar Incidente Ator SistemaAcessar a página de incidente. O sistema lista todos os incidentes cadastrados.Selecionar o registro. O sistema carrega na tela o registro selecionado. Fluxo Alternativo 2 – Alterar Incidente Ator SistemaAcessar a página de incidente. O sistema lista todos os incidentes cadastrados.Selecionar o item a ser modificado. O sistema carrega para a tela as informações referentes ao incidente selecionado.Alterar as informações e clica no botão gravar. O sistema valida as informações da tela. Se os dados estiverem OK, armazená-los na tabela SD_INCIDENTE e enviar mensagem de operação realizada com sucesso. Se os dados não estiverem OK, enviar mensagem de erro.Receber mensagem.Se a mensagem foi de erro, reinicie o processo dofluxo alternativo 2.Se a mensagem foi de sucesso, encerre o Fluxo Fluxo Alternativo 3 – Excluir Incidente Ator SistemaAcessar a página de incidentes. O sistema lista todos os incidentes cadastrados.Selecionar o item a ser excluído. O sistema carrega para a tela o incidente selecionado.Excluir o incidente e clica no botão Gravar. O sistema exclui os dados da base de dados e envia mensagem de operação realizada com sucesso.Receber mensagem.
  • 56. 56UC05 – Manter Mudança Tabela 6 – UC04 Manter MudançaNome UC05- Manter MudançaObjetivo Cadastrar Nova Mudança no Sistema.Atores Administrador; Usuários Cadastrados.Dados Consumidos Responsável, impacto, solicitante, urgência, categoria, descrição, assunto, Data de abertura, previsão de conclusão, data de inicio previsto, data início Atendimento, impacto.Dados Produzidos Mudança cadastrada.Prioridade Média.Pré-condições Possuir cadastro no sistema; Estar logado no sistema.Pós-condições Não se Aplica. Fluxo Principal – Cadastrar Mudança Ator SistemaAcessar a página de cadastro de Mudança do O sistema carrega a pagina principal de mudança.sistema.Preencher as informações relativas às mudanças e O sistema valida as informações da tela. Se osclica no botão gravar dados estiverem OK, armazená-los na tabela SD_MUDANCA e enviar mensagem de operação realizada com sucesso. Se os dados não estiverem OK, enviar mensagem de erro.Receber mensagem.Se a mensagem foi de erro, reinicie o processo dofluxo principal.Se a mensagem foi de sucesso, encerre o Fluxo Fluxo Alternativo 1 – Consultar Mudança Ator SistemaAcessar a página de mudança. O sistema lista todas as mudanças cadastradas.Selecionar o registro. O sistema carrega na tela o registro selecionado. Fluxo Alternativo 2 – Alterar MudançaAlterar Mudança Ator SistemaAcessar a página de mudança. O sistema lista todas as mudanças cadastradas.Selecionar a mudança a ser modificada. O sistema carrega para a tela as informações referentes à mudança selecionada.Alterar as informações e clica no botão gravar. O sistema valida as informações da tela. Se os dados estiverem OK, armazená-los na tabela SD_MUDANCA e enviar mensagem de operação
  • 57. 57 realizada com sucesso. Se os dados não estiverem OK, enviar mensagem de erro.Receber mensagem.Se a mensagem foi de erro, reinicie o processo dofluxo alternativo 2.Se a mensagem foi de sucesso, encerre o Fluxo Fluxo Alternativo 3 – Excluir Mudança Ator SistemaAcessar a página de mudança. O sistema lista todas as mudanças cadastradas.Selecionar a mudança à ser excluída. O sistema carrega para a tela o registro selecionado.Excluir a mudança e clica no botão gravar. O sistema exclui os dados da base de dados e envia mensagem de operação realizada com sucesso.Receber mensagem.UC06 – Manter Problema . Tabela 7 - UC05 Manter ProblemaNome UC06- Manter ProblemaObjetivo Cadastrar Problema.Atores Administrador; Usuários Cadastrados.Dados Consumidos Responsável, impacto, solicitante, urgência, categoria, descrição, assunto, Data de abertura, previsão de conclusão, data de inicio previsto, data início Atendimento, impacto.Dados Produzidos Problema cadastrado.Prioridade Alta.Pré-condições Possuir cadastro no sistema; Usuário estar logado no sistema.Pós-condições Não se aplica. Fluxo Principal – Cadastrar Problema Ator SistemaAcessar a página de cadastro de Problema. O sistema carrega a pagina de cadastro do problema.Preencher as informações relativas ao problema e O sistema valida as informações da tela. Se osclicar no botão gravar. dados estiverem OK, armazená-los na tabela SD_PROBLEMA e enviar mensagem de operação realizada com sucesso. Se os dados não estiverem OK, enviar mensagem de erro.
  • 58. 58Receber mensagem.Se a mensagem foi de erro, reinicie o processo dofluxo principal.Se a mensagem foi de sucesso, encerre o Fluxo Fluxo Alternativo 1 – Consultar ProblemaConsulta de Problema. Ator SistemaAcessar a página de problema. O sistema lista todos os problemas cadastrados.Selecionar o registro. O sistema carrega na tela o registro selecionado. Fluxo Alternativo 2 – Alterar Problema Ator SistemaAcessar a página de problema. O sistema lista todos os problemas cadastrados.Selecionar o problema a ser modificado. O sistema carrega para a tela as informações referentes ao problema selecionado.Alterar as informações e clica no botão gravar. O sistema valida as informações da tela. Se os dados estiverem OK, armazená-los na tabela SD_PROBLEMA e enviar mensagem de operação realizada com sucesso. Se os dados não estiverem OK, enviar mensagem de erro.Receber mensagem.Se a mensagem foi de erro, reinicie o processo dofluxo alternativo 2.Se a mensagem foi de sucesso, encerre o Fluxo Fluxo Alternativo 3 – Excluir Problema Ator SistemaO usuário acessa a página de problema. O sistema lista todos os problemas cadastrados.O usuário seleciona o problema a ser modificado. O sistema carrega para a tela o problema selecionado.Excluir o problema e clica no botão excluir. O sistema exclui os dados da base de dados e envia mensagem de operação realizada com sucesso.Receber mensagem.
  • 59. 59 6.6. Diagrama de Classes Existem três tipos de perspectivas oferecidas no desenvolvimento de umdiagrama de classe: Perspectiva conceitual, que representa os conceitos do domínioem estudo. Essa é uma perspectiva voltada para o cliente; Perspectiva deespecificação, que foca nas principais interfaces e métodos da arquitetura e nãocomo na forma que eles serão implementados. Essa perspectiva é voltada parapessoas que não necessitam do detalhamento do desenvolvimento; Perspectiva deimplementação, que aborda a forma como será o sistema será implementado. Essaé uma perspectiva voltada para a equipe de desenvolvimento. Na implementação do trabalho proposto, será utilizada a perspectiva deespecificação. Na figura abaixo é mostrado o diagrama de classe do sistema. class System FUNCAO TECNICO + getters() : void + getters() : Tecnico {query} + setters() : void {query} SOLICITACAO + alterar(Objeto) : void {query} + consultar(Objeto) : void {query} + excluir(Objeto) : void {query} + gravar(Objeto) : void {query} INCIDENTE MUDANCA PROBLEMA + getters() : Incidente {query} + getters() : EstadoMudanca {query} + getters() : EstadoProblema {query} + setters() : void {query} + setters() : void {query} + setters() : void {query} Figura 4 - Diagrama de Classe
  • 60. 60 6.7. Modelo de Entidade e Relacionamento Abaixo é mostrado o modelo de entidade e relacionamento utilizado nodesenvolvimento do sistema. Figura 5 - Modelo de Entidade e Relacionamento
  • 61. 61 6.8. Especificação das Tabelas 6.8.1. Tabela SD_ANEXOINCIDENTE Esta tabela é utilizada para armazenar os anexos do incidente. Tabela 8 - SD_ANEXOINCIDENTE ATRIBUTOS TIPO DO DADO CHAVE PRIMÁRIA CHAVE ESTRANGEIRA DESCRIÇÃOID_ANEXOINCIDENTE Long Sim Identificador Identificador da tabelaID_INCIDENTE Long Sim SD_INCIDENTE. Campo utilizado para especificar o nome comNM_NOME varchar(500) o qual deseja identificar cada anexo do incidente. Campo utilizado para armazenar a descriçãoDS_DESCRICAO varchar(2000) do anexo de forma que ajude a compreender detalhes do anexo. Campo utilizado paraANEXO_BLOB BLOB armazenar o anexo. 6.8.2. Tabela SD_ANEXOMUDANCA Tabela utilizada para separar os anexos referentes à mudança. Tabela 9 - SD_ANEXOMUDANCA ATRIBUTOS TIPO DO DADO CHAVE PRIMÁRIA CHAVE ESTRANGEIRA DESCRIÇÃOID_ANEXOMUDANCA Long Sim IdentificadorID_MUDANCA Long Sim Identificador da tabela SD_MUDANCADS_DESCRICAO varchar(50) Campo utilizado para descrição do anexoNM_NOME varchar(500) Campo utilizado para armazenar o nome do anexoNM_TIPO Varchar(50) Campo utilizado para armazenar o tipo do anexo. Tipo de anexo: CADASTRO - Anexo do tipo principal. IMPACTO - Anexo do impacto ROLLOUT - Anexo do ROLL_OUT BACKOUT - Anexo do BACK_OUT REVISAO - Anexo da REVISAOANEXO_BLOB BLOB Campo utilizado para armazenar o anexo.
  • 62. 62 6.8.3. Tabela SD_ESTADOMUDANCA Tabela utilizada para armazenar os estados da mudança. Tabela 10 - SD_ESTADOMUDANCA CHAVE ATRIBUTOS TIPO DO DADO CHAVE ESTRANGEIRA DESCRIÇÃO PRIMÁRIAID_ESTADOMUDANCA Long Sim IdentificadorNM_NOME Varchar (500) Armazena o nome único com o qual deseja identificar cada estado de mudança.NM_TEMPORIZADOR Varchar (50) Armazena o tempo gasto na implementação da mudançaDS_DESCRICAO Varchar(2000) Armazena a descrição do estado da mudança de forma que ajude a compreender cada estado. 6.8.4. Tabela SD_FUNCAO Tabela utilizada para armazenar a função do técnico dentro do sistema. Tabela 11 - SD_FUNCÃO CHAVE ATRIBUTOS TIPO DO DADO CHAVE ESTRANGEIRA DESCRIÇÃO PRIMÁRIAID_FUNCAO Long Sim IdentificadorNM_NOME Varchar (500) Armazena o nome único com o qual deseja identificar cada função de um técnico. Ex: Analista, Desenvolvedor, DBA, entre outras funções.DS_DESCRICAO Varchar(2000) Armazena a descrição de cada função de forma que ajude a compreender cada função
  • 63. 63 6.8.5. TABELA SD_IMPACTO CHAVE ATRIBUTOS TIPO DO DADO CHAVE ESTRANGEIRA DESCRIÇÃO PRIMÁRIAID_IMPACTO Long Sim IdentificadorNM_NOME Varchar (500) Armazena o nome único com o qual deseja identificar cada impacto de uma solicitação. Ex: Afeta o setor financeiro; Afeta o setor de almoxarifado.DS_DESCRICAO Varchar(2000) Armazena a descrição de cada impacto de forma que ajude a compreender cada impacto. 6.8.6. Tabela SD_INCIDENTE Tabela utilizada para armazenar incidentes. Tabela 12 - SD_INCIDENTE CHAVE ATRIBUTOS TIPO DO DADO CHAVE ESTRANGEIRA DESCRIÇÃO PRIMÁRIAID_INCIDENTE Long Sim IdentificadorID_RESPONSAVEL Long Sim Identificador da tabela SD_RESPONSAVELDS_SOLICITANTE Long Identificador da tabela SD_SOLICITANTEID_IMPACTO Long Sim Identificador da tabela SD_IMPACTOID_MODO Long Sim Identificador da tabela SD_MODOID_NIVEL Long Sim Identificador da tabela SD_NIVELID_URGENCIA Long Sim Identificador da tabela SD_URGENCIAID_CATEGORIA Long Sim Identificador da tabela SD_CATEGORIANM_ASSUNTO Varchar(500) Armazena o assunto relacionado ao incidente cadastradoDS_RESOLUCAO Varchar(800) Descrição da solução do incidenteDS_DESCRICAO Varchar(2000) Armazena a descrição do incidenteDT_ABERTURA Date Armazena a data de abertura do incidenteDT_PREVCONCLUSAO Date Armazena a data de previsão de resolução do incidenteDT_INICIOPREVISTA Date Armazena a data prevista para o início da resolução do incidenteDT_INICIOATENDIMENTO Date Armazena a data real do início do atendimento
  • 64. 64 6.8.7. Tabela SD_MATRIZPRIORIDADE Tabela utilizada para armazenar a prioridade com base no impacto e urgência. Tabela 13 - SD_ MATRIZPRIORIDADE ATRIBUTOS TIPO DO DADO CHAVE PRIMÁRIA CHAVE ESTRANGEIRA DESCRIÇÃOID_IMPACTO Long Sim Identificador da tabela SD_IMPACTOID_PRIORIDADE Long Sim Identificador da tabela SD_PRIORIDADEID_URGENCIA Long Sim Identificador da tabela SD_URGENCIA 6.8.8. Tabela SD_MUDANCA Tabela utilizada para armazenar as solicitações de mudanças. Tabela 14 - SD_MUDANCA CHAVE CHAVE ATRIBUTOS TIPO DO DADO DESCRIÇÃO PRIMÁRIA ESTRANGEIRAID_MUDANCA Long Sim IdentificadorID_MODO Long Sim Identificador da tabela SD_MODOID_RESPONSAVEL Long Sim Identificador da tabela SD_TECNICOID_NIVELMUDANCA Long Sim Identificador da tabela SD_NIVELMUDANCA.ID_IMPACTO Long Sim Identificador da tabela SD_IMPACTOID_SOLICITANTE Long Sim Identificador da tabela SD_SOLICITANTEID_URGENCIA Long Sim Identificador da tabela SD_SOLICITANTEID_CATEGORIA Long Sim Identificador da tabela SD_CATEGORIANM_DESCRICAO Varchar(50) Armazena a descrição da mudançaNM_ASSUNTO Varchar(2000) Armazena o assunto da mudançaDT_ABERTURA Date Armazena a data de abertura da mudançaDT_PREVISAOCONCLUSAO Date Armazena a data de abertura da mudançaDT_INICIOPREVISTA Date Armazena a data de previsão de início do atendimento da mudançaDT_INICIOATENDIMENTO Date Armazena a data real de início do atendimento.NM_RESOLUCAO Varchar(500) Descreve a resolução da mudançaNM_IMPACTO Varchar(4000) Descreve o impacto que a mudança poderá causarNM_PLANOROLLOUT Varchar(4000) Plano que definirá qual estratégia utilizada para atender
  • 65. 65 a mudançaNM_PLANOBACKOUT Varchar(4000) Plano que definirá qual estratégia utilizada para solucionar um problema ocorrido com a implementação da mudançaNM_LISTAVERIFICACAO Varchar(4000) Lista utilizada para verificar o atendimento das tarefasNM_REVISAO Varchar(4000) Revisar a mudança realizada 6.8.9. Tabela SD_MUDANCAESTADO Tabela utilizada para armazenar a associação entre as entre as tabelas SD_MUDANCA e SD_ESTADOMUDANCA. Tabela 15 - SD_MUDANCAESTADO CHAVE ATRIBUTOS TIPO DO DADO CHAVE ESTRANGEIRA DESCRIÇÃO PRIMÁRIAID_MUDANCAESTADO Long Sim Identificador.ID_ESTADOMUDANCA Long Sim Identificador da tabela SD_ESTADOMUDANCAID_MUDANCA Long Sim Identificador da tabela SD_MUDANCA 6.8.10. Tabela SD_NIVELMUDANCA Tabela utilizada para armazenar a classificação dos níveis de mudança. Tabela 16 - SD_NIVELMUDANCA ATRIBUTOS TIPO DO DADO CHAVE PRIMÁRIA CHAVE ESTRANGEIRA DESCRIÇÃOID_NIVELMUDANCA Long Sim IdentificadorNM_NOME Varchar(500) Campo utilizado para especificar o nome único com o qual deseja identificar cada nível de mudança.DS_DESCRICAO Varchar(2000) Campo utilizado para descrever o nível de mudança. 6.8.11. Tabela SD_PRIORIDADE Tabela utilizada para armazenar a importância atribuída a um pedido.
  • 66. 66 Tabela 17 - SD_PRIORIDADE ATRIBUTOS TIPO DO DADO CHAVE PRIMÁRIA CHAVE ESTRANGEIRA DESCRIÇÃOID_PRIORIDADE Long Sim IdentificadorNM_NOME Varchar(500) É onde deve especificar o nome único com o qual deseja identificar cada prioridadeNM_COR Varchar(50) Define a cor da prioridadeDS_DESCRICAO Varchar(2000) Ajuda a compreender a prioridade 6.8.12. Tabela SD_TECNICO Tabela utilizada para armazenar os técnicos que estarão envolvidos no processo de desenvolvimento de software. Nesta tabela conterá também a equipe de suporte que fará o primeiro contato com cliente. Tabela 18 - SD_TECNICO CHAVE ATRIBUTOS TIPO DO DADO CHAVE ESTRANGEIRA DESCRIÇÃO PRIMÁRIAID_TECNICO Long Sim IdentificadorID_FUNCAO Long Sim Identificador da tabela SD_FUNCAONM_LOGIN Varchar(50) Login utilizado para conectar na aplicação.NM_SENHA Varchar(50) Campo utilizado para armazenar a senha do técnicoNM_CUSTOPORMNUTO Number(8,2) Campo utilizado para armazenar custo da tarefa realizada pelo técnicoNM_EMAIL Varchar(50) Campo utilizado para armazenar o email do técnico.NM_NOME Varchar(100) Campo utilizado para armazenar o nome
  • 67. 67 6.8.13. Tabela SD_URGENCIA Tabela utilizada para armazenar a velocidade necessária para resolução de um incidente. Tabela 19 - SD_URGENCIA CHAVE ATRIBUTOS TIPO DO DADO CHAVE ESTRANGEIRA DESCRIÇÃO PRIMÁRIAID_URGENCIA Long Sim IdentificadorNM_NOME Varchar(50) É onde deve especificar o nome único com o qual deseja identificar cada urgênciaDS_DESCRICAO Varchar(2000) Ajuda a compreender a urgência 6.9. Árvore do Sistema Segue abaixo uma representação gráfica da estrutura do sistema proposto.A árvore foi criada como modelo de mapa mental, pois, facilita a visualização,memorização e compreensão da estrutura do sistema. Figura 6 - Árvore do Sistema
  • 68. 68 6.10. Especificações Físicas Logo abaixo serão mostradas as telas do sistema proposto, o Help on-line ea segurança física e lógica com as suas devidas normas. 6.10.1. Layout das Principais Telas da Aplicação A seguir, serão mostradas o protótipo das principais telas do sistemaproposto. As telas de edição usarão as mesmas de cadastro, portanto serãomostradas apenas as telas de cadastro. Abaixo é mostrada a tela utilizada para efetuar o login no sistema. Figura 7 - Tela de Login
  • 69. 69 Em seguida, é mostrada a tela para cadastro de uma nova solicitação. Ousuário determinará se a solicitação é uma Incidente ou um Problema. Figura 8 - Nova Solicitação Ao clicar em „Adicionar Solução‟ a tela abaixo é apresenta para a descriçãoda solução da solicitação. Figura 9 - Adicionar Solução
  • 70. 70Abaixo é apresentada a tela de cadastro de problema: Figura 10 - Cadastro de ProblemaO protótipo abaixo retrata a tela de cadastro do usuário. Figura 11 - Cadastro de Usuário
  • 71. 71 6.11. Help on-line O Help on-line é um mecanismo de ajuda e suporte ao usuário para utilizar eoperar o sistema. O mesmo disponibiliza um tópico de ajuda para a navegação eutilização do software. A opção „Ajuda‟ se encontra na parte superior das telas dosistema com o formato do sinal de interrogação indicando a ferramenta de ajuda. 6.12. Segurança Física e Lógica Para que a segurança de um sistema obtenha êxito em seu funcionamento énecessário que seus dados, assim como seus servidores e outros equipamentossejam protegidos. Segurança física é impedir o acesso não autorizado aequipamentos e segurança lógica é impedir o acesso das informações de umsistema. Todos que fazem uso das informações do sistema proposto devem teracesso conforme definição de cada perfil do usuário. Vários fatores deverão seranalisados na segurança física e lógica, a fim de se obter uma proteção máxima dosistema e de seus equipamentos. 6.12.1. Norma de Segurança Física As normas de segurança física têm como objetivo zelar e guardar o servidorde aplicação e servidor de banco de dados, onde deverá ser mantido de formaisolada de outros recursos de informática, como também deverá ser protegido deincêndios, desabamentos, relâmpagos, acesso indevido de pessoas, furto e outrosfatores que possam causar danos ao mesmo. Dessa forma, a Dave Systems possuium setor chamado COINF (Coordenadoria de Infraestrutura), que implementa todasas normas citadas acima. 6.12.2. Norma de Segurança Lógica Segurança lógica é a forma como o sistema deverá ser protegido no nível desistema operacional. Deverão existir normas de políticas de segurança para definir oacesso das informações no sistema. Todo usuário deve ter uma identificação única,
  • 72. 72pessoal e intransferível, qualificando-o, inequivocamente, como responsável porqualquer atividade desenvolvida sob esta identificação. O sistema proposto define tipos de perfis conforme cada tipo de atuaçãodentro da empresa. Permite a correta identificação de um usuário para lhe conferiracesso de acordo com seu perfil. Possibilitam especificar as ações permitidas eníveis de privilégio diferenciados para cada usuário através do estabelecimento depolíticas de uso.
  • 73. 737. Plano de Implantação A finalidade do Plano de Implantação é garantir que o sistema alcance seususuários com sucesso. O Plano de Implantação fornece uma agenda detalhada deeventos, pessoas responsáveis e dependências de evento necessárias para garantira mudança bem-sucedida para o novo sistema. A implantação deve minimizar oimpacto da mudança na equipe do cliente, no sistema de produção e na rotina geraldos negócios (RUP, 2010). O servidor de aplicação para o ambiente de produção definido, de forma quehaja as mínimas condições de funcionamento do sistema é possuir uma maquinacom o processador Intel Core 2 Duo, 4 gigabyte de memória, Apache Tomcat 6 ouuma versão superior, Java 5 ou uma versão superior. Para o banco de dados, a configuração mínima é conter um computador quepossua um processador Intel Core 2 Duo, 8 gigabyte de memória, SistemaOperacional – Windows e Oracle 10g XE.
  • 74. 748. Conclusão Muitas instituições possuem demandas internas de serviços que precisam serregistradas, analisadas e executadas, para que dessa forma tenham um ponto únicode controle dos serviços prestados. Partindo desse princípio foi desenvolvido umprojeto de gerenciamento de serviços voltado exclusivamente para odesenvolvimento de software, que será implantado na empresa Dave Systems(Empresa Fictícia). O trabalho desenvolvido visa centralizar os serviços internos prestados, ageração de relatórios gerenciais, a substituição do atual sistema devido a suainconsistência de dados e a utilização do mesmo para a implantação da ISO/IEC20000. Como resultado obteve-se um sistema capaz de atender e gerenciar osincidentes abordando todas as demandas, classificando e ordenando-os conforme otipo de incidente possibilitando a centralização na tomada de decisão, assim como oseu gerenciamento. Atualmente o sistema dá ênfase a implementação as disciplinas deGerenciamento de Incidente, Gerenciamento de Problema e Gerenciamento deMudança e o desenvolvimento de um Service Desk. Como trabalhos futuros, serãoimplementados as disciplinas de Gerenciamento de Configuração, Gerenciamentode Nível de Serviço e Gerenciamento de Liberação ficando a cargo da equipe dedesenvolvimento da empresa Dave Systems (Empresa Fictícia).
  • 75. 759. Referencias Bibliográficas[1] BMC SOFTWARE. ISO 20000: O que deve uma organização fazer? Disponívelem: <http://documents.bmc.com/products/documents/49/68/64968/64968.pdf>.Acessado em 29 de Junho de 2010.[2] SEBRAE. Programação e Controle de Produção. Disponível em:<http://www.sebraesp.com.br/faq/produtividade/programacao_controle_producao/cronograma>. Acessado em 25 de maio de 2010.[3] SUN. JAVA. Disponível em <http://www.java.com/ >. Acessado em 03 de Abril de2010.[4] DEVMEDIA, Oracle Free. Disponível em:<http://www.devmedia.com.br/articles/viewcomp_forprint.asp?comp=2317>.Acessado em 03 de Junho de 2010.[5] POSTGRESQL, site oficial. Sobre o PostgreSQL. Disponível em:<http://www.postgresql.org.br/sobre>. Acessado em 26 de junho de 2010.[6] RUP, Rational Unified Process. Melhor Prática: Desenvolva iterativamente.Disponível em: <http://www.wthreex.com/rup/manuals/intro/im_bp1.htm>. Acessadoem 05 de abril de 2010.[7] UML, Unified Model Language. Diagrama de Classes. Disponívelem:<http://www.dsc.ufcg.edu.br/~jacques/cursos/map/html/uml/diagramas/classes/classes1.htm >ABBEY, Michael; COREY, Michael J.; ABRAMSON, Ian. Oracle 8i GuiaIntrodutório. Rio de Janeiro: Campus, 2000.ABBEY, Michael; COREY, Michael J. Oracle, Guia do Usuário. São Paulo: MakronBooks, 1997.ANDRADE, Gabriel. O Que são Linguagens de Programação.<http://www.infoescola.com/informatica/o-que-sao-linguagens-de-programacao>.Acessado em 29 de abril de 2010.BOOCH, Grandy; RUMBAUGH, James; JACOBSON, Ivar; UML Guia do Usuário.Rio de Janeiro: Campus, 2005.CADERNHEAD, Rogers; LEMMAY, Laura. Aprenda Java em 21 Dias. Rio deJaneiro: Campus, 2005.CONVERSE, Tim; PARK, Joyce. PHP 4 a Bíblia. Rio de Janeiro: Campus, 2001.DEITEL, Harvey M.; DEITEL, Paul J. Java Como Programar. São Paulo: PearsonPrentice Hall 6° Edição, 2005
  • 76. 76FRY, Malcolm. The Goals of ITIL: Exploring the goals of Service Management.Sunnyvale, USA: Remedy, 2003.FURLAN, José Davi. Modelagem de Objetos Através da UML. São Paulo: Makron,1998.GONÇALVES, Edson. Desenvolvendo Aplicações Web com NetBeans IDE 5.5.Rio de Janeiro: Ciência Moderna, 2007.GUEDES, Gilleanes. UML 2 Guia Prático. São Paulo: Novatec 2007.LISCHNER, Ray. Delphi. O Guia Essencial. Rio de Janeiro: Campus, 2000KRUCHTEN, Philippe. Introdução ao RUP RATIONL UNIFIED PROCESS. Rio deJaneiro: Moderna, 2003.MAGALHÃES, Ivan Luizio; PINHEIRO, Walfrido Brito. Gerenciamento de Serviços deTI na Prática, Uma abordagem com base na ITIL. São Paulo: Novatec, 2007.MATOS, Alexandre Veloso. UML, Prático e Descomplicado. São Paulo: Érica,2002.PAGE-JONES, Meilir. Fundamento do Desenho Orientado a Objeto Com UML.Makron Books, 2000.PENDER, Tom. UML a Bíblia. Campus 2004.SANTOS, Lucas Lopes. MySQL. Disponível em: <http://www.malima.com.br/article_read.asp?id=142> Acessado em 26 de abril de2010.SANTOS, Rafael. INTRODUÇÃO À PROGRAMAÇÃO ORIENTDA A OBJETOSUSANDO JAVA. São Paulo: Campus, 2003.SHEPHERD, George. ASP.NET Passo a Passo. São Paulo: Bookmark, 2006.SWAN, Tom. Delphi, Bíblia do Programador. São Paulo: IDG BOOKS 3° Edição,1997.