PIM VI Sistema de Autopeças

Prévia do material em texto

17
UNIVERSIDADE PAULISTA -UNIP
SEPI – SISTEMA DE ENSINO PRESENCIAL INTERATIVO
BERGERES BEANNI FERNANDES FARRINELI
PROJETO INTEGRADO MULTIDISCIPLINAR VI
Sistema de venda de passagem de ônibus
Cremação - Belém PA 2019
BERGERES BEANNI FERNANDES FARRINELI
PROJETO INTEGRADO MULTIDISCIPLINAR VI
Sistema de venda de passagem de ônibus
Nome: Bergeres Beanni Fernandes Farrineli
Matricula: UP18226915
Curso: Análise e Desenvolvimento de Sistemas
Cremação - Belém PA 2019
RESUMO
Este Projeto Integrado Multidisciplinar tem como principal objetivo o desenvolvimento de um “software” para atender as necessidades de uma loja de autopeças localizada no Rio de janeiro. Adotando o conhecimento e técnicas que nos foram passadas no primeiro e segundo semestre do curso de Análise e Desenvolvimento de Sistemas, foi possível elaborar e desenvolver o programa de forma a cumprir todos os requisitos do projeto. 
Os problemas da empresa é com estoque e comissão dos colaboradores gerando diversos problemas a empresa, com isso podemos analisar e avaliar os requisitos necessários para elaboração da documentação, protótipos e os diagramas para apresenta-lo ao cliente a melhor solução possível.
Palavras-chave: Projeto. Desenvolvimento. Software.
ABSTRACT
	This Integrated Multidisciplinary Project has as main objective the development of a software to meet the needs of an auto parts store located in Rio de Janeiro. Adopting the knowledge and techniques that were passed to us in the first and second semester of the Systems Analysis and Development course, it was possible to elaborate and develop the program in order to fulfill all the requirements of the project.
	The problems of the company is with stock and commission of employees generating various problems to the company, with this we can analyze and evaluate the requirements needed to produce documentation, prototypes and diagrams to present it to the customer the best possible solution.
