INSTITUTO FEDERAL DO PARANÁ TAISE CALIXTO GONÇALVES

Transcrição

1 1 INSTITUTO FEDERAL DO PARANÁ TAISE CALIXTO GONÇALVES SGIM SISTEMA DE GERENCIAMENTO DE INFORMAÇÕES DE MANUTENÇÃO PARANAGUÁ 2012

2 2 TAISE CALIXTO GONÇALVES SGIM SISTEMA DE GERENCIAMENTO DE INFORMAÇÕES DE MANUTENÇÃO Trabalho de Conclusão de Curso apresentado ao Curso Técnico em Informática do Instituto Federal do Paraná, como requisito parcial de avaliação. Orientador: Wagner Rodrigo Weinert PARANAGUÁ 2012

3 3 AGRADECIMENTOS A Deus que me deu forças e segurança para que mais essa etapa da minha vida fosse concluída. Aos meus pais por todo apoio e incentivo ao longo da minha vida escolar, possibilitando que esse trabalho fosse desenvolvido. Aos amigos que estiveram presentes ao longo dessa jornada, compartilhando experiências e vivenciando ótimos momentos. Aos Professores do IFPR Campus Paranaguá, por todo o conhecimento ministrado. Ao colaborador Rafael Vargas pela gentileza em me ajudar no desenvolvimento do sistema. E ao Prof. Dr. Wagner Rodrigo Weinert, orientador deste trabalho, pela paciência e comprometimento que foram de fundamental importância durante todo o processo de desenvolvimento.

4 4 Plante seu jardim e decore sua alma, ao invés de esperar que alguém lhe traga flores. E você aprende que realmente pode suportar, que realmente é forte, e que pode ir muito mais longe depois de pensar que não se pode mais. E que realmente a vida tem valor e que você tem valor diante da vida! (William Shakespeare )

5 5 RESUMO Na empresa alimentícia X, atualmente, utiliza-se um sistema de gerenciamento de informações que é de extrema importância para o bom funcionamento da mesma. Porém, ao longo de sua utilização, o sistema apresentou problemas que foram relatados por seus usuários. Esse estudo tem o objetivo de analisar o sistema utilizando processos como a engenharia reversa, buscando aprimorar e desenvolver novas funcionalidades. O projeto será desenvolvido utilizando a arquitetura web interna da empresa. Em relação à modelagem, serão utilizados os conceitos de engenharia de software e análise estruturada para os diagramas do sistema. Ciclos de desenvolvimento como o paradigma em espiral e o ciclo PDCA são de extrema importância para prevenir problemas futuros. Além disso, serão utilizadas as linguagens ASP, HTML e JavaScript. A estrutura do banco de dados será remodelada utilizando o Modelo Entidade e Relacionamento e o Modelo Relacional, com o objetivo de armazenar dados de uma forma segura e organizada. Palavras-chave: PDCA. ASP. JavaScript. HTML. arquitetura web

6 6 ABSTRACT In food company X, currently uses a system of information management which is extremely important for the proper functioning of the same. However, throughout its use, the system had problems that were reported by users. This study aims to analyze the system using processes such as reverse engineering, seeking to enhance and develop new features. The project will be developed using the company's internal web architecture. Regarding modeling, will be used the concepts of software engineering for structured analysis and system diagrams. Development cycles as the paradigm spiral and PDCA cycle are extremely important to prevent future problems. Also, will be used ASP, HTML and JavaScript. The structure of the database will be remodeled using the Entity Model and Relationship and Relational Model, in order to store data in a safe and organized. Key Words: PDCA. ASP. JavaScript. HTML. web architecture

7 7 LISTA DE ILUSTRAÇÕES FIGURA 1 - Paradigma em Espiral FIGURA 2 - Ciclo PDCA FIGURA 3 - Quadro do Planejamento Kanban FIGURA 4 - Modelo Entidade Relacionamento FIGURA 5 - Modelo Relacional FIGURA 6 - Representação de um Processo FIGURA 7 - Representação de um Fluxo FIGURA 8 - Representação de um Depósito de Dados FIGURA 9 - Representação de um Terminador FIGURA 10 MER - Solicitação de Serviço e Materiais FIGURA 11 MER - IDM s FIGURA 12 MER Planejamento Kanban FIGURA 13 - Antigo MR - Solicitação de Serviços e Materiais FIGURA 14 Novo MR - Solicitação de Serviços e Materiais FIGURA 15 - Antigo MR - IDM's FIGURA 16 Novo MR IDM s FIGURA 17 MR Planejamento Kanban FIGURA 18 DF Nível FIGURA 19 DFD Nível FIGURA 20 DF Nível 2 Solicitação de Serviços e Materiais FIGURA 21 DF Nível 2 IDM s FIGURA 22 DFD Nível 2 Planejamento Kanban FIGURA 23 Tela Index FIGURA 24 Tela de Consulta de Solicitações FIGURA 25 Tela de Itens da Solicitação FIGURA 26 Tela do Relatório de Solicitações FIGURA 27 Tela de Cadastro de Índices FIGURA 28 Tela de Consulta dos Índices FIGURA 29 Tela de Exibição de Gráfico FIGURA 30 Tela de Cadastro de Manutentores FIGURA 31 Tela de Consulta do Planejamento... 42

