Você está na página 1de 25

Modelo TCC - Template

1 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

09/09/2014 22:20

Modelo TCC - Template

2 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

FACULDADE ALVORADA
CURSO DE TECNLOGO EM SISTEMAS DE INFORMAO

Jos do Nascimento Sousa


Eduardo Diniz

Sistema para Controle de Equipamento Reserva SisCER

Braslia-DF
2012
Jos do Nascimento Sousa
Eduardo Diniz

Sistema para Controle de Equipamento Reserva SisCER

Monografia apresentada a Faculdade Alvorada para a obteno do ttulo de Tecnlogo em Sistemas de Informao.

Orientador: Prof. Especialista Guilherme Rodrigues de Oliveira

09/09/2014 22:20

Modelo TCC - Template

3 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

Braslia-DF
2012

09/09/2014 22:20

Modelo TCC - Template

4 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

TERMO DE APROVAO

09/09/2014 22:20

Modelo TCC - Template

5 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

DEDICATRIA

Dedico este trabalho em especial milha famlia, s pessoas que considero minha segunda famlia, Dona Vera Lcia, Aleide Verlane e Alcilan, que estavam sempre me dando fora e motivao para seguir esta
caminhada.
(Jos do Nascimento)

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


A minha famlia, base da minha vida.
(Eduardo Diniz)

AGRADECIMENTOS

Primeiramente agradeo a Deus por todas as bnos que tem feito por mim.
Agradeo a meus pais Maria do Nascimento e Miguel Rodrigues, por acreditarem em mim e por ter feito de tudo para que, mesmo em momentos difceis, nunca desistir de estudar.
Agradeo ao nosso orientador, que nos ajudou a desenvolver este trabalho.
Agradeo tambm ao professor Joo Rebs pelas suas dicas em relao ao trabalho.
Agradeo aos meus colegas de classe que sempre foram muito prestativos em todos os aspectos.
(Jos do Nascimento)

Agradeo primeiramente ao meu Deus e Pai por estar presente em minha vida me dando fora para superar todos os obstculos nessa trajetria.
A minha famlia que foi fundamental nessa caminhada, em especial minha Me que sempre esteve ao meu lado me apoiando nos momentos que eu mais precisei.
Agradeo tambm aos meus verdadeiros amigos que fizeram parte desta etapa na minha vida e aos professores que estiveram presentes nos orientando e nos ensinado.
Enfim, agradeo a todos que de alguma forma ou de outra colaboraram e apoiaram para a concluso deste trabalho.
(Eduardo Diniz)

09/09/2014 22:20

Modelo TCC - Template

6 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

RESUMO

A necessidade de se ter um controle sobre bens e servios em poder da rea de TI (Tecnologia da Informao) de suma importncia para a empresa. Evitam-se gastos extras e a perda de disponibilidades de recursos. Para que seja
possvel este controle importante o uso de sistemas de informao para registrar as requisies e controle de uso. Sendo assim, o presente trabalho apresenta a implementao de um sistema para controle de equipamentos reservas.
Palavras-chave: Sistema de Informao. Tecnologia da Informao. Controle de equipamentos reservas. PHP. MySQL

09/09/2014 22:20

Modelo TCC - Template

7 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

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.

09/09/2014 22:20

Modelo TCC - Template

8 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

LISTA DE FIGURAS

09/09/2014 22:20

Modelo TCC - Template

9 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

LISTA DE TABELAS

09/09/2014 22:20

Modelo TCC - Template

10 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

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

Orientao 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 Informao

UC

Use Case

UML

Unified Modeling Language

XP

Extreme Programming

SQL

Structured Query Language

TB

Tera Byte

TI

Tecnologia da Informao

UC

Use Case

UML

Unified Modeling Language

09/09/2014 22:20

Modelo TCC - Template

11 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

SUMRIO

1.

09/09/2014 22:20

Modelo TCC - Template

12 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

Introduo

Para manter um atendimento ao cliente com eficincia e qualidade, necessrio que a empresa esteja preparada para contornar os problemas na hora certa. Uma empresa bem estruturada permite uma obteno de vantagens competitiva,
aumentando assim a satisfao do cliente pelos servios oferecidos (BERRY e PARASURAMAN, 1995).
Para atingir estes objetivos, so investidos recursos em sistemas de software para atender s reas de negcio. Deste modo, surge a importncia do alinhamento da TI (Tecnologia da Informao) aos negcios, cujo papel entregar solues
adequadas, nos prazos necessrios. 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 emprstimos. Pois, com esse sistema, os tcnicos de primeiro nvel
tero maior agilidade para consultar a disponibilidade dos equipamentos, proporcionando assim maior agilidade nas respostas ao cliente. E os tcnicos de segundo nvel tero um controle maior do fluxo de emprstimos assim como a localizao
dos emprestados.
1. Tema
O Sistema SisCER ser capaz de proporcionar um controle maior sobre equipamentos de informtica (impressoras, PDVs, nobreaks, estabilizadores, teclados, monitores, gavetas entre outros) que so solicitados para uso temporrio, pelo
usurio. O controle e as requisies de equipamentos reservas sero feitas via browser.

2. Justificativa

Tendo por princpio a necessidade de um controle dos equipamentos que esto sobre responsabilidade do laboratrio de informtica da empresa fictcia BIGMIX, h a necessidade de um sistema para controlar os emprstimos e o
armazenamento destes ativos e que possibilite o gerenciamento de requisies solicitadas pelos tcnicos da rea de Help Desk.

1. Formulao do Problema
1.
A empresa BIGMIX uma rede de supermercado do tipo fictcia com matriz situada na 403 Norte em Braslia, DF. na sede que se localiza o setor de tecnologia da informao. O laboratrio de informtica o responsvel por manter,
organizar e consertar equipamentos de TI. tambm o responsvel pelo controle, a guarda e a manuteno dos equipamentos reservas. Estes so usados para substituir, temporariamente, os equipamentos de clientes que esto em manuteno.
A dificuldade que o laboratrio de informtica est sofrendo para manter o controle de equipamentos reserva vem causando atrasos e falhas nas solicitaes, e tambm a perda de equipamentos nas filiais. O controle dos desses ativos so
feitos com anotaes em planilhas, mas, em muitos dos casos, essas so deixadas de lado, tornando difcil a localizao do equipamento.
O sistema, atualmente em uso, no permite um controle absoluto dos reservas.

4. Objetivos

Um objetivo pode ser definido como um propsito ou alvo que se pretende atingir, tambm pode ser chamado de objetivos, tudo aquilo que se deseja alcanar
atravs de uma ao clara e explcita (MARINHO 2007).

1. Objetivo Geral

Desenvolver um sistema utilizando o ambiente Web, permitindo o controle de equipamentos reserva pelo laboratrio de informtica e as solicitaes pelos tcnicos de suporte de primeiro nvel.

2. Objetivos Especficos

Controlar os equipamentos de informtica reservas e as solicitaes de requisies.