Keywords: Project. Development. Software.
SUMÁRIO
1 INTRODUÇÃO	7
2 REQUISITOS FUNCIONAIS	8
2.1 USUÁRIO	8
2.2 PERMISSÕES DE USUÁRIO	8
2.2.1 ADMINISTRADOR	8
2.2.2 USUÁRIO PADRÃO	8
2.2.3 USUÁRIO AUXILIAR	9
2.3 FORNECEDOR	9
2.4 PRODUTO	9
2.5 PEDIDO	9
2.6 AJUSTES	9
2.7 RELATÓRIO DE BALANÇO	9
2.71 RELATÓRIO DE PRODUTO POR FABRICANTE	9
2.72 RELATÓRIO DE COMISSÃO	9
3 REQUISITOS NÃO FUNCIONAIS	10
3.1 PADRONIZAÇÃO DOS CADASTROS	10
3.2 ACESSO A DADOS VIA ODBC	10
3.3 MANUAL DE USUÁRIO	10
3.4 ACESSO AUTENTICADO	11
3.5 SENHA CRIPTOGRAFADAS	11
3.6 AMBIENTE	11
3.7 HARDWARE	11
3.8 FERRAMENTAS DE DESENVOLVIMENTO	11
3.9 CRYSTAL REPORTS	12
4 DIAGRAMA DE CASO DE USO	12
5 ESPECIFICAÇÃO DOS CASOS DE USO	13
5.1 ESPECIFICAÇÃO: PRODUTO	13
5.2 ESPECIFICAÇÃO: FORNECEDOR	14
5.3 ESPECIFICAÇÃO: USUÁRIO	14
5.4 ESPECIFICAÇÃO: CONSULTAR PRODUTO	15
5.6 ESPECIFICAÇÃO: GERAR RELATÓRIO PARA BALANÇO	16
5.7 ESPECIFICAÇÃO: GERAR RELATÓRIO DE COMISSÃO	17
6 DIAGRAMA DE CLASSE	18
7 DIAGRAMA DE ATIVIDADE	19
7.1 DIAGRAMA DE USO USUÁRIO	19
7.2 DIAGRAMA DE USO FORNECEDOR	19
7.3 DIAGRAMA DE USO GERAR RELATÓRIO PARA BALANÇO	20
7.4 DIAGRAMA DE USO AJUSTE	21
7.5 DIAGRAMA DE USO CONSULTAR PRODUTO	22
7.6 DIAGRAMA DE USO GERAR RELATÓRIO COMISSÃO	23
8 PROTOTIPO DE TELAS	25
9 CONCLUSÃO	31
10	Bibliografia	31
Índice de figuras
Figura 1 - Diagrama de caso de uso	12
Figura 2 - Diagrama de classe	18
Figura 3 - Driagrama de uso usuário	19
Figura 4 - Diagrama de uso fornecedor	20
Figura 5 Diagrama de uso relatório de balanço	21
Figura 6 - Diagrama de uso de ajuste	22
Figura 7 Diagrama de uso consultar produto	23
Figura 8 Diagrama de uso relatório de comissão	24
Figura 9 tela de login	25
Figura 10 Tela busca de produto	25
Figura 11 Tela de cadastro de produto	26
Figura 12 Tela de informações do produto	26
Figura 13 Dados fiscais do produto	27
Figura 14 Tela busca usuário	27
Figura 15 Cadastro de usuário	28
Figura 16 Tela de permissões usuário	28
Figura 17 Tela de buscar fornecedor	29
Figura 18 Tela dados do fornecedor	29
Figura 19 Relatório de balanço	30
Figura 20 Relatório Comissão	30
6
1 INTRODUÇÃO
A loja a auto peças a qual nos contratou para realizar a criação de um software para corrigir diversos processos falhos em seu gerenciamento de estoque, devido a erros de acessos e operação humana ao registar itens e produtos de forma incorreta em seu conto de estoque. Com isso gerou diversos prejuízos financeiros a empresa, como; como cálculos incorretos no valor das comissões dos vendedores, atrasos nas compras de produtos para reposição de estoque, diminuição das vendas por falta de produtos no estoque, erros em dados importantes para o gestor da loja e prejuízos financeiros.
2 REQUISITOS FUNCIONAIS 
Uma função é descrita como um conjunto de entradas, seu comportamento e as saídas. Os requisitos funcionais podem ser cálculos, detalhes técnicos, manipulação de dados e de processamento e outras funcionalidades específicas que definem o que um sistema, idealmente, será capaz de realizar.
2.1 USUÁRIO
O sistema deve permitir realizar consulta, criar novo cadastro de usuário, atualização do cadastro e exclusão dos dados dos usuários. Cada usuário terá um login e senha de acesso ao sistema.
2.2 PERMISSÕES DE USUÁRIO
O sistema deve organizar os usuários em 3 grupos.
2.2.1 ADMINISTRADOR
Neste grupo de usuário estão todos aqueles responsáveis pelas operações administrativas, tendo acesso completo ao sistema.
2.2.2 USUÁRIO PADRÃO
Neste grupo de usuário estão aqueles responsáveis pelas operações padrões do sistema, com acesso a inserção e atualização de alguns dados, porém não sendo permitido a exclusão de informações. O caso de uso determinará os privilégios que este grupo terá em relação aos acessos.
2.2.3 USUÁRIO AUXILIAR
Neste grupo de usuário é somente para consulta.
2.3 FORNECEDOR
Deve-se ter um cadastro de todos os fornecedores dos produtos. Podendo incluir, excluir e alterar este cadastro.
2.4 PRODUTO
Os produtos consistem em todos os itens que o sistema irá controlar.
2.5 PEDIDO
Os pedidos consistem na gravação dos itens solicitados do pedido. Deve-se guardar a data e hora do pedido e o respectivo funcionário que fez o pedido.
2.6 AJUSTES 
Os ajustes consistem em um controle de devolução dos produtos para que se possa ajustar os itens de estoque.
2.7 RELATÓRIO DE BALANÇO 
O Relatório de Balanço deverá ser informado de acordo com o período solicitado, para comparação e metas de vendas.
2.71 RELATÓRIO DE PRODUTO POR FABRICANTE
O relatório demonstra uma lista dos produtos divididos em grupos de cada fabricante.
2.72 RELATÓRIO DE COMISSÃO
O relatório mostra a comissão do usuário por produto e totalizando a comissão.
3 REQUISITOS NÃO FUNCIONAIS
Requisitos não-funcionais são os requisitos relacionados ao uso da aplicação em termos de desempenho, usabilidade, confiabilidade, segurança, disponibilidade, manutenibilidade e tecnologias envolvidas.
3.1 PADRONIZAÇÃO DOS CADASTROS
Todos os cadastros do sistema deverão obedecer um mesmo padrão de usabilidade, os quais permitam:
Acesso direto ao registro pelo seu ID.
Acesso ao registro através de uma Pesquisa avançada 
Operação de Inserir, permitindo a inserção de um novo registro;
Operação de Alterar, permitindo a alteração do registro selecionado;
Operação de Excluir, permitindo a exclusão do registro selecionado;
Operação de Salvar, permitindo a conclusão do processo de inserção ou de alteração, persistindo os dados;
Operação de Cancelar, permitindo a desistência do processo de inserção ou de alteração, descartando os dados;
Operação de Fechar, permitindo a saída da tela de cadastro;
A tela de Pesquisa Avançada deverá ser padrão para todos os cadastros, permitindo filtragem por grupos conformecadastro.
Motor: caso usuário não digite nada no campo de pesquisa, o sistema irá listar todas as peças do grupo motor.
Transmissão: caso usuário não digite nada no campo de pesquisa, o sistema irá listar todas as peças do grupo transmissão.
Acessórios: caso usuário não digite nada no campo de pesquisa, o sistema irá listar todas as peças do grupo acessórios.
3.2 ACESSO A DADOS VIA ODBC
Todo acesso a dados deverá ser realizado via ODBC de forma a reduzir o acoplamento entre códigos e banco de dados.
3.3 MANUAL DE USUÁRIO
O sistema deve vir acompanhado com um manual de operação para o usuário final, em formato pdf, e através do botão HELP no sistema.
3.4 ACESSO AUTENTICADO
Todo acesso ao sistema deverá ser autenticado através do fornecimento de login e senha válidos. Tais dados de acesso deverão estar armazenados no banco de dados da aplicação
3.5 SENHA CRIPTOGRAFADAS
As senhas dos usuários da aplicação devem ser armazenadas de forma criptografada no banco de dados da aplicação
3.6 AMBIENTE
O sistema é composto de 2 partes com os seguintes requisitos:
Aplicação cliente: requisitos mínimos Windows 7 com .NET 3.5 instalado;
Banco de dados: utilizado o banco de dados mysql 4.5
O sistema funcionará em qualquer rede TCP/IP que permita comunicação remota através de ODBC da aplicação Cliente ao servidor de banco de dados, com a configuração do firewall para permitir a comunicação.
3.7 HARDWARE
O sistema é composto de 2 partes com os seguintes requisitos de hardware:
Aplicação Cliente: mínimo de 2GB de memória RAM e processador AMD ou INTEL de 2.5ghz.
Banco de dados: Requisitos do servidor compatível com Windows server 2008r2.
3.8 FERRAMENTAS DE DESENVOLVIMENTO
O sistema deverá ser desenvolvido utilizando o Visual Studio 2005, aproveitando suas funcionalidades de testes de unitários e cobertura de código.
Para banco de dados, será utilizado o MySQL.
3.9 CRYSTAL REPORTS
O sistema fará uso do “Crystal Reports for Visual Studio 2005” para a geração dos relatórios, permitindo assim a exportação dos relatórios para formatos XLS e PDF.
4 DIAGRAMA DE CASO DE USO
Figura 1 - Diagrama de caso de uso
5 ESPECIFICAÇÃO DOS CASOS DE USO
Caso de uso é uma técnica de especificação que descreve uma seqüência de ações que o sistema deve realizar para produzir uma resposta para um ator. Na realidade, tem-se uma seqüência da interação entre caso de uso e ator. O caso de uso detalha o que um sistema deve fazer, descrevendo como uma determinada funcionalidade é utilizada por um ator.
Cabe destacar que um caso de uso compreende duas partes: o diagrama de caso de uso e o caso de uso propriamente dito.  O diagrama de caso de uso é um dos nove diagramas da UML (Unified Modeling Language) enquanto que o caso de uso consiste de um template (ou modelo), conforme apresentado na seção seguinte, que serve para detalhar a seqüência de passos de execução do caso de uso.
5.1 ESPECIFICAÇÃO: PRODUTO
Objetivo
O operador usa o sistema para controlar os produtos do estoque, e os bens permanentes na entrada, saída, estorno e tombamento.
Atores Envolvidos
Usuário Padrão e Administrador do Sistema.
Pré-Condições	
O produto à ser cadastrado, deve ser oriundo de uma Nota Fiscal válida, ou seja de um Fornecedor cadastrado.
Fluxo Principal
O operador faz logon no Sistema.
O operador escolhe no menu qual ação à ser realizada: 1.Alterar -2.Incluir – 3.Excluir.
Se o operador escolher a opção Alterar: 
É solicitado código do produto para que seja efetuada a sua devida alteração.
Após feita a alteração, os novos dados são salvos.
Se o operador escolher a opção Excluir:
É solicitado o código do produto para que seja efetuada a sua devida exclusão.
 Após a exclusão, o cadastro do produto é apagado do sistema.
