SISTEMA DEDICADO PARA CONTROLE E REPOSIÇÃO DE ESTOQUE:

Transcrição

1 CENTRO ESTADUAL DE EDUCAÇÃO TECNOLÓGICA PAULA SOUZA FACULDADE DE TECNOLOGIA DE SÃO BERNARDO DO CAMPO ADIB MOISÉS DIB EDUARDO CLÁUDIO NICÁCIO JONAS POPOLIN FREI PEDRO HENRIQUE DE SOUZA QUISSELARO SISTEMA DEDICADO PARA CONTROLE E REPOSIÇÃO DE ESTOQUE: FARO Technologies do Brasil Ltda. São Bernardo do Campo SP Junho/2012

2 EDUARDO CLÁUDIO NICÁCIO JONAS POPOLIN FREI PEDRO HENRIQUE DE SOUZA QUISSELARO SISTEMA DEDICADO PARA CONTROLE E REPOSIÇÃO DE ESTOQUE: FARO Technologies do Brasil Ltda. Trabalho de conclusão de curso apresentado ao Centro Estadual de Educação Tecnológica Paula Souza, à Faculdade de Tecnologia de São Bernardo do Campo Adib Moisés Dib como requisito parcial à obtenção do título de tecnólogo em Informática para Gestão de Negócios. Orientadora: Professora Me. Sueli Ap. Loddi. São Bernardo do Campo SP Junho/2012

3 EDUARDO CLÁUDIO NICÁCIO JONAS POPOLIN FREI PEDRO HENRIQUE DE SOUZA QUISSELARO SISTEMA DEDICADO PARA CONTROLE E REPOSIÇÃO DE ESTOQUE: FARO Technologies do Brasil Ltda. Trabalho de conclusão de curso apresentado ao Centro Estadual de Educação Tecnológica Paula Souza, à Faculdade de Tecnologia de São Bernardo do Campo Adib Moisés Dib como requisito parcial à obtenção do título de tecnólogo em Informática para Gestão de Negócios. Monografia defendida e aprovada em: / / 2012 Banca examinadora: Prof. Me. Sueli Aparecida Loddi, FATEC SBC Orientador Prof. Me. Gonçalo Siqueira, FATEC SBC Avaliador Prof. Me. Rosângela Kronig, FATEC SBC Avaliador

4 Dedico este trabalho à minha esposa Andréa, aos meus familiares e aos meus amigos que, ao longo dos últimos três anos, me apoiaram e me incentivaram a dar o melhor de mim. Eduardo Cláudio Nicácio Dedico este trabalho a minha esposa, meus pais, amigos e professores que me apoiaram e me aguentaram durante essa fase da minha vida de estudos. Jonas P. Frei Dedico este trabalho a minha família, amigos da faculdade e a todos os professores. Pedro Henrique S. Quisselaro

5 Aos professores da FATEC-SBC, pela dedicação e paixão com que ministraram todas as aulas ao longo do curso. À nossa professora orientadora, cuja contribuição à conclusão deste trabalho de pesquisa foi de valor inestimável. Às nossas famílias, aos nossos amigos e a todos aqueles que, muito ou pouco, de uma forma ou de outra, nos incentivaram e nos apoiaram ao longo dos últimos três anos.

6 Cada um pensa em mudar a humanidade, mas ninguém pensa em mudar a si mesmo. Leon Nikolaievitch Tolstoi ( )

7 RESUMO Sistemas de Informação são ferramentas indispensáveis para a tomada de decisões dentro das empresas, seja uma decisão de caráter operacional, gerencial ou estratégico. Eles atuam no suporte de todos os processos que compõem a empresa, desde os processos ligados a controladoria, como processos financeiros, contábeis e fiscais, até processos relacionados a materiais, como compras, produção e estoque. Para que os Sistemas de Informação cumpram suas metas, seu processo de desenvolvimento deve levar em conta as boas práticas de Engenharia de Software. Este trabalho teve como objetivo geral abordar os conceitos Gestão de Estoques e Engenharia de Software. Como objetivo específico apresentar o desenvolvimento de um Sistema de Informação para Controle de Estoque, para a empresa FARO Technologies do Brasil Ltda. A metodologia adotada foi uma pesquisa bibliográfica no que tange a Gestão de Estoques e Engenharia de Software, seguida de uma pesquisa de campo para levantamento de necessidades junto empresa e construção do Sistema. Palavras-chaves: Sistema de Informação. Gestão de Estoque. Engenharia de Software. Faro Technologies.

8 ABSTRACT Information Systems are indispensable tools for a decision-making inside companies, even if it is an operational, management or strategic decisions. They acting as a support for all processes that composes the company, from processes related to controlling, financial, accounting and fiscal to processes related to materials, purchasing, production and inventory. For an Information System meet your goals, your development process might take in consideration the good practices from Software Engineer. This study had general objectives to show the concepts about Inventory Management and Software Engineer. Specific objectives were to present the development of an Information System for Inventory Management for the company Faro Technologies do Brasil Ltda. The methodology used was a literature research in terms of Inventory Management and Software Engineer, followed by a field research for needs assessment with the company and the developing of the System. Keywords: Information System. Inventory Management. Software Engineering. Faro Technologies.

9 LISTA DE FIGURAS Figura 1.1 Abrangência do MRP e do MRP II Figura 1.2 Visão geral de um ERP Figura 2.1 Modelo em Cascata Figura 2.2 Modelo Incremental Figura 2.3 Engenharia de software orientada a reuso Figura 2.4 Tipos de Requisitos não funcionais Figura 2.5 Uma visão em espiral do processo de engenharia de requisitos Figura 2.6 Sistema de contexto para estação meteorológica Figura 2.7 Caso de uso estação meteorológica Figura 2.8 Objetos da estação meteorológica Figura 2.9 Diagrama de estado da estação meteorológica Figura 2.10 Interfaces da estação meteorológica Figura 3.1 Diagrama de Casos de Uso Figura 3.2 Diagrama de classes da camada de modelos Figura 3.3 Diagrama de classes da camada de negócios Figura 3.4 Diagrama de classes da camada de acesso a dados Figura 3.5 Diagrama de classes utilitárias Figura 3.6 Modelo Entidade-Relacionamento (MER) Figura 3.7 Tela inicial de login do sistema Figura 3.8 Tela inicial de alteração de senha Figura 3.9 Tela inicial de redefinição de senha Figura 3.10 Tela inicial com informações no dashboard e as opções do menu... 73

10 Figura 3.11 Tela de manutenção de Clientes Figura 3.12 Tela de manutenção de Fornecedores Figura 3.13 Tela de manutenção de Inventário Figura 3.14 Tela de manutenção de Tipo de Uso Figura 3.15 Tela de manutenção de Usuário Figura 3.16 Tela de manutenção de Peças Figura 3.17 Tela de Registro de Entrada de Peças Figura 3.18 Tela de Registro de Saída de Peças Figura 3.19 Tela de Contato com os autores Figura 3.20 Tela de Relatório Consolidado Figura 3.21 Tela de Relatório Consolidado exportado para Excel...84 Figura 3.22 Tela de Relatório de Peças com Quantidades Críticas...85 Figura 3.23 Tela de Relatório de Peças com Quantidades Critica exportado para Excel...86

11 LISTA DE QUADROS Quadro 1.1 Detalhamento dos principais custos do gerenciamento de estoque.. 23 Quadro 1.2 Componentes básicos de um sistema de informação...27 Quadro 3.1 Descrição de Caso de Uso Manter Cadastro de Usuário...55 Quadro 3.2 Descrição de Caso de Uso Manter Estoque...55 Quadro 3.3 Descrição de Caso de Uso Manter Cadastro de Itens Quadro 3.4 Descrição de Caso de Uso Manter Registro de Entrada de Peças. 56 Quadro 3.5 Descrição de Caso de Uso Manter Registro de Saída de Peças Quadro 3.6 Descrição de Caso de Uso Gerar Relatórios Quadro 3.7 Descrição de Caso de Uso Manter Cadastro de Fornecedores Quadro 3.8 Descrição de Caso de Uso Manter Cadastro de Clientes Quadro 3.9 Descrição de Caso de Uso Manter Cadastro de Tipo de Utilização 59 Quadro 3.10 Elicitação de Requisitos Funcionais Quadro 3.11 Elicitação de Requisitos Não-Funcionais Quadro 3.12 Elicitação de Regras de Negócio...61 Quadro 3.13 Lista das ferramentas e recursos utilizados no processo de desenvolvimento do projeto Quadro 3.14 Configuração de Hardware... 67

12 LISTA DE ABREVIATURAS E SIGLAS DAL DAO ERP MER MPS MRP II MRP MVC RUP SBC SCM TI UML Data Access Layer Data Access Object Enterprise Resource Planning Modelo Entidade-Relacional Master Production Schedule Manufacturing Resource Planning Material Requirement Planning Model-View-Controller Rational Unified Process São Bernardo do Campo Supply Chain Management Tecnologia da Informação Unified Modeling Language

13 SUMÁRIO INTRODUÇÃO INTRODUÇÃO À GESTÃO DE ESTOQUES Gestão de Estoques Porque manter estoques Uma visão dos problemas com estoques Tipos de demanda Características básicas da gestão de estoques Restrições e custos relevantes de estoques Vantagem competitiva A inovação como vantagem competitiva A importância da Tecnologia da Informação TI aplicada à Gestão de Estoques MRP, MRP II e ERP INTRODUÇÃO À ENGENHARIA DE SOFTWARE Processos de Desenvolvimento de Software RUP - Rational Unified Process Fases do RUP Engenharia de Requisitos Projeto e implementação Testes de software Implantação... 48

14 2.7 Manutenção Pós-entrega UML Unified Modeling Language O PROJETO DE SOFTWARE A Empresa Fase de Concepção e Elaboração Modelagem de negócio Elicitação de Requisitos Análise Implementação Gerenciamento de configuração e ambiente Construção Modelagem de Negócio / Requisitos / Análise Implementação Testes CONCLUSÃO BIBLIOGRAFIA... 88

15 14 INTRODUÇÃO As grandes empresas do setor de manufatura necessitam diversas ferramentas para monitorar o processo de montagem e reposição de estoque de produtos utilizados em sua linha de produção. Dependendo do produto, diversas matérias primas diferentes são necessárias para sua fabricação, e a falta de qualquer destes itens afeta diretamente o desempenho produtivo da organização, acarretando perda da confiabilidade pelos seus clientes e prejuízos financeiros. As ferramentas da Tecnologia da Informação se tornaram indispensáveis para esse tipo de controle bem como para todos os processos de fabricação. JUSTIFICATIVA: As ferramentas de TI se tornaram indispensáveis para as tarefas diárias de Gestão de Estoque, facilitando a vida do gestor no controle e aquisição de matéria prima, evitando desperdício de materiais ou gastos desnecessários que podem prejudicar o caixa de uma empresa com compras em excesso. OBJETIVOS: Neste trabalho são apresentadas as facilidades que uma ferramenta de TI pode trazer para a tarefa diária de Gestão de Estoque e os conceitos básicos utilizados na modernidade pelas empresas sobre este assunto. Como objetivo específico, é apresentada uma ferramenta desenvolvida para controle de estoque desenvolvido para a empresa FARO Technologies do Brasil, empresa na qual um dos autores desta publicação trabalha e que foi verificada a necessidade de um sistema informatizado para este processo. METODOLOGIA: O desenvolvimento deste trabalho se apresenta pela fundamentação teórica sobre Gestão de Estoque e Engenharia de Software e seu desenvolvimento na qual é abordado o Gerenciamento de Projetos e suas fases. Ao final da fundamentação teórica, é apresentada uma ferramenta de TI desenvolvida para Gestão de Estoque.

