Tcc sistema controle-equipamento

1.847 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
1.847
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
94
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Tcc sistema controle-equipamento

  1. 1. FACULDADES NETWORK ZÓZIMO RODRIGUES DE SOUZA JUNIOR PROPOSTA DE SOFTWARE PARA CONTROLE DE EQUIPAMENTOS NOVA ODESSA 2007
  2. 2. ZÓZIMO RODRIGUES DE SOUZA JUNIOR PROPOSTA DE SOFTWARE PARA CONTROLE DE EQUIPAMENTOS Monografia apresentada às Faculdades Network como um dos pré-requisitos para a obtenção do grau de Bacharel em Sistemas de Informação. Orientador: Prof. Me. Flávio de Freitas Stecca NOVA ODESSA 2007
  3. 3. ZÓZIMO RODRIGUES DE SOUZA JUNIOR PROPOSTA DE SOFTWARE PARA CONTROLE DE EQUIPAMENTOS Monografia apresentada às Faculdades Network como um dos pré-requisitos para a obtenção do grau de Bacharel em Sistemas de Informação. Aprovada em: ______ / ______/ ______ BANCA EXAMINADORA Prof. Me. Flávio de Freitas Stecca Faculdades Network Prof. Tarcízio Antonio Fernandes Faculdades Network
  4. 4. I Dedico este trabalho aos meus pais, Zózimo e Onelia, e para minha noiva Susana por se constituírem diferentemente enquanto pessoas, proporcionando estímulos que me impulsionaram a buscar vida nova a cada dia; meus agradecimentos por terem aceito se privar de minha companhia pelos estudos, concedendo a mim a oportunidade de me realizar ainda mais.
  5. 5. II AGRADECIMENTOS Primeiramente aos meus pais, que me proporcionaram total infra-estrutura e apoio para que pudesse conquistar este título. Às nossas famílias, pela paciência em tolerar a nossa ausência. A todos os professores e seus convidados, pelo carinho, dedicação e entusiasmo demonstrados ao longo do curso. Especialmente à minha noiva Susana, pela paciência nos momentos perturbados e pela sua companhia em todo caminho percorrido. E, finalmente, a DEUS pela oportunidade e pelo privilégio que nos foram dados em compartilhar tamanha experiência e, ao freqüentar este curso, perceber e atentar para a relevância de temas que não faziam parte, em profundidade, das nossas vidas.
  6. 6. III “A ciência é uma mescla de dúvida e certeza. O bom cientista é arrogantemente humilde, o que não se reduz a um mero jogo de palavras: arrogante em relação ao método e humilde quanto à fé no seu conhecimento” Bachrach
  7. 7. IV RESUMO Este trabalho visa analisar um processo burocratizado realizado 100% manualmente em planilhas eletrônicas e propor uma solução em sistema que satisfaça suas necessidades principais, minimizando o tempo gasto, fornecendo confiabilidade na informação prestada e para o aumento da qualidade do serviço prestado, em que, em primeira instância, é a raiz do Suporte de TI. A pesquisa realizada apresenta informações sobre as ferramentas a serem utilizadas, metodologias a serem seguidas para se obter um produto de Software com qualidade, proporcionando, assim, para os usuários do serviço, um melhor atendimento às comunidades usuais do serviço. Palavras-chaves: Engenharia de Software; Desenvolvimento de Sistema.
  8. 8. V LISTAS LISTAS DE FIGURAS 1 Modelo Espiral ...............................................................................................................9 2 Modelo Cascata ..............................................................................................................10 3 Processo de Engenharia na Visão do RUP.....................................................................11 4 Principio de Funcionamento de Paginas em PHP ..........................................................14 5 PHP Editor......................................................................................................................15 6 Browser Internet Explorer ..............................................................................................16 7 Exemplo do Código HTML............................................................................................16 8 Estrutura de um Portal (Site) ..........................................................................................17 9 Planilha de Controle de Equipamentos na Manutenção .................................................22 10 Planilha de Controle de Equipamentos de Backups.......................................................23 11 Planilha de Inventário.....................................................................................................24 12 Diagrama de Entidade e Relacionamento.......................................................................26 13 Diagrama de Contexto....................................................................................................33 14 Representação dos símbolos a utilizar no desenho de um DFD.....................................35 15 DFD Nível 0 Sistema......................................................................................................36 16 DFD Nível 1 Sistema......................................................................................................37 17 DFD Nível 2 Usuários....................................................................................................38 18 DFD Nível 2 Setores ......................................................................................................39 19 DFD Nível 2 Equipamentos ...........................................................................................40 20 DFD Nível 2 Fornecedores.............................................................................................41 21 DFD Nível 2 Relatórios..................................................................................................42 22 DFD Nível 2 Solicitação Saída.......................................................................................43 23 DFD Nível 2 Contato Fornecedor ..................................................................................44 24 DFD Nível 2 Controlar Serviços ....................................................................................45 25 Protótipo Menu Admin...................................................................................................46 26 Protótipo Menu Contato Fornecedor..............................................................................47 27 Protótipo Menu Saída Equipamentos .............................................................................48 28 Protótipo Menu Orçamento ............................................................................................49 29 Protótipo Menu Finaliza Serviço....................................................................................50
  9. 9. VI LISTAS DE TABELAS 1 Dicionário das Tabelas ...................................................................................................28 2 Dicionário dos campos da tabela usuário .......................................................................28 3 Dicionário dos campos da tabela perfil ..........................................................................29 4 Dicionário dos campos da tabela setor ...........................................................................29 5 Dicionário dos campos da tabela tipo equipamento.......................................................29 6 Dicionário dos campos da tabela tipo atributo ...............................................................29 7 Dicionário dos campos da tabela atributo tipo equipamento..........................................29 8 Dicionário dos campos da tabela status do equipamento ...............................................29 9 Dicionário dos campos da tabela contato fornecedor.....................................................30 10 Dicionário dos campos da tabela equipamentos.............................................................30 11 Dicionário dos campos da tabela fornecedor..................................................................30 12 Dicionário dos campos da tabela histórico status...........................................................30 13 Dicionário dos campos da tabela marca equipamentos..................................................31 14 Dicionário dos campos da tabela modelo equipamento .................................................31 15 Dicionário dos campos da tabela orçamento ..................................................................31 16 Dicionário dos campos da tabela solicitação serviço .....................................................31 17 Dicionário dos campos da tabela solicitação saída.........................................................32 18 Dicionário dos campos da tabela valor atributo .............................................................32
  10. 10. VII SUMÁRIO 1. Introdução........................................................................................................................ 1 1.1 Materiais e Métodos .................................................................................................. 2 2. Desenvolvimento de Software......................................................................................... 3 2.1 Processos de Desenvolvimento de Software ............................................................. 7 2.1.1 Modelo em Espiral............................................................................................ 7 2.1.2 Modelo Cascata ................................................................................................ 9 2.1.3 Modelo Rational Unified Process (RUP) .........................................................11 2.2 Linguagem de Programação.....................................................................................12 2.2.1 PHP..................................................................................................................13 2.2.2 HTML..............................................................................................................15 2.3 Banco de Dados........................................................................................................17 2.3.1 Banco de Dados Relacional.............................................................................18 2.3.2 O Banco de Dados MySQL.............................................................................19 2.3.3 O Banco de Dados PostgreSQL.......................................................................20 3. Ambiente Estudado .........................................................................................................22 4. Modelagem de Dados......................................................................................................25 4.1 Diagrama entidade e relacionamento .......................................................................26 4.2 Dicionário de dados..................................................................................................27 4.3 Diagrama de Contexto (DC).....................................................................................32 4.4 DFD ..........................................................................................................................34 4.5 DFD Nível 0 SISTEMA ...........................................................................................36 4.6 DFD Nível 1 SISTEMA ...........................................................................................37 4.7 DFD Nível 2 - USUÁRIOS......................................................................................38 4.8 DFD Nível 2 – SETORES........................................................................................39 4.9 DFD Nível 2 - EQUIPAMENTOS...........................................................................40 4.10 DFD Nível 2 - FORNECEDORES.........................................................................41 4.11 DFD Nível 2 - RELATÓRIOS...............................................................................42 4.12 DFD Nível 2 – SOLICITAÇÃO SAÍDA ................................................................43 4.13 DFD Nível 2 – CONTATO FORNECEDOR .........................................................44 4.14 DFD Nível 2 – CONTROLAR SERVIÇO..............................................................45 5. Desenvolvimento do Protótipo .......................................................................................46 6. Considerações Finais.......................................................................................................51 Referências Bibliográficas...................................................................................................52
  11. 11. 1 1 – INTRODUÇÃO Atualmente, na empresa estudada, são preenchido, manualmente, planilhas, para controle de equipamentos na Manutenção, inventário em que existem diversos problemas no processo atual, de forma que dados são inseridos manualmente sem nenhuma padronização, contribuindo, assim, para uma maior dificuldade nas consultas, grande consumo de tempo na digitação de dados já inseridos e na verificação dos mesmos. Essas consultas nem sempre correspondem realmente à realidade, devendo ser avaliado se realmente se pode confiar na informação fornecida. Todo o orçamento da empresa externa é também preenchido nesta planilha, para que possa realizar um controle de custos de manutenção já realizados e a quantidade em que já foi consertada, para que possa saber se e viável ou não ser realizado a manutenção. Os pedidos de consertos só são aprovados mediante o levantamento desses dados, consultas diárias para consolidação dos equipamentos em poder de terceiros, atualização de status atuais, e são realizado análises de cada equipamento para aprovação. O local cujo estudo foi realizado, tem o agravante da necessidade de não faltar equipamentos para troca, pois se trata de um Hospital, onde um segundo vale uma vida, sendo assim, não podendo ficar sem reposição e quanto maior a demora na realização desses processos, maior será o tempo de retorno, gerando custos elevados na manutenção e gradativamente gerando também um aumento no investimento, para manter equipamentos suficientes para dar conta da demanda. Realizamos o levantamento dos processos e foi proposto um Sistema para aumentar a qualidade da informação tratada, agilizando o máximo do processo desenvolvido atualmente.
  12. 12. 2 1.1 - MATERIAIS E MÉTODOS Inicialmente, foi utilizado o método de levantamento de requisitos do software com os profissionais que utilizam o processo servindo como base para o desenvolvimento do mesmo. Após uma primeira interação com os processos, foram realizadas reuniões com o gerente do setor e entrevistas com os usuários para levantar todos os requisitos do Sistema. Foi adotado, para o desenvolvimento do protótipo inicial, modelagem da base de mais atividades, a partir da metodologia de Desenvolvimento em Espiral, pois, no desenvolvimento, é importante que fossem detectados possíveis problemas logo no início, devido à grande possibilidade de mudança no projeto original. Uma vez definida a metodologia de desenvolvimento, realizamos uma pesquisa para a escolha da linguagem de banco de dados e a linguagem de programação mais viável para o projeto. Devido a questões como custo e fácil portabilidade com bom desempenho, ficou decidido que a linguagem que atendia melhor esses parâmetros seria o PHP, acompanhado do banco de dados MySQL, devido ao fato de ser um banco de dados livre, confiável e da aplicação não ter grande complexidade nas transações, utilizado para a interface com o usuário, a Linguagem HTML gerada por uma ferramenta de desenvolvimento de páginas gratuito. Após a aceitação do projeto, está sendo realizado o procedimento de codificação dos processos básicos, em que estaremos disponibilizando versões para teste e levantamentos de possíveis problemas ou melhorias.
  13. 13. 3 2 - DESENVOLVIMENTO DE SOFTWARE Para o desenvolvimento de software e o processo de criação e implantação de uma determinada necessidade, tem que haver um maior domínio tanto da engenharia quanto do marketing, para resultar em um software. Como afirma Pressman (2005), o Software já superou o Hardware como chave para o sucesso de muitos sistemas. Um software é desenvolvido para ajudar em questões como: - Gestão de uma Empresa (Funcionários, Vendas, Compras, Estoque etc.); - Criação de um editor de textos; - Controle de tráfego aéreo; - Gestão de reservas para um Restaurante; Arquitetar um pequeno programa é fácil, mas, para grandes Sistemas, podemos ter várias dificuldades, como o fato de: - Serem desenvolvidos por muitas pessoas (dezenas ou mais); - Pessoas entrarem e saírem do projeto; - O sistema ser grande demais para ser entendido por uma só pessoa; Todos estes fatores podem resultar em problemas de comunicação entre os participantes do projeto, riscos no planejamento e diversos outro fatores, que podem levar a um produto de Software que não atende seus requisitos. Para desenvolver esse software, é necessário seguir respeitáveis métodos de trabalho, que são projetados por pessoas com muita experiência e que permitem evitar erros que poderiam atrasar o projeto ou mesmo fracassar. Esses métodos são compostos de várias fases, que são tipicamente:
  14. 14. 4 - Análise de requisito: Qual é o problema a ser resolvido? - Análise: Início da definição de informática, mas sem pensar numa implementação; precisa-se definir qual linguagem será usada, o banco de dados etc.. - Projeto: Análise e descrição detalhada da futura implementação. - Implementação: Desenvolvimento do projeto. - Teste: Testar se o sistema implementado faz o que era preciso, sendo definido inicialmente sem erros. As primeiras fases são as mais importantes e as mais difíceis. Um erro nessas etapas pode ter conseqüências muito graves. Conforme citado, as fases não são tão bem separadas. Na realidade, torna-se difícil de marcar exatamente o limite entre qualquer das etapas acima. O processo de desenvolvimento também não é tão simples, precisa-se sempre de retornos para corrigir alguns erros. O importante é descobrí-los o mais rápido possível para não perder tempo demais refazendo as coisas erradas, pois, como nos alerta Pressman (2005), a importância do Software é o mecanismo que nos possibilita aproveitar e dar vazão a esse potencial. O que caracteriza um Software, segundo Pressman, é o fato deste poder ser construído de diferentes formas, adequado ao que o ser humano constrói. O Software, porém, não é sensível a problemas ambientais, que fazem com que o Hardware se desgaste, e a maioria dos Softwares são feitos sob medida à sua realidade.
  15. 15. 5 A análise de requisitos e o processo inicial para o desenvolvimento do software, são importantes para que se possam definir quais são as necessidades e expectativas do cliente, auxiliando os desenvolvedores. Análise de Requisitos de software, segundo Pressman (2005), é a primeira fase e a mais importante para o Desenvolvimento do Software. Uma má análise de requisitos acarretará problemas futuros, gerando um estado irreal à necessidade do usuário. Para que esta seja feita, existe um usuário responsável em transmitir necessidades, muitas vezes confusas para um consultor responsável em interpretar e propor uma solução para os problemas. Nesse trâmite, existem diversos problemas, como interpretações errôneas, informações falsas e ambigüidade. Por isso que se deve manter uma estrutura confiável, para que os desenvolvedores não percam tempo no desenvolvimento. Para que se tenha um domínio da informação extraída, é necessário que se encerre com três pontos de vistas diferentes sobre os dados e quando são processados, sendo eles: - Fluxo da Informação : Representada pela maneira com que os dados se movimentam e modificam-se com relação ao software. - Conteúdo da Informação: Representa os dados e os atributos de controle individual que compreendem certos atributos de uma informação mais ampla. - Estrutura da Informação: Representa a estrutura interna a vários itens de controle e de dados.
  16. 16. 6 Preesmam, Balzer e Goldman propõem oito princípios de uma boa especificação, que são: - Separando funcionalidade de implementação: Descrição daquilo que é desejado e não do tem que ser realizado. - Uma linguagem de especificação de sistemas orientada ao processo é exibida: Situações que afetem dinamicamente as mudanças de comportamento de certas entidades que interagem com esse ambiente. - A especificação deve abranger o sistema do qual o software é um componente: Um sistema é composto de componentes que interagem somente dentro de seu contexto. - Uma especificação deve abranger o ambiente no qual o sistema opera: Requer o conhecimento de que o ambiente é, em si mesmo, composto por diversos objetos interagentes. - Uma especificação de sistema deve ser um modelo cognitivo: Deve narrar um sistema da forma como ele é percebido pelos usuários. - Uma especificação deve ser operacional: Deve ser completa e formal bastante para que se possa ser usada em uma implantação proposta para satisfazer uma situação de teste prepotente aos escolhidos. - A especificação do sistema deve ser tolerante com a não inteireza a ser expansível: Uma especificação é sempre um modelo abstrato de alguma situação real ou imaginária, não podendo, assim, ser incompleta, pois pode ser excessivamente complexa. - Uma especificação deve ser localizada e fracamente acoplada: Todos os processos anteriores lidam com a especificação como se ela fosse estática, mas existem muitas mudanças obrigando a sua estrutura a apropriar-se dessas atividades.
  17. 17. 7 Após todo o levantamento de requisitos, entraremos na fase de análise da Informática para sistematização, conforme citado na parte de estruturação de desenvolvimento de software. Sabendo que o Hospital é publico e tem, como deficiências, pouca verba, optaram por ferramentas livres para poder diminuir os custos de desenvolvimento. 2.1 - PROCESSOS DE DESENVOLVIMENTO DE SOFTWARES A utilização de um processo de software tem sido apontada como um fator primordial para o sucesso de empresas de desenvolvimento de software. Para poder melhor compreender o assunto, é necessário definir o que é um processo de software. Um processo de software pode ser entendido como um conjunto estruturado de atividades exigidas para desenvolver um sistema de software. 2.1.1 - MODELO EM ESPIRAL O modelo em espiral é um processo de desenvolvimento de software que combina elementos de projeto prototipação em etapas conforme Figura 01. Para uma típica aplicação, o modelo em espiral deverá significar que se tem uma visão grosseira dos elementos como uma aplicação utilizável, adicionando características nas fases e a determinado ponto.
  18. 18. 8 O modelo espiral é usado com mais freqüência em grandes projetos. Para os pequenos, os conceitos de desenvolvimento de software ágil torna-se uma alternativa mais viável e suas vantagens são: • As Estimativas tornam-se mais realísticas com o progresso do trabalho, porque problemas importantes são descobertos mais cedo no desenvolvimento. • É mais versátil para lidar com mudanças no desenvolvimento de software geralmente exigidas. • Engenheiros de software podem começar o trabalho no sistema mais cedo. Desvantagens: • Pode ser difícil convencer grandes clientes (particularmente em situações de contrato) de que a abordagem evolutiva é controlável. • A abordagem deste tipo de modelo exige considerável experiência na avaliação dos riscos e fia-se nessa experiência para o sucesso. Se um grande risco não for descoberto, poderão ocorrer problemas. • Este tipo de modelo é relativamente novo e não tem sido amplamente usado. • É importante ter em conta que podem existir diferenças entre o protótipo e o sistema final. O protótipo pode não cumprir os requisitos de desempenho, pode ser incompleto, e pode refletir somente algumas facetas do sistema a desenvolver. • O modelo em espiral pode levar ao desenvolvimento em paralelo de múltiplas partes do projeto, cada uma sendo abordada de modo diferenciado, por isso é necessário o uso de técnicas específicas para estimar e sincronizar cronogramas, bem como para determinar os indicadores de custo e progresso mais adequados.
  19. 19. 9 Figura 01 – Modelo Espiral Fonte: www.devmedia.com.br/.../viewcomp.asp?comp=3853 2.1.2 - MODELO CASCATA Modelo em Cascata tem como principal característica a seqüência de atividades, na qual cada fase transcorre completamente e seus produtos são vistos como entrada para uma nova fase conforme Figura 02. A saída da primeira etapa desliza para a segunda, e a saída da segunda etapa desliza para a terceira, e assim por diante. As atividades a executar são agrupadas em tarefas, executadas seqüencialmente, de forma que uma tarefa só poderá ter início quando a anterior tiver terminado. Uma das vantagens do modelo é que só se avança para a tarefa seguinte quando o cliente valida e aceita os produtos finais da tarefa atual. O modelo pressupõe que o cliente participa ativamente no projeto e que sabe muito bem o que quer.
  20. 20. 10 As principais desvantagens deste modelo são: - Dificuldade em acomodar mudanças depois que o processo está para ser executado; - Partição inflexível do projeto em estágios distintos; - Dificuldade em responder a mudanças dos requisitos; - É mais apropriado quando os requisitos são bem compreendidos; - Os projetos reais raramente se adaptam ao modelo linear e seqüencial; - É difícil capturar os requisitos de uma só vez; - O cliente tem de pacientemente esperar o resultado final; - Os programadores são frequentemente atrasados sem necessidade; - Alto custo de correção das especificações quando nas fases de Teste e Implantação; Figura 02 – Modelo em Cascata Fonte: http://pt.wikipedia.org/wiki/Modelo_em_cascata
  21. 21. 11 2.1.3 - RATIONAL UNIFIED PROCESS (RUP) O RUP é um processo de engenharia de software bem definido e bem estruturado, que define claramente quem é responsável pelo que, como as coisas devem ser feitas e quando fazê-las conforme figura 03. Este também provê uma estrutura bem definida para o ciclo de vida de um projeto RUP, articulando claramente os marcos essenciais e pontos de decisão. Não existe uma maneira exata de aplicar o RUP, pois ele pode ser aplicado de várias formas e será diferente em cada projeto e organização. Porém existem alguns princípios que podem caracterizar e diferenciar o RUP de outros métodos iterativos: - Atacar os riscos cedo e continuamente; - Certificar-se de entregar algo de valor ao cliente; - Focar no software executável; - Acomodar mudanças cedo; - Liberar um executável da arquitetura cedo; - Construir o sistema com componentes; - Trabalhar junto como um time; e - Fazer da qualidade um estilo de vida, não algo para depois. Figura 03 - Processo de Engenharia na visão do RUP Fonte : http://www.dei.unicap.br/~sergio/es/aulas/09-IntroducaoRUP.pdf
  22. 22. 12 2.2 - LINGUAGEM DE PROGRAMAÇÃO Uma linguagem de programação é um método padronizado para expressar um conjunto de instruções para um computador executar para uma determinado fim. Uma linguagem permite que um programador especifique precisamente sobre quais dados um computador vai atuar, como estes serão armazenados ou transmitidos e quais ações devem ser tomadas sob várias circunstâncias. O conjunto de palavras, composto de acordo com essas regras, constitui o código fonte de um software, que depois é traduzido para código de máquina, que é, por sua vez, executado pelo processador. Uma das principais metas das linguagens de programação é permitir que programadores tenham uma maior produtividade, permitindo expressar suas intenções mais facilmente do que quando comparado com a linguagem que um computador entende nativamente por código de máquina. Assim, linguagens de programação são projetadas para adotar uma sintaxe de nível mais alto, que pode ser mais facilmente entendida por programadores humanos. Linguagens de programação são ferramentas importantes para que programadores e engenheiros de software possam escrever programas mais organizados e com maior rapidez. Linguagens de programação também tornam os programas menos dependentes de computadores ou ambientes computacionais específicos, com uma propriedade chamada de portabilidade. Isto acontece porque programas escritos em linguagens de programação são traduzidos para o código de máquina do computador no qual será executado em vez de ser diretamente executado.
  23. 23. 13 2.2.1 PHP A linguagem assim escolhida para ser utilizada na implementação será o PHP (Personal Home Page), que é o módulo mais popular para os servidores Apache. Os especialistas reconhecem, em diversas publicações, que existem quatro excelentes qualidades: 1 – Velocidade; 2 – Estabilidade; 3 – Segurança; 4 – Simplicidade; Segundo Pushman, quando falamos de velocidade, não só falamos na rapidez na execução, como também na virtude de que isto não dificulta a funcionalidade da máquina. PHP integra-se bem com outro tipo de software, especialmente com Unix. De nada serve que um sistema seja rápido se não é estável. Aqui é quando aparece a segunda das virtudes deste sistema. O PHP utiliza seu próprio esquema de utilização de recursos e conta ainda com um método sofisticado para administrar variáveis. O PHP provê vários níveis de segurança que podem ser ajustados segundo as exigências do usuário. Os programadores de HTML podem integrar PHP em suas páginas sem maiores inconvenientes. Aqueles que já têm experiência ou uma certa familiaridade com a linguagem C ou inclusive JavaScript poderão rapidamente adaptar-se ao sistema. E aqui se salienta a qualidade de simplicidade. Outras vantagens do PHP: - Adapta-se a quase todas as plataformas. Utilizando a mesma base de código, PHP pode ser compilado e construído em 25 plataformas, inclusive UNIX, Windows (95/98/NT/2000) e Macs.
  24. 24. 14 - É extensível. A programação de PHP conta com uma raiz que admite extensões de código. Isto oferece aos programadores duas maneiras de estender o PHP para realizar processos especiais, seja escrevendo módulos de extensão e compilando os dentro do executável seja criando um executável que possa ser carregado, utilizando mecanismo de carga dinâmica do PHP. - PHP pode trabalhar com múltiplas interfaces: MySQL, MS SQL, Oracle, Informix, PostgreSQL e outras. - E uma das mais importantes é que o PHP é um software livre sob licença GPL. Conforme apresentado na figura 04 será explicado o princípio de funcionamento das páginas desenvolvidas em php. Figura 04 – Princípio de Funcionamento de Paginas em PHP. Fonte: http://www.desarrolloweb.com/articulos/392.php
  25. 25. 15 Como toda linguagem existem editores para facilitar seu desenvolvimento o PHP não é diferente na Figura 05 apresentamos o PHP Editor um excelente programa e gratuito. Figura 05 – PHP Editor. Fonte: baixaki.ig.com.br/site/detail5761.htm 2.2.2 HTML HTML deriva da expressão inglesa HIPER TEXT MARKUP LANGUAGE em português Linguagem de Marcação por Hipertextos, tornando um simples texto estático em dinâmico é a linguagem com que se escrevem as páginas para World Wide Web. O HTML é fruto da junção de dois padrões: • Hytime (Hypermedia/Time-based Document Structuring Laguagem ): representação estrutura de hipermídia e informação baseada em tempo. Esse padrão fornece a base para a construção de sistemas hipertextos padronizados.
  26. 26. 16 • SGML (Standard Generalized Markup Language): e um padrão de formatação de texto ele não foi desenvolvido para hipertexto, mas é conveniente para transformar documentos em hiper-objetos. As páginas web podem ser vistas pelo usuário mediante um tipo de aplicação chamada navegador (browser) figura 06, se não fosse esses navegadores enxergaríamos conforme a figura 07, esse e um exemplo do código HTML. Hoje o HTML é a linguagem usada pelos navegadores para mostrar as páginas da web ao usuário. Figura 06 – Browser Internet Explorer da Microsoft Figura 07 – Exemplo do Código HTML
  27. 27. 17 O princípio de funcionamento do HTML e transformar texto estáticos em dinâmicos por exemplo ao clicar em uma opção como HOME você será redirecionado para outra página, segue na Figura 08 um exemplo de como pode ser uma estrutura de um Site. Figura 08 – Estrutura de um Portal (Site). Fonte: http://www.desarrolloweb.com 2.3 - BANCO DE DADOS Existem conceitos importantes de recursos que podem ficar perdidos no meio de tantos nomes, assim, para facilitar a compreensão, há uma breve explicação sobre os recursos mais importantes que um banco de dados deve ter. - Referential integrity: também conhecido como integridade referencial, esse recurso consiste em restrições ou regras existentes para uma correta inserção de dados, por exemplo, para impedir que uma tabela seja preenchida sem que isso ocorra em outra;
  28. 28. 18 - Schemas: recurso que permite cruzar informações em um mesmo banco de dados, mas em estruturas diferentes; - SQL: sigla para Structured Query Language, que é uma linguagem utilizada em bancos de dados relacionais; - SSL: sigla para Secure Sockets Layer, que consiste em um protocolo para a troca segura de informações; - Stored procedures: esse recurso consiste em comandos SQL "guardados" no servidor para, por exemplo, executar tarefas repetitivas, evitando que um cliente tenha que executá-las constantemente; - Transactions: também conhecidas como transações, são instruções executadas em um bloco designado por parâmetros que indicam seu início e seu fim; - Triggers: também chamados de gatilhos, são recursos que permitem o acionamento de uma seqüência de comandos logo em seguida ou logo após um evento; - Views: consistem em um tipo de tabela virtual formada por campos extraídos de uma tabela verdadeira, facilitando o controle sob os dados acessados. 2.3.1 - BANCO DE DADOS RELACIONAL O relacional é um modelo de dados adequado a ser o subjacente de um sistema gerenciador de banco de dados (SGDB), que se baseia no princípio de que todos os dados estão guardados em tabelas ou, matematicamente falando, relações. Toda sua definição é teórica e baseada na lógica de predicados e na teoria dos conjuntos.
  29. 29. 19 O conceito foi criado por Edgar Frank Codd em 1970, sendo descrito no artigo "Relational Model of Data for Large Shared Data Banks". Na verdade, o modelo relacional foi o primeiro modelo de dados descrito teoricamente. 2.3.2 - O BANCO DE DADOS MYSQL O MySQL é um dos sistemas de gerenciamento de banco de dados mais populares que existe, e por ser otimizado para aplicações Web, é amplamente utilizado na internet. É muito comum encontrar serviços de hospedagem de sites que oferecem o MySQL e a linguagem PHP, justamente porque ambos trabalham muito bem em conjunto. Outro fator que ajuda na popularidade do MySQL é sua disponibilidade para praticamente qualquer sistema operacional, como Linux, FreeBSD (e outros sistemas baseados em Unix), Windows e Mac OS X. Além disso, o MySQL é um software livre sob licença GPL, o que significa que qualquer um pode estudá-lo ou alterá-lo conforme a necessidade. Entre as características técnicas do SGBD MySQL, estão: - Alta compatibilidade com linguagens como PHP, Java, Python, C#, Ruby e C/C++; - Baixa exigência de processamento (em comparação com outros SGBD); - Vários sistemas de armazenamento de dados (batabase engine), como MyISAM, MySQL Cluster, CSV, Merge, InnoDB, entre outros; - Recursos como transactions (transações), conectividade segura, indexação de campos de texto, replicação etc; - Instruções em SQL, como indica o nome; - Triggers; - Stored procedures; - Sub-selects;
  30. 30. 20 - Suporte total ao Unicode; - INFORMATION_SCHEMA (para armazenamento do dicionário de dados); - Server side cursors; - Suporte a SSL; - Melhoria no tratamento de erros. O MySQL surgiu na Suécia pelas mãos de três colegas: Allan Larsson, David Axmark e Michael Monty Widenius. Trabalhando com base de dados, eles sentiram a necessidade de fazer determinadas conexões entre tabelas e usaram o mSQL para isso. Porém não demoraram para perceber que essa ferramenta não lhes atendia conforme o necessário e passaram a trabalhar em uma solução própria. Surgia, então, o MySQL, cuja primeira versão foi lançada no ano de 1996. Um fato importante a ser destacado sobre o MySQL é que esse SGBD também possui uma versão que necessita de licença comercial. A MySQL AB, empresa que o desenvolve e que o distribui, oferece suporte diferenciado a quem estiver disposto a pagar por isso. 2.3.3 - O BANCO DE DADOS POSTGRESQL O sistema gerenciador de banco de dados PostgreSQL teve seu início na Universidade de Berkeley, na Califórnia, em 1986. À época, um programador chamado Michael Stonebraker liderou um projeto para a criação de um servidor de banco de dados relacionais chamado Postgres, oriundo de um outro projeto da mesma instituição denominado Ingres. Essa tecnologia foi então comprada pela Illustra, empresa posteriormente adquirida pela Informix. Porém, mesmo diante disso, dois estudantes de Berkeley (Jolly Chen e Andrew Yu) compatibilizaram o Postgres à linguagem SQL. Este projeto recebeu o nome de Postgres95.
  31. 31. 21 Em 1996, quando o projeto encontrava-se estável, o banco de dados recebeu o nome de PostgreSQL. No entanto, enquanto ainda possuía o nome Postgres95, o banco de dados teve várias mudanças. O seu código foi totalmente revisado e a linguagem SQL foi definida como padrão. Tecnicamente falando, o PostgreSQL é um banco de dados relacional e orientado a objetos. Um de seus atrativos é possuir recursos comuns a banco de dados de grande porte, o que o deixa apto a trabalhar, inclusive, com operações de missão crítica. Além disso, trata-se de um banco de dados versátil, seguro, gratuito e de código aberto disponível sob uma licença BSD. Entre suas características, tem-se: - Compatibilidade multi-plataforma, ou seja, executa em vários sistemas operacionais, como Windows, Mac OS X, Linux e outras variantes de Unix; - Compatibilidade com várias linguagens, entre elas, Java, PHP, Python, Ruby, e C/C++; - Base de dados de tamanho ilimitado; - Tabelas com tamanho de até 32 TB; - Quantidade de linhas de até 1.6 TB ilimitada; - Campos de até 1 GB; - Suporte a recursos, como triggers, views, stored procedures, SSL, MVCC, schemas, transactions, savepoints, referential integrity e expressões regulares; - Instruções em SQL, como indica o nome;
  32. 32. 22 3. O AMBIENTE ESTUDADO A empresa estudada utiliza, conforme citado anteriormente, uma planilha figura 09 que contém patrimônio do equipamento, tipo equipamento, marca, modelo, número serie, setor da localização, fornecedor, histórico de problemas, data do problema, status da situação e data do retorno. Figura 09 – Planilha de controle de equipamentos na manutenção.
  33. 33. 23 O controle de equipamento de backup figura 10, controla os equipamentos de backup da informática com data de empréstimo, setor emprestado, data da devolução e um campo para observações caso o equipamento tenha sido danificado no setor ou se está saindo para manutenção mantendo essas informações como um histórico, não esquecendo que todo o equipamento da informática é etiquetado com um nome ou número que deve ser seguido em ordem crescente por Ex: Impressora_Bkp1, Impressora_Bkp2. Figura 10 – Planilha de controle de equipamentos de backups. A planilha de inventário de equipamentos conforme figura 11, controla os equipamentos do parque tecnológico com os seguintes campos: nome, NetBios, Sistema
  34. 34. 24 Operacional, IP, patrimônio, localização, setor, processador, memória HD e dispositivos extras. Figura 11 – Planilha de inventário.
  35. 35. 25 4 – MODELAGEM DE DADOS A modelagem de dados é um processo no qual você planeja a sua base de dados de forma que você possa aproveitar os recursos do Gerenciador de Banco e também para que possa construir um banco de dados consistente, que reaproveite recursos, que exija menos espaço em disco e, sobretudo, que possa ser bem administrado. Assim, como no processo de software, a modelagem de dados é um processo que possui etapas a serem seguidas, mas que podem ser superadas, dependendo do tipo de banco que se pretende construir. O documento principal da modelagem de dados é o diagrama de Entidade-Relacionamento (DER) ou Modelo de Entidade-Relacionamento (MER). Neste documento, são representados as entidades e os relacionamentos entre elas. Esta primeira fase é o que chamamos de Modelagem Lógica. É quando determinamos o fluxo de dados entre as entidades, isto é, como o próprio nome diz, quando determinamos a lógica do banco que iremos construir.
  36. 36. 26 4.1 – DIAGRAMA ENTIDADE E RELACIONAMENTO Figura 12 – Diagrama entidade e relacionamento.
  37. 37. 27 4.2 – DICIONÁRIO DE DADOS Um dicionário de dados é uma coleção de metadados que contêm definições e representações de elementos de dados. Dentro do contexto de SGBD, um dicionário de dados é um grupo de tabelas e visões, habilitadas apenas para leitura ou consulta, ou seja, é uma base de dados, propriamente dita, que entre outras coisas, mantém as seguintes informações: - Definição precisa sobre elementos de dados ; - Perfis de usuários, papéis e privilégios; - Descrição de objetos; - Alocações de espaço; Um dos benefícios de um dicionário de dados bem preparado é a consistência entre itens de dados através de diferentes tabelas.
  38. 38. 28 Tabelas TBusuario Tabela com informações dos usuários do sistema. TBperfil Tabela com informações sobre os perfis de segurança do sistema. TBsetor Tabela com informações dos setores atendidos pelo sistema. TBtipo_equipamento Tabela com informações dos tipos de equipamento no sistema. TBtipo_atributo Tabela que guarda a ligação entre a tabela TBtipo_equipamento e TBatributo_tipo_equipamento. TBatributo_tipo_equipamento Tabela com informações de todos os tipo de atributos. TBvalor_atributo Tabela com informações dos valores de cada atributo. TBmarca_equipamentos Tabela com informações com todas as marcas dos equipamentos do sistema. TBequipamentos Tabela com informações dos equipamentos do sistema. TBsolicitacao_saida Tabela com informações de cada saída dos equipamentos para manutenção externa. TBorcamento Tabela com informações de cada orçamento recebido pelos seu respectivos fornecedores. TBmodelo_equipamento Tabela com informações dos modelos dos equipamentos do sistema. TBsilicitacao_servico Tabela com informações da finalização da solicitação de saída. TBhistorico_status Tabela com informações com um histórico das alterações dos status da saída. TBcadastro_status_equipamento Tabela com informações dos status atuais do sistema. TBfornecedor Tabela com informações do fornecedor. TBcontato_fornecedor Tabela com informações do contato com o fornecedor guardando como histórico de contatos. Tabela 01 – Dicionário das Tabelas. TBusuario ColumnName DataType PrimaryKey NotNull Comment AutoInc cod_usuario INTEGER PK NN AI TBPerfil_cod_perfil INTEGER FK TBsetor_cod_setor INTEGER FK descricao_usuario VARCHAR(50) NN funcao_usuario VARCHAR(50) NN e_mail_usuario VARCHAR(50) NN Login_usuario VARCHAR(20) NN senha_usuario VARCHAR(8) NN dasativado BOOL NN Tabela 02 – Dicionário dos campos da tabela usuário.
  39. 39. 29 TBperfil ColumnName DataType PrimaryKey NotNull Comment AutoInc cod_perfil INTEGER PK NN AI Administrador BOOL Consultor BOOL Tabela 03 – Dicionário dos campos da tabela perfil. TBsetor ColumnName DataType PrimaryKey NotNull Comment AutoInc cod_setor INTEGER PK NN descricao_setor VARCHAR(50) NN complemento_setor VARCHAR(255) responsavel_setor VARCHAR(50) NN e_mail_setor VARCHAR(50) NN Tabela 04 – Dicionário dos campos da tabela setor. TBtipo_equipamento ColumnName DataType PrimaryKey NotNull Comment AutoInc cod_Tipo_equipamento INTEGER PK NN AI descricao_tipo_equipamento VARCHAR(50) NN Tabela 05 – Dicionário dos campos da tabela tipo equipamento. TBtipo_atributo ColumnName DataType PrimaryKey NotNull Comment AutoInc TBtipo_equipamento_cod_Tipo_equipamento INTEGER FK NN TBatributo_tipo_equipamento_cod_atributo_equipamento INTEGER FK NN Tabela 06 – Dicionário dos campos da tabela tipo atributo. TBatributo_tipo_equipamento ColumnName DataType PrimaryKey NotNull Comment AutoInc cod_atributo_equipamento INTEGER PK NN AI TBvalor_atributo_Cod_valor INTEGER FK NN descricao_atributo VARCHAR(50) NN Tabela 07 – Dicionário dos campos da tabela atributo tipo equipamento. TBcadastro_status_equipamento ColumnName DataType PrimaryKey NotNull Comment AutoInc cod_status INTEGER PK NN AI descritivo_status VARCHAR(50) NN Tabela 08 – Dicionário dos campos da tabela status do equipamento.
  40. 40. 30 TBcontato_fornecedor ColumnName DataType PrimaryKey NotNull Comment AutoInc cod_Contato_fornecedor INTEGER PK NN AI TBPerfil_cod_perfil INTEGER FK NN TBsolicitacao_saida_saida_cod_solicitacao_saida INTEGER FK NN TBfornecedor_cod_fornecedor INTEGER FK NN Horas_contato TIME NN data_contato DATE NN descritivo_contato VARCHAR(255) NN Tabela 09 – Dicionário dos campos da tabela contato fornecedor. TBequipamentos ColumnName DataType PrimaryKey NotNull Comment AutoInc pi_equipamento VARCHAR(5) PK NN TBmodelo_equipamento_Cod_modelo INTEGER FK NN TBmarca_equipamentos_Cod_marca INTEGER FK NN TBsetor_cod_setor INTEGER FK NN TBtipo_equipamento_cod_Tipo_equipamento INTEGER FK NN Data_cadastro DATE NN n_serie_equipamentos VARCHAR(50) NN data_compra_equipamento DATE NN Tempo_garantia DATE NN backup_equipamento BOOL NN Tabela 10 – Dicionário dos campos da tabela equipamentos. TBfornecedor ColumnName DataType PrimaryKey NotNull Comment AutoInc cod_fornecedor INTEGER PK NN AI descricao_fornecedor VARCHAR(50) NN cnpj_fornecedor VARCHAR(20) NN Telefone_fonecedor INTEGER NN contato_fornecedor VARCHAR(50) NN end_fornecedor VARCHAR(255) NN e_mail_fornecedor VARCHAR(50) NN Tabela 11 – Dicionário dos campos da tabela fornecedor.
  41. 41. 31 TBhistorico_status ColumnName DataType PrimaryKey NotNull Comment AutoInc TBsolicitacao_saida_saida_cod_solicitacao_saida INTEGER FK NN Historico_alteracao_equipamento_Status_equipamento_cod_status INTEGER NN data_status DATE Tabela 12 – Dicionário dos campos da tabela histórico status. TBmarca_equipamentos ColumnName DataType PrimaryKey NotNull Comment AutoInc Cod_marca INTEGER PK NN AI Descricao_marca VARCHAR(50) NN Observacao_marca VARCHAR(50) Tabela 13 – Dicionário dos campos da tabela marca equipamentos. TBmodelo_equipamento ColumnName DataType PrimaryKey NotNull Comment AutoInc Cod_modelo INTEGER PK NN AI Descricao_modelo VARCHAR(50) NN Observacao_modelo VARCHAR(255) Tabela 14 – Dicionário dos campos da tabela modelo equipamento. TBorcamento ColumnName DataType PrimaryKey NotNull Comment AutoInc cod_orcamento INTEGER PK NN AI TBsilicitacao_servico_cod_solicitacao_serv INTEGER FK NN TBsolicitacao_saida_saida_cod_solicitacao_saida INTEGER FK NN TBfornecedor_cod_fornecedor INTEGER FK NN n_orcamento INTEGER NN data_orcamento DATE NN valor_mao_obra_orcamento FLOAT NN valor_peca_orcamento FLOAT NN data_solicitacao_aprovacao DATE NN descritivo_pecas_orcamento VARCHAR(255) descricao_mao_obra VARCHAR(255) Tabela 15 – Dicionário dos campos da tabela orçamento.
  42. 42. 32 TBsilicitacao_servico ColumnName DataType PrimaryKey NotNull Comment AutoInc cod_solicitacao_serv INTEGER PK NN Data_finalizacao DATE NN Observacao VARCHAR(255) Aprovado BOOL Reprovado BOOL Tabela 16 – Dicionário dos campos da tabela solicitação serviço. TBsolicitacao_saida ColumnName DataType PrimaryKey NotNull Comment AutoInc cod_solicitacao_saida INTEGER PK NN AI TBequipamentos_pi_equipamento VARCHAR(5) FK NN TBPerfil_cod_perfil INTEGER FK NN n_OS_solicitacao INTEGER data_emissao_solicitacao DATE NN descritivo_solicitacao VARCHAR(255) NN acessorios_solicitacao VARCHAR(255) Tabela 17 – Dicionário dos campos da tabela solicitação saída. TBvalor_atributo ColumnName DataType PrimaryKey NotNull Comment AutoInc Cod_valor INTEGER PK NN TBequipamentos_pi_equipamento VARCHAR(5) FK NN Valor_atributo VARCHAR(45) Tabela 18 – Dicionário dos campos da tabela valor atributo. 4.3 – DIAGRAMA DE CONTEXTO (DC) O diagrama de contexto é uma forma de representar o objeto do estudo, com relação ao ambiente em que se insere. Para gerar um diagrama de contexto deve se seguir a seguinte estrutura: ● Identificação dos usuários.
  43. 43. 33 Nesta etapa devemos identificar os usuários do sistema, eles podem ser o grupo que solicitou o sistema ou grupos internos ou externos a organização e que fornecerão ou receberão dados do sistema. Desenhe o sistema como um único grande processo. - Identificação dos eventos . No ambiente do usuário determine os eventos (situações) que resultam na geração de um fluxo de dados de entrada ou que requerem que o usuário receba dados do sistema. - Identificação das entradas e saídas. Para cada item da lista de eventos determine quais fluxos conectam o evento ao sistema. Os eventos importantes produzem entradas para o sistema ou utilizam saídas do sistema. Se um evento não tiver uma conexão de dados elimine-o da lista. Caso você identifique um fluxo de dados não considerado na lista de evento, acrescente o evento correspondente. 5 SituaçãoEquipamento 6 Inform a Aprovação C onserto Figura 13 – Diagrama de Contexto.
  44. 44. 34 4.4 – DFD O diagrama de fluxo de dados DFD, representa o fluxo de dados num sistema de informação, assim como as sucessivas transformações que estes sofrem. O DFD é uma ferramenta gráfica que transcreve, de forma não técnica, a lógica do procedimento do sistema em estudo, sendo usada por diferentes métodos. O DFD é a ferramenta mais usada para documentar a fase de análise do convencional ciclo de desenvolvimento de sistemas de informação. Uma vez que o DFD só representa a lógica, ou seja, o quê do sistema, a informação de controle não é representada neste diagrama. Nos diagramas originais de fluxo de dados, a informação de controle não era considerada no entanto nos últimos anos alguns autores alargaram os conceitos envolvidos neste diagrama para que pudesse ser utilizado para sistemas em que o tempo é um elemento crucial – sistemas de tempo real. O diagrama de fluxo de dados apresenta sempre quatro objetos de um sistema de informação: fluxo de dados, processos, arquivos de dados e entidades externas. Esta ferramenta é usada por diferentes autores, por exemplo Gane & Sarson e DeMarco & Yourdon , que recorrem a métodos e símbolos diferentes para representar cada objeto Figura 14.
  45. 45. 35 Figura 14 – Representação dos símbolos a utilizar no desenho de um DFD. No entanto, qualquer autor que use estes diagramas define os objetos do sistema da mesma forma: - entidades externas - pessoa, grupo de pessoas ou subsistema/sistema fora do sistema em estudo que recebem dados do sistema e/ou enviam dados para o sistema. As entidades externas funcionam sempre como origem/destino de dados; - fluxo de dados - dados que fluem entre processos, entre processos e arquivos de dados ou ainda entre processos e entidades externas, sem nenhuma especificação temporal (por exemplo ocorrência de processos simultâneos, ou todas as semanas); - arquivo de dados - meio de armazenamento de dados para posterior acesso e/ou atualização por um processo;
  46. 46. 36 - processo - recebe dados de entrada e transforma estes dados num fluxo de saída. Cada um dos processos representados pode ser decomposto num DFD Nível n+1 até atingir o nível desejado. 4.5 – DFD NÍVEL 0 SISTEMA O DFD de nível 0 apresenta uma visão clara do produto com todos os macro-processos, com entidades externas, fluxo de dados e depósito de dados principais. 6 SolicitarSaída 13 SolicitaConsultaSaída 2 Solicita C adastro/Alteração U suários 12 Solicita C onsulta U suários 15 SolicitaConsultaFornecedores 5 SolicitaCadastro/AlteraçãoFornecedores 16 Solicita C onsulta Equipam entos 4 Solicita C adastro/Alteração Equipam entos 9 SolicitaCadastro/AlteraçãoOrçamentos 17 SolicitaConsultaOrçamentos 18 Inform a Aprovação C onserto Figura 15 – DFD Nível 0 Sistema.
  47. 47. 37 4.6 - DFD NÍVEL 1 SISTEMA Figura 16 – DFD Nível 1 Sistema.
  48. 48. 38 4.7 - DFD Nível 2 - USUÁRIOS 11 SolicitaAlteração 7SolicitaValidaçãoDados 5 Inform a Setor 2 SolicitaValidaçãoDados 4 D efiniPerfil 8 C onsulta Perfil 3 Solicita C adastro / Alteração U suários 9 SolicitaConsultaUsuários 10 InformaSituaçãoCadastro 14SituaçãoUsuário Figura 17 – DFD Nível 2 Usuários.
  49. 49. 39 4.8 - DFD Nível 2 – SETORES 6 Solicitação Consulta Setores 10 SolicitaAlteração 7SolicitaValidaçãoDados 2 SolicitaValidaçãoDados 4 InformaSituaçãoCadastro 8SituaçãoSetor 3 SolicitaCadastro/ AlteraçãoSetores 9 Solicita C onsulta Setores Figura 18 – DFD Nível 2 Setores.
  50. 50. 40 4.9 - DFD Nível 2 – EQUIPAMENTOS Administrador 3.1 Cadastrar Equipamentos 3.2 Validar Dados 3.3 Consultar Equipamentos 3.4 Alterar Equipamentos EQUIPAMENTOS 3.6 Controlar Modelos 3.7 Controlar Marcas MODELOS MARCAS 3.8 Controlar Tipos / Atributos TIPOS TIPO ATRIBUTO VALOR ATRIBUTO 13 SolicitaçãoConsultaValor 25SolicitaCadastro/ AlteraçãoValor 20 Solicita Cadastro / Alteração Marcas 9 SolicitaConsultaMarcas 7Solicita Cadastro / Alteração Modelos 19 SolicitaConsultaModelos 11 SolicitaCadastro/ AlteraçãoTipos 23 SolicitaçãoConsultaTipos 12 SolicitaCadastro/Alteração Atributo 24 SolicitaConsultaAtributo 22 InformaTipos/ Atributo 9 Situação Tipo / Atributos 23 SolicitaAlteração 8InformaMarcas 21SituaçãoMarcas 10 Inform a M odelos 18 Situação M odelos 1Informa Equipamentos 2Solicita Validação 5 InformaSituação Cadastro 4 SolicitaCadastroEquipamentos 16 SolicitaConsultaEquipamentos 14 Situação Equipamentos 15 Solicita Validação 17 Inform a Situação Equipam entos 26 Solicita Consulta Equipamentos 27 SituaçãoEquipamentos 28 Altera Cadastro Equipamentos SETORES 3 SituaçãoSetores Figura 19 - DFD Nível 2 Equipamentos.
  51. 51. 41 4.10 - DFD Nível 2 – FORNECEDORES 2 SolicitaValidação 4 InformaSituaçãoCadastro 7 Solicita Consulta Fornecedores 3 Solicita Cadastro / Alteração Fornecedores 5 SituaçãoFornecedores 9SolicitaAlteração 11 SolicitaConsulta Fornecedores 10 InformaSituaçãoFornecedores Figura 20 – DFD Nível 2 Fornecedores.
  52. 52. 42 4.11 - DFD Nível 2 - RELATÓRIOS Administrador Consultor SAÍDA EQUIPAMENTOS 5.1 Emitir Relatório STATUS EQUIPAMENTOS 5.2 Validar Dados 1SolicitaRelatório 2Valida D ados 3 Situação Saída 4 Situação Status 5SituaçãoDados 6 Situação Relatório 7SolicitaRelatório 8 Situação Relatório Figura 21 – DFD Nível 2 Relatórios.
  53. 53. 43 4.12 - DFD Nível 2 - SOLICITAÇÃO DE SAÍDA Administrador 6.1 Cadastrar SAÍDA FORNECEDORES 6.2 Validar Dados 6.3 Consultar Saída 6.4 Alterar Saída EQUIPAMENTOS SAÍDA EQUIPAMENTOS STATUS EQUIPAMENTOS 6.5 Controlar Orçamentos ORÇAMENTOS 1 Informa Saída 5Solicita Cadastro / Alteração 4 Informa Fornecedor 3Informa Equipamentos 7 Situação da Saída 10 SolicitaConsulta 13 SolicitaConsulta 14 Consulta dados 15 InformaOrçamentos 17 SituaçãoOrçamentos 16 Solicita Cadastro / Alteração Orçamentos 18 SolicitaConsulta Orçamentos Figura 22 – DFD Nível 2 Solicitação de Saída.
  54. 54. 44 4.13 - DFD Nível 2 – CONTATO FORNECEDOR 2Valida D ados 4 SituaçãoSaída Equipamentos 6SituaçãoDados 7 Situação C ontato Fornecedores 5 SolicitarC adastro /Alteração C ontato Fornecedores 9 SolicitarC onsulta C ontato Fornecedores Figura 23 – DFD Nível 2 Contato Fornecedor.
  55. 55. 45 4.14 - DFD Nível 2 – CONTROLAR SERVIÇOS 2Valida D ados 4 Situação O rçam entos 6SituaçãoDados 7 Situação Serviços 5 SolicitarCadastro /Alteração Serviços 9 SolicitarConsulta Serviços Figura 24 – DFD Nível 2 Controlar Serviços.
  56. 56. 46 5 – DESENVOLVIMENTO DO PROTÓTIPO O Trabalho consiste em analisar e propor uma solução em sistema que satisfaça suas necessidades. Em seguida será mostrado um protótipo das telas iniciais principais. Para o Desenvolvimento foi utilizada a linguagem PHP com HTML e alguns JAVA SCRIPTS, para modelagem dos Dados e criação da base o BDDesigner 4 e a ferramenta XAMMP que contém um servidor WEB, o Apache, com o PHP e MySQL. Na figura 25 teremos a parte de administração com todos os cadastros iniciais como usuário, setores, Fornecedores e Equipamentos. Figura 25 – Protótipo Menu Admin.
  57. 57. 47 Na Figura 26, teremos a parte de Contato com Fornecedor com um Histórico de todos os Contatos com os Fornecedores. Figura 26 – Protótipo Menu Contato Fornecedor.
  58. 58. 48 Na Figura 27, teremos a parte de Solicitação de Saída de Equipamentos para Manutenção. Figura 27 – Protótipo Menu Saída de Equipamentos.
  59. 59. 49 Na Figura 28, teremos a parte Cadastro e Consulta dos Orçamentos dos Equipamentos na Manutenção. Figura 28 – Protótipo Menu Orçamento.
  60. 60. 50 Na Figura 29, teremos a parte de Aprovação ou Reprovação dos Orçamentos dos Equipamentos na Manutenção em desenvolvimento. Figura 29 – Protótipo Menu Finaliza Serviço.
  61. 61. 51 6 - CONSIDERAÇÕES FINAIS Este trabalho descreveu os processos fundamentais, para a análise de processo, desenvolvimento de Software, dando total estrutura para poder desenvolver um protótipo interativo, denominado Zeus, para o gerenciamento dos equipamentos na manutenção e inventário, a qual está no processo de codificação das telas dos menus. Buscando construir um produto de Software, que tem um objetivo genuíno de facilitar o acompanhamento no processo de Manutenção dos Equipamentos externos e melhorando, assim, o atendimento ao usuário, garantindo a segurança e veracidade dos dados fornecidos. Busquei em minha consulta bibliográfica todos os fundamentos necessários e a opinião de diversos autores a fim de gerar um Software produtivo. Com o desenvolvimento do protótipo inicial concluído, será disponibilizada uma versão para teste e, se possível, identificar possíveis problemas. O trabalho busca, com esse sistema, melhorar a rapidez e eficiência no processo de Atendimento, cuja primeira instância é a raiz do Suporte de TI.
  62. 62. 52 REFERÊNCIAS BIBLIOGRÁFICAS ALMEIDA, Ricardo Falbo. A Experiência na Definição de um Processo Padrão Baseado no Processo Unificado, 2007. Disponível no endereço: < http://www.inf.ufes.br/~ falbo/ download/pub/Simpros2000.pdf > Último acesso em: 12/09/2007. Banco de Dados MySQL, 2007. Disponível no endereço: <http://www.mysqlbrasil.com .br> Último acesso em: 03/05/2007. Banco de Dados Postgresql, 2007. Disponível no endereço: <http://www.postgresql.org.br> Último acesso em: 03/05/2007. CHEN, Peter. Modelagem de dados: A abordagem entidade relacionamento para projeto lógico. São Paulo: Makron Books, 1990. 80 p. Busca: Linguagem de Programação, 2007. Disponível no endereço: <http://pt.wikipedia.org/wiki/Linguagem_de_programa%C3%A7%C3%A3o>. Último acesso em: 03/05/2007. Busca: Modelo Relacional, 2007. Disponível no endereço: <http://pt.wikipedia.org/wiki/ Modelo_Relaciona >. Último acesso em: 03/05/2007. Busca: Modelo Cascata, 2007. Disponível no endereço: < http://pt.wikipedia.org/wiki/ Modeloemcascata>. Último acesso em: 10/07/2007. MUTO, Cláudio Adonai. PHP & MYSQL: guia completo. Rio de Janeiro: Brasport, 2002. 312 p. PUSHMAN, Jalal. Por que usar PHP, 2000. Disponível no endereço: <http:// wevdelopershounal.com/articles/why php.html.>. Último acesso em: 03/05/2007. PRESSMAN, Roger S. Engenharia software. São Paulo: Makron Books. Trad. SANTOS, José Carlos Barbosa, 2º Ed., 2005. 1056 p. SILBERSCHATZ, Abraham; KORTH, Henry F.; SUDARSHAN, S. Sistema de banco de dados. São Paulo: Makron Book, Trad. Marilia Guimarões Pinheiro, 3º Ed., 2004. 778 p. MARCO,Tom . Structured analysis and system specification. Yourdon Press, 1978. GANE,Chris, SARSON,Trish. Análise estruturada de sistemas. Livros Técnicos e Científicos, 5ª edição, 1985. LEITE, Jair. Engenharia de Software, 2007. Disponível no endereço: < http:// engenhariadesoftware.blogspot.com/2007/03/o-modelo-espiral.html.> Último acesso em: 03/06/2007.
  63. 63. 53 Artigo: O que é PHP < http://www.desarrolloweb.com/articulos/392.php>. Último acesso em : 12/08/2007. Artigo: Introdução ao HTML <http://www.criarweb.com/artigos/10.php> .Último acesso em : 09/08/2007. Artigo: Linguagem HTML. <http://www.criarweb.com/artigos/255.php> .Último acesso em : 15/07/2007. Artigo: O que é PHP. <http://www.criarweb.com/artigos/202.php> .Último acesso em : 15/07/2007. Artigo: phpMyAdmin. <http://www.criarweb.com/artigos/121.php>. Último acesso em : 15/07/2007. Manual MySQL.<HTTP://www.criarweb.com/manuais/mysql/>. Último Acesso em: 09/07/2007.

×