Modelo TCC - Template PDF

Modelo TCC - Template http://dc193.4shared.com/doc/fsPLDFFg/preview.
html
1 de 25 09/09/2014 22:20
Modelo TCC - Template http://dc193.4shared.com/doc/fsPLDFFg/preview.html
FACULDADE ALVORADA
CURSO DE TECNÓLOGO EM SISTEMAS DE INFORMAÇÃO
José do Nascimento Sousa
Eduardo Diniz
Sistema para Controle de Equipamento Reserva – SisCER
Brasília-DF
2012
José do Nascimento Sousa
Eduardo Diniz
Sistema para Controle de Equipamento Reserva – SisCER
Monografia apresentada a Faculdade Alvorada para a obtenção do título de Tecnólogo em Sistemas de Informação.
Orientador: Prof. Especialista Guilherme Rodrigues de Oliveira
2 de 25 09/09/2014 22:20
Brasília-DF
2012
3 de 25 09/09/2014 22:20
TERMO DE APROVAÇÃO
4 de 25 09/09/2014 22:20
DEDICATÓRIA
Dedico este trabalho em especial à milha família, às pessoas que considero minha segunda família, Dona Vera Lúcia, Aleide Verlane e Alcilan, que estavam sempre me dando força e motivação para seguir esta
caminhada.
(José do Nascimento)
A Deus, por tudo que fez e faz na minha vida.
A minha família, base da minha vida.
(Eduardo Diniz)
AGRADECIMENTOS
Primeiramente agradeço a Deus por todas as bênçãos que tem feito por mim.
Agradeço a meus pais Maria do Nascimento e Miguel Rodrigues, por acreditarem em mim e por ter feito de tudo para que, mesmo em momentos difíceis, nunca desistir de estudar.
Agradeço ao nosso orientador, que nos ajudou a desenvolver este trabalho.
Agradeço também ao professor João Rebés pelas suas dicas em relação ao trabalho.
Agradeço aos meus colegas de classe que sempre foram muito prestativos em todos os aspectos.
(José do Nascimento)
Agradeço primeiramente ao meu Deus e Pai por estar presente em minha vida me dando força para superar todos os obstáculos nessa trajetória.
A minha família que foi fundamental nessa caminhada, em especial à minha Mãe que sempre esteve ao meu lado me apoiando nos momentos que eu mais precisei.
Agradeço também aos meus verdadeiros amigos que fizeram parte desta etapa na minha vida e aos professores que estiveram presentes nos orientando e nos ensinado.
Enfim, agradeço a todos que de alguma forma ou de outra colaboraram e apoiaram para a conclusão deste trabalho.
(Eduardo Diniz)
5 de 25 09/09/2014 22:20
RESUMO
A necessidade de se ter um controle sobre bens e serviços em poder da área de TI (Tecnologia da Informação) é de suma importância para a empresa. Evitam-se gastos extras e a perda de disponibilidades de recursos. Para que seja
possível este controle é importante o uso de sistemas de informação para registrar as requisições e controle de uso. Sendo assim, o presente trabalho apresenta a implementação de um sistema para controle de equipamentos reservas.
Palavras-chave: Sistema de Informação. Tecnologia da Informação. Controle de equipamentos reservas. PHP. MySQL
6 de 25 09/09/2014 22:20
ABSTRACT
The need to have a control on goods and services in the power of IT (Information Technology) is of paramount importance to the company. This avoids extra expenses and loss of available resources. To be able to control it is important to use information
systems to record requests and usage control. Therefore, this work presents the implementation of a system for controlling equipment reserves.
Keywords: Information System. Information Technology. Control equipment
reserves. PHP. MySQL.
7 de 25 09/09/2014 22:20
LISTA DE FIGURAS
8 de 25 09/09/2014 22:20
LISTA DE TABELAS
9 de 25 09/09/2014 22:20
LISTA DE ABREVIATURAS E SIGLAS
API Application Programming Interface
ASP Active Server Pages
GB Giga Byte
GPL General Public License
GPL General Public License
HD Hard Disk
HTML HyperText Markup Language
JSP JavaServer Pages
LCD Liquid Cristal Display
MER Modelo de Entidade-Relacionamento
OO Orientação a Objetos
PDV Ponto de Vendas
PHP Hypertext Preprocessor
PHP/FI Personal Home Page/Forms Interpreter
RDBMS Relational Database Management System
RUP Rational Unified Process
SGBD Sistema Gerenciador de Banco de Dados
SisCER Sistema para Controle de Equipamento Reserva
SQL Structured Query Language
TB Tera Byte
TI Tecnologia da Informação
UC Use Case
UML Unified Modeling Language
XP Extreme Programming
SQL Structured Query Language
TB Tera Byte
TI Tecnologia da Informação
UC Use Case
UML Unified Modeling Language
10 de 25 09/09/2014 22:20
SUMÁRIO
1.
11 de 25 09/09/2014 22:20
Introdução
Para manter um atendimento ao cliente com eficiência e qualidade, é necessário que a empresa esteja preparada para contornar os problemas na hora certa. Uma empresa bem estruturada permite uma obtenção de vantagens competitiva,
aumentando assim a satisfação do cliente pelos serviços oferecidos (BERRY e PARASURAMAN, 1995).
Para atingir estes objetivos, são investidos recursos em sistemas de software para atender às áreas de negócio. Deste modo, surge a importância do alinhamento da TI (Tecnologia da Informação) aos negócios, cujo papel é entregar soluções
adequadas, nos prazos necessários. Este é um dos desafios da TI (SILVA e AZEVEDO, 2010).
O Sistema de Controle de Equipamento Reserva (SisCER) facilitará o processo de atendimento ao cliente de help-desk e service-desk, no controle de equipamentos para empréstimos. Pois, com esse sistema, os técnicos de primeiro nível
terão maior agilidade para consultar a disponibilidade dos equipamentos, proporcionando assim maior agilidade nas respostas ao cliente. E os técnicos de segundo nível terão um controle maior do fluxo de empréstimos assim como a localização
dos emprestados.
1. Tema
O Sistema SisCER será capaz de proporcionar um controle maior sobre equipamentos de informática (impressoras, PDVs, nobreaks, estabilizadores, teclados, monitores, gavetas entre outros) que são solicitados para uso temporário, pelo
usuário. O controle e as requisições de equipamentos reservas serão feitas via browser.
2. Justificativa
Tendo por princípio a necessidade de um controle dos equipamentos que estão sobre responsabilidade do laboratório de informática da empresa fictícia BIGMIX, há a necessidade de um sistema para controlar os empréstimos e o
armazenamento destes ativos e que possibilite o gerenciamento de requisições solicitadas pelos técnicos da área de Help Desk.
1. Formulação do Problema
1.
A empresa BIGMIX é uma rede de supermercado do tipo fictícia com matriz situada na 403 Norte em Brasília, DF. É na sede que se localiza o setor de tecnologia da informação. O laboratório de informática é o responsável por manter,
organizar e consertar equipamentos de TI. É também o responsável pelo controle, a guarda e a manutenção dos equipamentos reservas. Estes são usados para substituir, temporariamente, os equipamentos de clientes que estão em manutenção.
A dificuldade que o laboratório de informática está sofrendo para manter o controle de equipamentos reserva vem causando atrasos e falhas nas solicitações, e também a “perda” de equipamentos nas filiais. O controle dos desses ativos são
feitos com anotações em planilhas, mas, em muitos dos casos, essas são deixadas de lado, tornando difícil a localização do equipamento.
O sistema, atualmente em uso, não permite um controle absoluto dos reservas.
4. Objetivos
Um objetivo pode ser definido como um propósito ou alvo que se pretende atingir, também pode ser chamado de objetivos, tudo aquilo que se deseja alcançar
através de uma ação clara e explícita (MARINHO 2007).
1. Objetivo Geral
Desenvolver um sistema utilizando o ambiente Web, permitindo o controle de equipamentos reserva pelo laboratório de informática e as solicitações pelos técnicos de suporte de primeiro nível.
2. Objetivos Específicos
Controlar os equipamentos de informática reservas e as solicitações de requisições.
Realizar consultas de equipamentos reservas por tipo de equipamento (Estação, PDV, Balança, Gavetas, Teclados, Monitores, Nobreaks, Impressoras, entre outros.
Gerar relatórios dos equipamentos reservas que estão ativos ou não ativos podendo ser filtrados por tipo de equipamento.
5. Organização do Trabalho
O primeiro capítulo refere-se ao contexto do trabalho, o tema, os objetivos da monografia em apresentação.
O segundo capítulo realiza a apresentação da empresa BIBMIX e seu ramo de negócio.
O terceiro capítulo apresenta o cronograma das atividades de desenvolvimento dessa monografia, sinalizando os prazos para a finalização do trabalho.
O quarto capítulo descreve o referencial teórico, todas as fontes de pesquisa de ferramentas que serão utilizadas para o desenvolvimento do sistema e escrita da monografia.
No quinto capítulo, é apresentada a proposta, a descrição, os resultados, as restrições e as áreas afetadas pelo sistema que será desenvolvido.
No sexto capítulo, a descrição e identificação dos atores, casos de uso. E as principais telas do sistema e suas funcionalidades são apresentadas.
O sétimo capítulo descreve as atividades desempenhadas para a implantação do sistema na empresa.
Para o oitavo capítulo está registrada a conclusão do trabalho.
No nono e último capítulo estão descritas todas as referências bibliografias que dão sustentação e base ao desenvolvimento deste trabalho.
2.
12 de 25 09/09/2014 22:20
Análise Institucional
A análise institucional é um produto social-histórico. Trata-se da concepção de história da empresa (GOMES, 2006). Neste capítulo trataremos da análise institucional da empresa BIGMIX sua história, seu ramo de negócio, com o propósito de
abstrair os conhecimentos necessários para entender suas necessidades perante a construção de um novo sistema.
1. A Empresa e seu Negócio
A empresa BIGMIX é uma rede de supermercado, com sede estabelecida em Brasília – Asa Norte, com filiais em várias localidades do Distrito Federal. A BIGMIX dispõe de uma central de suporte ao usuário e de um laboratório de
informática localizado na 403 Norte.
A BIGMIX foi fundada em 1992, na 107 Norte. Em 1997 deu-se o início do processo de expansão dos negócios erguendo um prédio na 402/403 Norte, onde hoje funciona a matriz da organização, com inauguração em 17 de Dezembro de
1998. Neste período foi aberto, também, o Big Mix da QI-25 do Lago Norte, assim como o da 415/416 Sul, inaugurada em abril de 2005, com o que há de mais moderno no setor.
Em agosto de 2004, foi inaugurada a loja do Sudoeste, e em janeiro de 2008 no Lago Norte. Recentemente mais duas lojas foram instaladas, uma em Vicente Pires e outra em Águas Claras.
Sua política de trabalhar com produtos de qualidade a preços baixos e uma atenção especial no bom atendimento, resultou numa experiência gratificante para a empresa: a fidelização de clientes. Ao contrário das grandes redes, a BIGMIX é
visto como um supermercado de vizinhança, o bom amigo sempre pronto a atender.
1. Organograma da Empresa
O organograma da empresa BIGMIX está disposto da seguinte forma:
Figura - Organograma da Empresa
2. Descrição das Necessidades
“A atividade de levantamento de requisitos corresponde à etapa de compreensão do problema, aplicada ao desenvolvimento de software” (BEZERRA, 2002).
Para Pfleeger (2004), o levantamento e a análise dos requisitos não envolvem apenas descrever e registrar os requisitos apontados pelo cliente, mas sim identificar requisitos nos quais os desenvolvedores e o cliente possam concordar e nos
quais possam ser testados.
Notadamente há a necessidade de melhorar o processo de solicitações e o controle de equipamentos administrados pelo laboratório de informática da instituição, que hoje é feito da seguinte forma: O técnico de primeiro nível solicita por
telefone a requisição de um equipamento reserva e o técnico de segundo nível verifica se há disponibilidade de máquinas reserva, havendo a disponibilidade o técnico encaminha o equipamento para o cliente, fazendo anotações deste envio em
planilhas e nos chamados técnicos. O fato é que nem sempre são feitas essas anotações. Muitas vezes o cliente finaliza o chamado sem que a reserva tenha sido devolvida para o laboratório, fazendo com que os equipamentos fiquem retidos nas
lojas filiais.
3. Sistema de Informação Existente na Empresa
O atual software utilizado pela empresa é um sistema de ordem de serviço, onde é possível acompanhar todo o atendimento do chamado, controle de usuários, relatórios de chamados abertos e encerrados. O sistema tem um módulo de
empréstimo, mas não é usado por não atender as demanda do setor.
Todas as vezes que é aberto ou alterado um chamado, o sistema envia um aviso via e-mail com as devidas atualizações, possibilitando uma maior interação entre o técnico e o usuário.
4. Normas de Funcionamento
Para o devido funcionamento do sistema é necessário que o cliente registre uma ordem de serviço no sistema de acompanhamento técnico já existente na empresa. Após realizado este procedimento, o técnico de primeiro nível realiza o
atendimento e verifica se há necessidade do envio do equipamento para o laboratório. Se houver a necessidade do envio, o mesmo terá que registrar uma requisição de equipamento reserva no sistema SisCER e será atendido pelo técnico de
segundo nível que registrará neste sistema o empréstimo e enviará o equipamento reserva para o cliente.
Logo que o equipamento é consertado, o mesmo retorna para o cliente e o equipamento reserva é devolvido para o laboratório e a requisição é encerrada no sistema.
A ordem de serviço aberta pelo cliente no sistema atual da empresa poderá ser encerrada e a requisição no SisCER poderá continuar aberta até a devolução do equipamento para o laboratório.
5. Ambiente Tecnológico Existente
O ambiente tecnológico é composto por 260 computadores sendo 110 AMD Sempron 2.0GHz, 1GB, HD 160GB, monitor LCD 15", sistema operacional Windows XP, todo o pacote BrOffice; 30 Intel Celeron 2.8GHz, 1GB, HD 160GB, monitor
LCD 15”, Sistema operacional Windows XP; 90 AMD Sempro 2,7GHz, 2GB, 500GB, 60 com monitor LCD 15” e 30 com monitor de 20”, 57 com sistema operacional Windows 7 e 3 com sistema operacional Linux Ubuntu 12.4, das 90, 30 delas com
pacote BrOffice, 15 com gravadoras de CD/DVD; 30 Intel Pentium 4 3.2GHz, 1GB, HD 160GB, Monitor LCD 18,5”, sistema operacional Windows XP, 15 com pacote Office 2003 e 15 com BrOffice. 12 impressoras HP p2015, 8 impressoras HP 6940,
5 impressoras HP 2050.
1 Servidor de aplicações Dell PowerEdge T100 com Sistema operacional Windows server 2003; 2 Servidor de Apalicação Dell PowerEdge 2800 com Sistema operacional Ubuntu Server 10.04; 1 servidor de aplicação Intel Xeon 3.00GHz,
16GB, HD 2TB, Sistema operacional Debian 6; 1 Servidor de Banco de dado Dell PowerEdge 2800 Sistema operacional Windows server 2003; 1 servidor de banco de dados Dell PowerEdge R710 Sistema operacional Ubuntu Server 10,04; 1
servidor de backup Dell PowerEdge R710, Sistema operacional Ubuntu Server 10,04.
3.
13 de 25 09/09/2014 22:20
Cronograma
Esta é a parte do projeto que deve basear-se na duração do trabalho de pesquisa, enfatizando principalmente a data de início e término da pesquisa. as etapas devem ser cuidadosamente detalhadas e planejadas, levando-se em conta que,
no decorrer do processo, podem surgir imprevistos. Se as datas de início e fim não forem realísticas, é improvável que o projeto termine como planejado (CIN, 2001; MAISMONOGRAFIA, 2012).
Tabela - Cronograma
MÊS ETAPAS
Análise
Definição Definição (def. Apresentação
Delimitação Pesquisa Levantamento Planejamento Levantamento Escrever a Acertos após Entrega
Quinzena do da casos Projeto Codificação Testes da
do Tema Bibliográfica Teórico de Ações de Requisitos monografia apresentação final
ANO Problema metodologia de monografia
2012 uso)
Fevereiro 1a.
2a.
Março 1a.
2a.
Abril 1a.
2a.
Maio 1a.
2a.
Junho 1a.
2a.
Julho 1a.
2a.
Agosto 1a.
2a.
Setembro 1a.
2a.
Outubro 1a.
2a.
Novembro 1a.
2a.
Dezembro 1a.
2a.
4. Referencial Teórico
Neste capítulo serão apresentados todas as tecnologias, processos e conceitos estudados que foram escolhidos para o desenvolvimento do sistema.
1. Engenharia de Software
Segundo Junior (2012) e Pressman (2006), a engenharia de software abrange um conjunto de três elementos fundamentais: métodos, ferramentas e procedimentos. Estes elementos possibilitam ao gerente o controle do processo de
desenvolvimento do software e oferece ao profissional uma base para a construção de software de alta qualidade produtiva.
Ainda segundo Junior (2012), os métodos de engenharia de software proporcionam os detalhes de “como fazer” para construir o sistema de computador. As ferramentas desta disciplina proporcionam apoio automatizado ou semi-automatizado
aos métodos. E os procedimentos constituem o elo que mantém juntos os métodos e as ferramentas e possibilita o desenvolvimento racional e oportuno do software de computador.
As etapas que envolvem métodos, ferramentas e os procedimentos muitas das vezes são citadas como paradigmas da engenharia de software. Júnior (2012) relata que um paradigma de engenharia de software é escolhido tendo-se como
base a natureza do projeto e da aplicação, os métodos e as ferramentas a serem usados, os controles e os produtos que precisam ser entregues.
Segundo Pressman (1995), os paradigmas são os modelos de processos que possibilitam ao gerente controlar o processo de desenvolvimento de sistemas de software. Possibilita ainda que o desenvolvedor obtenha a base para produzir, de
maneira eficiente, software que satisfaça os requisitos preestabelecidos.
Sommerville (2003) define que um processo de software “é um conjunto de atividades e resultados associados que geram um produto de software”.
O processo é “Um arcabouço para as tarefas que são necessárias para construir softwares de alta qualidade” (PRESSMAN, 2006).
Paula Filho (2000) fala que um processo “é um conjunto de passos parcialmente ordenados, constituídos por atividades, métodos, práticas e transformações, usado para atingir uma meta que geralmente está associada a um ou mais
resultados concretos finais, que são os produtos da execução do processo”.
Ainda segundo Paula Filho (2000), na engenharia de software, processos podem ser definidos para atividades como desenvolvimento, manutenção, aquisição e contratação de software. Para cada um dos processos é possível definir
subprocessos, por exemplo, um processo de desenvolvimento abrange subprocessos de determinação dos requisitos, análise, desenho, implementação e testes. O ponto de partida para a arquitetura de um processo é a escolha de um modelo de
ciclo de vida no processo de desenvolvimento de software.
1. Arquitetura de Software
Segundo Ferreira e Girardi (2002), a construção de sistemas é composta de várias etapas que vão da análise de requisitos até sua implantação. A arquitetura da aplicação é um dos pontos críticos processo de desenvolvimento. Ela
representa o projeto global, solução computacional ao problema identificado na fase de análise de requisitos. Serve como uma organização do sistema, permitindo seu entendimento em termos de componentes, inter-relacionamentos e propriedades
consistentes ao longo do tempo e implementações.
A arquitetura é a peça-chave para se obter o controle intelectual sobre a complexidade de um sistema. Esse controle é provido pela abstração do sistema em questão que ela provê. No entanto, sua utilidade transcende a abstração do sistema. Por ser o conjunto das principais
decisões que regerão o desenvolvimento do sistema, a arquitetura também é peça fundamental em sua evolução, ditando assim o que pode e o que não pode ser feito durante todo o ciclo de vida do software. Além disso, essas decisões acabam sendo rastreáveis, permitindo
assim a avaliação de uma implementação do sistema a partir de sua arquitetura, ou ainda a avaliação da arquitetura a partir de uma implementação do sistema (BARBOSA, 2009, p. 2).
Bass et al apud Pressmman (2006) identificarão três razões pela qual a arquitetura de software é importante: representações da arquitetura de software constituem um facilitador da comunicação entre todas as partes interessadas (envolvidas) no
desenvolvimento de um sistema baseado em computador; a arquitetura destaca decisões iniciais de projeto que terão um impacto profundo em todo o trabalho de engenharia de software; a arquitetura constitui um modelo relativamente pequeno,
intelectualmente inteligível de como o sistema é estruturado e como seus componentes trabalham em conjunto.
Uma das principais habilitadoras em termos de proporcionar ganhos efetivos em agilidade e eficiência na manutenção e evolução dos sistemas de informação corporativos é a arquitetura de software, fator preponderante para ambientes
competitivos. Se for uma arquitetura de software inadequada, esta gera diversos problemas tecnológicos que refletem diretamente na gestão das organizações. Um dos principais deles é a forte integração que se estabelece entre: programas,
tabelas, filas de mensagens e demais componentes dos diversos sistemas de informação da corporação (SORDI et al, 2006).
2. Linguagem de Programação PHP
Segundo Welling e Thomsom (2005) “o PHP é uma linguagem de criação de scripts do lado do servidor que foi projetada especificamente para a Web”. O PHP é inserido em paginas HTML e é executado toda vez que a página for visitada. O
código é interpretado no servidor Web que gerará o HTML que será visto pelo usuário.
A linguagem PHP foi criada no outono de 1994 por Rasmus Lerdorf, era apenas um conjunto de scripts em Perl voltado à criação de páginas dinâmicas que Rasmus utilizava para monitorar o acesso ao seu currículo na internet. Com o tempo,
Rasmus foi aprimorando esse código e inserindo novas funcionalidades, escreveu uma implementação em C que possibilitava às pessoas desenvolverem de forma simples suas aplicações para a Web. O projeto foi chamado de PHP/FI – Personal
Home Page/Forms Interpreter e foi disponibilizado o código na web em 1995, para compartilhar com outras pessoas bem como receber ajuda e correção de bugs (DALL’OGLIO, 2009; MILANI, 2010; WELLING e THOMSOM, 2005).
A segunda versão do PHP foi lançada em novembro de 1997. No mesmo ano, dois estudantes Andi Gutmans e Zeev Suraski, utilizaram o PHP em um projeto acadêmico de comercio eletrônico, resolveram cooperar com Rasmus para
aprimorar o PHP. Para tanto, reescreveram todo o código-fonte, com base no PHP/FI 2, dando início ao PHP 3, Disponibilizado em junho de 1998. Nessa época o significado da sigla PHP mudou para PHP: Hypertext Preprocessor, retratando assim
a nova realidade de uma linguagem com propósitos mais amplos (DALL’OGLIO, 2009).
Com o objetivo de tornar o PHP mais poderoso, visando também projetos de grande complexidades, foi lançado o PHP 4, disponibilizado em 1999 e lançado oficialmente em 2000, trazendo muitas melhorias e novos recursos, como seções,
suporte a diversos servidores web, além da abstração de sua API, permitindo inclusive ser utilizado como linguagem para Shell script. Com a tecnologia estável, somente em 2004 foi lançada a nova versão do PHP (5.0), baseada em correções de
bugs encontradas nesse período e com várias outras características (DALL’OGLIO, 2009; MILANI, 2010).
São concorrentes diretos do PHP o ASP e JSP, tecnologias voltadas para o desenvolvimento Web. “A escolha da tecnologia para desenvolvimento de um projeto, deve ser feita com atenção e de acordo com a demanda do projeto. Para sites
e portais de internet, o PHP é tecnologia de ponta para atender praticamente todas as demandas” (MILANI, 2010, p. 22).
Milani (2010) entre o PHP e o ASP, o que ocorre é que diferente do PHP que tem licença gratuita, o ASP depende de um servidor Microsoft IIS para ser executado e não foi projetado desde o início para a web, sendo um meio de executar
Visual Basic no lado servidor, tornando-o mais lento que o PHP.
14 de 25 09/09/2014 22:20
Ainda segundo Milani (2010) tanto o PHP quanto o JSP (Java) são duas excelentes tecnologias e ambos com licença gratúita. Se dependesse apenas de recursos da linguagem, o Java tem mais vantagens sobre o PHP, tornando assim mais
evidentes em aplicações de grande porte e complexas. Agora para uso em aplicações web como sites e e-commerce em geral, destaca-se a facilidade do PHP para executar ações rapidamente, bem como sua simplicidade. É mais simples escrever
uma aplicação em PHP do que em Java (em termo de tamanho e complexidade de código-fonte).
Além dessas simples comparações do PHP com ASP e Java, deve ser levado em conta o mercado que conta com a maioria dos servidores de hospedagem e uso em domínio de internet voltada para o PHP, que continua crescendo (MILANI,
2010).
Welling e Thomson (2005), Destacam algumas vantagens do PHP em relação aos seus concorrentes diretos o Microsoft ASP.NET e Java Server Pages (JSP) e outras tecnologias como o Perl e ColdFusion. As vantagens listadas são as
seguintes: Alto desempenho; interfaces para muitos sistemas diferentes de banco de dados; bibliotecas integradas para muitas tarefas comuns da web; facilidade de aprender e utilizar; ótimo suporte orientado a objetos; portabilidade; disponibilidade
de código fonte; disponibilidade de suporte.
Considerando suas vantagens, que inclui velocidade, segurança, independência de plataforma e ser de distribuição gratuita, o PHP foi a linguagem de programação escolhida para desenvolvimento do SisCER.
3. Banco de Dados
Para entender o que é banco de dados é necessário saber a diferença entre dados e informação. Mesmo fazendo parte de um mesmo contexto e serem interligados, apresentam significados totalmente diferentes. Dados são, basicamente, um
conjunto alfanumérico ou imagem que não está agregado a nenhum conhecimento específico, tornando esse dado inutilizável para quem não souber em qual contexto ele está contido e o que exatamente ele representa, não podendo interpretá-lo.
Enquanto que Informação pode ser classificada como um segundo estágio que um dado pode percorrer. É a agregação de um determinado conhecimento a um dado. Uma informação pode ser interpretada, enquanto um dado apenas pode ser
visualizado ou lido (MILANI, 2010).
Ainda segundo Milani (2010) Banco de Dados seria uma coleção de dados, organizados em tabelas, referentes a um assunto ou propósito específico, com objetivo de organizar os dados de modo a tornar a vida dos usuários do negócio em
questão mais prática, precisa, rápida e confiável. Seu uso em aplicações traz dezenas de benefícios. É uma forma centralizadora de armazenar informações, padronizada pelo SQL(Structure Query Language) nome dado a linguagem responsável
pela interação com os dados armazenados na maioria dos bancos de dados relacionais, evitando que um projeto busque dados em um ou mais arquivos-texto separados e espalhados, cada um com formato distinto dependente de documentação de
seu criador.
1. MySQL
O MySQL é um poderoso e rápido sistema de gerenciamento de banco de dados relacional (Relational Database Management System - RDBMS). O servidor MySQL controla o acesso aos dados para assegurar que vários usuários possam
trabalhar com os dados ao mesmo tempo, fornecer acesso rápido aos dados e assegurar que somente usuários autorizados obtenham acesso. (WELLING e THOMSON, 2005).
Ainda segundo Welling e Thomson (2005), o MySQL é um servidor multiusuário e multiencadeado (ou multitheaded). Utiliza a linguagem de consulta padrão de banco de dados em todo o mundo SQL.
Segundo Pacievitch (2011), o MySQL foi criado na Suécia, por David Axmark, Allan Larsson e o finlandês Michael Widenius. Eles começaram o projeto em 1980. E segundo Welling e Thomson (2005), está disponível publicamente desde
1996. O MySQL ganhou o prêmio Journal Reader’s Choice Award Linux em várias ocasiões. Ele está disponível sob um esquema de licença dupla. Pode ser usado sob a licença Open Source (GPL – General Public License) gratuitamente, contanto
que cumpra os termos da licença. Caso queira distribuir uma aplicação não-GPL que inclua o MySQL, deverá comprar uma licença comercial.
Welling e Thomson (2005) fala que os principais concorrentes do MySQL são PostgreSQL, Microsoft SQL Server e Oracle e elenca as capacidades do MySQL que inclui: alto desempenho; baixo custo; fácil configuração e aprendizado;
portabilidade; disponibilidade do código-fonte; disponibilidade de suporte.
Conforme as descrições das facilidades e desempenho e de suas vantagens, o MySQL é o banco de dados escolhido para implementação do sistema proposto.
4. RUP (Rational Unified Process)
Segundo Kruchten (2003) o Rational Unified Process (Processo Racional Unificado) é um processo de engenharia de software que fornece uma abordagem disciplinada para assumir tarefas e responsabilidade dentro de uma organização de
desenvolvimento e tem como objetivo assegurar a produção de software dentro de prazo e orçamento previsíveis. Ele permite que a equipe se adapte às necessidades mutáveis de um projeto.
“Foi criado pela Rational Software Corporation e adquirido em fevereiro de 2003 pela IBM” (MARTINEZ, 2010, p.).
Segundo Booch et al (2005) o RUP faz uso de algumas das melhores práticas atuais para desenvolvimento de software de forma que pode ser adaptado a uma ampla variedade de projetos e empresas. Sua meta é permitir a produção de
software de alta qualidade e que atenda às necessidades do usuário final.
Ainda segundo Booch et al (2005) as características do processo são as seguintes: é um processo interativo; as atividades dão ênfase à criação e manutenção de modelos no lugar de documentos impressos; o desenvolvimento é centrado na
arquitetura; as atividades de desenvolvimento são orientadas por casos de uso; dispõe de suporte para técnicas orientadas a objetos, cada modelo é orientado a objeto; é um processo configurável; encoraja o controle de qualidade e o
gerenciamento de risco, contínuos e objetivos.
A Figura 2 mostra a arquitetura global do Rational Unified Process. Segundo Kruchten (2003) o processo tem duas estruturas, ou seja, duas dimensões. O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo
como se desdobra, é onde estão localizadas suas fases. Já o eixo vertical é onde estão localizadas suas disciplinas, representa os fluxos essenciais do processo, que agrupa logicamente as atividades por natureza.
Segundo Booch et al (2005) “uma fase é o período de tempo entre dois importantes marcos de progresso do processo em que um conjunto bem-definido de objetivos é alcançado”. Conforme mostra a Figura 2, o RUP é composto por quatro
fases que são elas: concepção, elaboração, construção e transição. A concepção e a elaboração abrangem as atividades criativas e de engenharia do ciclo de vida do desenvolvimento; a construção e a transição constituem sua produção.
Figura - Arquitetura Global do RUP
Fonte: RUP (2003)
Ainda segundo Booch et al (2005) em cada fase ocorrem várias interações. Essas interações representa o ciclo completo desde a captação dos requisitos até a implementação e teste, tendo como resultado um projeto executável. A versão
não precisa ter características de versão comercial. Pois, sua finalidade é fornecer base sólida para avaliar e testar, assim como uma linha de base uniforme para o próximo ciclo de desenvolvimento.
1. Desenvolvimento Iterativo
O desenvolvimento que segue o ciclo de vida do modelo cascata ocorre lineamente, desde a análise de requisitos, passando pela construção, teste de código e unidade, teste de subsistema e teste do sistema. O modelo cascata é
representado na Figura 3. O problema básico desta abordagem é que adia o risco de forma que torna caro desfazer erros de fases anteriores. A descoberta tardia de defeitos de construção tende a resultar em custos excedentes ou cancelamento do
projeto. A abordagem em cascata tende a mascarar os riscos reais para um projeto até que seja tarde para fazer qualquer coisa significante neles. (KRUCHTEN, 2003).
Figura - Ciclo de vida em cascata.
Fonte: RUP (2003)
Ainda segundo Kruchten (2003) O processo iterativo e incremental é uma alternativa para a abordagem em cascata.
RUP (2003) um projeto de desenvolvimento de software que usa o desenvolvimento iterativo tem ciclo de vida que consiste em várias interações. “Uma interação é um ciclo completo de desenvolvimento, resultando em uma versão (interna ou
externa) de um produto executável que constitui um subconjunto do produto final em desenvolvimento e cresce de modo incremental de uma iteração para outra para se tornar o sistema final” (BOOCH et al, 2005, pg.447). As interações nas fases de
iniciação e de elaboração se concentram nas atividades de gerenciamento, requisitos e design. As interações nas fases de construção se concentram no design, na implementação e no teste. E as iterações na fase de transição se concentram no
teste e na implantação.
RUP (2003) lista motivos que, geralmente, torna uma abordagem iterativa superior a uma abordagem linear ou em cascata, são eles: os riscos são reduzidos mais cedo, pois os elementos são integrados progressivamente; as táticas e os
requisitos variáveis são acomodados; a melhoria e o refinamento do produto são facilitados, resultando em um produto mais robusto; as organizações podem aprender a partir dessa abordagem e melhorar seus processos; a capacidade de
reutilização aumenta.
15 de 25 09/09/2014 22:20
2. Fases do RUP
Conforme Kruchten (2003) O RUP é composto de quatro fases. As quatro fases constituem um ciclo de desenvolvimento e produzem uma geração de software. Um produto de software é criado em um ciclo de desenvolvimento inicial. A
menos que o ciclo de vida do produto pare neste momento, um produto evoluirá em sua próxima geração por uma repetição da seqüência das fases concepção, elaboração, construção e transição, mas com ênfase diferente nas várias fases.
1. Concepção
Segundo Kruchten (2003) a meta da fase de concepção é alcançar o consentimento de todos os interessados nos objetivos do ciclo de vida para o projeto. Durante esta fase é estabelecida a extensão do software do projeto e limitação de
condições, inclusive um conceito operacional, critérios de aceitação e descrição do que é e não é pretendido estar no produto, casos de usos, estimativas de custo e riscos. Ou seja, é capturado o contexto e os critérios mais importantes e restrições
de forma que se possam derivar critérios de aceitação para o produto final.
No período de concepção é onde se estabelece uma visão para o sistema e se delimita o escopo do projeto. Que inclui caso de negócio, requisitos de alto nível e o plano de projeto inicial. No plano de projeto estará incluso critérios de
sucesso, a avaliação de risco, a estimativa de recursos necessários e um plano para a fase mostrando a programação dos principais marcos de progresso (BOOCH et al, 2005).
Segundo Kruchten (2003) o resultado da fase de concepção é a criação destes artefatos: um documento de visão que é uma visão geral dos requisitos centrais do projeto com as características fundamentais e as principais restrições; a
pesquisa do modelo de caso de uso que lista todos os casos de uso e atores que podem ser identificados nesta fase prematura; um glossário de projeto inicial; Um caso de uso do negócio que inclui contexto de negócio, critérios de sucesso
(projeção de renda, reconhecimento de mercado etc.) e previsão financeira; uma avaliação de risco inicial; um plano de projeto que mostra as fases e iterações.
2. Elaboração
Na elaboração, o propósito é analisar o domínio do problema, o estabelecimento da fundação de uma arquitetura sólida, o desenvolvimento do plano de projeto e eliminar os elementos de alto risco do projeto. As decisões de arquitetura
devem ser feitas com uma compreensão de todo os sistema, ou seja, sua extensão, funcionalidades principais e requisitos não funcionais, como requisitos de desempenho (BOOCH et al, 2005; KRUCHTEN, 2003).
De acordo com Booch et al (2005), esta fase envolve o arquiteto do sistema e o gerente de projeto como principais atores, bem como analistas, desenvolvedores, testadores, e outros. Normalmente envolve uma equipe maior que a
concepção.
Kruchten (2003) fala que nesta etapa, é construído um protótipo executável de arquitetura, em uma ou mais iterações, dependendo da extensão, tamanho, risco e novidade do projeto.
“No final da fase de elaboração, você examina o escopo e os objetivos detalhados do sistema, a escolha de arquitetura e a solução para os principais riscos além de decidir se deve prosseguir com a construção”. (BOOCH et al, 2005, p. 446).
Em resumo, os objetivos da fase de elaboração incluem: Definir, validar e delinear a arquitetura tão rápida quanto possível de ser realizada; Delinear a visão; Delinear um plano de alta-fidelidade para a fase de construção; Demonstrar que a
arquitetura de linha de base suportará esta visão, a um custo razoável num tempo razoável (KRUCHTEN, 2003).
3. Construção
Durante a fase de construção, é desenvolvido de maneira iterativa e incremental um produto completo, pronto para a transição aos usuários. Todos os componentes restantes e características são completamente testadas. Esta fase é, de
certo modo, um processo industrial no qual é colocada ênfase em gerenciar recursos e controlar operações para aperfeiçoar custos, prazos e qualidades (BOOCH et al, 2005; KRUCHTEN, 2003).
Segundo Kruchten (2003), os objetivos da fase de construção incluem: minimizar custos de desenvolvimento, aperfeiçoando recursos e evitando fragmentar e refazer desnecessário; alcançar a qualidade adequada tão rápido quanto possível
de ser realizada; alcançar versões úteis (alfa e beta) tão rápida quanto possível de ser realizada.
Estão envolvidos nesta fase o arquiteto de software, o gerente de projeto e os líderes da equipe de construção, bem como a equipe completa de desenvolvimento e teste. No final, decide-se se o software, ambiente e usuários estão prontos
para se tornarem operacionais (BOOCH et al, 2005).
4. Transição
Nesta fase, o software se torna disponível para o usuário, ou seja, a transição é levar o software à comunidade de usuário. Normalmente após a entrega ao usuário surgem questões que requerem o desenvolvimento de novos lançamentos,
correção de alguns problemas identificados ou concluir algumas características que foram adiadas. (BOOCH et al, 2005; KRUCHTEN, 2003).
Essa fase inicia-se quando uma linha base é madura bastante para ser distribuída no domínio de usuários finais, ou seja, uma versão beta do sistema. E se conclui quando a linha base de desenvolvimento alcança a versão completa.
Muitos esforços são empregados desenvolvendo documentação orientada a usuário, treinamento e suporte no uso inicial do sistema e reação da avaliação de usuário. Porém, neste momento do ciclo de vida, a avaliação do usuário deverá ser
limitada principalmente ao produto afinado, configuração, instalação e questões de utilidade (KRUCHTEN, 2003).
Segundo Booch et al (2005) no final da fase de transição, pode decidir se os objetivos do ciclo de vida do projeto foram alcançados e determinar se deverá iniciar outro ciclo de desenvolvimento.
5. Disciplinas do RUP
Como foi visto na Figura 2, o RUP é composto por nove disciplinas. Cada disciplina está um conjunto de artefatos correlacionados. Um artefato pode ser definido como um documento, relatório ou executável, que é produzido, manipulado ou
consumido. Uma atividade descreve as tarefas executadas pelos trabalhadores para criar ou modificar artefatos, juntamente com as técnicas e diretrizes para a realização de tarefas, possivelmente incluindo a utilização de ferramentas para ajudar a
automação de algumas das tarefas (BOOCH et al, 2005).
Ainda conforme Booch et al (2005) as nove disciplinas são:
1. Modelagem de negócio: Descreve a estrutura e a dinâmica da empresa.
2. Requisitos: Descreve os requisitos usando várias abordagens;
3. Análise e projeto: Descreve as várias visões da arquitetura.
4. Implementação: Leva em consideração o desenvolvimento do software, o teste da unidade e a integração.
5. Teste: Descreve casos de teste, procedimentos e medidas para acompanhamento de erros.
6. Entrega: Abrange listas, notas de versão, treinamento e outros aspectos da entrega de um aplicativo.
7. Gerenciamento da configuração: Controla as modificações e mantém a integridade dos artefatos do projeto e das atividades de gerenciamento.
8. Gerenciamento de projeto: Descreve vários estratégias para o trabalho com um processo iterativo.
9. Ambiente: Abrange a infra-estrutura necessária para o desenvolvimento do sistema.
6. UML (Unified Model Language)
A UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) é, indiscutivelmente, um padrão de mercado para modelagem de sistemas no paradigma da orientação a objetos (MELO, 2004).
A UML é uma linguagem padronizada que serve para a elaboração da estrutura de projetos de software, ou seja, é uma linguagem gráfica empregada para a visualização, a especificação, a construção e a documentação de artefatos que
façam uso de sistemas complexos de software. Ela muita expressiva, que abrange todas as visões necessárias ao desenvolvimento e implementação de softwares (BOOCH et al, 2005).
Para Fowler (2005) a UML “é uma família de anotações gráficas, apoiada por um metamodelo único, que ajuda na descrição e no projeto de sistemas de software, particularmente daqueles construídos utilizando o estilo orientado a objetos
(OO)”
Segundo Booch et al (2005) a UML Proporciona uma forma-padrão para a preparação de planos de arquitetura de projetos de sistemas, incluindo aspectos conceituais tais como processos de negócios e funções do sistema, além de itens
concretos como as classes escritas em determinada linguagem de programação, esquemas de bancos de dados e componentes de software reutilizáveis.
Ainda segundo Booch et al (2005) a modelagem é uma parte central de todas as atividades que levam à implantação de um bom software. Com a modelagem, podem ser construídos modelos para comunicar a estrutura e o comportamento
desejados do sistema. Construir modelos para visualizar e controlar a arquitetura dos sistemas. Construir modelos para compreender melhor o sistema que esta sendo elaborado, expondo oportunidades de simplificação e reaproveitamento é
possível, também, construir modelos para gerenciar riscos.
Apesar de ser perfeitamente utilizada em processo orientado a casos de usos, centrado na arquitetura, iterativo e incremental, a UML é independente do processo.
De acordo com Booch et al (2005), na UML existem treze tipos de diagramas. Um diagrama é a representação gráfica de um conjunto de elementos, geralmente representadas como gráficos de vértices (itens) e arcos (relacionamento). São
desenhados para permitir a visualização de um sistema sob diferentes perspectivas: nesse sentido, um diagrama constitui uma projeção de um determinado sistema. Um diagrama representa uma visão parcial dos elementos que compõem o
sistema.
Os trezes diagramas da UML são: Diagrama de classes, diagrama de objetos, diagrama de componentes, diagrama de estruturas compostas, diagrama de caso de uso, diagrama de sequências, diagrama de comunicações, diagrama de
gráficos de estados, diagrama de atividades, diagrama de implementação, diagrama de pacote, diagrama de temporização e diagrama de visão geral da interação.
16 de 25 09/09/2014 22:20
5. Proposta do Novo Sistema
Controlar todo o estoque de equipamentos para empréstimos e o gerenciamento de requisições dos técnicos de primeiro nível. Um sistema que seja possível visualizar quais ativos estão emprestados, disponíveis e em manutenção.
1. Descrição do Sistema Proposto
Criar um sistema disponível através da WEB, com acesso reservado apenas da empresa e por usuários com autenticação.
O sistema será de fácil uso, permitindo às pessoas seu manuseio de forma simples e prática. O SisCER terá na tela principal menus de acesso rápido às funcionalidades do sistema fazendo com que os funcionários encontre rápido os
equipamentos que precisam para fazer a requisição.
2. Resultados Esperados
Com a utilização do SisCER, espera-se que haja um controle maior sobre as solicitações de equipamentos, armazenando os dados necessários para a fácil localização dos mesmos. O sistema dará aos técnicos de primeiro nível uma visão
geral dos ativos de informática disponíveis para atendimento imediato, tornando o processo de empréstimo rápido e prático. Espera-se também, a melhora no controle de cobrança dos reservas feitas pelos técnicos de segundo nível, mesmo após o
fechamento da ordem de serviço, diminuindo o risco de perda.
É esperado que o sistema funcione de forma estável e que a interface seja simples e amigável. É também esperado, com a implantação desse sistema, que diminua o acumulo de papéis contendo as informações de empréstimos realizados
consequentemente agilizando o trabalho dos técnicos que irão utilizar as funcionalidades que o sistema proporciona.
3. Restrições do sistema proposto
O sistema estará disponível apenas para acesso via intranet, os usuários do sistema deverão estar devidamente autenticados com senhas de acesso para fazer qualquer tipo de transação utilizando o sistema de acordo com suas limitações
de perfil.
O técnico de primeiro nível, após logado, terá acesso para cadastrar as requisições e realizar consultas de equipamentos no ato da requisição. O técnico de segundo nível será capaz de cadastrar outros técnicos, cadastrar equipamentos,
cadastrar tipos de equipamentos, inserir, pesquisar e encerrar requisições. O técnico de segundo nível também terá acesso para gerar relatórios dos equipamentos.
4. Relação Custo x Benefícios: Análise de Viabilidade Econômica do Novo Sistema
O custo para o desenvolvimento desse projeto é considerado viável se for considerado os valores praticados pelo mercado, além do fato que com este sistema, as despesas com compra de novos equipamentos de informática para
substituição daqueles perdidos nas filiais, por, atualmente, não ter controle dos mesmos, serão evitados. Com isso, será possível a compra de novos equipamentos para aumentar o estoque de reservas.
5. Áreas Afetadas Pelo Novo Sistema
O novo sistema impactará em toda a empresa no sentido de ter um controle absoluto dos equipamentos de informática disponíveis para empréstimos, em alguns setores de forma mais direta. Como é o caso do setor de tecnologia da
informação que serão os únicos usuários do sistema e estes terão uma nova rotina de requisição e expedição dos equipamentos reserva para a matriz e filiais.
6. Banco de Dados
O banco de dados escolhido para o desenvolvimento do sistema SisCER foi O MySQL Server. Este Banco de dados, além de outras qualidades, demonstra um alto desempenho, alta disponibilidade, suporte transacional e de fácil manuseio
tornando assim uma combinação perfeita para o sistema proposto.
6. Documentação de Análise
Este capítulo mostra a documentação de análise usada para o desenvolvimento do sistema.
1. Visão Macro dos Atores
Eclipse (2008) fala que para entender totalmente o objetivo de um sistema, é preciso saber quem usará o sistema, ou seja, quem serão os Atores.
Os Atores constituem as entidades que interagem com o ambiente do sistema e pode ser tampo pessoas ou sistemas (de hardware ou software) que interagem com o sistema em desenvolvimento. Os Atores definem um papel particular e
17 de 25 09/09/2014 22:20
são sempre externos ao sistema. O sistema é descrito através de casos de uso que são executados por um número de atores (CASTRO, 2011).
Borba (2010) fala que os atores normalmente são representados por uma figura de um “stickman”. A Figura 4 mostra exemplos de atores:
Figura - Atores
Fonte: BORBA (2010)
2. Identificação dos Atores
No SisCer haverá dois perfis. O primeiro perfil será associado ao técnico de segundo nível e o segundo ao técnico de primeiro nível.
O técnico de segundo nível cadastrará novos técnicos, tanto de nível 01(um) como de nível 2(dois) e terá acessos as todas funcionalidades.
O perfil de técnico nível 01(um) só poderá registrar requisições e consultá-las.
3. Lista de Casos de Uso
Segundo Eclipse (2008) “Um caso de uso descreve o que o sistema tem que fazer para fornecer valor aos stakeholders. Ele define uma sequência de ações executadas pelo sistema que geram um resultado de valor observável para um ator
em particular”
Para Baesso (2004) “Casos de Uso são funcionalidades que o sistema realiza e que fornece um benefício a um ator específico”. São características dos Casos de Uso: Sempre iniciados por um ator; sempre retornam um resultado ao ator;
especifica uma funcionalidade completa
Casos de uso descrevem o que acontece dentro do sistema mostrando apenas o que o sistema faz, e não como (CASTRO, 2011).
No Sistema para Controle de Equipamentos Reserva (SisCER), foram utilizados 6 casos de uso, conforme descrito na Tabela 02:
Tabela - Casos de Uso