16 15 ESTRUTURA: Capítulo 1 - Introdução à Gestão de Estoques: definições, necessidades, problemas, demandas, características, vantagem competitiva e aplicação de TI na Gestão de Estoque; Capítulo 2 - Introdução à Engenharia de Software: definições, processos de desenvolvimento, modelos, metodologias, gerenciamento, implantação e ferramentas de apoio; Capítulo 3 - O Projeto de Software: a empresa, fases do desenvolvimento, casos de uso, diagramas do sistema, gerenciamento de configuração, construção e testes. Conclusão Bibliografia

17 16 1 INTRODUÇÃO À GESTÃO DE ESTOQUES Desde tempos imemoriáveis, a humanidade tem-se valido de estoques de diversos tipos de suprimentos, de modo a suportar o seu desenvolvimento e a sua sobrevivência. O conceito de gestão de estoques é um conceito universal e está presente em praticamente todos os tipos de empresas, assim como no cotidiano da maioria das pessoas. Segundo Ballou (1993), estoque é "a armazenagem de mercadorias prevendo seu uso futuro [...]". Para Marins (2012), "estoques são acúmulos de recursos entre as fases específicas dos processos de transformação". Em administração, estoque refere-se a mercadorias, produtos finais, acabados ou semiacabados, dentre outros recursos, em posse dos agentes econômicos, que, na definição de Carvalho (2007, p. 3, grifos nossos), são "[...] indivíduos, instituições ou conjunto de instituições que, através das suas decisões e ações, tomadas racionalmente, influenciam de alguma forma a economia. São eles as Famílias [...], as Empresas [...], o Estado [...] e o Capital [...]". No meio empresarial, se por um lado o excesso de estoques representa custos operacionais e perdas de oportunidade do capital, por outro lado níveis baixos de estoque podem originar perdas econômicas devido à falta de produtos (custos de vendas perdidas). 1.1 Gestão de Estoques Martins (2012) afirma que gerir um estoque é, basicamente, o ato de gerir os recursos ociosos e possuidores de valor econômico, destinados ao suprimento das necessidades futuras em uma organização. Bertaglia (2009, p. 331), define o gerenciamento de estoque como "[...] um ramo da administração de empresas que está relacionado com o planejamento e o controle de estoques de materiais ou produtos que serão utilizados na produção ou na comercialização de bens ou serviços".

18 17 A gestão dos estoques visa, primariamente, manter os recursos ociosos em inventário em constante equilíbrio com o nível econômico ótimo dos investimentos. "E isto é obtido mantendo estoques mínimos, sem correr o risco de não tê-los em quantidades suficientes e necessárias para manter o fluxo da produção [...] em equilíbrio com o fluxo de consumo" (MARTINS, 2012, p. 13). Martins (2012) explica ainda que a gestão de estoques ainda é, apesar da sua importância, extensão e complexidade, negligenciada em muitas empresas, sendo considerada como uma atividade não estratégica e/ou limitada às tomadas de decisão em níveis organizacionais táticos ou operacionais. Contudo, algumas empresas já perceberam as vantagens competitivas de uma eficiente gestão de estoques ao longo de toda a cadeia de suprimentos da qual fazem parte Porque manter estoques Os estoques existem devido à diferença de ritmo ou de taxa entre a capacidade de produção (ou fornecimento) e a demanda. Ballou (1993) afirma que, idealmente, haveria uma perfeita sincronização entre oferta e demanda, de forma a tornar a existência de estoques desnecessária. Porém, como é impossível prever a exata demanda futura de um produto ou serviço, e como nem sempre os recursos estão disponíveis a qualquer momento, as organizações acumulam estoques com a finalidade de se assegurar a disponibilidade de suprimentos e a minimizar os custos totais de fabricação e distribuição. Ballou (1993) explica que os estoques são, geralmente, uma das maiores preocupações não só dos gestores de operações, mas também dos gestores financeiros, que se preocupam com os custos inerentes aos recursos consumidos; dos gestores comerciais, que se preocupam com o prejuízo que uma possível indisponibilidade de produtos possa acarretar; e dos gestores fabris, que se preocupam com uma possível capacidade fabril ociosa devido à escassez de matéria-prima.

19 18 Para Ballou (1993), há seis finalidades às quais se prestam os estoques: 1) Melhorar o nível de serviço oferecido: os estoques auxiliam a área de marketing a vender os produtos de uma empresa. Estes, podendo estar localizados mais próximos dos pontos de venda e com quantidades adequadas, apresentam duas vantagens claras aos clientes: disponibilidade imediata e menor tempo de ressuprimento. Para quem fornece isso significa vantagem competitiva e menores custos com vendas perdidas. Além disso, a empresa pode beneficiar-se da disponibilidade constante de seus produtos, mesmo no caso de ofertas sazonais; 2) Incentivar economias na produção: estoques agem como um elo entre a oferta e a demanda, possibilitando uma produção mais constante e menos suscetível às flutuações das vendas, uma maior estabilidade à força de trabalho, que pode ser mantida em níveis constantes, e um menor custo de preparação dos lotes, que podem ser diminuidos. Isso ocorre porque, à medida que uma organização aumenta os lotes de fabricação de um produto, seu custo unitário cai; 3) Permitir economias de escala: pequenos lotes de compras, gerados para atender a necessidades de produção ou para o abastecimento direto dos clientes, implicam em maiores custos de frete, pois não há volume suficiente que possibilite a obtenção de descontos. De modo semelhante, as mercadorias tendem a diminuir de preço quando sua compra está vinculada à compra de lotes maiores. A isso, dá-se o nome de economia de escala; 4) Proteger contra alterações nos preços: as curvas de oferta e demanda ditam os preços dos bens comprados no mercado aberto, tais como minérios, produtos do agronegócio, petróleo, etc. As organizações podem antecipar suas compras em vista de aumentos previstos de preços. Esta ação acaba por gerar estoques que, de uma forma ou de outra, a área de logística deve administrar; 5) Proteger contra alterações na demanda / tempo de ressuprimento: na maioria das vezes, não é possível prever, com absoluta certeza, a demanda por produtos ou o tempo de ressuprimento em um sistema logístico. Para garantirem a disponibilidade de seus produtos, as empresas devem manter um estoque adicional, também chamado de estoque de segurança, que deve ser adicionado aos estoques regulares, visando atender as necessidades de produção ou do mercado; 6) Proteger contra contingências: as empresas devem manter estoques de reserva para garantir o fornecimento normal em caso de contingências, que incluem,

20 19 mas não se limitam a, greves, incêndios, catástrofes naturais, guerras, epidemias, etc. Bertaglia (2009), por sua vez, afirma que o investimento em estoques tem dois objetivos estratégicos principais: 1) Maximizar os recursos da empresa: a formação de estoques proporciona, em muitos casos, um melhor balanceamento das operações de uma organização, garantindo uma maior eficiência em suas operações, uma redução de custos de mão-de-obra e a utilização plena da capacidade instalada; 2) Fornecer um nível satisfatório de serviço ao cliente ou consumidor: uma forma de a organização assegurar o atendimento uniforme de seus clientes é através da criação de estoques considerando os limites desejáveis de abastecimento, garantindo, mesmo no caso de picos de demanda, o fornecimento contínuo de produtos e serviços aos seus clientes. 1.2 Uma visão dos problemas com estoques Ballou (1993) explica que, como tendência geral, os estoques têm crescido juntamente com as vendas ao longo dos anos, sendo que os bens não duráveis, como roupas e alimentos, representam um terço dos estoques totais nas empresas, ao passo que os bens duráveis, como automóveis e máquinas de lavar, representam os dois terços restantes. Isso se deve ao fato de que os estoques de bens duráveis apresentam oscilações maiores que os estoques de bens não duráveis, uma vez que sua compra pode ser adiada mais facilmente. Para Bertaglia (2009, p. 333), "a compreensão dos objetivos estratégicos da existência e do gerenciamento dos estoques é fundamental para se definir metas, funções, tipos de estoque e [...] como eles afetam as organizações em suas atividades [...]". De acordo com Ballou (2004), a previsão dos níveis de demanda ao longo do ciclo de um produto é fundamental à empresa como um todo, uma vez que propicia dados básicos para o planejamento e controle de diversas áreas, tais como a

21 20 logística, o marketing, a produção e as finanças. Martins (1999) define previsão como sendo [...] um processo metodológico para a determinação de dados futuros baseado em modelos estatísticos, matemáticos ou econométricos ou ainda em modelos subjetivos apoiados em uma metodologia de trabalho clara e previamente definida Tipos de demanda Para Ballou (1993), a divisão dos estoques em classes ou tipos facilita seu controle, e uma das melhores formas de se classificá-los é quanto à natureza da sua demanda, que pode ser permanente, sazonal, irregular, declinante ou derivada. O autor as define: Demanda permanente: ocorre com os produtos que possuem ciclos de vida muito longos, sem grandes picos ou vales de consumo ao longo do ano. Estoques de produtos com demanda permanente requerem ressuprimento contínuo, e seu controle é orientado para a previsão de demanda de itens, à determinação do momento de ressuprimento, e à definição do tamanho do lote de ressuprimento; Demanda sazonal: estoques mantidos para produtos altamente sazonais ou que apresentam altos picos de consumo dificilmente podem ser liquidados, a não ser à base de promoções e com descontos vantajosos. Nesta categoria temos, por exemplo, os enfeites natalinos, os itens de campanhas políticas e os ovos de páscoa; Demanda irregular: é aquela que apresenta um padrão irregular, e existe inclusive para produtos de demanda contínua. O controle de estoques para produtos com demanda irregular está vinculado à previsão precisa das vendas, principalmente quando essa flutuação está atrelada a tempos de ressuprimento demasiadamente longos ou inflexíveis; Demanda em declínio: há produtos cuja demanda finda em um momento previsível no futuro. O declínio desse tipo de demanda é gradual, possibilitando que seu estoque excedente seja diminuído aos poucos. Há produtos, no entanto, que apresentam um fim de demanda abrupto, mas planejado. Nesta categoria

22 21 encontram-se, por exemplos, os materiais militares, que possuem sua vida útil definida na concepção do projeto; Demanda derivada: ocorre quando o padrão de demanda de determinado produto deriva-se da demanda de outro produto. O estoque requerido para atender a uma demanda derivada é, também, derivado. Pode-se determinar com precisão quanto e quando devemos produzir certo bem através da demanda de outro bem. Por exemplo, podemos prever precisamente quanto se deve produzir de pneus dados à demanda de veículos zero quilômetro. 1.3 Características básicas da gestão de estoques Fitzsimmons (2004) diz que para que se possa projetar, programar e gerenciar um sistema de estoque, tem que saber as características de cada item estocado e conhecer suas variáveis, bem como os vários sistemas de estoque disponível. Bertaglia (2009) afirma que a flutuação nos níveis dos estoques de uma empresa impactam diretamente suas finanças, e propõe o uso de alguns indicadores de desempenho que visam auxiliar no monitoramento dos estoques, tais como o giro de estoque e a cobertura de estoque. "O giro de estoque corresponde ao número de vezes que o estoque é totalmente consumido durante um determinado período (normalmente um ano)" (BERTAGLIA, 2009, p. 333). Esse indicador é calculado com base na relação do volume vendido no ano dividido pelo capital médio investido, e é comumente utilizado pelas empresas para comparar seu desempenho ao de empresas similares. É dado pelas fórmulas: Giro de estoque = Vendas anuais ($) Estoque médio ($) ou Giro de Estoque = Vendas anuais (unid.) Estoque médio (unid.)