Realizar consultas de equipamentos reservas por tipo de equipamento (Estao, PDV, Balana, Gavetas, Teclados, Monitores, Nobreaks, Impressoras, entre outros.
Gerar relatrios dos equipamentos reservas que esto ativos ou no ativos podendo ser filtrados por tipo de equipamento.

5. Organizao do Trabalho

O primeiro captulo refere-se ao contexto do trabalho, o tema, os objetivos da monografia em apresentao.

O segundo captulo realiza a apresentao da empresa BIBMIX e seu ramo de negcio.

O terceiro captulo apresenta o cronograma das atividades de desenvolvimento dessa monografia, sinalizando os prazos para a finalizao do trabalho.
O quarto captulo descreve o referencial terico, todas as fontes de pesquisa de ferramentas que sero utilizadas para o desenvolvimento do sistema e escrita da monografia.
No quinto captulo, apresentada a proposta, a descrio, os resultados, as restries e as reas afetadas pelo sistema que ser desenvolvido.

No sexto captulo, a descrio e identificao dos atores, casos de uso. E as principais telas do sistema e suas funcionalidades so apresentadas.

O stimo captulo descreve as atividades desempenhadas para a implantao do sistema na empresa.

Para o oitavo captulo est registrada a concluso do trabalho.

No nono e ltimo captulo esto descritas todas as referncias bibliografias que do sustentao e base ao desenvolvimento deste trabalho.

2.

09/09/2014 22:20

Modelo TCC - Template

13 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

Anlise Institucional

A anlise institucional um produto social-histrico. Trata-se da concepo de histria da empresa (GOMES, 2006). Neste captulo trataremos da anlise institucional da empresa BIGMIX sua histria, seu ramo de negcio, com o propsito de
abstrair os conhecimentos necessrios para entender suas necessidades perante a construo de um novo sistema.

1. A Empresa e seu Negcio

A empresa BIGMIX uma rede de supermercado, com sede estabelecida em Braslia Asa Norte, com filiais em vrias localidades do Distrito Federal. A BIGMIX dispe de uma central de suporte ao usurio e de um laboratrio de
informtica localizado na 403 Norte.
A BIGMIX foi fundada em 1992, na 107 Norte. Em 1997 deu-se o incio do processo de expanso dos negcios erguendo um prdio na 402/403 Norte, onde hoje funciona a matriz da organizao, com inaugurao em 17 de Dezembro de
1998. Neste perodo foi aberto, tambm, 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 poltica de trabalhar com produtos de qualidade a preos baixos e uma ateno especial no bom atendimento, resultou numa experincia gratificante para a empresa: a fidelizao de clientes. Ao contrrio das grandes redes, a BIGMIX
visto como um supermercado de vizinhana, 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. Descrio das Necessidades

A atividade de levantamento de requisitos corresponde etapa de compreenso do problema, aplicada ao desenvolvimento de software (BEZERRA, 2002).
Para Pfleeger (2004), o levantamento e a anlise dos requisitos no 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 solicitaes e o controle de equipamentos administrados pelo laboratrio de informtica da instituio, que hoje feito da seguinte forma: O tcnico de primeiro nvel solicita por
telefone a requisio de um equipamento reserva e o tcnico de segundo nvel verifica se h disponibilidade de mquinas reserva, havendo a disponibilidade o tcnico encaminha o equipamento para o cliente, fazendo anotaes deste envio em
planilhas e nos chamados tcnicos. O fato que nem sempre so feitas essas anotaes. Muitas vezes o cliente finaliza o chamado sem que a reserva tenha sido devolvida para o laboratrio, fazendo com que os equipamentos fiquem retidos nas
lojas filiais.

3. Sistema de Informao Existente na Empresa

O atual software utilizado pela empresa um sistema de ordem de servio, onde possvel acompanhar todo o atendimento do chamado, controle de usurios, relatrios de chamados abertos e encerrados. O sistema tem um mdulo de
emprstimo, mas no usado por no 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 atualizaes, possibilitando uma maior interao entre o tcnico e o usurio.

4. Normas de Funcionamento

Para o devido funcionamento do sistema necessrio que o cliente registre uma ordem de servio no sistema de acompanhamento tcnico j existente na empresa. Aps realizado este procedimento, o tcnico de primeiro nvel realiza o
atendimento e verifica se h necessidade do envio do equipamento para o laboratrio. Se houver a necessidade do envio, o mesmo ter que registrar uma requisio de equipamento reserva no sistema SisCER e ser atendido pelo tcnico de
segundo nvel que registrar neste sistema o emprstimo 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 laboratrio e a requisio encerrada no sistema.
A ordem de servio aberta pelo cliente no sistema atual da empresa poder ser encerrada e a requisio no SisCER poder continuar aberta at a devoluo do equipamento para o laboratrio.

5. Ambiente Tecnolgico Existente

O ambiente tecnolgico 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 aplicaes Dell PowerEdge T100 com Sistema operacional Windows server 2003; 2 Servidor de Apalicao Dell PowerEdge 2800 com Sistema operacional Ubuntu Server 10.04; 1 servidor de aplicao 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.

09/09/2014 22:20

Modelo TCC - Template

14 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

Cronograma

Esta a parte do projeto que deve basear-se na durao do trabalho de pesquisa, enfatizando principalmente a data de incio e trmino 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 incio e fim no forem realsticas, improvvel que o projeto termine como planejado (CIN, 2001; MAISMONOGRAFIA, 2012).

Tabela - Cronograma

MS

ETAPAS

Quinzena
ANO
2012
Fevereiro

1a.

Maro

1a.

Definio
do
Problema

Delimitao
do Tema

Pesquisa
Bibliogrfica

Levantamento
Terico

Definio
da
metodologia

Planejamento
de Aes

Levantamento
de Requisitos

Anlise
(def.
casos
de
uso)

Escrever a
monografia

Projeto

Codificao

Testes

Apresentao
da
monografia

Acertos aps
apresentao

Entrega
final

2a.

2a.
Abril

1a.
2a.

Maio

1a.
2a.

Junho

1a.

Julho

1a.

Agosto

1a.

2a.

2a.

2a.
Setembro 1a.
2a.
Outubro

1a.
2a.

Novembro 1a.
2a.
Dezembro 1a.
2a.
4. Referencial Terico

Neste captulo sero 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 trs elementos fundamentais: mtodos, ferramentas e procedimentos. Estes elementos possibilitam ao gerente o controle do processo de
desenvolvimento do software e oferece ao profissional uma base para a construo de software de alta qualidade produtiva.
Ainda segundo Junior (2012), os mtodos 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 mtodos. E os procedimentos constituem o elo que mantm juntos os mtodos e as ferramentas e possibilita o desenvolvimento racional e oportuno do software de computador.
As etapas que envolvem mtodos, ferramentas e os procedimentos muitas das vezes so citadas como paradigmas da engenharia de software. Jnior (2012) relata que um paradigma de engenharia de software escolhido tendo-se como
base a natureza do projeto e da aplicao, os mtodos e as ferramentas a serem usados, os controles e os produtos que precisam ser entregues.
Segundo Pressman (1995), os paradigmas so 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 satisfaa 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 arcabouo para as tarefas que so necessrias para construir softwares de alta qualidade (PRESSMAN, 2006).
Paula Filho (2000) fala que um processo um conjunto de passos parcialmente ordenados, constitudos por atividades, mtodos, prticas e transformaes, usado para atingir uma meta que geralmente est associada a um ou mais
resultados concretos finais, que so os produtos da execuo do processo.
Ainda segundo Paula Filho (2000), na engenharia de software, processos podem ser definidos para atividades como desenvolvimento, manuteno, aquisio e contratao de software. Para cada um dos processos possvel definir
subprocessos, por exemplo, um processo de desenvolvimento abrange subprocessos de determinao dos requisitos, anlise, desenho, implementao 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 construo de sistemas composta de vrias etapas que vo da anlise de requisitos at sua implantao. A arquitetura da aplicao um dos pontos crticos processo de desenvolvimento. Ela
representa o projeto global, soluo computacional ao problema identificado na fase de anlise de requisitos. Serve como uma organizao do sistema, permitindo seu entendimento em termos de componentes, inter-relacionamentos e propriedades
consistentes ao longo do tempo e implementaes.

A arquitetura a pea-chave para se obter o controle intelectual sobre a complexidade de um sistema. Esse controle provido pela abstrao do sistema em questo que ela prov. No entanto, sua utilidade transcende a abstrao do sistema. Por ser o conjunto das principais
decises que regero o desenvolvimento do sistema, a arquitetura tambm pea fundamental em sua evoluo, ditando assim o que pode e o que no pode ser feito durante todo o ciclo de vida do software. Alm disso, essas decises acabam sendo rastreveis, permitindo
assim a avaliao de uma implementao do sistema a partir de sua arquitetura, ou ainda a avaliao da arquitetura a partir de uma implementao do sistema (BARBOSA, 2009, p. 2).

Bass et al apud Pressmman (2006) identificaro trs razes pela qual a arquitetura de software importante: representaes da arquitetura de software constituem um facilitador da comunicao entre todas as partes interessadas (envolvidas) no
desenvolvimento de um sistema baseado em computador; a arquitetura destaca decises iniciais de projeto que tero um impacto profundo em todo o trabalho de engenharia de software; a arquitetura constitui um modelo relativamente pequeno,
intelectualmente inteligvel 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 eficincia na manuteno e evoluo dos sistemas de informao corporativos a arquitetura de software, fator preponderante para ambientes
competitivos. Se for uma arquitetura de software inadequada, esta gera diversos problemas tecnolgicos que refletem diretamente na gesto das organizaes. Um dos principais deles a forte integrao que se estabelece entre: programas,
tabelas, filas de mensagens e demais componentes dos diversos sistemas de informao da corporao (SORDI et al, 2006).

2. Linguagem de Programao PHP

Segundo Welling e Thomsom (2005) o PHP uma linguagem de criao 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 pgina for visitada. O
cdigo interpretado no servidor Web que gerar o HTML que ser visto pelo usurio.
A linguagem PHP foi criada no outono de 1994 por Rasmus Lerdorf, era apenas um conjunto de scripts em Perl voltado criao de pginas dinmicas que Rasmus utilizava para monitorar o acesso ao seu currculo na internet. Com o tempo,
Rasmus foi aprimorando esse cdigo e inserindo novas funcionalidades, escreveu uma implementao em C que possibilitava s pessoas desenvolverem de forma simples suas aplicaes para a Web. O projeto foi chamado de PHP/FI Personal
Home Page/Forms Interpreter e foi disponibilizado o cdigo na web em 1995, para compartilhar com outras pessoas bem como receber ajuda e correo de bugs (DALLOGLIO, 2009; MILANI, 2010; WELLING e THOMSOM, 2005).
A segunda verso do PHP foi lanada em novembro de 1997. No mesmo ano, dois estudantes Andi Gutmans e Zeev Suraski, utilizaram o PHP em um projeto acadmico de comercio eletrnico, resolveram cooperar com Rasmus para
aprimorar o PHP. Para tanto, reescreveram todo o cdigo-fonte, com base no PHP/FI 2, dando incio 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 propsitos mais amplos (DALLOGLIO, 2009).
Com o objetivo de tornar o PHP mais poderoso, visando tambm projetos de grande complexidades, foi lanado o PHP 4, disponibilizado em 1999 e lanado oficialmente em 2000, trazendo muitas melhorias e novos recursos, como sees,
suporte a diversos servidores web, alm da abstrao de sua API, permitindo inclusive ser utilizado como linguagem para Shell script. Com a tecnologia estvel, somente em 2004 foi lanada a nova verso do PHP (5.0), baseada em correes de
bugs encontradas nesse perodo e com vrias outras caractersticas (DALLOGLIO, 2009; MILANI, 2010).
So 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 ateno 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 licena gratuita, o ASP depende de um servidor Microsoft IIS para ser executado e no foi projetado desde o incio para a web, sendo um meio de executar
Visual Basic no lado servidor, tornando-o mais lento que o PHP.

09/09/2014 22:20

Modelo TCC - Template

15 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

Ainda segundo Milani (2010) tanto o PHP quanto o JSP (Java) so duas excelentes tecnologias e ambos com licena gratita. Se dependesse apenas de recursos da linguagem, o Java tem mais vantagens sobre o PHP, tornando assim mais
evidentes em aplicaes de grande porte e complexas. Agora para uso em aplicaes web como sites e e-commerce em geral, destaca-se a facilidade do PHP para executar aes rapidamente, bem como sua simplicidade. mais simples escrever
uma aplicao em PHP do que em Java (em termo de tamanho e complexidade de cdigo-fonte).
Alm dessas simples comparaes 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 domnio de internet voltada para o PHP, que continua crescendo (MILANI,
2010).
Welling e Thomson (2005), Destacam algumas vantagens do PHP em relao aos seus concorrentes diretos o Microsoft ASP.NET e Java Server Pages (JSP) e outras tecnologias como o Perl e ColdFusion. As vantagens listadas so 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 cdigo fonte; disponibilidade de suporte.
Considerando suas vantagens, que inclui velocidade, segurana, independncia de plataforma e ser de distribuio gratuita, o PHP foi a linguagem de programao escolhida para desenvolvimento do SisCER.

3. Banco de Dados

Para entender o que banco de dados necessrio saber a diferena entre dados e informao. Mesmo fazendo parte de um mesmo contexto e serem interligados, apresentam significados totalmente diferentes. Dados so, basicamente, um
conjunto alfanumrico ou imagem que no est agregado a nenhum conhecimento especfico, tornando esse dado inutilizvel para quem no souber em qual contexto ele est contido e o que exatamente ele representa, no podendo interpret-lo.
Enquanto que Informao pode ser classificada como um segundo estgio que um dado pode percorrer. a agregao de um determinado conhecimento a um dado. Uma informao pode ser interpretada, enquanto um dado apenas pode ser
visualizado ou lido (MILANI, 2010).
Ainda segundo Milani (2010) Banco de Dados seria uma coleo de dados, organizados em tabelas, referentes a um assunto ou propsito especfico, com objetivo de organizar os dados de modo a tornar a vida dos usurios do negcio em
questo mais prtica, precisa, rpida e confivel. Seu uso em aplicaes traz dezenas de benefcios. uma forma centralizadora de armazenar informaes, padronizada pelo SQL(Structure Query Language) nome dado a linguagem responsvel
pela interao 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 documentao de
seu criador.

1. MySQL

O MySQL um poderoso e rpido sistema de gerenciamento de banco de dados relacional (Relational Database Management System - RDBMS). O servidor MySQL controla o acesso aos dados para assegurar que vrios usurios possam
trabalhar com os dados ao mesmo tempo, fornecer acesso rpido aos dados e assegurar que somente usurios autorizados obtenham acesso. (WELLING e THOMSON, 2005).
Ainda segundo Welling e Thomson (2005), o MySQL um servidor multiusurio e multiencadeado (ou multitheaded). Utiliza a linguagem de consulta padro de banco de dados em todo o mundo SQL.
Segundo Pacievitch (2011), o MySQL foi criado na Sucia, por David Axmark, Allan Larsson e o finlands Michael Widenius. Eles comearam o projeto em 1980. E segundo Welling e Thomson (2005), est disponvel publicamente desde
1996. O MySQL ganhou o prmio Journal Readers Choice Award Linux em vrias ocasies. Ele est disponvel sob um esquema de licena dupla. Pode ser usado sob a licena Open Source (GPL General Public License) gratuitamente, contanto
que cumpra os termos da licena. Caso queira distribuir uma aplicao no-GPL que inclua o MySQL, dever comprar uma licena comercial.
Welling e Thomson (2005) fala que os principais concorrentes do MySQL so PostgreSQL, Microsoft SQL Server e Oracle e elenca as capacidades do MySQL que inclui: alto desempenho; baixo custo; fcil configurao e aprendizado;
portabilidade; disponibilidade do cdigo-fonte; disponibilidade de suporte.
Conforme as descries das facilidades e desempenho e de suas vantagens, o MySQL o banco de dados escolhido para implementao 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 organizao de
desenvolvimento e tem como objetivo assegurar a produo de software dentro de prazo e oramento previsveis. Ele permite que a equipe se adapte s necessidades mutveis 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 prticas atuais para desenvolvimento de software de forma que pode ser adaptado a uma ampla variedade de projetos e empresas. Sua meta permitir a produo de
software de alta qualidade e que atenda s necessidades do usurio final.
Ainda segundo Booch et al (2005) as caractersticas do processo so as seguintes: um processo interativo; as atividades do nfase criao e manuteno de modelos no lugar de documentos impressos; o desenvolvimento centrado na
arquitetura; as atividades de desenvolvimento so orientadas por casos de uso; dispe de suporte para tcnicas orientadas a objetos, cada modelo orientado a objeto; um processo configurvel; encoraja o controle de qualidade e o
gerenciamento de risco, contnuos e objetivos.
A Figura 2 mostra a arquitetura global do Rational Unified Process. Segundo Kruchten (2003) o processo tem duas estruturas, ou seja, duas dimenses. O eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida do processo
como se desdobra, onde esto localizadas suas fases. J o eixo vertical onde esto localizadas suas disciplinas, representa os fluxos essenciais do processo, que agrupa logicamente as atividades por natureza.
Segundo Booch et al (2005) uma fase o perodo de tempo entre dois importantes marcos de progresso do processo em que um conjunto bem-definido de objetivos alcanado. Conforme mostra a Figura 2, o RUP composto por quatro
fases que so elas: concepo, elaborao, construo e transio. A concepo e a elaborao abrangem as atividades criativas e de engenharia do ciclo de vida do desenvolvimento; a construo e a transio constituem sua produo.

Figura - Arquitetura Global do RUP


Fonte: RUP (2003)

Ainda segundo Booch et al (2005) em cada fase ocorrem vrias interaes. Essas interaes representa o ciclo completo desde a captao dos requisitos at a implementao e teste, tendo como resultado um projeto executvel. A verso
no precisa ter caractersticas de verso comercial. Pois, sua finalidade fornecer base slida para avaliar e testar, assim como uma linha de base uniforme para o prximo ciclo de desenvolvimento.
1. Desenvolvimento Iterativo

O desenvolvimento que segue o ciclo de vida do modelo cascata ocorre lineamente, desde a anlise de requisitos, passando pela construo, teste de cdigo e unidade, teste de subsistema e teste do sistema. O modelo cascata
representado na Figura 3. O problema bsico desta abordagem que adia o risco de forma que torna caro desfazer erros de fases anteriores. A descoberta tardia de defeitos de construo 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 vrias interaes. Uma interao um ciclo completo de desenvolvimento, resultando em uma verso (interna ou
externa) de um produto executvel que constitui um subconjunto do produto final em desenvolvimento e cresce de modo incremental de uma iterao para outra para se tornar o sistema final (BOOCH et al, 2005, pg.447). As interaes nas fases de
iniciao e de elaborao se concentram nas atividades de gerenciamento, requisitos e design. As interaes nas fases de construo se concentram no design, na implementao e no teste. E as iteraes na fase de transio se concentram no
teste e na implantao.
RUP (2003) lista motivos que, geralmente, torna uma abordagem iterativa superior a uma abordagem linear ou em cascata, so eles: os riscos so reduzidos mais cedo, pois os elementos so integrados progressivamente; as tticas e os
requisitos variveis so acomodados; a melhoria e o refinamento do produto so facilitados, resultando em um produto mais robusto; as organizaes podem aprender a partir dessa abordagem e melhorar seus processos; a capacidade de
reutilizao aumenta.

09/09/2014 22:20

Modelo TCC - Template

16 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

2. Fases do RUP

Conforme Kruchten (2003) O RUP composto de quatro fases. As quatro fases constituem um ciclo de desenvolvimento e produzem uma gerao 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 prxima gerao por uma repetio da seqncia das fases concepo, elaborao, construo e transio, mas com nfase diferente nas vrias fases.

1. Concepo

Segundo Kruchten (2003) a meta da fase de concepo alcanar o consentimento de todos os interessados nos objetivos do ciclo de vida para o projeto. Durante esta fase estabelecida a extenso do software do projeto e limitao de
condies, inclusive um conceito operacional, critrios de aceitao e descrio do que e no pretendido estar no produto, casos de usos, estimativas de custo e riscos. Ou seja, capturado o contexto e os critrios mais importantes e restries
de forma que se possam derivar critrios de aceitao para o produto final.
No perodo de concepo onde se estabelece uma viso para o sistema e se delimita o escopo do projeto. Que inclui caso de negcio, requisitos de alto nvel e o plano de projeto inicial. No plano de projeto estar incluso critrios de
sucesso, a avaliao de risco, a estimativa de recursos necessrios e um plano para a fase mostrando a programao dos principais marcos de progresso (BOOCH et al, 2005).
Segundo Kruchten (2003) o resultado da fase de concepo a criao destes artefatos: um documento de viso que uma viso geral dos requisitos centrais do projeto com as caractersticas fundamentais e as principais restries; 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 glossrio de projeto inicial; Um caso de uso do negcio que inclui contexto de negcio, critrios de sucesso
(projeo de renda, reconhecimento de mercado etc.) e previso financeira; uma avaliao de risco inicial; um plano de projeto que mostra as fases e iteraes.

2. Elaborao

Na elaborao, o propsito analisar o domnio do problema, o estabelecimento da fundao de uma arquitetura slida, o desenvolvimento do plano de projeto e eliminar os elementos de alto risco do projeto. As decises de arquitetura
devem ser feitas com uma compreenso de todo os sistema, ou seja, sua extenso, funcionalidades principais e requisitos no 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
concepo.
Kruchten (2003) fala que nesta etapa, construdo um prottipo executvel de arquitetura, em uma ou mais iteraes, dependendo da extenso, tamanho, risco e novidade do projeto.
No final da fase de elaborao, voc examina o escopo e os objetivos detalhados do sistema, a escolha de arquitetura e a soluo para os principais riscos alm de decidir se deve prosseguir com a construo. (BOOCH et al, 2005, p. 446).
Em resumo, os objetivos da fase de elaborao incluem: Definir, validar e delinear a arquitetura to rpida quanto possvel de ser realizada; Delinear a viso; Delinear um plano de alta-fidelidade para a fase de construo; Demonstrar que a
arquitetura de linha de base suportar esta viso, a um custo razovel num tempo razovel (KRUCHTEN, 2003).

3. Construo

Durante a fase de construo, desenvolvido de maneira iterativa e incremental um produto completo, pronto para a transio aos usurios. Todos os componentes restantes e caractersticas so completamente testadas. Esta fase , de
certo modo, um processo industrial no qual colocada nfase em gerenciar recursos e controlar operaes para aperfeioar custos, prazos e qualidades (BOOCH et al, 2005; KRUCHTEN, 2003).
Segundo Kruchten (2003), os objetivos da fase de construo incluem: minimizar custos de desenvolvimento, aperfeioando recursos e evitando fragmentar e refazer desnecessrio; alcanar a qualidade adequada to rpido quanto possvel
de ser realizada; alcanar verses teis (alfa e beta) to rpida quanto possvel de ser realizada.
Esto envolvidos nesta fase o arquiteto de software, o gerente de projeto e os lderes da equipe de construo, bem como a equipe completa de desenvolvimento e teste. No final, decide-se se o software, ambiente e usurios esto prontos
para se tornarem operacionais (BOOCH et al, 2005).

4. Transio

Nesta fase, o software se torna disponvel para o usurio, ou seja, a transio levar o software comunidade de usurio. Normalmente aps a entrega ao usurio surgem questes que requerem o desenvolvimento de novos lanamentos,
correo de alguns problemas identificados ou concluir algumas caractersticas que foram adiadas. (BOOCH et al, 2005; KRUCHTEN, 2003).
Essa fase inicia-se quando uma linha base madura bastante para ser distribuda no domnio de usurios finais, ou seja, uma verso beta do sistema. E se conclui quando a linha base de desenvolvimento alcana a verso completa.
Muitos esforos so empregados desenvolvendo documentao orientada a usurio, treinamento e suporte no uso inicial do sistema e reao da avaliao de usurio. Porm, neste momento do ciclo de vida, a avaliao do usurio dever ser
limitada principalmente ao produto afinado, configurao, instalao e questes de utilidade (KRUCHTEN, 2003).
Segundo Booch et al (2005) no final da fase de transio, pode decidir se os objetivos do ciclo de vida do projeto foram alcanados 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, relatrio ou executvel, que produzido, manipulado ou
consumido. Uma atividade descreve as tarefas executadas pelos trabalhadores para criar ou modificar artefatos, juntamente com as tcnicas e diretrizes para a realizao de tarefas, possivelmente incluindo a utilizao de ferramentas para ajudar a
automao de algumas das tarefas (BOOCH et al, 2005).
Ainda conforme Booch et al (2005) as nove disciplinas so:
1. Modelagem de negcio: Descreve a estrutura e a dinmica da empresa.
2. Requisitos: Descreve os requisitos usando vrias abordagens;
3. Anlise e projeto: Descreve as vrias vises da arquitetura.
4. Implementao: Leva em considerao o desenvolvimento do software, o teste da unidade e a integrao.
5. Teste: Descreve casos de teste, procedimentos e medidas para acompanhamento de erros.
6. Entrega: Abrange listas, notas de verso, treinamento e outros aspectos da entrega de um aplicativo.
7. Gerenciamento da configurao: Controla as modificaes e mantm a integridade dos artefatos do projeto e das atividades de gerenciamento.
8. Gerenciamento de projeto: Descreve vrios estratgias para o trabalho com um processo iterativo.
9. Ambiente: Abrange a infra-estrutura necessria para o desenvolvimento do sistema.
6. UML (Unified Model Language)

A UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) , indiscutivelmente, um padro de mercado para modelagem de sistemas no paradigma da orientao a objetos (MELO, 2004).
A UML uma linguagem padronizada que serve para a elaborao da estrutura de projetos de software, ou seja, uma linguagem grfica empregada para a visualizao, a especificao, a construo e a documentao de artefatos que
faam uso de sistemas complexos de software. Ela muita expressiva, que abrange todas as vises necessrias ao desenvolvimento e implementao de softwares (BOOCH et al, 2005).
Para Fowler (2005) a UML uma famlia de anotaes grficas, apoiada por um metamodelo nico, que ajuda na descrio e no projeto de sistemas de software, particularmente daqueles construdos utilizando o estilo orientado a objetos
(OO)
Segundo Booch et al (2005) a UML Proporciona uma forma-padro para a preparao de planos de arquitetura de projetos de sistemas, incluindo aspectos conceituais tais como processos de negcios e funes do sistema, alm de itens
concretos como as classes escritas em determinada linguagem de programao, esquemas de bancos de dados e componentes de software reutilizveis.
Ainda segundo Booch et al (2005) a modelagem uma parte central de todas as atividades que levam implantao de um bom software. Com a modelagem, podem ser construdos 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 simplificao e reaproveitamento
possvel, tambm, 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 representao grfica de um conjunto de elementos, geralmente representadas como grficos de vrtices (itens) e arcos (relacionamento). So
desenhados para permitir a visualizao de um sistema sob diferentes perspectivas: nesse sentido, um diagrama constitui uma projeo de um determinado sistema. Um diagrama representa uma viso parcial dos elementos que compem o
sistema.
Os trezes diagramas da UML so: Diagrama de classes, diagrama de objetos, diagrama de componentes, diagrama de estruturas compostas, diagrama de caso de uso, diagrama de sequncias, diagrama de comunicaes, diagrama de
grficos de estados, diagrama de atividades, diagrama de implementao, diagrama de pacote, diagrama de temporizao e diagrama de viso geral da interao.

