Sistema de Gerenciamento de Suporte de Tecnologia da Informação para Prefeituras
Descrição do Produto
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE SÃO PAULO – IFSP
EDLAINE GARCIA ROMERO SUELI SAYURI SAITO VANDERLEI BENEDITO DA SILVA FILHO
SISTEMA DE GERENCIAMENTO DE SUPORTE DE TECNOLOGIA DA INFORMAÇÃO PARA PREFEITURAS
Bragança Paulista – SP 2012
INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DE SÃO PAULO– IFSP
EDLAINE GARCIA ROMERO SUELI SAYURI SAITO VANDERLEI BENEDITO DA SILVA FILHO
SISTEMA DE GERENCIAMENTO DE SUPORTE DE TECNOLOGIA DA INFORMAÇÃO PARA PREFEITURAS
Trabalho de Conclusão de Curso apresentado ao Instituto Federal de Educação, Ciência e Tecnologia de São Paulo - IFSP, como parte dos requisitos para conclusão do curso Tecnólogo em Análise e Desenvolvimento de Sistemas.
Orientador (a): Prof. Ms. Leticia Souza Netto Brandi
Bragança Paulista – SP 2012
Romero, Edlaine Garcia Sistema de Gerenciamento de Suporte de Tecnologia da Informação para Prefeituras / Edlaine Garcia Romero, Sueli Sayuri Saito, Vanderlei Benedito da Silva Filho. - Bragança Paulista,2012. –83 f. Monografia de Graduação – Instituto Federal de Educação Ciência e Tecnologia de São Paulo. Orientadora: Prof. Ms. Leticia Souza Netto Brandi
1.Suporte de TI 2. Gerenciamento 3.Software Livre I. Saito, Sueli Sayuri II. Filho, Vanderlei Benedito da Silva
EDLAINE GARCIA ROMERO SUELI SAYURI SAITO VANDERLEI BENEDITO DA SILVA FILHO
SISTEMA DE GERENCIAMENTO DE SUPORTE DE TECNOLOGIA DA INFORMAÇÃO PARA PREFEITURAS
Membros da Banca:
_______________________________________________________________ Profª. Ms. Leticia Souza Netto Brandi - Orientadora Instituto Federal de São Paulo – Campus Bragança Paulista
_______________________________________________________________ Prof. Dr. Luciano Bernardes de Paula Instituto Federal de São Paulo – Campus Bragança Paulista
_______________________________________________________________ Prof. Ms. Cristina Corrêa de Oliveira Instituto Federal de São Paulo – Campus Bragança Paulista
____________________________ NOTA FINAL:
____________________________
TCC aprovado em: ___/___/_____.
DEDICATÓRIA
Este trabalho é dedicado aos profissionais de Tecnologia da Informação, os quais desempenham papel importante nas organizações, sejam elas públicas ou privadas, otimizando o trabalho, gerenciando recursos tecnológicos, contribuindo nas estratégias de negócio e tornando o sistema de informação uma ferramenta essencial, eficaz e eficiente.
AGRADECIMENTOS
Agradecemos, em primeiro lugar, a Deus, por iluminar nossos caminhos e n'Ele encontrarmos fé para a realização dessa etapa acadêmica; à nossa orientadora, Ms. Letícia Souza Netto Brandi, que nos norteou com muita dedicação neste trabalho; aos demais Mestres, pelos conhecimentos transmitidos; ao Instituto Federal de Educação, Ciência e Tecnologia de São Paulo, pela oportunidade e apoio oferecidos, assim como aos demais funcionários, pelos trabalhos desenvolvidos; aos colaboradores da Souza Oliveira Publicidade e servidores municipais da Prefeitura de Atibaia, por compartilharem seus conhecimentos e experiências profissionais e, por fim, aos nossos familiares, amigos e, principalmente, aos companheiros, nossa gratidão pela compreensão e por permanecerem ao nosso lado nessa jornada.
“A primeira regra de qualquer tecnologia utilizada nos negócios é que a automação aplicada a uma operação eficiente aumentará a eficiência. A segunda é que a automação aplicada a uma operação ineficiente aumentará a ineficiência.” Bill Gates
LISTA DE FIGURAS
Figura 1 - Arquitetura geral do RUP ..................................................................................... 20 Figura 2 - Diagramas da UML 2.0 ........................................................................................ 21 Figura 3 - Exemplo de Diagrama de Casos de Uso ............................................................. 23 Figura 4 - Exemplo de Diagrama de Classes ....................................................................... 24 Figura 5 - Exemplo de Diagrama de Sequência ................................................................... 25 Figura 6 - Model View Controller (MVC)............................................................................... 27 Figura 7 - Diagrama de Caso de Uso Gráfico ...................................................................... 42 Figura 8 - Diagrama de Classe Visão de Negócio ................................................................ 57 Figura 9 - Diagrama de Classe Visão de Projeto ................................................................. 58 Figura 10 - Diagrama de Sequência Abrir Chamado ............................................................ 60 Figura 11 - Modelo Entidade Relacionamento ..................................................................... 61 Figura 12 - Tela Inicial do Sistema ....................................................................................... 63 Figura 13 - Context.xml........................................................................................................ 64 Figura 14 - Hibernate.cfg.xml ............................................................................................... 64 Figura 15- Classe HibernateConnection .............................................................................. 65 Figura 16 - Interface DAO .................................................................................................... 65 Figura 17 - Entidade Setor ................................................................................................... 66 Figura 18 - Classe SetorAction ............................................................................................ 66 Figura 19 - Trecho de formulário de cadastro de patrimônio ................................................ 67 Figura 20 - Agenda .............................................................................................................. 67 Figura 21 - Relatório por setor ............................................................................................. 68
LISTA DE TABELAS Tabela 1 - Questionário TI: Questões e Objetivos ................................................................ 39 Tabela 2 - Questionário Demais Setores: Questões e Objetivos .......................................... 39 Tabela 3 - Tabela de Requisitos .......................................................................................... 40 Tabela 4 - Exceções ............................................................................................................ 55 Tabela 5 - Regras de Negócio ............................................................................................. 55 Tabela 6 - Mensagens ......................................................................................................... 56 Tabela 7 - Dicionário de dados ............................................................................................ 61
APÊNDICES
APÊNDICE A - Questionário Setor de TI ............................................................................. 76 APÊNDICE B - Questionário Demais Setores ...................................................................... 77 APÊNDICE C - Gráficos ...................................................................................................... 79 APÊNDICE D - Tela do Github ............................................................................................ 86 APÊNDICE E - Aprovação Comitê de Ética ......................................................................... 87
LISTA DE ABREVIATURAS E SIGLAS
CAU
Central de Atendimento ao Usuário
CPU
Central Processing Unit
CSS
Cascading Style Sheets
DAO
Data Access Object
FSF
Free Software Foundation
FTP
File Transfer Protocol
GPL
General Public Licence
HTML
Hipertext Markup Language
HTTP
HyperText Transfer Protocol
IP
Internet Protocol
MER
Modelo Entidade-Relacionamento
MVC
Model View Controller
OMG
Object Management Group
OMT
Object Modeling Techinque
OOSE
Object-Oriented Software Engineering
PDCA
Plan, Do, Check and Act
RUP
Rational Unified Process
SPB
Software Público Brasileiro
SQL
Structured Query Language
TCP
Transmission Control Protocol
TI
Tecnologia da Informação
UML
Unified Modeling Language
URL
Uniform Resource Locator
SUMÁRIO INTRODUÇÃO..................................................................................................................... 11 1. REVISÃO TEÓRICA ........................................................................................................ 16 1.1 Engenharia de Software................................................................................................. 16 1.1.1 Processos de Software.................................................................................... 16 1.1.2 Rational Unified Process (RUP) ...................................................................... 17 1.2 Unified Modeling Language (UML) ................................................................................. 20 1.2.1 Diagrama de Casos de Uso............................................................................. 22 1.2.2 Diagrama de Classes ...................................................................................... 23 1.2.3 Diagrama de Sequência .................................................................................. 24 1.3 A Linguagem JAVA ........................................................................................................ 25 1.4 Model View Controller (MVC) ......................................................................................... 27 1.5 MySql............................................................................................................................. 27 1.6 Data Access Object (DAO) ............................................................................................ 28 1.7 Software Livre ................................................................................................................ 28 1.7.1 Software Público Brasileiro .............................................................................. 31 1.8 Gestão Pública .............................................................................................................. 31 1.9 Qualidade de Serviço ..................................................................................................... 32 1.9.1 Qualidade em TI – Help Desk .......................................................................... 33 2. METODOLOGIA CIENTÍFICA.......................................................................................... 34 2.1 Quanto à abordagem do problema ................................................................................ 34 2.2 Quanto à natureza ......................................................................................................... 34 2.3 Quanto ao objetivo ......................................................................................................... 34 2.4 Quanto aos métodos...................................................................................................... 35 2.4.1 Método do Estudo de Caso ............................................................................. 35 2.5 Técnicas de Coleta de Dados ........................................................................................ 36 2.5.1 Observação ..................................................................................................... 36 2.5.2 Questionário .................................................................................................... 36 3. DESENVOLVIMENTO ..................................................................................................... 38 3.1 Concepção..................................................................................................................... 38 3.2 Elaboração..................................................................................................................... 57 3.2.1 Diagrama de Classes ...................................................................................... 57 3.2.2 Diagrama de Sequência .................................................................................. 59 3.2.3 Modelagem do Banco de Dados...................................................................... 60 3.3 Construção .................................................................................................................... 63 3.3.1 Implementação ........................................................................................................... 63 3.3.2Testes .............................................................................................................. 68 3.4 Transição ....................................................................................................................... 69 CONSIDERAÇÕES FINAIS ................................................................................................. 70 REFERÊNCIAS BIBLIOGRÁFICAS ..................................................................................... 73
RESUMO
Os sistemas e equipamentos tecnológicos são recursos importantes das organizações. O presente trabalho trata do desenvolvimento de um sistema de código livre que oferece suporte aos serviços prestados pelo setor de Tecnologia da Informação nas Prefeituras. O desenvolvimento do sistema está amparado pela Engenharia de Software, tendo como modelo de processo o RUP; utilizando as tecnologias UML, MySql, Java. Os dados para a elaboração deste trabalho foram coletados através do estudo de caso múltiplo, envolvendo duas prefeituras. Trata-se de uma pesquisa aplicada com abordagem qualitativa, utilizando questionários e a observação participante como técnicas de pesquisa. Constatou-se que os softwares destinados para o gerenciamento e suporte para áreas de TI não contemplavam os processos de agendamento de serviços e emissão de relatórios gerenciais. Desta forma, conclui-se que os objetivos propostos foram alcançados com sucesso. Destaca-se que os módulos de “Agendamento” e “Emissão de Relatórios” preencheram as lacunas existentes no segmento de softwares para esta finalidade. O emprego de software livre proporcionou duas vantagens significativas tais como a financeira pela redução de custos com relação a aquisição de software e o ganho técnico através do acesso ao código fonte de forma a facilitar as customizações. Palavras- chave: Suporte de TI, Gerenciamento, Software Livre, Prefeitura, Tecnologia da Informação.
ABSTRACT
Technological equipment and systems are organizations’ important resources. This paper is about the development of a free source system that offers support to services provided by Informational Technology sectors in City Halls. The development of the referred system is sustained by Software Engineering, having RUP as it’s process model; using technologies UML, MySql, JAVA. The required data in order to prepare this work was collected through multiple case study, which involved two City Halls. It is an applied research with a qualitative approach, with questionnaires and participatory observation among it’s research techniques. It was found that the softwares intended for management and supporting of IT sectors did not comprehended the process of job scheduling and management reporting. Thus, it is concluded that the proposed objectives were successfully achieved. It must be highlighted the fact that the modules for “Scheduling” and “Reporting” filled the gaps found in softwares of this segment. The usage of free software provided two significant advantages such as the economic, through the reduction of expenses when compared to the acquisition of softwares and the technical profit through the source code access, in order to facilitate customizations. Keywords: IT Support, Management, Free Software, City Hall, Information Technology.
11
INTRODUÇÃO
Os sistemas e equipamentos tecnológicos direcionados ao setor público são recursos de grande importância, pois são ferramentas necessárias para administrar questões financeiras, jurídicas, públicas, etc. Porém, para um funcionamento eficaz e eficiente desses recursos, deve haver uma boa equipe técnica na área de Tecnologia da Informação1. A tecnologia da informação permite que todos os processos públicos sejam migrados para rotas de dados, facilitando assim a integração entre secretarias, fundações, rotinas burocráticas e orçamentárias no âmbito público. (MACEDO, 2007, p.3).
Uma ferramenta de gerenciamento de suporte de TI ajuda a buscar soluções para os problemas cotidianos dos usuários e otimizar o trabalho dos gestores de suporte. Para Faria (2004, apud RODRIGUEZ e VIEIRA 2007, p.210) o diferencial competitivo de uma empresa e sua sustentabilidade estão cada vez mais ligados à sua capacidade e rapidez de inovação. Este trabalho propõe a elaboração de um sistema de código livre que gerencie o atendimento do suporte técnico do setor de TI de prefeituras.
Visão Geral do Problema
A Prefeitura A possui cerca de dois mil e quinhentos servidores e a Prefeitura B possui cerca de quatro mil e trezentos, sendo a maioria usuários de microcomputadores interligados em rede. Este projeto definiu-se devido à convivência com as dificuldades existentes em ambas as prefeituras, seja realizando ou recebendo os serviços de suporte de TI. Há um grande número de sistemas e de equipamentos, muitos obsoletos, no parque computacional, porém o número de profissionais qualificados para atender a demanda é reduzido. O perfil de usuário é de baixo a médio conhecimento em informática, utilizando os equipamentos em tempo integral, com atividades diversas, não tendo recebido nenhum tipo de treinamento e necessitando constantemente do suporte de TI, além disso, os funcionários têm dificuldade em aceitar novas tecnologias, impondo barreiras às implantações.
1
Tecnologia da Informação. Doravante tratada como TI.
12
Outra característica do cenário estudado é a opção por softwares livres, mas seus usuários têm dificuldade em assimilá-los, possuem um preconceito quanto à sua utilização, dando preferência a softwares proprietários. Existem questões políticas, como troca de prefeito, secretários, coordenadores, entre outros, além de servidores com cargos comissionados que constantemente são renovados, gerando alta rotatividade nos setores, o que exige uma constante manutenção dos dados dos funcionários. A comunicação entre os setores, e mesmo dentro de cada setor, é falha, originando solicitações duplicadas, reincidências e problemas que poderiam ser evitados com informações internas. As formas atuais de acionar o suporte são via telefone, email ou memorando; essas não são eficazes pois frequentemente os ramais estão ocupados ou não são atendidos devido ao grande número de solicitações, acarretando reclamações e demora na resolução dos problemas. Outro problema está no fato de os usuários não saberem a ordem de prioridade dos serviços, previsão de término ou situação em que se encontra a sua solicitação. Pendências, reclamações e sugestões dificilmente são anotadas e, quando são, não há controle sobre esses processos. Cada servidor que presta o suporte de TI age de forma específica, não havendo padronização no atendimento. Como muitos dos atendimentos devem ser realizados de forma presencial, a falta de funcionários e a dificuldade de locomoção aumentam o tempo de resposta e deixam a equipe desfalcada. A demora ou não resolução dos problemas junto ao suporte de TI afeta não somente os servidores públicos, mas também os contribuintes, que muitas vezes precisam aguardar por muito tempo ou retornar em outro momento, o que causa impaciência e reclamações. O sistema atual permite a abertura de chamados apenas pelos profissionais de TI, não possibilita o agendamento de tarefas, não emite relatórios para o controle de demanda e, para seu funcionamento, necessita da instalação local no computador a ser utilizado, não proporcionando a otimização das atividades realizadas. Os softwares livres de suporte de TI disponíveis não possuem um controle de bens patrimoniais e não possibilitam o agendamento de tarefas em um único programa. O alto fluxo de trabalho, as prioridades das equipes de desenvolvimento das prefeituras e as restrições orçamentárias inviabilizam a elaboração ou compra de um novo sistema. Analisando os problemas citados, questiona-se:
13
De que maneira um novo sistema vai melhorar a confiabilidade, desempenho e atuação dos profissionais de TI? Quais funcionalidades do sistema de suporte do setor de TI devem ser contempladas? Qual padrão de desenvolvimento deve ser empregado para a elaboração do sistema? O objetivo geral do presente trabalho é desenvolver um sistema de código livre para dar suporte aos serviços prestados pelo setor de Tecnologia da Informação para prefeituras. Para a realização do objetivo geral foram elencados os seguintes objetivos específicos:
Manter um cadastro dos funcionários de TI com os devidos perfis de
autorização;
Desenvolver
aplicativos
para
controlar
os equipamentos
do
parque
computacional;
Registrar os tipos de serviços prestados;
Cadastrar os setores da prefeitura;
Controlar os chamados técnicos executados;
Desenvolver uma agenda para as atividades a serem realizadas;
Emitir relatórios do sistema;
Acompanhar o fluxo de informação das requisições.
O bom desempenho de uma empresa, pública ou privada, está diretamente ligado à qualidade dos serviços de TI, cujo gerenciamento eficaz proporciona confiabilidade e comodidade para todos os setores, evitando falhas e resolvendo problemas em menor tempo. O setor público possui recursos escassos e que devem ser utilizados de forma a criar sistemas de informação capazes de responder às questões de gerenciamento de forma eficaz. A implantação de softwares livres tende a ser mais barata do que a de sistemas proprietários, além de sua segurança e manutenção não dependerem diretamente de terceiros. A escolha do desenvolvimento deste projeto para prefeituras é respaldada pelo fato de que dois dos integrantes da equipe são funcionários da Administração Municipal de diferentes cidades.
Um deles trabalha no setor de Tecnologia da Informação, lidando
diretamente com os problemas mencionados acima. A outra integrante trabalha no setor de
14
protocolo, sendo usuária dos sistemas e equipamentos de informática. Dessa forma, as fases de levantamento de requisitos e a etapa de implementação foram facilitadas. Os dois integrantes levantaram diferentes visões nas suas respectivas prefeituras. Na Prefeitura A há ausência de investimentos em tecnologia em toda prefeitura, onde boa parte do parque computacional é composta por equipamentos obsoletos. Há um grande fluxo de acionamento ao suporte devido à falta de conhecimento dos usuários quanto à manipulação de equipamentos e softwares. O número de profissionais qualificados é pequeno em relação ao grande número de usuários e equipamentos tecnológicos existentes, e há grande dificuldade de se realizarem novas contratações, nos últimos 15 anos apenas um concurso público possuía vaga para o setor. Na Prefeitura B nota-se que devido ao desconhecimento da burocracia e outros problemas com relação às solicitações de serviços de suporte, o usuário, instintivamente, acaba por reclamar e reivindicar soluções rápidas dos técnicos, causando transtornos e aborrecimentos para todas as partes envolvidas,
inclusive ao
contribuinte que,
indiretamente, também necessita do sistema. É evidente certo grau de insatisfação dos usuários solicitantes, justamente por não obter um resultado eficaz e eficiente de suas solicitações. A morosidade das requisições torna o problema ainda mais agravante em algumas situações. Pode ser tomado como exemplo, um contexto político, o qual, a manutenção dos equipamentos de um setor de chefia, é tratado com alta prioridade, enquanto as dos demais servidores, embora necessitem também de reparos urgentes, são postos em segundo plano. Nos dois ambientes foi possível notar uma grande falta de treinamento aos usuários e que o compartilhamento de informação juntamente com a existência de profissionais qualificados é fator importantíssimo para o bom relacionamento e processo das atividades nas organizações públicas municipais. Evidenciam-se diferenças estruturais existentes nas prefeituras em questão, onde a Prefeitura A mostra-se mais organizada, possui a Coordenadoria Especial de Tecnologia da Informação, com 10 funcionários e 4 estagiários atendendo a demanda. Na Prefeitura B há uma Divisão de TI ligada a Secretaria de Administração, contendo apenas 5 funcionários. Apesar dessas diferenças, muitos problemas são semelhantes e podem ser resolvidos da mesma maneira. Este trabalho é dividido em quatro partes, sendo cada uma delas focada em diferentes fases do projeto. O Capítulo um introduz a revisão teórica de cada ferramenta e os conceitos utilizados na construção do Sistema de Gerenciamento de Sistema, a começar pela Engenharia de Software, importante referência para produção de um software de qualidade, sendo que o
15
método escolhido para esta aplicação é o RUP. Continua com as descrições de UML, instruindo a modelagem do projeto, seguido por fundamentos de Java, que aponta as principais características dessa linguagem; apresenta, também, uma breve explicação de MVC, MySql e DAO, além de definições sobre software livre, gestão pública e qualidade de serviços, importantes itens para a composição estrutural desse trabalho. O Capítulo dois apresenta a metodologia utilizada nesta pesquisa, refere-se ao tipo de abordagem, trata do objetivo e da natureza, dos métodos de pesquisa e descreve técnicas para coleta de dados, que são essenciais para o levantamento de requisitos do sistema. O Capítulo três é responsável pela descrição de todas as fases do desenvolvimento do software, agregando os conhecimentos do processo RUP, modelo de iteração, de acordo com padrões de construção. O capítulo demonstra todo procedimento adotado desde a concepção, iniciado pelo levantamento de requisitos, estudo do caso de uso; seguido pela elaboração, modelagem de diagramas, banco de dados; passando pela construção, etapa em que o cliente já pode visualizar protótipos do sistema e, por último, a transição, que se refere à transferência ao cliente. Para concluir o trabalho, expõem-se as considerações finais e projetos de trabalhos futuros. Analisa-se todo o processo executado, a fim de oferecer soluções para o problema apresentado, sugerindo, ainda, a sua continuação, visando o aperfeiçoamento do sistema, uma vez que esse é uma ferramenta que otimiza o suporte de TI nas prefeituras.
16
1. REVISÃO TEÓRICA
Este capítulo apresenta um breve referencial teórico sobre as áreas envolvidas no presente trabalho. São apresentados conceitos de Engenharia de Software, UML, JAVA, MVC, MySql, Padrão DAO, Software Livre, Gestão Pública e Qualidade de Serviço.
1.1 Engenharia de Software
Para Sommerville (2011, p.2), o mundo em que vivemos não existiria sem os softwares, pois o uso de sistemas computacionais está presente desde segmentos industriais às áreas de entretenimento. O autor conclui que a Engenharia de Software é essencial para o funcionamento de sociedades nacionais e internacionais. A engenharia de software tem por objetivo apoiar o desenvolvimento profissional de software, mais do que a programação individual. Ela inclui técnicas que apoiam especificação, projeto e evolução de programas, que normalmente não são relevantes para o desenvolvimento de software pessoal (SOMMERVILLE, 2011, p.3).
A Engenharia de Software abrange um processo, métodos e ferramentas que permitem o desenvolvimento de softwares de alta qualidade pelos profissionais (PRESSMAN, 2011, p.29). Sommerville (2011, p.2) enfatiza que um software não trata apenas do programa em si, mas de toda a documentação associada e dados de configurações necessários para o programa operar corretamente.
1.1.1 Processos de Software
Segundo Pressman (2011, p.40), o processo é composto de várias atividades, ações e tarefas que serão realizadas no desenvolvimento de um produto.
No contexto da
Engenharia de Software, um processo é uma abordagem adaptável que permite realizar o trabalho de selecionar e escolher o conjunto apropriado de ações e tarefas, com o objetivo de entregar o software dentro do prazo e com a qualidade suficiente para satisfazer às expectativas. Pressman (2011, p.40-41) cita cinco atividades que compreendem a engenharia de software como modelo de metodologia genérico: a) Comunicação;
17
b) Planejamento; c) Modelagem; d) Construção; e) Emprego. A comunicação é essencial para compreender objetivos de todas as partes interessadas, levantar necessidades, definir funções e características do software. Para um projeto de software, a atividade de planejamento cria um “mapa”, que servirá de guia, descrevendo tarefas técnicas a serem conduzidas, riscos, recursos necessários, produtos resultantes e um cronograma de trabalho. A modelagem é criada pelo engenheiro de software, na tentativa de compreender melhor o problema, através de um “esboço”, para que se possa ter ideia do todo. Quanto à construção, esta refere-se à geração de códigos e testes. Com relação ao emprego, o software é entregue ao cliente, que avalia e fornece o feedback2 de sua avaliação. Processos de software são complexos e, para serem corretamente desenvolvidos, dependem das decisões de muitas pessoas. Não existe um processo ideal, podendo as organizações desenvolverem seus próprios processos (SOMMERVILLE, 2011, p.19).
1.1.2 Rational Unified Process (RUP) Martins (2006, p.175) define RUP como uma metodologia para gerenciar projetos de desenvolvimento de software que usa a UML como ferramenta para especificação de sistemas, composto por um conjunto de disciplinas que fornecem diretrizes para definição das tarefas e atribuição da alta qualidade, atendendo às necessidades do cliente e dos usuários, bem como às restrições de prazo e custo. O RUP provê as seguintes ferramentas e recursos (MARTINS, 2006, p.176-186): a. Desenvolvimento iterativo: O objetivo é conduzir o projeto em iterações. Cada iteração é tratada de forma tradicional, alguns requisitos e riscos mais críticos são abordados, há um pouco de análise, implementação, teste e implantação. Depois há outra iteração, com outros requisitos, riscos, há mais análise, implementação, teste e implantação, até a conclusão do projeto. b. Gerenciamento de requisitos: Requisito é uma característica que o sistema precisa apresentar. O projeto deve ser planejado e conduzido de modo a incorporar facilmente as mudanças, identificando os requistos mais importantes. Os requisitos são dinâmicos e mudam por vários motivos durante a vida do projeto. c. Arquitetura baseada em componentes: 2
Resposta. Michaelis Dicionário Prático Inglês/ Português - Nova Ortografia
18
Pode-se definir componente como um pedaço de software, um módulo, um pacote ou um subsistema, que executa uma função específica e coesa. Juntos, os componentes formam a arquitetura. A abordagem baseada em componentes viabiliza o reuso e a personalização de componentes em larga escala. d. Organização da especificação em "modelos": Um modelo é uma simplificação da realidade que descreve o sistema a partir de determinado ponto de vista. O RUP trabalha como modelos providos pelo UML. O uso de modelos ajuda a equipe a visualizar, especificar, construir e documentar a estrutura e o comportamento do software. e. Verificação constante da qualidade: A correção de problemas de software é mais cara de realizar após a implantação, por isso, é importante controlar e garantir a qualidade do sistema durante todo o ciclo de vida do projeto. A verificação da qualidade requer a criação de testes para cada cenário e provê soluções para as causas mais comuns de fracasso de projetos. f. Controle de mudanças: Tem como objetivo controlar as versões dos artefatos criados e modificados durante o projeto. g. Organização do sistema com estrutura estática e dinâmica: Quanto à estrutura estática, os processos RUP definem os papéis, atividades, artefatos trabalhados e os procedimentos que devem ser executados, definindo "quem" está executando "o quê" e "quando". A abordagem iterativa foi concebida para ser dinâmica e adaptativa, acomodando mudanças de objetivos e estratégias. h. Trabalho com processos focados na arquitetura e nos casos de uso: Grande parte do foco do RUP está na modelagem, facilitando o entendimento e a representação do problema e da solução. Tipicamente a modelagem é desenvolvida em três aspectos: conceitual, lógico e físico. O RUP trabalha com uma abordagem dirigida pelos casos de uso, que detalham os requisitos funcionais do ponto de vista do usuário, servindo como uma espécie de contrato entre o cliente e o desenvolvedor. Martins (2006, p.186-221) elenca seis processos de engenharia e três de suporte para o RUP, no qual cada processo é tratado como uma disciplina. Processos de Engenharia:
a. Modelagem do negócio:
19
No Modelo de Negócio estão documentados os conceitos pertinentes ao negócio. b. Captura dos requisitos: Possibilita a definição das características do sistema conforme observadas pelo cliente, apontando o desenvolvimento para a direção correta. c. Análise e design: Tem como objetivo traduzir os requisitos em uma especificação que indique como o sistema deve ser implementado. Define a arquitetura selecionada, o ambiente operacional, a performance, entre outros. d. Implementação: Durante este processo são construídas várias versões operacionais do sistema ou de parte dele a fim de demonstrar sua funcionalidade. e. Teste: A cada iteração o software é testado, num processo de avaliação contínua de qualidade. f. Implantação: Tem o objetivo de disponibilizar o sistema para os usuários. Processos de Suporte:
a. Gerenciamento do projeto: Envolve o gerenciamento de todo o projeto durante seu ciclo de vida. b. Gerenciamento de configuração e mudanças: Tem o objetivo de registrar e manter uma trilha das mudanças e da evolução dos artefatos produzidos. c. Gerenciamento do ambiente: Define os processos e ferramentas para a empresa que está desenvolvendo o sistema. Por fim, o RUP é composto por quatro fases (MARTINS, 2006, p. 225-228): a. Concepção: na qual a preocupação é estabelecer uma visão do sistema do ponto de vista do negócio, avaliando se o projeto é viável; b. Elaboração: cujo objetivo é capturar os requisitos ainda não identificados e definir uma arquitetura sólida; c. Construção: quando o sistema e a documentação destinada ao usuário são criados;
20
d. Transição: com o foco em transferir o produto para a comunidade de usuários. Cada fase é executada em uma ou mais iterações e não seguem uma sequência tradicional de requisitos, análise, programação, integração e testes. A Figura 1 ilustra o ciclo de vida do processo, as quatro fases do RUP, e o fluxo de processos, representado por suas disciplinas.
Figura 1 - Arquitetura geral do RUP Fonte: Peraire et al. p.12
1.2 Unified Modeling Language (UML)
Segundo Guedes (2011, p.19) a UML, ou Linguagem de Modelagem Unificada, é uma linguagem visual usada para modelar sistemas orientados a objeto. A construção da UML teve diversos colaboradores, sendo seus principais contribuintes Grady Booch, James Rumbaugh e Ivar Jacobson, conhecidos como "os três amigos" (BEZERRA, 2007, p.15). Surgiu da união dos três métodos de modelagem mais populares até meados da década de 1990, propostos pelos três amigos: método de Booch, método OMT (Object Modeling Techinque) de Jacobson e o método OOSE (Object-Oriented Software Engineering) de Rumbaugh (GUEDES, 2011, p.19).
21
Em 1997, a UML foi aprovada como linguagem-padrão de modelagem pela OMG3. Sua definição continua em desenvolvimento e conta com muitos colaboradores (BEZERRA, 2007, p.15). Em 2005 foi lançada a versão 2.0 da linguagem que, atualmente, se encontra na versão 2.3 beta. Sua documentação pode ser consultada no site www.uml.org, da OMG. (GUEDES, 2011, p.20). Guedes (2011, p.19) ressalta que a UML não é uma linguagem de programação, mas sim uma linguagem de modelagem, com o objetivo de auxiliar os engenheiros de software a definirem as características do sistema, como seus requisitos, seu comportamento, estrutura lógica, a dinâmica de seus processos e suas necessidades físicas em relação ao equipamento sobre o qual o sistema será implantado. Grandes projetos não podem ser modelados de cabeça, nem mesmo a maioria dos pequenos projetos pode sê-lo; Guedes (2011, p.20) afirma que qualquer sistema deve ser modelado anteriormente à sua implantação, pois os sistemas de informação costumam ter a propriedade de "crescer", ou seja, são dinâmicos e estão em constante mudança. Um processo de desenvolvimento que utilize a UML envolve a criação de diversos documentos, que podem ser textuais ou gráficos. Esses documentos são chamados de artefatos de software. Os artefatos gráficos podem ser definidos pela utilização dos diagramas da UML (BEZERRA, 2007, p.17). A UML 2.0 possui 13 diagramas descritos na Figura 2.
Figura 2 - Diagramas da UML 2.0 Fonte: Bezerra (2007, p.18)
3
Object Management Group - consórcio internacional de empresa que define e ratifica padrões na área da orientação a objetos.
22
A UML possui um número grande de diagramas com o objetivo de fornecer múltiplas visões do sistema a ser modelado, analisando sob diversos aspectos de maneira a permitir que um diagrama complete o outro e que cada diagrama analise o sistema, ou parte dele, sob determinada óptica (GUEDES, 2011, p.19). Conforme Bezerra (2007, p.15) cada elemento gráfico possui uma sintaxe, que corresponde à forma predeterminada de desenhar o elemento, e uma semântica, que define o que significa o elemento e com qual objetivo o mesmo deve ser criado. As ferramentas de modelagem automatizadas (ferramentas CASE) se tornaram comuns, mas a maioria dos símbolos mais úteis da UML pode ser esboçada com papel e lápis, anteriormente à sua transposição para um meio eletrônico (PAGE-JONES, 2001, p.85).
1.2.1 Diagrama de Casos de Uso
O diagrama de casos de uso é o diagrama mais geral e informal da UML: possui uma linguagem simples para que os usuários tenham uma ideia geral de como o sistema irá se comportar, sendo utilizado principalmente nas fases de levantamento e análise de requisitos; além disso, pode ser consultado durante todo o processo de modelagem e servir de base para outros diagramas (GUEDES, 2011, p.30). Guedes (2011, p.30-31) explica que o diagrama procura identificar os atores (usuários, outros sistemas ou algum hardware especial) que utilizarão o software, bem como os serviços (funcionalidades) que o sistema disponibilizará aos atores. Na Figura 3 é apresentado um exemplo de diagrama de casos de uso, nesse caso um Sistema de Controle Bancário.
23
Figura 3 – Exemplo de Diagrama de Casos de Uso Fonte: Guedes (2011, p.31)
1.2.2 Diagrama de Classes
O diagrama de classes é provavelmente o mais utilizado e um dos mais importantes da UML uma vez que serve de apoio para a maior parte dos outros diagramas, definindo a estrutura das classes utilizadas pelo sistema, determinando os atributos e métodos de cada classe e estabelecendo como as classes se relacionam e trocam informações entre si (GUEDES, 2011, p.31).
24
A Figura 4 contém um exemplo de diagrama de classes de um Sistema de Controle Bancário.
Figura 4 - Exemplo de Diagrama de Classes Fonte: Guedes (2011, p.32)
1.2.3 Diagrama de Sequência
Guedes (2011, p.33) define o diagrama de sequência como um diagrama comportamental que se preocupa com a ordem temporal em que as mensagens são trocadas entre os objetos de um processo. Em geral, baseia-se em um caso de uso específico e apoia-se no diagrama de classes para determinar os objetos. Na Figura 5 é apresentado um exemplo de diagrama de sequência, segundo o caso de uso Emitir Saldo, exibido na Figura 3.
25
Figura 5 - Exemplo de Diagrama de Sequência Fonte: Guedes (2011, p.34)
1.3 A Linguagem JAVA
A revolução do microprocessador provocou um impacto profundo em dispositivos eletrônicos inteligentes de consumo popular. Devido a isso, a Sun Microsystem, em 1991, financiou um projeto de pesquisa corporativa interna que resultou em uma linguagem com base em C++ (DEITEL, 2010, p.6). O mercado de dispositivos eletrônicos inteligentes para o consumidor final não se desenvolvia com a velocidade prevista pela Sun. Contudo, com a explosão em popularidade da Web, em 1993, a Sun viu a possibilidade de utilizar o potencial da linguagem JAVA para adicionar conteúdo dinâmico às páginas da Web (DEITEL, 2010, p.6). De acordo com Deitel (2010, p.6) a Sun anunciou formalmente o JAVA em uma conferência em maio de 1995. Atualmente, ele é usado para desenvolver aplicativos corporativos de grande porte, aprimorar a funcionalidade de servidores Web, fornecer aplicativos para dispositivos voltados ao consumo popular, entre outros propósitos. Horstmann (2010, p.1-4) descreve 11 características-chave da linguagem JAVA: a) simples; b) orientada a objetos;
26
c) compatibilidade com redes; d) robusto; e) seguro; f)
possui arquitetura neutra;
g) portável; h) interpretado; i)
alto desempenho;
j)
múltiplas threads;
k) dinâmico.
O JAVA possui uma versão mais limpa da sintaxe do C++, ainda que não pareça tão simples quando comparado a ambientes visuais (como Visual Basic), por necessitar de mais código inserido manualmente. Outro aspecto que ressalta sua simplicidade é o seu reduzido tamanho: o tamanho do interpretador básico é de cerca de 40 quilobytes (Kb), e a incorporação das bibliotecas-padrão básicas e suporte de thread adicionam apenas 175 quilobytes (Kb) ao seu tamanho total. É orientado a objetos, focalizando os dados e interfaces com esses objetos. Tem uma extensa biblioteca de rotinas para lidar com protocolos TCP/IP como HTTP e FTP, seus aplicativos podem abrir e acessar objetos pela Internet via URLs com a mesma facilidade que ao acessar um sistema local. Quanto à sua robustez, a linguagem JAVA coloca ênfase na verificação preliminar de possíveis problemas, verificação dinâmica posterior e eliminação de situações propensas a erros. Por ser concebido para ser usado em ambientes em rede, apresenta muita ênfase à segurança, permitindo a construção de sistemas livres de vírus e adulterações. O compilador gera um formato de arquivo de objetos neutro quanto à sua arquitetura e o código compilado é executável em muitos processadores. Não há nenhuma dependência de implementação. Sua portabilidade permite ser executado em diferentes plataformas e seu interpretador pode executar bytecodes JAVA diretamente em qualquer máquina. Ainda, esses bytecodes podem ser convertidos instantaneamente em código de máquina para a CPU específica, aumentando o desempenho. O JAVA possui múltiplos threads, trazendo como benefício uma melhor responsividade interativa e comportamento em tempo real. O JAVA é uma linguagem mais dinâmica que C ou C++ uma vez que, tendo sido projetada para adaptar-se a um ambiente em evolução, suas bibliotecas podem adicionar livremente novos métodos e variáveis de instância sem nenhum efeito sobre seus clientes.
27
1.4 Model View Controller (MVC)
O MVC é um modelo de desenvolvimento de software. Segundo Fowler (2006, p.315) o MVC considera três papéis distintos: Vista, Controlador e Modelo. O modelo é um objeto que representa uma informação sobre o domínio. A vista representa a exibição do modelo na interface de usuário, dizendo respeito apenas à apresentação de informações, uma vez que as alterações destas informações são manipuladas pelo controlador. O controlador recebe a entrada do usuário, manipula o modelo e faz com que a vista seja atualizada apropriadamente (FOWLER, 2006, p.315). O autor ainda afirma que a separação entre a apresentação e o modelo é um dos mais importantes princípios do projeto de software, e só não deve ser usado em sistemas muito simples, onde o modelo não tem nenhum comportamento real.
Na Figura 6 podemos visualizar os três papéis do MVC.
Figura 6 - Model View Controller (MVC) Fonte: Fowler (2006, p.315)
1.5 MySql
Manzano (2007, p.14) define que SQL (Structured Query Language - Linguagem Estruturada de Consulta) não é uma linguagem de programação, mas sim uma linguagem declarativa utilizada para facilitar o acesso às informações armazenadas em banco de dados relacional, que armazena os dados e informações em tabelas formadas por linhas (registros) e colunas (campos). Ainda segundo Manzano (2007, p.17) o programa MySql é um sistema de gerenciamento de banco de dados relacional que utiliza o SQL como interface de acesso e extração de informações de um banco de dados em uso.
28
O MySql surgiu de um projeto interno da empresa sueca Tcx DataKonsult AB, por iniciativa dos funcionários. O projeto batizado de MySql foi liberado ao público geral no fim de 1996 e, em 2001, foi fundada uma empresa totalmente baseada na oferta de produtos e serviços específicos relacionados ao MySql, a MySqlAB (GILMORE, 2008, p.487). O MySql é um dos sistemas de gerenciamento de bancos de dados de maior popularidade no mundo. É rápido, multitarefa e multiusuário (MANZANO, 2007, p.17). Gilmore (2008, p.498-500) reforça a popularidade do MySql citando alguns recursos: a) Flexibilidade: o MySql atende a vários sistemas operacionais; b) Capacidade: desde o início os desenvolvedores focaram o desempenho, mesmo com o crescimento de capacidades que antes faltavam, o compromisso com a velocidade não foi alterado;
c) Segurança: apresenta grande quantidade de opções de segurança e configuração.
O MySql possui opções flexíveis de licença, sendo liberado sob duas licenças: a de código aberto, versão gratuita com liberdade para usar com um software também de código aberto; e a Commercial License, disponível para aqueles que preferirem não liberar o código do projeto (GILMORE, 2008, p. 500-501).
1.6 Data Access Object (DAO)
Segundo Trottier (2004, apud DESCHAMPS, 2010, p.30) o padrão de projeto DAO provê uma conexão entre a camada de regra de negócio e a de persistência da aplicação de forma transparente. Assim, todo o acesso à fonte de dados é abstraído e encapsulado, escondendo os detalhes de sua implementação dos componentes de negócio que o utilizam.
1.7 Software Livre
O movimento do software livre é um movimento pelo compartilhamento do conhecimento tecnológico. Teve início na década de 1980 e se espalhou pelo mundo (SILVEIRA, 2004, p.5). Silveira (2004, p.5-6) cita como principais defensores desse movimento hackers, acadêmicos, cientistas, combatentes pela causa da liberdade e forças político-culturais. Os maiores opositores são as megaempresas, que vivem de um modelo econômico baseado na
29
exploração de licenças de uso de software, governantes, frações burocráticas e políticos que querem bloquear a disseminação dos conhecimentos sobre software, além de agentes pragmáticos interessados no financiamento que podem receber dos megagrupos. O software livre se refere a quatro tipos de liberdade, definidas pela Free Sotware Foundation4, para os usuários do software (FIGUEIREDO et al, 2005, p.27): a)
A liberdade de executar o programa, para qualquer propósito (liberdade nº 0);
b)
A liberdade de estudar como o programa funciona e adaptá-lo para as suas necessidades (liberdade nº 1). O acesso ao código-fonte é um pré-requisito para esta liberdade;
c)
A liberdade de redistribuir cópias de modo que você possa ajudar ao seu próximo (liberdade nº 2);
d)
A liberdade de aperfeiçoar o programa, e liberar os seus aperfeiçoamentos, de modo que toda a comunidade se beneficie deles (liberdade nº 3). O acesso ao código-fonte é um pré-requisito para esta liberdade.
Silveira (2004, p.9) define software proprietário como um modelo de desenvolvimento e distribuição baseado em licenças restritas de uso, no qual fala-se em autoria e propriedade do software. Esse modelo esconde os algoritmos que o compõem. Muitos usuários não sabem que não estão comprando um produto mas sim uma licença de uso, a propriedade do software continua com a empresa que o desenvolve. Ainda conforme Silveira (2004, p.15) software livre é Open Source, ou seja, é um software que possui o código-fonte aberto. É importante distinguir algumas categorias: software aberto, software gratuito e software livre. Muitos softwares gratuitos são proprietários e muitos de fonte aberta não asseguram as quatro liberdades do software livre. A maior parte dos softwares livres utiliza a GPL, General Public Licence (Licença Pública Geral). Criada pela Free Software Foundation, a GPL é uma licença que usa os princípios do direito autoral com o objetivo de proteger o software livre e assegurar que ninguém possa torná-lo proprietário. Dentro da GPL existe o chamado copyleft, que usa o copyright, que restringe o direito de cópia, para assegurar o seu inverso, a liberdade de copiar. A copyleft impõe uma restrição: nenhum software dele derivado poderá se tornar proprietário (SILVEIRA, 2004, p.19). Aguiar et al. (2009, p.35-36) destaca três dos vários motivos para se optar por usar software livre: os motivos técnicos, uma visão que se baseia unicamente na excelência técnica do software; os motivos sociais, que denotam independência, em grande parte dos 4
FSF - Fundação para o Software Livre - é uma organização sem fins lucrativos, fundada em 4 de Outubro de 1985 que se dedica a eliminação de restrições sobre a 'cópia, redistribuição, estudo e modificação de programas de computadores.
30
casos envolvidos em projetos de inclusão digital em comunidades desfavorecidas; e os motivos financeiros, afinal muitos não querem ou não podem pagar pelo alto preço das licenças. Silveira (2004, p.38-41) elenca cinco argumentos para a adoção de software livre como paradigma do desenvolvimento e uso das tecnologias da informação no governo: a)
argumento macroeconômico;
b) argumento de segurança; c) argumento da autonomia tecnológica; d) argumento da independência de fornecedores; e) argumento democrático.
Do ponto de vista macroeconômico, a adoção do software livre permite diminuir o envio de royalties pelo pagamento de licenças de software, gerando maior sustentabilidade do processo de inclusão digital e de informatização e modernização das empresas e instituições. Sob o aspecto de segurança o software proprietário se afirma na ausência de transparência do seu código-fonte, que deve permanecer fechado para seu usuário, já o software aberto pode ser completamente auditado pelos usuários. Sob o argumento da autonomia tecnológica, amplia as condições de autonomia e capacitação tecnológica do país,
já que permite que usuários também
sejam
desenvolvedores. Quanto à independência de fornecedores, quando o governo opta por este padrão ele se esquiva do posterior aprisionamento à empresa que desenvolveu o software. No argumento democrático, as tecnologias de informação e comunicação estão se consolidando como meios de expressão do conhecimento, de expressão cultural e de transações econômicas. A limitação a seu acesso passa a ser percebida como violação dos direitos fundamentais. Ao atingir uma fase em que a informação ocupa posição cada vez mais central como força produtiva, o capitalismo atinge o estágio em que o compartilhamento e a distribuição do conhecimento tecnológico podem gerar mais riqueza do que o seu tradicional modelo baseado na propriedade privada dos meios de produção. O valor agregado a um software livre desenvolvido em rede tende a ser maior que os desenvolvidos pela indústria de software proprietário. (SILVEIRA, 2004, p.7)
A Free Software Foundation disponibiliza em seu site (www.fsf.org) as definições precisas sobre o que é software livre.
31
1.7.1 Software Público Brasileiro
Cardoso, Meffe e Martins (2011, p.28) definem o Software Público Brasileiro, SPB, como um dos alicerces para conduzir a política de desenvolvimento, distribuição e uso de software pelo setor público no Brasil. O modelo adota o exemplo do padrão de desenvolvimento para software livre no qual os participantes cooperam intensivamente sem restrições aparentes e encontram seu ambiente de produção colaborativa na Internet. O software pode ser usado por todos sem que se estabeleça competição entre seus usuários, uma vez que, se um ou muitos o utilizam, os demais não perdem a possibilidade de vir a usá-lo. Isto permite que o software pode ser considerado um bem público e passível de ser tratado como política pública. Há ainda a possibilidade de aprimorar seus recursos por diferentes atores, abrindo oportunidades de sua qualidade ser ampliada através da disseminação de seu código-fonte, documentação associada e da efetiva colaboração dos usuários e desenvolvedores (CARDOSO, MEFFE e MARTINS, 2011, p.28). No
Portal
SPB,
que
pode
ser
acessado
através
do
endereço
www.softwarepublico.gov.br, estão disponíveis, gratuitamente, soluções desenvolvidas por órgãos públicos, empresas, universidades e até mesmo pessoas físicas. Qualquer organização ou pessoa interessada pode obter o código das soluções mediante cadastramento no Portal. Não há custo com a licença de uso, mas há um incentivo para que se compartilhem as melhorias incorporadas às soluções (CARDOSO, MEFFE e MARTINS, 2011, p.28). Ainda segundo Cardoso, Meffe e Martins (2011, p.29) o que rege o Software Público Brasileiro é a Instrução Normativa N.01 de 17 de Janeiro de 2011, que dispõe sobre os procedimentos para o desenvolvimento, a disponibilização e o uso do SPB. O SPB é uma iniciativa pioneira no mundo e tem chamado atenção de importantes instituições internacionais.
1.8 Gestão Pública
Neste projeto, o conceito de Gestão Pública é essencial para o entendimento da postura burocrática e de limitações existentes para qualquer procedimento na organização. Para Dias (1998, apud PIRES e MACEDO, 2006), as organizações públicas têm como objetivo prestar serviços à sociedade. Podendo ser consideradas como: sistemas dinâmicos,
muito
complexos,
independentes
e
inter-relacionados
coerentemente,
envolvendo informações e seus fluxos, estruturas organizacionais, pessoas e tecnologias.
32
Ainda, buscam cumprir suas funções, de maneira a garantir maior eficiência da máquina pública e melhor atendimento para a sociedade. De acordo com Pires e Macedo (2006), as organizações públicas são sistemas complexos devido ao alto índice de burocracia. Elas mantêm características básicas das demais organizações às quais se acrescem alguns aspectos específicos como: apego às regras e rotinas, supervalorização da hierarquia, paternalismo nas relações, apego ao poder, entre outras. Essas diferenças são importantes na definição dos processos internos, seja com relação às inovações e mudanças, na formação de valores e crenças da organização e ainda na política de recursos humanos.
1.9 Qualidade de Serviço
Oliveira (2003, p.10-11) conceitua que a qualidade total no setor de serviços está ligada com o fornecimento do produto “serviço” com qualidade aos clientes, proprietários e funcionários. O autor observa que esse conceito não se limita apenas aos clientes externos, mas sim a todos de uma cadeia administrativa para um objetivo comum: a qualidade. Statdlober (2006, p.9), os conceitos de gestão pela qualidade, sejam na produção manufatureira ou serviços, têm como objetivo fazer com que os resultados esperados sejam atingidos repetitivamente e de forma confiável, alcançando melhoria contínua. O autor destaca quatro itens fundamentais da qualidade: a) Processo - o qual apresenta os seguintes elementos:
Solicitação do cliente/usuário;
Tratamento da solicitação;
Retorno, solução ou feedback;
Controle do processo definidos.
Esses elementos podem ser desdobrados conforme complexidade da solicitação e estrutura da empresa, visando garantir a uniformidade dos resultados, mesmo que as pessoas envolvidas no atendimento mudem. b) Objetivo da qualidade – estabelece padrões para o nível de serviço ou execuções dos processos; c) Indicadores da qualidade – é a maneira formal de medir o andamento do atendimento; d) Método
de
acompanhamento
–
forma
sistemática
definida
para
o
acompanhamento, por exemplo, a ferramenta PDCA (Plan, Do, Check e Act, em
33
português, planejar, fazer/executar, checar e agir), que consiste em um ciclo de gerenciamento completo.
1.9.1 Qualidade em TI – Help Desk
O setor da tecnologia da informação, nas últimas décadas, tem se tornado uma área indispensável nas empresas privadas e nos setores públicos nos quais, embora o acompanhamento tecnológico seja menos acelerado, existe preocupação quanto ao suporte para o bom funcionamento dos sistemas e equipamento. Para agilizar esses processos de suporte, as organizações possuem o chamado sistema de “Help Desk”, que pode ser definido como o setor da empresa para o qual são encaminhadas questões e na qual resolvem-se os problemas (CAVALARI e COSTA, 2005). Zielinski e Bortoleto (2007) descrevem o Help Desk como sistemas utilizados para controle, rastreamento, produção e recuperação de informações rapidamente, em uma base de conhecimentos, objetivando resolver problemas específicos. A utilização dessa ferramenta permite que os pedidos de assistência técnica realizados por usuários possam ser atendidos com maior rapidez e eficácia, sendo que, na maioria dos casos, os problemas são repetitivos e podem ser respondidos com uma solução aplicada anteriormente. Neste sentido, é importante destacar os elementos da qualidade de serviços, inserindo-os no sistema Help Desk de maneira a alcançar resultados desejáveis em um processo de melhoria contínua, levando em consideração o sistema, para melhorar o gerenciamento das soluções de atendimento (CAVALARI e COSTA, 2005). O
segundo
capítulo
desenvolvimento do trabalho.
descreve
a
metodologia
de
pesquisa
utilizada
no
34
2. METODOLOGIA CIENTÍFICA
Neste capítulo será apresentado o método científico que foi utilizado no desenvolvimento da pesquisa.
2.1 Quanto à abordagem do problema
Uma pesquisa pode possuir abordagem de cunho quantitativo, qualitativo ou ambos. Conforme Oliveira (2010, p.27-28) a abordagem quantitativa significa quantificar dados obtidos através de informações coletadas por meio de questionários, entrevistas, observações, assim como o emprego de recursos e técnicas estatísticas. Por sua vez, a abordagem qualitativa conduz um processo de reflexão e análise da realidade através da utilização dos métodos e técnicas para compreensão detalhada do objeto em estudo, em seu contexto histórico e segundo sua estruturação. Esse processo implica em estudos, na observação, na aplicação de questionários, de entrevistas e na análise de dados que deve ser apresentada de forma descritiva.
2.2 Quanto à natureza
Appolinário (2012, p.62) ressalta que quanto à sua finalidade, uma pesquisa pode ser classificada como básica ou aplicada. A pesquisa básica (ou fundamental) está ligada ao incremento científico sem qualquer objetivo comercial. A pesquisa aplicada é suscitada por objetivos comerciais, ou seja, está voltada para o conhecimento de novos processos ou produtos orientados de acordo com a necessidade do mercado.
2.3 Quanto ao objetivo
Segundo Gil (2010, p.27-29) a pesquisa é classificada quanto ao objetivo em três níveis: Pesquisa exploratória: tem como principal objetivo desenvolver, esclarecer e modificar conceitos e ideias, tendo em vista a formulação de problemas precisos ou a construção de hipóteses. Apresentam menor rigidez no planejamento, envolvem levantamento bibliográfico e documental, entrevistas não padronizadas e estudos de caso.
35
Pesquisa
descritiva:
possui
como
principal
finalidade
a
descrição
das
características de determinada população ou fenômeno ou, ainda, o estabelecimento de relações entre variáveis. Uma de suas características mais significativas está no uso de técnicas padronizadas de coleta de dados. As pesquisas descritivas são habitualmente realizadas por pesquisadores sociais preocupados com a atuação prática. Pesquisa explicativa: tem como objetivo primordial identificar os fatores que determinam ou contribuem para a ocorrência dos fenômenos. É o tipo de pesquisa que mais aprofunda o conhecimento da realidade, pois explica a razão das coisas. Também é o tipo mais complexo e delicado, em que o risco de cometer erros aumenta consideravelmente. Nas ciências naturais, necessitam do uso do método experimental, e, nas ciências sociais, requer o uso do método observacional.
2.4 Quanto aos métodos
Toda pesquisa científica possui um rigor, que necessita ser norteada por um método: [...] o método significa uma investigação que segue um modo ou uma maneira planejada e determinada para conhecer alguma coisa; procedimento racional para o conhecimento seguindo um percurso fixado’. Nesse sentido, o método pressupõe um planejamento com a utilização de instrumentos adequados (técnica), para consecução dos objetivos predeterminados. (CHAUÍ, 1994, p.354 apud OLIVEIRA, 2010, p. 20)
Seguindo a afirmação acima, pode-se observar a existência de métodos distintos, que permitem a classificação de determinada pesquisa em diferentes categorias, tais como: método dedutivo, indutivo, hipotético-dedutivo, estudo de caso, entre outros. Neste trabalho foi utilizado o Estudo de Caso, que será detalhado no próximo item.
2.4.1 Método do Estudo de Caso
Segundo Huberman (1991); Yin (2005); Mucchielli (1996) (apud OLIVEIRA, 2010, p.25) “o estudo de caso é uma estratégia metodológica do tipo exploratório, descritivo e interpretativo.” Oliveira (2010, p.25), afirma que o método “pode ser trabalhado através das mais variadas técnicas e de métodos que facilitam a compreensão do fenômeno a ser estudado”, esta aplicação “deve ser utilizada para atender aos objetivos preestabelecidos pelos pesquisadores (as), como forma de estudo aprofundado a fim de buscar fundamentos e explicações para determinado fato ou fenômeno da realidade empírica.” De acordo com Mucchielli (1996 apud OLIVEIRA, 2010, p.26):
36
[...] existem três diferentes tipos para se utilizar o método de estudo de caso: estudo de caso intrínseco ou estudo de caso único (fato, objeto, fenômeno), estudo de caso instrumental (definido dentro de um modelo teórico) e o estudo de caso múltiplo (estudo entre duas ou mais realidades ou situações). O estudo de caso intrínseco ou único trata de uma única realidade que pode ser estuda exaustivamente, na tentativa de se buscar novos elementos que possam explicar o objeto de estudo. O estudo de caso instrumental fundamenta-se em um determinado modelo teórico, no qual se pretende analisar diferentes fenômenos que possam corroborar ou não o modelo preestabelecido. Para o estudo de caso múltiplo, a pesquisa utiliza mais de uma realidade para confrontar dados, visando buscar explicações e fundamentos para fenômenos que caracterizam o objeto de estudo. [grifos do autor]
2.5 Técnicas de Coleta de Dados
As
informações
podem
ser
coletadas
através
questionários,
entrevistas,
observações, etc. De acordo com Oliveira (2010, p.28), na abordagem qualitativa, há um processo de reflexão e análise da realidade através da aplicação de métodos e técnicas para compreender detalhadamente o objeto de estudo em seu contexto histórico e/ou segundo sua estruturação.
2.5.1 Observação
Constitui a base da investigação científica, técnica através da qual dados podem ser coletados. Para Gil (2010, p.101), a observação pode ser estruturada ou não, segundo os meios utilizados, e participante ou não participante de acordo com o grau de participação do observador. Neste projeto, a técnica utilizada foi a de observação participante, na qual o observador assumiu o papel de um membro do grupo no estudo (GIL, 2010, p.103). Vale salientar que dois integrantes desta pesquisa possuem papéis distintos, ora sendo pesquisadores do trabalho, ora servidores públicos, desempenhando atividades pertinentes a seus setores e, assim, convivendo com os problemas. Caracterizando, desta forma, uma investigação natural, pois o observador pertence a este grupo (GIL, 2010, p.103).
2.5.2 Questionário
O questionário pode ser definido como uma técnica de investigação composta por um número consideravelmente elevado de questões apresentadas por escrito às pessoas,
37
tendo por objetivo levantar opiniões, sentimentos, interesses, expectativas, situações vivenciadas etc. (GIL, 2010, p. 121) Como define Gil (2010, p.129-130), por meio de questões fechadas, apresenta-se ao respondente um conjunto de alternativas de resposta para que seja escolhida a que melhor representa sua situação ou ponto de vista. Por exemplo, uma das perguntas elaboradas para esta pesquisa: “Como você analisa o tempo de resposta ao entrar em contato com o suporte?”, foram apresentadas as seguintes alternativas: a) Ótimo; b) Bom; c) Regular; d) Ruim; e) Péssimo. Algumas limitações, porém, se tornaram obstáculos, pelo fato de: a) impedir auxílio ao informante quando este não compreende corretamente as instruções dos questionários; b) não oferecer garantia de que a maioria das pessoas entreguem devidamente preenchido, implicando na diminuição da representatividade da amostra; c) número de perguntas relativamente pequeno, pois questionários extensos apresentam alta probabilidade de não serem respondidos. Oliveira (2010, p.43), afirma que um instrumento de pesquisa é dito válido quando é capaz de medir com precisão o que se deseja conhecer. Mediante o exposto, o presente trabalho caracteriza-se como uma abordagem qualitativa, por tratar de uma pesquisa exploratória e descritiva, constituindo um estudo de caso múltiplo. O terceiro capítulo apresenta o desenvolvimento do software proposto.
38
3. Desenvolvimento
Este projeto tem como objetivo principal a elaboração de um sistema de suporte de TI para prefeituras. Neste capítulo aborda-se o processo de desenvolvimento do software, desde a análise dos requisitos até a implantação do sistema. Para o gerenciamento deste projeto foi utilizada a metodologia RUP, que é composta por quatro fases: concepção, elaboração, construção e transição. A seguir apresenta-se os requisitos do sistema, o diagrama de caso de uso gráfico e textual, o diagrama de classes, o diagrama de sequência, o modelo de entidade e relacionamento e a implementação do sistema.
3.1 Concepção
Nesta fase, a preocupação foi estabelecer uma visão do sistema do ponto de vista de negócio, avaliando se o projeto seria viável ou não. De maneira a melhor visualizar o contexto do negócio, criou-se um modelo de negócio, onde são documentados os conceitos pertinentes ao mesmo, com o objetivo de documentar os processos e a relação entre os conceitos. A identificação das necessidades para a elaboração do Sistema de Suporte de TI para Prefeituras foi inicialmente realizada através de dois modelos de questionários (apêndices A e B), aplicados em duas prefeituras distintas. Para a aplicação destes questionários o projeto precisou passar pela avaliação de um comitê de ética. Após a aprovação (exibida no apêndice E), foi possível o emprego dos questionários. Um dos questionários, voltado aos setores de TI, composto por 7 questões, foi aplicado a 10 profissionais que trabalham no setor. O outro questionário, direcionado aos setores que recebem os serviços prestados pela área de TI, foi empregado a 60 servidores públicos. Cada questão teve um objetivo específico, a análise de cada resposta permitiu estabelecer as funções que o sistema deve desempenhar. Na Tabela 1 são apresentados os dados obtidos no questionário aplicado nos setores de TI das prefeituras e na Tabela 2, os dados obtidos nos demais setores.
39
Tabela 1 - Questionário TI: Questões e Objetivos Questões
Objetivo
1. Formação: a. Ensino Médio Completo
d. Superior Completo na Área
Identificar o perfil do grupo avaliado em relação a
b. Ensino Médio Incompleto
e. Superior Completo fora da Área
sua formação acadêmica.
c. Ensino Superior Incompleto f. Pós Graduação 2. Existe algum software de gerenciamento e controle do setor?
Identificar a existência de um software de auxílio
a. Sim
ao suporte.
b. Não
3. Qual a sua usabilidade no atual sistema? a. Esporadicamente
c. Algumas vezes por semana
b. 1 vez por semana
d. Todos os dias
4. Com que frequencia você realiza atendimento de suporte? a. Esporadicamente
c. Algumas vezes por semana
b. 1 vez por semana
d. Mais de uma vez por dia
5. O atual sistema proporciona agilidade nos atendimentos e demais serviços realizados por este setor? a. Sim
Analisar a frequencia de uso do sistema.
Analisar o fluxo de atendimentos realizado por cada profissional de TI
Investigar
a
satisfação
quanto
atitudes
tomadas
ao
sistema
existente.
b. Não
6. Como são tratadas situações reincidentes? a. Buscam diferentes formas para descobrir o motivo das reincidências
Identificar
b. Tratam igual aos demais problemas
problemas de difícil resolução.
as
quanto
a
c. Outros _________________________________ 7. O que acha necessário adicionar em um novo sistema?
Investigar as opiniões quanto ao processo total
______________________________________________
do suporte utilizando um sistema.
Apesar de possuir objetivos específicos, a análise conjunta dos dois questionários promoveu a definição de características do sistema, conforme observações realizadas pelo cliente (servidores das prefeituras). Tabela 2 - Questionário Demais Setores: Questões e Objetivos Questões
Objetivo
1. Formação: a. Ensino Médio Completo
d. Superior Completo na Área
Identificar o perfil do grupo avaliado em relação a
b. Ensino Médio Incompleto
e. Superior Completo fora da Área
sua formação acadêmica.
c. Ensino Superior Incompleto f. Pós Graduação 2. Qual a forma de contatar o suporte de TI? a. Telefone
d. Chat
b. Memorando
e. Outro __________________
Identificar os atuais meios de contato com o TI.
c. Email 3. Como você analisa o tempo de resposta ao entrar em contato com o suporte? a. Ótimo
d. Ruim
b. Bom
e. Péssimo
Analisar a satisfação referente ao suporte inicial recebido.
c. Regular 4. Com que frequência é necessário acionar o suporte? a. Esporadicamente
c. Uma vez por mês
b. 1 vez por semana
d. Várias vezes por semana
5. O suporte é eficaz? a. Sim
Verificar a frequência de problemas relacionados ao TI. Identificar a satisfação quanto ao processo de
b. Não
suporte.
40
6. Os problemas são resolvidos? a. Sim, sempre
c. Quase nunca
b. Às vezes
d. Nunca
Analisar a satisfação referente ao resultado da solicitação.
7. Qual a atitude do suporte quanto a problemas repetidos? a. Buscam resolver o problema de qualquer forma b. Tentam algumas vezes, mas se não obtiverem sucesso, não tomam
Identificar a satisfação quanto a forma do suporte
nenhuma outra providência
agir quanto a problemas de difícil resolução.
c. nada fazem para resolver os problemas contínuos d. Outros_______________________________________ 8. Existe algum tipo de feedback (resposta) por parte do suporte após os atendimentos?
Verificar a comunicação entre solicitante e
a. Sim, sempre
c. Quase nunca
b. Às vezes
d. Nunca
solicitado após o término do suporte.
9. Qual sua opinião sobre o atual suporte do TI?
Investigar as opiniões quanto ao processo total
________________________________________________
do suporte.
10. Dê sugestões para melhorar a forma de ser atendido:
Identificar melhorias a serem empregadas em um
________________________________________________
novo sistema.
Para a interpretação dos dados colhidos através dos questionários, as respostas foram transpostas em gráficos (Apêndice C) e os resultados foram analisados sob uma perspectiva qualitativa. Juntamente com a análise dos resultados dos questionários estudou-se os softwares livres disponíveis no Portal do Software Público Brasileiro, em especial o software Central de Atendimento ao Usuário (CAU), desenvolvido pela Embratur. Pôde-se, assim, confirmar a viabilidade de desenvolvimento do sistema e elencar os seus requisitos funcionais, responsáveis por descrever as suas funcionalidades; e os requisitos não funcionais, que declaram restrições ou atributos de qualidade para um software para o processo de desenvolvimento do sistema. Segurança, usabilidade e interoperabilidade são exemplos de requisitos não funcionais. A Tabela 3 contém os principais requisitos do sistema: Tabela 3 - Tabela de Requisitos ID 1
2
Descrição do Requisito Possibilitar o cadastramento dos dados pessoais dos usuários Permitir o cadastramento dos equipamentos do parque computacional
Tipo Funcional
Funcional
3
Permitir o cadastramento dos setores
Funcional
4
Possibilitar o cadastramento dos serviços prestados
Funcional
5
Permitir a abertura de chamados por qualquer usuário
Funcional
6
Permitir a realização de um chamado
Funcional
7
Permitir o acompanhamento dos chamados pelos solicitantes
Funcional
Categoria
41
Permitir o agendamento de tarefas realizadas
8
externamente
Funcional
9
Emitir relatórios gerenciais
Funcional
10
Apenas gerentes podem emitir relatórios
Funcional
Possuir uma interface simples e funcional para que
11
agilize o atendimento
Não-Funcional
Usabilidade
12
Comunicar com o banco MySQL
Não-Funcional
Interoperabilidade
13
Ser implementado na linguagem JAVA padrão J2EE
Não-Funcional
Implementação
14
Deverá executar em qualquer navegador
Não-Funcional
Portabilidade
15
Deverá ter alta disponibilidade
Não-Funcional
Confiabilidade
16
Utilizar ferramentas livres para o seu desenvolvimento
Não-Funcional
Processo
Não-Funcional
Segurança
A base de dados deve ser protegida para acesso
17
apenas de usuários autorizados
O RUP utiliza a UML como ferramenta para especificação de sistema. Os processos do modelo de negócio são documentados através de casos de uso. Com os dados inicialmente avaliados e os requisitos elencados, foi possível a elaboração do diagrama de caso de uso gráfico e textual, que especificam o que o sistema deve fazer. O sistema possui dois atores, sendo: o ator usuário, desempenhando o papel de solicitante do suporte, dividido em dois níveis de permissão: Normal e Avançado; e o ator funcionário TI com o papel de prestador de serviços, dividido em três níveis de permissão: Moderador, Gerente e Estagiário. O diagrama ilustrado na Figura 7 identifica os usuários que utilizam o software de gerenciamento de suporte de TI, e exibe o que o sistema deve oferecer de funcionalidades. Cada elipse representa um caso de uso específico, sendo os casos de uso "Abrir Chamado" e "Emitir Relatórios" os principais, pois o primeiro é a funcionalidade central do sistema, onde todos os outros casos de uso estão direta ou indiretamente ligados, e o segundo permite a análise dos serviços prestados e o controle de demanda. O usuário com o nível de permissão Avançado pode abrir qualquer tipo de chamado, já o usuário com permissão Normal possui restrições em alguns tipos de serviço, conforme especificado no momento de cadastro do mesmo. O funcionário TI com permissão de Estagiário pode apenas executar o caso de uso "Realizar Atendimento", o funcionario TI Moderador somente não tem acesso ao caso de uso "Emitir Relatórios" disponível ao Gerente, que também pode executar os demais casos de uso. Este diagrama é útil a todas as pessoas relacionadas ao sistema, uma vez que, a partir dele, os usuários entendem melhor o que está sendo feito. Dessa maneira, foi possível discutir melhorias nas especificações e chegar a um consenso sobre as funcionalidades oferecidas.
42
Figura 7 - Diagrama de Caso de Uso Gráfico
A descrição textual do caso de uso, exibida a seguir, oferece detalhes ao leitor sem oferecer minúcias técnicas, contando a visão do negócio. Este documento alimenta o diagrama de classes e o diagrama de sequência, além de determinar regras, exceções e mensagens a serem exibidas ao usuário. a) Caso de uso: Abrir Chamado Descrição: Este caso de uso possibilita a abertura de chamado técnico através do sistema. Atores: Usuário e Funcionário TI. Pré-condição: O ator deve estar devidamente autenticado no sistema. Fluxo Principal: 1. O caso de uso inicia quando o ator acessa o item “Abrir Chamado”; 2. O sistema exibe um formulário de “Abertura de Chamado” contendo: 2.1 Dados do Solicitante: [RN01] 2.1.2 Nome;
43
2.1.2 Cargo; 2.1.3 Setor; 2.1.4 Telefone; 2.1.5 Email; 2.1.6 Matrícula; 2.2 Dados do Chamado: 2.2.1 Tipo; [RN02] 2.2.2 Serviço; [RN03][RN04][RN05] 2.2.3 Patrimônio; [RN06] 2.2.4 Setor; [RN12][RN13] 2.2.5 Descrição; 2.2.6 Data e hora de abertura do chamado; [RN01] 3. O ator informa os dados do chamado; [RN07] 4. O sistema valida os dados; [E01][E02] 5. Os dados são salvos e é exibida a tela "Confirmação de Abertura de Chamado", cotendo o número do chamado; [RN14] 6. Fim do caso de uso "Abrir Chamado". Fluxo alternativo: Este caso de uso não contém fluxos alternativos. Pós-condição: Realizar atendimento.
b) Caso de uso: Acompanhar Chamado Descrição: Este caso de uso possibilita o acompanhamento dos chamados abertos pelo usuário. Atores: Usuário. Pré-condição: Deve-se haver chamados abertos pelo ator devidamente autenticado no sistema. Fluxo Principal: 1. O caso de uso inicia quando o ator acessa o item “Acompanhar Chamado”; 2. O sistema exibe uma tela, contendo: 2.1 Opção "Exibir Filtros de Pesquisa"; 2.2 Tabela com os dados: 2.2.1 Número do chamado aberto pelo ator;[RN08] 2.2.2 Patrimônio do equipamento envolvido no chamado;[RN09] 2.2.3 Descrição do chamado; 2.2.4 Situação em que se encontra o chamado;[RN22] 2.2.5 Data de abertura do chamado; 2.2.6 Data de encerramento do chamado;[RN10]
44
3. Fim do caso de uso "Acompanhar Chamado". Fluxo alternativo: A01 (2.1) - Pesquisar chamado: 1. O ator seleciona a opção "Exibir Filtros de Pesquisa"; 2. O sistema exibe um formulário contendo os filtros: 2.1 Número do chamado; 2.2 Situação; 2.3 Patrimônio; 2.4 Data de Abertura; 2.5 Data de Encerramento; 3. O ator insere os dados para pesquisa;[RN11] 4. O sistema valida os dados;[E03] 5. O sistema retorna uma tabela contendo os dados dos chamados encontrados na pesquisa; 6. Fim do fluxo alternativo. A02 (2.2) - Detalhar Chamado: 1. O ator seleciona um chamado específico da tabela de chamados; 2. O sistema exibe a tela “Detalhes do Chamado”, contendo: 2.1 Dados do Solicitante: 2.1.1 Nome do Solicitante; 2.1.2 Setor do Solicitante; 2.2 Dados do chamado: 2.2.1 Número do Chamado; 2.2.2 Tipo de Serviço; 2.2.3 Serviço; 2.2.4 Patrimônio;[RN09] 2.2.5 Setor; 2.2.6 Descrição; 2.2.7 Data de abertura; 2.2.8 Cancelar Chamado;[ RN15] 2.3 Dados do Atendimento:[RN10] 2.3.1 Nome do Atendente; 2.3.2 Situação;[RN22] 2.3.3 Serviço Realizado; 2.3.4 Data de Encerramento; 2.3.5 Histórico;[RN16] 2.3.6 Avaliar Chamado;[RN17]
45
3. Fim do fluxo alternativo. Pós-condição: Cancelar Chamado; Avaliar Chamado.
c) Caso de uso: Cancelar Chamado Descrição: Este caso de uso permite o cancelamento de determinado chamado. Atores: Usuário. Pré-condição: Deve haver um chamado aberto ainda não finalizado. Fluxo Principal: 1. O caso de uso inicia quando o ator acessa o item “Cancelar Chamado” na tela de detalhe de determinado chamado; 2. O sistema exibe um formulário, contendo: 2.1 Dados do Solicitante [RN01] 2.1.1 Nome: Nome do ator autenticado no sistema; 2.1.2 Email: Email do ator autenticado no sistema; 2.2 Dados do Chamado[RN01] 2.2.1 Número do chamado; 2.2.2 Data e hora do cancelamento do chamado; 2.3 Descrição do motivo do cancelamento; 3. O ator informa os dados;[RN07] 4. O sistema valida os dados;[E01] 5. Os dados são salvos e é exibida a mensagem [MS04]; 6. Fim do caso de uso "Cancelar Chamado". Fluxo alternativo: Este caso de uso não contém fluxos alternativos. Pós-condição: Este caso de uso não contém pós-condições.
d) Caso de uso: Avaliar Chamado Descrição: Este caso de uso permite ao Usuário avaliar o atendimento de determinado chamado. Atores: Usuário. Pré-condição: Um chamado deve ter sido finalizado. Fluxo Principal: 1. O caso de uso inicia quando o ator acessa o item “Avaliar Chamado” na tela de detalhe de determinado chamado; 2. O sistema exibe um formulário, contendo os itens: 2.1 Problema Resolvido;[RN18] 2.2 Satisfação com a solução apresentada;[RN19] 2.3 Satisfação com o conhecimento técnico do atendente;[RN19]
46
2.4 Satisfação com o tempo de espera para o atendimento;[RN19] 2.5 Satisfação quanto ao tempo de solução;[RN19] 2.6 Observação; 3. O sistema valida os dados;[E01] 4 Os dados são salvos e é exibida a mensagem [MS05]; 5. Fim do caso de uso "Avaliar Chamado". Fluxo alternativo: Este caso de uso não contém fluxos alternativos. Pós-condição: Este caso de uso não contém pós-condições.
e) Caso de uso: Agendar Serviço: Descrição: Este caso de uso permite o agendamento de tarefas externas. Atores: Funcionário TI. Pré-condição: O ator deve estar devidamente autenticado no sistema. Fluxo Principal: 1. O caso de uso inicia quando o ator seleciona determinado chamado no item “Realizar Atendimento” na tela de detalhe de determinado chamado; 2. O ator seleciona a opção "Agendar Serviço"; 3. O sistema exibe um formulário contendo dados: 3.1 Data; 3.2 Hora; 4. O ator informa os dados; [RN07] 5. O sistema valida os dados; [E01] 6. O sistema exibe uma mensagem [MS10]; 7. Fim do caso de uso "Agendar Serviço"; Fluxo alternativo: Este caso de uso não possui fluxos alternativos. Pós-condição: Finalizar o atendimento.
f) Caso de uso: Manter Cadastro de Usuário Descrição: Este caso de uso permite a inserção, edição e pesquisa dos usuários do sistema. Atores: Funcionário TI. Pré-condição: O ator deve estar devidamente autenticado no sistema. Fluxo Principal: 1. O caso de uso inicia quando o ator seleciona a opção "Cadastro/Usuários"; 2. O sistema exibe as opções de inclusão, alteração e consulta de usuário;[RN20] 3. O ator seleciona a opção de inclusão de usuário; 4. O sistema exibe um formulário com os dados:
47
4.1 Permissão;[RN23] 4.2 Matrícula; 4.3 Nome; 4.4 Cargo; 4.5 Setor; [RN12] 4.6 Email; 4.7 Telefone; 4.8 Senha; 4.9 Confirmar Senha; 4.10 Status;[RN21] 5. O ator informa os dados do usuário;[RN07] 6. O sistema valida os dados;[E01][E04] 7. Os dados são salvos e é exibida a mensagem [MS06]; 8. Fim do caso de uso "Manter Cadastro de Usuário!"; Fluxo alternativo: A01 (2) - Alterar Usuário: 1. O ator seleciona a opção "Alterar Usuário"; 2. O ator insere os dados de pesquisa de usuário: 2.1 Nome; 2.2 Matrícula; 2.3 Setor; 2.4 Status; 3. O ator insere os dados para pesquisa;[RN11] 4. O sistema valida os dados;[E03] 5. O sistema retorna uma tabela contendo os dados dos usuários encontrados na pesquisa; 6. O ator seleciona o usuário a ser alterado; 7. O sistema apresenta um formulário, contendo os dados do usuário selecionado; Permissão;[RN23] Nome; Cargo; Setor; Email; Telefone; Senha; Confirmar Senha; Status;[RN21]
48
8. O ator informa os dados a serem alterados;[RN07] 9. O sistema valida os dados;[E01][E04] 10. Os dados são salvos e é exibida a mensagem [MS08]; 11. Fim do fluxo alternativo. A02 (2) - Pesquisar Usuário: 1. O ator seleciona a opção "Pesquisar Usuário"; 2. O ator insere os dados de pesquisa de usuário: 2.1 Nome; 2.2 Matrícula; 2.3 Setor; 3. O ator insere os dados para pesquisa;[RN11] 4. O sistema valida os dados;[E03] 5. O sistema retorna uma tabela contendo os dados dos usuários encontrados na pesquisa; 6. Fim do fluxo alternativo. Pós-condição: Este caso de uso não contém pós-condições.
g) Caso de uso: Manter Tipo de Serviço Descrição: Este caso de uso permite a inserção, edição e pesquisa dos tipos de serviço. Atores: Funcionário TI. Pré-condição: O ator deve estar devidamente autenticado no sistema. Fluxo Principal: 1. O caso de uso inicia quando o ator seleciona a opção "Cadastro/Tipo de Serviço"; 2. O sistema exibe as opções de inclusão, alteração e consulta de tipo de serviço;[RN20] 3. O ator seleciona a opção de inclusão de tipo de serviço; 4. O sistema exibe um formulário com os dados: 4.1 Nome; 4.2 Descrição; 4.3 Status;[RN21] 5. O ator informa os dados do tipo de serviço;[RN07] 6. O sistema valida os dados;[E01] 7. Os dados são salvos e é exibida a mensagem [MS06]; 8. Fim do caso de uso "Manter Tipo de Serviço". Fluxo alternativo: A01 (2) - Alterar Tipo de Serviço:
49
1. O ator seleciona a opção "Alterar Tipo de Serviço"; 2. O ator insere os dados de pesquisa de tipo de serviço: 2.1 Nome; 2.2 Status; 3. O ator insere os dados para pesquisa;[RN11] 4. O sistema valida os dados;[E03] 5. O sistema retorna uma tabela contendo os dados dos tipos de serviços encontrados na pesquisa; 6. O ator seleciona o tipo de serviço a ser alterado; 7. O sistema apresenta um formulário, contendo os dados do tipo de serviço selecionado: 7.1 Nome; 7.2 Descrição; 7.3 Status;[RN21] 8. O ator informa os dados a serem alterados;[RN07] 9. O sistema valida os dados;[E01] 10. Os dados são salvos e é exibida a mensagem [MS08]; 11. Fim do fluxo alternativo. A02 (2) - Pesquisar Tipo de Serviço: 1. O ator seleciona a opção "Pesquisar Tipo de Serviço"; 2. O ator insere os dados de pesquisa do tipo de serviço: 2.1 Nome; 2.2 Status; 3. O ator insere os dados para pesquisa;[RN11] 4. O sistema valida os dados;[E03] 5. O sistema retorna uma tabela contendo os dados dos tipos de serviços encontrados na pesquisa; 6. Fim do fluxo alternativo. Pós-condição: Este caso de uso não contém pós-condições.
h) Caso de uso: Manter Cadastro de Serviço Descrição: Este caso de uso permite a inserção, edição e pesquisa dos serviços relacionados ao setor de TI. Atores: Funcionário TI. Pré-condição: O ator deve estar devidamente autenticado no sistema. Fluxo Principal: 1. O caso de uso inicia quando o ator seleciona a opção "Cadastro/Serviços";
50
2. O sistema exibe as opções de inclusão, alteração e consulta de serviços; [RN20] 3. O ator seleciona a opção de inclusão de serviços; 4. O sistema exibe um formulário com os dados: 4.1 Tipo de Serviço;[RN02] 4.2 Nome; 4.3 Descrição; 4.4 Status;[RN21] 4.5 Visibilidade;[RN24] 5. O ator informa os dados do serviço;[RN07] 6. O sistema valida os dados;[E01] 7. Os dados são salvos e é exibida a mensagem [MS06]; 8. Fim do caso de uso "Manter Cadastro de Serviço". Fluxo alternativo: A01 (2) - Alterar Serviço: 1. O ator seleciona a opção "Alterar Serviço"; 2. O ator insere os dados de pesquisa de usuário: 2.1 Tipo de Serviço; 2.2 Nome; 2.3 Status; 3. O ator insere os dados para pesquisa;[RN11] 4. O sistema valida os dados;[E03] 5. O sistema retorna uma tabela contendo os dados dos serviços encontrados na pesquisa; 6. O ator seleciona o serviço a ser alterado; 7. O sistema apresenta um formulário, contendo os dados do usuário selecionado: 7.1 Tipo de Serviço;[RN02] 7.2 Nome; 7.3 Descrição; 7.4 Status;[RN21] 7.5 Visibilidade[RN24]; 8. O ator informa os dados a serem alterados;[RN07] 9. O sistema valida os dados;[E01] 10. Os dados são salvos e é exibida a mensagem [MS08]; 11. Fim do fluxo alternativo. A02 (2) - Pesquisar Serviço: 1. O ator seleciona a opção "Pesquisar Serviço"; 2. O ator insere os dados de pesquisa do serviço:
51
2.1 Tipo de Chamado; 2.2 Nome; 2.3 Status 3. O ator insere os dados para pesquisa;[RN11] 4. O sistema valida os dados;[E03] 5. O sistema retorna uma tabela contendo os dados dos serviços encontrados na pesquisa; 6. Fim do fluxo alternativo. Pós-condição: Este caso de uso não contém pós-condições.
i) Caso de uso: Manter Cadastro de Patrimônio Descrição: Este caso de uso permite a inserção, edição e pesquisa dos bens patrimoniais referentes ao campo computacional. Atores: Funcionário TI. Pré-condição: O ator deve estar devidamente autenticado no sistema. Fluxo Principal: 1. O caso de uso inicia quando o ator seleciona a opção "Cadastro/Patrimônio"; 2. O sistema exibe as opções de inclusão, alteração e consulta de patrimônio; [RN20] 3. O ator seleciona a opção de inclusão de patrimônio; 4. O sistema exibe um formulário com os dados: 4.1 Código; 4.2 Setor;[RN12] 4.3 Nome; 4.4 Descrição; 4.5 Status;[RN21] 5. O ator informa os dados do patrimônio;[RN07] 6. O sistema valida os dados;[E01][E05] 7. Os dados são salvos e é exibida a mensagem [MS06]; 8. Fim do caso de uso "Manter Cadastro de Patrimônio". Fluxo alternativo: A02 (2) - Alterar Patrimônio: 1. O ator seleciona a opção "Alterar Patrimônio"; 2. O ator insere os dados de pesquisa de patrimônio: 2.1 Código; 2.2 Setor; 2.3 Nome; 2.4 Status;
52
3. O ator insere os dados para pesquisa;[RN11] 4. O sistema valida os dados;[E03] 5. O sistema retorna uma tabela contendo os dados dos patrimônios encontrados na pesquisa; 6. O ator seleciona o patrimônio a ser alterado; 7. O sistema apresenta um formulário, contendo os dados do patrimônio selecionado: 7.1 Setor; 7.2 Nome; 7.3 Descrição; 7.4 Status;[RN21] 8. O ator informa os dados a serem alterados;[RN07] 9. O sistema valida os dados;[E01][E05] 10. Os dados são salvos e é exibida a mensagem [MS08]; 11. Fim do fluxo alternativo. A03 (2) - Pesquisar Patrimônio: 1. O ator seleciona a opção "Pesquisar Patrimônio"; 2. O ator insere os dados de pesquisa de patrimônio: 2.1 Código; 2.2 Setor; 2.3 Nome; 2.4 Status; 3. O ator insere os dados para pesquisa;[RN11] 4. O sistema valida os dados;[E03] 5. O sistema retorna uma tabela contendo os dados dos patrimônios encontrados na pesquisa; 6. Fim do fluxo alternativo. Pós-condição: Este caso de uso não contém pós-condições.
j) Caso de uso: Manter Cadastro de Setores Descrição: Este caso de uso permite a inserção, edição e pesquisa dos setores que compõem a prefeitura. Atores: Funcionário TI. Pré-condição: O ator deve estar devidamente autenticado no sistema. Fluxo Principal: 1. O caso de uso inicia quando o ator seleciona a opção "Cadastro/Setor"; 2. O sistema exibe as opções de inclusão, alteração e consulta de setor; [RN20] 3. O ator seleciona a opção de inclusão de setor;
53
4. O sistema exibe um formulário com os dados: 4.1 Nome; 4.2 Código; 4.3 Status;[RN21] 5. O ator informa os dados do setor;[RN07] 6. O sistema valida os dados;[E01] 7. Os dados são salvos e é exibida a mensagem [MS06]; 8. Fim do caso de uso "Manter Cadastro de Setor". Fluxo alternativo: A01 (2) - Alterar Setor: 1. O ator seleciona a opção "Alterar Setor"; 2. O ator insere os dados de pesquisa do setor: 2.1 Nome; 2.2 Código; 2.3 Status; 3. O ator insere os dados para pesquisa;[RN11] 4. O sistema valida os dados;[E03] 5. O sistema retorna uma tabela contendo os dados dos setores encontrados na pesquisa; 6. O ator seleciona o setor a ser alterado; 7. O sistema apresenta um formulário, contendo os dados do setor selecionado: 7.1 Nome; 7.2 Status;[RN21] 8. O ator informa os dados a serem alterados;[RN07] 9. O sistema valida os dados;[E01] 10. Os dados são salvos e é exibida a mensagem [MS08]; 11. Fim do fluxo alternativo. A02 (2) - Pesquisar Setor: 1. O ator seleciona a opção "Pesquisar Setor"; 2. O ator insere os dados de pesquisa do setor: 2.1 Nome; 2.2 Código; 2.3 Status; 3. O ator insere os dados para pesquisa;[RN11] 4. O sistema valida os dados;[E03] 5. O sistema retorna uma tabela contendo os dados dos setores encontrados na pesquisa;
54
6. Fim do fluxo alternativo. Pós-condição: Este caso de uso não contém pós-condições.
k) Caso de uso: Realizar Atendimento Descrição: Este caso de uso permite a realização do atendimento. Atores:
Funcionário
TI.Pré-condição:
Possuir
um
chamado
aguardando
atendimento, o autor deve estar devidamente autenticado no sistema. Fluxo Principal: 1. O caso de uso inicia quando o ator seleciona a opção "Realizar Atendimento"; 2. O sistema exibe as opções de realizar atendimento e consulta; 3. O sistema exibe uma lista com todos os chamados abertos. 4. O ator seleciona um chamado específico; 5. O sistema exibe um formulário com os dados do chamado selecionado; 6. O ator insere dados referentes ao atendimento;[RN25][RN26] 7. O ator insere os dados; [RN07] 8. O sistema valida os dados; [E03] 9. O sistema exibe a mensagem [MS11] Fluxo alternativo: A01 (2) - Pesquisar Chamado: 1. O ator seleciona a opção "Pesquisar Chamado"; 2. O ator insere os dados de pesquisa do chamado: 2.1 Número do chamado; 2.2 Data de abertura; 2.3 Patrimônio; 2.4 Setor; 3. O ator insere os dados para pesquisa;[RN11] 4. O sistema valida os dados;[E03] 5. O sistema retorna uma tabela contendo os dados dos setores encontrados na pesquisa; 6. Fim do fluxo alternativo. Pós-condição: Avaliar Chamado.
l) Caso de uso: Emitir Relatórios Descrição: Este caso de uso permite a emissão de relatórios. Atores: Funcionário TI.Pré-condição: O ator deve estar devidamente autenticado no sistema. Fluxo Principal:
55
1. O caso de uso inicia quando o ator seleciona a opção "Emitir Relatórios"; 2. O sistema exibe as opções de relatórios: 2.1 Por setor; 2.2 Pelo status do chamado; 2.3 Por funcionário; 3. O ator seleciona o relatório desejado; 4. O sistema exibe um gráfico com os dados; 5. Fim do Caso de Uso "Emitir Relatório". Fluxo alternativo: Este caso de uso não contém fluxos alternativos. Pós-condição: Este caso de uso não contém pós-condições. Na Tabela 4 são apresentadas as exceções do caso de uso textual, na Tabela 5 são apresentadas suas regras de negócio e a Tabela 6 apresenta as mensagens que o sistema emitirá. Tabela 4 - Exceções ID
EXCEÇÃO
E01
Caso algum dos campos obrigatórios informados na regra [RN07] não tenham sido preenchidos, o sistema deverá emitir a mensagem [MS01] e retornar para o fluxo no passo anterior.
E02
Se for informado um número de patrimônio que não estiver cadastrado o sistema deverá emitir a mensagem [MS02] e retornar para o passo anterior.
E03
Caso a pesquisa não encontre dados o sistema deverá emitir a mensagem [MS03] e retornar ao passo anterior.
E04
Se digitar um login já cadastrado o sistema deve emitir a mensagem [MS07]
E05
Se digitar um número já cadastrado o sistema deve emitir a mensagem [MS09]
Tabela 5 - Regras de Negócio ID
REGRA
RN01
O(s) campo(s) deve(m) ser preenchido(s) automaticamente pelo sistema.
RN02
O campo “Tipo” deve ser uma lista contendo os tipos de serviços cadastrados no Caso de Uso "Manter Tipo de Serviço". A lista deve ser apresentada em ordem alfabética e a opção “Escolha” será a padrão.
RN03
O campo “Serviço” deve ser uma lista contendo os nomes de serviços cadastrados no Caso de Uso "Manter Cadastro de Serviço" de acordo com o tipo de chamado escolhido. A lista deve ser apresentada em ordem alfabética e a opção “Escolha” será a padrão.
RN04
Um mesmo chamado pode conter mais de um serviço, abrindo mais de uma lista.
RN05
Determinados serviços são restritos a usuários com permissões específicas, não estando disponíveis para os usuários que não contém estas permissões.
RN06
Se o tipo de chamado conter um bem patrimoniado, o usuário deverá informar o número do patrimônio e seguir para o próximo passo.
RN07
Os campos indicados por (*) são de preenchimento obrigatório.
RN08
O ator apenas pode visualizar chamados abertos por ele.
RN09
Caso o chamado não envolva bem patrimoniado retorna um campo vazio.
RN10
Dado(s) gerado(s) após finalização do caso de uso "Realizar Atendimento".
56
ID
REGRA
RN11
Pode-se preencher uma ou mais opções de filtro, caso nenhum campo seja preenchido, o sistema retorna todos os dados.
RN12
O campo “Setor” deve ser uma lista contendo os tipos de chamado cadastrados no Caso de Uso "Manter Cadastro de Setor". A lista deve ser apresentada em ordem alfabética e a opção “Escolha” será a padrão.
RN13
Se o tipo de chamado conter um bem patrimoniado, o campo setor deve ser preenchido automaticamente pelo sistema, de acordo com os dados inseridos no Caso de Uso "Manter Cadastro de Patrimônio".
RN14
O número de chamado é um número sequencial gerado automaticamente pelo sistema.
RN15
A opção de cancelamento só deve estar disponível para chamados que não foram finalizados.
RN16
O campo "Histórico" deve ser uma tabela contendo um resumo das atividades realizadas durante o ciclo de vida do chamado.
RN17
A opção de avaliação do chamado só deve estar disponível para chamados já finalizados. Pode ser realizado apenas uma vez por chamado e não é obrigatório.
RN18
Lista contendo os valores "Sim" e "Não".
RN19
Lista contendo os valores 1-Péssimo, 2-Ruim, 3-Regular, 4-Bom, 5-Ótimo, tendo a opção "Escolha" como padrão.
RN20
Devido a dados de log e emissão de relatórios, os dados cadastrados não poderão ser deletados;
RN21
Os status devem ser "Ativo" ou "Inativo", onde os inativos só podem ser utilizados em logs e relatórios, a opção "Ativo" deve ser a padrão.
RN22
A situação do chamado pode ser "Aguardando Atendimento", "Em Atendimento", "Aguardando Agendamento" , "Cancelado" ou "Encerrado", de acordo com a etapa do atendimento do chamado.
RN23
O campo "Permissão" deve ser uma lista contendo os valores "Gerente", "Moderador", "Estagiário", "Comum" e "Avançado", pré definidos pelo sistema.
RN24
O campo visibilidade deve ser uma lista contendo os perfis de usuário que terão permissão para selecionar determinado serviço.
RN25
Um atendimento pode possuir mais de um serviço.
RN26
Os dados de abertura do chamado podem ser modificados durante a realização do atendimento
Tabela 6 - Mensagens ID
MENSAGEM
MS01
"Preencha o campo [Nome do campo]!"
MS02
"Número de Patrimônio Inválido!"
MS03
"Nenhum dado encontrado!"
MS04
"Chamado Cancelado!"
MS05
"Obrigado pela colaboração!"
MS06
"Cadastro Realizado com Sucesso!"
MS07
"Login já cadastrado!"
MS08
"Dados Alterados!"
MS09
"Patrimônio já cadastrado!"
MS10
"Agendamento Realizado!"
MS11
"Atendimento Realizado!"
57
3.2 Elaboração Na fase de elaboração, os requisitos são traduzidos numa especificação de como o sistema será implantado, planejando o restante do projeto.
3.2.1 Diagrama de Classes
A partir dos diagramas de casos de uso gráfico e textual e dos requisitos especificados para o software, pôde-se modelar o diagrama de classes, o qual descreve a estrutura do sistema, mostrando os objetos a serem criados e seus relacionamentos. Sete classes iniciais foram criadas, tendo como pontos centrais as classes "Chamado" e "Detalhe Serviço" conforme mostrado na Figura 8.
Figura 8 - Diagrama de Classe Visão de Negócio
As classes possuem atributos (dados) e operações (comportamentos), que foram implantados no programa em JAVA como campos e operações, respectivamente. Para o desenvolvimento deste projeto utilizou-se a arquitetura MVC, que fornece uma maneira de dividir a funcionalidade envolvida na manutenção e apresentação dos
58
dados de uma aplicação. Usando esse padrão, mapeou-se os conceitos no domínio de aplicações, criando o diagrama de classes exibido na Figura 9.
Figura 9 - Diagrama de Classe Visão de Projeto
59
Nessa arquitetura o modelo representa os dados da aplicação e as regras do negócio que governam o acesso e a modificação dos dados. O modelo mantém o estado persistente do negócio e fornece ao controlador a capacidade de acessar as funcionalidades da aplicação encapsuladas pelo próprio modelo. Um componente de visualização renderiza o conteúdo de uma parte particular do modelo e encaminha para o controlador as ações do usuário. Acessa também os dados do modelo via controlador e define como esses dados devem ser apresentados. Um controlador define o comportamento da aplicação, interpreta as ações do usuário e as mapeia para chamadas do modelo. As ações realizadas pelo modelo incluem ativar processos de negócio ou alterar o estado do modelo. Com base na ação do usuário e no resultado do processamento do modelo, o controlador seleciona uma visualização a ser exibida como parte da resposta à solicitação do usuário. Há um controlador para cada conjunto de funcionalidades relacionadas. Todas as funcionalidades de bancos de dados, como obter as conexões, mapear objetos para tipos de dados SQL ou executar comandos SQL são feitas pelas classes DAO, permitindo assim separar as regras de negócio das regras de acesso a banco de dados.
3.2.2 Diagrama de Sequência O diagrama de sequência foi modelado de acordo com o diagrama de classes. Os objetos destas classes trocam mensagens entre si, modelando a sequência de interações que descrevem o comportamento dos objetos. Por se tratar do caso de uso central do sistema, optou-se por exibir apenas o caso de uso "Abrir Chamado" no diagrama de sequência, como visto na Figura 10. O usuário acessa o formulário de abertura de chamado, a classe controle é acionada, onde estão os métodos para acessar as classes DAO. O usuário seleciona o tipo de serviço e, de acordo com este, seleciona um serviço específico a ser realizado. Se o tipo de serviço referir-se a um patrimônio, a numeração do mesmo deve ser informada e os dados do setor são vinculados automaticamente. Caso não haja patrimônio o setor deve ser adicionado manualmente. Em seguida, a abertura do chamado é finalizada retornando uma mensagem ao usuário.
60
Figura 10 - Diagrama de Sequência Abrir Chamado
3.2.3 Modelagem do Banco de Dados O modelo de classes foi traduzido para a linguagem de banco de dados; no caso deste projeto a linguagem utilizada foi o MySQL. Foi produzido o modelo entidaderelacionamento (MER) exibido na Figura 11. Juntamente com o MER, foi criado um Dicionário de Dados, exibido na Tabela 7, contendo a explicação de todos os objetos nele criados. Este documento permite a obtenção de informações sobre todos os objetos do modelo de forma textual, contendo explicações difíceis de incluir no diagrama. Por fim o banco de dados é apresentado na sua forma textual.
61
Figura 11 - Modelo Entidade Relacionamento
Tabela 7 - Dicionário de dados Entidade: Servico Atributo PK idServico FK idTipoServico Nome Descrição Situação Visibilidade Entidade: tipoServico Atributo PK idTipoServico Nome Situação Descrição Entidade: detalheServiço Atributo PK idDetalheServico FK usuario_matricula FK Idservico FK chamado_numCha mado
Classe Determinante Determinante Simples Simples Simples
Domínio Inteiro Inteiro Caracter Caracter Inteiro
Tamanho
Simples
Inteiro
Classe Determinante Simples Simples
Domínio Inteiro Caracter Inteiro
Tamanho
Simples
Caracter
250
Classe Determinante Determinante Determinante Determinante
Domínio Inteiro Inteiro Inteiro Inteiro
Tamanho
50 250
50
Descrição ID do serviço ID do tipo do serviço Nome do serviço Descrição do serviço Situação que se encontra o serviço Quais usuários terão acesso ao serviço Descrição ID do Tipo do Serviço Nome do Tipo do serviço Situação do Tipo do Serviço Descrição do Tipo do Serviço Descrição ID do Detalhe do Serviço Matrícula do Usuário ID do Serviço Número do Chamado
62
descricaoServico dataServico Entidade: Chamado Atributo PK numChamado FK codigoPatrimonio FK codigoSetor FK usuario_matricula dataAbertura dataEncerramento descricaoProblema Situação dataAgendamento horaAgendamento Entidade: Usuario Atributo PK Matricula FK codigoSetor Nome Cargo Email Senha Telefone Situação Permissão Entidade: Setor Atributo PK codigoSetor Nome Situação Entidade: Patrimonio Atributo PK codigoPatrimonio FK codigoSetor Nome Stuação Descrição
Simple Simples
Caracter Data
255
Descrição do Serviço Formato dd/mm/aaaa
Classe Determinante Determinante Determinante Determinante Simples Simples Simples Simples Simples Simples
Domínio Inteiro Inteiro Inteiro Inteiro Data Data Caracter Inteiro Data Hora
Tamanho
Descrição Numero do Chamado Código do Patrimônio Código do Setor Matrícula do Usuário Formato dd/mm/aaaa Formato dd/mm/aaaa Descrição do Problema Situação do Chamado Formato dd/mm/aaaa Formato 00:00:00
Classe Determinante Determinante Simples Simples Simples Simples Multivalorado Simples Simples
Domínio Inteiro Inteiro Caracter Caracter Caracter Caracter Inteiro Inteiro Inteiro
Tamanho
Classe Determinante Simples Simples
Domínio Inteiro Caracter Inteiro
Tamanho
Classe Determinante Determinante Simples Simples Simples
Domínio Inteiro Inteiro Caracter Inteiro Caracter
Tamanho
250
Descrição Matrícula do Usuário Código do Setor Nome do Usuário Cargo do Usuário E-mail do Usuário Senha de Acesso Número de Telefone Situação do Usuário Tipo de Permissão do Usuário
50 30 50 12
Descrição Código do Setor Nome do Setor Situação do Setor
50
Descrição Código do Patrimônio Código do Setor Nome do bem patrimoniado Situação do Patrimônio Descrição do Patrimônio
20 250
A seguir apresenta-se o banco de dados de forma textual: servico (idservico, idTipoServico, nome, descricao, situacao, visibilidade) idTipoServico referencia TipoServico tipoServico (idTipoServico, nome, situacao, descricao) detalheServico
(idDetalheServico,
usuario_matricula,
idservico,
numChamado,
descricaoServico, dataServico) usuario_matricula referencia usuario idservico referencia serviço numChamado referencia chamado chamado dataAbertura,
(numChamado, dataEncerramento,
codigoPatrimonio, descricaoProblema,
horaAgendamento) codigoPatrimonio referencia patrimonio
codigoSetor, situacao,
usuario_matricula, dataAgendamento,
63
codigoSetor referencia setor usuario_matricula referencia usuario usuario (matricula, codigoSetor, nome, cargo, email, senha, telefone, situacao, permissao) codigoSetor referencia setor setor ( codigoSetor, nome, situacao ) patrimonio (codigoPatrimonio, codigoSetor, nome, situacao, descricao) codigoSetor referencia setor
3.3 Construção
Nesta fase o foco está na implementação, evoluindo-se o protótipo inicial para um produto final.
3.3.1 Implementação
Neste projeto desenvolveu-se um sistema Web utilizando a linguagem JAVA, visando a elaboração de uma interface de software simples e funcional, compatível com qualquer navegador de internet. A Figura 12 apresenta a página inicial do Sistema de Gerenciamento de Suporte contendo os campos de usuário e senha para serem preenchidos
Figura 12 - Tela Inicial do Sistema
64
A conexão com o banco é realizada em três etapas: a primeira refere-se à configurações do banco, feita através do arquivo context.xml ilustrado na Figura 13; a seguinte estabelece a conexão e mapeia as entidades, permitindo a múltipla conexão ao sistema, através do arquivo hibernate.cfg.xml, Figura 14; a última tarefa permite métodos para acessar a sessão, ou seja, a conexão estabelecida com o banco de dados, realizados na classe HibernateConnection, conforme Figura 15.
Figura 13 – Context.xml
Figura 14 - Hibernate.cfg.xml
65
Figura 15- Classe HibernateConnection
Para permitir a manipulação dos dados foi criada uma interface DAO, que contém os principais métodos de acesso ao banco, utilizados em todas as classes DAO descritas no diagrama de classes de visão de projeto. A Figura 16 exemplifica esta interface.
Figura 16 - Interface DAO
Os dados dos objetos foram encapsulados em classes de entidade, que possuem anotações que informam a biblioteca da linguagem JAVA, Hibernate, responsável pela
66
persistência com o banco de dados. Estas anotações são precedidas do símbolo arroba (@);
Figura 17 - Entidade Setor
Por exemplo na Figura17 a anotação @Column identifica determinada variável em relação a uma coluna no banco de dados. As regras de negócio são transpostas em métodos nas classe Actions.
Figura 18 - Classe SetorAction
67
As telas e formulários foram elaborados através de código Hipertext Markup Language (html), junto com estilos Cascading Style Sheets (CSS) e códigos de JavaScript, permitindo um layout simples e funcional aos usuários, apresentado na Figura 19.
Figura 19 - Trecho de formulário de cadastro de patrimônio
Um dos principais itens do sistema é a possibilidade de agendamento de serviços externos durante a realização do atendimento. Esta funcionalidade pode ser gerenciada através de uma agenda, exibida na Figura 20.
Figura 20 - Agenda
68
Outro item importante é a emissão de relatórios. O sistema permite a elaboração de gráficos que representam o número de chamados abertos por cada setor, verificando em quais locais há maior incidência de problemas. Há ainda gráficos que apresentam o número de chamados atendidos por cada funcionário do TI, podendo ter um gerenciamento da demanda. Por fim, permite a criação de gráficos que demonstram os status dos chamados, quantos se encontram abertos, finalizados ou foram cancelados, conforme Figura 21.
Figura 21 - Relatório por setor
3.3.2Testes
A cada iteração, o software foi testado em um processo de avaliação contínua da qualidade, corrigindo problemas e a má interpretação dos requisitos. Neste trabalho foram realizados testes de unidade, integração, sistema, segurança e regressão, realizados pelos próprios desenvolvedores. No teste de unidade pequenas partes do código foram analisadas, encontrando e corrigindo falhas de funcionamento em uma pequena parte do sistema funcionando independente do todo. No teste de integração, avalia-se a combinação de componentes, ou seja, das partes do sistema que dependem de outras partes, como estabelecido na fase de projeto. Assim, foram corrigidas falhas pertinentes à integração entre diferentes módulos. Já o teste de sistema simula a utilização do mesmo como se fosse o usuário final, onde os dados de entrada são os mesmos que um usuário utilizaria no dia-a-dia durante a manipulação do sistema. No teste de segurança foram testados todos os níveis de permissão para a navegação no sistema, verificando se cada um está condizente com seu papel.
69
Durante as iterações do RUP, alguns novos requisitos acarretaram mudanças no escopo original, fazendo com que aplicações já testadas passassem novamente pelos testes, gerando o chamado teste de regressão.
3.4 Transição
A fase de transição é aquela na qual se realiza a transferência do sistema para o cliente. Ao fim deste trabalho, o software proposto não foi implantado em nenhum lugar. O sistema será implantado na prefeitura de Atibaia, onde será avaliado. O software possui seu código fonte aberto, pode ser utilizado e modificado por qualquer pessoa. Este código está disponível no GitHub5 através do endereço https://github.com/vandeko/SGS (apêndice D). O RUP é um processo iterativo, no qual cada iteração é tratada de forma tradicional. Algumas etapas se repetiram uma ou mais vezes durante o ciclo de vida do software até sua implementação. Apenas ferramentas gratuitas foram utilizadas no desenvolvimento do sistema. Para a elaboração dos diagramas de UML foi utilizado o software Astah Community. Para a elaboração do Modelo de Entidade Relacionamento foi utilizado o programa DB Designer, a codificação JAVA foi realizada no NetBeans e, para o servidor Apache, juntamente com a conexão e administração do banco de dados, foi utilizado o WampServer.
5
Serviço Web com planos comerciais e gratuitos para projetos de código aberto.
70
CONSIDERAÇÕES FINAIS
Os objetivos traçados para o Sistema de Gerenciamento de Suporte foram alcançados com sucesso. A implementação do projeto permitiu a elaboração de um sistema que suprisse a lacuna que demais softwares estudados não preenchiam até o momento de sua concepção, como o agendamento de serviços e a vinculação do patrimônio para o controle de serviços. Além de atender, também, aos requisitos levantados através das técnicas e metodologias aplicadas na coleta de dados, através das quais foi possível delimitar as principais funcionalidades do sistema. Entretanto, a implantação do sistema não pôde ser realizada devido à dependência de fatores externos ao projeto. Considerações e análises dos esforços para realização deste trabalho são expostas a seguir. O Sistema de Gerenciamento de Suporte alcançou seus objetivos, sendo possível realizar cadastro dos funcionários de TI, com os devidos perfis de autorização, e dos demais funcionários administrativos que utilizarão a ferramenta para solicitação dos serviços. Um cadastro dos setores foi desenvolvido para melhor controle e análise das requisições. O software possibilitou manter os equipamentos do parque computacional, através de cadastro dos patrimônios. Foram desenvolvidos módulos para registrar os serviços prestados e controlar os chamados executados. A exibição dos detalhes de cada chamado é apresentada em forma de histórico, tanto para os solicitantes dos serviços quanto para os técnicos que ofereceram o suporte. Um dos principais itens do sistema consiste na elaboração de uma agenda para os serviços externos, que promove uma maior organização quanto aos chamados técnicos executados. O agendamento só pode ser realizado pelo usuário autenticado com perfil de moderador, pois esse é responsável por delegar os serviços a serem prestados. Outra funcionalidade contemplada pelo sistema é a emissão de relatórios, sendo o gerente o único perfil autorizado a realizar esta atividade. Os relatórios emitidos dizem respeito aos chamados realizados por:
setor, através dos quais pode-se conhecer os setores com maior incidência
de problemas;
funcionário, na intenção de averiguar os técnicos que mais atendem.
Há ainda o relatório por status de chamados, para informar quantos chamados foram realizados, cancelados ou estão aguardando atendimento. Todos os módulos apresentam uma interface funcional e de fácil navegabilidade.
71
É importante ressaltar que o módulo de agendamento surgiu da necessidade real de organizar tarefas externas e que o mesmo, integrado a um sistema de gerenciamento, proporcionaria ao suporte melhor
controle das atividades.
Estas
funcionalidades não foram encontradas em softwares do Portal do Software Público Brasileiro, estudados durante a etapa de análise deste projeto, assim como o módulo de registro dos equipamentos patrimoniais, o que garante ao setor de TI melhor organização. Pode-se afirmar que o Sistema de Gerenciamento de Suporte, embora não apresente nenhuma inovação tecnológica quanto ao software em si, buscou aperfeiçoar os conceitos já existentes, agrupando ferramentas funcionais e focando a utilização em órgãos municipais. Neste projeto, é imprescindível frisar sobre sistema possuir um código aberto, ou seja, visando o setor público, com o objetivo de propor uma ferramenta de uso gratuito, a fim de que demais profissionais possam manipular o código e melhorá-lo para os devidos fins. O código do Sistema de Gerenciamento de Suporte de TI, está disponível no site GitHub, para que os interessados possam fazer o download e efetuar possíveis alterações de acordo com a necessidade. Destacando assim, o propósito deste projeto em elaborar o sistema de código aberto onde demais prefeituras poderão adquirir e customizá-lo conforme desejarem. As pesquisas realizadas para este trabalho levaram ao aprofundamento de conhecimentos práticos e teóricos, necessários para o desenvolvimento do software e também para avaliar e buscar soluções para os problemas enfrentados no ambiente administrativo municipal, no que diz respeito ao suporte de TI. O trabalho permitiu entender melhor a situação das instituições públicas no sentido tecnológico. As mesmas possuem um grande fluxo de solicitações de suporte aos seus equipamentos e sistemas, o que leva à insatisfação dos profissionais de TI e dos demais servidores que necessitam de suporte, evidenciando a necessidade da utilização de um software que auxilie o gerenciamento do suporte prestado. Os problemas tecnológicos ocorridos nos mais diversos setores afetam a prestação de serviços para os contribuintes, influenciando no desempenho da administração pública. A realização desse trabalho permitiu aos integrantes que são funcionários das prefeituras estudadas uma melhor interpretação do papel oposto ao seu, ou seja, o funcionário de TI pôde entender melhor o usuário e o usuário pode entender melhor o processo de suporte. Assim notou-se que o usuário pode possuir baixo conhecimento em informática, mas o mesmo precisa apenas ter conhecimento na função em que desempenha cabendo ao funcionário de TI possuir maior paciência e dedicação no atendimento.
72
Algumas solicitações podem demorar a ser atendidas, mas isso ocorre por falta de funcionários, equipamentos ou uma maior complexidade para a realização de tal solicitação. O resultado de um sistema eficiente é o aperfeiçoamento do suporte, acarretando maior agilidade na realização das tarefas. Contudo, um sistema, ainda que eficiente, não pode ser tomado como única solução. Profissionais qualificados, ferramentas apropriadas, cursos de capacitação e treinamento completam uma equipe de suporte de TI que possa atender a todas as necessidades expostas da melhor forma possível. Trabalhos Futuros
O Sistema de Gerenciamento de Suporte foi elaborado como sua própria denominação evidencia: para prestar suporte aos envolvidos nos gerenciamentos dos recursos tecnológicos das prefeituras, cumprindo, portanto os resultados esperados. Mediante o sucesso alcançado nos objetivos já expostos, considera-se a possibilidade de importação de bancos de dados a este sistema. Considerando que já exista outro sistema operante em prefeituras que, supõe-se, mantêm um banco de dados contendo informações fundamentais, tais quais as de funcionários, como números de matrícula, setores lotados, entre outros, é de total relevância ao Sistema de Gerenciamento de Suporte adquirir estes dados para compor sua base. Sugere-se, portanto, um módulo visual de importação de banco de dados, a fim de facilitar a manipulação das informações para o usuário. O sistema atualmente disponibiliza três tipos de relatórios, conforme já exposto, para que melhor sejam analisadas as demandas. Sugere-se acrescentar mais opções de relatórios gerenciais, por exemplo: tipo de serviço mais requisitado, para analisar os motivos e aplicar correções. Além de seu código fonte estar disponível no GitHub pretende-se submete-lo ao Portal do Software Público Brasileiro, com a finalidade de disponibilizá-lo para qualquer outro interessado em utilizá-lo. Desta forma, para trabalho futuro se prevê o entendimento das exigências burocráticas para o encaminhamento deste software ao SPB.
73
REFERÊNCIAS BIBLIOGRÁFICAS
APPOLINÁRIO, Fábio. Metodologia da Ciência: filosofia e prática da pesquisa. 2. ed. São Paulo: Cengage Learning, 2012. 240 p.
BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML. 2 ed. Rio de Janeiro: Elsevier, 2007. 369 p.
CARDOSO, Jarbas Lopes; MEFFE Corinto; MARTINS, Pérsio Penteado Pinto. O Software Público Brasileiro. Software Público: Linux Magazine. São Paulo: Linux New Media do Brasil, n. 6, p. 28-29, jun 2011. Edição Especial.
CAVALARI,Gabriel O. T.;COSTA, Heitor A. X. Modelagem e Desenvolvimento de um Sistema Help-Desk para a Prefeitura Municipal de Lavras. Revista Eletrônica de Sistemas de Informação, v. 4, n. 2, 2005. Disponível em: .Acesso em: 21 mar. 2012
DEITEL, P. J. JAVA: Como Programar. 8 ed. São Paulo: Pearson Prentice Hall, 2010. 1145 p.
DESCHAMPS, Samuel Yuri. Framework para Mapeamento Objeto-Relacional em Delphi. Blumenau, 2010. Disponível em: . Acesso em: 5 mai. 2012. FIGUEIREDO, Arianne Vivian de Sousa, et al. Softwares Livres, vantagens. Maringa Management: Revista de Ciências Empresariais, v. 2, n. 1 p. 26-33, jan./jun. 2005.
FOWLER, Martim. Arquitetura de Aplicações Corporativas. Tradução Addison Wesley Professional. 1. ed. São Paulo: Bookman, 2006. 492 p.
GIL, Antonio Carlos. Métodos e Técnicas de Pesquisa Social. 6. ed. São Paulo : Atlas, 2010. 200 p.
GILMORE, W. Jason. Dominando PHP e MySql - Do Iniciante ao Profissional. 3 ed. Rio de Janeiro: Alta Books, 2008. 769 p. GUEDES, Gilleanes T. A.. UML 2 - Uma Abordagem Prática. 2 ed. São Paulo: Novatec, 2011. 484 p.
74
HORSTMANN, Cay S. Core JAVA, volume 1: Fundamentos. 8 ed. São Paulo: Pearson Prentice Hall, 2010. 383 p. MACEDO, Roberto Gondo, A Democratização da Informação na Gestão Pública: A Cibercomunicação como Ferramental Estratégico no Tratamento da Informação. Santos, 2007. Disponível em: . Acesso em 15 mar. 2012.
MACHADO, Murilo Bansi. Distros e comunidades: a dinâmica interna de Debian, Fedora, Slackware e Ubuntu. In: AGUIAR, Vicente Macedo de (Org). Software Livre, cultura hacker e o ecossistema da colaboração. 1 ed. São Paulo: Momento Editorial, 2009. p. 14-38.
MANZANO, José Augusto N. G. MySql5.0, interativo: guia básico de orientação e desenvolvimento. 1 ed. São Paulo: Érica, 2007. 332 p. MARTINS, José Carlos Cordeiro. Gerenciando Projetos de desenvolvimento de Software com PMI, RUP e UML. 3 ed. Rio de Janeiro: Brasport, 2006. 308p.
MELHORAMENTOS. Michaelis Dicionário Prático-Inglês. 2 ed. São Paulo: Melhoramentos, 2010. 958p.
OLIVEIRA, Maria Marly de. Como fazer Projetos, Relatórios, Monografias, Dissertações, Teses. 5 ed. Rio de Janeiro: Elsevier, 2010. 232 p.
OLIVEIRA, O. J. (Org.). Gestão da qualidade: tópicos avançados. 1 ed. São Paulo: Thomson Learning, 2006, 243 p. PAJE-JONES, Meiler. Fundamentos do Desenho Orientado a Objeto com UML. 1 ed.,São Paulo: Makron Books, 2001. 369 p. PERAIRE, Cécile. et al. The IBM Rational Unified Process for System z. 1 ed. Redbooks, 2007. 270 p. Disponível em . Acesso em: 10 jun 2012.
PIRES, José Calixto de Souza; MACEDO, Kátia Barbosa. Cultura organizacional em organizações públicas no Brasil. Revista de Administração Pública. Rio de Janeiro, v. 40, n. 1, jan/fev. 2006. Disponível em: . Acesso em: 15 mar. 2012.
PRESSMAN, Roger S. Engenharia de Software: uma abordagem profissional. Tradução Ariovaldo Griesi e Mario Moro Fecchio. 7. ed. Porto Alegre: AMGH, 2011. 780 p.
75
RODRIGUEZ, Martius Vicente Rodriguez y; VIEIRA, Daniele Machado. Governança de TI no Setor Público - Caso Data Prev. Revista Produção Online, Florianópolis, v.7, nº 7, p. 207-225, dez./abr. 2007. SILVEIRA, Sérgio Amadeu da. Software Livre: a luta pela liberdade do conhecimento. 1 ed. São Paulo: Editora Fundação Perseu Abramo, 2004. 79 p. SOMMERVILLE ,Ian. Engenharia de Software. Tradução Ivan Bosnic e Kalinka G. de O. Gonçalves. 9. ed. São Paulo: Person Prentice Hall, 2011. 529 p.
STATDLOBER, Juliano. Help-Desk e SAC com qualidade. 1 ed. Rio de Janeiro: Brasport, 2006. 176 p.
ZIELINSKI, Fabio; BORTOLETO, Silvio. Aplicação de RBC em Sistema de Help Desk: estudo de caso RadSystem. In: SEGET – SIMPÓSIO DE EXCELÊNCIA EM GESTÃO E TECNOLOGIA, 4., 2007, Curitiba. Disponível em: . Acesso em: 21 mar. 2012.
76
APÊNDICE A - QUESTIONÁRIO SETOR DE TI Entrevistado:_______________________________Função:_______________________ 1. Formação: a. b. c. d. e. f. g.
Ensino médio incompleto Ensino médio completo Ensino superior incompleto Curso técnico Superior completo na área Superior completo fora da área Pós graduação
2. Existe algum software de gerenciamento e controle do setor? a. Sim b. Não 3. Qual a frequência de utilização do atual sistema, caso haja algum? a. b. c. d.
Esporadicamente Uma vez por semana Algumas vezes por semana Todos os dias
4. Com que frequência você realiza atendimento de suporte? a. b. c. d.
Esporadicamente Uma vez por semana Algumas vezes por semana Mais de uma vez por dia
5. O atual sistema proporciona agilidade nos atendimentos e demais serviços realizados por este setor? a. Sim b. Não 6. Como são tratadas situações reincidentes? a. Buscam diferentes formas para descobrir o motivo das reincidências. b. Tratam iguais aos demais problemas. c. Outros _________________________________________________________ 7. O que acha necessário adicionar em um novo sistema?
77
APÊNDICE B - QUESTIONÁRIO DEMAIS SETORES Entrevistado: _________________________________________________ Função:______________________________________________________ Secretaria/Departamento/Setor:__________________________________ 1. Formação: a. b. c. d. e. f.
Ensino médio incompleto Ensino médio completo Ensino superior incompleto Superior completo na área Superior completo fora da área Pós graduação
2. Qual a forma de contatar o suporte de TI? a. b. c. d. e.
Telefone Memorando / Comunicado E-mail Chat Outros
3. a. b. c. d. e.
Como você analisa o tempo de resposta ao entrar em contato com o suporte? Ótimo Bom Regular Ruim Péssimo
4. Com que frequência é necessário acionar o suporte? a. b. c. d.
Esporadicamente Uma vez por mês Uma vez por semana Várias vezes por semana
5. O suporte é eficaz/ pratico? a. Sim b. Não c. Às vezes 6. Os problemas são resolvidos? a. b. c. d.
Sim, sempre Às vezes Quase nunca Nunca
78
7. Qual a atitude do suporte quanto a problemas repetitivos? a. Buscam resolver o problema de qualquer forma b. Tentam algumas vezes resolver, mas se não obtiverem sucesso, não tomam nenhuma outra providencia c. Nada fazem para resolver os problemas contínuos d. Outros _________________________________________________________ 8. Existe algum tipo de feedback (resposta) por parte do suporte após os atendimentos? a. b. c. d.
Sim, sempre Às vezes Quase nunca Nunca
9. Qual sua opinião sobre o atual suporte do TI? Existe algum tipo de feedback (resposta) por parte do suporte após os atendimento 10. Dê sugestões para melhorar a forma de ser atendido:
79
APÊNDICE C - GRÁFICOS
Gráfico 1 - Gráfico Formação Acadêmica TI
Gráfico 2 - Existência Atual de Sofware de Suporte
80
Gráfico 3 - Frequência de Realização de Atendimento
Gráfico 4 - Frequência Utilização do Software de Suporte
81
Gráfico 5 - Satisfação Quanto a Agilidade do Sistema
Gráfico 6 - Tratamento de Situações Reincidentes
82
Gráfico 7 - Formação Acadêmica Demais Setores
Gráfico 8 - Forma de Acionar o Suporte
83
Gráfico 9 - Frequência de Acionamento do Suporte
Gráfico 10 - Satisfação Quanto ao Tempo de Resposta do Suporte
84
Gráfico 11 - Feedback Quanto ao Atendimento Prestado
Gráfico 12 - Satisfação Quanto a Resolução de Problemas
85
Gráfico 13 - Satisfação Quanto a Eficácia do Suporte restado
Gráfico 14 - Satisfação Quanto a Atitude Tomada em Problemas Reincidentes
86
APÊNDICE D – TELA DO GITHUB
87
APÊNDICE E – APROVAÇÃO COMITÊ DE ÉTICA
Lihat lebih banyak...
Comentários
