PONTIFÍCIA UNIVERSIDADE CATÓLICA DE CAMPINAS

João Pedro Duarte Giatti

Gabriel Henrique Pera Coelho
Lucas Clara Sampaio
Gabriel de Oliveira Mansur
Flávio Augusto Dario de Moraes

RELATÓRIO DE PROJETO:

STOCKX

CAMPINAS
2024
PONTIFÍCIA UNIVERSIDADE CATÓLICA DE CAMPINAS
ESCOLA POLITÉCNICA
ENGENHARIA DE SOFTWARE

João Pedro duarte Giatti

Gabriel Henrique Pera Coelho
Lucas Clara Sampaio
Gabriel de Oliveira Mansur
Flávio Augusto Dario de Moraes

RELATÓRIO DE PROJETO:
StockX

Relatório de projeto de sistema, apresentado no componente curricular

Projeto Integrador I, do curso de Engenharia de Software, da Escola
Politécnica da Pontifícia Universidade Católica de Campinas.

Orientador: José Marcelo Traina Chacon

CAMPINAS
2024
 SUMÁRIO

1. INTRODUÇÃO 1
2. JUSTIFICATIVA 2
3. OBJETIVOS 3
4. ESCOPO 4
5. NÃO ESCOPO 5
6. REQUISITOS FUNCIONAIS 6
7. REQUISITOS NÃO FUNCIONAIS 10
8. METODOLOGIA APLICADA AO PROJETO 11
9. ACOMPANHAMENTO DA GESTÃO DO PROJETO 13
10. PREMISSAS 14
11. RESTRIÇÕES 15
12. PRINCIPAIS TELAS DO SISTEMA, DESCRIÇÃO FUNCIONAMENTO 16
13. CONCLUSÃO 17
13.1 Resultados obtidos 17
13.2 Sugestões de melhorias 17
REFERÊNCIAS 18
 1

1. INTRODUÇÃO

Ultimamente, há uma deficiência na disponibilidade de softwares ágeis, rápidos e

intuitivos no âmbito de gerenciamento de estoque – o que se torna uma grande
busca de empreendedores a respeito de um sistema digno. Além de que, desde a
revolução dos softwares, na década de 1970, o preço de sistemas
computacionais de gerenciamento de lojas, produtos, estoques e vendas no geral,
é alvo de um crescimento exponencial, desencadeando em uma deficiência de
estabelecimentos físicos na busca de um sistema simples, bom e barato.

De acordo com a IDC(International Data Corporation), ou a grande brasileira

ABES(Associação Brasileira de Empresas de Software), é possível ver um
aumento significativo de quase 30% na busca de softwares para gerenciamento
de comércio por parte de pequenas e médias empresas. O que reflete
significativamente na importância moderna quanto ao uso de sistemas para
garantir um bom negócio. Tais dados foram minuciosamente analisados por
nossos integrantes a fim de reverter esse cenário em partes, atingindo essas
empresas para um passo evolução de tais métodos com a tecnologia.

Nossa equipe dispõe de metodologias “direto ao ponto” e com exatamente os

requisitos que o cliente busca, barateando assim a mão de obra no
desenvolvimento do software e diminuindo o tempo de produção. Visando todavia,
estabelecer paradigmas que se encaixem em qualquer estilo de negócio que lide
com estoques e produtos. Ademais, o software contará com intuitividade em suas
funcionalidades, facilitando quaisquer processos que demandem um funcionário,
como o próprio cadastro de produtos, por exemplo.
 2

2. JUSTIFICATIVA

Por que é necessário um software de gerenciamento de estoque?

Desde o estopim da Terceira Revolução Industrial (1950 até os dias atuais),

houve uma significativa junção entre o comércio/indústria à tecnologia, gerando
uma necessidade contínua da tecnologia e softwares como cooperadores no
gerenciamento de um negócio. No terceiro quadrimestre de 2023, MEIs
representam 73,6% das empresas abertas, superando um aumento de 5,8% em
relação ao terceiro quadrimestre de 2022 – dado este que reflete o aumento
significativo semestral do surgimento de empresas de médio ou pequeno porte. E
devido a demanda, a expressamente maioria depende ou dependerá de um ou
mais softwares para gerenciar a própria empresa. Neste cenário, aplica-se em
grande parte a necessidade de um sistema de gerenciamento de software, se e
somente se estas se relacionam no âmbito de comércio e vendas.
Outro ponto notável, é a aplicação deste software, tanto em vendas de produtos
físicos, quanto online. Integrando um negócio físico, em outro, graficamente
aplicado em um banco de dados, possibilitando um maior controle do gerente
quanto aos estoques de sua própria empresa.
Desse modo, é possível notar a crescente demanda mundial por sistemas do tipo,
e que por sua vez consiga lidar com lojas virtuais ou físicas, abrangendo o público
alvo.
 3