09/09/2014 22:20

Modelo TCC - Template

17 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

5. Proposta do Novo Sistema

Controlar todo o estoque de equipamentos para emprstimos e o gerenciamento de requisies dos tcnicos de primeiro nvel. Um sistema que seja possvel visualizar quais ativos esto emprestados, disponveis e em manuteno.

1. Descrio do Sistema Proposto

Criar um sistema disponvel atravs da WEB, com acesso reservado apenas da empresa e por usurios com autenticao.
O sistema ser de fcil uso, permitindo s pessoas seu manuseio de forma simples e prtica. O SisCER ter na tela principal menus de acesso rpido s funcionalidades do sistema fazendo com que os funcionrios encontre rpido os
equipamentos que precisam para fazer a requisio.

2. Resultados Esperados

Com a utilizao do SisCER, espera-se que haja um controle maior sobre as solicitaes de equipamentos, armazenando os dados necessrios para a fcil localizao dos mesmos. O sistema dar aos tcnicos de primeiro nvel uma viso
geral dos ativos de informtica disponveis para atendimento imediato, tornando o processo de emprstimo rpido e prtico. Espera-se tambm, a melhora no controle de cobrana dos reservas feitas pelos tcnicos de segundo nvel, mesmo aps o
fechamento da ordem de servio, diminuindo o risco de perda.
esperado que o sistema funcione de forma estvel e que a interface seja simples e amigvel. tambm esperado, com a implantao desse sistema, que diminua o acumulo de papis contendo as informaes de emprstimos realizados
consequentemente agilizando o trabalho dos tcnicos que iro utilizar as funcionalidades que o sistema proporciona.