UC01 Realizar Login
UC02 Manter Técnico
UC03 Cadastrar Tipo de Equipamento
UC04 Manter Equipamento
UC05 Manter Requisição
UC06 Gerar Relatório
4. Diagrama de caso de uso
Madeira (2007) O diagrama de casos de uso é um diagrama da UML cujo objetivo é representar as necessidades (requisitos) do sistema que será desenvolvido.
O diagrama de Casos de Uso procura, por meio de uma linguagem simples, possibilitar a compreensão do comportamento externo do sistema por qualquer pessoa, tentando apresentar o sistema por intermédio de uma perspectiva do usuário. É dentre todos os diagramas da
UML, o mais abstrato e, portanto o mais flexível (GUEDES, 2008, p. 48).
Fowler et al (2000) relata que os diagramas de Casos de Uso fornecem a base da comunicação entre clientes e os desenvolvedores no planejamento do projeto. É um diagrama abstrato, pois fornece uma visão do sistema com os atores que
hora produzem informações para o sistema e por outro lado consomem informações do mesmo sistema.
Está representado na Figura 5 o diagrama de caso de uso do sistema que será desenvolvido.
Figura - Diagrama de Caso de Uso
5. Descrição detalhada dos Casos de Uso
A seguir, será apresentada a especificação de cada caso de uso proposto para o Sistema para Controle de Equipamento Reserva (SisCER), mencionado na Figura 5.
UC01 – Login
Tabela - Caso de Uso UC01 – Login
Nome UC01 – Login
Objetivo Realizar acesso ao sistema definido os níveis de perfil
Atores Técnico de primeiro e segundo nível.
Dados Consumidos Login e senha
Dados Produzidos Acesso ao sistema
Prioridade Alta
Pré-condições Possuir autorização e perfil de acesso
Pós-condições N/A
Fluxo Principal
Realizar login.
Ator Sistema
Inserir login e senha Validar dados do usuário: login e senha
Fluxo Alternativo 1
Erro: Dados incorretos
Ator Sistema
Inserir login e senha Validar dados: login e senha, dados não validados e
enviar mensagem de erro.
Verificar mensagem de erro Mensagem de erro informando que os dados estão