8 8 SUMÁRIO 1 INTRODUÇÃO E JUSTIFICATIVA OBJETIVO GERAL OBJETIVOS ESPECÍFICOS FUNDAMENTAÇÃO TEÓRICA ENGENHARIA DE SOFTWARE Paradigma em Espiral Manutenção de Software e Sistemas Engenharia Reversa LINGUAGENS ASP HTML Javascript SISTEMAS DE INFORMAÇÕES GERENCIAIS Ciclo PDCA Planejamento Kanban BANCO DE DADOS Banco de Dados Relacional Modelo Entidade Relacionamento (MER) Modelo Relacional (MR) ANÁLISE ESTRUTURADA Diagrama de Fluxo de Dados Processos Fluxo Depósito de Dados Terminadores... 25

9 9 3 METODOLOGIA ANÁLISE DE REQUISITOS MODELO ENTIDADE RELACIONAMENTO - MER MODELO RELACIONAL - MR DIAGRAMA DE FLUXO DE DADOS DFD RESULTADOS INDEX SOLICITAÇÃO DE SERVIÇOS E MATERIAIS Itens da Solicitação Relatório de Solicitações IDM s Cadastro de Índices Consulta de Índices PLANEJAMENTO KANBAN Cadastro de Manutentores Consulta do Planejamento CONCLUSÃO REFERÊNCIAS... 44

10 10 1 INTRODUÇÃO E JUSTIFICATIVA A gestão de informações de manutenção é um processo muito importante para garantir o bom funcionamento da empresa alimentícia X. Para realizar essa gestão, atualmente, utiliza-se um sistema web localizado na intranet da empresa. O sistema foi desenvolvido pelos alunos Jonatan Dias Pinheiro e Jonathan Hikaru Matsuzaki como trabalho de conclusão de curso no ano de 2011, contribuindo com a automação dos processos e diminuindo o risco de falhas. Durante o seu período de utilização, que vem desde o inicio de 2011 até abril de 2012, o sistema apresentou algumas deficiências, relatadas por seus usuários. Entre elas, está a necessidade de preencher todos os campos de uma solicitação de compra. Se o usuário esquecerse de preencher um campo que não é obrigatório, perde todos os outros itens preenchidos corretamente. Esse tipo de erro provoca o retrabalho, atrasando e dificultando a conclusão da atividade. Devido a esses erros, algumas funções até foram abandonadas e não estão mais em uso. Deficiências como essas, são decorrentes do processo de engenharia de software, que precisa ser seguido rigorosamente, passando por todas as etapas para evitar que situações como essa venham a ocorrer. Baseado na importância do sistema para empresa, o processo de manutenção é necessário para buscar erros e garantir melhorias. 1.1 OBJETIVO GERAL Dar continuidade ao trabalho iniciado no ano de 2011, testando e aprimorando o sistema, revisando e reestruturando todos os modelos utilizados para representá-lo. 1.2 OBJETIVOS ESPECÍFICOS Este trabalho tem os seguintes objetivos específicos: Identificar o maior número possível de falhas do sistema atual; Identificar funcionalidades ainda não implementadas, mas essenciais para a empresa, utilizando entrevistas com usuários;

11 11 Revisar toda a modelagem do sistema; Implementar as modificações; Testar o sistema; Reimplantar o sistema; Reavaliar a satisfação do usuário;

12 12 2 FUNDAMENTAÇÃO TEÓRICA 2.1 ENGENHARIA DE SOFTWARE A utilização da Engenharia de Software cresce dia após dia, gerando vários conceitos entre diferentes especialistas. Para Rezende (2005, p.2) É a metodologia de desenvolvimento e manutenção de sistemas modulares, com as seguintes características: processo (roteiro) dinâmico, integrado e inteligente de soluções tecnológicas: adequação aos requisitos funcionais do negócio do cliente e seus respectivos procedimentos pertinentes: efetivação de padrões de qualidade, produtividade e efetividade em suas atividades e produtos; fundamentação na Tecnologia da Informação disponível, viável, oportuna e personalizada; planejamento e gestão de atividades, recursos, custos e datas. O objetivo fundamental da Engenharia de Software é controlar o desenvolvimento de um sistema, garantindo que as necessidades do cliente sejam atendidas, evitando problemas e buscando melhores resultados. Segundo Carvalho e Chiossi (2001, citado por REZENDE, 2005) A engenharia de software é uma disciplina que reúne metodologias, métodos e ferramentas a serem utilizados, desde a percepção do problema até o momento que o sistema desenvolvido deixa de ser operacional, visando resolver problemas inerentes ao processo de desenvolvimento e ao produto de software. Este conceito apresenta uma Engenharia de Software diferenciada, dividida em três partes essenciais: métodos, ferramentas e metodologias ou processos. Os métodos envolvem um estudo de como será o desenvolvimento do software através de processos como o planejamento e a análise de requisitos. As ferramentas são métodos criados para facilitar o desenvolvimento, como por exemplo, orientação a objetos e análise estruturada. Os processos são a junção das duas partes anteriores. Eles determinam a sequência em que o projeto será desenvolvido, priorizando a qualidade do software. Porém, alguns especialistas costumam omitir esse conceito gerencial da Engenharia de Software, voltando-se apenas para o lado tecnológico do processo. Conforme Pressman (1995, citado por REZENDE, 2005), Os aspectos gerenciais do desenvolvimento de software devem receber uma atenção cada vez maior nessa disciplina. Portanto, o conceito de Engenharia de Software não deve ser compreendido como algo isolado, e sim interdisciplinar como afirma Maffeo (1992, citado por REZENDE, 2005). Para ele a engenharia de software é:

13 13 A área interdisciplinar que engloba vertentes tecnológica e gerencial visando a abordar de modo sistemático (modular), os processos de construção, implantação e manutenção de produtos de software com qualidade assegurada por construção segundo cronogramas e custos previamente definidos. Por isso, é muito importante que seja adotado um modelo de processo de desenvolvimento de software. Através dele podemos melhorar a parte tecnológica através da parte gerencial. Existem diversos tipos de modelos, entre eles o paradigma em espiral que será utilizado ao longo do desenvolvimento do projeto. A Engenharia de Software vai além do desenvolvimento e abrange também a manutenção, parte crucial para garantir o bom funcionamento do sistema. Existem diversas técnicas que possibilitam que a manutenção seja realizada da melhor forma possível, entre elas a engenharia reversa. Define-se então Engenharia de Software como um processo de planejamento do projeto, como das ferramentas e metodologias a serem utilizadas Paradigma em Espiral O modelo em espiral foi proposto originalmente por Barry Boehm em 1988, apresentando uma forma rápida de desenvolver softwares mais completos. Segundo Boehm (2000, citado por PRESSMAN, 2005). O modelo espiral de desenvolvimento é um gerador de modelo de processo guiado por risco usado para guiar a engenharia de sistemas intensivos em software com vários interessados concorrentes. Ele tem duas principais características distintas. A primeira é uma abordagem cíclica, para aumentar incrementalmente o grau de definição e implementação de um sistema enquanto diminui o seu grau de risco. A outra é um conjunto de marcas de ancoragem, para garantir o comprometimento dos interessados com soluções exequíveis e mutuamente satisfatórias para o sistema. Utilizando esse modelo é possível seguir um processo evolucionário realizando atividades descritas no espiral em sentindo horário, partindo do centro. A Figura 1 apresenta um exemplo do paradigma, que é composto por quatro etapas: planejamento, análise de riscos, engenharia e avaliação do cliente.

14 14 FIGURA 1 - Paradigma em Espiral O planejamento é o primeiro passo e o mais relevante. Durante esse processo são definidos os objetivos, a metodologia e as suas possíveis restrições. É o planejamento que serve de base para o próximo passo: a análise de riscos. Através dessa análise é possível identificar, estimar e monitorar acontecimentos que possam colocar em risco a execução do projeto. Completando o planejamento e a análise de riscos é possível partir para a execução da engenharia, que é o desenvolvimento propriamente dito. Após completar os três primeiros passos o sistema é submetido à avaliação do cliente. É muito importante para a segurança do projeto que todos os passos sejam seguidos na ordem estipulada e quantas vezes seja preciso. Cada vez que o ciclo é encerrado novas informações são adicionadas garantindo qualidade e segurança ao projeto. O diferencial do modelo em espiral é que ele pode ser utilizado tanto no desenvolvimento do software como na sua manutenção. Segundo Pressman (2005, pg. 45). Em resumo, a espiral, quando caracterizada desse modo, permanece operacional até que o software seja retirado de serviço. Há momentos em que o processo fica adormecido, mas sempre que uma modificação é iniciada, o processo começa no ponto de entrada adequado (por exemplo, aperfeiçoamento de produto). O modelo em espiral é uma ótima abordagem para desenvolvimento de projetos porque à medida que o processo avança o desenvolvedor pode se preparar melhor para enfrentar as restrições apresentadas por cada etapa do ciclo.

15 Manutenção de Software e Sistemas A manutenção é de extrema importância para o ciclo de vida de um software, seja ela para corrigir erros ou adicionar novas funcionalidades. Para Pressman (1995, citado por REZENDE, 1999), A manutenção de software é caracterizada como um iceberg, ou seja, esperamos que apenas a parte visível esteja carente de manutenção, porém, normalmente uma massa enorme de problemas e custos esconde-se sobre a superfície. A forma de manutenção usada para correção de erros é muito frequente. Muitos projetos são levados à adiante sem completarem todo o ciclo de desenvolvimento da engenharia, ocasionando falhas. Portanto o desenvolvedor precisa ficar atento aos erros que foram deixados para trás. Apesar de ser considerada problemática, baseando-se na importância de um sistema para determinada empresa, esse tipo de manutenção é muito utilizado, buscando resgatar erros e garantir melhorias através de processos como a engenharia reversa Engenharia Reversa O processo de engenharia reversa consiste em reavaliar softwares, partindo do resultado final do projeto em busca de uma maior compreensão do mesmo. Para Pressman (1995, citado por REZENDE, 1999) A engenharia reversa tem como princípio a desmontagem das caixas pretas do software, de seus segredos, de trás para frente, ou seja, o processo de recuperação do projeto com especificação e documentação procedimental, arquitetural e de dados. A vantagem do uso do processo de engenharia reversa, é que através das informações recuperadas sobre o software já existente é possível melhorar o sistema, reimplementando e adicionando novas funcionalidades.