3. Restries do sistema proposto

O sistema estar disponvel apenas para acesso via intranet, os usurios do sistema devero estar devidamente autenticados com senhas de acesso para fazer qualquer tipo de transao utilizando o sistema de acordo com suas limitaes
de perfil.
O tcnico de primeiro nvel, aps logado, ter acesso para cadastrar as requisies e realizar consultas de equipamentos no ato da requisio. O tcnico de segundo nvel ser capaz de cadastrar outros tcnicos, cadastrar equipamentos,
cadastrar tipos de equipamentos, inserir, pesquisar e encerrar requisies. O tcnico de segundo nvel tambm ter acesso para gerar relatrios dos equipamentos.

4. Relao Custo x Benefcios: Anlise de Viabilidade Econmica do Novo Sistema

O custo para o desenvolvimento desse projeto considerado vivel se for considerado os valores praticados pelo mercado, alm do fato que com este sistema, as despesas com compra de novos equipamentos de informtica para
substituio daqueles perdidos nas filiais, por, atualmente, no ter controle dos mesmos, sero evitados. Com isso, ser possvel 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 informtica disponveis para emprstimos, em alguns setores de forma mais direta. Como o caso do setor de tecnologia da
informao que sero os nicos usurios do sistema e estes tero uma nova rotina de requisio e expedio 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, alm de outras qualidades, demonstra um alto desempenho, alta disponibilidade, suporte transacional e de fcil manuseio
tornando assim uma combinao perfeita para o sistema proposto.