Se o operador escolher a Opção Incluir:
5.1 O sistema solicita os dados do novo produto.
5.2 O sistema verifica se o fornecedor do produto já é cadastrado no sistema.
5.3 Depois de validado o produto, o produto é incluído no estoque.
6. O sistema registra as informações fornecidas.
	
Pós Condições
O Sistema deve mostrar a quantidade do produto no estoque.
5.2 ESPECIFICAÇÃO: FORNECEDOR
Objetivo	
O operador usa o sistema para fazer a inclusão, exclusão e alteração no cadastro de Fornecedores.
Atores Envolvidos
Usuário Padrão e Administrador do Sistema.
Pré-Condições	
O usuário deve ser identificado pelo sistema.
Fluxo Principal
O operador faz logon no Sistema.
O operador escolhe no menu qual ação à ser realizada: 1.Alterar -2.Incluir – 3.Excluir.
Se o operador escolher a opção Alterar:
É solicitado o CNPJ do fornecedor para que seja efetuada a sua devida alteração.
Após feita a alteração, os novos dados são salvos.
Se o operador escolher a opção Excluir: 
É solicitado o CNPJ do fornecedor para que seja efetuada a sua devida exclusão. 
Após a exclusão, o cadastro do fornecedor é apagado do sistema.
Se o operador escolher a Opção Incluir: 
O sistema solicita os dados do novo fornecedor. 
O sistema verifica se o CNPJ do fornecedor é um numero válido. 
O fornecedor é incluso no cadastro de fornecedores.
6. O sistema registra as informações fornecidas.	
Pós Condições
O fornecedor foi cadastrado, alterado ou excluído no sistema.
5.3 ESPECIFICAÇÃO: USUÁRIO
Objetivo	
O Administrador usa o sistema para fazer a inclusão, exclusão e alteração dos usuários do sistema e suas devidas prioridades de acesso.
Atores Envolvidos
Administrador do Sistema.
Pré-Condições	
O usuário deve ser identificado pelo sistema.
Fluxo Principal
O operador faz logon no Sistema.
O operador escolhe no menu qual ação à ser realizada: 1.Alterar -2.Incluir – 3.Excluir.
Se o operador escolher a opção Alterar: 
3.1.É solicitado o nome do usuário para que seja efetuada a sua devida alteração.
3.2Após feita a alteração, os novos dados são salvos.
4. Se o operador escolher a opção Excluir: 
4.1.É solicitado o nome do usuário para que seja efetuada a sua devida exclusão. 
4.2Após a exclusão, o cadastro do fornecedor é apagado do sistema.
5. Se o operador escolher a Opção Incluir:
5.1.O sistema solicita os dados do novo usuário. 
5.2.È escolhida a prioridade de acesso ao sistema: 1.Usuário Padrão -2.Usuário Restrito – 3.Administrador . 
5.3.É definida senha de acesso.
6. O sistema registra as informações fornecidas.	
 