16 LINGUAGENS ASP Em 1996 a Microsoft apresentou o ASP, uma nova linguagem de programação derivada do BASIC que foi criada para funcionar nos servidores de internet da Microsoft (IIS). A linguagem ASP surgiu para sanar problemas enfrentados pelos programadores da época como a preocupação com a velocidade de acesso e a sobrecarga do sistema. Sua utilização também sanou o problema de interpretação encontrado em alguns navegadores em relação ao Javascript, pois seus scripts são enviados ao servidor e transformados em saídas, como o HTML. Oferecendo muitos tipos de aplicações distintas, permite acesso à base de dados, ao sistema de arquivos do servidor e em geral, a todos os recursos que tenha o próprio servidor. Utilizada em sites simples e grandes servidores, a versatilidade e facilidade do ASP fizeram com que essa linguagem se tornasse uma ótima opção para desenvolvimento web HTML A HTML foi criada em 1990 por um cientista chamado Tim Berners-Lee com a finalidade inicial de possibilitar a troca de documentos entre cientistas de diversas universidades. O sucesso foi tanto que hoje em dia o HTML é amplamente utilizado. Considerado por muitos como uma linguagem de programação, o HTML é essencialmente para a formatação de páginas como afirma Campos (2004, pg. 19). Ao contrário do que parece, HTML não é uma linguagem de programação porque não possui comandos para tomada de decisões (if...then...else), estruturas de repetição (do...while, repeat...while),variáveis, funções etc. O HTML pode ser definido basicamente como um conjunto de TAG s utilizadas para definir como o texto e outros elementos da página serão mostrados na tela. Por ser de fácil aprendizagem e poder ser manipulada em qualquer editor de texto é uma linguagem que ganhou o mundo no quesito desenvolvimento web.

17 Javascript Originalmente desenvolvido por Brendan Eich da Netscape em 1995, o javascript é um linguagem de script de páginas web que acabou tornando-se a linguagem de programação mais popular para esse tipo de aplicação. Consagrou-se por características inovadoras como, por exemplo, o suporte a sintaxe de programação estruturada da linguagem C com seus elementos condicionais. Nas páginas web é responsável por diversas funções que são incluídas em páginas HTML fornecendo facilidade, como é o caso da validação de dados, conforme afirma Ynemine (2005, pg. 1) Pode-se inserir comandos para executar algo quando uma página for aberta ou fechada, pode-se criar uma validação de formulário para a verificação do correto preenchimento dele, efetuar contas, exibir mensagens na barra de status, criar pequenas animações, entre outros. Por ser uma linguagem suportada por muitos navegadores, o Javascrip tornou-se uma linguagem essencial para muitos frameworks em outras linguagens. Graças a sua crescente velocidade de implementações tem ganhado o título de linguagem intermediária mais prática. 2.3 SISTEMAS DE INFORMAÇÕES GERENCIAIS Para uma empresa as tomadas de decisões são de extrema importância para seu futuro. Por essa razão, as informações a serem gerenciadas precisam estar organizadas para uma melhor visualização. Surge então a necessidade de sistemas gerenciais que facilitem o trabalho dos gestores de informação, garantindo informações úteis e válidas. O sistema é responsável por fornecer à empresa informações que possam melhorar seu desempenho e evitar futuros problemas em vários níveis (estratégico, tático e operacional). A empresa torna-se então mais dinâmica e flexível, proporcionando a interação de todos e encontra no sistema de gerenciamento uma ferramenta de apoio ao processo decisório.

18 Ciclo PDCA O método PDCA foi desenvolvido na década de 30 pelo americano Walter Andrew Shewhart. Mas foi William Edwards Deming o responsável pela difusão do método no Japão. O PDCA constitui um ciclo de desenvolvimento buscando qualidade e melhoria contínua. No ciclo a análise e documentação dos processos são relevantes para atingir as metas estipuladas pela empresa. Ele é dividido em quatro pontos principais, conforme a Figura 2: Plan (planejar), Do (executar), Check (verificar) e Action (agir). FIGURA 2 - Ciclo PDCA Plan O ciclo PDCA inicia-se na fase de planejamento, a mais importante na execução de qualquer processo. Nessa fase são decididas as metas a serem compridas e a metodologia utilizada para atingir os objetivos desejados. Os conceitos de Engenharia de Software são aplicados nessa fase, em que o projeto precisa ser planejado com seus respectivos custos e riscos.

19 19 Do A partir da metodologia definida no planejamento é preciso dar inicio aos treinamentos necessários para que o desenvolvedor consiga levar o projeto a adiante. Essa fase do ciclo também contempla a programação em si. Check A fase de verificação é muito importante porque através dela é possível analisar se o trabalho está seguindo como foi proposto. Ela precisa ser implementada não só no terceiro passo do ciclo, mas em todo ele, pois é de fundamental importância que o projeto funcione bem. É preciso testar e avaliar a qualidade do software. Nessa etapa erros futuros podem ser evitados garantindo uma melhor produtividade do sistema. Action Com as informações reunidas na fase de verificação, se for necessário, é preciso corrigir erros ou propor melhorias no desenvolvimento do processo para que as metas iniciais sejam cumpridas e as necessidades do cliente atendidas Planejamento Kanban O Sistema Kanban foi desenvolvido com o objetivo de facilitar a gestão visual ( Kanban significa cartão visual em japonês.). No planejamento da manutenção, o conceito é aplicado através de um quadro de gestão onde as tarefas semanais dos manutentores são identificadas por cartões coloridos conforme é possível observar na Figura 3.

