Diego de Mattos Marques
Felipe de Oliveira Jacinto
Sistema de Cotação de Preços - SISCOP
Trabalho de Conclusão de Curso submetido ao Curso de Tecnologia em Sistemas de Computação da Universidade
Federal Fluminense como requisito parcial para obtenção do título de Tecnólogo em Sistemas de Computação.
Orientador:
Alexandre Domingues Gonçalves
Niterói
2011
Diego de Mattos Marques
Felipe de Oliveira Jacinto
Sistema de Cotação de Preços - SISCOP
Trabalho de Conclusão de Curso submetido ao Curso de Tecnologia em Sistemas de Computação da Universidade
Federal Fluminense como requisito parcial para obtenção do título de Tecnólogo em Sistemas de Computação.
Banca Examinadora:
_________________________________________
Prof. Alexandre Domingues Gonçalves, Msc. – Orientador
UFF - Universidade Federal Fluminense
_________________________________________
Prof. Leandro Soares de Sousa, Msc. – Avaliador
UFF - Universidade Federal Fluminense
Dedicamos este trabalho a nossos familiares
e amigos.
AGRADECIMENTOS
Primeiramente a Deus, que nos deu força para chegarmos até aqui.
Aos tutores e professores do CEDERJ pela
atenção e pelo conhecimento que nos passaram.
Aos Colegas do CEDERJ pelo incentivo e troca de experiências.
A todos os nossos familiares e amigos pelo
apoio, colaboração e paciência.
“O tempo é um grande professor, mas infelizmente ele mata todos os seus alunos”.
Hector Berlioz
RESUMO
Durante a fase de compras de novos produtos, os Supermercados efetuam cotações de preços entre seus diversos fornecedores com o intuito de adquirir os
produtos com o menor preço possível, entretanto muitos deles não possuem uma
solução de software para tornar esta atividade mais rápida e eficiente. Os fornecedores, muitas das vezes, têm de preencher seus preços em listas de papel ou, em outras situações, esperar, por horas, a sua vez para poder utilizar um computador com
um sistema básico do próprio empreendimento. O presente trabalho apresenta o
processo de desenvolvimento de um sistema onde os fornecedores possam inserir
seus preços para seus produtos, em diversos estabelecimentos, de forma centralizada e informatizada. Para tal, utilizaremos a plataforma Web, onde teremos os Supermercados cadastrados e, para cada um, a listagem com seus produtos e os fornecedores habilitados para participar da cotação de preço em questão.
Palavras-chaves: Cotação de Preços, Sistema Informatizado, Fornecedores,
Supermercado.
LISTA DE ILUSTRAÇÕES
Figura 1: Diagrama de Casos de Uso....................................................................... 20
Figura 2: Usuários e Pedido...................................................................................... 30
Figura 3: Orçamento e Produtos............................................................................... 31
Figura 4: Iniciar processo de cotação ....................................................................... 33
Figura 5: Informar proposta de preço........................................................................ 34
Figura 6: Gerenciar Produto...................................................................................... 35
Figura 7: Encerrar processo de cotação ................................................................... 36
Figura 8: Cadastrar fornecedor ................................................................................. 37
Figura 9: Gerenciar usuários..................................................................................... 38
Figura 10: Gerenciar operadores do supermercado ................................................. 39
Figura 11: Diagrama de Entidade-Relacionamento do Usuário ................................ 42
Figura 12: Diagrama de Entidade-Relacionamento do Orçamento........................... 43
Figura 13: Tela Inicial do Sistema............................................................................. 49
Figura 14: Tela Inicial para Administrador do Supermercado ................................... 50
Figura 15: Administrador do Supermercado – Gerenciar Produtos .......................... 51
Figura 16: Administrador do Supermercado – Adicionar produto ............................. 52
Figura 17: Administrador do Supermercado – Gerenciar Fornecedores................... 53
Figura 18: Administrador do Supermercado – Adicionar Fornecedor ....................... 54
Figura 19: Administrador do Supermercado – Gerenciar Cotações.......................... 55
Figura 20: Administrador do Supermercado – Gerenciar Operadores...................... 56
Figura 21: Administrador do Supermercado – Adicionar Operador .......................... 57
Figura 22: Tela Inicial do Administrador do Sistema ................................................. 58
Figura 23: Administrador do Sistema – Gerenciar administradores.......................... 59
Figura 24: Administrador do Sistema – Adicionar administrador .............................. 60
Figura 25: Tela Inicial do Operador do Sistema........................................................ 61
LISTA DE TABELAS
Tabela 1: Fornecedor................................................................................................ 44
Tabela 2: Orçamento ................................................................................................ 44
Tabela 3: orçamento_has_produto ........................................................................... 45
Tabela 4: pedido ....................................................................................................... 45
Tabela 5: pedido_has_produto ................................................................................. 46
Tabela 6: produto...................................................................................................... 46
Tabela 7: supermercado ........................................................................................... 47
Tabela 8: usuário ...................................................................................................... 47
LISTA DE ABREVIATURAS E SIGLAS
DCP – Diagrama de Classes do Projeto
IDE – Integrated Development Enviroment (Ambiente integrado para desenvolvimento de software)
PHP – Acrônimo recursivo para: PHP: Hypertext Preprocessor
SGBD – Sistema Gerenciador de Banco de Dados
UML – Unified Modeling Language (Linguagem de modelagem unificada)
SUMÁRIO
RESUMO .................................................................................................................... 6
LISTA DE ILUSTRAÇÕES.......................................................................................... 7
LISTA DE TABELAS ................................................................................................... 8
LISTA DE ABREVIATURAS E SIGLAS ...................................................................... 9
1
2
3
4
INTRODUÇÃO................................................................................................... 11
1.1
MOTIVAÇÃO............................................................................................ 11
1.2
OBJETIVO ............................................................................................... 12
1.3
ORGANIZAÇÃO DO TRABALHO ............................................................ 12
ANÁLISE DE REQUISITOS............................................................................... 14
2.1
DESCRIÇÃO DOS ENVOLVIDOS........................................................... 14
2.2
DESCRIÇÃO DOS USUÁRIOS DO SISTEMA ........................................ 15
2.3
REQUISITOS FUNCIONAIS .................................................................... 16
2.4
REQUISITOS NÃO-FUNCIONAIS ........................................................... 17
2.5
PESQUISA DE MERCADO...................................................................... 19
MODELAGEM ................................................................................................... 19
3.1
DIAGRAMA DE CASOS DE USO............................................................ 20
3.2
DESCRIÇÃO DOS CASOS DE USO....................................................... 21
3.3
DIAGRAMA DE CLASSES....................................................................... 29
3.4
DIAGRAMAS DE SEQUÊNCIA................................................................ 32
CONSTRUÇÃO DO SISTEMA .......................................................................... 40
4.1
BANCO DE DADOS................................................................................. 41
4.2
DICIONÁRIO DE BANCO DE DADOS .................................................... 43
4.3
INTERFACES .......................................................................................... 48
4.4
TESTES ................................................................................................... 62
4.5
IMPLANTAÇÃO ....................................................................................... 63
5
CONCLUSÕES E TRABALHOS FUTUROS ..................................................... 64
6
REFERÊNCIAS BIBLIOGRÁFICAS................................................................... 65
11
1 INTRODUÇÃO
No mundo competitivo em que vivemos, para manter um negócio vivo e
lucrativo, independente de sua natureza, é necessário, dentre outras características,
possuir bons fornecedores e adquirir os produtos sempre com os menores preços
possíveis.
Neste cenário entra, como um dos fatores decisivos, a cotação de preços.
O presente trabalho apresenta o desenvolvimento de um sistema capaz de
identificar o melhor preço para um determinado produto através da comparação dentre todos os valores informados pelos fornecedores.
1.1
MOTIVAÇÃO
A motivação para a realização deste trabalho surgiu a pouco mais de três
anos, quando tivemos a oportunidade de conhecer de perto a real situação do processo de cotação dos supermercados da cidade de Angra dos Reis-RJ, atuando no
papel de fornecedor, ou seja, responsável, basicamente, por inserir os preços e gerar os pedidos dos clientes.
A experiência não foi muito longa, perdurando por não mais de seis meses, de Novembro de 2008 até Abril de 2009. Entretanto foi tempo suficiente para
perceber que era necessário evoluir o processo de cotação de preços destes estabelecimentos. Era necessário centralizar o processo, utilizando-se da maior ferramenta disponível atualmente: a Internet.
O processo de cotação adotado nestes supermercados não é bom para os
fornecedores e também não é bom para os supermercados. Os fornecedores precisam ir a cada um dos supermercados, nos quais são cadastrados, para realizar a
12
cotação dos produtos e, por outro lado, os supermercados devem oferecer uma infraestrutura para receber esses fornecedores.
Observamos, também, que cada supermercado possui seu próprio método
para realização da cotação. Enquanto uns realizam o processo utilizando-se de
softwares locais, outros, por incrível que pareça, ainda utilizam listas em papel. Estes fatos tornam o processo lento e ineficiente, gerando filas e constantes reclamações de ambas as partes.
Tendo em vista o exposto, declinamos por desenvolver um projeto, utilizando-se a plataforma Web, no qual o processo de cotação seria centralizado, onde
clientes e fornecedores compartilhariam um mesmo ambiente para realizar o processo de cotação.
1.2
OBJETIVO
O objetivo do nosso trabalho foi desenvolver um sistema de cotação de
preços, no qual supermercados e fornecedores compartilhem um mesmo ambiente,
proporcionando maior agilidade, eficiência e eficácia no processo de cotação de preços.
Os supermercados cadastrados poderão selecionar a lista dos produtos
que desejam cotar e os fornecedores que participam do processo. Os fornecedores
cadastrados efetuam a cotação de preços para cada um dos itens selecionados pelos clientes. Ao final do processo, o sistema gera pedidos de compra para cada um
dos fornecedores, com os itens cotados com os menores preços.
1.3
ORGANIZAÇÃO DO TRABALHO
Este trabalho foi dividido da seguinte forma: No Capítulo 2 são apresentados o levantamento e descrição dos requisitos funcionais e não-funcionais bem como os usuários que irão operar o sistema. No Capítulo 3 é apresentada a modela-
13
gem, utilizando a ferramenta UML através dos casos de uso, diagramas de classes e
de sequência. No Capítulo 4 apresentamos os itens que descrevem a construção do
banco de dados e os detalhes da implantação. Ao final, são apresentadas as conclusões e as indicações para trabalhos futuros.
14
2 ANÁLISE DE REQUISITOS
A análise de requisitos é o 1º passo no modelo do processo. Nesta fase,
definimos o que deve ser feito e não a forma como será implementado. Desta forma,
serve como contrato entre desenvolvedor e comprador.
Podemos dizer que, análise de requisitos, é o processo de aquisição, refinamento e verificação das necessidades do sistema, com o objetivo de sistematizar
o processo de definição dos requisitos, obtendo uma especificação correta e completa do mesmo para elaboração do Documento de Requisitos.
Durante a análise de requisitos, realizaremos um estudo das características que o sistema deverá ter para atender às necessidades e expectativas do cliente.
2.1
DESCRIÇÃO DOS ENVOLVIDOS
Stakeholder (em português, parte interessada ou interveniente), é um termo usado em administração que refere-se a qualquer pessoa ou entidade que afeta
ou é afetada pelas atividades de uma empresa.
“O termo foi usado pela primeira vez pelo filósofo Robert Edward Freeman.
Segundo ele, os stakeholders são um elemento essencial ao planejamento estratégico de negócios”. (Wikipedia [12])
De maneira mais ampla, compreende todos os envolvidos em um processo, que pode ser de caráter temporário (como um projeto) ou duradouro (como o negócio de uma empresa ou a missão de uma organização).
15
Foram identificados os seguintes stakeholders:

Administrador do sistema: pessoa responsável por contatar as empresas oferecendo o sistema de cotação de preços na Internet. Tem
a responsabilidade de manter o site.

Administrador do supermercado: pessoa responsável pelo cadastramento dos operadores e pela manutenção dos itens e dos fornecedores no sistema, assim como, da verificação dos pedidos emitidos após as cotações.

Operador do supermercado: funcionário capacitado para operar o
sistema, liberando os processos de cotação, selecionando quais itens e quais fornecedores que irão participar do processo.

Fornecedor: pessoa interessada em participar da cotação aberta
pelo operador do supermercado. Usa o sistema como forma de inserir os preços de seus produtos nas cotações abertas.
2.2
DESCRIÇÃO DOS USUÁRIOS DO SISTEMA
Nesta seção, temos a apresentação de como os envolvidos irão interagir
com o sistema. Uma breve descrição sobre estas pessoas e suas responsabilidades
com o sistema será apresentada a seguir:

Administrador do sistema: responsável pelo cadastro de empresas
e o gerenciamento dos usuários no sistema.

Administrador do supermercado: responsável pelo cadastramento
dos operadores, dos produtos e pelo cadastramento dos fornecedores no sistema. Poderá emitir relatórios de últimas compras e cotações realizadas, filtrando por períodos, por itens ou por fornecedores.

Operador do supermercado: manterá os produtos e fornecedores.
Responsável pela abertura dos processos de cotação, inclusão dos
16
itens e as quantidades que farão parte dos mesmos, assim como
quais fornecedores serão incluídos no processo.

