PIM VI Análise e Desenvolvimento de Sistemas

Prévia do material em texto

UNIP INTERATIVA 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
 
 
 
PROJETO DE DESENVOLVIMENTO DE UM SISTEMA PARA UMA LOJA DE 
AUTOPEÇAS. 
 
 
 
 
 
 
 
 
 
 
Unip Interativa – Polo Santo André 
2017 
 
 
 
2 
 
UNIP INTERATIVA 
Projeto Integrado Multidisciplinar 
Cursos Superiores de Tecnologia 
 
 
 
PROJETO INTEGRADO MULTIDISCIPLINAR II – PIM IV 
PROJETO DE DESENVOLVIMENTO DE UM SISTEMA PARA UMA LOJA 
DE AUTOPEÇAS. 
 
 
 
Nome: Bruno Gonzalez Ruiz 
RA: 1444444 
Análise e Desenvolvimento de Sistemas 
PIM VI - DP 
 
 
 
 
 
 
 
Unip Interativa – Polo Santo André 
2017 
 
 
 
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 
 
ABSTRACT: 
 
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... 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
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 cunho familiar. 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 eformulaçã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, produtossemi 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 requisitosfuncionais 
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 o sistema, 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 de uso 
 
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 Sprint O 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 e controle. 
 
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 distancie dos 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. Administração de materiais: Uma Introdução. 1 ed. São 
Paulo: Atlas, 1999. 
BAGLIN, Gérard et al. Management industriel et logistique. Paris: Economica, 
1990. 
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 estoquesna 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. 
 
 
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.