6. Documentao de Anlise

Este captulo mostra a documentao de anlise usada para o desenvolvimento do sistema.

1. Viso Macro dos Atores


Eclipse (2008) fala que para entender totalmente o objetivo de um sistema, preciso saber quem usar o sistema, ou seja, quem sero 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

09/09/2014 22:20

Modelo TCC - Template

18 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

so sempre externos ao sistema. O sistema descrito atravs de casos de uso que so executados por um nmero de atores (CASTRO, 2011).
Borba (2010) fala que os atores normalmente so representados por uma figura de um stickman. A Figura 4 mostra exemplos de atores:

Figura - Atores
Fonte: BORBA (2010)

2. Identificao dos Atores

No SisCer haver dois perfis. O primeiro perfil ser associado ao tcnico de segundo nvel e o segundo ao tcnico de primeiro nvel.
O tcnico de segundo nvel cadastrar novos tcnicos, tanto de nvel 01(um) como de nvel 2(dois) e ter acessos as todas funcionalidades.
O perfil de tcnico nvel 01(um) s poder registrar requisies 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 sequncia de aes executadas pelo sistema que geram um resultado de valor observvel para um ator
em particular
Para Baesso (2004) Casos de Uso so funcionalidades que o sistema realiza e que fornece um benefcio a um ator especfico. So caractersticas 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 no 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 Tcnico

UC03

Cadastrar Tipo de Equipamento

UC04

Manter Equipamento

UC05

Manter Requisio

UC06

Gerar Relatrio

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 compreenso do comportamento externo do sistema por qualquer pessoa, tentando apresentar o sistema por intermdio de uma perspectiva do usurio. dentre todos os diagramas da
UML, o mais abstrato e, portanto o mais flexvel (GUEDES, 2008, p. 48).