23 Restrições e custos relevantes de estoques Quando se fala sobre os custos que envolvem no estoque, não se deve levar em consideração apenas o custo da aquisição do material junto ao fornecedor, mas também, os custos relativos à sua logística, estocagem e também as perdas financeiras decorrentes à falta de itens em estoque, como demonstra FITZSIMMONS e FITZSIMMONS (2004, p. 346): O desempenho de um sistema de estoque é geralmente medido por seu custo médio anual. [...] incluem os custos de manutenção, de pedido, de falta de produtos e o custo de compras dos itens. [...] O custo de oportunidade associado com o capital investido no estoque é o maior componente do custo de manutenção. Existem outros componentes que afetam o custo do estoque como os custos com seguro e obsolescência. Outro custo que deve ser levado em consideração é o custo da variação cambial / taxas de importação existentes para os produtos importados. Importar vários itens em apenas um pedido, quando do mesmo fornecedor, faz com que se dilua o valor de algumas taxas aduaneiras fixas, que são cobradas por processos de importação. O quadro 1.1 detalha os principais custos do gerenciamento de estoque:

24 23 Custos do pedido Definição das especificações dos itens a serem comprados; Localização ou identificação de fornecedores potenciais e solicitação de preços; Avaliação de preços e seleção de fornecedores; Negociação de preços; Preparação das ordens de compra; Emissão ou transmissão das ordens de compra aos fornecedores externos; Acompanhamento para garantir que as ordens de compras foram recebidas pelos fornecedores. Custos de recebimento e inspeção Transporte, expedição e recebimento; Preparação e manuseio de registros de recibos e outros papéis; Exame das embalagens a fim de verificar danos visíveis; Desembalar os itens; Contagem ou pesagem de itens a fim de garantir que a quantidade correta tenha sido entregue; Coleta de amostras e encaminhamento para organismos de inspeção e teste; Inspeção e teste dos itens a fim de garantir que estejam em conformidade com as especificações de compras; Transferências dos itens para as áreas de armazenagem. Custo de manutenção Encargos financeiros associados aos estoques; Custo de oportunidade do capital associados aos itens, armazenagem e outros elementos do sistema de inventário; Taxas e seguro; Movimentação dos itens para dentro e fora da área de estocagem e manutenção dos registros das movimentações; Furto ou roubo; Fornecimento de sistemas de segurança para proteção dos estoques; Quebras, danos e deterioração; Obsolescência das peças e descarte de material com prazo de validade vencido; Depreciação; Espaço de armazenagem e instalações (normalmente, o dimensionamento é baseado no estoque máximo em vez do médio); Fornecimento de ambientes com temperatura, umidade, limpeza, etc., controlados; Gerenciamento (tarefas tais como supervisão do pessoal de estoques, quantificação periódica do inventário físico, verificação e correção de registros, etc.). Custo de manutenção Vendas e lucros perdidos; Insatisfação e má vontade do cliente: clientes perdidos; Penalidades por atraso na entrega ou por não entregar mercadorias; Expedição de pedidos para reabastecer estoques esgotados. Quadro Detalhamento dos principais custos do gerenciamento de estoque Fonte: FITZSIMMONS E FITZSIMMONS, 2005, p.345

25 Vantagem competitiva Turban, Rainer e Potter (2005, grifo nosso) definem vantagem competitiva como sendo uma vantagem em relação aos concorrentes em alguma medida como custo, qualidade ou velocidade que leva ao controle de um mercado e lucros maiores que a média. Segundo Faria (2005), para as empresas, vantagem competitiva é o que faz com que a sua oferta seja a escolhida pelos seus clientes e clientes potenciais, dentre todas as ofertas disponíveis no seu mercado de atuação. competitiva: De acordo com Porter (1996, apud Loddi, 2006, p. 40) a vantagem [...] surge fundamentalmente do valor que uma empresa consegue criar para seus compradores e que ultrapassa o custo de fabricação pela empresa. O valor é aquilo que os compradores estão dispostos a pagar, e o valor superior provém da oferta de preços mais baixos do que os da concorrência por benefícios equivalentes ou do fornecimento de benefícios singulares que mais do que compensam um preço mais alto. Existem dois tipos de vantagem competitiva: liderança de custo e diferenciação [...]. De acordo com Turban, Rainer e Potter (2005), a estrutura mais conhecida para se analisar a competitividade das organizações é o modelo de forças competitivas de Michael Porter, usado para o desenvolvimento de estratégias que aumentem as margens competitivas da organização e, também, para demonstrar como a Tecnologia da Informação pode auxiliar nesse processo. O modelo reconhece cinco forças principais que influenciam o posicionamento de uma empresa em um determinado setor: a ameaça de novos entrantes, o poder de negociação dos fornecedores, o poder de negociação dos clientes, a ameaça de substituição de produtos e serviços e a rivalidade entre as empresas existentes no setor. As empresas tentam continuamente desenvolver estratégias voltadas à manutenção de uma posição lucrativa e sustentável contra as cinco forças de Porter. Este autor, assim como outros, propôs algumas estratégias com a finalidade de

26 nortear as organizações na obtenção de vantagem competitiva. Turban, Rainer e Potter (2005) destacam doze dessas estratégias: 25 1) Estratégia de liderança de custo: estratégia baseada na criação de produtos ou serviços no menor custo do setor de atuação; 2) Estratégia de diferenciação: estratégia baseada na oferta de diferentes produtos, serviços ou recursos de produtos; 3) Estratégia de nicho: estratégia que envolve a seleção de um segmento de escopo estreito (nicho de mercado) e ser o melhor em qualidade, velocidade ou custo; 4) Estratégia de crescimento: estratégia baseada no aumento da fatia de mercado, na atração de novos clientes ou na venda de mais produtos; 5) Estratégia de inovação: estratégia baseada na introdução de novos produtos e serviços, na adição de recursos aos produtos ou serviços existentes, ou no desenvolvimento de novas formas de produzi-los; 6) Estratégia de aliança: estratégia que consiste no trabalho com parceiros de negócios em parcerias, alianças, empreendimentos conjuntos ou empresas virtuais, criando sinergia, permitindo que as empresas se concentrem em seus negócios de base e oferecendo oportunidades de crescimento; 7) Estratégia de eficácia operacional: estratégia que consiste em melhorar a maneira como os processos de negócios internos são executados, permitindo à organização realizar tarefas semelhantes melhor que suas concorrentes; 8) Estratégia de orientação ao cliente: estratégia que consiste na concentração de esforços visando à satisfação dos clientes; 9) Estratégia de tempo: estratégia que consiste em tratar o tempo como recurso, que deve ser gerenciado e usado em benefício da organização; 10) Estratégia de barreiras à entrada: estratégia que consiste na criação de barreiras à entrada de novos competidores, por exemplo, através de patentes ou serviços únicos; 11) Estratégia de fidelização de clientes ou fornecedores: estratégia que consiste em encorajar clientes ou fornecedores a fazerem negócios com a organização, ao invés de seus concorrentes;

27 26 12) Estratégia de aumento de custos de troca: estratégia que consistem em desencorajar que clientes ou fornecedores passem para a concorrência por motivos econômicos A inovação como vantagem competitiva Devido à grande competitividade em grande parte dos segmentos de mercado, as empresas buscam a todo o momento oferecer em seus produtos e serviços diferenciais que as coloquem em vantagem em relação à concorrência. Uma das maneiras mais eficientes para que se consiga essa vantagem ou diferenciação é por meio da inovação. Segundo Santos (2012), a cada dia novas tecnologias chegam ao mercado e as empresas em geral inovam seus produtos e serviços aplicando o que há de mais sofisticado para a satisfação plena de seus clientes. A vantagem competitiva na era do conhecimento é ainda mais importante do que na velha economia, pois, como se pode observar, a economia digital não mudou o negócio principal das organizações: as tecnologias de Internet tão e somente oferecem as ferramentas que podem aumentar o sucesso das organizações por meio de suas fontes tradicionais de vantagem competitiva. Ortuño (2007) lembra que a maioria das grandes empresas que se destacam no segmento que atuam, e resistem a épocas de crise, tem a inovação como prioridade. Segundo Pegrino (2010), apesar de ser a maneira mais comum, inovar não é necessariamente criar um novo produto ou serviço, é possível também inovar melhorando os produtos e serviços que já existem. Segundo Rikard (2008), a inovação, ao contrário da invenção, tem o caráter de atribuir valor a uma determinada invenção, tornando-a revolucionária e a deixando na memória das pessoas.

28 27 Peregrino (2010) define inovação como sendo o caminho que as empresas devem permanente percorrer para enfrentar os desafios do mercado e se manter jovens e competitivas. empresas: Brandão et al. (2006, p. 15) destaca a importância das inovações para as Inovações acrescentam valor a produtos, ajudando as empresas a sobreviver num cenário crescentemente competitivo. Elas têm utilidades múltiplas: dão acesso a novos mercados, aumentam lucros, geram emprego e renda, fortalecem marcas. Para Cavagnoli (2009), mesmo sendo importante, são poucas as empresas brasileiras que usam a inovação para se manterem competitivas A importância da Tecnologia da Informação Turban, Rainer e Potter (2005, p. 40) definem Tecnologia da Informação como [...] a coleção de recursos de informação de uma organização, seus usuários e a gerência que os supervisiona; inclui a infraestrutura de TI e todos os outros sistemas de informação em uma organização. Estes autores definem que, basicamente, os sistemas de informação são compostos por quatro componentes como apresentado no quadro 1.2: COMPONENTE Hardware Software Banco de dados Rede DEFINIÇÃO Um conjunto de dispositivos (por exemplo, processador, monitor, teclado e impressora) que, juntos, aceitam dados e informações, os processam e os apresentam. Um conjunto dos programas que permitem que o hardware processe dados. Uma coleção de arquivos relacionados, tabelas, relações e assim por diante, que armazenam dados e associações entre eles. O conjunto de conexão (com ou sem fio) que permite o compartilhamento de recursos por diferentes computadores. Quadro 1.2 Componentes básicos de um sistema de informação Fonte: Adaptado de TURBAN, RAINER e POTTER, 2005, p.41

29 28 Dentro do processo de inovação com objetivo de fazer com que a empresa se torne cada vez mais competitiva, a Tecnologia da Informação é indispensável, conforme a declaração de Bertaglia (2009, p. 474): Hoje, essa tecnologia é parte integrante da empresa e quem não enxergar isso terá seu futuro extremamente comprometido. A tecnologia da Informação ajuda a transformar radicalmente as características da empresa, seja na produção, na distribuição ou no serviço ao cliente. Grande parte das organizações não percebe a importância de usá-la como elemento importante que dá suporte na luta pela competitividade. "Uma empresa que hoje não tenha pelo menos alguns recursos de TI para atender ao cliente e agilizar os processos perde competitividade [...]" (HABERKORN, 2009, p. 26). Porter (2004) define liderança no custo total, diferenciação e enfoque, como estratégias competitivas genéricas. A Tecnologia da Informação contribui diretamente com essas estratégias, pois segundo Ramos, Silva e Alvarenga (2009, p. 10) a TI pode contribuir com redução de custos, ganhos de produtividade, prospecção de novos mercados, facilidade de relacionamento com clientes e fornecedores, conhecimento do mercado de atuação e da conjuntura econômica [...]. Santos (2009) lembra que durante muito tempo a Tecnologia da Informação era vista apenas como um 'centro de custo', que não gerava retorno para a organização. Atualmente as empresas já enxergam a importância da tecnologia da informação como arma estratégica, porém, para Barbaceli (2009), "não é difícil encontrar departamentos de TI desconectados à realidade dos negócios da empresa. [...]". Para que a Tecnologia da Informação seja realmente um diferencial para a empresa, é necessário que o departamento esteja alinhado ao negócio da organização. "Antes de estabelecer uma estratégia para a Tecnologia de Informação, a empresa deve claramente identificar o papel dessa área no contexto organizacional [...]" (BERTAGLIA, 2009, p. 477).

