pim completo pdf

Prévia do material em texto

Unip Polo Nazaré 
2020. 
 
 
 
 
UNIP INTERATIVA 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia- 
PIM V 
 
 
 
 
 
 
 
 
 
 
 
 
DESENVOLVIMENTO DE UM ROTEIRO DE TESTES PARA 
UM SISTEMA 
Unip Polo Nazaré 
2020. 
 
 
 
 
 
UNIP INTERATIVA 
Projeto Integrado Multid isciplinar 
Cursos Superiores de Tecnologia- 
PIM V 
 
 
 
 
 
 
DESENVOLVIMENTO DE UM ROTEIRO DE TESTES PARA 
UM SISTEMA 
 
 
 
 
 
 
 
Erick Patrik Alves da Fonseca 
UP - 19222259 
Curso: Analise e Desenvolvimento de Sistemas 
3º Semestre de 2020. 
 
 
 
 
 
 
RESUMO 
 
O projeto deve ser executado para que sirva de avaliação do PIM-V referente ao 
Curso superior Tecnológico em Analise e desenvolvimento de Sistemas, que será 
executado com base no aprendizado adquirido, conforme estudos das disciplinas de 
Engenharia de Software e Projeto de Interface com o usuário. 
O trabalho será realizado um teste de caixa preta de um sistema de formatação de 
artigos acadêmicos, com objetivo de verificar sua correção em relação ao 
comportamento esperado e mediante as falhas e erros serão registrados e 
reportados no relatório final. 
 
Palavras-chave: Engenharia de Software, teste caixa preta. 
 
 
 
 
 
 
ABSTRACT 
 
 
The project must be executed to serve as an evaluation of the PIM-V for the 
Technological Superior Course in Systems Analysis and Development, which will be 
executed based on the acquired learning, according to studies of the disciplines of 
Software Engineering and User Interface Design . The work will be carried out a black 
box test of a system of formatting of academic articles, with the objective of verifying 
its correction in relation to the expected behavior and through the failures and errors 
will be recorded and reported in the final report. 
 
 
 
 
Keywords: Software Engineering, Black-box Testing. 
 
 
 
 
SUMÁRIO 
 
 
1- INTRODUÇÃO ..................................................................................................... 6 
2- TESTES DE SOFTWARE ............................................................................ 7 
2.1 Técnicas de Teste de So†ware ..................................................................................... 7 
3-PLANEJAMENTO ................................................................................................. 8 
4 - PROJETO ........................................................................................................... 9 
5- IMPLEMENTAÇÃO ............................................................................................ 10 
6-EXECUÇÃO ........................................................................................................ 11 
Caso de teste 1 ............................................................................................................. 11 
Caso de teste 2 ............................................................................................................. 12 
Caso de teste 3 ............................................................................................................. 13 
Caso de teste 4 ............................................................................................................. 14 
Caso de teste 5 ............................................................................................................. 15 
Caso de teste 6 ............................................................................................................. 16 
Caso de teste 7 ............................................................................................................. 17 
Caso de teste 8 ............................................................................................................. 18 
Caso de teste 9 ............................................................................................................. 19 
Caso de teste 10 ......................................................................................................................... 20 
Caso de teste 10.1 ...................................................................................................................... 21 
RELATÓRIO FINAL ........................................................................................... 22 
CONCLUSÃO ............................................................................................................ 23 
REFERÊNCIAS ..................................................................................................... 24 
6 
 
 
 
 
1- INTRODUÇÃO 
 
O objetivo deste projeto é criar e executar roteiros de tes tes com o a técnica caixa-
preta para auxiliar um departamento de extensão, pesquisa e pós-graduação 
(DEPP) de uma universidade que comprou um sistema de formatação de trabalhos 
e precisa dar o aceite final para a aquisição do software. 
Essas duas versões deverão ser geradas pelo Sistema de Formatação de Artigos 
Acadêmicos como o DEPP precisa avaliar e dar o aceite final no sistema, mas não 
tem o domínio das técnicas a serem aplicadas para a avaliação, pediu o auxílio do 
Curso Superior de Tecnologia em Análise e Desenvolvimento de Sistemas para 
realizar essas atividades. 
Para a avaliação do sistema de formatação de artigos acadêmicos foram 
identificados 10 (dez) casos de testes a serem executados, assim elaborei roteiros 
detestes de tipo caixa-preta, onde serão aplicados e gerados resultados dos testes. 
7 
 
 
 
 
 
 
2- TESTES DE SOFTWARE 
 
Os testes de software estão incluídos nas etapas de verificação e validação como artificio 
para a garantia de qualidade do produto de software. Técnica dependendo do contexto e do 
tempo para a elaboração do projeto. 
Software são técnicas dinâmicas usadas sobre o sistema já construído, podendo serem 
software a partir da década de 80 onde houveram a elaboração de métodos formais, tornando-
se uma atividade essencial ao processo de construção do produto de software. 
Para entender testes de software faz–se necessário ter a clareza nos conceitos de concepção 
do produto de software, são atividades de validação, uma equipe inteira é responsável. 
 
 
2.1 Técnicas de Teste de SoGware 
 
As técnicas de testes de software estão divididas em dois objetivos: 
A especificação funcional da aplicação e a qualidade do código. A especificação 
funcional da aplicação está voltada aos testes de sistema e de aceitação enquanto 
os testes de unidade e de Integração se relacionam com os testes de código. 
Este projeto utilizara a técnica funcional, mais especificamente o teste de caixa preta 
que consiste em avaliar se o software está de acordo com as necessidades dos 
usuários finais. São necessários alguns artefatos para que se possam criar testes 
bem elaborados. Entre estes artefatos temos o documento de requisitos e pelo 
menos um protótipo visual das telas a serem testadas. Com esses documentos em 
mãos a equipe pode iniciar as atividades de teste que estão divididas em 
concordância nas etapas definidas: 
 Planejamento: Consiste em determinar qual ponto do sistema será testado 
 
 Projeto: Nesta fase são apresentados os casos de teste que nada mais e do que um 
requisito do utilizador com relação ao sistema. 
 
 Implementação: Analisa cada caso de teste e elaboram os roteiros detestes em que 
encontramos as descrições detalhadas dos passos para a execução do sistema, a fim 
de identificar os casos de teste determinados na etapa de projeto. 
 
 Execução: executam-se os roteiros e estrutura os resultados 
 
 Verificação: Caso tenha não conformidades com os requisitos do usuário, que gera 
as evidencia dos testes através de prints das telas. Com essas informações podemos 
iniciar os testes no sistema disponível no endereço solicitado pelo DEEP. Cada parte 
está descrita e implantadas nas seções seguintes. 
8 
 
 
 
 
3- PLANEJAMENTO 
 
O projeto deve ser executado para que sirva de avaliação do PIM-V referente aoCurso 
superior Tecnológico em Analise e desenvolvimento de Sistemas. A técnica utilizada 
para avaliar se o sistema está de acordo como as conformidades previstas pelo 
Departamento de Extensão, Pesquisa e Pós-graduação e a funcional caixa-preta 
que verifica situações de 
sucesso e insucesso na execução de determinadas funcionalidades denominadas casos de 
teste. A universidade informou 10 casos de testes os quais serão criados roteiros 
específica para cada caso, executados e geradas as evidencias com sucessos ou 
insucesso observados. Será gerado um relatório final apontando as possíveis falhas 
do sistema, auxiliando a DEPP na aceitação do Sistema. 
9 
 
 
 
 
 
 
 
4 - PROJETO 
 
Nesta fase iremos identificar os casos de teste informados pela DEPP como mostra abaixo: 
Caso de teste 1: Gerar um artigo completo com um autor cadastrado com sucesso 
(nenhum campo pode ficar em branco) 
Caso de teste 2: Gerar um artigo para submissão com um autor cadastrado com 
sucesso (nenhum campo pode ficar em branco). 
Caso de teste 3: Gerar um artigo completo com três autores cadastrados com 
sucesso (nenhum campo pode ficar em branco). 
Caso de teste 4: Gerar um artigo completo com três autores com e- mails inválidos 
(nenhum campo pode ficar em branco). 
Caso de teste 5: Gerar um artigo completo com três autores com os campos de autor 
em branco. 
Caso de teste 6: Gerar um artigo completo com um autor cadastrado com sucesso 
(nenhum campo pode ficar em branco) e limpar os dados sem gerar o artigo. 
Caso de teste 7: Gerar um artigo completo com um autor cadastrado com sucesso 
(nenhum campo pode ficar em branco), criando no campo “corpo do texto” um texto 
com formatação em negrito, itálico, subscrito e sobrescrito e o texto justificado com 
sucesso 
Caso de teste 8: Gerar um artigo completo com um autor cadastrado com sucesso 
(nenhum campo pode ficar em branco), anexando no campo “corpo do texto” uma 
imagem de um arquivo com sucesso. 
Caso de teste 9: Gerar um artigo completo com um autor cadastrado com sucesso 
(nenhum campo pode ficar em branco), anexando no campo “Notas” uma URL de 
um arquivo com sucesso e criando um texto formato à esquerda e em negrito. 
Caso de teste 10: Testes de interface 
10 
 
 
 
 
 
 
5- IMPLEMENTAÇÃO 
 