Pós Condições
O usuário foi cadastrado, alterado ou excluído no sistema.
5.4 ESPECIFICAÇÃO: CONSULTAR PRODUTO
Objetivo
O operador usa o sistema para consultar os produtos do estoque, e os bens permanentes na entrada, saída, estorno e tombamento.
Atores Envolvidos
Usuário Restrito, Usuário Padrão e Administrador do Sistema.
Pré-Condições	
O usuário deve ser identificado pelo sistema.
Fluxo Principal
O operador faz logon no Sistema.
O sistema solicita informações do produto à ser consultado.
O usuário faz a digitação dos dados do produto.
A consulta é realizada e as informações do produto são exibidas na tela.
O sistema oferece ao usuário a opção de impressão.
O sistema fecha a tela de exibição.
Pós Condições
A consulta ao produto foi realizada. 
5.5 ESPECIFICAÇÃO: CONSULTAR FORNECEDOR
Objetivo
O operador usa o sistema para consultar os fornecedores da empresa.
Atores Envolvidos
Usuário Restrito, Usuário Padrão e Administrador do Sistema.
Pré-Condições	
O usuário deve ser identificado pelo sistema.
Fluxo Principal
O operador faz logon no Sistema.
O sistema solicita CNPJ do fornecedor à ser consultado.
O usuário faz a digitação dos dados do fornecedor.
A consulta é realizada, e os dados do fornecedor são exibidos na tela.
O sistema oferece ao usuário a opção de impressão.
O operador fecha a tela de exibição.
Pós Condições
A consulta aos dados do fornecedor foi realizada. 
5.6 ESPECIFICAÇÃO: GERAR RELATÓRIO PARA BALANÇO
Objetivo
O operador usa o sistema para gerar um relatório para balanço, de todos os produtos do estoque.
Atores EnvolvidosSetor Comercial
Pré-Condições	
O usuário deve ser identificado pelo sistema.
Fluxo Principal
O operador faz logon no Sistema.
 	Clica no menu relatório
	Clica em relatório para balanço
