UNIP INTERATIVA I NTERATIVA Projeto Integrado Multidisciplinar Cursos Superiores de Tecnologia
Sistema para Autopeças
Aluno: Júlio Júlio César Hermógenes. Hermógenes.
Unip (Balneário Camboriu) 2016
2
UNIP INTERATIVA Projeto Integrado Multidisciplinar Cursos Superiores de Tecnologia
Sistema para Autopeças
Aluno: Júlio César Hermógenes RA: 1416113 Curso: Análise e Desenvolvimento de Sistemas Semestre: 3º
UNIP (Balneário Camboriú) 2016
3
RESUMO
Este projeto tem por objetivo iniciar o desenvolvimento de um sistema para uma loja de autopeças. A empresa FICTÍCIA LTDA foi contratada por uma loja de autopeças localizada no Rio de Janeiro para sanar suas deficiências em seus processos com um sistema devidamente planejado, documentado e desenvolvido baseado em seus processos, necessidades, regras e requisitos. O gerente de projetos da empresa contratada deverá fornecer meios para que sua equipe possa desenvolver o sistema e fazer o levantamento necessário para isso, além de documentar os processos para sua equipe e para o cliente.
Palavras-chaves: Processos, Sistema, necessidades, regras, requisitos, documentar.
4
ABSTRACT
This project aims to initiate the development of a system for an auto parts store. The company Soother Ltd. was contracted by a auto parts store located in Rio de Janeiro to remedy its shortcomings in its processes with a properly planned system, documented and developed based on its processes, requirements, rules and requirements. The project manager of the contractor must provide ways for your team to develop the system and mapping required for this, in addition to document the processes for your team and for the client.
Keywords: Process, system, requirements, rules, requirements, document.
5
Sumário
RESUMO.................................................................................................................3 ABSTRACT .............................................................................................................4 INTRODUÇÃO ........................................................................................................6 1.
Casos do uso ................................................................................................7
1.1.
Especificação dos casos de uso ...................................................................7
1.1.1. Manter Produto .............................................................................................7 1.1.2. Manter Fornecedor .......................................................................................8 1.1.3. Manter Usuário .............................................................................................9 1.1.4. Consultar Produto .........................................................................................10 1.1.5. Consultar Fornecedor ...................................................................................11 1.1.6. Gerar relatório para balanço .........................................................................11 2.
Requisitos não funcionais .............................................................................12
2.1.
Padronização dos cadastros.........................................................................12
2.2.
Acesso a dados ............................................................................................13
2.3.
Manual de instalação ....................................................................................13
2.4.
Manual do usuário ........................................................................................13
2.5.
Acesso autenticado ......................................................................................13
2.6.
Senhas criptografadas ..................................................................................14
2.7.
Ambiente.......................................................................................................14
2.8.
Hardware ......................................................................................................14
2.9.
Ferramentas de Desenvolvimento ................................................................14
3.
Diagrama de classes ....................................................................................15
3.1.
Protótipos......................................................................................................15
CONCLUSÃO ..........................................................................................................17 REFERENCIAS .......................................................................................................18
6
Introdução
A loja RIO DE JANEIRO AUTOPEÇAS LTDA, localizada no Rio de Janeiro, possui processos falhos e deficientes. Seu proprietário, visando corrigir esses processos, contratou a empresa FICTÍCIA LTDA para sanar essas deficiências em seus processos, como muita ação humana no registro de informações e descontrole do estoque. Gerando grandes problemas, 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. Cabe ao gerente de projetos da empresa contratada identificar os casos de usos, assim como elaborar os modelos de casos de uso, os relacionamentos entre as entidades (classes) necessárias para o desenvolvimento do sistema, descrever os requisitos não funcionais e de usabilidade, identificar e descrever o contexto de uso e regras de negócio, elaborar os diagramas de classes de análise e os protótipos das telas principais. Com isso será possível desenvolver um sistema sólido, com o mínimo de erros e que se adeque e resolva problemas nos processos da loja, além de garantir a usabilidade do usuário, regras de negócios bem elaborados, prazos bem definidos e cliente satisfeito.
7
1. Casos do uso
Para o controle de estoque da empresa foi elaborado um diagrama de caso de uso que trata os setores da empresa, usuários comuns (padrão), usuários restritos e administradores do sistema. 1.1. Especificação dos casos de uso 1.1.1.
Manter 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: 1. O operador faz logon no Sistema. 2. O operador escolhe no menu qual ação à ser executada: A. Alterar - B. Incluir - C. Excluir. 3. Se o operador escolher a opção Alterar: 3.1. É solicitado código do produto para que seja efetuada a sua devida alteração. 3.2. Após feita a alteração, os novos dados são salvos. 4. Se o operador escolher a opção Excluir: 4.1. É solicitado o código do produto para que seja efetuada a sua devida exclusão. 4.2. Após a exclusão, o cadastro do produto é apagado do sistema. 5. Se o operador escolher a Opção Incluir:
8
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. 1.1.2.
Manter 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: 1. O operador faz logon no Sistema. 2. O operador escolhe no menu qual ação à ser executada: A. Alterar - B. Incluir - C. Excluir. 3. Se o operador escolher a opção alterar: 3.1. É solicitado o CNPJ do fornecedor para que seja efetuada a sua devida alteração. 3.2. Após feita a alteração, os novos dados são salvos. 4. Se o operador escolher a opção excluir: 4.1. É solicitado o CNPJ do fornecedor para que seja efetuada a sua devida exclusão.
9
4.2. Apó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 fornecedor. 5.2. O sistema verifica se o CNPJ do fornecedor é um número válido. 5.3. 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. 1.1.3.
Manter 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: 1. O operador faz logon no Sistema. 2. O operador escolhe no menu qual ação à ser realizada: A. Alterar - B. Incluir – C. Excluir. 3. 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.2. Após feita a alteração, os novos dados são salvos. 4. Se o operador escolher a opção Excluir:
10
4.1. É solicitado o nome do usuário para que seja efetuada a sua devida exclusão. 4.2. Após a exclusão, o cadastro do usuário é 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: A. Usuário Padrão - B. Usuário Restrito - C. 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. 1.1.4.
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: 1. O operador faz logon no Sistema. 2. O sistema solicita informações do produto a ser consultado. 3. O usuário faz a digitação dos dados do produto. 4. A consulta é realizada e as informações do produto são exibidas na tela. 5. O sistema oferece ao usuário a opção de impressão. 6. O sistema fecha a tela de exibição.
11
Pós-condições: A consulta ao produto foi realizada. 1.1.5.
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: 1. O operador faz logon no Sistema. 2. O sistema solicita CNPJ do fornecedor à ser consultado. 3. O usuário faz a digitação dos dados do fornecedor. 4. A consulta é realizada, e os dados do fornecedor são exibidos na tela. 5. O sistema oferece ao usuário a opção de impressão. 6. O operador fecha a tela de exibição. Pós-condições: A consulta aos dados do fornecedor foi realizada.
1.1.6.
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 envolvidos: Setor comercial. Pré-condições: O usuário deve ser identificado pelo sistema. Fluxo principal: 1. O operador faz logon no Sistema.
12
2. O sistema solicita a data ou período. 3. O usuário faz a digitação do período. 4. O relatório é exibido na tela. 5. O sistema oferece ao usuário a opção de impressão. 6. O operador fecha a tela de exibição. Pós-condições: O relatório para balanço por período foi gerado.
2. Requisitos não funcionais
Para desenvolvimento, implantação e utilização do sistema, deve ser correspondido os seguintes requisitos não funcionais: 2.1. Padronização dos cadastros
Todos os cadastros do sistema deverão obedecer a um mesmo padrão de usabilidade, os quais permitam: a) Acesso direto ao registro pelo seu ID. b) Acesso ao registro através de uma Pesquisa avançada c) Operação de Inserir, permitindo a inserção de um novo registro; d) Operação de Alterar, permitindo a alteração do registro selecionado; e) Operação de Excluir, permitindo a exclusão do registro selecionado; f) Operação de Salvar, permitindo a conclusão do processo de inserção ou de alteração, persistindo os dados; g) Operação de Cancelar, permitindo a desistência do processo de inserção ou de alteração, descartando os dados; h) Operação de Fechar, permitindo a saída da tela de cadastro;
13
A tela de Pesquisa Avançada deverá ser padrão para todos os cadastros, permitindo filtragem por qualquer campo do registro, de 3 formas: a) Início: somente registros cujo campo selecionado inicia com o valor informado são retornados; b) Meio: somente registros cujo campo selecionado contém o valor informado são retornados; c) Fim: somente registros cujo campo selecionado termina com o valor informado são retornados; Se algum dos campos do registro for uma data, a pesquisa avançada ainda permitirá a filtragem de registros através do fornecimento de um intervalo de datas, através do qual será possível filtrar registros cujo campo de data selecionado esteja no dado intervalo. 2.2. Acesso a dados
Todo acesso a dados deverá ser realizado via ODBC de forma a reduzir o acoplamento entre código e banco de dados. 2.3. Manual de instalação
O sistema deve vir acompanhado com um manual de instalação em formato PDF. 2.4. Manual do usuário
O sistema deve vir acompanhado com um manual de operação para o usuário final, em formato PDF. 2.5. 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.
14
2.6. Senhas criptografadas
As senhas dos usuários da aplicação devem ser armazenadas de forma criptografada no banco de dados da aplicação. 2.7. Ambiente
O sistema, composto de 2 partes, tem os seguintes requisitos de ambiente: a) Aplicação Cliente: Deverá ter como alvo principal o Windows 8.1, com .NET Framework 4.5 instalado; b) Banco de Dados: Deverá ser empregado qualquer sistema operacional que suporte o Microsoft SQL Server 2012. O sistema funcionará em qualquer rede TCP/IP que permita comunicação remota através de ODBC ou Client do SQL Server da aplicação Cliente ao servidor de Banco de dados. Quaisquer firewalls devem ser configurados para permitir essa comunicação. 2.8. Hardware
O sistema, composto de 2 partes, tem os seguintes requisitos de hardware: a) Aplicação Cliente: Mínimo de 128mb de memória livres para a operação do sistema; b) Banco de Dados: Os mesmos requisitos de hardware do SQL Server 2012. 2.9. Ferramentas de Desenvolvimento
O sistema deverá ser desenvolvido utilizando o Visual Studio 2013, aproveitando suas funcionalidades de testes unitários e cobertura de código. Para banco de dados, serão utilizados o SQL Server e o SQL Server Management Studio.
15
3.
Diagrama de classes 3.1. Protótipos
A tela para manter o produto será como mostra a Imagem 1 a seguir:
Imagem 1 - Protótipo Manter Produto. Fonte: Autoria própria
A tela para manter o fornecedor será como mostra a Imagem 2 a seguir:
Imagem 2 - Protótipo Manter Fornecedor. Fonte: Autoria própria
16
A tela para manter o usuário será como mostram as Imagem 3 a seguir:
Imagem 3 - Protótipo Manter Usuário. Fonte: Autoria própria
17
Conclusão
Com a utilização de técnicas de levantamentos de requisitos, documentação dos mesmos, diagramas e protótipos um projeto pode ser otimizado no que diz respeito a gerenciamento, mudanças de regras de negócio, planejamento, acompanhamento pelos usuários envolvidos assim como promover uma maior interação do próprio usuário no ciclo de vida de desenvolvimento do software. Neste projeto conseguimos analisar todas essas fases para sanar uma dificuldade em um dos processos do nosso cliente, a loja de auto-peças localizada no Rio de Janeiro. Concluiu-se que para poder desenvolver um software de qualidade e que atenda ao processo, requisitos e expectativas do cliente é necessário aplicar técnicas de análise de sistemas orientados a objetos, otimizar a interface com o usuário através de protótipos, aplicar técnicas de gerenciamento de projeto e engenharia de software e o próprio desenvolvimento do sistema orientado a objeto. Com isso podemos otimizar o tempo de desenvolvimento, mensurar de forma mais precisa o cronograma, prazos e custos, analisar de forma precisa os requisitos do sistema e gerar um produto altamente estável e funcional.
18
Referências
BECK., and Kent. TDD Desenvolvimento Guiado por Testes. Bookman, 2010. VitalBook file. Disponível em: . Acesso em: 08 de junho de 2016. Mauro, PEZZÈ,, and YOUNG, Michal. Teste e Análise de Software: Processos, Princípios e Técnicas. Bookman, 2008. VitalBook file. Disponível em: . Acesso em: 08 de junho de 2016. Myers, G. J.,The Art of Software of Testing. 2nd edition; Hoboken, New Jersey: John Wiley & Sons; 2004. Maldonado, J. C.; Barbosa, E. F.; Vincenzi, A. M. R.; Delamaro, M. E.; Souza, S. R. S.; Jino, M. Introdução ao teste de software. Relatório Técnico 65 Versão 2004-01, Instituto de Ciências Matemáticas e de Computação – ICMC-USP. BURNSTEIN, I. Practical software testing: a process-oriented approach., New York: Springer, 2003, 709p. LEWIS, W. E.; VEERAPILLAI, G.. Software Testing and Continuous Quality Improvement. 2.ed., Florida: Auerbach, 2005, 534p. FOWLER, M; SCOTT, K. UML Essencial. Porto Alegre: Bookman, 2000.
