Controle de vendas - Loja de Jogos, Acessórios e Produtos GEEK

Prévia do material em texto

0
21
UNIVERSIDADE PAULISTA – UNIP
UNIP INTERATIVA
PROJETO INTEGRADO MULTIDISCIPLINAR VI – PIM VI
	
SISTEMA PARA CONTROLE LOJA DE JOGOS, ACESSÓRIOS E PRODUTOS GEEK
POLO DE SÃO MIGUEL DO OESTE
JUNHO 2021
UNIVERSIDADE PAULISTA – UNIP
UNIP INTERATIVA
PROJETO INTEGRADO MULTIDISCIPLINAR VI – PIM VI
SISTEMA PARA CONTROLE LOJA DE JOGOS, ACESSÓRIOS E PRODUTOS GEEK
POLO DE SÃO MIGUEL DO OESTE
JUNHO 2021
RESUMO
O projeto que segue surgiu da necessidade de uma loja de venda de equipamentos de jogos, acessórios e produtos geek automatizar as vendas, processo no qual permitirá o maior controle de estoque, melhor atendimento ao cliente, melhor aproveitamento do tempo pelos colaboradores da loja. A atual forma de controle é feita em uma planilha do Excel, com os dados de cada venda alimentados de forma manual. Para isso a empresa Infinity Automation (grupo do PIM VI) fará a análise dos requisitos e o levantamento das informações necessárias para a automatização do sistema.
Para atender a demanda do cliente será desenvolvido uma aplicação para desktop, onde roda o sistema operacional Windows. O sistema será focado no gerenciamento das vendas ao cliente e terá níveis de acesso para que se tenha controle sobre as operações realizadas. Será tratado no projeto os casos de uso com os modelos de casos de uso, requisitos funcionais e de negócios, juntamente com as regras de negócio, os requisitos não funcionais do sistema, diagrama de classe, Modelo Entidade Relacionamento (MER). 
A elaboração deste projeto foi baseada nos livros textos da Unip com reforços em pesquisas na Internet, fóruns de discussão e em bibliografias de autores que foram apresentados nos próprios livros textos, com o intuito de ser o mais assertivo possível na elaboração do projeto.
Palavras Chaves: Sistema, análise, regras.
ABSTRACT
The project that continues to arise from the need for a store selling game equipment, accessories and geek products to automate sales, a process that will allow for greater stock control, better customer service, better use of time by store employees. The current form of control is done in an Excel spreadsheet, with the data of each sale manually fed. For this, the company Infinity Automation (PIM VI group) will analyze the requirements and gather the information needed to automate the system.
To meet customer demand, a desktop application will be developed, running the Windows operating system. The system will be focused on managing sales to the customer and will have access levels so that you have control over the operations carried out. The use cases will be treated in the project with the use case models, requirements and business, together with the business rules, the non-required system requirements, class diagram, Entity Relationship Model (MER).
The elaboration of the project was based on the textbooks of this Unip with reinforcements in Internet research, in the discussion forums and in the bibliographies of authors that were elaborated in the textbooks themselves, in order to be as assertive as possible in the elaboration of the project.
Keywords: System, analysis, rules.
SUMÁRIO
1.INTRODUÇÃO........................................................................................................6
2. DESENVOLVIMENTO...........................................................................................7
2.1 Identificar os casos de uso...................................................................................7
3. MODELO DE CASOS DE USO.............................................................................8
4. IDENTIFICAÇÃO ENTRE OS RELACIONAMENTOS DE INCLUDE, EXTEND E GENERALIZAÇÃO.....................................................................................................9
4.1 Include..................................................................................................................9
4.2 Extend..................................................................................................................9
4.3 Generalização......................................................................................................9
4.4 Diagrama dos relacionamentos de Include - Extend - Generalização.................9
5. REQUISITOS NÃO FUNCIONAIS E REGRAS DE NEGÓCIO............................10
5.1 Regras de negócio.............................................................................................10
5.2 Requisitos não funcionais..................................................................................10
5.3 O sistema...........................................................................................................10
6. DIAGRAMA DE CLASSE DE ANALISE - BOUNDARY - CONTROL - ENTITY..11
7. MER - MODELO ENTIDADE RELACIONAMENTO.............................................12
7.1 Diagrama Entidade relacionamento...................................................................13
8. PROTOTIPAGEM DAS TELAS............................................................................13
9. Conclusão............................................................................................................15
10. Referências........................................................................................................16
LISTA DE FIGURAS
Figura 1 – Modelo de caso de uso.............................................................................8
Figura 2 – Diagrama Includ, Extend, generalização..................................................9
Figura 3 – DER Diagrama Entidade-Relacionamento..............................................12
INTRODUÇÃO
O mercado de desenvolvimento de software é um dos negócios que mais tem crescimento nos dias atuais. Melhorias em sistemas (atualização de software, migração para sistemas mais confiáveis), automatização de processos, estão cada vez mais presentes no nosso dia a dia. Desde pequenas automações dentro das residências até sistemas que gerenciam empresas multinacionais, com troca de dados e informações quase que momentâneas pela alta gerencia e até mesmo clientes.
A empresa Infinity Automation (Grupo PIM VI) é uma empresa do ramo de desenvolvimento de software multiplataforma (Windows, MacOS, Android, IOS) e neste projeto se fará a apresentação das funcionalidades do sistema: CRUD para clientes (cadastro de clientes, alterações de cadastro, exclusão de cadastro e consultas a clientes já cadastrados), CRUD para produtos (cadastro de novos produtos, alterações de cadastro em um produto já existente, exclusão do cadastro e consultas a produtos cadastrados). O sistema contará com diversos níveis de acesso. Este controle aos níveis de acesso garante a segurança sobre as operações realizadas e evita que uma pessoa sem treinamento realize alguma atividade não autorizada no sistema. 
O desenvolvimento deste projeto se dará baseado no conhecimento adquirido no curso de Analise e Desenvolvimento de Sistemas, do Segundo Semestre da Unip. Serão utilizados os conhecimentos adquiridos nas disciplinas de Análise de Sistemas Orientada a Objetos, Banco de Dados e Gestão Estratégica de Recursos Humanos. Será desenvolvido de acordo com as normas vigentes e de acordo com o que foi apresentado nos livros texto e desta forma se apresentará as funcionalidades e os requisitos para a elaboração do sistema.
DESENVOLVIMENTO
Inicialmente será apresentado os casos de uso. Os casos de uso servem para especificar todas as funcionalidades de um software. Com estas especificações, o futuro projetista e / ou programador irá se basear para confeccionar o software. Um bom detalhamento dos casos de uso acarretará em um software padrão, sendo realizado mais rapidamente e com maior índice de assertividade. 
Todo o sistema foi confeccionado baseado nas informações repassadas pelo cliente, advindas por meio de reuniões e acompanhamento do processo de vendas e estoque dos produtos disponíveis na loja.
 2.1.	Identificar os casos de usoDevemos identificar alguns passos primários para nossos casos de uso, estes são compostos basicamente por quatro partes:
· Cenário: sequência de eventos que acontecem quando um usuário interage com o sistema.
· Ator: Usuário do sistema, ou melhor, um tipo de usuário. 
· Use Case: É uma tarefa ou uma funcionalidade realizada pelo ator (usuário). 
· Comunicação: é o oque liga um ator com um caso de uso. 
Sabendo disso podemos criar nosso cenário começando pelos nossos atores:
· Cliente;
· Atendente;
· Estoquista;
· Supervisor;
Vamos definir a ação de cada usuário: 
· Cliente: Compra produto do vendedor, compra produto no balcão (atendente), recebe produto do atendente, informa os dados para o cadastro;
· Atendente: Recebe solicitação de compra do Cliente, solicita o produto para o funcionário, recebe produto do estoquista, entrega o produto para o cliente, realiza o cadastro do cliente;
· Estoquista: Compra produto mediante solicitação do sistema de controle de estoque, da entrada no sistema da nota do produto, recebe solicitação de produto do atendente, recebe solicitação de compra balcão, entrega produto ao atendente, entrega produto ao cliente balcão ou entregador;
· Supervisor: Consulta todos os dados do sistema (controle de estoque, compras, vendas, porcentagens, etc.), efetua alterações e cancelamento das vendas dos atendentes. 
Modelo de casos de uso
Para melhor interpretação de tudo o que foi comentado no item acima devemos demonstrar em forma de diagrama os casos de uso:
Figura 01: Modelo de caso de uso
Fonte: Autores.
Identificação entre os relacionamentos de Include, extend e generalização
1.1. Include
Quando o caso de uso A “inclui” o caso de uso B, significa que sempre que o caso de uso A for executado o caso de uso B também será executado. A direção do relacionamento é do caso de uso que está incluindo para o caso de uso incluído.
1.2. Extend
Quando o caso de uso B estende o caso de uso A, significa que quando o caso de uso A for executando o caso de uso B poderá (poderá – talvez não seja) ser executado também. A direção do relacionamento é do caso de uso extensor (aqui o caso de uso B) para o caso de uso estendido (aqui o caso de uso A).
1.3. Generalização
Quando o caso de uso B generaliza o caso de uso C isso significa que, além de fazer tudo que está especificado (ele = B), ele também executará tudo que está especificado no caso de uso C.
1.4. Diagrama dos relacionamentos de Include, extend e generalização
Figura 02: Diagrama Includ, Extend, generalização
Fonte: Autores
Requisitos não funcionais e regras de negócios
1.5. Regras de negócio
É o que define a forma de fazer o negócio, refletindo a política interna, o processo definido e/ou as regras básicas de conduta. Ou seja, é um conjunto de instruções que os usuários já seguem e que o sistema a ser desenvolvido deve contemplar. Restrições, validações, condições e exceções são exemplos clássicos de regras de negócio. Uma regra de negócio não necessariamente será refletida no sistema como uma funcionalidade, mas ela com certeza determinará o comportamento de uma ou mais funcionalidades do sistema.
1.6. Requisitos não funcionais
É aquele que define os parâmetros de funcionamento do sistema, que trarão ao usuário uma melhor experiência no uso do sistema, porém não são diretamente acionados por ele. Nesta categoria estão os requisitos de arquitetura, desempenho, usabilidade, tempo de resposta, padrão de nomenclatura, entre outros. Em geral, o usuário final do sistema tem uma boa noção dos requisitos não funcionais desejados, porém, pela própria subjetividade deles, o usuário não os explicita diretamente. Ou, nos melhores casos, o usuário fala coisas como: “que o sistema seja rápido”, “fácil de usar”, não dependa de ninguém para usar”.
1.7. O Sistema
Tendo essas informações podemos seguir agregando esta solução. Para suprimir os erros de registro de informações, o sistema deverá importar automaticamente a nota fiscal eletrônica, na qual foi atrelada anteriormente a uma ordem de compra. Com isso deverá acrescentar e dar entrada automaticamente nos itens de estoque, após conferência do estoquista, além disto efetuar cálculo do produto através das informações da compra, impostos, analise de resultados e margem de lucros e comissionamentos. Também deverá calcular automaticamente a porcentagem de comissão que o atendente terá com resultado de suas vendas finalizadas (levando em consideração seu percentual que foi definido na tela cadastro de vendedores da empresa).
Outro tópico importante para o sistema é o estoque mínimo, no qual deverá informar o funcionário que o estoque está no mínimo e o mesmo deverá efetuar a compra dos produtos, além disto, deverá sugerir que itens com maior incidência de venda estejam com um estoque maior. Da mesma maneira com os itens de menos venda ou com muito tempo em estoque, deverão ser alertados a fim de efetuar possível promoção para não ter capital financeiro parado. Caso o produto foi vendido e já possuí ordem de compra para repor o estoque, o sistema deverá informar o funcionário que não há este produto a pronta entrega e o mesmo tem previsão de chegada estipulada para tal data, já informar o novo preço do item.
O sistema no momento da venda deverá acrescentar em um modulo contas a receber, e disponibilizar informações para faturamento. O mesmo deve ocorrer na hora da compra dos produtos, que deverá lançar as contas a pagar, criar análise de demonstrativos de resultados, criar metas e projeções financeiras para os próximos meses.
Diagrama de classe de análise (boundary, control, entity)
A classe boundary é responsável por modelar a interação entre o ambiente do sistema e seus trabalhos internos. Essa interação envolve transformar e converter eventos, bem como observar mudanças na apresentação do sistema. É a classe de fronteira que trata das questões relativas à camada mais externa do sistema.
A classe control é usada para modelar um comportamento de controle específico de um ou alguns casos de uso. Geralmente estão controlando chamadas a classes de entidade. Por isso seu comportamento é muito ligado às ideias de coordenação, de ponte entre a camada mais externa do sistema (classes de fronteira) e a camada mais interna do sistema (classes de entidade).
A classe entity, modelamos comportamentos e informações que devem ser armazenados. É de responsabilidade das classes de entidade manter e atualizar informações relativas ao negócio do sistema, como: pessoas, eventos, objetos reais, ou qualquer outra informação ligada ao negócio ao qual o sistema está inserido. Por exemplo: em um sistema voltado para a área de ensino, provavelmente teremos uma classe de entidade chamada aluno, outra chamada disciplina e assim por diante.
MER (Modelo entidade-relacionamento)
O Modelo Entidade-Relacionamento (MER) é um tipo de modelo conceitual que descreve as entidades, seus atributos e como se relacionam. Considerado um modelo de alto-nível, tem como objetivo representar um arranjo de dados mais perto do mundo real, é um modelo abstrato desenvolvido pelo Prof. Peter Chen, a fim de representar as estruturas de dados de forma mais natural e mais próxima do mundo real dos negócios. Partindo desta afirmativa, podemos entender que o modelo reproduz aspectos abstratos que a estrutura possuirá no banco de dados da aplicação. Sendo assim, utilizamos os recursos do MER para desenvolver o Diagrama Entidade-Relacionamento (DER) o qual é a sua representação gráfica conforme imagem abaixo.
Figura 03: DER (Diagrama Entidade-Relacionamento).
Fonte: Autores.
1.8. Diagrama Entidade Relacionamento
Um diagrama entidade-relacionamento (ER) é um tipo de fluxograma que ilustra como entidades, pessoas, objetos ou conceitos, se relacionam entre si dentro de um sistema. Diagramas ER são mais utilizados para projetar ou depurar bancos de dados relacionais nas áreas de engenharia de software, sistemas de informações empresariais, educação e pesquisa. Também conhecidos como DER, ou modelos ER, usam um conjunto definido de símbolos, taiscomo retângulos, diamantes, ovais e linhas de conexão para representar a interconectividade de entidades, relacionamentos e seus atributos.
2. Prototipagem das telas
	Tela 01 – Login: nesta tela o usuário poderá entrar com seu login e senha desde que este já exista.
	
	Tela 02 – Cadastro de usuário: nesta tela o usuário poderá fazer o cadastro de um login e senha. Esta operação só poderá ser feita se o usuário logado for administrador do sistema – nível mais alto de acesso. 
	
	Tela 03 – Cadastro de produto: nesta tela o usuário poderá fazer o cadastro de produto com todos os dados necessários para cada produto. Usado sistema para cadastro, consulta, atualização e remoção de produto. 
	
	Tela 04 – Cadastro de cliente: nesta tela o usuário poderá fazer o cadastro de cliente inserindo todos os dados pertinentes a cada cliente. Usado sistema para cadastro, consulta, atualização e remoção de cliente.
	
	Tela 05 – Venda de produto: nesta tela o usuário tem acesso aos dados da venda do produto. Algumas operações são restritas para usuário de administrador. Aqui será inserido leitura de código de barras do produto e dados de clientes já cadastrados serão carregados diretamente do banco de dados.
	
