Você está na página 1de 15

UNIVERSIDADE PAULISTA – UNIP EaD

Projeto Integrado Multidisciplinar

CURSO SUPERIOR DE TECNLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

Projeto de sistema de controle de vendas de uma loja de jogos,


acessórios e produtos geek.

2022
SÃO PAULO
UNIVERSIDADE PAULISTA – UNIP EaD

Projeto Integrado Multidisciplinar – PIM VI

CURSO SUPERIOR DE TECNOLOGIA EM ANÁLISE E DESENVOLVIMENTO DE SISTEMAS

Projeto de sistema de controle de vendas de uma loja de jogos, acessórios e


produtos geek.

Nome(s) Completo(s) dos Aluno(s): Rafaella Macena, Wallace


Rodrigues, Tiago Alexandre
RA(s): 2176061 (Rafaella), 2189424 (Wallace), 2176587 (Tiago)
Curso: Análise e Desenvolvimento de Sistemas
Semestre:3º Semestre

2022
SÃO PAULO
RESUMO

O Projeto Integrado Multidisciplinar (PIM VI) tem como objetivo apresentar um


projeto que tem como objetivo de fazer um controle de vendas de uma loja de jogos,
acessórios e produtos geek. O projeto foi elaborado em cima do que aprendemos nas
disciplinas: Análise de Sistemas Orientada a Objetos, Banco de Dados e Gestão
Estratégica de Recursos Humanos, com o auxílio dessas matérias saber quais itens
são mais vendidos, qual o faturamento de cada semana, mês e ano.

Palavras-chave: Jogos, Vendas, Empresa.


ABSTRACT

The Integrated Multidisciplinary Project (PIM VI) aims to present a project that
aims to control the sales of a game store, accessories and geek products. The project
was designed based on what we learned in the subjects: Object-Oriented Systems
Analysis, Database and Strategic Management of Human Resources, with the help of
these materials, knowing which items are the most sold, what the revenue of each
week, month and year.

Keywords: Games, Sales, Company.


SUMÁRIO
1. INTRODUÇÃO ........................................................................................... 6
2. CASOS DE USO ........................................................................................ 7
2.1 CUSTOS DO PROJETO........................................................................... 8
3. REQUISITOS FUNCIONAIS ....................................................................... 8
4. REQUISITOS NÃO FUNCIONAIS .............................................................. 9
5. DESCRIÇÃO DE CASOS DE USO .......................................................... 10
5.1 CONTEXTO DE USO ............................................................................. 10
5.3 CONTEXTO DE AMBIENTE................................................................... 11
5.4 CONTEXTO DE CADASTRO ................................................................. 11
6. DIAGRAMA DE CLASSE ......................................................................... 12
7.CONCLUSÃO ............................................................................................ 14
8. REFERENCIAS ........................................................................................ 15
6

1. INTRODUÇÃO

Cada vez mais as inovações tecnológicas têm sido procuradas para


automatização, produtividade, segurança e muitos outros fatores trazendo muitas
melhorias para empresas, profissionais e pessoas que se beneficiam com essas
soluções.
E com essa grande mudança na área tecnológica uma loja de venda de jogos
eletrônicos, acessórios e produtos geek fechou um contrato para o desenvolvimento
de um software para controlar as vendas. Atualmente, as pequenas tarefas
gerenciadas para controlar vendas eram manipuladas utilizando planilhas em Excel.
E com isso foi feita toda a análise de requisitos, a identificação dos casos de uso onde
temos como principais casos de uso cadastros de clientes e de produtos, as consultas
e as exclusões relacionadas aos produtos que serão vendidos na loja, exclusão de
produto, cancelamento de venda, consulta de preço e os atores do sistema serão o
estoquista, o atendente e o supervisor, todos com login e senha com nível de acesso
para suas responsabilidades.
7

2. CASOS DE USO

Com base na reunião com o cliente para a criação de um sistema, foi