Fowler et al (2000) relata que os diagramas de Casos de Uso fornecem a base da comunicao entre clientes e os desenvolvedores no planejamento do projeto. um diagrama abstrato, pois fornece uma viso do sistema com os atores que
hora produzem informaes para o sistema e por outro lado consomem informaes 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. Descrio detalhada dos Casos de Uso

A seguir, ser apresentada a especificao 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 nveis de perfil

Atores

Tcnico de primeiro e segundo nvel.

Dados Consumidos

Login e senha

Dados Produzidos

Acesso ao sistema

Prioridade

Alta

Pr-condies

Possuir autorizao e perfil de acesso

Ps-condies

N/A

Fluxo Principal
Realizar login.
Ator

Sistema

Inserir login e senha

Validar dados do usurio: login e senha

Fluxo Alternativo 1
Erro: Dados incorretos
Ator

Sistema

Inserir login e senha

Validar dados: login e senha, dados no validados e


enviar mensagem de erro.

Verificar mensagem de erro

Mensagem de erro informando que os dados esto


incorretos retorna tela de login.

09/09/2014 22:20

Modelo TCC - Template

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

UC02 Manter Tcnico


Tabela - Caso de Uso UC02 Manter Tcnico.
Nome

UC02 Manter Tcnico

Objetivo

Cadastrar Tcnico.

Atores

Tcnico de segundo nvel.

Dados Consumidos

Nome, Login, Senha, Nvel, Ramal e E-mail.

Dados Produzidos

Cadastro de tcnico.

Prioridade

Alta

Pr-condies

Possuir perfil de tcnico de segundo nvel e estar logado no sistema.

Ps-condies

N/A

Fluxo Principal Cadastrar Tcnico


Cadastrar tcnico.
Ator

Sistema

Acessar pgina cadastrar tcnico.

Abrir formulrio de cadastro de tcnico

Inserir os dados: Nome, Login, Senha, Nvel, 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
seno 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 Tcnico


Ator

Sistema

Acessar a pgina de gerenciar tcnico

Exibir lista de tcnicos cadastrados.

Clicar no boto alterar ao lado do tcnico que

Exibir dados do tcnico escolhido

deseja realizar a alterao


Realizar a alterao desejada e clica em

Recebe os dados inseridos, verifica se todos os dados


foram preenchidos, se foram o sistema armazena-os
seno exibido a mensagem Favor, preencher campo.

alterar

Receber mensagem

Exibir mensagem de alterao realizada com sucesso. Se


aparecer mensagem de erro reinicie o processo.

Fluxo Alternativo 2
Alterar Senha
Ator

Sistema

Acessar a pgina gerenciar tcnico

Exibir lista de tcnicos cadastrados.

Clicar no boto alterar senha ao lado do tcnico

Exibir formulrio de alterao de senha.

que deseja realizar a alterao


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
seno exibido a mensagem Favor, preencher campo.

Receber mensagem

Exibir mensagem de alterao realizada com ucesso. Se


aparecer mensagem de erro reinicie o processo.

Fluxo Alternativo 3
Erro: Favor, preencher campo
Ator

Sistema

Inserir os dados: Nome, Login, Senha, Nvel, Ramal, e Verificar dados: dados
E-mail.
mensagem de erro.
Verificar mensagem de erro

no

preenchidos,

enviar

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

Tcnico de segundo nvel

Dados Consumidos

Nome do tipo

Dados Produzidos

Cadastro de tipo de equipamento

Prioridade

Alta

Pr-condies

Possuir perfil de tcnico de segundo nvel e estar logado no sistema.

Ps-condies

N/A

Fluxo Principal Criar tipo de Equipamento


Cadastrar tipo de equipamento
Ator

Sistema

Acessar a pgina 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


foram preenchidos, se foram o sistema armazena-os
seno exibido a mensagem Favor, preencher campo.

cadastrar.

Receber mensagem

Exibir mensagem de cadastro realizado com sucesso. Se


aparecer mensagem de erro reinicie o processo.

Fluxo Alternativo 1
Erro: Favor, preencher campo
Ator

Sistema

Inserir o dado: nome do tipo.

Verificar dado: dado no preenchido, enviar mensagem


de erro.

Verificar mensagem de erro

Mensagem de erro informando que o campo no foi


preenchido e retorna tela de cadastro.

UC04 Manter Equipamento

Tabela - Caso de Uso UC04 Manter Equipamento


Nome

UC04 Manter Equipamento

Objetivo

Cadastrar Equipamento.

Atores

Tcnico de segundo nvel.

Dados Consumidos

Nome, Especificao, Tipo e Status.

Dados Produzidos

Cadastro de Equipamento.

Prioridade

Alta

Pr-condies

Possuir perfil de tcnico de segundo nvel e estar logado no sistema.

Ps-condies

N/A

Fluxo Principal Cadastrar Equipamento


Cadastrar novo equipamento.

19 de 25

Ator

Sistema

Acessar pgina cadastrar equipamento.

Abrir formulrio de cadastro de equipamento.

09/09/2014 22:20

Modelo TCC - Template

20 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

Inserir os dados: Nome, Especificao, Tipo e Status


e clicar em cadastrar.

Receber mensagem

Recebe os dados inseridos, verifica se todos os dados


necessrios foram preenchidos, se foram o sistema
armazena-os seno exibido a mensagem Favor,
preencher campo.
Exibir mensagem de cadastro realizado com
sucesso. Se aparecer mensagem de erro ou mensagem
para cadastrar um equipamento em uso, registre uma
requisio reinicie o processo.

Fluxo Alternativo 1 Editar equipamento


Ator

Sistema

Acessar a pgina gerenciar equipamentos

Exibir lista de equipamentos cadastrados.

Clicar no boto editar ao lado do equipamento

Verifica se o equipamento est em uso. Se estiver exibe a


mensagem Equipamento em uso. Impossvel alterar. Se
no exibi dados do equipamento escolhido.

que deseja realizar a alterao

Realiza as alteraes desejadas

Recebe os dados inseridos, verifica se todos os dados


necessrios foram preenchidos, se foram o sistema
armazena-os seno 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 requisio reinicie o processo.

Fluxo Alternativo 2
Inativar Equipamento
Ator

Sistema

Acessar a pgina de gerenciar equipamento

Exibir lista de equipamentos cadastrados

Clicar no boto Inativar ao lado do equipamento que Recebe a solicitao e altera o status do
deseja alterar o status.
equipamento.
Fluxo Alternativo 3
Erro: Equipamento em uso. Impossvel alterar
Ator

Sistema

Inserir os dados: Nome, Especificao, Tipo e Status.

Verifica se o equipamento est em uso. Se estiver exibe a


mensagem Equipamento em uso. Impossvel alterar.

Verificar mensagem de erro

Mensagem de erro informando que o no possvel


cadastrar o equipamento e retorna tela de cadastro.

UC05 Manter Requisio

Tabela - Caso de Uso UC05 Manter Requisio


Nome

UC05 Manter Requisio

Objetivo

Cadastrar Requisio

Atores

Tcnico de segundo e primeiro nvel.

Dados Consumidos

Tcnico, Numero do Chamado, Nome do Usurio, Ramal, Setor, Loja, Data de


Emprstimo, Previso de Entrega e Equipamento.

Dados Produzidos

Cadastro de requisio.

Prioridade

Alta

Pr-condies

Estar logado no sistema.


RN - Tcnico de primeiro nvel apenas registra requisio e o de segundo nvel
insere, atualiza e encerra requisio.

Ps-condies

N/A

Fluxo Principal Cadastra Requisio


Cadastrar nova requisio
Ator

Sistema

Acessar o boto nova requisio

Abrir formulrio de cadastro de requisio.

Inserir os dados: Nmero do Chamado, Nome do Recebe os dados inseridos, verifica se todos os dados
usurio, Ramal, Setor, Loja, Data de Entrega e necessrios foram preenchidos, se foram o sistema
Equipamento e clica em Cadastrar.
armazena-os seno exibido a mensagem Favor,
preencher campo.
Receber mensagem

Exibir mensagem de cadastro realizado com sucesso. Se


aparecer mensagem de erro reinicie o processo.