3. OBJETIVOS

OBJETIVO GERAL DO PROJETO

Nosso objetivo geral será desenvolver um sistema de controle de estoque, cálculo

de preço de venda, percentuais e classificação de lucro.

OBJETIVOS ESPECÍFICOS DO PROJETO

1. Levantar os requisitos necessários para o sistema, considerando as necessidades

específicas da empresa em relação ao controle de estoque e cálculo de preço de venda.

2. Projetar a arquitetura do sistema, definindo as funcionalidades principais e a integração

com outros sistemas existentes na empresa.
3. Desenvolver as funcionalidades básicas do sistema, incluindo cadastro de produtos,
controle de estoque e cálculo de preço de venda.
4. Implementar a lógica de cálculo de preço de venda, considerando os percentuais de
custo e lucro estabelecidos pela empresa.
5; Garantir segurança e sigilo dos dados da empresa com sistema de criptografia.
6. Testar o sistema de forma exaustiva, garantindo que todas as funcionalidades estejam
operando corretamente e atendendo aos requisitos estabelecidos.
7. Apresentar o sistema à banca examinadora, demonstrando sua eficácia e a
contribuição para a melhoria dos processos internos da empresa.
 4

4. ESCOPO

Nosso objetivo ao desenvolver esse sistema é facilitar para os funcionários com a

catalogação dos produtos e ajudar as empresas a melhorarem sua organização
em relação aos produtos do estoque e, com isso, otimizarem suas compras,
vendas e também melhorar o tempo de entrega do produto para o cliente. Para
isso, será necessário que o funcionário forneça ao sistema os dados do produto.
Com os dados obtidos, o sistema perguntará ao usuário se ele deseja catalogar
ou retirar o produto. Esses dados ficarão salvos em um banco de dados, onde os
funcionários poderão acessar assim que quiserem. O sistema será desenvolvido
em Python.
 5

5. NÃO ESCOPO

Ao contrário do escopo, o não escopo são as funções que não serão

implantadas no sistema por falta de necessidade ou qualquer outro motivo. Em
nosso sistema, o não escopo será:

● Interface gráfica.

● Não serão necessárias informações adicionais como email, celular.

● Recuperação de senha.

● Anexo de arquivos.

● Alteração de requisição.
 6

6. REQUISITOS FUNCIONAIS

Caso de Uso:
RF_F1: Menu
Descrição:
Quando o funcionário acessar o sistema será a área em que ele deverá escolher
o que será feito.
Ator Principal:
Funcionário
Pré-condições:
O usuário deverá ter um computador com acesso ao sistema da empresa e com
acesso a internet.
Validações:
Números e letras
Requisitos especiais:
Não Aplicável
Fluxo principal:

Ações do ator Ações do sistema

Tela de Entrada
Solicitar escolha da função entre
Escolhe uma das funções
Se selecionar opção= 1, chama
RF_F2:INSERIR
Se seleccionar opção=2, chama RF_F3:
VISUALIZAR
Se seleccionar opção=3, chama RF_F4:
ALTERAR
Se seleccionar opção=4, executa
RF_F5:EXCLUIR

Se seleccionar opção=5, executa

RF_F6:CRIAR TABELA

Se seleccionar opção=6, executa

RF_F7:ZERAR TABELA

Se seleccionar opção=7, executa

RF_F8:CLASSIFICAR LUCRO
 7

Se selecionar opção=8(SAIR)
Saia do programa
 8

Caso de Uso:
RF_F2: INSERIR
Descrição:
Quando o funcionário estiver com os dados de um produto novo na qual não foi
registrado ainda, dessa maneira irá calcular o preço da nova mercadoria e irá
inseri-la no banco de dados.
Ator Principal:
Funcionário.
Pré-condições:
O usuário tem ciência das características e do código do produto.
Validações:
Código e tipo do produto.
Requisitos especiais:
Não Aplicável
Fluxo principal:

Ações do ator Ações do sistema

Solicita os dados do produto e seu
código.
Insere dados e as características do
produto.
Verifica dados inseridos.
Calcula-se o preço do produto.
Criptografa a descrição
Inserir o produto no banco de dados.
Apresenta uma tela de sucesso, o valor
que deverá ser colocado no produto e a
margem de lucro que o produto terá
Voltar para o RF_F1: menu.

Caso de Uso:
RF_F3: Visualizar
Descrição:
 9

Quando o usuário estiver querer visualizar a tabela para saber o que foi inserido e
mostrar seus dados.
Ator Principal:
Funcionário.
Pré-condições:
Conter algum produto no banco de dados
Validações:
Não Aplicável.
Requisitos especiais:
Não Aplicável
Fluxo principal:

Ações do ator Ações do sistema

Descriptografa a Descrição

Mostra a tabela produto do banco de

dados
Voltar para o RF_F1: menu.

Casos de uso:
RF_F4: ALTERAR.
Descrição:
Quando o funcionário precisar modificar algum tipo de dado sobre algum produto,
deve utilizar essa opção.
 10

Ator Principal:
Funcionário.
Pré-condições:
Conhecimento do produto para poder modificá-lo.
Validações:
Dados do produto para modificá-lo e conhecimento de qual produto deve-se
modificado.
Requisitos especiais:
Não Aplicável.
Fluxo principal:

Ações do ator Ações do sistema

Mostra uma tabela de itens já
cadastrados com opção de procura.
Mostra todos os dados do item e deixa o
usuário editar, com um botão de salvar
logo abaixo.
Espera a escolha de um dos itens.
Escolhe um dos itens
Escreve as informações que deverão ser
modificados
Sobrescrever as informações que
estavam no banco de dados pelas
escritas pelo usuário
Voltar para o RF_F1: menu

Caso de Uso:
RF_F5:EXCLUIR.
Descrição:
Quando o funcionário precisar excluir algum tipo de produto por motivos de venda
ou qualquer outro.
Ator Principal:
Funcionário.
 11

Pré-condições:
Saber procurar o produto e ter conhecimento do produto que deseja excluir.
Validações:
Produto que se deve excluir.
Requisitos especiais:
Não Aplicável.
Fluxo principal:

Ações do ator Ações do sistema

Mostra uma tabela de itens já
cadastrados
Espera a escolha de um dos itens
Escolhe um dos itens
Exclui o item
Voltar para o RF_F1: menu

Caso de Uso:
RF_F6: CRIAR TABELA
Descrição:
Criar a tabela para o sistema
Ator Principal:
Gerente.
Pré-condições:
Entrar na sistema
Validações:
 12

Não Aplicável
Requisitos especiais:
Não Aplicável

Fluxo principal:

Ações do ator Ações do sistema

Cria a tabela “Produtos”

Voltar para o RF_F1: menu.

Caso de Uso:
RF_F7: ZERAR TABELA
Descrição:
Quando é for necessário excluir todos os produtos do sistema
Ator Principal:
Gerente.
Pré-condições:
Entrar no sistema.
Validações:
 13

Não Aplicável
Requisitos especiais:
Não Aplicável

Fluxo principal:

Ações do ator Ações do sistema

Exclui a tabela “Produtos”

Cria a tabela “Produtos”

Voltar para o RF_F1: menu.

Caso de Uso:
RF_F8:CLASSIFICAR LUCRO
Descrição:
Quando for necessário o cálculo do lucro total dos itens adicionados no sistema.
Ator Principal:
Gerente.
Pré-condições:
Possuir itens na tabela original.
 14

Validações:
Não Aplicável
Requisitos especiais:
Não Aplicável

Fluxo principal:

Ações do ator Ações do sistema

Separa cada item em uma tabela

diferente

Mostra todas as informações de cara

item

Voltar para o RF_F1: menu.

7. REQUISITOS NÃO FUNCIONAIS

Desempenho:

O software precisa conseguir suportar muitos produtos e cadastros simultâneos

de forma rápida e eficiente.
 15

Usabilidade:

O visual e disposição de elementos, como botões, devem ser intuitivos, simples e

minimalistas.

Segurança:

O banco de dados deve requirir criptografia, e proteção de dados sem falhas, para
prevenir ataques ou roubo de informações.