incorretos retorna à tela de login.
18 de 25 09/09/2014 22:20
UC02 – Manter Técnico
Tabela - Caso de Uso UC02 – Manter Técnico.

Nome UC02 – Manter Técnico
Objetivo Cadastrar Técnico.
Atores Técnico de segundo nível.
Dados Consumidos Nome, Login, Senha, Nível, Ramal e E-mail.
Dados Produzidos Cadastro de técnico.
Prioridade Alta
Pré-condições Possuir perfil de técnico de segundo nível e estar logado no sistema.
Fluxo Principal – Cadastrar Técnico
Cadastrar técnico.
Ator Sistema
Acessar página ‘cadastrar técnico’. Abrir formulário de cadastro de técnico
Inserir os dados: Nome, Login, Senha, Nível, Ramal,Recebe

e os dados inseridos, verifica se todos os dados
E-mail e clicar em cadastrar. foram preenchidos, se foram o sistema armazena-os
senão é exibida a mensagem: “Favor, preencher campo”.
Recebe a mensagem Exibir mensagem de cadastro realizado com sucesso. Se

aparecer mensagem de erro reinicie o processo.
Fluxo Alternativo 1 -
Alterar Técnico
Ator Sistema
Acessar a página de gerenciar técnico Exibir lista de técnicos cadastrados.
Clicar no botão alterar ao lado do técnico que Exibir dados do técnico escolhido
deseja realizar a alteração
Realizar a alteração desejada e clica em Recebe os dados inseridos, verifica se todos os dados
alterar foram preenchidos, se foram o sistema armazena-os
senão é exibido a mensagem “Favor, preencher campo”.
Receber mensagem Exibir mensagem de alteração realizada com sucesso. Se