20 20 FIGURA 3 - Quadro do Planejamento Kanban As cores dos cartões são definidas pela seguinte sistemática: Tarefa executada retira-se o cartão verde do quadro; Tarefa atrasada 7 dias substitui-se o cartão verde por amarelo; Tarefa atrasada 14 dias substitui-se o cartão amarelo por vermelho; Por exemplo, é planejado para um eletricista trocar uma lâmpada no dia 05 de novembro de 2012 (segunda-feira). Ao fim da semana de planejamento, no dia 10 de novembro de 2012 (sábado), checou-se que o eletricista não trocou a lâmpada e acrescentou-se uma placa amarela ao quadro. Inicia-se uma nova semana de planejamento. Ao fim da semana, ao checar que o eletricista cumpriu a tarefa, retirou-se a placa do quadro. 2.4 BANCO DE DADOS Armazenar informações importantes sempre foi essencial à vida do ser humano. Antigamente elas eram registradas em papel, ocasionando perda de dados e excesso de material. Para resolver esse problema, na década de 60, surgiram os primeiros sistemas de banco de dados. Mas esses sistemas pioneiros ainda continham muitos erros, conforme afirma Alves (2004, pg.21)

21 21 (...) Essa arquitetura tinha vários inconvenientes, sendo os cinco principais: -Não havia controle de acesso concorrente de vários usuários -Não era possível executar mais de um processo ao mesmo tempo num arquivo de dados -A definição da estrutura do arquivo se encontrava inserida no próprio código do aplicativo, o que significa que os programas controlavam as tarefas de gravação e leitura dos dados no arquivo. Isso ocasionava uma dependência entre o banco de dados e a aplicação, tornando muito complexo o processo de manutenção de todo o sistema. -Inconsistência, redundância, dificuldade de acesso e isolamento de dados. -Problemas relativos à segurança nos dados Cada modificação no código fonte exigia modificações nas suas duplicatas também, dificultando a manutenção do sistema. Surge então o chamado Sistema Gerenciador de Banco de Dados, o SGBD. Esse sistema inovador permite ao usuário criar e manter um banco de dados de uma forma segura e sem problemas estruturais. É possível compreender o conceito de banco de dados utilizando exemplos simples, presente em nosso dia-a-dia, como nas lojas, nos bancos e nos supermercados Segundo Elmasri e Navathe (2011, pg.3) Um banco de dados é uma coleção de dados relacionados. Com dados, queremos dizer fatos conhecidos que podem ser registrados e possuem significado implícito. Por exemplo, considere os nomes, números de telefone e endereços das pessoas que você conhece. Você pode ter registrado esses dados em uma agenda ou, talvez, os tenha armazenado em um disco rígido, usando um computador pessoal e um software como Microsoft Access ou Excel. Essa coleção de dados relacionados, com um significado implícito, é um banco de dados Banco de Dados Relacional O banco de dados relacional surgiu na década de 70, tornando-se uma alternativa para o uso do banco de dados hierárquico e em rede. Atualmente é o modelo de banco de dados mais utilizados nas aplicações. Esse tipo de banco é constituído basicamente por tabelas simples, estruturadas em linhas e colunas, que se relacionam entre si. As tabelas facilitam a organização de dados e possibilitam consultas para responder a perguntas relacionadas aos negócios do cliente.

22 Modelo Entidade Relacionamento (MER) O modelo entidade relacionamento baseia-se na percepção do mundo real oferecendo facilidade para o desenvolvimento do projeto de banco de dados. Representa através de diagramas objetos básicos chamados entidades e as relações entre esses objetos..as entidades são representadas pelos retângulos e a relação entre elas é representada através de um losango. Cada entidade e relacionamento possuem determinados atributos. No exemplo da Figura 4, para realizar um pedido (relação) existem duas entidades envolvidas: fornecedor e produto. Fornecedor Pedido Produto Cod-Forn Preço Quant. Cod-Prod FIGURA 4 - Modelo Entidade Relacionamento Modelo Relacional (MR) O modelo relacional é uma representação do banco de dados através de um conjunto de relações. Para ELMASRI e NAVATHE (2011, pg.39). Informalmente, cada relação é semelhante a uma tabela de valores, ou até certo ponto, a um arquivo plano de registros. Ele é chamado de arquivo plano porque cada registro tem uma simples estrutura linear ou plana. Conforme a Figura 5, neste modelo as relações são representadas por tabelas que são equivalentes a entidades do modelo entidade relacionamento.

23 23 FIGURA 5 - Modelo Relacional 2.5 ANÁLISE ESTRUTURADA A análise estruturada é um processo para a diagramação do projeto com a finalidade de retratar o fluxo e as informações envolvidas no sistema, a partir de uma divisão em módulos para uma melhor visualização. Para Gane e Sarson (1986, citado por REZENDE, 1999) Análise estruturada é uma das tantas técnicas para a efetivação de uma Metodologia de Desenvolvimento de Sistemas ou Software, bem como, é um conjunto de ferramentas orientado para a construção de uma especificação estruturada para projetos, sistemas e software, tanto do ponto de vista lógico, como físico. Essa forma de análise é frequentemente escolhida porque seus diagramas são compreensíveis e com poucos símbolos, características importantes para quebrar a barreira entre o conhecimento técnico em informática e o conhecimento da empresa em questão. Aproximando o cliente do desenvolvedor, a análise estruturada busca evitar a manutenção do sistema, reduzindo custos e aumentando a produtividade.