30 TI aplicada à Gestão de Estoques Historicamente, muitas atividades do gerenciamento das cadeias de fornecimento eram feitas manualmente usando papéis, telefones e faxes, mas isso pode ser bastante ineficiente. Assim, desde a época em que os computadores começaram a ser utilizados nos negócios, as pessoas desejaram automatizar os processos ao longo da cadeia de fornecimento. (TURBAN, RAINER e POTTER, 2005, p. 301). Um sistema de controle de estoque é um conjunto de regras e procedimentos que permitem responder às perguntas de grande importância, e tomar decisões sobre os estoques (MOREIRA, 2004, p.270 apud CHAGAS, SOUZA e SIMÃO, p. 3) MRP, MRP II e ERP Estas siglas começaram a ser usadas na década de O MRP 1 ( Material Requirement Planning), segundo Haberkorn (2009, p. 14), [...] calculava tudo o que deve ser comprado e produzido. Esses sistemas eram direcionados a grandes fábricas, que tinham uma grande linha de produtos, que por sua vez eram compostos por uma grande variedade de componentes e matérias primas. Martins e Laugeni (2006) explicam que o MRP surgiu da necessidade de se controlar a quantidade de matéria prima necessária para a produção dos produtos que eram oferecidos ao mercado, considerando a sua demanda. que: Segundo Correa, Gianesi e Caon (2007, p. 78) o MRP baseia-se na ideia de [...] se são conhecidos todos os componentes de determinado produto e os tempos de obtenção de cada um deles, podemos, com base na visão de futuro das necessidades de disponibilidade do produto em questão, calcular os momentos e as quantidades que devem ser obtidas, de cada um dos componentes para que não haja falta nem sobra de nenhum deles, no suprimento das necessidades dadas pela produção do referido produto. 1 MRP: Material Requirement Planning em português, Planejamento para Requisição de Materiais

31 Para a realização de seus cálculos, o MRP necessita de quatro tipos de entradas (VOLLMANN, BERRY E WHYBARK apud SOUZA, 2001): 30 1) Planejamento Mestre de Produção (MPS): Informações de ordens planejadas e programadas para cada item, contendo quantidades necessárias e datas das necessidades; 2) Situação de Inventário: Provê informação de inventário disponível; 3) Estrutura de Produto (Lista de Materiais): Componentes e quantidades necessárias para se produzir uma unidade; 4) Registros de Planejamento: tamanho de lote, lead time, fatores de perda e estoques de segurança. Além disso, o MRP utiliza parâmetros, que são: a) Política de lotes mínimos: indica a quantidade mínima de abertura de uma ordem, permitindo qualquer quantidade deste nível mínimo ou superior; b) Política de lotes máximos: indica a quantidade de lote máxima a ser aberta, não permitindo produções de quantidades acima do máximo definido; c) Política de períodos fixos: o sistema calcula todas as necessidades ao longo de períodos futuros, de duração definida, período a período, e concentra no início desses períodos os recebimentos planejados do total das necessidades calculadas; d) Estoques de Segurança: quantidade de estoque planejada para estar em inventário visando à proteção contra as flutuações de demanda e suprimentos; e) Lead Time: tempos de obtenção ou ressuprimento. É o tempo que decorre entre a liberação de uma ordem (de compra ou produção) e o material correspondente estar pronto e disponível para uso. O avanço da tecnologia relacionada aos computadores colaborou para que a ideia do MRP também sofresse mudanças e evoluísse. Em 1980 pode-se ver o surgimento de um novo conceito de sistema de informação, que foi chamado de MRP II 2 (Manufacturing Resources Planning). 2 MRPII: do inglês Manufacturing Resources Planning ou Planejamento de Recursos para Produção.

32 31 Apesar de utilizarem a mesma sigla, o MRP e o MRPII eram sistemas com funcionalidades diferentes, já que de modo geral, o MRP I dizia apenas produza isso, compre aquilo. Já o MRP II indicava como produzir [...] (HABERKORN, 2009, p.14). Para controlar o processo de produção, o MRP II consequentemente passou a considerar e controlar outras variáveis, tornando os seus cálculos mais complexos do que os cálculos efetuados pelo MRP I. O sistema MRP II [...] não calculava apenas as necessidades de materiais, mas também as necessidades de outros recursos do processo de manufatura (CORREA, GIANESI E CAON, 2007, p.133), Além dos materiais que já eram tratados, passou-se a considerar também outros insumos, como mão de obra, equipamentos, espaços disponíveis para estocagem, instalações, entre outros [...] (MARTINS e LAUGENI, 2006, p. 354). Existem fatores importantes que devem ser respeitados para que o MRP II funcione de maneira eficaz. Por se tratar de um sistema que tem como objetivo integrar os processos da empresa é necessário que as informações sejam compartilhadas entre todos envolvidos no uso do sistema, unificando a base de dados. Outro fator importante é a exatidão dos dados que são inseridos pelos usuários, considerando que as informações geradas pelo sistema e que influenciarão no processo de produção da empresa, dependem diretamente desses dados. Ou seja, o bom funcionamento de um sistema MRP II depende do comprometimento das pessoas envolvidas (CORRÊA, GIANESI E CAON, 2007). A figura 1.1 demonstra a abrangência do MRP I e do MRP II:

33 32 Figura Abrangência do MRP e do MRP II Fonte: CORRÊA, GIANESI e CAON, 2007, p.134 Em 1990 surge o conceito de ERP (Enterprise Resources Planning) 3, ainda mais abrangente que o MRP II, cujo objetivo, na visão de Slake, Chambers e Johnston (2009, p. 438) era [...] integrar a gestão de diferentes funções do negócio como um todo, de modo a aprimorar o desempenho de todos os processos interrelacionados do negócio. Correa, Gianesi e Caon (2007, p. 390) afirmam que um sistema dito ERP tem a pretensão de suportar todas as necessidades de informação para a tomada de decisão gerencial de um empreendimento como um todo. O sistema ERP assim como MRP II funciona com uma única base de dados, porém além das informações do setor de manufatura, o ERP concentra informações de todas outras áreas da empresa. O ERP é um sistema que facilita o fluxo de informações dentro de uma empresa, integrando as diferentes funções, quais sejam: manufatura, logística, 3 ERP: do inglês Entreprise Resources Planning ou Planejamento de Recursos Empresariais

34 finanças, recursos humanos e engenharia, entre outras (MARTINS e LAUGENI, 2006, p. 388). Na figura 1.2 é mostrada a visão geral de um ERP: 33 Figura Visão geral de um ERP Fonte: MARTINS e LAUGENI, 2006, p.388 O ERP apresentou uma trajetória de constante evolução e chegou a um estágio em que resolveu praticamente todos os processos operacionais dentro da empresa (HABERKORN, 2009, p. 27). Durante esse processo de evolução os sistemas ERP adquiriram novas funcionalidades, uma delas é o SCM (Supply Chain Management) Gerenciamento da cadeia de suprimentos, que está diretamente ligada à gestão de estoques. Cadeia de suprimentos é o processo da movimentação de bens desde o pedido do cliente através dos estágios de aquisição de matéria prima, produção até a distribuição dos bens para os clientes (ROCKFORD CONSULTING GROUP RCG (2001) apud BRUSTELLO E SALGADO, 2006, p. 1).

35 34 Segundo Martins e Laugeni (2006, p. 170): [...] a gestão da cadeia de abastecimento ou Supply Chain Management diz respeito às práticas de gestão que são necessárias para que todas as empresas agreguem valor ao cliente desde a fabricação dos materiais, passando pela produção dos bens e serviços, a distribuição e a entrega final ao cliente. Martins e Laugeni (2006) ainda afirmam que os sistemas ERP de grande porte, inclusive sistemas brasileiros, têm funcionalidades para a gestão da cadeia de suprimentos, e que existem sistemas que são desenvolvidos exclusivamente com esta finalidade.

36 35 2 INTRODUÇÃO À ENGENHARIA DE SOFTWARE Engenharia de Software é uma disciplina que estuda os aspectos de produção de software, desde sua especificação, projeto e evolução de programas, sendo este estudo o diferencial de um software amador para um software profissional, como define Sommerville (2011). O autor afirma, ainda, que software não é apenas uma palavra para programas de computador, mas engloba também, além do programa em si, toda a sua documentação associada e, dados de configuração para que o programa opere corretamente. Schach (2009, p. 4) complementa a definição de Engenharia de Software da seguinte maneira: [...] é uma disciplina cujo objetivo é produzir software isento de falhas, entregue dentro de prazo e orçamento previstos, e que atenda às necessidades do cliente. Além disso, o software deve ser fácil de ser modificado quando as necessidades do usuário mudarem. 2.1 Processos de Desenvolvimento de Software Processo de desenvolvimento de software é definido por Pfleeger (2004) como uma série de etapas a serem seguidos que envolvem atividades, restrições e recursos para alcançar uma saída desejada. Entre estes recursos, este autor descreve como um conjunto de ferramentas e técnicas para o desenvolvimento de um software, conceito utilizado também por Sommerville (2011). Sommerville (2011) define alguns processos para o desenvolvimento de softwares. Os quatro mais importantes são: 1) Especificação de software: funcionalidades e restrições do software; 2) Projeto e implantação de software: Produção do software deve atender às especificações; 3) Validação de software: validação do software pelo cliente; 4) Evolução de software: o software deve evoluir conforme necessidade de mudança do cliente.

37 36 Pfleeger (2004) define que o desenvolvimento de software envolve vários estágios ou processos diferentes, entre eles: análise e definição de requisitos, projeto do sistema, projeto do programa, programação em si, teste do software, implantação do sistema e a manutenção. O autor ainda acrescenta que estes processos podem ser organizados como um modelo. Existem vários modelos de processo de desenvolvimento de software que podem ser utilizados conforme a necessidade e que visam tornar o desenvolvimento de software mais eficiente. Sommerville (2011, p. 19) explica que [...] um modelo de processo de software é uma representação simplificada de um processo de software. O autor aborda três modelos diferentes de processo e os define da seguinte maneira: 1) O modelo em cascata: considera as atividades fundamentais do processo de especificação, desenvolvimento, validação e evolução, representando cada uma delas como fases independentes, como ilustra a figura 2.1: Figura 2.1 Modelo em Cascata Fonte: SOMMERVILLE, 2011, p.20 2) Desenvolvimento Incremental: intercala cada processo de desenvolvimento. São criadas várias versões incrementais, sendo adicionadas a cada versão novas funcionalidades em relação à versão anterior. A figura 2.2 ilustra o processo incremental de desenvolvimento:

38 37 Figura 2.2 Modelo Incremental Fonte: SOMMERVILLE, 2011, p.22 3) Engenharia de software orientada a reuso: quando existe uma quantidade significativa de componentes reusáveis e que vão sendo integrados ao sistema conforme as fases de seu desenvolvimento. A figura 2.3 ilustra este modelo: Figura 2.3 Engenharia de software orientada a reuso Fonte: SOMMERVILLE, 2011, p Rational Unified Process (RUP) Martins (2010) define o RUP 4 como uma metodologia para gerenciar projetos de software utilizando-se do UML 5 como uma ferramenta para especificação de sistemas. Sommerville (2011) complementa que o RUP é um modelo moderno e genérico de processo de desenvolvimento de software e que está dividido em fases, sendo estas: a concepção, elaboração, construção e transição, dividindo as atividades em requisitos, análise, projeto, entre outras. 4 RUP (Rational Unified Process): Processo Unificado de Desenvolvimento de software criado pela Rational Inc.. 5 UML (Unified Modeling Language): Processo unificado de modelagem de software representada por diagramas.