Fluxo Alternativo 2
Alterar Senha
Ator Sistema
Acessar a página ‘gerenciar técnico’ Exibir lista de técnicos cadastrados.
Clicar no botão alterar senha ao lado do técnico Exibir formulário de alteração de senha.
que deseja realizar a alteração
Inserir os dados: Nova senha e Confirmar nova senha. Recebe os dados inseridos, verifica se todos os dados
foram preenchidos, se foram o sistema armazena-os
Receber mensagem Exibir mensagem de alteração realizada com ucesso. Se

Fluxo Alternativo 3
Erro: Favor, preencher campo
Ator Sistema
Inserir os dados: Nome, Login, Senha, Nível, Ramal, e Verificar dados: dados não preenchidos, enviar
E-mail. mensagem de erro.
Verificar mensagem de erro Mensagem de erro informando que faltam dados a serem
preenchidos e retorna à tela de cadastro.
UC03 – Cadastrar Tipo de Equipamento
Tabela - Caso de Uso UC03 – Cadastrar Tipo de Equipamento
Nome UC03 – Cadastrar Tipo de Equipamento
Objetivo Cadastrar Tipo de equipamento
Atores Técnico de segundo nível
Dados Consumidos Nome do tipo
Dados Produzidos Cadastro de tipo de equipamento
Prioridade Alta
Fluxo Principal – Criar tipo de Equipamento
Cadastrar tipo de equipamento
Ator Sistema
Acessar a página ‘Tipo Equipamento’. Exibir lista de equipamentos cadastrados
Inserir os dados: nome do tipo e clicar em Receber os dados inseridos, verifica se todos os dados
cadastrar. foram preenchidos, se foram o sistema armazena-os
Receber mensagem Exibir mensagem de cadastro realizado com sucesso. Se