Regulamentação:

O sistema deve cumprir com normas de proteção de dados, padrões de indústria

e não ferir nenhuma regulamentação.

Confiabilidade:

O software deve passar confiança e exibir ao usuário toda a regulamentação de

proteção de dados e do usuário em si.
 16

8. METODOLOGIA APLICADA AO PROJETO

Para o desenvolvimento deste projeto foi aplicada a Metodologia de

Aprendizagem Baseada em Projetos (PBL), onde os alunos foram divididos em
Times e foram realizadas algumas etapas como: Introdução e Planejamento,
Coleta, Desenvolvimento, Pesquisa, Finalização e Publicação. Em todas as
etapas os Times realizaram atividades avaliativas e no final houve uma
apresentação do produto de software final.
Detalhamento das etapas:

● Introdução e Planejamento – organização da turma pelo professor em

Times com 5 pessoas. Explicação do processo de desenvolvimento do

projeto, apresentação do cronograma geral com as etapas avaliativas.
Explicação sobre o TEMA e Requisitos básicos do projeto.
Esclarecimento de dúvidas gerais sobre as etapas.

● Coleta – os Times deverão pesquisar os Requisitos Básicos

buscando referencias bibliográficas e artigos científicos que

contextualizem os requisitos no contexto do projeto. Deverão discutir e
definir que ferramentas de software de apoio (word, photoshop,
excel, project, canva, flame, e etc.) serão utilizadas para o
desenvolvimento do projeto. Deverão montar um Cronograma com as
atividades levantadas pelo Time e atribuir período de planejamento e
execução com nome dos responsáveis por cada atividade, se
atentando as datas de entrega avaliativas do professor. Todos os itens
produzidos nesta etapa serão documentados no modelo descritivo
(gerando um doc) e postados no CANVAS nas datas determinadas
pelo professor.

● Desenvolvimento – os Times deverão executar gradativamente as

etapas do projeto, com a execução da alimentação da documentação e

programação do sistema a ser desenvolvido, apresentar as atividades
seguindo etapas avaliativas através das reuniões com o professor.
 17

● Revisão – os Times devem reavaliar e readequar as atividades

apontadas pelo professor durante as reuniões como pontos a serem

revistos e corrigidos, e se for necessário, realizar novos estudos,
pesquisas, conversar com os outros professores das outras disciplinas
contribuintes, para o aperfeiçoamento do projeto.

● Finalização – processo de refinamento, realização de Testes e

finalização do projeto e da documentação a ser entregue, e preparação

da apresentação final. Cada Time será avaliado pelo professor através
de uma apresentação no próprio laboratório de informática
 18

9. ACOMPANHAMENTO DA GESTÃO DO PROJETO

htt
ps://trello.com/b/YXFgjIQA/1-semestre
 19

10. PREMISSAS

● O software será desenvolvido para ser utilizado em dispositivos desktop.

● Deve ser capaz de gerenciar múltiplos locais de armazenamento
● O software deve ser capaz de receber e enviar dados criptografados de
forma que não afete o resultado final do produto.
● A interface do usuário deve ser intuitiva e fácil de usar, visando a eficiência
operacional.
● Deve suportar múltiplos usuários com diferentes níveis de permissão de
acesso.
● Acesso a internet
 20

11. RESTRIÇÕES

● O projeto deve ser desenvolvido dentro do orçamento e prazo

definidos.
● Deve ser compatível com as tecnologias existentes na infraestrutura
da empresa.
● A segurança dos dados (criptografia) do estoque deve ser uma
prioridade, com medidas robustas de proteção contra acesso não
autorizado.
● Deve ser capaz de integrar-se com outros sistemas existentes,
como sistemas de contabilidade e sistemas de fornecedores.
● Deve ser escalável para lidar com o crescimento futuro do volume
de dados e necessidades do negócio.
 21

12. PRINCIPAIS TELAS DO SISTEMA, DESCRIÇÃO FUNCIONAMENTO

1. Tela do Menu

Na tela do menu, é possível visualizar as opções de telas/ações a

serem tomadas pelo usuário, cada uma contendo um valor de comando.
Logo abaixo, um campo para digitar o comando que levará a nova tela ou
execução de algum bloco de código.

TELAS:

● Cadastro de produtos
● Visualização da tabela
● Alterar Produto
● Excluir Produto
● Classificar Lucro

