PROPOSTA DE SOFTWARE PARA CONTROLE DE EQUIPAMENTOS

FACULDADES NETWORK
ZÓZIMO RODRIGUES DE SOUZA JUNIOR
PROPOSTA DE SOFTWARE
PARA CONTROLE DE EQUIPAMENTOS
NOVA ODESSA
2007

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

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

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.

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.

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

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.

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

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

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

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.

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.

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:

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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

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.

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

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;

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.

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;

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.

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;

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.

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

24
Operacional, IP, patrimônio, localização, setor, processador, memória HD e dispositivos
extras.
Figura 11 – Planilha de inventário.

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.

26
4.1 – DIAGRAMA ENTIDADE E RELACIONAMENTO
Figura 12 – Diagrama entidade e relacionamento.

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.

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.

29
TBperfil
cod_perfil INTEGER PK NN AI
Administrador BOOL
Consultor BOOL
Tabela 03 – Dicionário dos campos da tabela perfil.
TBsetor
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
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
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
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
cod_status INTEGER PK NN AI
descritivo_status VARCHAR(50) NN
Tabela 08 – Dicionário dos campos da tabela status do equipamento.

30
TBcontato_fornecedor
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
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
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.

31
TBhistorico_status
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
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
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
cod_orcamento INTEGER PK NN AI
TBsilicitacao_servico_cod_solicitacao_serv 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.

32
TBsilicitacao_servico
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
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
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.

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.

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.

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;

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.

37
4.6 - DFD NÍVEL 1 SISTEMA
Figura 16 – DFD Nível 1 Sistema.

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.

39
4.8 - DFD Nível 2 – SETORES
6
Solicitação Consulta
Setores
10
SolicitaAlteração
7SolicitaValidaçãoDados
2
SolicitaValidaçãoDados
4
8SituaçãoSetor
3
SolicitaCadastro/
AlteraçãoSetores
9
Solicita
C
onsulta
Setores
Figura 18 – DFD Nível 2 Setores.

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.

41
4.10 - DFD Nível 2 – FORNECEDORES
2
SolicitaValidação
4
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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

PROPOSTA DE SOFTWARE PARA CONTROLE DE EQUIPAMENTOS

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (11)

Ähnlich wie PROPOSTA DE SOFTWARE PARA CONTROLE DE EQUIPAMENTOS

Ähnlich wie PROPOSTA DE SOFTWARE PARA CONTROLE DE EQUIPAMENTOS (20)

PROPOSTA DE SOFTWARE PARA CONTROLE DE EQUIPAMENTOS