24 Diagrama de Fluxo de Dados O diagrama de fluxo de dados é uma das principais modelagens gráficas da análise estruturada. Para Ferreira (1989, citado por REZENDE, 1999), Técnica estruturada de diagramação de software, possui tipos diversificados de diagramas, derivando-se (ou explodindo) em outros subsequentes. Esse tipo de diagrama é muito utilizado devido a sua fácil visualização. A divisão das funcionalidades do sistema em módulos facilita a compreensão do mesmo. Segundo Yourdon (1990, pg. 179) Ele não precisa de explicações; basta olharmos para ele para compreendêlo. A representação é simples e sem intrusões e, de uma certa forma, bastante intuitivo. Isso é especialmente importante quando lembramos quem supostamente examinará a figura não o analista de sistemas, mas o usuário! Se precisar de uma enciclopédia para ler e entender o modelo do sistema, provavelmente não se interessará por nada daquilo. Um diagrama de fluxo de dados possui quatro componentes principais: processos, fluxo, depósitos de dados e terminadores Processos Os processos são o primeiro componente do diagrama. Eles mostram como os dados das entradas são transformados em saídas. Conforme apresenta a Figura 6, o nome da função é a descrição do processo no verbo infinitivo. São representados graficamente por um círculo. FIGURA 6 - Representação de um Processo

25 Fluxo A simbologia de fluxo é utilizada para demonstrar o movimento de informações de uma parte a outra do sistema. A Figura 7 exemplifica um fluxo, ele é representado por uma seta, saindo ou entrando de um processo. FIGURA 7 - Representação de um Fluxo Depósito de Dados Ao contrário do fluxo que representa a movimentação de informações, o depósito de dados representa informações estáticas. Ele é utilizado para modelar essas informações que estão em repouso. O depósito de dados é representado por duas linhas paralelas e sua nomenclatura é o plural dos pacotes transportados pelo fluxo, como indica a Figura 8. FIGURA 8 - Representação de um Depósito de Dados Terminadores Os terminadores são utilizados para representar entidades externas que se comunicam com o sistema. Na maioria das vezes os terminadores são pessoas ou grupos que estejam ligados ao sistema, mas fora de seu funcionamento. Em alguns casos eles também podem caracterizar outro sistema. A Figura 9 apresenta um exemplo terminador que é representado através de um retângulo.

26 FIGURA 9 - Representação de um Terminador 26

27 27 3 METODOLOGIA Para continuar o trabalho iniciado no ano de 2011 foram seguidos alguns métodos e processos que serão discriminados ao longo da metodologia. 3.1 ANÁLISE DE REQUISITOS Anteriormente ao desenvolvimento do projeto foram realizadas entrevistas com os usuários do sistema, contribuindo com o levantamento de requisitos. Os principais requisitos são: Solicitação de Serviço e Materiais o Validação dos campos o Envio automático de quando uma solicitação for inserida. o Exibição do status da solicitação. o Inserir não conformidade quando houver algum problema na solicitação o Busca de solicitação por número da ordem e por código. IDM s (Índices de Manutenção) o Inserir novos índices, conforme padrão da empresa o Exibir os índices por área Planejamento Kanban o Acompanhamento visual das atividades planejadas o Realizar integração com o planejamento feito no SAP 3.2 MODELO ENTIDADE RELACIONAMENTO - MER Foi utilizado o modelo entidade relacionamento para realizar a modelagem do banco de dados e garantir uma gestão de informações mais prática e segura. Para garantir uma melhor visualização o modelo foi dividido por funcionalidade e será analisado separadamente.

28 28 Solicitação de Serviço e Materiais A Figura 10 apresenta o MER do processo de solicitação. Há a participação de duas entidades, relacionadas entre si. Uma solicitação pode ter vários itens e um determinado item participa apenas de uma solicitação, caracterizando uma relação 1:N. FIGURA 10 MER - Solicitação de Serviço e Materiais IDM s Como é possível observar na figura 11, existe uma entidade chamada IDM que contém os dados relacionados aos Índices de Manutenção. Ela está ligada na entidade Dados através de uma ligação 1:N, demonstrando que um elemento dessa entidade só pode estar relacionado a um elemento da entidade Dados. FIGURA 11 MER - IDM s

29 29 Planejamento Kanban O MER do planejamento Kanban é exemplificado pela Figura 12. É possível observar que as entidades Semana e Kanban conversam entre si através de uma ligação 1:1. Isso representa que em cada semana deve haver um único planejamento Kanban, da mesma forma que um planejamento deve pertencer a apenas uma semana. Existem outras três entidades muito importantes no processo: Manutentor, Função e Local de Instalação. A entidade Manutentor, que possui os dados de cada funcionário, está ligada com a entidade Função em uma relação 1:N. A relação indica que cada manutentor deve possuir apenas uma função, enquanto que cada função pode pertencer a mais de um manutentor. A entidade Local de Instalação contém as descrições dos locais da empresa, indicando em qual deles o serviço será realizado. FIGURA 12 MER Planejamento Kanban