Fluxo Alternativo 1
Erro: Favor, preencher campo
Ator Sistema
Inserir o dado: nome do tipo. Verificar dado: dado não preenchido, enviar mensagem
de erro.
Verificar mensagem de erro Mensagem de erro informando que o campo não foi
preenchido e retorna à tela de cadastro.
UC04 – Manter Equipamento
Tabela - Caso de Uso UC04 – Manter Equipamento
Nome UC04 – Manter Equipamento
Objetivo Cadastrar Equipamento.
Dados Consumidos Nome, Especificação, Tipo e Status.
Dados Produzidos Cadastro de Equipamento.
Prioridade Alta
Fluxo Principal – Cadastrar Equipamento
Cadastrar novo equipamento.
Ator Sistema
Acessar página ‘cadastrar equipamento’. Abrir formulário de cadastro de equipamento.
19 de 25 09/09/2014 22:20
Inserir os dados: Nome, Especificação, Tipo e Status Recebe os dados inseridos, verifica se todos os dados
e clicar em cadastrar. necessários foram preenchidos, se foram o sistema
armazena-os senão é exibido a mensagem “Favor,
preencher campo”.
Receber mensagem Exibir mensagem de cadastro realizado com

sucesso. Se aparecer mensagem de erro ou mensagem
‘para cadastrar um equipamento em uso, registre uma
requisição’ reinicie o processo.
Fluxo Alternativo 1 -
Editar equipamento
Ator Sistema
Acessar a página ‘gerenciar equipamentos’ Exibir lista de equipamentos cadastrados.
Clicar no botão editar ao lado do equipamento Verifica se o equipamento está em uso. Se estiver exibe a
que deseja realizar a alteração mensagem ‘Equipamento em uso. Impossível alterar’. Se
não exibi dados do equipamento escolhido.
Realiza as alterações desejadas Recebe os dados inseridos, verifica se todos os dados