Iniciei através de um roteiro de testes, com as exigências necessárias, as execuções 
dos testes, contemplando a condição inicial, os passos a serem realizados, dados 
de entrada, resultado previsto, resultado real e a data de realização como podemos 
visualizar na tabela abaixo: 
 
 
11 
 
 
 
 
 
 
6- EXECUÇÃO 
 
Abaixo estão inseridos os roteiros de testes dos casos de 1 a 10 com os dados utilizados 
na verificação: 
Caso de teste 1: 
Desenvolvimento e execução 
Roteiro do caso de teste 1 
 
 
Ao clicar no botão Gerar, o arquivo é exibido na própria janela do navegador, na mesma aba 
do sistema, verificando-se a ausência de um botão ou link para download do arquivo. Sugere 
se que o arquivo seja gerado me aberto em aba separada, permitindo ao usuário visualizá- lo 
no próprio browser, mas mantendo a tela do sistema aberta, podendo também optar por salvá- 
lo em sua máquina, no formato PDF. 
http://sfaa.unipinterativa.edu.br/pdf/ 
 
 
http://sfaa.unipinterativa.edu.br/pdf/
12 
 
 
 
 
 
 
Caso de teste 2: 
Roteiro do Caso de teste 2 
 
 
 
 
O arquivo foi gerado com sucesso. Reitera-se aqui a sugestão de melhoria feita no caso 
anterior. 
http://sfaa.unipinterativa.edu.br/pdf/ 
 
http://sfaa.unipinterativa.edu.br/pdf/
13 
 
 
 
 
 
 
 
Caso de teste 3: 
 
 Roteiro do Caso de Teste 3 
 
 
 
 
 
 
 
 
O arquivo foi gerado com sucesso, apresentando a identificação dos três autores cadastrados. 
Reitera-se aqui a sugestão de melhoria feita nos casos de teste 1 e 2. 
http://sfaa.unipinterativa.edu.br/pdf/ 
 
http://sfaa.unipinterativa.edu.br/pdf/
14 
 
 
 
 
Caso de teste 4: 
Roteiro do Caso de Teste 4 
 
 
 
O sistema exibe mensagem de alerta no caso do não preenchimento ou do 
preenchimento incorreto (endereço inválido) do campo de e-mail, destacando-o em 
vermelho. Observa-se, no entanto, que o sistema considera inválido o endereço de e-
mail somente se este não contiver o caractere @ (arroba), ou seja, qualquer endereço 
inserido, ainda que com formato incorreto, é considerado válido pelo sistema, desde 
que o sinal @ (arroba) esteja presente. Outra observação a ser feita é que, o exposto 
acima somente aplica-se ao campo de e- mail referente ao primeiro autor cadastrado, 
ou seja, somente este é de preenchimento obrigatório. O não preenchimento dos e- 
mails dos demais autores ou seu preenchimento com a inserção de dados incorretos 
não gera nenhuma mensagem de erro tampouco impede que o sistema de prossiga 
com o processo de geração do arquivo. Sugere-se a implementação de mais critérios 
que permitam ao sistema identificar um endereço de e- mail inválido, não permitindo 
a continuidade do processo enquanto não for inserido um dado no formato correto, 
sendo também necessário que este comportamento ocorra para os demais autores 
cadastrados. 
http://sfaa.unipinterativa.edu.br/pdf/ 
 
 
 
 
 
http://sfaa.unipinterativa.edu.br/pdf/
15 
 
 
Caso de teste 5: 
 
Roteiro do Caso de Teste 5 
 
 
 
 
 
 
 
Observou-se que as regras de validação dos campos referentes ao primeiro autor não se aplicam 
aos demais autores adicionados. Sugere-se a aplicação das mesmas regras de validação para 
todos os autores cadastrados. 
http://sfaa.unipinterativa.edu.br/pdf/
16 
 
 
 
 
Caso de teste 6: 
 
 Roteiro do Caso de Teste 6 
 
 
 
 
O sistema não limpou todos os campos do formulário. Os campos “Corpo do texto”, “Notas” e 
“Referências Bibliográficas” não são apagados. 
 
http://sfaa.unipinterativa.edu.br/pdf/
 
17 
 
 
 
 
Caso de teste 7: 
 Roteiro do Caso de Teste 7 
 
 
O sistema funcionou satisfatoriamente, gerando o artigo com a formatação previamente 
configurada. 
http://sfaa.unipinterativa.edu.br/pdf/ 
http://sfaa.unipinterativa.edu.br/pdf/
18 
 
 
 
 
Caso de teste 8: 
 Roteiro do Caso de Teste 8 
 
 
 
O sistema não dispõe de ferramenta para inserção de imagens previamente salvas 
no computador do usuário. Ao tentar inserir uma imagem disponível na web, 
apresenta falha, não exibindo a imagem, mas tão somente sua URL. Sugere-se a 
implementação de um botão na barra de ferramentas do campo “Corpo do texto” que 
permita inserir arquivos de imagens online ou a partir da máquina utilizada pelo 
usuário, da forma similar aos processadores de textos como o Word ou Write. Outra 
forma seria possibilitar o acesso direto do sistema à área de transferência do 
computador, proporcionando mais agilidade no processo ao permitir que o usuário 
realize a ação por meio dos comandos de copiar e colar ou simplesmente arrastando 
e soltando o objeto. 
http://sfaa.unipinterativa.edu.br/pdf/ 
http://sfaa.unipinterativa.edu.br/pdf/
19 
 
 
 
 
Caso de teste 9: 
 Roteiro do Caso de Teste 9 
 
 
 
Ao gerar o artigo completo, o sistema exibe no campo “Notas” o texto formatado 
conforme pedido e o endereço do arquivo externo em PDF, porém este não se 
encontra formatado como um link, ou seja, para ter acesso ao seu conteúdo, faz-se 
necessário copiar a URL e colar na barra de endereços do navegador, em uma aba 
à parte. Sugere-se a correção do problema fazendo com que, no arquivo gerado, o 
endereço inserido esteja sensível ao mouse e que, ao clicar sobre ele, o documento 
seja aberto em aba separada, permitindo ao usuário mais praticidade para realizar 
a consulta. 
20 
 
 
 
 
Caso de teste 10: 
 Roteiro do Caso de Teste 10 
 
 
21 
 
 
 
 
Caso de teste 10.1: 
 
 
 
 
 
 
Observou-se que o sistema não oferece proteção contra entrada de dados não 
previstos, os quais, tratados de maneira inadequada, causam problemasnas etapas 
seguintes do processamento. Sugere-se a devida correção das instabilidades 
relativas ao comportamento da interface, realizando uma verificação das regras de 
validação de cada campo, de maneira a não permitir a entrada de dados fora do 
formato especificado, com quantidade de caracteres além do limite estabelecido, 
bem como verificar se os campos com indicação de obrigatoriedade estão sendo 
bloqueados. 
22 
 
 
 
 
 
 
RELATÓRIO FINAL 
 
Este projeto teve o propósito de elaborar e executar um roteiro de testes para um 
sistema de formatação de artigos acadêmicos, desenvolvido por uma empresa 
contratada para este fim, para o DEPP (Departamento de Extensão Pesquisa e Pós-
Graduação) da Universidade Paulista. 
A partir da aplicação da técnica de testes funcionais ou “caixa-preta”, foi realizada a 
análise das respostas do sistema frente às entradas de dados propostos nos roteiros 
e casos de testes, assim como das funcionalidades, da interface e de sua 
interatividade como o usuário. 
Ao longo do ciclo de testes, em função dos problemas identificados, a equipe aponta 
as diversas melhorias a serem implementadas, a fim de garantir que todos os 
requisitos solicitados estejam presentes no produto final e que este atenda, na sua 
totalidade, as funções que lhe foram atribuídas. 
23 
 
 
 
 
 
 
 
 
 
 
CONCLUSÃO 
 