39 38 Martins (2010) aponta as seguintes ferramentas e recursos do RUP: 1) Desenvolvimento iterativo: permite gerenciar melhor os requisitos, facilitando o tratamento das descobertas constantes ocorridas durante o projeto; 2) Gerenciamento de requisitos: gerenciar os requisitos que além de essenciais para o projeto, podem mudar durante a vida do projeto por serem dinâmicos e mutáveis por diversos motivos como, por exemplo, a mudanças do problema, da ideia do usuário, das técnicas e do mercado; 3) Arquitetura baseada em componentes: estruturar a arquitetura do sistema em componentes, viabilizando a reutilização e a personalização de componentes; 4) Organização da especificação em modelos : utilização de modelos gráficos baseados na UML para apresentação geral do software; 5) Verificação constante da qualidade: garantir que o software durante seu ciclo de vida funcione conforme o esperado em relação as funcionalidades, confiabilidade e performance; 6) Controle de mudanças: controle das versões criadas e modificadas durante o processo de desenvolvimento do software. Além dessas ferramentas e recursos, o autor adiciona que o RUP organiza o sistema com estrutura estática ou dinâmica, além de trabalhar com processos focados na arquitetura e nos casos de uso Fases do RUP Martines (2010) explica as quatro fases do RUP: 1) Fase de Concepção / Iniciação: abrange tarefas de comunicação com o cliente e o planejamento. É feito um plano de projeto avaliando os possíveis riscos, as estimativas de custo e prazos, estabelecendo as prioridades, levantamento dos requisitos do sistema e preliminarmente fazendo suas análises. Assim, haverá uma anuência das partes interessadas na definição do escopo do projeto, onde são examinados os objetivos para se decidir sobre a continuidade do desenvolvimento;

40 39 2) Fase de Elaboração: abrange a modelagem do modelo genérico do processo. O objetivo desta fase é analisar de forma mais detalhada a análise do domínio do problema, revisando os riscos que o projeto pode sofrer e a arquitetura do projeto começa a ter sua forma básica. Dúvidas sobre a confiabilidade do projeto e se os custos serão admissíveis são esclarecidas durante esta etapa; 3) Fase de Construção: desenvolve ou adquire os componentes de software. O principal objetivo desta fase é a construção do sistema de software, com foco no desenvolvimento de componentes e outros recursos do sistema. Durante esta etapa, a grande parte da codificação do software é desenvolvida; 4) Fase de Transição: abrange a entrega do software ao usuário e a fase de testes. O objetivo desta fase é a disponibilização do sistema, tornando-o funcional e compreensível pelo usuário final. As atividades desta fase incluem o treinamento dos usuários finais e a realização de testes da versão beta do sistema visando garantir que o mesmo possua o nível adequado de qualidade e que o sistema atenda os requisitos mínimos desejados. Maia (2009) destaca que em cada uma dessas fases é realizada uma série de atividades agrupadas por disciplinas e que a intensidade dessas atividades variam de acordo com a fase em que esta é realizada. O autor descreve as dez disciplinas: Modelagem de Negócios, Requisitos, Análise e Design, Implementação, Teste, Implantação, Ambiente, Gerenciamento de Projeto, Gerenciamento de Configuração e Mudança. Cada disciplina mostra todas as atividades que você deve realizar para produzir um determinado conjunto de artefatos. Essas disciplinas são descritas em nível geral um resumo de todos os papéis, atividades e artefatos envolvidos. É uma maneira de demonstrar em um nível mais detalhado como ocorre a colaboração entre papéis e de que forma eles usam e produzem artefatos. Os passos nesse nível detalhado são chamados de "detalhamentos do fluxo de trabalho". 2.3 Requisitos de Sistema Para iniciar o processo de desenvolvimento de qualquer software, é imprescindível que o programador conheça as reais necessidades do seu cliente usuário final, como definido por Pfleeger (2007, p. 111), que afirma ser necessário [...] compreender o que os clientes e usuários esperam que o sistema realize.

41 40 Sommerville (2011) complementa esta definição afirmando que os requisitos, além de descrever o que o sistema deve fazer, ajudam a definir os serviços que ele irá oferecer e as restrições a seu funcionamento, e ainda utiliza dois termos distintos para a definição de requisitos: 1) Requisitos de usuário: são declarações utilizando uma linguagem natural com diagramas demonstrando quais serviços o sistema deverá fornecer aos seus usuários e quais são suas restrições de operação; 2) Requisitos de sistema: são descrições detalhadas das suas funções, serviços e as restrições de operação do sistema de software. A documentação dos requisitos de sistema deve definir exatamente o que o sistema deverá ter. A partir desta definição, existem dois tipos de requisitos básicos que um sistema necessita, sendo eles os Requisitos Funcionais e os Requisitos Não Funcionais. Pfleefer (2007) define requisitos funcionais como uma interação entre o sistema e seu ambiente. Sommerville (2011) complementa esta definição explicando que os requisitos funcionais são as declarações do que o sistema deverá fornecer, como deverá reagir com as entradas específicas e como deverá se comportar em cada situação, além de poder explicitar o que o sistema não deve fazer. Os requisitos não funcionais são definidos por Sommerville (2011) como requisitos que demonstram as restrições aos serviços ou funções que o sistema oferece, como por exemplo, restrições impostas por normas e no processo de desenvolvimento, tempos de execução do sistema e plataforma de uso. O autor ainda complementa dizendo que estes requisitos, diferentemente dos requisitos funcionais, muitas vezes se aplicam ao sistema como um todo. A figura 2.4 mostra os tipos de requisitos não funcionais:

42 41 Requisitos não funcionais Requisitos de usabilidade Requisitos de eficiencia Requisitos de produtos Requisitos de confiança Requisitos de proteção Requisitos organizacio nais Requisitos reguladores Requisitos éticos Requisitos externos Requisitos legais Requisitos contábeis Requisitos de desempenho Requisitos de espaço Requisitos ambientais Requisitos operacionais Requisitos de desenvolvimento Requisitos de segurança/ proteção Figura 2.4 Tipos de Requisitos não funcionais Fonte: SOMMERVILLE, 2011, p.61 Segundo Pfleefer (2007), por ser um passo importante para o desenvolvimento do sistema, os requisitos devem ser discutidos entre o programador e o usuário para que ambos concordem e não haja dúvidas no momento do desenvolvimento ou expectativas falsas pelo usuário no momento da entrega. Requisitos fazem parte do sistema, sendo uma característica dele ou a descrição do que ele pode realizar. Sommerville (2011) corrobora esta afirmação complementando que as especificações de requisitos devem ser claras, inequívocas e de fácil compreensão, completas e consistentes, evitando diferentes interpretações tanto pelo cliente quanto pelo grupo de desenvolvedores que trabalharão no desenvolvimento do software. Quando especificados os requisitos, dois tipos de documentos são criados, sendo um deles de modo mais geral, sem muitos termos técnicos, porém, de uma maneira que o cliente ou usuário possam ler e compreender os requisitos elicitados; e um mais técnico, a ser utilizado pelos desenvolvedores do sistema, onde será descrito minuciosamente como cada requisito deverá ser trabalhado. A figura 2.5 demonstra uma visão em espiral do processo de engenharia de requisitos:

43 42 Figura 2.5 Uma visão em espiral do processo de engenharia de requisitos Fonte: SOMMERVILLE, 2011, p Projeto e implementação Sommerville (2011) define o projeto e a implementação de software como uma etapa do processo onde um sistema de software executável é desenvolvido. Para pequenos sistemas esta etapa é a engenharia de software; para grandes sistemas, o projeto e a implementação do software é apenas uma parte de um conjunto de processos envolvidos na engenharia de software. Sommerville (2011, p. 124) descreve que [...] o projeto de software é uma atividade criativa em que você identifica os componentes de software e seus relacionamentos com base nos requisitos do cliente. Pfleefer (2007) define que para que a implementação do software flua de maneira organizada e que todos os envolvidos nessa etapa entendam o que está sendo desenvolvido, é necessário que todos conheçam os procedimentos e padrões da organização antes de começarem a escrever o código, pois cada empresa possui um padrão diferente em relação ao estilo de codificação, ao formato e à

44 nomenclatura de dados e aos padrões de conteúdo que permitem a interpretação e o completo entendimento por qualquer membro da equipe de desenvolvimento. 43 Sommerville (2011) define que, por ser uma atividade criativa, o projeto não é um processo sequencial, pois necessita de ideias, propondo soluções e refinando-as conforme as informações ficam disponíveis, podendo ser necessário voltar atrás no desenvolvimento e adaptá-las para a nova necessidade. Baseando-se em sistemas orientados a objetos, que são compostos de objetos interativos que mantém seu próprio estado local e oferecem operações neste estado, facilitando uma possível mudança no sistema por se tratarem de objetos ou entidades autônomas, Sommerville (2011) indica a utilização da UML como metodologia para desenvolvimento de software, por se tratar de uma metodologia voltada à representação gráfica de todo o processo de desenvolvimento, permitindo que profissionais de software se comuniquem entre si de forma mais rápida e precisa do que por formas verbais. Este conceito também é defendido por Schach (2009, grifo nosso) que afirma que uma imagem vale mais que mil palavras. Sommerville (2011) apresenta cinco ações a serem tomadas para o desenvolvimento de um projeto de sistema, desde a sua contextualização até o projeto detalhado orientado a objetos. São eles: 1) Compreender e definir o contexto e as interações externas com o sistema: compreender os relacionamentos entre o software que está sendo projetado e seu ambiente externo bem como estabelecer os limites do sistema. Pode ser feito utilizando-se um caso de uso como demonstra os exemplos das figuras 2.6 e 2.7. Para cada uma das ações definidas no caso de uso, o autor usa uma descrição de caso de uso para definir claramente as informações que são trocadas:

45 44 Figura 2.6 Sistema de contexto para estação meteorológica Fonte: SOMMERVILLE, 2011, p.126 Figura 2.7 Caso de uso estação meteorológica Fonte: SOMMERVILLE, 2011, p.127 2) Projetar a arquitetura do sistema: após definidas as interações do sistema de software com o ambiente do sistema, utiliza-se estas informações para projetar a arquitetura do sistema. Devem-se identificar os principais componentes do

46 45 sistema e suas interações e organizá-los utilizando um padrão de arquitetura, como um modelo em camadas; 3) Identificar os principais objetos do sistema: define que, utilizando-se das descrições dos casos de uso, é possível identificar objetos e operações do sistema. A partir destas informações, é possível identificar as classes de objetos do sistema. Podem ser coletadas informações também à partir de documentos de requisitos, conversas com usuários, ou à partir de sistemas pré-existentes. A figura 2.8 exemplifica os objetos e suas classes: Figura 2.8 Objetos da estação meteorológica Fonte: SOMMERVILLE, 2011, p.129 4) Desenvolver modelos de projeto: consiste em mostrar os objetos ou classes de objetos em um sistema, bem como suas associações e relacionamentos. Esses modelos são a ponte entre os requisitos do sistema e a sua implementação. Precisam ser abstratos para que detalhes desnecessários não escondam os relacionamentos entre eles e os requisitos do sistema, porém devem incluir detalhes suficientes para os programadores possam tomar decisões de implementação. Sommerville (2011) ainda define alguns tipos de modelos de projeto, tais como os estruturais, os dinâmicos, os de subsistema, os de sequência e os de máquina de estado. A figura 2.9 demonstra um exemplo de diagrama de estado:

47 46 Figura 2.9 Diagrama de estado da estação meteorológica Fonte: SOMMERVILLE, 2011, p.132 5) Especificar interfaces: parte importante para qualquer processo de projeto, pois especifica as interfaces entre os componentes do projeto. Especificamse as interfaces de forma que os objetos e os subsistemas possam ser projetados em paralelo. Logo após uma interface ter sido especificada, os desenvolvedores dos outros objetos podem supor que ela será implementada. Podem ser especificadas usando-se a mesma notação de um diagrama de classe, porém não existirá a seção de atributos e o estereótipo <<interface>> deve ser incluído na parte do nome. A figura 2.10 exemplifica a especificação de duas interfaces: Figura 2.10 Interfaces da estação meteorológica Fonte: SOMMERVILLE, 2011, p.133 Schach (2009, p. 481) conclui a ideia de Sommerville (2011) afirmando que o objetivo do fluxo de trabalho de implementação é o de implementar o produto de software desejado na linguagem de programação escolhida [...].

48 Testes de software Martins (2010) afirma que as correções de problemas de software podem ser até mil vezes mais caras para realizar após a implantação do sistema do que durante seu processo de desenvolvimento, sendo de suma importância garantir a qualidade durante todo o ciclo de vida do projeto. Schach (2009) cita que uma série de tipos diferentes de testes tem de ser realizados durante o processo de implementação de um sistema de software, que incluem testes individuais em cada módulo desenvolvido, de integração destes módulos, do produto final e o de aceitação por parte dos usuários do sistema. software: Sommerville (2011) destaca dois objetivos distintos do processo de teste de 1) Demonstrar ao desenvolvedor e ao cliente que o software atende aos requisitos; 2) Descobrir situações em que o software se comporta de maneira incorreta, indesejável ou diversa da especificada, como, por exemplo, processamentos incorretos e corrupção de dados. Duas definições importantes devem ser consideradas (SOMMERVILLE, 2011 apud BOEHM, 1979, p. 145, grifo nosso): 1) Validação: estar construindo o produto certo; 2) Verificação: estar construindo o produto da maneira correta. Martins (2010) define diversos tipos de testes com finalidades distintas que avaliam a qualidade do sistema, divididos em três diferentes dimensões: 1) Qualidade: é testada a confiabilidade (resistência às falhas de execução), funcionalidade (onde se devem executar todos os casos de uso apresentando o comportamento esperado) e seu desempenho (executar e responder no tempo esperado em ambiente de uso real);

49 48 2) Estágios de teste: é executado teste de unidade (teste em cada um dos módulos, conforme estes são desenvolvidos), teste de integração (se todos os módulos desenvolvidos foram integrados de forma completa e corretos), teste de sistema (o sistema como um todo) e o teste de aceitação (onde o sistema completo é testado pelo usuário final para fins de aceitação ou homologação). 3) Tipos de teste: onde diversos tipos de testes são executados, cada um com um objetivo singular para avaliar uma característica especifica do sistema: a. Teste de benchmark: desempenho do elemento com os requisitos deste especificados; b. Teste de configuração: aceitação do elemento testado quanto a configuração de hardware e software; c. Teste de funcionamento: funcionamento correto do elemento testado como documentado nos casos de uso; d. Teste de instalação: se o elemento testado pode ser instalado em diferentes plataformas e ambientes sem apresentar problemas; e. Teste de integridade: verificar a confiabilidade, robustez e resistência a falhas do elemento testado; f. Teste de carga: verificar se o elemento mantem o funcionamento desejado mesmo quando varia a quantidade de transações, usuários e outros elementos. Martins (2010) ainda conclui que todos os testes devem ser projetados por um profissional qualificado, que será responsável por planejar, projetar e avaliar os testes, bem como os procedimentos de como estes testes devem ser executados pelo testador, que por sua vez irá executar os testes e avaliar os resultados, recuperar os erros e registrar o histórico de solicitações de correção decorrentes das falhas encontradas. 2.6 Implantação Martins (2010) define que o objetivo do processo de implantação é disponibilizar o sistema para os usuários finais. Este processo inclui o teste do sistema no ambiente de produção, empacotamento do software para sua distribuição, a sua distribuição e instalação, o treinamento dos usuários e da equipe

50 comercial e a migração de dados do sistema antigo para o novo sistema, caso o usuário final o possua. 49 Este autor afirma, ainda, que o pico das atividades de implantação ocorre na fase de transição, onde o principal objetivo é a implantação do sistema e, para facilitar o trabalho da equipe de implantação, o usuário deve ser envolvido no processo desde o início, quando o sistema ainda está em sua versão beta. São definidos também pelo autor os profissionais que devem trabalhar nesta etapa de implantação: Gerente de Implantação; Gerente de Projeto; Escritor Técnico; Testador; Desenvolvedor. Martins (2010) enumera e define as seis atividades executadas no processo de implantação: 1) Planejar a implantação: definir a lista dos elementos a serem entregues e garantir que o cliente esteja comprometido e ciente com as atividades de implantação; 2) Desenvolver material de suporte: material de treinamento, suporte, ferramentas de instalação, manuais de uso e operação do sistema, entre outros; 3) Criar versão: empacotar o sistema e verificar se todos os artefatos necessários estão contidos nele; 4) Versão beta: distribuir uma versão beta 6 para os usuários para que possam avaliar seu funcionamento junto ao sistema e a execução da instalação; 5) Testar o sistema no ambiente do cliente: instalar o sistema no ambiente de produção para que o usuário faça os testes necessários, para sua aceitação; 6) Prover acesso ao site para download: caso o software seja disponibilizado em algum tipo de portal para o usuário ou website. 6 BETA: versão de avaliação de programas

51 Manutenção Pós-entrega Pfleeger (2004) define a manutenção pós-entrega como sendo qualquer trabalho efetuado para modificar o sistema, logo após ele entrar em operação. O autor adiciona ainda que o software, diferente do hardware, não sofre degradação com o tempo nem requer manutenção periódica, mas sim, adaptações para mudanças de um sistema operacional ou tempo de execução relacionados a novos parâmetros de processadores e acesso a discos, bem como adaptações a novas necessidades especificas dos usuários. Sommerville (2011) define três diferentes tipos de manutenção de software: 1) Correção de defeitos: correção em falhas na codificação que podem estar relacionados ou não a erros do projeto; 2) Adaptação ambiental: quando existem alterações de hardware, sistema operacional ou algum software de apoio, e o sistema deve ser adaptado; 3) Adição de funcionalidade: quando existem mudanças nos requisitos de sistema pelo usuário ou novas regras de negócio organizacionais. Quanto à adição de funcionalidade, o autor destaca que adicionar funcionalidades depois que um sistema está em operação é muito mais caro e complicado do que durante o seu desenvolvimento devido a várias razões como estabilidade da equipe, que pode ter sido alterada desde o período de desenvolvimento até o momento da manutenção; más práticas de desenvolvimento, onde por motivos como o não fechamento de um contrato de manutenção com a mesma empresa que desenvolveu o sistema, não estimula a equipe de desenvolvimento a fazer um código manipulável e de fácil entendimento; falta de qualificação de pessoal, onde a equipe, além de inexperiente, pode não estar familiarizada com o domínio do sistema; e também a idade do programa e estrutura, onde, com o tempo, devido a várias alterações já feitas no programa ou utilização de técnicas já obsoletas, cria-se uma dificuldade no entendimento do código.

52 UML Unified Modeling Language Guedes (2009) define UML (Unified Modeling Language ou Linguagem de Modelagem Unificada) como uma linguagem visual utilizada na modelação de software que se baseia no paradigma de orientação a objetos. Martins (2010) complementa afirmando que sua utilização serve para visualizar, especificar, construir e documentar os elementos de um sistema baseado em software. Tanto Guedes (2009) quanto Martins (2010) afirmam que a UML não é uma linguagem de programação, mas sim, uma linguagem de modelagem cujo objetivo é auxiliar a engenharia de software a definir as características do sistema de software a ser desenvolvido, facilitando a visualização de suas características pelo programador. Grandes projetos não podem ser modelados de cabeça, nem mesmo a maioria dos pequenos projetos pode sê-lo, exceto, talvez, aqueles extremamente simples (GUEDES, 2009, p. 20). O autor esclarece ainda que devido ao fato de o software ser dinâmico e costumar ter a propriedade de ser ampliado com o passar do tempo, sua complexidade aumenta e, para que se mantenha sua facilidade e rapidez de manutenção e correção, é importante que o sistema de informação tenha uma documentação extremamente detalhada, evitando produzir novos erros no momento da correção dos antigos. Guedes (2009) cita que a UML na fase do projeto ajuda a trabalhar com o domínio da solução, estabelecendo como o sistema realizará o que foi determinado na fase de análise, criando a solução para o problema identificado, estabelecendo diretrizes de como as funcionalidades irão realizar o que foi solicitado. Neste momento é que deve ser selecionada a linguagem de programação a ser utilizada, o sistema de gerenciamento de banco de dados a ser implementado, suas interfaces e a distribuição física na empresa, definindo que tipo de hardware necessário para a correta implantação e funcionamento. blocos: Martins (2010) especifica a estrutura básica da UML considerando três

53 52 1) Elementos básicos: são elementos pertinentes a estrutura, comportamento, agrupamento e anotações. A estrutura representa as partes do sistema, que podem ser conceituais ou físicas (classes, interfaces, casos de uso, componentes e nós). O comportamento está relacionado às partes dinâmicas da UML, representando o comportamento no tempo e espaço. O agrupamento permite juntar todas as informações citadas acima em um só contexto. E as anotações são as contextualizações que descrevem, clareiam e elucidam os conceitos em um modelo; 2) Relacionamentos: são as associações dos elementos básicos, podendo ser de quatro tipos diferentes: dependência, onde acontece o relacionamento semântico entre dois elementos, sendo que a alteração de um, afeta diretamente o outro; a associação, onde o relacionamento estrutural entre dois elementos representa a ligação cardinal entre as partes (por exemplo, um relacionamento 1 n ); a generalização, onde o relacionamento permite demonstrar a abstração de classes ou herança; a agregação, onde acontece uma associação, porém com maior dependência entre os elementos, pois um não existe sem o outro; 3) Diagramas: são os agrupamentos dos elementos básicos e dos relacionamentos, onde é possível construir diversas visões do sistema. Existem vários tipos de diagramas, dentre os quais os de classes, de objetos, de casos de uso, de interação, de sequência, de estado, de atividades, de componentes e de Deployment.

54 53 3 O PROJETO DE SOFTWARE Esse capítulo introduz a empresa Faro Technologies do Brasil Ltda. Em seguida é apresentado o resultado do processo de desenvolvimento do software, sendo o RUP a metodologia de Gerenciamento de Projeto adotada. Ressalta-se que a fase de Transição ainda não aconteceu na empresa, logo não foi documentada. 3.1 A Empresa A empresa FARO Technologies, Inc. com sede na cidade de Lake Mary, no estado da Flórida EUA atua no mercado de equipamentos de alta tecnologia direcionados às áreas de controle dimensional (metrologia e controle de qualidade) e desenvolvimento de dispositivos de aquisição de imagens em três dimensões. Possui fábricas nos EUA, Alemanha e em Singapura, além de estruturas de serviços em vários outros países da Europa e, desde o início de 2011, no Brasil. No Brasil, a FARO Technologies executa serviços de manutenção e calibração dos equipamentos da sua marca para os clientes nacionais além do suporte a seus clientes por telefone e visitas in loco. Ainda não possuem fabricação dos equipamentos em nosso país. Por se tratar de uma empresa completamente focada em manutenção dos equipamentos, a assistência técnica utiliza-se de peças de reposição para uso diário e, atualmente, possui um controle desse estoque de peças manual e impreciso. Após a análise deste processo, foi verificada a necessidade do controle acurado e informatizado destas para que não falte nenhum item para manutenção, o que gera atraso na devolução dos equipamentos aos seus clientes e automaticamente, a insatisfação por parte deles, pois os mesmos necessitam desses equipamentos para liberação de produção nas suas empresas. Todas as peças utilizadas nas manutenções dos seus equipamentos aqui no Brasil precisam ser importadas na sua totalidade da sede dos EUA.