Fluxo Alternativo Atualizar Requisio


Atualizar Requisio

Ator

Sistema

Acessar a pgina de requisies

Exibir lista de requisies cadastradas.

Inserir o dado no campo observao na requisio que Verifica requisio selecionada e exibe mensagem de
deseja atualizar e clica em atualizar requisio
confirmao Deseja realmente atualizar esta requisio.
Recebe mensagem e confirma alterao.

Recebe os dados inseridos e atualiza requisio. Se


operao falhar, exibe mensagem Falha ao atualizar
requisio.

Clicar no boto alterar

Armazenar os dados

Receber mensagem

Exibir mensagem requisio atualizada com sucesso.

Fluxo Alternativo 2
Encerrar Requisio
Ator

Sistema

Acessar a pgina de requisies

Exibir lista de requisies cadastradas.

Clicar no boto encerrar requisio ao lado da requisio Recebe


que
a solicitao e encerra requisio.
deseja encerrar.
Receber Mensagem

Exibir mensagem de requisio encerrada com sucesso.

Fluxo Alternativo 3
Erro: Favor, preencher campo.
Ator

Sistema

Inserir os dados: Nmero do Chamado, Nome do Verificar dados: dados no preenchidos, enviar mensagem
usurio, 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 Relatrio


Tabela - Caso de Uso UC06 Gerar Relatrio
Nome

UC06 Gerar Relatrio

Objetivo

Gerar Relatrio

09/09/2014 22:20

Modelo TCC - Template

21 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

Atores

Tcnico de segundo nvel.

Dados Consumidos
Dados Produzidos

Relatrios de acordo com o filtro

Prioridade

Alta

Pr-condies

Possuir perfil de tcnico de segundo nvel e estar logado no sistema.

Ps-condies

N/A

Fluxo Principal Gerar Relatrio


Gerar relatrio
Ator

Sistema

Acessar a pgina de relatrio.

Exibir primeiro menu de filtro de relatrios

Escolher a opo de filtro: Todos os Equipamentos,


Equipamentos Ativos e Equipamentos no Ativos e
clicar no desejado.

Verificar a opo escolhida e exibir segundo menu de


filtro de relatrios.

Escolher a opo de filtro: Lista com tipos de


equipamentos.

Verificar a opo escolhida e gerar relatrio de


equipamentos.

Receber Relatrio

Gera relatrio para download. Se no houver dados


suficientes para gerar relatrio exibido mensagem
Dados insuficientes para gerar relatrio.

Fluxo Alternativo 1
Erro: Dados insuficientes para gerar relatrio
Ator

Sistema

Selecionar filtro.

Verificar dados: processar relatrio, caso no haja dados


suficientes para gerao do relatrio, enviar mensagem
de erro.

Verificar mensagem de erro

Mensagem de erro informando que os dados so


insuficientes para gerar relatrio.

6. Diagramas de Classes

Segundo Borba (2010) este o diagrama mais importante da UML. Est no centro da sua arquitetura. Outros diagramas so elaborados a partir dele. uma importante ferramenta para a documentao de sistema ou produto de software.
Segundo Fowler (2000), o diagrama de classes descreve os tipos de objetos e os tipos de relacionamentos estticos existentes entre eles no sistema. As classes representam propriedades e comportamentos de um conjunto de objetos em um
sistema. Como essas classes no existem sozinhas, importante a representao de seus relacionamentos.
A Figura 6 refere-se ao diagrama de classes onde so apresentadas todas as classes que compem 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 relaes, demonstrando a sua condio de dependncia.

Figura - Modelo de Entidade de Relacionamento

8. Especificao das Tabelas

As tabelas a seguir, apresentam as especificaes dos campos do MER do sistema proposto.

Tabela - Equipamento

EQUIPAMENTO
Campo

Tipo

Relacionamento Observao

CD_EQP

INT(11)

PK

NM_EQP

CHAR(50)

TX_ESP_EQP

TEXT

CD_TIP

AUTO_INCREMENT
NOT NULL

INT(11)

FK

NOT NULL

CD_STT

INT(11)

FK

NOT NULL

VL_ATV_EQP

CHAR(1)

NOT NULL

Tabela - Requisio

REQUISICAO
Relacionamento Observao

Campo

Tipo

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

09/09/2014 22:20

Modelo TCC - Template

22 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

TX_OBS_RQS

TEXT

Tabela - Tcnico

TECNICO
Campo

Tipo

Relacionamento Observao

CD_TCN

INT(11)

PK

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)

AUTO_INCREMENT

Tabela - Tipo

TIPO
Campo

Tipo

Relacionamento Observao

CD_TIP

INT(11)

PK

TX_DESC_TIP

CHAR(50)

AUTO_INCREMENT
NOT NULL

Tabela - Usuario

USUARIO
Campo

Tipo

Relacionamento Observao

CD_USU

INT(11)

PK

CD_LJA_STR

INT(11)

FK

NM_USU

CHAR(100)

NOT NULL

TX_RML_USU

CHAR(10)

NULL

AUTO_INCREMENT
NOT NULL

Tabela - Status

STATUS
Campo

Tipo

Relacionamento Observao

CD_STT

INT(11)

PK

TX_DESC_STT

CHAR(30)

AUTO_INCREMENT
NOT NULL

Tabela - Setor

SETOR
Campo

Tipo

Relacionamento Observao

CD_STR

INT(11)

PK

NM_STR

CHAR(100)

AUTO_INCREMENT
NOT NULL

2.
Tabela - Loja

LOJA
Campo

Tipo

Relacionamento Observao

CD_LJA

INT(11)

PK

NM_LJA

CHAR(100)

AUTO_INCREMENT
NOT NULL

Tabela - Loja_Setor

LOJA_
SETOR
Campo

Tipo

Relacionamento Observao

CD_LJA_STR

INT(11)

PK

AUTO_INCREMENT

CD_LJA

INT(11)

FK

NOT NULL

CD_STR

INT(11)

FK

NOT NULL

9.

09/09/2014 22:20

Modelo TCC - Template

23 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

rvore do Sistema

Na figura 8 temos a estrutura do sistema representada em forma de rvore.

Figura - rvore do Sistema

3.
4.

10. Especificao Tcnica

1. Layout Das Principais Telas Da Aplicao

Na Figura 9 temos a tela de login do sistema, onde cada tcnico dever acessar com seu respectivo perfil, aps ser cadastrado.

Figura - Tela de Login

Na figura 10 temos a tela principal do sistema, que exibida aps o tcnico realizar o login.

Figura - Tela principal do sistema

Na figura 11 temos a tela de cadastro de requisio, nesta tela os dados da requisio devero ser inseridos para que esta seja registrada.

Figura - Tela de cadastro de requisio

Na figura 12 exibida a tela de consulta de requisies j cadastradas no sistema.


Figura - Tela de consulta de requisio

09/09/2014 22:20

Modelo TCC - Template

24 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

1. Navegao
5. Logo abaixo na figura 13 apresentada a tela de navegao do sistema:

Figura - Menu de navegao do sistema

12. Segurana Fsica e Lgica

A segurana fsica e lgica ser baseada na poltica de segurana da empresa. Por tanto, para o devido funcionamento do sistema como garantia de disponibilidade, e a integridade das informaes nele tratada, h a necessidade que poltica
de segurana interna esteja implantada e estabelecida para todos os usurios do SisCER.

1. Segurana Fsica

A Segurana fsica visa disponibilidade do sistema. Dessa forma faz se necessrio que os servidores de aplicaes e de banco de dados estejam conectados em No-Breaks individuais, sala de servidores com ar-condicionado alm de
acesso permitido somente as pessoas autorizadas.
Atualmente a empresa j conta com estes requisitos, alm de existir um sistema de backup das informaes que faz uma cpia 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. Segurana Lgica