Conclui-se, do presente trabalho, que o processo de desenvolvimento de software 
demanda muito mais do que o simples conhecimento de uma linguagem de 
programação, abrangendo um conjunto de atividades a serem executadas de forma 
planejada a partir da utilização de teorias, métodos, técnicas e ferramentas 
adequadas que visam a criação de um produto que contenha as características que 
lhe confiram a capacidade de atender as necessidades dos usuários finais. Os 
conhecimentos adquiridos por meio da disciplina proposta para a elaboração deste 
projeto possibilitou uma visão abrangente do conceito de qualidade de software e da 
importância da aplicação dos seus requisitos, objetivando a melhoria dos processos 
de desenvolvimento, minimizando custos e retrabalho e possibilitando a obtenção 
de resultados positivos e cada vez mais alinhados com as expectativas e com a 
satisfação da equipe e do cliente. A elaboração e aplicação de um roteiro de testes 
do tipo “caixa-preta” para realizar a verificação e validação de um sistema, 
possibilitou conhecer na prática a importância do trabalho desenvolvido por controle 
daquilo que é produzido, e, ao mesmo tempo, uma conscientização sobre a 
necessidade da qualidade, mediante a exposição das vantagens proporcionadas 
pela aplicação de metodologias de desenvolvimento de softwares fundamentadas 
em parâmetros qualitativos. 
24 
 
 
 
 
 
 
 
 
 
 
 
 
REFERÊNCIAS 
 
Figuras 1 a 10: Imagens de tela do sistema, disponível em: 
http://sfaa.unipinterativa.edu.br/pdf/. (acessado entre os dias 29 e 31 de março de 
2020). 
Textuais: 
SOMMERVILLE, I. Engenharia de software. São Paulo: Pearson, 2011. 
PRESSMAN, R. S. Engenharia de software: uma abordagem profissional. São 
Paulo: McGraw-Hill, 2011. RIBEIRO, A. L. Engenharia de software II. São Paulo: 
Editora Sol, 2017. 
http://sfaa.unipinterativa.edu.br/pdf/
http://sfaa.unipinterativa.edu.br/pdf/
 
 
 
UNIP INTERATIVA 
Projeto Integrado Multidisciplinar 
Cursos Superiores de 
Tecnologia 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
Unip – Nazaré 
2020 
 
 
 
 
 
 
 
 
 
 
 
PROJETO DE DESENVOLVIMENTO DE UM SISTEMA PARA UMA LOJA DE 
AUTOPEÇAS. 
2 
PROJETO INTEGRADO MULTIDISCIPLINAR II – PIM IV 
PROJETO DE DESENVOLVIMENTO DE UM SISTEMA PARA UMA LOJA DE 
AUTOPEÇAS. 
 
 
 
UNIP INTERATIVA 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
 
 
 
 
 
 
 
 
Erick Patrik Alves da Fonseca 
UP - 19222259 
Curso: Analise e Desenvolvimento de Sistemas 
3º Semestre de 2020. 
 
 
 
 
 
 
 
 
 
 
 
 
 
Unip – Nazaré 
2020 
3 
 
 
 
RESUMO: 
 
Diante do atual cenário das organizações, onde permeiam os avanços tecnológicos 
com ferramentas cada vez mais complexas e rápidas, se torna necessário para toda 
e qualquer organização buscar meios de organizar seus processos chaves e 
Auxiliares, para melhor satisfazer as necessidades dos clientes. Reduzindo o foco 
ao trabalho produzido, pode-se afirmar que administrar de maneira eficiente o 
estoque disponível é algo vital para a empresa pesquisada perdurar por mais tempo 
diante de um mercado altamente competitivo. Desta forma o presente estudo tem 
por finalidade analisar e buscar maneiras para uma melhor administração do 
estoque. 
 
 
Palavras-chave: Processos chaves. Estoque. Mercado. 
4 
Given the current scenario of organizations, where technological advances permeate 
with increasingly complex and fast tools, it becomes necessary for every organization 
to find ways to organize its key and auxiliary processes to better meet the needs of 
its customers. Reducing the focus on the work produced, it can be said that efficiently 
managing the available stock is vital for the researched company to last longer in a 
highly competitive market. In this way the present study aims to analyze and look for 
ways to better manage the inventory. 
Keywords: Key processes. Stock. Marketplace... 
 
 
 
ABSTRACT: 
 
 
5 
 
 
 