55 Fase de Concepção e Elaboração As fases de concepção e elaboração aconteceram em períodos distintos, porém sintetizadas conforme descrito a seguir Modelagem de negócio a) Visão do negócio: Durante o a análise do processo de estoque da empresa FARO Technologies do Brasil Ltda., foi verificado a inexistência de um sistema de TI que fizesse o controle e administração do inventário de peças, processo que era executado visualmente e com auxilio de planilhas eletrônicas, tornando assim, um controle ineficiente e impreciso. Neste momento, foi proposta a criação de um sistema dedicado e customizado para esta atividade, que tornou-se o escopo deste trabalho de pesquisa e desenvolvimento. b) Caso de Uso de Negócio: O diagrama de caso de uso a seguir demonstra o processo ideal para o gerenciamento do estoque da empresa: Manter Cadastro de Usuários Manter Estoque Manter Cadastro de ítens Manter Registro de Entrada de Peças Manter Registro de Saída de Peças Gerente Gerar Relatórios Manter Cadastro de Fornecedor Técnico Manter Cadastro de Clientes Manter Cadastro de Tipo de Utilização Figura 3.1 Diagrama de Casos de Uso Fonte: autoria própria

56 c) Descrição funcional de casos de uso: Os quadros 3.1 até o 3.9 demonstram as descrições funcionais dos casos de uso apontados no item b : 55 Nome do Caso de Uso Caso de Uso Geral Ator Principal Atores Secundários Resumo Pré-Condições Pós-Condições Ações do Autor Gerente Manter Cadastro de Usuário Descreve as etapas necessárias para cadastro de novos usuários no sistema O gerente deverá ter privilégios de administrador Ações do Sistema 1. Selecionar a opção para cadastro de usuário 2. Carregar a tela de cadastro de usuário 3. Entrar com as informações do usuário 4. Validar os dados entrados 5. Gravar os dados no sistema Quadro 3.1 Descrição de Caso de Uso Manter Cadastro de Usuário Fonte: Autoria própria Nome do Caso de Uso Manter Estoque Caso de Uso Geral Ator Principal Atores Secundários Resumo Pré-Condições Pós-Condições Ações do Autor Gerente Descreve as etapas necessárias para gestão dos itens em estoque Itens devem estar cadastrados anteriormente no sistema Ações do Sistema 1. Acessa a tela de manutenção de itens e seleciona item desejado 2. Carregar na tela as informações sobre o item selecionado 3. Se necessário, alterar, inserir ou excluir as informações sobre o item. 4. Se necessário, salvar as alterações. Quadro 3.2 Descrição de Caso de Uso Manter Estoque Fonte: Autoria própria

57 56 Nome do Caso de Uso Manter Cadastro de Itens Caso de Uso Geral Ator Principal Atores Secundários Resumo Pré-Condições Gerente Descreve as etapas necessárias manter o cadastro dos itens do estoque Pós-Condições Ações do Autor Ações do Sistema 1. Informar o código do item 2. Consultar o código do item 3. Se já houver este item cadastrado com este código informado, apresentar seus dados 4. Se necessário, alterar, inserir ou excluir os dados do item. 5. Se necessário, salvar as alterações Quadro 3.3 Descrição de Caso de Uso Manter Cadastro de Itens Fonte: Autoria própria Nome do Caso de Uso Manter Registro de Entrada de Peças Caso de Uso Geral Ator Principal Atores Secundários Resumo Pré-Condições Pós-Condições Ações do Autor Gerente Descreve as etapas necessárias para registrar a entrada de itens comprados no sistema Itens devem estar cadastrados anteriormente no sistema Ações do Sistema 1. Selecionar a opção de registro de entrada de itens 2. Carregar a tela com os campos a serem preenchidos 3. Inserir todos dados relativos à entrada do item 4. Validar os dados informados 5. Se necessário, alterar, inserir ou excluir os dados da entrada do item 6. Se necessário, salvar as alterações Quadro 3.4 Descrição de Caso de Uso Manter Registro de Entrada de Peças Fonte: Autoria própria

58 57 Nome do Caso de Uso Manter Registro de Saída de Peças Caso de Uso Geral Ator Principal Atores Secundários Resumo Pré-Condições Pós-Condições Ações do Autor Gerente Técnico Descreve as etapas necessárias para registrar a saída de itens utilizados O cliente e o item devem estar cadastrados anteriormente no sistema Ações do Sistema 1. Selecionar a opção de registro de saída de item 2. Carregar a tela com os campos a serem preenchidos 3. Inserir todos dados relativos à saída do item 4. Validar os dados informados 5. Se necessário, alterar, inserir ou excluir os dados da saída do item 6. Se necessário, salvar as alterações Quadro 3.5 Descrição de Caso de Uso Manter Registro de Saída de Peças Fonte: Autoria própria Nome do Caso de Uso Gerar Relatórios Caso de Uso Geral Ator Principal Atores Secundários Resumo Pré-Condições Gerente Descreve as etapas necessárias para gerar relatórios do estoque Pós-Condições Ações do Autor Ações do Sistema 1. Selecionar a opção de relatório a ser emitido 2. Carregar os dados referentes ao relatório selecionado 3. Mostrar o relatório Quadro 3.6 Descrição de Caso de Uso Gerar Relatórios Fonte: Autoria própria

59 58 Nome do Caso de Uso Manter Cadastro de Fornecedores Caso de Uso Geral Ator Principal Atores Secundários Resumo Pré-Condições Gerente Descreve as etapas necessárias para manter o cadastro dos fornecedores Pós-Condições Ações do Autor Ações do Sistema 1. Informar o CNPJ do fornecedor 2. Consultar o CNPJ do fornecedor e verificar se já possui cadastro 3. Se já houver este CNPJ cadastrado apresentar seus dados 4. Se necessário, alterar, inserir ou excluir os dados do fornecedor 5. Se necessário, salvar as alterações Quadro 3.7 Descrição de Caso de Uso Manter Cadastro de Fornecedores Fonte: Autoria própria Nome do Caso de Uso Manter Cadastro de Clientes Caso de Uso Geral Ator Principal Atores Secundários Resumo Pré-Condições Gerente Técnico Descreve as etapas necessárias para manter o cadastro dos clientes Pós-Condições Ações do Autor Ações do Sistema 1. Informar o CNPJ do fornecedor 2. Consultar o CNPJ do fornecedor e verificar se já possui cadastro 3. Se já houver este CNPJ cadastrado apresentar seus dados 4. Se necessário, alterar, inserir ou excluir os dados do cliente 5. Se necessário, salvar as alterações Quadro 3.8 Descrição de Caso de Uso Manter Cadastro de Clientes Fonte: Autoria própria

60 59 Nome do Caso de Uso Manter Cadastro de Tipo de Utilização Caso de Uso Geral Ator Principal Atores Secundários Resumo Pré-Condições Gerente Técnico Descreve as etapas necessárias para manter o cadastro dos tipos de utilização Pós-Condições Ações do Autor Ações do Sistema 1. Informar os dados do tipo de utilização 2. Se já houver este CNPJ cadastrado apresentar seus dados 3. Se necessário, alterar, inserir ou excluir os dados do cliente 4. Se necessário, salvar as alterações Quadro 3.9 Descrição de Caso de Uso Manter Cadastro de Tipo de Utilização Fonte: Autoria própria Elicitação de Requisitos Os quadros 3.10 a 3.12 apresentam a descrição dos requisitos funcionais, dos requisitos não funcionais e das regras de negócios elicitadas durante a documentação do projeto.

61 60 Requisito Funcional Descrição Prioridade RF001 Manter Cadastro de Usuário Obrigatório RF Contém as seguintes informações: nome de usuário, senha para o usuário, telefone de contato, nome completo, , status da conta (ativo ou inativo) e grupo a que o usuário pertence (administrador ou usuário). Obrigatório RF002 Manter Cadastro de Itens de Estoque Obrigatório RF Contém as seguintes informações: nome do fornecedor do item, número de controle interno, descrição original (caso seja importado), descrição traduzida para o português, código de normalização para importação (NCM) e o status do item (ativo ou inativo). Obrigatório RF003 Manter registro de entrada de peças Obrigatório RF Contém as seguintes informações: nome da peça, data de entrada no estoque, quantidade recebida, número da nota fiscal ou invoice de entrada, valor unitário e o status desta entrada (ativo ou inativo). Obrigatório RF004 Manter registro de saída de peças Obrigatório RF Contém as seguintes informações: descrição da peça, código do serviço (RMA), cliente onde foi utilizada a peça, data da venda, quantidade vendida, tipo de utilização (garantia, não garantia, cortesia), valor unitário vendido e status da saída (ativo ou inativo). Obrigatório RF005 Manter Estoque Obrigatório RF Contém as seguintes informações: descrição da peça, quantidade atual em estoque, quantidade mínima, tempo de ressuprimento (em dias), status da peça (ativo ou inativo). Obrigatório RF006 Manter Cadastro de Fornecedores Obrigatório RF Contém as seguintes informações: CPF ou CNPJ do fornecedor, nome da empresa, nome fantasia, endereço completo, CEP, bairro, cidade, estado, país, website (opcional), de contato, nome do contato, telefone, fax (opcional) e status do fornecedor (ativo ou inativo). Obrigatório RF007 Manter Cadastro de Clientes Obrigatório RF Contém as seguintes informações: CNPJ do cliente, nome da empresa, endereço completo, CEP, bairro, cidade, estado, de contato, nome do contato, telefone, fax (opcional) e status do cliente (ativo ou inativo). Obrigatório RF008 Manter Cadastro de Tipo de Utilização Obrigatório RF Contém as seguintes informações: código do tipo de utilização, descrição do tipo de utilização da peça e status do tipo de utilização (ativo ou inativo). Obrigatório RF009 Gerar relatórios Obrigatório RF O sistema gera os seguintes relatórios: a) relatório dos itens com quantidade menor ou igual ao mínimo cadastrado; b) relatório com posição consolidada do estoque até a data atual apenas das peças que possuam quantidade igual ou superior a uma unidade; c) relatório mensal das peças utilizadas no mês (sempre contando a partir do primeiro dia do mês corrente até a data da emissão do relatório). Quadro 3.10 Elicitação de Requisitos Funcionais Fonte: Autoria própria Obrigatório