A Segurana lgica esta diretamente voltada ao controle de acesso do usurio ao sistema. O acesso ao sistema SisCER dar-se- por meio de login e senha. O nvel de acesso est limitado conforme os cargos. Usurio somente poder utilizar
o sistema, estando previamente cadastrado.
Para evitar incidente na segurana, a empresa dever adotar alguns padres como: no permitir tentativas de obter acesso no autorizado ou colocar o sistema prova; proibir que os usurios passem seus dados de acessos a outros
usurios. Para evitar acesso indevido todos os perfis devem finalizar a sesso ao termino do perodo de utilizao do sistema.

7. Plano de Implantao

A empresa contratada faz uso de outros sistemas que utilizam as mesmas configuraes do que iremos implantar, inclusive banco de dados MySQL. Sendo assim, no houve a necessidade de realizar configuraes de Servidores. Feito
apenas as configuraes de instalao do sistema SisCER nos servidores j existentes.
Foi realizado um treinamento com os funcionrios que tero acesso ao sistema com durao de 4 horas, onde foram apresentadas todas as funcionalidades do sistema e como estas devero ser aplicadas para substituir processos manuais.
O sistema ter um prazo de teste de 15 dias, perodo este onde sero observados erros apresentados pelo sistema, para que estes sejam corrigidos at o termino do perodo de testes.

1. Atividades Futuras

As atividades futuras esto voltadas para a insero de mais funcionalidades que torne o sistema ainda melhor, como por exemplo, desenvolvimento de mdulos para agendamento de equipamentos, incluir no sistema as opes para inativar
tcnicos que deixaram a empresa ou que no tenham mais acesso ao sistema. Acrescentar manter status para que os tcnicos estejam livres para acrescentar mais opes como, por exemplo, o status de agendado. Possibilitar que o tcnico de
primeiro nvel possa alterar alguns dados pessoais.
Criar um mdulo para cadastrar usurios (cliente), setores e lojas a fim de obter relatrios estatsticos sobre emprstimos de equipamentos onde seja possvel verificar quais lojas e setores ou usurio que mais solicitaram reservas.
Implementar no cadastro de equipamentos um campo onde seja possvel gerar, automaticamente, um cdigo identificador (Patrimnio) para cada produto cadastrado, proporcionando um controle maior sobre os mesmos. Tudo em funo da
melhoria do sistema.

8. Concluso

Visando o controle sobre os equipamentos de informtica que esto no laboratrio de informtica da organizao, 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 aes que seriam utilizadas para o desenvolvimento do software.
Aps levantar os requisitos, com base nos problemas enfrentados pela empresa, deu-se inicio a implementao do sistema, onde foram colocadas em prtica as tecnologias escolhidas.
Na implantao foi realizado o treinamento dos funcionrios que fariam uso do sistema, onde foi explanado todo o sistema. E includo sua rotina um novo processo que substitua 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 emprstimo e sua localizao,
automatizando o que antes era feito manualmente conforme os requisitos levantados na organizao.

09/09/2014 22:20

Modelo TCC - Template

25 de 25

http://dc193.4shared.com/doc/fsPLDFFg/preview.html

9. Referncias Bibliogrficas

BAESSO, Milena Alexandre dos Santos. Diagrama de Caso de Uso e Diagrama de Sequncia. Disponvel 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. Dissertao submetida Coordenao do Curso de Ps-Graduao em Cincia da Computao da Universidade Federal de
Campina Grande. Disponvel 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. Servio de Marketing: Competindo atravs da qualidade. 3 ed. So Paulo: Maltese, 1995.
BEZERRA, Eduardo. Princpios de Anlise e Projeto de Sistemas com UML: 8. ed. Rio de Janeiro: Elsevier, 2002.
BOOCH, Grady. RUMBAUGH, James. JACOBSON, Ivar. UML: guia do usurio. 2 ed. Rio de Janeiro: Elsevier:2005.
BORBA, Gilmar Luiz de. Diagrama de Caso de Uso. Disponvel em: <http://gilmarborba.com.br/?p=93>. Acessado em 21 de novembro de 2012.
BORBA, Gilmar Luiz de. Diagrama de Classes. Disponvel em: <http://gilmarborba.com.br/?p=184>. Acessado em 21 de novembro de 2012.
CASTRO, Jaelson. Modelagem de Caso de Uso. Disponvel em: <http://www.cin.ufpe.br/~if716/arquivos/8-CasodeUso.pdf>. Acessado em: 22 de novembro de 2012.
CIN. Desenvolvimento do Cronograma. Disponvel 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 Orientao a Objetos. 2 ed. So Paulo: Novatec, 2009.
ECLIPSE. Conceito: Ator. Disponvel 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, Rosrio. ARQUITETURAS DE SOFTWARE BASEADAS EM AGENTES: DO NVEL GLOBAL AO DETALHADO. Universidade Federal do Maranho. Departamento de Informtica. Campus do
Bacangar s/n. Disponvel 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 padro de modelagem de objetos. 2a. edio. Porto Alegre : Bookman, 2000
FOWLER, Martin. UML essencial: um breve guia para a linguagem-padro de modelagem de objetos. 3 ed. Porto Alegre: Bookman, 2005.
GUEDES, Gilleanes T. A. UML : uma abordagem prtica. 3 ed. So Paulo : Novatec Editora, 2008.
GOMES, Adelino Duarte. Instituio e Institucionalistas. Disponvel 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. Disponvel em:< http://www.waltenomartins.com.br/es_aps.pdf>. Acessado em: 14 de outubro de 2012.
KRUCHTEN, Philippe. Introduo ao RUP Rational Unified Process. 2 ed. Rio de Janeiro: Editora Cincia Moderna Ltda, 2003.
MADEIRA, Marcelo de Melo. Entendendo o Diagrama de Casos de Uso. Disponvel 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. Disponvel em: < http://www.maismonografia.com.br/cronograma.htm>. Acessado em 20 de novembro de 2012.
MARINHO, Joo Paulo Meira. Definio dos Objetivos. Disponvel em: <http://www.scribd.com/doc/275547/DEFINICAO-DOS-OBJETIVOS >. Acessado em: 20 de Outubro de 2012.
MARTINEZ, Mariana. RUP (Rational Unified Process). Disponvel em: http://www.infoescola.com/engenharia-de-software/rup/. Acessado em: 11 de novembro 2012.
MELO, Ana Cristina. Desenvolvendo aplicaes com UML 2.0: do conceito implementao. 2 ed. Rio de Janeiro: Brasport, 2004.
MILANI, Andr. Construindo Aplicaes Web com PHP e MySQL. 1 ed. So Paulo. Novatec, 2010.

PACIEVITCH, Yuri. MySQL. Disponvel em: < http://www.infoescola.com/informatica/mysql/ >. Acessado em 1 de novembro de 2012.

PAULA FILHO, Wilson de Pdua. Engenharia de Software: fundamentos, mtodos e padres. Disponvel 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 prtica. 2. ed. So Paulo: Prentice Hall, 2004.

PRESSMAN, Roger S. Engenharia de Software 3 edio. So Paulo: Makron Books. 1995.

PRESSMAN, Roger S. Software Engineering 6 edio.So Paulo: McGraw-Hill, 2006.


RUP. Rational Unified Process, 2002. Disponvel em: < http://www.wthreex.com/rup/manuals/intro/im_bp1.htm>. Acesso em: 11 de novembro 2012.
RUP. Rational Unified Process, 2002. Disponvel em: <http://www.wthreex.com/rup/portugues/index.htm>. Acesso em: 11 de novembro 2012.
SOMMERVILLE, I. Engenharia de Software. 6 ed. So Paulo: Addison Wesley, 2003.
SORDI, Jos Osvaldo de. MARINHO, Bernadete de Lourdes Marinho. NAGY, Marcio. BENEFCIOS DA ARQUITETURA DE SOFTWARE ORIENTADA A SERVIOS PARA AS EMPRESAS: ANLISE DA EXPERINCIA DO ABN AMRO BRASIL.
Revista de Gesto da Tecnologia e Sistemas de Informao. Vol.3, N. 1,2006, p.19-34. Disponvel 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 Gesto da execuo de servios. 2010. Disponvel 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.

09/09/2014 22:20