Baixe o app para aproveitar ainda mais
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.
Compartilhar