AÇÃO:

● Criar Tabela Produtos

● Zerar Tabela
● Sair

2. Tela de Cadastro
 22

Na tela de cadastro, o programa pede uma série de inputs, que

recebe do usuário as informações de um produto, as guarda em variáveis,
insere no banco de dados (conexão por ORACLEDB), caso os valores
inseridos correspondam ao tipo de dados da tabela. E por fim, imprime o
cálculo de Preço de Venda (PV).

O cálculo de PV oferece valores importantes em porcentagens e

percentual do valor bruto, para registro dos custos adjacentes e margem de
lucro, tanto em porcentagem, quanto em parcela do valor total.

Os tipos de classificação de lucro são: “Prejuízo”, “Equilíbrio”,

“Baixo”, “Médio” e “Alto”.

A visualização desta o de outras telas, foi usada a biblioteca

Colorama, que permite uma melhor leitura e paramentação das
funções/telas.

3. Tela de visualização da tabela

 23

Na tela de visualização de dados, é possível identificar facilmente os

produtos já cadastrados e seus respectivos valores atribuídos, com a
descrição já descriptografada, diferentemente da visualização direta pelo
banco de dados SQL (ORACLE).

4. Tela de Alterar Produto

Na tela de alterar um produto, o programa primeiramente mostra a

tabela descriptografada para consulta do usuário, e em seguida pergunta
qual o código do produto que o usuário deseja alterar.

Dado o valor, abre um formulário de novos valores para aquele

produto. Que são guardados em variáveis, assim como no cadastro, e
inseridas no banco de dados por meio do UPDATE.
 24

5. Excluir Produto

Na tela de exclusão de produtos, é possível excluir um produto com

o mesmo processo de alterar, ou seja, o programa imprima a tabela de
produtos para consulta do usuário, pergunta o código do produto que deve
excluir, e realiza a ação de deletar a linha do banco de dados, preservando
os demais produtos cadastrados.

6. Classificar Lucro
 25

Na tela de classificação de lucro, é executada a mesma função de cálculo

de Preço de Venda (PV) que ocorre após cadastrar um produto, porém, esta tela
prevê a necessidade do usuário consultar novamente este cálculo para cada
produto na tabela, junto com a impressão de suas variáveis únicas..
 26

13. CONCLUSÃO

Por fim, confirmamos que todos os objetivos do projeto foram

alcançados, pois temos em mãos um programa funcional que realiza a gestão de
produtos, como inserção, remoção e atualização. É importante ressaltar que
sistemas como esse são essenciais para a eficiência e produtividade de
empresas, pois são responsáveis pela rapidez e facilidade de realizar a gestão do
estoque.

Além disso, o desenvolvimento desse projeto possibilitou que os

integrantes do Time 2 aprendessem sobre tópicos como programação em python,
conexão de uma IDE com banco de dados, eficiência de código, trabalho em
equipe, organização e gestão de projetos. Tudo isso foi essencial para a
realização desse projeto.

1.1 Resultados obtidos

O programa entrega ao usuário um sistema que gerencia produtos no

estoque, na qual calcula seu valor de venda de acordo com os dados adicionados
e classifica a margem de lucro dos itens.

1.2 Sugestões de melhorias

Algumas sugestões levantadas durante o desenvolvimento foram

principalmente relacionadas a interface do programa. Por exemplo, foi
discutido a possibilidade de melhorias estéticas do menu do software e
mais diversidade nos botões.
Além disso, foi discutida a inserção de uma função de contagem de
estoque, no qual apresenta a quantidade que um determinado produto será
armazenado.
A equipe também considerou a possibilidade de criação de tabelas no
excel em tempo real baseado nas tabelas armazenadas no StockX, assim
 27

dando ao usuário uma forma alternativa e fácil de consultar sua lista de

estoque disponível.

REFERÊNCIAS

COLORAMA, Biblioteca Python.

Disponível em: <https://pypi.org/project/colorama/> Acesso em 23 de Maio de
2024

ORACLEDB, Biblioteca Python para conexão com Banco de Dados Oracle.

Disponível em: <https://pypi.org/project/oracledb/> Acesso em 23 de Maio de
2024

ORACLE, Banco de dados do projeto.

Disponível em: <https://www.oracle.com/br/database/> Acesso em 23 de Maio de
2024