30 MODELO RELACIONAL - MR Através dos diagramas do modelo relacional é possível observar as tabelas e relações entre elas, trazendo uma visualização mais próxima de como realmente vai funcionar a estrutura de banco de dados. Nos diagramas MR serão apresentados os diagramas da estrutura do banco que rodam atualmente na empresa e os remodelados, apresentando suas melhorias. Os diagramas da estrutura atual do banco foram obtidos através do processo de Engenharia reversa. Solicitação de Serviço e Materiais No modelo antigo, como mostra a figura 13, existem duas tabelas relacionadas à solicitação de serviço e materiais: Solicitação de Compra e Itens de Compra. Porém as tabelas não se relacionam entre si e possuem alguns atributos iguais. Além disso, a tabela Itens de Compra não possui chave primária, o que possibilita que registros iguais sejam inseridos e gera inconsistência de dados. FIGURA 13 - Antigo MR - Solicitação de Serviços e Materiais

31 31 Na remodelagem, além de definir uma chave primária na tabela Itens de Compra, as duas tabelas foram interligadas, relacionando as informações e garantindo uma melhor organização, como mostra a figura 14. As necessidades de acompanhamento de status e não conformidades também foram previstas no novo modelo com a inserção de novos campos na tabela Solicitação de Compra. FIGURA 14 Novo MR - Solicitação de Serviços e Materiais IDM s A Figura 15 exemplifica o antigo modelo do sistema de IDM s. É possível observar que existem quatro tabelas que não possuem relação entre si e nem chaves primárias. As tabelas de ordens pendentes e encerradas são alimentadas de forma manual e através de procedures os índices de manutenção são gerados e inseridos na tabela de índices. A tabela de metas possui a finalidade de definir a meta de cada índice. Os problemas relacionados a esse modelo de banco começaram a surgir quando uma pessoa sem conhecimento de banco de dados assumiu a responsabilidade pela gestão dos índices. Como a inserção de dados era manual, o sistema acabou sendo abandonado.

32 32 FIGURA 15 - Antigo MR - IDM's Surgiu então a necessidade de uma nova modelagem que permitisse que uma pessoa sem amplos conhecimentos em informática conseguisse realizar a gestão dos índices. No novo modelo o número de tabelas foi reduzido, tornando-o mais simples e prático. Ele foi desenvolvido de acordo com a necessidade de empresa de estratificar os índices. A tabela contendo a descrição do índice é interligada com a tabela que contem os dados, como mostra a figura 16, garantindo informações precisas. FIGURA 16 Novo MR IDM s

33 33 Planejamento Kanban Em relação ao Planejamento Kanban, que é uma funcionalidade nova, foram modeladas tabelas para que o sistema de gestão fosse construído da melhor forma e que facilitassem a integração com o planejamento no sistema SAP, de acordo com a figura 17. Para atender as necessidades foram criadas uma tabela para cadastrar os manutentores e outra para os locais da empresa, permitindo indicar, por exemplo, quem é responsável por um serviço pendente e aonde aquele serviço deveria ter sido executado. As tabelas foram modelas buscando fornecer ao usuário o máximo de informações possíveis, facilitando a gestão. FIGURA 17 MR Planejamento Kanban 3.3 DIAGRAMA DE FLUXO DE DADOS DFD No desenvolvimento do sistema a metodologia escolhida foi a análise estruturada. Com base nisso foi utilizado o Diagrama de Fluxo de Dados para a representação do sistema, abrangendo o nível 0, o nível 1 e o nível 2 do DFD.

34 34 Nível 0 O nível 0 do DFD é o nível mais simples, como mostra a Figura 18. Nele apenas são representadas as entidades externas que interagem com o sistema e como elas fazem isso. FIGURA 18 DF Nível 0 Nível 1 A figura 19 representa o DFD de nível 1. Nesse nível o detalhamento do sistema é maior e é possível observar a relação e as funcionalidades e os terminadores. FIGURA 19 DFD Nível 1

35 35 Nível 2 O nível 2 é o mais detalhado de todos os níveis. Para proporcionar uma melhor visualização, o modelo foi dividido em partes. o Solicitação de Serviços e Materiais O DFD de Solicitação de Serviços e Materiais possuiu apenas um terminador: o usuário, de acordo com a figura 20. Ele alimenta as informações que serão armazenadas no depósito de dados chamado solicitações. As funcionalidades são descritas dentro dos círculos: Manter Solicitação e Busca. FIGURA 20 DF Nível 2 Solicitação de Serviços e Materiais o IDM s O módulo de IDM s é exclusivo para inserção e exibição de relatórios de índices, conforme demonstra a figura 21. As informações são geradas com o auxílio de um dos terminadores, o SAP, e migram para o depósito de dados. Outra função do módulo é a busca desses índices que é feita com a ajuda do terminador usuário.

36 36 FIGURA 21 DF Nível 2 IDM s o Planejamento Kanban O DFD do Planejamento Kanban possuiu dois terminadores: o usuário e o sistema SAP. As informações necessárias para o gerenciamento são importadas do terminador SAP através do Upload de relatórios. Essas informações são armazenadas no depósito de dados, podendo ser acessadas pela funcionalidade de busca através do terminador usuário, conforme mostrado na figura 22. FIGURA 22 DFD Nível 2 Planejamento Kanban

37 37 4 RESULTADOS 4.1 INDEX A figura 23 apresenta a página Index do sistema. O menu foi adequado a funções que realmente fossem necessárias e tornou-se mais simples e prático. FIGURA 23 Tela Index 4.2 SOLICITAÇÃO DE SERVIÇOS E MATERIAIS Consulta de Solicitações A tela de consulta de solicitações foi remodelada, como mostra a figura 24, oferecendo ao usuário uma forma mais simples e completa para a pesquisa de dados. Além disso, novos filtros foram acrescentados para suprir as necessidades expostas pelos usuários nos questionários de requisitos.