necessários foram preenchidos, se foram o sistema
armazena-os senão é exibido a mensagem “Favor,
preencher campo”.

aparecer mensagem de erro ou mensagem: ‘para cadastrar
um equipamento em
uso, registre uma requisição’ reinicie o processo.
Fluxo Alternativo 2
Inativar Equipamento
Ator Sistema
Acessar a página de gerenciar equipamento Exibir lista de equipamentos cadastrados
Clicar no botão Inativar ao lado do equipamento que Recebe a solicitação e altera o status do
deseja alterar o status. equipamento.
Fluxo Alternativo 3
Erro: Equipamento em uso. Impossível alterar
Ator Sistema
Inserir os dados: Nome, Especificação, Tipo e Status. Verifica se o equipamento está em uso. Se estiver exibe a
mensagem ‘Equipamento em uso. Impossível alterar’.
Verificar mensagem de erro Mensagem de erro informando que o não é possível

cadastrar o equipamento e retorna à tela de cadastro.
UC05 – Manter Requisição
Tabela - Caso de Uso UC05 – Manter Requisição
Nome UC05– Manter Requisição
Objetivo Cadastrar Requisição
Atores Técnico de segundo e primeiro nível.
Dados Consumidos Técnico, Numero do Chamado, Nome do Usuário, Ramal, Setor, Loja, Data de
Empréstimo, Previsão de Entrega e Equipamento.
Dados Produzidos Cadastro de requisição.
Prioridade Alta
Pré-condições Estar logado no sistema.

RN - Técnico de primeiro nível apenas registra requisição e o de segundo nível
insere, atualiza e encerra requisição.
Fluxo Principal – Cadastra Requisição
Cadastrar nova requisição
Ator Sistema
Acessar o botão nova requisição Abrir formulário de cadastro de requisição.
Inserir os dados: Número do Chamado, Nome do Recebe os dados inseridos, verifica se todos os dados
usuário, Ramal, Setor, Loja, Data de Entrega e necessários foram preenchidos, se foram o sistema
Equipamento e clica em Cadastrar. armazena-os senão é exibido a mensagem “Favor,
preencher campo”.

Fluxo Alternativo – Atualizar Requisição
Atualizar Requisição
Ator Sistema
Acessar a página de requisições Exibir lista de requisições cadastradas.
Inserir o dado no campo observação na requisição que Verifica requisição selecionada e exibe mensagem de
deseja atualizar e clica em atualizar requisição confirmação ‘Deseja realmente atualizar esta requisição’.
Recebe mensagem e confirma alteração. Recebe os dados inseridos e atualiza requisição. Se

operação falhar, exibe mensagem ‘Falha ao atualizar
requisição’.
Clicar no botão alterar Armazenar os dados
Receber mensagem Exibir mensagem requisição atualizada com sucesso.
Fluxo Alternativo 2
Encerrar Requisição
Ator Sistema
Acessar a página de requisições Exibir lista de requisições cadastradas.
Clicar no botão encerrar requisição ao lado da requisição Recebe

que a solicitação e encerra requisição.
deseja encerrar.
Receber Mensagem Exibir mensagem de requisição encerrada com sucesso.
Fluxo Alternativo 3
Erro: Favor, preencher campo.
Ator Sistema
Inserir os dados: Número do Chamado, Nome do Verificar dados: dados não preenchidos, enviar mensagem
usuário, Ramal, Setor, Loja, Data de Entrega e de erro.
Equipamento.
Verificar mensagem de erro Mensagem de erro informando que faltam dados a serem
preenchidos e retorna à tela de cadastro
UC06 – Gerar Relatório
Tabela - Caso de Uso UC06 – Gerar Relatório
Nome UC06 – Gerar Relatório
Objetivo Gerar Relatório
20 de 25 09/09/2014 22:20
Dados Consumidos
Dados Produzidos Relatórios de acordo com o filtro
Prioridade Alta
Fluxo Principal – Gerar Relatório
Gerar relatório
Ator Sistema
Acessar a página de relatório. Exibir primeiro menu de filtro de relatórios
Escolher a opção de filtro: Todos os Equipamentos, Verificar a opção escolhida e exibir segundo menu de
Equipamentos Ativos e Equipamentos não Ativos e filtro de relatórios.
clicar no desejado.
Escolher a opção de filtro: Lista com tipos de Verificar a opção escolhida e gerar relatório de
equipamentos. equipamentos.
Receber Relatório Gera relatório para download. Se não houver dados

suficientes para gerar relatório é exibido à mensagem
“Dados insuficientes para gerar relatório”.
Fluxo Alternativo 1
Erro: Dados insuficientes para gerar relatório
Ator Sistema
Selecionar filtro. Verificar dados: processar relatório, caso não haja dados
suficientes para geração do relatório, enviar mensagem
de erro.
Verificar mensagem de erro Mensagem de erro informando que os dados são