O sistema solicita a data ou período.
O usuário faz a digitação do período.
O relatório é exibido na tela.
O sistema oferece ao usuário a opção de impressão.
O operador fecha a tela de exibição.
Pós Condições
O relatório para balanço por período, foi gerado.
5.7 ESPECIFICAÇÃO: GERAR RELATÓRIO DE COMISSÃO
Objetivo
O administrador usa o sistema para gerar um relatório de comissão, de todos os colaboradoes ou apenas um.
Atores Envolvidos
Administrador
Pré-Condições	
O usuário deve ser identificado pelo sistema.
Fluxo Principal
O administrador faz logon no Sistema.
 	Clica no menu relatório.
	Clica em relatório de comissão.
O sistema solicita a data ou período.
Apresenta dois check box um cheackbox para todos os colaboradoes, e um checkbox que abre o campo pesquisa para buscar apenas um colaborador.
O usuário faz a digitação do período ou data
Depois seleciona um dos checkbox
Se o checkbox selecionado for de pesquisa por colaborador, deverá digitar o nome.
O relatório é exibido na tela.
O sistema oferece ao usuário a opção de impressão.
O administrador fecha a tela de exibição.
Pós Condições
O relatório de comissão por período, foi gerado, ou relatório de comissão por colaborador gerado.
6 DIAGRAMA DE CLASSE
Figura 2 - Diagrama de classe
7 DIAGRAMA DE ATIVIDADE
7.1 DIAGRAMA DE USO USUÁRIO
Figura 3 - Driagrama de uso usuário
7.2 DIAGRAMA DE USO FORNECEDOR
Figura 4 - Diagrama de uso fornecedor
7.3 DIAGRAMA DE USO GERAR RELATÓRIO PARA BALANÇO
Figura 5 Diagrama de uso relatório de balanço
7.4 DIAGRAMA DE USO AJUSTE
Figura 6 - Diagrama de uso de ajuste
7.5 DIAGRAMA DE USO CONSULTAR PRODUTO
Figura 7 Diagrama de uso consultar produto
7.6 DIAGRAMA DE USO GERAR RELATÓRIO COMISSÃO
Figura 8 Diagrama de uso relatório de comissão
8 PROTOTIPO DE TELAS
Figura 9 tela de login
Figura 10 Tela busca de produto
Figura 11 Tela de cadastro de produto
Figura 12 Tela de informações do produto
Figura 13 Dados fiscais do produto
Figura 14 Tela busca usuário
Figura 15 Cadastro de usuário
Figura 16 Tela de permissões usuário
Figura 17 Tela de buscar fornecedor
Figura 18 Tela dados do fornecedor
Figura 19 Relatório de balanço
Figura 20 Relatório Comissão
9 CONCLUSÃO
A proposta do PIM foi desenvolver um sistema de controle de estoque e comissão em uma loja de auto peças, objetivando e remanejando o sistema para que não houvesse mais problemas nos setores estoque e financeiro. O sistema especialista no domínio do conhecimento no qual foi construído, demosntrando que os objetivos do cliente estão sendo alcançados e visando usuários de todas as idades com ou pouco conhecimento na área de informática pois a interface ficou bem limpa e objetiva, resolvendo os problemas do cliente.
Bibliografia
http://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408. (s.d.). http://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408. Fonte: http://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408: http://www.devmedia.com.br/o-que-e-uml-e-diagramas-de-caso-de-uso-introducao-pratica-a-uml/23408
https://pt.wikipedia.org/wiki/Diagrama_de_atividade. (s.d.). https://pt.wikipedia.org/wiki/Diagrama_de_atividade. Fonte: https://pt.wikipedia.org/wiki/Diagrama_de_atividade: https://pt.wikipedia.org/wiki/Diagrama_de_atividade
https://pt.wikipedia.org/wiki/Diagrama_de_caso_de_uso. (s.d.). https://pt.wikipedia.org/wiki/Diagrama_de_caso_de_uso. Fonte: https://pt.wikipedia.org/wiki/Diagrama_de_caso_de_uso: https://pt.wikipedia.org/wiki/Diagrama_de_caso_de_uso
https://pt.wikipedia.org/wiki/Diagrama_de_classes. (s.d.). https://pt.wikipedia.org/wiki/Diagrama_de_classes. Fonte: https://pt.wikipedia.org/wiki/Diagrama_de_classes: https://pt.wikipedia.org/wiki/Diagrama_de_classes
https://pt.wikipedia.org/wiki/Requisito_funcional. (s.d.). https://pt.wikipedia.org/wiki/Requisito_funcional. Fonte: https://pt.wikipedia.org/wiki/Requisito_funcional: https://pt.wikipedia.org/wiki/Requisito_funcional
https://pt.wikipedia.org/wiki/Requisito_n%C3%A3o-funcional. (s.d.). https://pt.wikipedia.org/wiki/Requisito_n%C3%A3o-funcional. Fonte: https://pt.wikipedia.org/wiki/Requisito_n%C3%A3o-funcional: https://pt.wikipedia.org/wiki/Requisito_n%C3%A3o-funcional
Wikipedia. (s.d.). wikipedia. Fonte: wikipedia: https://pt.wikipedia.org/wiki/Requisito_funcional
n Pioneira, 2005.