3. CONCLUSÃO
No desenvolvimento deste trabalho foi possível utilizar e aprimorar os conhecimentos adquiridos nas disciplinas do bimestre. Foi possível discutir os assuntos e pensar como seria na realidade um software para uma empresa real. Tudo foi pensado e feito de maneira que atendesse todas os requisitos e normas para garantir a melhor funcionalidade do sistema. Fontes que acreditou se serem aprimorados além do que estava descrito nos livros textos e vídeo aulas foram discutidas e reforçadas com buscas em bibliografias de outros autores, bem como troca de ideias com profissionais da área de tecnologia.
Com a elaboração do projeto foi possível concluir que será possível realizar um trabalho satisfatório perante o cliente e garantir o funcionamento do processo como um todo e a operação será feita de uma forma simples e pratica. Todas as facilidades foram possíveis devido a implementação das ferramentas estudadas no decorrer do bimestre. Todos os pré requisitos do projeto foram atendidos de forma satisfatória e tem se com isso a garantia de satisfação do cliente.
REFERENCIAS
ATE O MOMENTO. Caso de Uso – Include, Extend e Generalização. Disponível em: < http://www.ateomomento.com.br/caso-de-uso-include-extend-e-generalizacao/> Acesso em: 01/05/2021.
DEVMEDIA. Modelo Entidade Relacionamento (MER) e Diagrama Entidade-Relacionamento (DER). Disponível em: <https://www.devmedia.com.br/modelo-entidade-relacionamento-mer-e-diagrama-entidade-relacionamento-der/14332>. Acesso em: 05/06/2021.