38 38 FIGURA 24 Tela de Consulta de Solicitações Itens da Solicitação De acordo com a necessidade de controle de custos da empresa, foram adicionados campos no relatório que possibilitassem a visualização do custo da solicitação antes que a mesma fosse atendida, como exemplifica a figura 25, proporcionando análise de viabilidade. FIGURA 25 Tela de Itens da Solicitação

39 Relatório de Solicitações Foi disponibilizada ao usuário a possibilidade de gerar um relatório de solicitações escolhendo os campos adequados a sua necessidade, como mostra a figura 26. Além disso, o relatório pode ser exportado para Excel, facilitando a gestão de informações. FIGURA 26 Tela do Relatório de Solicitações 4.3 IDM s Cadastro de Índices A tela de Cadastro de Índices, apresentada na figura 27, foi desenvolvida com a finalidade de construir um sistema de níveis para exibição dos índices e melhor estratificação. Além disso, essa nova tela possibilita ao usuário cadastrar todos novos índices necessários para o controle da empresa, sanando uma necessidade inicial.

40 40 FIGURA 27 Tela de Cadastro de Índices Consulta de Índices A nova tela de consulta de índices, demonstrada na figura 28, foi criada buscando possibilitar ao usuário a melhor visualização possível dos dados. Através do sistema de níveis é possível desdobrar os resultados da maneira que for necessária, facilitando a análise dos índices.

41 41 FIGURA 28 Tela de Consulta dos Índices A tela também conta com o recurso de gráficos, conforme a figura 29, tornando a exibição de dados mais simples e direta. FIGURA 29 Tela de Exibição de Gráfico

42 PLANEJAMENTO KANBAN Cadastro de Manutentores Para garantir um melhor acompanhamento da execução de serviços, é preciso saber quem são as pessoas responsáveis por eles. Para suprir essa necessidade foi preciso criar uma tela de cadastro dos funcionários, exemplificada na figura Consulta do Planejamento FIGURA 30 Tela de Cadastro de Manutentores A consulta do planejamento Kanban, demonstrada na figura 31, é totalmente interligada com o planejamento feito no sistema SAP. O quadro visual é montado com base na importação de um relatório em Excel, garantindo a integridade dos dados. FIGURA 31 Tela de Consulta do Planejamento

43 43 5 CONCLUSÃO Ao término desse trabalho, observa-se que os objetivos traçados no início dessa jornada foram atingidos como planejado, fornecendo à empresa uma melhor gestão de seus processos. Ao longo do desenvolvimento do projeto algumas dificuldades foram encontradas como a utilização de conceitos e linguagens então desconhecidos e a falta de conhecimento em relação aos processos da empresa. Mas a principal dificuldade encontrada foi a interpretação e análise do sistema, consequência da falta de diagramação do mesmo. Foi possível vivenciar a importância do planejamento e da documentação para a manutenção futura de um projeto. Métodos muito importantes como a engenharia reversa propiciaram conhecer a fundo o sistema, possibilitando que as necessidades apresentadas pelos usuários fossem resolvidas. Os principais processos foram aprimorados, garantindo satisfação e praticidade. Agora, a Solicitação de Serviços e Materiais tornou-se mais completa, podendo ser consultada com filtros que atendem a demanda dos usuários. De acordo com a necessidade de controle de custos da empresa, foram adicionados campos no relatório que possibilitassem a visualização do custo da solicitação antes que a mesma fosse atendida. Os Índices de Manutenção podem ser acompanhados semanalmente através de faróis e gráficos, facilitando a visualização. Além disso, uma nova funcionalidade foi implementada, o Planejamento Kanban, garantindo uma melhor gestão visual das ordens de serviço de manutenção. As melhorias proporcionadas por esse trabalho serviram para facilitar a rotina dos usuários, enriquecendo-a com uma grande quantidade de informações organizada de forma simples e prática.

44 44 REFERÊNCIAS ALVES, W. Fundamentos de Bancos de Dados. Érica, BOEHM, B. Spiral Development: experience, principles and refinements. Spiral Development Workshop, Disponível em < Acesso em: 01 jun CAMPOS, L. HTML rápido e prático. Terra, CARVALHO, A. M. B. R.; CHIOSSI, T. C. S. Introdução à engenharia de software. Campinas: Unicamp, ELSMARI, R.; NAVATHE, S. Sistemas de Banco de Dados. 6. ed. São Paulo: Pearson, FERREIRA Jr., Setembrino Soares. Apostila de Treinamento em Análise Estruturada. Incepa S/A., GANE Chris; SARSON, Trish. Análise Estruturada de Sistemas. Rio de Janeiro: LTC, MAFFEO, Bruno. Engenharia de Software e Especificação de Sistemas. Rio de Janeiro: Campus, PRESSMAN, R. Engenharia de Software. 6. ed. São Paulo: Makron, REZENDE, D. Engenharia de Software e Sistemas de Informações. Rio de Janeiro: Brasport, YNEMINE, S. Conhecendo o Javascript. 1. ed. Visual Books, YOURDON, E. Análise Estruturada Moderna. Rio de Janeiro: Campus, 1992.