insuficientes para gerar relatório.
6. Diagramas de Classes
Segundo Borba (2010) este é o diagrama mais importante da UML. Está no centro da sua arquitetura. Outros diagramas são elaborados a partir dele. É uma importante ferramenta para a documentação de sistema ou produto de software.
Segundo Fowler (2000), o diagrama de classes descreve os tipos de objetos e os tipos de relacionamentos estáticos existentes entre eles no sistema. As classes representam propriedades e comportamentos de um conjunto de objetos em um
sistema. Como essas classes não existem sozinhas, é importante a representação de seus relacionamentos.
A Figura 6 refere-se ao diagrama de classes onde são apresentadas todas as classes que compõem o Sistema para Gerenciamento de Equipamento Reserva (SisCER).
Figura - Diagrama de Classes
7. Modelo de Entidade-Relacionamento
A Figura 7 apresenta o Modelo de Entidade-Relacionamento (MER) onde ilustra as tabelas e suas relações, demonstrando a sua condição de dependência.
Figura - Modelo de Entidade de Relacionamento
8. Especificação das Tabelas
As tabelas a seguir, apresentam as especificações dos campos do MER do sistema proposto.
Tabela - Equipamento
EQUIPAMENTO
Relacio-
Campo Tipo namento Observação
CD_EQP INT(11) PK AUTO_INCREMENT
NM_EQP CHAR(50) NOT NULL
TX_ESP_EQP TEXT
CD_TIP INT(11) FK NOT NULL
CD_STT INT(11) FK NOT NULL
VL_ATV_EQP CHAR(1) NOT NULL
Tabela - Requisição
REQUISICAO
Relacio-
CD_RQS INT(11) PK AUTO_INCREMENT
CD_EQP INT(11) FK NOT NULL
CD_TCN INT(11) FK NOT NULL
CD_USU INT(11) FK NOT NULL
NR_CHM CHAR(15) NOT NULL
DT_INI_RQS DATE NOT NULL
DT_FIN_RQS DATE NOT NULL
VL_SIT_RQS CHAR(1) “E” OU “V”, NOT NULL
21 de 25 09/09/2014 22:20
TX_OBS_RQS TEXT
Tabela - Técnico
TECNICO
Relacio-
CD_TCN INT(11) PK AUTO_INCREMENT
NM_TCN CHAR(100) NOT NULL
TX_LGN_TCN CHAR(30) UNIQUE, NOT NULL
TX_SNH_TCN CHAR(15) NOT NULL
VL_NVL_TCN CHAR(1) NOT NULL
TX_RML_TCN CHAR(10)
TX_EML_TCN CHAR(100)
Tabela - Tipo
TIPO
Relacio-
CD_TIP INT(11) PK AUTO_INCREMENT
TX_DESC_TIP CHAR(50) NOT NULL
Tabela - Usuario
USUARIO
Relacio-
CD_USU INT(11) PK AUTO_INCREMENT
CD_LJA_STR INT(11) FK NOT NULL
NM_USU CHAR(100) NOT NULL
TX_RML_USU CHAR(10) NULL
Tabela - Status
STATUS
Relacio-
CD_STT INT(11) PK AUTO_INCREMENT
TX_DESC_STT CHAR(30) NOT NULL
Tabela - Setor
SETOR
Relacio-
CD_STR INT(11) PK AUTO_INCREMENT
NM_STR CHAR(100) NOT NULL
2.
Tabela - Loja
LOJA
Relacio-
CD_LJA INT(11) PK AUTO_INCREMENT
NM_LJA CHAR(100) NOT NULL
Tabela - Loja_Setor
LOJA_
SETOR
Relacio-
CD_LJA_STR INT(11) PK AUTO_INCREMENT
CD_LJA INT(11) FK NOT NULL
CD_STR INT(11) FK NOT NULL
9.
22 de 25 09/09/2014 22:20
Árvore do Sistema
Na figura 8 temos a estrutura do sistema representada em forma de árvore.
Figura - Árvore do Sistema
3.
4.
10. Especificação Técnica
1. Layout Das Principais Telas Da Aplicação
Na Figura 9 temos a tela de login do sistema, onde cada técnico deverá acessar com seu respectivo perfil, após ser cadastrado.
Figura - Tela de Login
Na figura 10 temos a tela principal do sistema, que é exibida após o técnico realizar o login.
Figura - Tela principal do sistema
Na figura 11 temos a tela de cadastro de requisição, nesta tela os dados da requisição deverão ser inseridos para que esta seja registrada.
Figura - Tela de cadastro de requisição
Na figura 12 é exibida a tela de consulta de requisições já cadastradas no sistema.
Figura - Tela de consulta de requisição
23 de 25 09/09/2014 22:20
1. Navegação
5. Logo abaixo na figura 13 é apresentada a tela de navegação do sistema:
Figura - Menu de navegação do sistema
12. Segurança Física e Lógica
A segurança física e lógica será baseada na política de segurança da empresa. Por tanto, para o devido funcionamento do sistema como garantia de disponibilidade, e a integridade das informações nele tratada, há a necessidade que política
de segurança interna esteja implantada e estabelecida para todos os usuários do SisCER.
1. Segurança Física
A Segurança física visa à disponibilidade do sistema. Dessa forma faz se necessário que os servidores de aplicações e de banco de dados estejam conectados em No-Breaks individuais, sala de servidores com ar-condicionado além de
acesso permitido somente as pessoas autorizadas.
Atualmente a empresa já conta com estes requisitos, além de existir um sistema de backup das informações que faz uma cópia dos dados diariamente e guardados em um terceiro servidor somente para este fim, em um lugar separado dos
outros servidores. A sala está equipada com rigoroso sistema de acesso.
2. Segurança Lógica
A Segurança lógica esta diretamente voltada ao controle de acesso do usuário ao sistema. O acesso ao sistema SisCER dar-se-á por meio de login e senha. O nível de acesso está limitado conforme os cargos. Usuário somente poderá utilizar
o sistema, estando previamente cadastrado.
Para evitar incidente na segurança, a empresa deverá adotar alguns padrões como: não permitir tentativas de obter acesso não autorizado ou colocar o sistema à prova; proibir que os usuários passem seus dados de acessos a outros
usuários. Para evitar acesso indevido todos os perfis devem finalizar a sessão ao termino do período de utilização do sistema.
7. Plano de Implantação
A empresa contratada faz uso de outros sistemas que utilizam as mesmas configurações do que iremos implantar, inclusive banco de dados MySQL. Sendo assim, não houve a necessidade de realizar configurações de Servidores. Feito
apenas as configurações de instalação do sistema SisCER nos servidores já existentes.
Foi realizado um treinamento com os funcionários que terão acesso ao sistema com duração de 4 horas, onde foram apresentadas todas as funcionalidades do sistema e como estas deverão ser aplicadas para substituir processos manuais.
O sistema terá um prazo de teste de 15 dias, período este onde serão observados erros apresentados pelo sistema, para que estes sejam corrigidos até o termino do período de testes.
1. Atividades Futuras
As atividades futuras estão voltadas para a inserção de mais funcionalidades que torne o sistema ainda melhor, como por exemplo, desenvolvimento de módulos para agendamento de equipamentos, incluir no sistema as opções para inativar
técnicos que deixaram a empresa ou que não tenham mais acesso ao sistema. Acrescentar “manter status” para que os técnicos estejam livres para acrescentar mais opções como, por exemplo, o status de agendado. Possibilitar que o técnico de
primeiro nível possa alterar alguns dados pessoais.
Criar um módulo para cadastrar usuários (cliente), setores e lojas a fim de obter relatórios estatísticos sobre empréstimos de equipamentos onde seja possível verificar quais lojas e setores ou usuário que mais solicitaram reservas.
Implementar no cadastro de equipamentos um campo onde seja possível gerar, automaticamente, um código identificador (Patrimônio) para cada produto cadastrado, proporcionando um controle maior sobre os mesmos. Tudo em função da
melhoria do sistema.
8. Conclusão
Visando o controle sobre os equipamentos de informática que estão no laboratório de informática da organização, foi desenvolvido o sistema SisCER (Sistema para controle de Equipamento Reserva).
O estudo realizado para este trabalho objetivou todo um cronograma que incluiu projetar, desenvolver e implantar o sistema. Durante o percurso do cronograma, foram decididas e escolhidas quais tecnologias seriam utilizadas e o
planejamento de ações que seriam utilizadas para o desenvolvimento do software.
Após levantar os requisitos, com base nos problemas enfrentados pela empresa, deu-se inicio a implementação do sistema, onde foram colocadas em prática as tecnologias escolhidas.
Na implantação foi realizado o treinamento dos funcionários que fariam uso do sistema, onde foi explanado todo o sistema. E incluído à sua rotina um novo processo que substituía aqueles feitos manualmente.
Com base no exposto, conclui-se que o projeto atingiu os objetivos esperados, pois o sistema possibilitou à empresa controlar todo seu estoque de equipamentos reservas, assim como o processo de empréstimo e sua localização,
automatizando o que antes era feito manualmente conforme os requisitos levantados na organização.
24 de 25 09/09/2014 22:20
9. Referências Bibliográficas
BAESSO, Milena Alexandre dos Santos. Diagrama de Caso de Uso e Diagrama de Sequência. Disponível em: <http://www.dmo.fee.unicamp.br/~henrique/cursoc++/diagrama.pdf>. Acessado em 21 de novembro de 2012.
BARBOSA, Guilherme Mauro Germoglio. Um Livro-texto para o Ensino de Projeto de Arquitetura de Software. Dissertação submetida à Coordenação do Curso de Pós-Graduação em Ciência da Computação da Universidade Federal de
Campina Grande. Disponível em: <http://docs.computacao.ufcg.edu.br/posgraduacao/dissertacoes/2009/Dissertacao_GuilhermeMauroGerrmoglioBarbosa.pdf>. Acessado em: 30 de outubro de 2012.
BERRY, Leonard L; PARASURAMAN A. Serviço de Marketing: Competindo através da qualidade. 3 ed. São Paulo: Maltese, 1995.
BEZERRA, Eduardo. Princípios de Análise e Projeto de Sistemas com UML: 8. ed. Rio de Janeiro: Elsevier, 2002.
BOOCH, Grady. RUMBAUGH, James. JACOBSON, Ivar. UML: guia do usuário. 2ª ed. Rio de Janeiro: Elsevier:2005.
BORBA, Gilmar Luiz de. Diagrama de Caso de Uso. Disponível em: <http://gilmarborba.com.br/?p=93>. Acessado em 21 de novembro de 2012.
BORBA, Gilmar Luiz de. Diagrama de Classes. Disponível em: <http://gilmarborba.com.br/?p=184>. Acessado em 21 de novembro de 2012.
CASTRO, Jaelson. Modelagem de Caso de Uso. Disponível em: <http://www.cin.ufpe.br/~if716/arquivos/8-CasodeUso.pdf>. Acessado em: 22 de novembro de 2012.
CIN. Desenvolvimento do Cronograma. Disponível em: < http://www.cin.ufpe.br/~if717/Pmbok2000/pmbok_v2p/wsp_6.4.html>. Acessado em 25 de outubro de 2012
DALL`OGLIO, Pablo. PHP: Programando com Orientação a Objetos. 2ª ed. São Paulo: Novatec, 2009.
ECLIPSE. Conceito: Ator. Disponível em <http://epf.eclipse.org/wikis/openuppt/openup_basic/guidances/concepts/actor,_zGqO0MDpEduTGJ8i4u8TMw.html>. Acessado em 22 de novembro de 2012.
FERREIRA, Steferson Lima Costa. GIRARDI, Rosário. ARQUITETURAS DE SOFTWARE BASEADAS EM AGENTES: DO NÍVEL GLOBAL AO DETALHADO. Universidade Federal do Maranhão. Departamento de Informática. Campus do
Bacangar s/n. Disponível em: <http://143.54.31.10/reic/edicoes/2002e2/tutoriais/ArquiteturasDeSoftwareBaseadasEmAgentes.pdf>. Acessado em 30 de outubro de 2012.
FOWLER, Martin. KENDALL, Scott. UML Essencial um breve guia para a linguagem – padrão de modelagem de objetos. 2a. edição. Porto Alegre : Bookman, 2000
FOWLER, Martin. UML essencial: um breve guia para a linguagem-padrão de modelagem de objetos. 3ª ed. Porto Alegre: Bookman, 2005.
GUEDES, Gilleanes T. A. UML : uma abordagem prática. 3ª ed. São Paulo : Novatec Editora, 2008.
GOMES, Adelino Duarte. Instituição e Institucionalistas. Disponível em: < http://www.fpce.uc.pt/nefog/conf/publicacoes/files/instinst >. Acessado em: 14 de outubro de 2012.
JUNIOR. Walter Martins Parreira. APOSTILA ENGENHARIA DE SOFTWARE. Disponível em:< http://www.waltenomartins.com.br/es_aps.pdf>. Acessado em: 14 de outubro de 2012.
KRUCHTEN, Philippe. Introdução ao RUP – Rational Unified Process. 2ª ed. Rio de Janeiro: Editora Ciência Moderna Ltda, 2003.
MADEIRA, Marcelo de Melo. Entendendo o Diagrama de Casos de Uso. Disponível em: <http://celodemelo.wordpress.com/2007/03/17/entendedo-o-diagrama-de-casos-de-uso/>. Acessado em 21 de novembro de 2012.
MAISMONOGRAFIA. Cronograma da Monografia. Disponível em: < http://www.maismonografia.com.br/cronograma.htm>. Acessado em 20 de novembro de 2012.
MARINHO, João Paulo Meira. Definição dos Objetivos. Disponível em: <http://www.scribd.com/doc/275547/DEFINICAO-DOS-OBJETIVOS >. Acessado em: 20 de Outubro de 2012.
MARTINEZ, Mariana. RUP (Rational Unified Process). Disponível em: http://www.infoescola.com/engenharia-de-software/rup/. Acessado em: 11 de novembro 2012.
MELO, Ana Cristina. Desenvolvendo aplicações com UML 2.0: do conceito à implementação. 2ª ed. Rio de Janeiro: Brasport, 2004.
MILANI, André. Construindo Aplicações Web com PHP e MySQL. 1ª ed. São Paulo. Novatec, 2010.
PACIEVITCH, Yuri. MySQL. Disponível em: < http://www.infoescola.com/informatica/mysql/ >. Acessado em 1 de novembro de 2012.
PAULA FILHO, Wilson de Pádua. Engenharia de Software: fundamentos, métodos e padrões. Disponível em: < http://www.analysts.com.br/download/UCB_ESW/EngenhariaSoftware_WilsonPadua.pdf>. Acessado em: 28 de outubro de 2012.
PFLEEGER, Shari Lawrence. Engenharia de Software: teoria e prática. 2. ed. São Paulo: Prentice Hall, 2004.
PRESSMAN, Roger S. Engenharia de Software – 3ª edição. São Paulo: Makron Books. 1995.
PRESSMAN, Roger S. Software Engineering – 6ª edição.São Paulo: McGraw-Hill, 2006.

RUP. Rational Unified Process, 2002. Disponível em: < http://www.wthreex.com/rup/manuals/intro/im_bp1.htm>. Acesso em: 11 de novembro 2012.
RUP. Rational Unified Process, 2002. Disponível em: <http://www.wthreex.com/rup/portugues/index.htm>. Acesso em: 11 de novembro 2012.
SOMMERVILLE, I. Engenharia de Software. 6 ed. São Paulo: Addison Wesley, 2003.
SORDI, José Osvaldo de. MARINHO, Bernadete de Lourdes Marinho. NAGY, Marcio. BENEFÍCIOS DA ARQUITETURA DE SOFTWARE ORIENTADA A SERVIÇOS PARA AS EMPRESAS: ANÁLISE DA EXPERIÊNCIA DO ABN AMRO BRASIL.
Revista de Gestão da Tecnologia e Sistemas de Informação. Vol.3, Nº. 1,2006, p.19-34. Disponível em: < http://www.revistasusp.sibi.usp.br/pdf/jistem/v3n1/03.pdf>. Acessado em 30 de outubro de 2012.
SILVA, Adilson Ferreira da. AZEVEDO, Marilia Macorin de. Arquitetura de Software: Uma Central para Gestão da execução de serviços. 2010. Disponível em: < http://ebookbrowse.com/arquitetura-de-software-pdf-d31066584>. Acessado em 28
de outubro de 2012.
WELLING, Luke; THOMSON, Laura. PHP e MySQL: Desenvolvimento Web. 3ª ed. Rio de Janeiro: Campus, 2005.
25 de 25 09/09/2014 22:20

Modelo TCC - Template PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Modelo TCC - Template PDF

Enviado por

Direitos autorais:

Formatos disponíveis

Modelo TCC - Template http://dc193.4shared.com/doc/fsPLDFFg/preview.

CURSO DE TECNÓLOGO EM SISTEMAS DE INFORMAÇÃO

José do Nascimento Sousa

Sistema para Controle de Equipamento Reserva – SisCER

José do Nascimento Sousa

Sistema para Controle de Equipamento Reserva – SisCER

Orientador: Prof. Especialista Guilherme Rodrigues de Oliveira

A Deus, por tudo que fez e faz na minha vida.

A minha família, base da minha vida.

Agradeço ao nosso orientador, que nos ajudou a desenvolver este trabalho.

Keywords: Information System. Information Technology. Control equipment

reserves. PHP. MySQL.

LISTA DE ABREVIATURAS E SIGLAS

API Application Programming Interface

ASP Active Server Pages

GPL General Public License

GPL General Public License

HTML HyperText Markup Language

JSP JavaServer Pages

LCD Liquid Cristal Display

MER Modelo de Entidade-Relacionamento

PDV Ponto de Vendas

PHP Hypertext Preprocessor

PHP/FI Personal Home Page/Forms Interpreter

RDBMS Relational Database Management System

RUP Rational Unified Process

SGBD Sistema Gerenciador de Banco de Dados

SisCER Sistema para Controle de Equipamento Reserva

SQL Structured Query Language

UML Unified Modeling Language

SQL Structured Query Language

UML Unified Modeling Language

O sistema, atualmente em uso, não permite um controle absoluto dos reservas.

através de uma ação clara e explícita (MARINHO 2007).

Controlar os equipamentos de informática reservas e as solicitações de requisições.

O primeiro capítulo refere-se ao contexto do trabalho, o tema, os objetivos da monografia em apresentação.

O segundo capítulo realiza a apresentação da empresa BIBMIX e seu ramo de negócio.

O sétimo capítulo descreve as atividades desempenhadas para a implantação do sistema na empresa.

Para o oitavo capítulo está registrada a conclusão do trabalho.

1. A Empresa e seu Negócio

O organograma da empresa BIGMIX está disposto da seguinte forma:

Figura - Organograma da Empresa

2. Descrição das Necessidades

3. Sistema de Informação Existente na Empresa

5. Ambiente Tecnológico Existente

2. Linguagem de Programação PHP

4. RUP (Rational Unified Process)

Figura - Arquitetura Global do RUP

Fonte: RUP (2003)

Figura - Ciclo de vida em cascata.

Fonte: RUP (2003)

Ainda conforme Booch et al (2005) as nove disciplinas são:

1. Modelagem de negócio: Descreve a estrutura e a dinâmica da empresa.

2. Requisitos: Descreve os requisitos usando várias abordagens;

3. Análise e projeto: Descreve as várias visões da arquitetura.

4. Implementação: Leva em consideração o desenvolvimento do software, o teste da unidade e a integração.

5. Teste: Descreve casos de teste, procedimentos e medidas para acompanhamento de erros.

9. Ambiente: Abrange a infra-estrutura necessária para o desenvolvimento do sistema.

6. UML (Unified Model Language)

5. Proposta do Novo Sistema

1. Descrição do Sistema Proposto

3. Restrições do sistema proposto

4. Relação Custo x Benefícios: Análise de Viabilidade Econômica do Novo Sistema