Fornecedor: irá utilizar o sistema para efetuar as cotações, inserindo seus preços para cada produto presente na mesma.
2.3
REQUISITOS FUNCIONAIS
Os requisitos funcionais descrevem as funcionalidades que se espera que
o sistema disponibilize, de uma forma completa e consistente. É aquilo que o utilizador espera que o sistema ofereça, atendendo aos propósitos para qual o sistema será desenvolvido. Os requisitos funcionais identificados são os seguintes:

O sistema deverá permitir que o administrador do sistema gerencie
todos os usuários.

O sistema deverá permitir a inclusão de novos produtos.

O sistema deverá permitir a inclusão de novos fornecedores.

O sistema deverá permitir que seja iniciado um processo de cotação.

O sistema deverá informar para cada fornecedor, cadastrado e escolhido pelo administrador do supermercado, que a sua participação está sendo solicitada no processo de cotação e que um pedido
está aguardando a sua proposta de preços.

O sistema deverá permitir que cada fornecedor, participante da cotação, faça a sua proposta de preços, referentes aos produtos requisitados pelo supermercado.

O sistema deverá permitir que o administrador do supermercado
encerre o processo de cotação.
17
2.4
REQUISITOS NÃO-FUNCIONAIS
Especifica todos os requisitos não funcionais do sistema. Foram divididos
em: requisitos de acesso, usabilidade, desempenho, interface, operacionais e de segurança (Guedes, 2009).
Acesso
Os perfis de usuário para acesso aos recursos do sistema são:

Administrador do sistema: terá acesso total às constas de usuário.

Administrador do supermercado: terá acesso global às informações
do supermercado tais como, produtos cadastrados, fornecedores e
gerenciamento de operadores.

Operador do supermercado: terá acesso às operações relacionadas
ao processo de cotação de preços, tais como, os produtos que farão parte e os fornecedores que participarão.

Fornecedor: terá acesso ao módulo de inserção de preços e visualização do resultado final dos seus preços.
Usabilidade
O sistema deverá ser "fácil" de usar. Operações pertinentes aos requisitos
devem ser ágeis. Em outras palavras, devem ser simples, fáceis de serem executadas e consumir pouco tempo.
Desempenho
O sistema deve operar de forma leve, com o menor tempo de resposta
possível, para que até clientes/fornecedores com conexões mais lentas possam utilizar o sistema de forma favorável.
18
O sistema deverá se comportar "elegantemente" quando estiver sobrecarregado, isto é, disponibilizar para o usuário recurso de visualização do processamento que está sendo executado (por exemplo, barra de progressão).
Interface
Para acessar o sistema, se faz necessário um computador com um navegador apropriado, pelo qual o sistema será acessado, utilizando-se conexão com a
Internet.
Operacionais
O sistema poderá ser acessado em estações de trabalho que tenham capacidade de rodar algum navegador de Internet.
Será necessário um servidor de páginas que faça a interpretação/execução de uma linguagem própria para Web e um banco de dados confiável
para armazenamento dos dados. A escolha deverá ser uma linguagem de programação e banco de dados de livre distribuição cujo custo é baixo ou mesmo sem custo de licenciamento.
Segurança
O sistema deverá restringir o acesso aos módulos de cadastro.
O sistema deverá gerar backups automáticos diariamente dos dados armazenados para uma restauração caso ocorra algum problema no servidor.
As senhas de todos os usuários deverão ser criptografadas para garantir a
segurança do sistema.
19
2.5
PESQUISA DE MERCADO
É sabido que, atualmente, existem diversos softwares no mercado que realizam cotações de preços, utilizando diversos critérios para determinação de qual
empresa irá fornecer determinado produto.
Entretanto, para o nicho de mercado apresentado, nenhuma aplicação totalmente baseada na Web foi encontrada.
Assim como comentado anteriormente, os supermercados atualmente utilizam-se de softwares locais, instalados dentro da própria rede do supermercado,
que disponibiliza alguns computadores para que os fornecedores participem das cotações.
A solução de mercado mais próxima do que estamos propondo foi encontrada na página da empresa Datahex (DATAHEX, 2011), com o produto de software
intitulado “Sistema de Cotação”. Este software deve ser instalado localmente nos
usuários, porém, como diferencial dos que existem atualmente nos supermercados
pesquisados, este se comunica com a Internet, podendo enviar as listas de produtos
e resultados de cotação por e-mail para os fornecedores.
3 MODELAGEM
A Engenharia de software orientada a objetos é uma evolução da Engenharia de software, mas com uma forma totalmente diferente de ver os relacionamentos e análise do problema por ter um enfoque na orientação a objeto (LARMAN,
2007).
Neste processo de engenharia de software, temos como grande aliada, as
ferramentas UML, que atuam como um apoio visual ao aprendizado para entender o
código existente. Essas ferramentas UML colaboram para elaboração dos Diagramas UML de pacotes, classes e interação a partir do próprio código.
20
Entretanto, antes de partirmos para a criação do código, devemos fazer a
modelagem do sistema, que nos auxiliará a entender melhor o sistema que está
sendo desenvolvido.
Os modelos fornecem uma cópia do projeto de um sistema e ajudam a visualizá-lo como ele é ou como desejamos que ele seja, permitem especificar a estrutura ou comportamento do sistema, proporcionam um guia para a sua construção e
documentam as decisões tomadas.
3.1
DIAGRAMA DE CASOS DE USO
Um diagrama de casos de uso é uma excelente imagem do contexto do
sistema; ele é um bom diagrama de contexto, ou seja, mostra a fronteira de um sistema, o que está fora dele e como o sistema é usado. Serve como uma ferramenta
de comunicação que resume o comportamento do sistema e seus atores. (Larman,2007).
A Figura 1 apresenta o diagrama de casos de uso do sistema.
Figura 1: Diagrama de Casos de Uso
21
3.2
DESCRIÇÃO DOS CASOS DE USO
Descrição dos Casos de Uso são narrativas de texto que usualmente tomam a forma de uma nota ou um documento que é de alguma maneira ligado ao
Caso de Uso, e detalha o processo ou atividades que serão executadas ao longo
dele. A seguir é apresentada a descrição dos casos de uso do sistema:
3.2.1 - Caso de Uso 1: Gerenciar produto.
Sumário: O caso de uso se inicia quando algum produto precisa ser editado para
pode fazer parte de um processo de cotação de preços.
Ator principal: Operador do supermercado.
Pré-condições: O usuário estar identificado pelo sistema.
Pós-condições: Produtos editados e prontos para serem usados em um processo
de cotação de preços. É possível identificar o usuário que realizou a inclusão e a
qual supermercado pertence.
Fluxo Principal:
1) O operador abre a tela de CRUD dos produtos.
2) O sistema exibe uma lista de produtos com ações associadas.
3) O operador executa uma das ações para um produto listado.
a) Subfluxo criar produto.
b) Subfluxo alterar produto.
c) Subfluxo apagar produto.
(a) Subfluxo criar produto:
1a. O sistema exibe o formulário de cadastro.
2a. O operador digita todos os dados do produto.
3a. O operador manda salvar o produto.
4a. O sistema salva o produto no sistema.
5a. Caso haja outro produto para ser cadastro o operador retorna para o item 1.
Fluxo Alternativo para (a) Subfluxo criar produto:
1a. Algum dado inválido é digitado.
22
1. O sistema exibe uma mensagem informando o campo que contem o dado
inválido.
2. O operador corrige o erro.
3. O sistema retorna para o item 4 do (a) Subfluxo criar produto.
(b) Subfluxo alterar produto:
1b. O sistema exibe o formulário de cadastro preenchido com os dados do produto.
2b. O fluxo é encaminhado para os itens 2-4 do Subfluxo (a) criar produto.
3b. O sistema retorna para o item 2 do Fluxo Principal.
(c) Subfluxo apagar produto:
1c. O sistema pede uma confirmação para apagar o produto.
2c. O operador confirma a operação.
3c. O sistema apaga o produto do sistema.
3.2.2 - Caso de Uso 2: Iniciar processo de cotação.
Sumário: O usuário do supermercado deseja informar para os seus fornecedores
que pretende adquirir uma lista de produtos.
Ator principal: Operador do supermercado.
Pré-condições: O usuário estar identificado pelo sistema.
Pós-condições: Todos os fornecedores selecionados pelo supermercado estão cientes do início do processo de cotação de preços.
Fluxo Principal:
1)
O usuário inicia o processo de cotação.
2)
O sistema solicita o período de duração da cotação.
3)
O usuário entra com a data de início e de fim.
4)
O sistema apresenta a listagem com os produtos a escolher para entrar na cotação.
5)
O usuário seleciona um produto para fazer parte da cotação.
6)
Se houve outro produto para ser incluído retorna para o item 5.
23
7)
O usuário informa ao sistema que todos os produtos já foram selecionados.
8)
O sistema pede que seja informado o fornecedor que irá participar da cotação.
9)
O usuário seleciona um fornecedor.
10) Se houve outro fornecedor para participar retorna para o item 9.
11) O usuário informa ao sistema que todos os fornecedores já foram selecionados.
12) O sistema impede que a lista de produtos e fornecedores selecionados seja alterada.
13) O sistema envia um aviso de início de processo de cotação, por e-mail, para
todos os fornecedores participantes.
Fluxo Alternativo:
1) A qualquer momento antes do item 12 os produtos e fornecedores podem ser alterados.
2) Se o produto não estiver cadastrado ir para o caso de uso Gerenciar produto.
3) Se o fornecedor não estiver cadastrado ir para o caso de uso Cadastrar Fornecedores.
a)
Ocorre um erro no envio de e-mail.
b)
O sistema notifica ao usuário o erro.
3.2.3 - Caso de Uso 3: Encerrar o processo de cotação.
Sumário: O usuário do supermercado deseja finalizar a cotação e escolher para
qual fornecedor deve ser enviado o pedido de compra.
Ator principal: Operador do supermercado.
Pré-condições: O usuário do supermercado deve estar identificado pelo sistema.
Pós-condições: O fornecedor, que fez a proposta ganhadora, é informado da sua
vitória e envia os produtos desejados. A cotação fica gravada para consultas futuras.
Fluxo Principal:
1) O sistema exibe um relatório comparativo das propostas enviadas pelos fornecedores destacando o ganhador de cada item.
2) O sistema envia uma notificação para todos os fornecedores informando que o
processo de cotação está encerrado e já existe um ou mais vencedores.
24
a) O(s) fornecedor(es) vencedor(es) recebe(m) uma notificação diferenciada.
3) O(s) fornecedor(es) ganhador(es) envia(m) os produtos cotados junto de uma boleta de cobrança.
Fluxo Alternativo:

A qualquer momento o usuário decide cancelar a cotação:
1. um e-mail avisando o cancelamento é enviado para todos os fornecedores.
1) Ocorre um erro no envio de e-mail.
a) O sistema notifica ao usuário o erro.
3.2.4 - Caso de Uso 4: Gerenciar operadores do supermercado
Sumário: O administrador do supermercado deseja gerenciar o cadastro dos operadores do supermercado. Criando, definindo as permissões ou editando os dados.
Ator principal: Administrador do supermercado.
Pré-condições: O administrador do supermercado deve estar identificado pelo sistema.
Pós-condições: O operador do supermercado está configurado conforme as necessidades do administrador do supermercado.
Fluxo Principal:
1) O administrador do supermercado abre a tela de CRUD dos operadores do supermercado.
2) O sistema exibe uma lista de operadores do supermercado com ações associadas.
3) O administrador do supermercado executa uma das ações:
a) Subfluxo criar operador do supermercado.
b) Subfluxo alterar operador do supermercado.
c) Subfluxo apagar operador do supermercado.
(a) Subfluxo criar operador do supermercado.
1a. O sistema exibe o formulário de cadastro.
25
2a. O administrador do supermercado digita todos os dados do operador do supermercado.
3a. O administrador do supermercado manda salvar o operador do supermercado.
4a. O sistema salva o operador do supermercado no sistema.
5a. Caso haja outro operador do supermercado para ser cadastro, retorna para o
item 1.
Fluxo Alternativo para (a) Subfluxo criar operador do supermercado:
1a.
Algum dado inválido é digitado.
1. O sistema exibe uma mensagem informando o campo que contem o dado
inválido.
2. O administrador do supermercado corrige o erro.
3. O sistema retorna para o item 4 do (a) Subfluxo criar operador do supermercado.
(b) Subfluxo alterar produto:
1b. O sistema exibe o formulário de cadastro preenchido com os dados do produto.
2b. O fluxo é encaminhado para os itens 2-4 do Subfluxo (a) criar operador do
supermercado.
3b. O sistema retorna para o item 2 do Fluxo Principal.
(c) Subfluxo apagar operador do supermercado:
1c. O sistema pede uma confirmação para apagar o operador do supermercado.
2c. O administrador do supermercado confirma a operação.
3c. O sistema apaga o operador do supermercado do sistema.
26
3.2.5 - Caso de Uso 5: Gerenciar usuários.
Sumário: O administrador do sistema deseja gerenciar o cadastro dos usuários. Criando, definindo as permissões ou editando os dados.
Ator principal: Administrador do sistema.
Pré-condições: O administrador do sistema deve estar identificado pelo sistema.
Pós-condições: O usuário está corretamente configurado.
Fluxo Principal:
1) O administrador do sistema abre a tela de CRUD dos usuários.
2) O sistema exibe uma lista de usuários com ações associadas.
3) O administrador do sistema executa uma das ações:
a) Subfluxo criar usuário.
b) Subfluxo alterar usuário.
c) Subfluxo apagar usuário.
(a) Subfluxo criar usuário.
1a. O sistema exibe o formulário de cadastro.
2a. O administrador do sistema digita todos os dados do usuário.
3a. O administrador do sistema manda salvar o usuário.
4a. O sistema salva o usuário no sistema.
5a. Caso haja outro usuário para ser cadastro, retorna para o item 1.
Fluxo Alternativo para (a) Subfluxo criar usuário:
1a.
Algum dado inválido é digitado.
1. O sistema exibe uma mensagem informando o campo que contem o dado
inválido.
2. O administrador do sistema corrige o erro.
3. O sistema retorna para o item 4 do (a) Subfluxo criar usuário.
(b) Subfluxo alterar usuário:
1b. O sistema exibe o formulário de cadastro preenchido com os dados do usuário.
2b. O fluxo é encaminhado para os itens 2-4 do Subfluxo (a) criar usuário.
27
3b. O sistema retorna para o item 2 do Fluxo Principal.
(c) Subfluxo apagar usuário:
1c. O sistema pede uma confirmação para apagar o usuário.
2c. O administrador do sistema confirma a operação.
3c. O sistema apaga o usuário do sistema.
3.2.6 - Caso de Uso 6: Informar proposta de preço.
Sumário: O fornecedor deseja informar a sua proposta de preço em uma cotação.
Ator principal: Fornecedor.
Pré-condições: O fornecedor estar identificado no sistema.
Pós-condições: Os preços do fornecedor devem estar cadastrados no sistema.
Fluxo Principal:
1) O sistema lista os processos de cotação abertos.
2) O fornecedor seleciona um processo para participar.
3) O sistema exibe os itens do pedido da cotação.
4) O fornecedor envia o seu preço, para cada um dos produtos.
5) O sistema salva os preço e impede que sejam alterados.
6) O sistema notifica o supermercado via e-mail da proposta feita pelo fornecedor.
Fluxo Alternativo:
1) Algum dado inválido é digitado.
a) O sistema exibe uma mensagem informando o campo que contem o dado inválido.
b) O fornecedor corrige o erro.
c) O sistema retorna para o item 4 do Fluxo Principal.
28
3.2.7 - Caso de Uso 7: Cadastrar Fornecedores.
Sumário: Um supermercado deseja realizar o cadastro de um fornecedor no sistema.
Ator principal: Operador do supermercado.
Pré-condições: O usuário estar identificado pelo sistema.
Pós-condições: O fornecedor está cadastrado e disponível para acessar o sistema.
Fluxo Principal:
1) O sistema exibe o formulário de cadastro.
2) O operador digita os dados solicitados.
3) O sistema cria o usuário e liberar o seu acesso.
4) O fornecedor aguarda ser chamado para participar de um processo de cotação.
Fluxo Alternativo:
1) Algum dado inválido é digitado.
2) O sistema exibe uma mensagem informando o campo que contem o dado inválido.
3) O fornecedor corrige o erro.
4) O sistema retorna para o item 3 do Fluxo Principal.
29
3.3
DIAGRAMA DE CLASSES
O diagrama de classes é um dos mais importantes e mais utilizados da
UML. Seu principal enfoque está em permitir a visualização das classes que irão
compor o sistema com seus respectivos atributos e métodos, bem como em demonstrar como as classes do diagrama se relacionam, complementam e transmitem
as informações entre si. A visão do diagrama é estática de como as classes são organizadas, preocupando-se em como definir a estrutura lógica das mesmas.
UML inclui diagramas de classe para ilustrar classes, interfaces e suas associações. Eles são usados para modelagem estática de objetos. O mesmo diagrama UML pode ser usado em múltiplas perspectivas. Em uma perspectiva conceitual,
o diagrama de classes pode ser usado para visualizar um modelo de domínio. Pode
ser usado também em uma perspectiva de software ou projeto. Um termo para essa
finalidade é diagrama de classes de projeto (DCP). (LARMAN,2007).
O diagrama de classes representa a estrutura do sistema, recorrendo ao
conceito de classe e suas relações. O modelo de classes resulta de um processo de
abstração onde são identificados os objetos relevantes do sistema em estudo. Um
objeto é uma ocorrência que tem interesse para o sistema em estudo e que se pretende descrever no seu ambiente, contendo identidade e comportamento. O comportamento de um objeto define o modo como ele age e reage a estímulos externos e a
identidade de um objeto é um atributo que o distingue de todos os demais, sendo
preservada quando o seu estado é alterado. (Guedes, 2009).
30
A seguir é apresentado o Diagrama de classes em uma perspectiva conceitual para visualização do modelo de domínio.
Figura 2: Usuários e Pedido
31
Figura 3: Orçamento e Produtos
32
3.4
DIAGRAMAS DE SEQUÊNCIA
Os diagramas de sequência e os diagramas de comunicação – chamados
de diagramas de interação – são dois dos diagramas utilizados na UML para a modelagem dos aspectos dinâmicos de sistemas. Um diagrama de interação mostra
uma interação, formada por um conjunto de objetos e seus relacionamentos, incluindo as mensagens que poderão ser enviadas entre eles. Um diagrama de sequência
é um diagrama de interação que dá ênfase à ordenação temporal das mensagens; o
diagrama de comunicação é um diagrama de interação que dá ênfase à organização
estrutural dos objetos que enviam e recebem mensagens. (BOOCH, RUMBAUGH,
JACOBSON, 2006)
Neste trabalho faremos uso apenas do diagrama de sequência por ser de
mais fácil construção e entendimento, já que apresenta a rotina de forma sequencial
de acordo com o fluxo de chamada.
Os diagrama de sequência baseia-se no diagrama de caso de uso e, normalmente, existe um diagrama de sequência para cada caso de uso declarado, uma
vez que o caso de uso se refere a um processo disparado por um ator. Sendo assim,
o diagrama de sequência depende do diagrama de classe, já que as classes dos objetos utilizados no diagrama de sequência estão descritas nele.
33
A seguir apresentamos os diagramas de sequência.
Figura 4: Iniciar processo de cotação
34
Figura 5: Informar proposta de preço
35
Figura 6: Gerenciar Produto
36
Figura 7: Encerrar processo de cotação
37
Figura 8: Cadastrar fornecedor
38
Figura 9: Gerenciar usuários
39
Figura 10: Gerenciar operadores do supermercado
40
4 CONSTRUÇÃO DO SISTEMA
A seguir, descrevemos as ferramentas utilizadas no processo de desenvolvimento do sistema:
 Para a construção da base de dados será utilizado o MySQL, um sistema de gerenciamento de banco de dados (SGBD) de fácil integração