SUMÁRIO 
1 INTRODUÇÃO. .......................................................................................................... 6 
1.1 Delimitação do Tema e Formulação do Problema ............................................... 7 
1.2 Objetivos ............................................................................................................. 7 
2 FUNDAMENTAÇÃO TEÓRICA ............................................................................................ 7 
2.1 Logística ............................................................................................................. 7 
2.1.2 Conceito .......................................................................................................... 8 
2.2 Gestão de estoque ............................................................................................. 8 
2.2.2 Gestão de estoque no varejo ........................................................................... 9 
2.2.3 Relevância dos estoques no processo de gestão .......................................... 10 
3 SETOR DE PEÇAS AUTOMOTIVAS .......................................................................... 10 
4 VISÃO GERAL .......................................................................................................... 11 
4.1 Conferência minuciosa ..................................................................................... 11 
4.2 Técnicas de conferência a empresa faz uso......................................................12 
4.3 Possibilidade do vendedor vender uma peça por outra sem que perceba........12 
4.4 Comunicação entre compras e vendas..............................................................13 
4.5 Sistema de Informações de movimento de estoque .......................................... 13 
4.6 Procedimento de balanço ..................................................................................13 
5 METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE ............................................ 14 
5.1 Premissas de desenvolvimento de sistemas ...................................................... 14 
5.2 Fases da metodologia de desenvolvimento de sistemas ................................... 14 
5.3 Definições das fases de desenvolvimento de sistemas ..................................... 15 
5.4 Metodologia ágil ............................................................................................... 16 
6 PROCESSO DE SOFTWARE .................................................................................... 16 
6.1 Especificação de software. ...............................................................................17 
6.2 Engenharia e análise de requisitos ................................................................... 17 
6.3 Requisitos funcionais ......................................................................................... 18 
6.4 Requisitos não funcionais .................................................................................. 18 
7 PROJETO E IMPLEMENTAÇÃO DE SOFTWARE ............................................................. 18 
8 UML (LINGUAGEM DE MODELAGEM UNIFICADA ........................................................... 19 
8.1 Diagrama de casos de uso. .............................................................................. 19 
8.2 Diagrama de classe .......................................................................................... 20 
8.3 Implementação ................................................................................................. 20 
8.4 Programação orientada a objetivos ...................................................................20 
8.5 Papéis do Scrum .............................................................................................. 22 
8.5.1 Scrum Master. ............................................................................................... 22 
9 LINGUAGEM JAVA ................................................................................................... 23 
9.1 Banco de dados e serviços. .............................................................................. 24 
9.2 Desenvolvimento da interface ........................................................................... 25 
9.3 Projeto exibição ................................................................................................ 26 
10 CONCLUSÃO ........................................................................................................ 27 
11 REFERENCIAS ....................................................................................................... 28 
6 
 
 
 
 
1 - INTRODUÇÃO 
 
Por meio da observação cotidiana, tendo em vista o grande fluxo de materiais 
movimentado pela empresa diariamente, pode-se observar a falta de controle em 
seu deposito de mercadorias, e através de um estudo detalhado busca-se analisar 
descritivamente seu funcionamento atual, e sugerir melhorias para melhor 
aproveitamento do seu estoque, gerando um controle mais rigoroso e um melhor 
rendimento dos investimentos em estoques. 
A empresa de autopeças Ltda. é de cunhofamiliar. Foi fundada em 15 de janeiro de 
1993, e está entre os principais varejistas do setor automotivo. 
O pesquisador é filho do proprietário, estando diretamente ligado à empresa pela 
função de gerente administrativo. E por mais que se possa argumentar as negativas 
quanto a certas práticos organizacionais identificadas, o mesmo manteve-se neutro 
e exercendo apenas a função de pesquisador. 
 
1.1 Delimitação do tema e formulação do problema 
 
Em meio as constantes mudanças no mercado mundial, fruto do contínuo processo 
de inovações e melhorias gerenciais que objetivam captar cada vez mais novos 
clientes para empresas, nota-se que as organizações que desejam perpetuar frente 
a essa nova realidade, de um modo geral deve se preocupar cada vez mais em 
identificar pontos a serem melhorados e oportunidades a serem aproveitadas. 
Dependendo do setor em que a empresa atua e da sazonalidade, é necessário um 
nível mínimo de estoque que aja como amortecedor entre oferta e demanda. No 
caso da empresas que trabalham com estoque, gerenciá-lo de maneira eficiente é 
algo primordial, visto que estoque é dinheiro que está parado, portanto possuí-lo na 
quantidade certa é fundamental para que se consiga reduzir os custos relacionados 
com a manutenção do mesmo, objetivando proporcionar maior competitividade 
frente aos concorrentes. 
7 
 
 
 
Problemas relacionados a gestão de estoque afetam grande parte das empresas 
brasileiras, em muitos casos a causa não é estrutural ou por procedimentos, mas 
sim cultural. Tudo é ainda mais complicado conforme a concorrência aumenta, é aí 
que está o perigo para tais empresas, não existe um planejamento de médio e longo 
prazo, ou seja, apenas realizam tomadas de decisões em curto prazo, e isso é 
fundamentalmente arriscado, pois está primeiramente suscetível ás tendências do 
mercado que invariavelmente podem levar á algum caminho sem volta, ou então 
falta de identidade da empresa com o mercado consumidor onde as estratégias são 
confusas e o consumidor não possui um posicionamento da organização ou este é 
altamente fragmentado. 
Na concepção de CORRÊA et al (2000, p45), “estoques são acúmulos de recursos 
materiais entre fases específicas de processos de transformação”. Partindo da 
definição anteriormente citada. Pode-se afirmar que estoques surgem em diversas 
fases de um processo que para empresa só irá terminar de fato ao chegar ao 
consumidor final. 
 
1.2 Objetivos 
 
 Estudar as medidas a serem adotadas na gestão de estoques para redução 
de custos e melhoria do atendimento. 
 Levantar as saídas e entradas de peças automotivas; 
 Descrever os critérios de procedimentos de pedidos; 
 Identificar o controle de estoque existente; 
 Propor medidas na gestão de estoques. 
 
 
 
2 FUNDAMENTAÇÃO TEORICA 
 
2.1 Logística 
 
A Logística é a área responsável por prover recursos, equipamentos e informações 
para a execução de todas as atividades de uma empresa. Entre as atividades da 
8 
 
 
 
logística estão o transporte, movimentação de materiais, armazenamento, 
processamento de pedidos e gerenciamento de informações. 
O termo Logística, de acordo com o Dicionário Aurélio, vem do francês Logistique e 
tem como uma de suas definições "a parte da arte da guerra que trata do 
planejamento e da realização de: projeto e desenvolvimento, obtenção, 
armazenamento, transporte, distribuição, reparação, manutenção e evacuação de 
material para fins operativos ou administrativos“. Outros historiadores defendem que 
a palavra logística vem antigo grego logos (λόγος), que significa razão, cálculo, 
pensar e analisar. 
 
2.1.2 Conceito 
 
De acordo com Ballou (1993), a logística empresarial estuda como a administração 
pode prover melhor nível de rentabilidade nos serviços de distribuição aos clientes e 
consumidores, através de planejamento, organização e controle efetivos para as 
atividades de movimentação e armazenagem, que visam facilitar o fluxo de 
produtos. 
De uma maneira mais simplória, no entanto não menos rica em sua contribuição 
científica de fato, Baglin et al. (1990) definem a logística como uma função da 
empresa que se preocupa com a gestão do fluxo físico do suprimento de matérias- 
primas, assim como a distribuição dos produtos finais aos clientes. 
Partindo dessas duas conclusões podemos afirmar que em suma logística pode ser 
compreendida como a arte de comprar, receber, armazenar, separar, expedir, 
transportar e entregar o produto/serviço certo, na hora certa, no lugar certo, ao 
menor custo possível. 
 
2.2 Gestão de Estoque 
 
A gestão de estoques é um assunto vital da área de logística e, frequentemente, 
absorve parte substancial do orçamento operacional de uma organização. Como 
eles não agregam valores aos produtos, quanto menor o nível de estoques com que 
um sistema produtivo conseguir trabalhar, mais eficiente será (DIAS 1990). Partindo 
9 
 
 
 
dos estudos de Novaes (2001) podemos concluir que gerenciar estoques é a tarefa 
de administrar recursos de maneira eficiente otimizando-os e os gerenciando de 
maneira a propiciar resultados positivos para empresa. 
Para finalizar a etapa conceitual o autor Dornier (2000), concluiu que a gestão de 
estoque é uma função estratégica da logística, segundo o mesmo as tarefas 
relacionadas a esse ramo, têm que ser executada por pessoas capacitadas e 
criativas, que sempre estejam a busca da redução dos custos e efetividade do 
sistema.Pode ser compreendida também como a forma de planejar de maneira 
eficiente os cuidados para com as matérias-primas, material auxiliar, material de 
manutenção, material de escritório, material e peças em processos e produtos 
acabados, para que estejam dispostos da maneira correta em seus respectivos 
locais, gerando sempre uma economia de custos, tempo e dinheiro (CHING, 2001). 
A gestão de estoques é um conceito que está presente em praticamente todo o tipo 
de empresas, assim como na vida cotidiana das pessoas. Desde o início da sua 
história que a humanidade tem usado estoques de variados recursos, de modo a 
suportar o seu desenvolvimento e sobrevivência, tais como ferramentas e alimentos 
(GARCIA et al., 2006, p.9). 
No meio empresarial, se por um lado o excesso de estoques representa custos 
operacionais e de oportunidade do capital empatado, por outro lado níveis baixos de 
estoque podem originar perdas de economias e custos elevados devido à falta de 
produtos. Regra geral, não é tarefa fácil encontrar o ponto ótimo neste Trade off 
(GARCIA et al., 2006, p.9). 
 
2.2.2 Gestão de Estoque no Varejo 
 
Um dos pontos mais críticos em uma operação de varejo é a gestão dos estoques. 
Isso se torna ainda mais importante no Brasil, onde o custo de capital é muito alto 
quando comparado a outros países. Adicionalmente, em alguns casos ainda 
prevalece a cultura de que o segredo do varejo está na compra e não na qualidade 
da gestão dos estoques, na operação comercial e no relacionamento com os 
consumidores. As famosas compras de fim de mês e as “compras de oportunidade” 
são bons exemplos dessa visão. Será que o desconto adicional que se obteve do 
10 
 
 
 
fornecedor e que teve como contrapartida um volume adicional realmente valeu a 
pena? Foi feito algum tipo de acordo para gerar demanda incremental? O custo de 
maior carregamento de estoque foi contemplado na análise do comprador? Como 
evitar o fenômeno do desbalanceamento do estoque, quando há excesso de alguns 
produtos e falta de outros? O desbalanceamento ocorre seja porque a quantidade 
comprada foi superior ou inferior à demanda, seja porque as vendas são diferentes 
em cada loja, tanto em quantidade quanto em sortimento. Comprar mais implica em 
excesso de mercadorias e capital imobilizado. Comprar menos significa ruptura de 
estoques, gerando perda de vendas e margem e não atender bem aos 
consumidores. 
 
2.2.3 Relevância dos estoques no processo de gestão 
 
De acordo com Viana (2002) o termo estoque é muito amplo, tradicionalmente pode 
ser considerado como representativo de matérias primas, produtos semi abados, 
componentes para montagem, sobressalentes, produtos acabados, materiais 
administrativos e suprimentos variados. Partindo-se dessa premissa, Viana (2002, p. 
109-110) define estoque como Materiais, mercadorias ou produtos acumulados para 
utilização posterior, de modo a permitir o atendimento regular das necessidades dos 
usuários para a continuidade da atividade da empresa, sendo o estoque gerado, 
consequentemente, pela impossibilidade de prever-se a demanda com exatidão. 
 
 
3 SETOR DE PEÇAS AUTOMOTIVAS 
 
O setor de peças automotivas é muito peculiar no que se refere ao seu crescimento 
ou declínio, nos dias de hoje as facilidades de crédito e financiamentos fazem com 
que as pessoas facilmente tenham acesso a carro novos, que por consequência irão 
apresentar menos problema que ocasionem troca de peças, e por terem garantia a 
montadora exige que a manutenção seja feita nas concessionárias, o que acaba por 
diminuir a fatia de mercado que poderia pertencer as lojas de autopeças. 
11 
 
 
 
Em contra partida, as lojas de autopeças, possuem um preço mais acessível e as 
vezes além da peça possuem também o serviço de manutenção e concerto de 
carros, o que as tornam diferente das concessionárias, onde o custo para reparos e 
manutenção é bem mais oneroso. 
 
4. VISÃO GERAL DOS COLABORADORES 
 
Esta etapa busca retratar a visão dos colaboradores com relação ao tema estudado, 
todos os participantes da empresa colaboraram com esta etapa do desenvolvimento 
da pesquisa. 
 
4.1 Conferência minuciosa na chegada dos materiais 
 
 
 
Fonte: dados pesquisa (2010) 
 
 
De acordo com as respostas evidenciadas no gráfico conferência de materiais, 
podemos observar que a maioria dos respondentes 62,5% dos colaboradores da 
empresa julgam não existir uma conferência minuciosa dos materiais que a mesma 
trabalha, nem do ponto de vista da entrada, nem do ponto de vista da saída, 
12 
 
 
 
enquanto 37,5 % afirmam o contrário, afirmando haver uma conferência minuciosa 
de materiais. O que pode ocorrer sérios riscos a organização tendo em vista a 
diversidade de produtos que a empresa trabalha. 
 
 
4.2 Técnicas de conferência a empresa faz uso 
 
Fonte: dados da pesquisa (2010) 
 
 
Dentre as técnicas de conferência praticadas pela empresa 62,5% dos 
colaboradores afirmaram que a organização faz uso da conferência qualitativa dos 
materiais, averiguando possíveis defeitos de fabricação, 25 % afirmam que a 
empresa faz uso da contagem cega e o restante 12,5 % que a empresa apenas faz 
uso de uma simples conferência quantitativa. Conforme descrito anteriormente, o 
correto deveria as três se completarem e não tendência maior a outra, talvez possa 
indicar um dos motivos para a falta ou excesso de mercadorias. 
 
4.3 Possibilidade do vendedor vender uma peça por outra sem que perceba, ou até mesmo por 
falta de conhecimento técnico 
 
De acordo com o conhecimento técnico e percepção, 62,5% dos funcionários da 
empresa julgam que possuem o conhecimento necessário para venderem peças de 
13 
 
 
 
modo incorreto, tirando um pedido e entregando outro, enquanto 37,5% julgam que 
devido à falta de conhecimento técnico podem trocar uma peça por outra. 
Confrontando os dados anteriores tendo em vista que os mesmo afirmaram não 
conhecer todo o material, mas se julgam aptos ao serviço, talvez possa indicar uma 
fuga do foco principal por temerem seus respectivos empregos. 
 
4.4 Comunicação entre compras e vendas 
 
Existir uma comunicação concreta entre o comprador e o setor de vendas, frente a 
esse resultado 75% dos colaboradores diz não existir uma comunicação concreta 
entre ambas as áreas. Apesar de interagem entre si no mesmo espaço de trabalho. 
 
4.5 Sistema de informação que controle a movimentação do estoque. 
 
 
Fonte: dados da pesquisa (2010) 
 
 
De acordo com os dados coletados verifica-se que 25% dos funcionários afirmam 
existir um sistema de informação eficiente que controle a movimentação do estoque, 
enquanto 75% julgam não existir um sistema de informação capaz de movimentar de 
maneira correta o estoque. O que implica na aquisição de um novo sistema, ou o 
mesmo deveria ser aproveitado de melhor maneira. 
14 
 
 
 
4.6 Procedimento de balanço 
 
Existi o processo de balanço dentro da loja, até mesmo pelo fato do estoque físico 
nunca bater com o estoque registrado em sistema. Então a contagem, mesmo que 
de mínima importância no estoque existente. 
 
5 - METODOLOGIA DE DESENVOLVIMENTO DE SOFTWARE 
 
Uma metodologia completa constitui-se de uma abordagem organizada para atingir 
um objetivo, por meio de passos preestabelecidos. É um roteiro, um processo 
dinâmico e iterativo para desenvolvimento estruturado de projetos, sistemas ou 
software, visando a qualidade, produtividade e efetividade de projetos (REZENDE, 
1997). Metodologia de software não é apenas uma técnica, porque pode utilizar 
qualquer outra técnica de desenvolvimento de projeto, sistema ou software. Alguns 
exemplos de técnicas são: Análise Estruturada, Análise de Pontos por Função, 
Análise Orientada a Objetos, Unified Modeling Language (UML) entre outras. A 
metodologia deve auxiliar o desenvolvimento de projetos, consiste em várias, 
sistemas ou software, de modo que os mesmos atendam de maneira adequadaàs 
necessidades do cliente ou usuário, com os recursos disponíveis e dentro de um 
prazo ideal definido em conjunto com os envolvidos. Não deve limitar a criatividade 
profissional, mas deve ser um instrumento que determine um planejamento 
metódico, que harmonize e coordene as áreas envolvidas. 
O que limita a criatividade não é a metodologia, mas os requisitos de qualidade, 
produtividade e efetividade de um projeto (REZENDE, 2005). 
 
5.1 Premissas de desenvolvimento de sistemas 
 
As premissas da metodologia são a modularidade e sua própria existência. A 
modularidade não tolera o desenvolvimento de projetos, sistemas ou software sem 
15 metodologia. A segunda premissa retrata que sempre um sistema ou software 
deve ser desenvolvido com uma metodologia, mesmo que ainda não esteja 
fortemente sedimentada (REZENDE, 2005). 
15 
 
 
 
 
 
5.2 Fases da metodologia de desenvolvimento de sistemas 
 
As fases de uma metodologia também podem ser chamadas de ciclo de vida de 
sistema ou processos de software. Embora essas fases sejam apresentadas em 
sequência, o processo de desenvolvimento de Sistemas de Informação deve ser 
dinâmico e interativo. Essa interatividade permite que a equipe desenvolvedora 
retorne às fases anteriores ou desmembre o sistema em módulos ou protótipos, 
possibilitando a continuação da construção de uma parte do Sistema de Informação. 
Todavia, sempre devem ser respeitados os pontos avaliação da qualidade e 
aprovação, que requerem revisão da qualidade do projeto e validação formal dos 
envolvidos. As fases para o desenvolvimento de projetos, sistemas ou software são: 
estudo preliminar, ou anteprojeto, ou estudo inicial, ou primeira visão; análise do 
sistema atual, ou reconhecimento do ambiente; projeto lógico, ou especificação do 
projeto, ou design; projeto físico, ou execução, ou implementação do projeto, ou 
programação; projeto de implantação, ou projeto de disponibilização e uso 
(REZENDE, 2005). 
 
5.3 Definições das fases de desenvolvimento de sistemas 
 
 Estudo preliminar: É a visão global do projeto, com a primeira definição dos 
requisitos funcionais, objetivos, abrangências, integrações, limitações, impactos e 
áreas envolvidas. 
 Análise do Sistema: É a visão do atual sistema, relatando requisitos funcionais 
atuais. 
 Projeto Lógico: É a confecção de propostas de soluções, definição dos requisitos 
funcionais, desenho da lógica do projeto. Definição de o que o projeto fará. 
 Projeto Físico: Execução, confecção de programas e seus testes, layout das 
entradas e saídas. 
 Projeto de implantação: Disponibilidade, execução do planejamento de 
implantação, treinamento e capacitação do cliente ou usuário. Para o 
desenvolvimento do software foi utilizado uma metodologia, onde através dela foi 
16 
 
 
 
feita a análise após a realização da entrevista com o proprietário, a divisão do 
projeto em fases como estudo preliminar, Linguagem UML com diagramas de classe 
e de caso de uso e a implementação do projeto disposto para a equipe. 
 
 
 
 
5.4 Metodologia Ágil 
 
Em 2001, Kent Beck e outros notáveis desenvolvedores, produtores e consultores 
de software |Bec01a| (conhecidos como a “Aliança Ágil”) assinaram o “Manifesto 
para o Desenvolvimento Ágil de Software”. Um manifesto é normalmente associado 
com um movimento político emergente – um movimento que ataque a velha guarda 
e sugira mudanças revolucionárias. De algum modo, isso é exatamente o que o 
desenvolvimento ágil é. Embora as ideias subjacentes que guiam o desenvolvimento 
ágil tenham estado conosco há muitos anos, somente durante a década de 190 é 
que essas ideias foram cristalizadas em um “movimento”. Em essência, os métodos 
ágeis foram desenvolvidos em um esforço para vencer as fraquezas percebidas e 
reais da engenharia de software convencional. O desenvolvimento ágil pode 
fornecer importantes benefícios, mas ele não é aplicável a todos os projetos, 
produtos, pessoas e situações. Ele também não é contrário à sólida prática de 
engenharia de software e pode ser aplicado como uma filosofia prevalecente a todo 
o trabalho de software (PRESSMAN, 2006). 
A engenharia de software ágil combina uma filosofia e um conjunto de diretrizes de 
desenvolvimento. A filosofia encoraja a satisfação do cliente e a entrega incremental 
do software logo de início; equipes de projeto pequenas, altamente motivadas, 
métodos informais; produtos de trabalho de engenharia de software mínimos e 
simplicidade global do desenvolvimento. As diretrizes de desenvolvimento enfatizam 
a entrega em contraposição à análise e ao projeto (apesar dessas atividades não 
serem desencorajadas) e a comunicação ativa e contínua entre desenvolvedores e 
clientes (PRESSMAN, 2006). 
 
6 - PROCESSOS DE SOFTWARE 
17 
 
 
 
 
Na engenharia de software, processos podem ser definidos para atividades como 
Especificação de software, Projeto e Implementação de software. E para cada 
atividade dessa, podem-se definir subprocessos, como determinação de requisitos 
funcionais, análise de sistema, diagramação, programação, testes e implantação. 
Sommerville (2003) define um processo de software como um conjunto de atividades 
e resultados associados que levam á produção de um produto de software. Os 
processos de software são complexos e, como todos os processos intelectuais, 
dependem de julgamento humano. Não há um processo ideal, e diferentes 
organizações desenvolveram abordagem inteiramente diferente. Até dentro da 
mesma empresa pode haver muitos processos diferentes utilizados para o 
desenvolvimento de software. 
 
6.1 Especificação de software 
 
Segundo Sommerville (2003) a especificação de software destina-se a estabelecer 
quais funções são requeridas pelo sistema e as restrições sobre operação e o 
desenvolvimento do sistema. Essa etapa do processo de software geralmente é 
chamada de engenharia de requisitos que se encontrados erros produzem 
problemas posteriores no projeto e na implementação do sistema. 
 
6.2 Engenharia e análise de requisitos 
 
Na etapa de especificação no desenvolvimento de um software são coletados 
requisitos ou informações necessárias para modelagem do sistema. Para poder 
analisar e entender o problema a ser solucionado e estabelecer com precisão o que 
o sistema deve fazer. Com a análise de requisitos serão determinados e analisados 
requisitos com a finalidade de converter a explicação de alto nível desses requisitos 
em uma lista precisa que possa ser usada como informação para o restante da fase 
de análise. A organização dos requisitos em grupos com diferentes níveis de 
descrições permite que não apareçam problemas durante o processo de engenharia 
de requisitos. 18 A análise de requisito é fundamental para elaborar um sistema ou 
18 
 
 
 
software que atenda e satisfaça plenamente os desenvolvedores, clientes e 
usuários. Quando bem definido e relatados evitam muitos problemas futuros e um 
deles é a alta manutenção de sistemas e software (REZENDE, 2005). 
 
 
 
 
6.3 Requisitos funcionais 
 
Os requisitos de um software, também chamados de requerimento de software ou 
de requisitos funcionais de um sistema, devem ser elaborados no início de um 
projeto de sistema ou software. (REZENDE, 2005). 
Os requisitos funcionais são declarações de funções que o sistema deve fornecer, 
como o sistema deve reagir a entradas específicas e como deve se comportar em 
determinadas situações. Em alguns casos os requisitos funcionais podem também 
explicitamente declarar o que o sistema não deve fazer. (SOMMERVILLE, 2003). 
 
6.4 Requisitos não funcionais 
 
Os requisitos não funcionais, como o nome sugere, são aqueles que não dizem 
respeito diretamente às funções específicas fornecidas pelo sistema. Eles podem 
estar relacionados a propriedades de sistema emergentes, como confiabilidade, 
tempo de resposta e espaço em disco. Como alternativa, eles podem definir 
restrições para osistema, como a capacidade dos dispositivos de E/S 
(entrada/saída) e as representações de dados utilizadas nas interfaces de sistema. 
Muitos requisitos não funcionais dizem respeito ao sistema como um todo, e não a 
características individuais do sistema. Com isso ele se torna na maioria das vezes 
mais importantes do que os requisitos funcionais individuais. Pois quando falha pode 
deixar o sistema inútil, enquanto o requisito funcional apenas degrada o sistema. Por 
exemplo se um sistema de controle falha em cumprir o requisito de desempenho as 
funções de controle não irá funcionar direito. 
 
7 - PROJETO E IMPLEMENTAÇÃO DE SOFTWARE 
19 
 
 
 
 
Descreve que a etapa de implementação do 19 desenvolvimento de software é o 
processo de conversão de uma especificação de sistema em um sistema executável 
que envolve processo de projeto e programação de software podendo ser também 
um aperfeiçoamento da especificação de software quando aliado a uma metodologia 
de desenvolvimento. Um projeto de software é uma descrição de estrutura de 
software a ser implementada, dos dados que são parte do sistema, das interfaces 
entre componentes do sistema e, algumas vezes, dos algoritmos utilizados. O 
processo de projeto de software envolve acrescentar forma e detalhes, á medida 
que o projeto é desenvolvido com retornos constantes a fim de corrigir projetos 
anteriores. (SOMMERVILLE, 2003). 
 
8 - UML (LINGUAGEM DE MODELAGEM UNIFICADA) 
 
UML é uma linguagem para visualização, especificação, construção e 
documentação de artefatos de um software orientado a objeto. Sua vantagem é que 
ela serve para as quatro atividades: análise, design, implementação e teste. Ela é 
composta por itens, relacionamentos e diagramas, sendo eles: Itens: Estruturais 
(classe, interface, casos de uso e componentes); Comportamentais (interações, 
máquinas de estado); Grupos de elementos (pacotes, frameworks e subsistemas) e 
Anotações (notas). Relacionamentos: Dependência; Associação; Generalização e 
Realização. Os relacionamentos são entre itens como classes e casos de uso. 
Diagramas: são divididos em 9 diagramas que são: de classes; de objetos; de casos 
de uso; de sequência; de colaborações; de gráficos de estados; de atividades; de 
componentes e de implantação. Neste trabalho foram utilizados os diagramas de 
classe e de casos de uso. 
 
8.1 Diagrama de casos deuso 
 
O Diagrama de Casos de Uso tem o objetivo de auxiliar a comunicação entre os 
analistas e o cliente. Esse diagrama descreve um cenário que mostra as 
20 
 
 
 
 
 
 
 
funcionalidades do sistema do ponto de vista do usuário. Podemos ver o diagrama 
feito neste trabalho no capítulo 6, página 32. 
O diagrama de caso de uso é representado por atores, casos de uso e 
relacionamentos. Os relacionamentos podem ser associações entre atores e casos 
de uso; generalizações entre os atores e generalizações, extends e includes. 
 
8.2 Diagrama de classe 
 
A funcionalidade externa de um sistema orientado a objetos é fornecida por meio de 
colaboração entre objetos que colaboram uns com os outros para produzir os 
resultados visíveis no desenvolvimento do sistema. Essa colaboração permite 
compreender como o sistema está estruturado internamente (BEZERRA, 2007). A 
relação entre esses objetos são representados por um diagrama de classe. No qual 
são representadas por classes e associações entre as mesmas é um diagrama rico 
em termos de notação e importante para nível de análise. 
 
8.3 Implementação 
 
Implementação é a fase do ciclo de vida de um software (programa computacional, 
documentação e dados), no contexto de um sistema de informação, que 
corresponde à elaboração e preparação dos módulos necessários à sua execução. 
Podemos encontrar parte da implementação do software. 
 
8.4 Programação Orientada a Objetos 
21 
 
 
 
Orientação a objetos é uma maneira de programar que ajuda na organização e 
resolve muitos problemas enfrentados pela programação procedural. A programação 
orientada a objeto, segundo a maioria dos especialistas, 21 fundamenta-se em 
quatro princípios: abstração, encapsulamento, herança e polimorfismo. (MECENAS, 
2008). O paradigma Orientado a Objetos (POO) é o mais avançado no quesito de 
reusabilidade de código e não resolve tudo aquilo que se propõe a fazer, ferindo, 
inclusive, seus próprios preceitos e ocasionando no sistema dificuldade de 
compreensão, manutenção, forte acoplamento e até mesmo redundância de código 
(WINCK & JUNIOR, 2006). A programação orientada a objetos se ocupa de realizar 
um projeto de software utilizando uma linguagem de programação orientada a 
objetos na qual aceita implementação direta de objetos e fornece recursos para 
definir as classes de objetos. Os sistemas orientados a objetos devem ser de fácil 
manutenção, uma vez que os objetos são independentes. (SOMMERVILLE, 2003) 
SCRUM é um processo Ágil ou ainda um framework para gerenciamento de projetos 
Ágeis. É um processo de gerência de projetos, certamente não uma metodologia, 
pois isto seria pesado demais (SCHWABER, 2004). O Scrum não é um processo 
previsível, ele não define o que fazer em toda circunstância. Ele é usado em 
trabalhos complexos nos quais não é possível prever tudo o que irá ocorrer e 
oferece um framework e um conjunto de práticas que torna tudo visível. Isso permite 
aos praticantes do Scrum saber exatamente o que está acontecendo ao longo do 
projeto e fazer os devidos ajustes para manter o projeto se movendo ao longo do 
tempo visando alcançar os seus objetivos (SCHWABER, 2004). O Scrum possui 
componentes para organizar o desenvolvimento de softwares e iteração entre o 
cliente e a equipe de desenvolvimento, são eles: Sprints, Product Backlog e Sprint 
Backlog. Sprints: O Sprint é o ciclo de desenvolvimento do Scrum, caracterizado por 
ter um curto período onde a equipe foca na entrega de uma meta específica. Product 
Backlog ou Backlog do Produto: Requisitos de produtos organizados em uma lista 
de itens. Sprint Backlog: O Sprint Backlog é gerado a partir das histórias retiradas do 
Product Backlog e que serão implementadas durante o Sprint. Ciclo do Scrum O 
Scrum tem o progresso de desenvolvimento baseado em iterações com duração que 
pode variar de duas a seis semanas, chamadas de Sprints. A primeira etapa dentro 
do Sprint é uma reunião de planejamento (Sprint Planning), onde o time (Scrum 
22 
 
 
 
Team), em conjunto com o cliente (Product Owner) define o que será implementado 
na iteração, sendo responsabilidade do cliente realizar a priorização do trabalho a 
ser feito. (VARASCHIM, 2009) Outra etapa é a de execução, onde o time detalha as 
tarefas necessárias para implementar o que foi solicitado pelo cliente e depois inicia 
a execução das mesmas. Durante o Sprint o time realiza reuniões diárias (Daily 
Meeting) com 15 minutos para averiguar o acompanhamento do progresso do 
desenvolvimento, usando para isto o Burn Down Chart, que é um gráfico usado para 
o acompanhamento das tarefas a realizar, em andamento e já realizadas. Ao final do 
Sprint é realizada uma reunião para a validação da entrega (Sprint Review), onde o 
cliente e quem mais tiver interesse no produto pode verificar se o objetivo do Sprint 
foi atingido. Logo após, é realizada apenas pelo time uma reunião (Sprint 
Retrospective) onde o Sprint é avaliado sob a perspectiva de processo, time ou 
produto, quais foram os acertos e os erros com o objetivo de melhorar o processo de 
trabalho. 
 
Figura: Ciclo do Scrum 
 
 
8.5 Papéis do Scrum 
 
8.5.1 Scrum Master: 
 
É o gerente do projeto, sua função é ser o facilitador do processo e ajudar as 
pessoas a resolver os problemas. Scrum Team: é o time do projeto com no máximo 
23 
 
 
 
10 a 15 participantes e deve ser multidisciplinar e auto organizado. Product Owner: é 
o cliente de um time Scrum, ele é responsável pelo retorno do investimento de um 
produto. 3.3 Etapas do SprintO Sprint é definido como um ciclo de desenvolvimento 
curto em que o time foca em atingir o objetivo proposto pelo Product Owner. Durante 
este ciclo o time 24 deve ter total autoridade para seu gerenciamento, não devendo 
sofrer interferências externas do cliente ou de outras pessoas. Sprint Planning: é a 
primeira atividade dentro do Sprint, uma reunião, durante essa reunião é feita uma 
seleção das histórias que serão implementadas durante aquele ciclo. Daily Scrum: é 
uma reunião rápida que deve ter o tempo fechado, realizada todo dia, reuniões em 
pé no qual os membros do time explicam entre si o que foi feito desde a última Daily 
Scrum. Sprint Review: acontece no final de cada Sprint, durante esta reunião o time 
mostra o resultado do seu trabalho para o Product Owner e para outros clientes. 
Sprint Retrospective: é a reunião do time realizada sempre ao final de cada Sprint e 
deve ser utilizada para a correção dos problemas detectados pelo time no processo 
de desenvolvimento. O scrum é um modelo de implementação simples, faz parte 
poucas especificações e artefatos, o desafio é integrá-lo as necessidades do cliente, 
do time e da empresa. É importante saber que a prática do Scrum cria equipes 
motivadas, e com o tempo criam laços com o produto tendendo cada vez mais a 
entregar qualidade e eficiência. Após ver e analisar todas essas características foi 
escolhido o scrum como um método de gerenciamento do projeto, pois o mesmo nos 
permite fazer isso. Criando assim as sprints para ir mostrando as funcionalidades do 
sistema ao cliente conforme elas iam sendo feitas. Essas sprints tinham em média 
duas semanas cada, pois assim havia tempo hábil para a criação das 
funcionalidades. Ao final das sprints foram realizadas reuniões com o cliente para ir 
verificando se estava de acordo o produto do projeto. Também foi realizada uma 
última reunião após o termino do processo de desenvolvimento para apresentação 
do produto final e aprovação do cliente. 
 
9 - LINGUAGEM JAVA 
 
Java é uma linguagem derivada a partir da linguagem de programação C. C foi 
criada, influenciada e testada por programadores profissionais. A linguagem possui 
24 
 
 
 
poucas restrições, códigos estruturados e um conjunto de palavras-chaves limitado. 
Essas características mostram que C trabalha no mais baixo nível, já outras 
linguagens trabalho no nível mais alto. Java é uma das filhas de C. Criada por 
James Gosling, da Sun Microsystems, com o nome de “Oak”, a linguagem deveria 
incorporar os benefícios da programação orientada a objetos sem, no entender do 
criador, a desnecessária complexidade de C (MECENAS 2008). Segundo Mecenas 
(2008) a linguagem Java é dividida nos seguintes componentes: Applets: applet é 
um componente de software que executa uma função limitada em outro ambiente de 
programa, como um navegador da Web. Os applets Java fornecem recursos 
interativos em um navegador da Web por meio do Java Virtual Machine (JVM). 
JVM (Java Virtual Machine): O mecanismo responsável pela interpretação do código 
intermediário Java. A Máquina Virtual Java, embora possa parecer estranho, não 
conhece a linguagem Java. Ela somente reconhece o formato de arquivo .class que 
contém os bytecodes, os quais serão traduzidos para o código binário da plataforma 
hospedeira. JSDK (Java Software Development Kit) ou JDK (Java Development 
Kit): O conjunto de ferramentas de desenvolvimento oferecido pela Sun e outros 
fabricantes, que inclui, como estrutura mínima, um compilador e um interpretador. 
 JRE (Java Runtime Environment): O ambiente de execução Java existente nas 
máquinas dos usuários finais, que apenas executam aplicações Java. O ambiente 
inclui, portanto, a Maquina Virtual Java e as classes que formam a plataforma Java. 
 JDBC (Java Database Connectivity): Arquitetura baseada em interface e 
especificações que permite acesso multiplataforma a bancos de dados. O acesso 
aos dados baseia-se em drivers JDBC, que são implementados por conjuntos de 
classes que dominam a arquitetura e os comandos dos bancos de dados. 
Servlets: Extensões do padrão CGI, escritas em puro Java, usadas para a geração 
de conteúdo dinâmico para a Web. JSP (JavaServer Pages): Conjunto de APIs 
que permitem a criação de páginas web dinâmicas, com acesso a dados e interação 
com o usuário. Atualmente, há uma forte tendência a se utilizar JSP para a parte 
visual das aplicações e Servlets para a lógica de validação econtrole. 
 
9.1 Bancos de Dados e Serviços 
25 
 
 
 
A janela Serviços dá acesso a muitos recursos auxiliares, tais como bancos de 
dados, servidores, serviços web e rastreadores de problemas. Você pode iniciar e 
parar os bancos de dados e servidores diretamente no IDE. Ao trabalhar com 
bancos de dados, você pode adicionar, remover e modificar os seus dados no IDE. 
Quando você implantou um aplicativo para um servidor, você pode gerenciar seus 
recursos mobilizados, porque eles são exibidos no nó Servidores. 
 
Figura : Serviços Básicos 
 
 
9.2 Desenvolvimento de Interface 
 
Projeto de interface gráfica pode ser desenvolvido dentro do próprio IDE, com isso 
facilita a integração da interface e do código fonte do projeto em desenvolvimento, 
vantagem essa muito utilizada pelos usuários dessa ferramenta facilitando assim a 
visualização do usuário final de um software. 
26 
 
 
 
 
 
Figura : Exemplo de interface gráfica 
 
 
Criação de uma interface gráfica de um software contendo dois botões, um título e 
duas caixas de texto mostrados na figura 6. 5.4 Suporte O NetBeans IDE oferece 
suporte para desenvolvedores C/C++ e PHP, fornecendo editores e ferramentas 
para os seus quadros e tecnologias relacionadas. Além disso, o IDE tem editores e 
ferramentas para XML, HTML, PHP, Groovy, Javadoc, Java Script e JSP. NetBeans 
IDE pode ser instalado em todos os sistemas operacionais que suportam Java, a 
partir do Windows para o Linux para sistemas Mac OS. Porque o próprio NetBeans 
IDE é escrito em Java. 
 
9.3 Projeto Exibição: 
 
A janela Projetos é o principal ponto de entrada para as fontes do projeto. Ele 
mostra uma visão lógica do conteúdo do projeto. Além da janela Projetos, o IDE 
fornece a janela Arquivos, para que você possa ver todos os arquivos que 
pertencem a um projeto, e a janela de Favoritos, onde você pode adicionar pastas e 
arquivos de modo que eles podem ser pesquisados dentro do IDE. 
27 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
10 - CONCLUSÃO 
 
A gestão de estoque é um tema que vem sendo retratado nas diversas esferas do 
mundo empresarial, administrá-lo ou gerenciá-lo de maneira eficiente é uma tarefa 
árdua mais necessária, pois estoque em excesso é dinheiro parado, e em pouca 
quantidade é perigo de falta de itens para uma compra de cliente, portanto buscar 
meios que auxiliem no controle do mesmo é de fundamental importância para as 
empresas que querem se manter competitivas diante de um mercado cada vez mais 
exigente e enxuto. 
Para realização deste trabalho foi aplicado um estudo na empresa Peças Ltda, onde 
a todo momento buscou-se entender o porquê da ocorrência de falta e excesso de 
peças na loja, averiguando sempre o controle do estoque através do levantamento 
dos procedimentos de entradas e saídas de materiais, do critérios relacionados aos 
pedidos, dentre outros, com todo esse levantamento constatou-se uma série de 
pequenos problemas, que acaba por gerar perdas e desperdícios para empresa, 
contatou-se também que a falta de treinamento faz com que o setor de vendas não 
esteja completamente antenados nas mudanças e sofisticação das peças, bem 
como desatualizados em relação ao sistema em que a empresa usa, onde uns 
dominam e outros mal o utilizam. 
28 
 
 
 
Portanto levando em consideração a análise dos resultados, podemos afirmar que 
se a empresa continuar com o atual contexto de operacionalização, a tendência é 
que cada vez mais se distanciedos concorrentes e vá perdendo espaço, no 
mercado, apesar de ser uma rotina interna, o gerenciamento de estoque tem reflexo 
imediatos no consumidor final, que pode se chatear por ter que trocar uma peça 
danificada, na qual poderia ter sido vistoriada desde sua chegada a empresa, o 
consumidor pode inclusive deixar de comprar na loja devido ao fato das constantes 
faltas de peças, em que o mesmo necessite de modo urgente, entre outros. 
 
 
 
 
 
 
 
11 – REFERÊNCIAS BIBLIOGRAFICAS 
 
ARNOLD, J. R. Tony. 
Paulo: Atlas, 1999. 
BAGLIN, Gérard et al. 
1990. 
Administração de materiais: Uma Introdução. 1 ed. São 
 
Management industriel et logistique. Paris: Economica, 
BALLOU, Ronald H. Logística Empresarial: transportes, administração de 
materiais, distribuição física. São Paulo. Ed. Atlas. 1993. 
BOWERSOX, Donald J.; CLOSS, David J. Logística empresarial: o processo de 
integração da cadeia de suprimento. São Paulo: Atlas. 2001. 
BROCKA, Bruce M.; BROCKA, Suzanne. Gerenciamento da qualidade. São Paulo: 
Makron Books, 1994. 
CARREIRO, Antonio Almeida. Metodologia da pesquisa científica. Salvador: 2008. 
CATELLI, Armando. Controladoria: uma abordagem da gestão econômica GECON, 2 
ed. São Paulo: Atlas, 2001. 
CERVO, A. L.; BERVIAN, P. A. Metodologia científica. 3. Ed. São Paulo: McGraw- Hill 
do Brasil, 1983. 
CHING, Hong Yuh. Gestão de estoques na cadeia de logística integrada: Supply Chain. 2. 
ed. São Paulo: Atlas. 2001. 
29 
 
 
 
CORREA, H. L. Planejamento Programação e Controle da Produção – MRP II / ERP, 
Conceitos, uso e implantação, São Paulo: Atlas, 2000. 
DIAS, Marco Aurélio P. Administração de Materiais: uma abordagem logística. 3ª ed., 
São Paulo: Atlas,1990. 
DORNIER, Philippe et al. Logística e operações globais. São Paulo: Atlas, 2000. 
ECONOMÁTICA. Software base de dados. Versão Mar. 2003. 1 CD-ROM. FAZANO, 
Carlos Alberto. Qualidade: a evolução de um conceito. São Paulo: Banas 
Qualidade, set. 2006, n. 172. 
FREITAS, João Batista de. SEVERIANO FILHO, Cosmo. APRECIAÇÃO DOS 
CUSTOS OCULTOS DO PROCESSO SUCROALCOOLEIRO EM UMA USINA DE 
ÁLCOOL NA PARAIBA. Revista Gestão Industrial. v. 03, n. 01: p. 52-63, 2007. 
GARCIA, Eduardo S.; REIS, Leticia M. T. V.; MACHADO, Leonardo R.; FERREIRA, 
Virgílio J. M. – Gestão de estoques: otimizando a logística e a cadeia de 
suprimentos. Rio de Janeiro: E-papers Serviços Editoriais Ltda., 2006. 
GOEBEL, Dieter. 1996. Logística: otimização do transporte e estoques na empresa. 
Rio de Janeiro. Estudos em Comércio Exterior v. 1, n. 1. Curso de Pós-Graduação 
em Comércio Exterior – ECEX/IE/UFRJ. Disponibilizado em: 
<http://www.cel.coppead.ufrj.br>. Acesso em 10 nov.2009. 
GIL, A.C. Métodos e técnicas de pesquisa social. São Paulo: Atlas, 1999. LAKATOS, 
Eva Maria; MARCONI, Marina de Andrade. Metodologia científica. 2. Ed. São Paulo: 
Atlas, 1991. 
LEONI, George S.G. Planejamento, Implantação e Controle. São Paulo: 2 ed; Atlas, 
1996. 
LOPES DE SÁ, A. Dicionário de Contabilidade. 8. ed. São Paulo: Atlas, 1990. 
MARTINS, Petrônio Garcia. ALT, Paulo Renato Campos. Administração de materiais e 
recursos patrimoniais. São Paulo: Saraiva, 2004. 
MARTINS, Eliseu. Contabilidade de Custos. São Paulo, Atlas, 2000. VARASCHIM, 
Jacques Douglas. Implantando o SCRUM em um Ambiente de 
Desenvolvimento de Produtos para Internet. Rio de Janeiro, 2009. Java.com. 
Disponível em: . Acesso em: 24 mar. 2013. Netbeans.org. Disponível em: . Acesso 
em: 23 maio 2013. Oracle.com. Disponível em: . Acesso em: 1 nov. 2013. 
http://www.cel.coppead.ufrj.br/
30 
 
 
 
SLACK, Nigel; CHAMBERS, Stuart; HARLAND, Christine; HARRISON, Alan; 
JOHNSTON, Robert. Administração da produção. 1. ed. São Paulo: Atlas. 1997. 
MEGLIONI, Evandir. Custos. São Paulo: Makron Books, 2001. 
NOVAES, Antônio G. Logística e Gerenciamento da Cadeia de Distribuição: 
Estratégia,Operação e Avaliação. Rio de Janeiro. Campus, 2001. 
POZO, Hamilton. Administração de recursos materiais e patrimoniais: uma abordagem 
logística. 2 ed. São Paulo: Atlas, 2002. 
ROCHA, Welington. Gestão Estratégica. Artigo - Faculdade de Economia, 
Administração e Contabilidade – USP. São Paulo. 1999. 
SLACK, Nigel; CHAMBERS, Stuart; HARLAND, Christine; HARRISON, Alan; 
JOHNSTON, Robert. Administração da produção. 1. ed. São Paulo: Atlas. 1997.