62 61 Requisito Não Funcional Descrição Prioridade RNF001 O sistema utiliza o banco de dados Microsoft SQL Server 2008 juntamente com a Microsoft Management Studio Express. Obrigatório RNF002 RNF003 O sistema executa perfeitamente sobre os sistemas operacionais da Microsoft de núcleo NT, a saber: Windows XP Professional SP3 Windows Server 2008 Windows 7 Professional SP1 O sistema foi desenvolvido na linguagem de programação C#. Utiliza-se utilizar bibliotecas de terceiros. Obrigatório Obrigatório RNF004 O sistema utiliza a autenticação de usuários baseado em login e senha. Obrigatório RNF005 RNF006 RNF007 RNF009 Cada usuário tem uma regra de utilização do sistema que pode ser definida no momento do cadastro do usuário. O sistema grava em um arquivo de logs as ações efetuadas pelos usuários, ordenadas por data e hora. O sistema contém funções que validam os dados de entrada dos formulários, bem como verificam sua consistência no momento de gravação no banco de dados. Todo o sistema foi desenvolvido utilizando a língua inglesa como base, inclusive os relatórios emitidos. Quadro 3.11 Elicitação de Requisitos Não-Funcionais Fonte: Autoria própria Obrigatório Obrigatório Obrigatório Regra de Negócio RNG001 RNG002 Descrição Cada usuário tem uma regra de utilização do sistema que pode ser definida no momento do cadastro do usuário. O administrador tem acesso irrestrito a todas as funcionalidades do sistema. O usuário tem acesso apenas aos requisitos RF004 e RF007. Os usuários simples (técnicos) apenas podem manter o cadastro de clientes e registrar a saída de peças do estoque. Prioridade Obrigatório Obrigatório RNG003 Apenas os usuários administradores podem gerar relatórios do sistema. Obrigatório RNG004 RNG005 As opções de modificar, excluir ou inserir apenas estão disponíveis aos usuários simples (técnicos) nas opções citadas na regra de negócio RNG002. Para as outras opções, apenas a visualização. O sistema verifica a quantidade atual dos itens no estoque e compara com a quantidade mínima para geração dos relatórios. Quadro 3.12 Elicitação de Regras de Negócio Fonte: Autoria própria Obrigatório Obrigatório

63 Análise A seguir é apresentada a arquitetura de classes do projeto bem como o modelo relacional do banco de dados. No item possui uma breve explicação sobre cada um desses diagramas. a) Diagramas de classes da camada de modelos: Figura Diagrama de classes da camada de modelos Fonte: autoria própria

64 63 b) Diagrama de classes da camada de negócios: Figura Diagrama de classes da camada de negócios Fonte: autoria própria

65 64 c) Diagrama de classes da camada de acesso a dados: Figura Diagrama de classes da camada de acesso a dados Fonte: autoria própria

66 65 d) Diagrama de classes utilitárias: Figura Diagrama de classes utilitárias Fonte: autoria própria

67 66 e) MER - Modelo de Entidade-Relacionamento do banco de dados criado: Figura 3.6 MER - Modelo Entidade-Relacionamento Fonte: autoria própria Implementação Para este projeto, não existiu um protótipo de prova do software nem uma metodologia formal de desenvolvimento Gerenciamento de configuração e ambiente a) Por se tratar de um sistema de baixa complexidade e apenas os três autores deste projeto estão envolvidos no processo de desenvolvimento do sistema, não houve necessidade da criação de um plano de gerenciamento de configuração, sendo apenas detalhadas no quadro 3.13 os recursos e as ferramentas necessárias

68 67 para o desenvolvimento e a configuração das máquinas dos ambientes de desenvolvimento e teste. Toda alteração ou revisão necessária foi discutida com todos os membros da equipe antes de sua implantação; b) O quadro 3.13 mostra uma lista das ferramentas e recursos utilizados no processo de desenvolvimento do projeto: Ferramenta IIS (Internet Information Service) Microsoft SQL Server 2008 Microsoft Visual Studio 2008 Microsoft C# Microsoft Windows 7 Professional Microsoft.NET Framework 3.5 Skype Descrição Servidor de informações de Internet utilizado para disponibilizar o funcionamento da aplicação web Sistema de Gerenciamento de Banco de Dados utilizado Ferramenta utilizada para desenvolvimento do código de programação do software Linguagem de programação utilizada Sistema operacional utilizado durante processo de desenvolvimento Biblioteca de classes Ferramenta de comunicação da equipe Quadro 3.13 Lista das ferramentas e recursos utilizados no processo de desenvolvimento do projeto Fonte: Autoria própria c) O quadro 3.14 contém a configuração do hardware dos computadores dos ambientes de desenvolvimento e de testes: Ambiente Desenvolvimento Teste Configuração de Hardware Processador: Intel Core 2 Quad 6600 Memória RAM: 4GB Hard Disk: 500 GB IP: Dinâmico Processador: Intel Core i5 Memória RAM: 4GB Hard Disk: 500 GB IP: Dinâmico Quadro 3.14 Configuração de Hardware Fonte: Autoria própria

69 Construção Modelagem de Negócio / Requisitos / Análise As três primeiras etapas da fase da construção do software permaneceram-se inalteradas, mantendo as mesmas informações contidas no item Implementação O desenvolvimento do software seguiu o conceito de três camadas, denominado MVC (Model-View-Controler), no qual cada camada contém classes que apresentam um conjunto de características em comum e funcionalidades interrelacionadas. A camada de modelos (model) engloba as classes do modelo de negócios em seu estado puro, sendo que seus objetos apresentam atributos públicos para que as outras camadas do sistema possam acessar as informações de seu estado interno, bem como promover a alteração desse estado. Modelos geralmente mapeiam as colunas das tabelas do banco de dados para seus atributos em uma relação 1..1, ou seja, para cada atributo público de um objeto desse tipo, há uma coluna na tabela correspondente. Quando um atributo do objeto refere-se a uma lista de itens, diz-se que, para cada atributo do modelo, há uma tabela correspondente no banco de dados. O diagrama de classes dessa camada pode ser visto na figura 3.2 apresentada no item A camada de lógica e de negócios (controler) engloba as classes que contém as regras de negócios levantadas durante a fase de elicitação de requisitos. Estas classes, por sua vez, também possuem métodos que permitem a validação dos objetos criados, bem como a invocação dos métodos correspondentes da camada de acesso a dados. Seu diagrama pode ser visto na figura 3.3 apresentada no item

70 69 A camada de apresentação (view) engloba todos os recursos de apresentação, como formulários Web, páginas estáticas, scripts, imagens e folhas de estilo. É com essa camada que o usuário interage e pela qual geralmente é medida a qualidade de um sistema de informação. Para esta camada foi criada, ainda, uma biblioteca de classes utilitárias, cujo diagrama pode ser visto na figura 3.5 apresentada no item 3.2.3, e que tem por finalidade concentrar as funcionalidades (propriedades e métodos) que se repetem por toda a aplicação, incluindo, mas não se limitando, a funções de encriptação e desencriptação de textos e senhas de usuários, formatação de mensagem de erro, extensão de componentes de formulários, tratamento de tipos enumerados, tradução e conversão de tipos de dados, dentre outras. O sistema utiliza-se ainda de mais um padrão de projeto denominado DAL (Data Access Layer ou Camada de Acesso de Dados), englobando todas as classes que fazem acesso diretamente às entidades correspondentes no sistema de gerenciamento de banco de dados, permitindo a inclusão, a consulta, a alteração e a exclusão dos dados. O diagrama de classes dessa camada pode ser visto na figura 3.4 apresentada no item Além das camadas e dos padrões de projetos descritos, o sistema utilizou-se da biblioteca jquery, escrita em linguagem Javascript, que fornece suporte para elementos visuais de interface com o usuário, tais como calendário (que pode ser visto nas telas de registro de entrada e saída de peças); os gráficos utilizados nos relatórios e no dashboard da tela inicial; e nas máscaras de entrada de dados em todos os formulários em que se fizeram necessárias Testes Após o desenvolvimento do sistema, o mesmo foi implantado em uma máquina de testes diversa daquela do ambiente de desenvolvimento, visando uma análise do seu comportamento em diferentes configurações de hardware e software. Realizada a execução do script em SQL para a criação do banco de dados do sistema e das tabelas necessárias, assim como seu relacionamento (chaves

71 70 primárias e estrangeiras), copiou-se a versão publicada do sistema - com suas bibliotecas já compiladas - para o diretório raiz do Internet Information Services, normalmente sob o caminho C:\inetpub\wwwroot. O sistema apresentou funcionamento correto e dentro do esperado, sem nenhuma falha de integração entre as diferentes camadas. A conexão com o banco de dados ocorreu sem nenhuma falha, e o único parâmetro que precisou ser alterado em seu arquivo de configuração foi a senha do usuário 'sa' (ou system administrator) padrão do SQL Server Após esta configuração inicial, apenas se fez necessário que o usuário abrisse seu navegador de Internet favorito e informasse a URL ' para acesso ao sistema. As figuras 3.7 até 3.19 demonstram as telas do sistema após a implantação: a) A tela inicial conforme figura 3.7 possui a função de login no sistema: Figura Tela inicial de login do sistema Fonte: autoria própria

72 71 b) A figura 3.8 demonstra a tela para alteração de senha do usuário: Figura Tela inicial de alteração de senha Fonte: autoria própria

73 c) Caso o usuário esqueça a senha, é solicitado o de cadastro do usuário para recuperação de senha conforme figura 3.9: 72 Figura Tela inicial de redefinição de senha Fonte: autoria própria

74 d) A figura 3.10 mostra a tela Home do sistema com informações de alguns dashboards e as opções do menu: 73 Figura Tela inicial com informações no dashboard e as opções do menu Fonte: autoria própria

75 74 e) A figura 3.11 demonstra a tela Manter cadastro de Cliente com os campos para preenchimento e logo abaixo uma lista com todos os clientes já existentes no banco de dados: Figura Tela de manutenção de Clientes Fonte: autoria própria

76 75 f) A figura 3.12 demonstra a tela Manter cadastro de fornecedores com os campos para preenchimento e logo abaixo uma lista com todos os fornecedores já existentes no banco de dados: Figura Tela de manutenção de Fornecedores Fonte: autoria própria

77 76 g) A figura 3.13 demonstra a tela Manter inventário com os campos para preenchimento e logo abaixo uma lista com todos os dados dos itens já existentes no banco de dados: Figura Tela de manutenção de Inventário Fonte: autoria própria

78 77 h) A figura 3.14 demonstra a tela Manter Tipo de Uso com os campos para preenchimento e logo abaixo uma lista com todos os tipos de uso já existentes no banco de dados: Figura Tela de manutenção de Tipo de Uso Fonte: autoria própria

79 78 i) A figura 3.15 demonstra a tela Manter Usuário onde o administrador pode cadastrar os usuários do sistema e logo abaixo uma lista com os usuários já existentes no banco de dados: Figura Tela de manutenção de Usuário Fonte: autoria própria

80 79 j) A figura 3.15 demonstra a tela Manter Cadastro de Peças onde o administrador pode cadastrar os tens do estoque e, logo abaixo, uma lista com os itens já existentes no banco de dados: Figura Tela de manutenção de Peças Fonte: autoria própria

81 80 k) A figura 3.17 demonstra a tela Manter Registro de Entrada de Peças e seus campos para preenchimento e, logo abaixo, um histórico de todas as entradas de itens no estoque: Figura Tela de Registro de Entrada de Peças Fonte: autoria própria

82 81 l) A figura 3.18 demonstra a tela Manter Registro de Saída de Peças e seus campos para preenchimento e, logo abaixo, um histórico de todas as saídas de itens do estoque: Figura Tela de Registro de Saída de Peças Fonte: autoria própria

83 m) A figura 3.19 demonstra a tela Contato onde possui informações sobre os desenvolvedores do sistema, neste caso os autores deste projeto: 82 Figura Tela de Contato com os autores Fonte: autoria própria

84 n) A figura 3.20 demonstra a tela Relatório Consolidado onde demonstra uma posição do estoque com todas as suas peças existentes: 83 Figura Tela de Relatório Consolidado Fonte: autoria própria

85 84 o) A figura 3.21 demonstra a tela Relatório Consolidado exportado para Excel onde demonstra uma posição do estoque com todas as suas peças existentes, porém exportado para uma planilha em Excel: Figura Tela de Relatório Consolidado exportado para Excel Fonte: autoria própria