com a linguagem de programação adotada, boa portabilidade (suporta
praticamente qualquer plataforma atual), excelente desempenho e estabilidade, e fácil de usar.
 Adotamos o PHP como linguagem de programação. O PHP é uma linguagem de desenvolvimento para Web que tem como objetivo principal a
implementação de soluções Web velozes, simples e eficientes. Outra boa
característica dessa linguagem é a portabilidade, que se dá pela independência de plataforma.
 Para auxiliar o desenvolvimento da aplicação com o PHP, adotamos
também o framework CakePHP, que tem por objetivo o desenvolvimento
ágil sem a perda de flexibilidade. O CakePHP utiliza padrões de projeto
conhecidos, entre eles o MVC (Model-View-Controller).
 Como ferramenta auxiliar foi utilizada também o Netbeans IDE 6.5, que
é um ambiente de desenvolvimento integrado (IDE) gratuito, multiplataforma e de código aberto para desenvolvedores de software na linguagem
Java, C/C++, PHP, Groovy, Ruby entre outras.
41
4.1
BANCO DE DADOS
Os bancos de dados surgiram graças à necessidade das grandes empresas de armazenar grandiosas quantidades de informação de uma forma rápida, simples e confiável, e que por sua vez pudessem acessá-la em qualquer momento sem
a necessidade de se deslocar às salas dedicadas a arquivar documentação, como
até há pouco tempo se fazia.
Quando começou o surgimento de programas de computador, começouse a armazenar dados nos arquivos dos programas, o qual era mais cômodo, porém,
ainda assim tinham grandes dificuldades na hora de modificar registros, estruturas
ou simplesmente buscar informação.
Na década de sessenta, surgiram os bancos de dados. Nestes bancos de
dados eram salvos os dados utilizados pelos usuários, empresas, etc.
Como definição de banco de dados, entendemos que se trata de um conjunto de dados inter-relacionados e armazenados sem redundâncias desnecessárias, os quais servem às aplicações sem estarem relacionados de uma maneira direta a elas.
Um banco de dados pode ser utilizado por várias aplicações e usuários.
Todo banco de dados deve permitir inserir, modificar e excluir dados, portanto nos
bancos de dados se salvam informações de dois tipos:
Os dados de usuários (dados usados pelas aplicações)
Os dados de sistema (dados que o banco de dados utiliza para sua administração. Ex.: Dados dos usuários que têm acesso ao banco de dados).
42
Nas Figuras 11 e 12, temos o diagrama de entidades e relacionamentos do sistema:
Figura 11: Diagrama de Entidade-Relacionamento do Usuário
43
Figura 12: Diagrama de Entidade-Relacionamento do Orçamento
4.2
DICIONÁRIO DE BANCO DE DADOS
“É um documento que registra dados sobre os dados – ou seja, registra
metadados.” (LARMAN,2007). Nas tabelas seguintes, são apresentados os campos
44
de cada entidade no banco de dados, com os respectivos tipos, tamanhos, chaves
primárias e descrições:
fornecedor
Coluna
Tipo
Chave Primária
Obrigatório
id
INTEGER(5)
Sim
Sim
cnpj
INTEGER(11)
Não
Sim
nome
VARCHAR(100)
Não
Sim
endereco
VARCHAR(400)
Não
Sim
email
VARCHAR(100)
Não
Sim
Tabela 1: Fornecedor
orcamento
Coluna
Tipo
Chave Primária
Obrigatório
id
INTEGER(9)
Sim
Sim
pedido_usuario_id INTEGER(6)
Sim
Sim
pedido_id
INTEGER(9)
Sim
Sim
fornecedor_id
INTEGER(5)
Sim
Sim
status_2
INTEGER(1)
Não
Não
Tabela 2: Orçamento
45
orcamento_has_produto
Coluna
Tipo
Chave Primária Obrigatório
produto_usuario_id
INTEGER(6)
Sim
Sim
produto_id
INTEGER
Sim
Sim
orcamento_pedido_id
INTEGER(9)
Sim
Sim
orcamento_pedido_usuario_id
INTEGER(6)
Sim
Sim
orcamento_fornecedor_id
INTEGER(5)
Sim
Sim
orcamento_id
INTEGER(9)
Sim
Sim
preco
FLOAT
Não
Sim
Tabela 3: orçamento_has_produto
pedido
Coluna
Tipo
Chave Primária
Obrigatório
id
INTEGER(9)
Sim
Sim
usuario_id INTEGER(6)
Sim
Sim
preco
FLOAT
Não
Não
status_2
INTEGER(1)
Não
Sim
data_inicial
DATE
Não
Sim
data_final
DATE
Não
Sim
Tabela 4: pedido
46
pedido_has_produto
Coluna
Tipo
Chave Primária Obrigatório
pedido_usuario_id INTEGER(6)
Sim
Sim
pedido_id
INTEGER(9)
Sim
Sim
INTEGER(6)
Sim
Sim
INTEGER
Sim
Sim
produto_usuario_id
produto_id
Tabela 5: pedido_has_produto
produto
Coluna
Tipo
Chave Primária
Obrigatório
id
INTEGER
Sim
Sim
usuario_id INTEGER(6)
Sim
Sim
preco
FLOAT
Não
Sim
nome
VARCHAR(100)
Não
Sim
Tabela 6: produto
47
supermercado
Coluna
Tipo
Chave Primária
Obrigatório
id
INTEGER(5)
Sim
Sim
cnpj
INTEGER(11)
Não
Sim
nome
VARCHAR(100) Não
Sim
endereco
VARCHAR(300) Não
Sim
Tabela 7: supermercado
usuario
Coluna
Tipo
id
INTEGER(6) Sim
Sim
fornecedor_id
INTEGER(5) Não
Sim
supermercado_id
INTEGER(5) Não
Sim
nome
login
senha
tipo
Chave Primária
VAR-
Obrigatório
Não
Sim
Não
Sim
Não
Sim
INTEGER(1) Não
Sim
CHAR(200)
VARCHAR(100)
VARCHAR(150)
Tabela 8: usuário
48
4.3
INTERFACES
Uma interface, na área da computação, é a fronteira que define a forma
de comunicação entre duas entidades. Ela pode ser entendida como uma abstração
que estabelece a forma de interação da entidade com o mundo exterior, através da
separação dos métodos de comunicação externa dos detalhes internos da operação,
permitindo que esta entidade seja modificada sem afetar as entidades externas que
interagem com ela. Uma interface também pode promover um serviço de tradução
para entidades que não falam a mesma linguagem, como no caso de humanos e
computadores.
A interface existente entre um computador e um humano é conhecida como interface de usuário e as interfaces utilizadas para conectar os componentes de
hardware são chamadas de interfaces físicas.
O projeto da interface com o usuário cria um meio efetivo de comunicação
entre o ser humano e o computador. Seguindo um conjunto de princípios de projeto
de interface, o projeto identifica objetos e ações de interface e depois cria um layout
de tela que forma a base para um protótipo de interface com o usuário. (PRESSMAN, 2006)
A forma como os usuários interagem é um item importante no processo de
desenvolvimento de um software. “Frustação e ansiedade são parte da vida diária
para muitos usuários de sistemas de informação computadorizados.” (SHNEIDERMAN, 1990).
A seguir, apresentamos as interfaces de usuário do sistema e uma breve
explicação sobre seu funcionamento.
49
Figura 13: Tela Inicial do Sistema
Através da tela inicial do sistema (figura 13), os usuários, operadores e
administradores do sistema, assim como os fornecedores dos produtos, podem se
logar para utilizar as ferramentas do sistema.
No momento em que o utilizador entra no sistema, aparecem as opções
correspondentes, de acordo com a categoria a qual o utilizador pertença: administrador do supermercado, operador de supermercado, fornecedor e administrador do
sistema.
50
Figura 14: Tela Inicial para Administrador do Supermercado
Os administradores de supermercado podem realizar, basicamente, 4 operações: gerenciar produtos, gerenciar fornecedores, gerenciar cotações, assim como
gerenciar os operadores do supermercado, como mostrado na figura 14.
51
Figura 15: Administrador do Supermercado – Gerenciar Produtos
Os administradores do supermercado podem realizar inclusão, pesquisa,
edição e exclusão de produtos no sistema, como mostrado na figura 15.
As operações de pesquisa (filtrar), edição e exclusão de produtos, podem
ser realizadas diretamente nesta tela principal de Gerenciar Produtos. Ao clicar sobre o botão “add +”, uma tela de inclusão de produtos será mostrada, como mostrado na figura 16.
52
Figura 16: Administrador do Supermercado – Adicionar produto
Os produtos possuem diversas informações, que devem ser inseridas no
momento do cadastro do mesmo, conforme pode ser observado na tela acima.
53
Figura 17: Administrador do Supermercado – Gerenciar Fornecedores
Os administradores do supermercado podem realizar inclusão, pesquisa,
edição e exclusão de fornecedores no sistema, como mostrado na figura 17.
As operações de pesquisa (filtrar), edição e exclusão de fornecedores, podem ser realizadas diretamente nesta tela principal de Gerenciar Fornecedores. Ao
clicar sobre o botão “add +”, uma tela de inclusão de fornecedores será mostrada,
como na figura 18.
54
Figura 18: Administrador do Supermercado – Adicionar Fornecedor
Os fornecedores possuem diversas informações, que devem ser inseridas
no momento do cadastro do mesmo, conforme pode ser observado na tela acima.
55
Figura 19: Administrador do Supermercado – Gerenciar Cotações
Os administradores do supermercado podem realizar inclusão, pesquisa,
edição e exclusão de cotações no sistema.
As operações de pesquisa (filtrar), edição, encerramento e exclusão de cotações, podem ser realizadas diretamente nesta tela principal de Gerenciar Cotações, figura 19.
Ao se criar uma nova cotação, através do botão “add +”, os fornecedores
selecionados serão avisados sobre o início da cotação, com os respectivos produtos
selecionados para a mesma.
Uma cotação em aberto, só pode ser excluída após o seu encerramento.
Ao se encerrar uma cotação, os fornecedores serão avisados sobre o encerramento.
Após o encerramento de uma cotação, o administrador do supermercado
deverá avaliar o resultado e submetê-lo para os respectivos fornecedores, vencedores nos produtos em que ofereceram o menor preço.
56
Figura 20: Administrador do Supermercado – Gerenciar Operadores
Os administradores do supermercado podem realizar inclusão, pesquisa,
edição e exclusão de Operadores no sistema, menu da figura 20.
As operações de pesquisa (filtrar), edição, encerramento e exclusão de
operadores, podem ser realizadas diretamente nesta tela principal de Gerenciar Operadores (figura 20). Ao clicar sobre o botão “add +”, uma tela de inclusão de Operadores será mostrada, como abaixo.
57
Figura 21: Administrador do Supermercado – Adicionar Operador
Os Operadores possuem diversas informações, que devem ser inseridas
no momento do cadastro do mesmo, conforme pode ser observado na figura 21.
58
Figura 22: Tela Inicial do Administrador do Sistema
Os administradores de sistema somente podem gerenciar os Administradores do Supermercado, menu da figura 22.
Cada supermercado cadastrado no sistema poderá ter somente um usuário administrador, com o qual realizará cadastros de operadores no sistema.
59
Figura 23: Administrador do Sistema – Gerenciar administradores
Os administradores do sistema podem realizar inclusão, pesquisa, edição
e exclusão de Administradores de Supermercado no sistema.
As operações de pesquisa (filtrar), edição, encerramento e exclusão de
Administradores de Supermercado, podem ser realizadas diretamente nesta tela
principal de Gerenciar Administrador de Supermercado, figura 23. Ao clicar sobre o
botão “add +”, uma tela de inclusão de Operadores será mostrada, como na figura
24.
60
Figura 24: Administrador do Sistema – Adicionar administrador
Os Administradores de Supermercado possuem diversas informações, que
devem ser inseridas no momento do cadastro do mesmo, conforme pode ser observado na tela acima.
Cada supermercado cadastrado no sistema de Cotação de Preços terá
somente um usuário administrador de supermercado cadastrado.
61
Figura 25: Tela Inicial do Operador do Sistema
Os operadores do sistema são usuários com as mesmas características
dos administradores de supermercado, entretanto não possuem a operação de Gerenciar Operadores, figura 25.
Todas as outras operações (gerenciar produtos, fornecedores e cotações)
podem ser executadas pelos operadores dos supermercados.
62
4.4
TESTES
“Teste é um processo de execução de um programa com a finalidade de
encontrar um erro” (PRESSMAN, 2006, p.93).
“Não se pode garantir que todo software funcione corretamente, sem a
presença de erros” (MYERS, 2004, p. 8), visto que os mesmos muitas vezes possuem um grande número de estados com atividades e algoritmos complexos. O tamanho do projeto a ser desenvolvido e a quantidade de pessoas envolvidas no processo de desenvolvimento aumentam ainda mais a complexidade. Idealmente, toda
permutação possível do software deveria ser testada. Entretanto, isso se torna impossível para a ampla maioria dos casos devido à quantidade impraticável de possibilidades.
Diante do exposto acima, percebemos que falhas podem ser originadas
por diversos motivos. Por exemplo, a especificação, assim como a implementação,
podem conter erros ou estarem incompletas, ou pode conter requisitos impossíveis
de serem implementados, devido à limitações de hardware ou software, portanto,
uma falha é o resultado de um ou mais defeitos em algum aspecto do sistema.
Utilizamos a abordagem de teste conhecida como Caixa-Preta, que referese a testes que são conduzidos na interface do software. Um teste caixa-preta examina algum aspecto fundamental do sistema, pouco se preocupando com a estrutura lógica interna do software. (PRESSMAN, 2006).
Durante o processo de desenvolvimento do projeto (Sistema de Cotação
de Preços), foram efetuados uma série de testes de funcionais, para verificar se os
requisitos levantados foram implementados corretamente na etapa de desenvolvimento do sistema. Para uma análise dos erros, que ocorriam ao longo do processo
foi feita uma análise por nível de criticidade (ALTA, MÉDIA, BAIXA) das ocorrências
de erros, que o sistema apresentava, para que fossem corrigidos posteriormente.
A representação escolhida para as funcionalidades foram os casos de uso,
que tomados em conjunto, constituem todas as possibilidades de utilização do sistema.
63
De uma forma geral, as funcionalidades principais, observadas isoladamente, apresentaram resultados satisfatórios em relação aos testes, com índice mínimo de falhas que foram imediatamente corrigidas.
4.5
IMPLANTAÇÃO
Para a implantação do sistema, será necessário um servidor contratado
que seja capaz de hospedar aplicações Web em PHP e MySQL, preferencialmente
com o sistema operacional Linux. Para que o sistema possa ser bem utilizado esse
servidor deve ser seguro e estável.
Após a instalação do sistema no servidor escolhido, ele será apresentado
aos supermercados, que deverão realizar o cadastro de seus fornecedores e produtos.
Cada supermercado que aderir ao sistema será devidamente cadastrado
por um dos administradores do sistema e passará por uma fase de treinamento para
conhecer todas as funcionalidades e fazer um bom uso do sistema. Feito isso os supermercados, e também os fornecedores, estarão aptos a realizar as cotações OnLine, utilizando-se do Sistema de Cotação de Preços, conseguindo, com isso, maior
rapidez, eficiência e eficácia no processo de compra de produtos.
64
5 CONCLUSÕES E TRABALHOS FUTUROS
Com o desenvolvimento desta ferramenta de cotação de preços, colocamos em prática os conceitos de arquitetura de sistemas e engenharia de software,
que através da definição e normatização dos processos de desenvolvimento fazem
com que tenhamos um sistema com maior qualidade.
Outro ponto importante para a garantia de qualidade do projeto e satisfação do cliente é a realização de testes durante o desenvolvimento do sistema. Tiramos proveito também da aplicação desse princípio.
A possibilidade de realizar todo o processo de cotação de preços através
da Internet traz grandes benefícios aos supermercados e, também, aos fornecedores. Os supermercados não mais se preocuparão com infraestrutura para receber os
fornecedores e os fornecedores não mais terão que se deslocar, desnecessariamente, até o supermercado somente para preencher a cotação de preços, preocupandose apenas em comprar e vender produtos, respectivamente.
Com a utilização da ferramenta ao longo do tempo e o consequente aumento da demanda, novas funcionalidades poderão ser implementadas para atender
ainda melhor aos usuários. Tenciona-se agregar ao sistema funcionalidades de controle de estoque juntamente ao processo de cotação, onde, de acordo com informações de regra de negócio de cada cliente, o sistema já informa a necessidade de inserir um produto no processo de cotação, utilizando informações do estoque atual do
mesmo.
O desenvolvimento e implantação desta ferramenta certamente trarão benefícios e melhorias para o processo de aquisição de produtos nos mercados da região de Angra dos Reis-RJ, podendo ser estendido inclusive para outras regiões.
65
6 REFERÊNCIAS BIBLIOGRÁFICAS
1. LARMAN Craig., Utilizando UML e Padrões: uma introdução à análise e ao projeto
orientado a objeto e ao desenvolvimento iterativo, tradução Rosana Vaccare Braga,
3. Ed., Porto Alegre, RS, Bookman, 2007.
2. PRESSMAN Roger S., Engenharia de Software 6. Ed. São Paulo, Mac Graw Hill, 2006;
tradução de Rosângela Delloso Penteado e Fernão Stella R. Germano. São Paulo.
3. SHNEIDERMAN, B., Designing the User Interface, 3ed., Addison-Wesley, 1990.
4. BOOCH, Grady, UML: guia do usuário / Grady Booch, James Rumbaugh, Ivar Jacobson; Rio de Janejro: Elsevier, 2005 - 2ª Reimpressão.
5. BOGONI, Eduardo H. Um novo sistema de atendimento aos pacientes do sistema
hospitalar público do município de Volta Redonda, 2007. Monografia - Curso de
Tecnologia de Sistemas de Computação, CEDERJ, Volta Redonda, RJ.
6. SILVA, Henrique D. da; CARVALHO, Emanual C. de, Sistema de Gerência de Tutorias
do CEDERJ – Volta Redonda, 2009. Monografia – Curso de Tecnologia em Sistemas
de Computação, CEDERJ (UFF/UFRJ), Volta Redonda, RJ.
7. BEZERRA, Bráulio S, VIEIRA, Luiz Guilherme M., RIBEIRO, Pedro D., Sistema de Controle de Publicações – Paracambi, 2010. Monografia – Curso de Curso de Tecnologia
em Sistemas de Informação – FAETEC – RJ.
8. LIMA, Thiago S. M.; SALVIO, Roseane, Sistema de Gerência e Divulgação de Imóveis
– Volta Redonda, 2009. Monografia – Curso de Tecnologia em Sistemas de Computação, CEDERJ (UFF/UFRJ), Volta Redonda, RJ.
9. MYERS, Glenford J., John Wiley & Sons, The Art of Software Testing, 2, Nova Jèrsei:
2004.
10. Datahex, http://www.datahex.com.br/comprebemprofessional/sistema-de-cotacao.html Sistema Compre Bem Profissional – Acessado 09/04/2011
11. http://br.php.net/manual/pt_BR/ - Manual do PHP, em português. Acessado em
09/04/2011
12. Wikipedia, http://pt.wikipedia.org/wiki/Stakeholder#cite_note-0 – Stakeholder. Acessado
em 07/05/2011.
13. Guedes, G. T. (2009), UML 2 Uma Abordagem Prática. São Paulo: Novatec.