identificado os papeis que seriam executados considerando relacionamentos
com sistema sendo elas humanas ou de sistemas/hardwares. Analisando esses
requisitos de interação foi identificado os atores e as funções deles
relacionadas ao sistema, que são:
• Cliente
• Controle de estoque
• Operador de cartão de crédito
8

2.1 CUSTOS DO PROJETO

Para o desenvolvimento deste projeto de empréstimos, os custos serão


baixos, mas irá atender todos os requisitos de qualidade visando o custo-benefício.
Depois que o Colégio Sempre Vencer aceitar o projeto que foi oferecido, irão
começar as etapas para entregar o produto no prazo de 3 meses.
O custo do projeto final dando os gastos que teremos contratando um
analista de sistemas, programadores, analistas de qualidade e um coordenador de
projeto, incluindo as mãos de obras, mensalidade e os custos para pode
implementar esse projeto na escola, é de R$ 150.000,00. Já que o custo com a
equipe será em torno de R$ 60.000,00 durante os 3 meses e para obtermos lucro de
55% em cima do valor final cobrado.

3. REQUISITOS FUNCIONAIS

Descrevem explicitamente as funcionalidades e serviços do sistema, são de

extrema importância no desenvolvimento de aplicativos, pois, sem eles não há


funcionalidades nos sistemas. Seus modelos devem ser construídos em um nível de
entendimento claro e objetivo, além de um código fonte totalmente aplicável. Este
projeto contou com 3 fases, que são elas.

• Cadastro e login de usuários: para o sistema ser utilizado será


necessário realizar um cadastro e o login é a confirmação da
autenticação do usuário no sistema;
9

• Cadastro e controle de equipamentos: esta funcionalidade


ficara disponível apenas para o administrador. Onde ele irá
controlar data e hora da reserva, quem solicitou o serviço e
confirmações e cancelamentos;
• Ajuda e avisos: para o auxílio dos usuários o aplicativo vai
disponibilizar uma área de ajuda para caso de dúvidas, como
também vai disponibilizar um aviso para os usuários sobre as
entregas dos equipamentos quando estiver próximo ao
período final de reserva.

4. REQUISITOS NÃO FUNCIONAIS

Definem propriedades e restrições do sistema, definem características e


impõe limites do sistema como método de desenvolvimento, tempo e espaço. Podem
ser do sistema todo ou de partes do sistema. Este projeto contou com 3 fases, que
são elas:
• Desempenho: o cadastramento, consultas e reservas feitas
no sistema são bastante simples e pode ser feito de qualquer
plataforma;
• Permissões de usuários: o sistema controlará os acessos de
diferentes usuários;
• Manutenção: o sistema terá que ser atualizado toda vez que
um equipamento novo for inserido.
10

5. DESCRIÇÃO DE CASOS DE USO

Com o objetivo de auxiliar e facilitar a comunicação entre cliente e analistas, é


descrito em detalhes todas as funcionalidades do controle de vendas da loja de jogos
do sistema ao ponto de vista do usuário, proporcionando uma melhor qualidade e
usabilidade dentro do sistema
O objetivo principal do sistema pretendido é permitir que o usuário possa
realizar compra de jogos dos mais variados gêneros, estilos e a gosto do cliente, para
isso é necessário que o usuário seja capaz de se conectar à internet e de apresentar
através de uma interface com o layout do sistema (notebook, tablet, macbook,
smartphone entre os mais variados meios possíveis que ele consiga ter acesso)
Entretanto para isso será necessário que ele faça um cadastro na plataforma
caso seja seu primeiro acesso com seu login e senha. Futuramente caso o usuário
esqueça sua senha, poderá solicitar através de um link disponibilizado via SMS ou e-
mail informados dentro do perfil do cliente, sendo assim possível a modificação da
senha atual.

5.1 CONTEXTO DE USO

Abordaremos como atributos e requisitos para aqueles usuários novos, como


uma introdução do sistema para que assim podemos guiar o cliente e oferecer a
melhor produtividade e usabilidade dentro da plataforma:

USABILIDADE DO SISTEMA
ATRIBUTOS REQUISITO
Conhecimento do sistema Sites de compras online
Habilidade no teclado teclado do computador/smartphone
Habilidade no mouse mouse do computador
Qualificações Não requerido
Experiência na tarefa Não requerido
Experiência organizacional Não requerido
11

Dúvidas (sobre o sistema) Chat online disponível (24hrs)


ATRIBUTOS FÍSICOS REQUISITO
VISÃO Visão normal ou corrigida
AUDIÇÃO Não requerido (Suporte Hand Talk)
Mãos com destreza normal (Suporte
Destreza Manual TeamViewer)

5.3 CONTEXTO DE AMBIENTE

As conexões para acesso a plataforma devem estar disponíveis em Ponto de


acesso à Internet (WIFI, 3G, 4GH, BANDA LARGA, ROTEADOR)
Com o intuito de proporciona uma melhor fluidez no sistema e otimizar a
usabilidade do usuário, sendo assim o sistema deve ser usado com os padrões ideais
e especificados.

5.4 CONTEXTO DE CADASTRO

DESCRIÇÃO DO AMBIENTE DE EFETUAR LOGIN


IDENTIFICAÇÃO Efetuar login (acesso ao sistema)
ESCOPO loja de jogos
Propósito para permitir ao usuário acesso a
DESCRIÇÃO DO OBJETIVO
plataforma
Ator Cliente
Interesses Cliente e Empresa de jogos
Pré-condições deve possuir login e senha
Pós-condições efetuando login será direcionado a página de jogos
12

6. DIAGRAMA DE CLASSE

Um diagrama de classes é uma representação da estrutura com relações das


classes que servem como modelo para objetos. Sendo uma modelagem útil para o
desenvolvimento do sistema, pois fornece ajuda para definir e priorizar as classes que
o sistema poderá possuir.

Uma classe pode ser representada por um retângulo e possuir até três divisões:
• Nome da classe
• Atributo da classe
• Objeto da classe

Entity ou entidade, são informações e comportamentos que são armazenados no


sistema, normalmente são identificados como casos de uso.

Control ou controle, seu objetivo é realizar a coordenação de entrega das camadas


internas do sistema e camadas externas.

Boundary ou fronteira, possuem a responsabilidade de dividir o ambiente interno do


externo, podendo assim de forma sequencial representar as interações que um
sistema faz com os atores ou alimentar informações de outros sistemas.

A seguir apresentaremos o diagrama de classes baseado no sistema desenvolvido


para os clientes e fornecer informações conforme o seu processamento de
recebimento dos pedidos, verificação do produto, disponibilidade entre outras funções.
13
14

7.CONCLUSÃO

Conclui-se, o projeto teve como proposito desenvolver um sistema capaz de


gerenciar e automatizar o processo de venda da empresa, mostrando modelagem
desenvolvimento do sistema com um diagrama de processo, onde será mostrado o
processo de negócio do gerenciamento do estoque até conclusão da venda do
produto.
15

8. REFERENCIAS

http://www.univasf.edu.br/~jorge.cavalcanti/Ihm5_Engenharia%20de%20Usabili
dade.pdf

http://www.inf.puc-
rio.br/~inf1403/docs/alberto2011_1/18_Design_Requisitos.pdf

https://mestresdaweb.com.br/tecnologias/requisitos-funcionais-e-nao-
funcionais-o-que-
sao/#:~:text=Os%20requisitos%20n%C3%A3o%20funcionais%20s%C3%A3o,fu
ncionais%20descrevem%20como%20ser%C3%A3o%20feitos.

https://creately.com/

https://www.lucidchart.com/pages/pt/o-que-e-diagrama-de-classe-uml

https://www.ateomomento.com.br/uml-diagrama-de-classes/

https://pt.slideshare.net/Portal_do_estudante_ADS/diagramas-de-distribuicao

https://www.ateomomento.com.br/diagramas-uml/

https://www.devmedia.com.br/qualidade-de-software/9408

Você também pode gostar