sistema dedicado para controle e reposição de estoque

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
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
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
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
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.
“Cada um pensa em mudar a humanidade, mas ninguém
pensa em mudar a si mesmo”.
Leon Nikolaievitch Tolstoi (1828-1910)
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.
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.
LISTA DE FIGURAS
Figura 1.1 – Abrangência do MRP e do MRP II....................................................... 32
Figura 1.2 – Visão geral de um ERP........................................................................ 33
Figura 2.1 – Modelo em Cascata............................................................................. 36
Figura 2.2 – Modelo Incremental.............................................................................. 37
Figura 2.3 – Engenharia de software orientada a reuso.......................................... 37
Figura 2.4 – Tipos de Requisitos não funcionais.....................................................41
Figura 2.5 – Uma visão em espiral do processo de engenharia de requisitos........ 42
Figura 2.6 – Sistema de contexto para estação meteorológica............................... 44
Figura 2.7 – Caso de uso estação meteorológica.................................................... 44
Figura 2.8 – Objetos da estação meteorológica....................................................... 45
Figura 2.9 – Diagrama de estado da estação meteorológica................................... 46
Figura 2.10 – Interfaces da estação meteorológica................................................. 46
Figura 3.1 – Diagrama de Casos de Uso................................................................. 54
Figura 3.2 – Diagrama de classes da camada de modelos..................................... 62
Figura 3.3 – Diagrama de classes da camada de negócios.................................... 63
Figura 3.4 – Diagrama de classes da camada de acesso a dados.......................... 64
Figura 3.5 – Diagrama de classes utilitárias............................................................. 65
Figura 3.6 – Modelo Entidade-Relacionamento (MER)............................................ 66
Figura 3.7 – Tela inicial de login do sistema............................................................ 70
Figura 3.8 – Tela inicial de alteração de senha........................................................ 71
Figura 3.9 – Tela inicial de redefinição de senha..................................................... 72
Figura 3.10 – Tela inicial com informações no dashboard e as opções do menu...73
Figura 3.11 – Tela de manutenção de Clientes.......................................................74
Figura 3.12 – Tela de manutenção de Fornecedores.............................................. 75
Figura 3.13 – Tela de manutenção de Inventário..................................................... 76
Figura 3.14 – Tela de manutenção de Tipo de Uso................................................. 77
Figura 3.15 – Tela de manutenção de Usuário......................................................... 78
Figura 3.16 – Tela de manutenção de Peças........................................................... 79
Figura 3.17 – Tela de Registro de Entrada de Peças............................................... 80
Figura 3.18 – Tela de Registro de Saída de Peças.................................................. 81
Figura 3.19 – Tela de Contato com os autores......................................................... 82
Figura 3.20 – Tela de Relatório Consolidado............................................................ 83
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
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”..................... 56
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”.... 57
Quadro 3.6 – Descrição de Caso de Uso “Gerar Relatórios”................................... 57
Quadro 3.7 – Descrição de Caso de Uso “Manter Cadastro de Fornecedores”...... 58
Quadro 3.8 – Descrição de Caso de Uso “Manter Cadastro de Clientes” ............... 58
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................................................. 60
Quadro 3.11 – Elicitação de Requisitos Não-Funcionais ........................................ .61
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...................................................................................... 67
Quadro 3.14 – Configuração de Hardware............................................................... 67
LISTA DE ABREVIATURAS E SIGLAS
DAL
Data Access Layer
DAO
Data Access Object
ERP
Enterprise Resource Planning
MER
Modelo Entidade-Relacional
MPS
Master Production Schedule
MRP II
Manufacturing Resource Planning
MRP
Material Requirement Planning
MVC
Model-View-Controller
RUP
Rational Unified Process
SBC
São Bernardo do Campo
SCM
Supply Chain Management
TI
Tecnologia da Informação
UML
Unified Modeling Language
SUMÁRIO
INTRODUÇÃO ......................................................................................................... 14
1
INTRODUÇÃO À GESTÃO DE ESTOQUES .............................................. 16
1.1
Gestão de Estoques .................................................................................. 16
1.1.1
Porque manter estoques ............................................................................. 17
1.2
Uma visão dos problemas com estoques ............................................... 19
1.2.1
Tipos de demanda....................................................................................... 20
1.3
Características básicas da gestão de estoques...................................... 21
1.3.1
Restrições e custos relevantes de estoques ............................................... 22
1.4
Vantagem competitiva ............................................................................. 24
1.4.1
A inovação como vantagem competitiva .................................................... 26
1.4.2
A importância da Tecnologia da Informação .............................................. 27
1.5
TI aplicada à Gestão de Estoques ........................................................... 29
1.5.1
MRP, MRP II e ERP ................................................................................... 29
2
INTRODUÇÃO À ENGENHARIA DE SOFTWARE .................................... 35
2.1
Processos de Desenvolvimento de Software ......................................... 35
2.2
RUP - Rational Unified Process .............................................................. 37
2.2.1
Fases do RUP ............................................................................................ 38
2.3
Engenharia de Requisitos ....................................................................... 39
2.4
Projeto e implementação ......................................................................... 42
2.5
Testes de software ................................................................................... 47
2.6
Implantação .............................................................................................. 48
2.7
Manutenção Pós-entrega ......................................................................... 50
2.8
UML – Unified Modeling Language ......................................................... 51
3
O PROJETO DE SOFTWARE ................................................................... 53
3.1
A Empresa ................................................................................................ 53
3.2
Fase de Concepção e Elaboração ........................................................... 54
3.2.1
Modelagem de negócio .............................................................................. 54
3.2.2
Elicitação de Requisitos ............................................................................. 59
3.2.3
Análise ....................................................................................................... 62
3.2.4
Implementação ........................................................................................... 66
3.2.5
Gerenciamento de configuração e ambiente .............................................. 66
3.3
Construção ............................................................................................... 68
3.3.1
Modelagem de Negócio / Requisitos / Análise ............................................ 68
3.3.2
Implementação ........................................................................................... 68
3.3.3
Testes ........................................................................................................ 69
CONCLUSÃO .......................................................................................................... 87
BIBLIOGRAFIA ....................................................................................................... 88
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.
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
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".
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.
1.1.1 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.
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,
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
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”.
1.2.1 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
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:
Vendas anuais ($)
Giro de estoque =
Vendas anuais (unid.)
ou
Estoque médio ($)
Giro de Estoque =
Estoque médio (unid.)
22
1.3.1 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:
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 1.1 - Detalhamento dos principais custos do gerenciamento de estoque
Fonte: FITZSIMMONS E FITZSIMMONS, 2005, p.345
24
1.4 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”.
De acordo com Porter (1996, apud Loddi, 2006, p. 40) a vantagem
competitiva:
[...] 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
25
nortear as organizações na obtenção de vantagem competitiva. Turban, Rainer e
Potter (2005) destacam doze dessas estratégias:
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;
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.
1.4.1 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.
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.
Brandão et al. (2006, p. 15) destaca a importância das inovações para as
empresas:
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.
1.4.2 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
DEFINIÇÃO
Hardware
Um conjunto de dispositivos (por exemplo, processador, monitor, teclado
e impressora) que, juntos, aceitam dados e informações, os processam e
os apresentam.
Software
Um conjunto dos programas que permitem que o hardware processe
dados.
Banco de
dados
Uma coleção de arquivos relacionados, tabelas, relações e assim por
diante, que armazenam dados e associações entre eles.
Rede
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
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).
29
1.5 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).
1.5.1 MRP, MRP II e ERP
Estas siglas começaram a ser usadas na década de 1960. 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.
Segundo Correa, Gianesi e Caon (2007, p. 78) o MRP baseia-se na ideia de
que:
[...] 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
30
Para a realização de seus cálculos, o MRP necessita de quatro tipos de entradas
(VOLLMANN, BERRY E WHYBARK apud SOUZA, 2001):
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.
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:
32
Figura 1.1 - 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
33
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:
Figura 1.2 - 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).
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.
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.
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:
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. 23
2.2 Rational Unified Process (RUP)
Martins (2010) define o RUP4 como uma metodologia para gerenciar projetos
de software utilizando-se do UML5 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.
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.
2.2.1 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;
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”.
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:
41
Requisitos
não
funcionais
Requisitos
de
usabilidade
Requisitos
de produtos
Requisitos
de
eficiencia
Requisitos
externos
Requisitos
de
confiança
Requisitos
reguladores
Requisitos
de proteção
Requisitos
éticos
Requisitos
organizacio
nais
Requisitos
legais
Requisitos
contábeis
Requisitos de
segurança/
proteção
Requisitos de
desempenho
Requisitos
de espaço
Requisitos
ambientais
Requisitos
operacionais
Requisitos de
desenvolvimento
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:
42
Figura 2.5 – Uma visão em espiral do processo de engenharia de requisitos
Fonte: SOMMERVILLE, 2011, p.70
2.4 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 à
43
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.
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:
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
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:
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 [...]”.
47
2.5 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.
Sommerville (2011) destaca dois objetivos distintos do processo de teste de
software:
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);
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
49
comercial e a migração de dados do sistema antigo para o novo sistema, caso o
usuário final o possua.
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 beta6 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
50
2.7 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.
51
2.8 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.
Martins (2010) especifica a estrutura básica da UML considerando três
blocos:
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.
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.
54
3.2 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.
3.2.1 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
Manter Cadastro de Clientes
Manter Cadastro de Tipo de Utilização
Figura 3.1 Diagrama de Casos de Uso
Fonte: autoria própria
Técnico
55
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’:
Nome do Caso de Uso
Manter Cadastro de Usuário
Caso de Uso Geral
Ator Principal
Gerente
Atores Secundários
Resumo
Descreve as etapas necessárias para cadastro
de novos usuários no sistema
Pré-Condições
O gerente deverá
administrador
ter
privilégios
de
Pós-Condições
Ações do Autor
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
Gerente
Atores Secundários
Resumo
Descreve as etapas necessárias para gestão
dos itens em estoque
Pré-Condições
Itens devem estar cadastrados anteriormente
no sistema
Pós-Condições
Ações do Autor
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
56
Nome do Caso de Uso
Manter Cadastro de Itens
Caso de Uso Geral
Ator Principal
Gerente
Atores Secundários
Descreve as etapas necessárias manter o
cadastro dos itens do estoque
Resumo
Pré-Condições
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
Gerente
Atores Secundários
Resumo
Descreve as etapas necessárias para registrar
a entrada de itens comprados no sistema
Pré-Condições
Itens devem estar cadastrados anteriormente
no sistema
Pós-Condições
Ações do Autor
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
57
Nome do Caso de Uso
Manter Registro de Saída de Peças
Caso de Uso Geral
Ator Principal
Gerente
Atores Secundários
Técnico
Resumo
Descreve as etapas necessárias para registrar
a saída de itens utilizados
Pré-Condições
O cliente e o item devem estar cadastrados
anteriormente no sistema
Pós-Condições
Ações do Autor
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
Gerente
Atores Secundários
Descreve as etapas necessárias para gerar
relatórios do estoque
Resumo
Pré-Condições
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
58
Nome do Caso de Uso
Manter Cadastro de Fornecedores
Caso de Uso Geral
Ator Principal
Gerente
Atores Secundários
Descreve as etapas necessárias para manter o
cadastro dos fornecedores
Resumo
Pré-Condições
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
apresentar seus dados
CNPJ
cadastrado
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
Gerente
Atores Secundários
Técnico
Resumo
Descreve as etapas necessárias para manter o
cadastro dos clientes
Pré-Condições
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
59
Nome do Caso de Uso
Manter Cadastro de Tipo de Utilização
Caso de Uso Geral
Ator Principal
Gerente
Atores Secundários
Técnico
Resumo
Descreve as etapas necessárias para manter o
cadastro dos tipos de utilização
Pré-Condições
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
3.2.2 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.
60
Requisito
Funcional
RF001
RF001.01
RF002
RF002.01
RF003
RF003.01
RF004
RF004.01
RF005
RF005.01
RF006
RF006.01
RF007
RF007.01
RF008
RF008.01
RF009
RF009.01
Descrição
Prioridade
Manter Cadastro de Usuário
Obrigatório
Contém as seguintes informações: nome de usuário, senha para o
usuário, telefone de contato, nome completo, e-mail, status da conta
(ativo ou inativo) e grupo a que o usuário pertence (administrador ou
usuário).
Obrigatório
Manter Cadastro de Itens de Estoque
Obrigatório
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
Manter registro de entrada de peças
Obrigatório
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
Manter registro de saída de peças
Obrigatório
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
Manter Estoque
Obrigatório
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
Manter Cadastro de Fornecedores
Obrigatório
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), e-mail de contato, nome do contato,
telefone, fax (opcional) e status do fornecedor (ativo ou inativo).
Obrigatório
Manter Cadastro de Clientes
Obrigatório
Contém as seguintes informações: CNPJ do cliente, nome da empresa,
endereço completo, CEP, bairro, cidade, estado, e-mail de contato,
nome do contato, telefone, fax (opcional) e status do cliente (ativo ou
inativo).
Obrigatório
Manter Cadastro de Tipo de Utilização
Obrigatório
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
Gerar relatórios
Obrigatório
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).
Obrigatório
Quadro 3.10 – Elicitação de Requisitos Funcionais
Fonte: Autoria própria
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
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
Obrigatório
RNF003
O sistema foi desenvolvido na linguagem de programação C#. Utiliza-se
utilizar bibliotecas de terceiros.
Obrigatório
RNF004
O sistema utiliza a autenticação de usuários baseado em login e senha.
Obrigatório
RNF005
Cada usuário tem uma regra de utilização do sistema que pode ser
definida no momento do cadastro do usuário.
Obrigatório
RNF006
O sistema grava em um arquivo de logs as ações efetuadas pelos
usuários, ordenadas por data e hora.
Obrigatório
RNF007
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.
Obrigatório
RNF009
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
Regra de
Negócio
Descrição
Prioridade
RNG001
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.
Obrigatório
RNG002
Os usuários simples (técnicos) apenas podem manter o cadastro de
clientes e registrar a saída de peças do estoque.
Obrigatório
RNG003
Apenas os usuários administradores podem gerar relatórios do sistema.
Obrigatório
RNG004
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.
Obrigatório
RNG005
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
62
3.2.3 Análise
A seguir é apresentada a arquitetura de classes do projeto bem como o
modelo relacional do banco de dados. No item ‘3.3.2’ possui uma breve explicação
sobre cada um desses diagramas.
a) Diagramas de classes da camada de modelos:
Figura 3.2 - Diagrama de classes da camada de modelos
Fonte: autoria própria
63
b) Diagrama de classes da camada de negócios:
Figura 3.3 - Diagrama de classes da camada de negócios
Fonte: autoria própria
64
c) Diagrama de classes da camada de acesso a dados:
Figura 3.4 - Diagrama de classes da camada de acesso a dados
Fonte: autoria própria
65
d) Diagrama de classes utilitárias:
Figura 3.5 - Diagrama de classes utilitárias
Fonte: autoria própria
66
e) MER - Modelo de Entidade-Relacionamento do banco de dados criado:
Figura 3.6 MER - Modelo Entidade-Relacionamento
Fonte: autoria própria
3.2.4 Implementação
Para este projeto, não existiu um protótipo de prova do software nem uma
metodologia formal de desenvolvimento.
3.2.5 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
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
Descrição
IIS (Internet Information Service)
Servidor de informações de Internet utilizado para disponibilizar o
funcionamento da aplicação web
Microsoft SQL Server 2008
Sistema de Gerenciamento de Banco de Dados utilizado
Microsoft Visual Studio 2008
Ferramenta utilizada para desenvolvimento do código de
programação do software
Microsoft C#
Linguagem de programação utilizada
Microsoft Windows 7 Professional
Sistema operacional utilizado durante processo de
desenvolvimento
Microsoft .NET Framework 3.5
Biblioteca de classes
Skype 5.9.0.115
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
Configuração de Hardware
Desenvolvimento
Processador: Intel Core 2 Quad 6600
Memória RAM: 4GB
Hard Disk: 500 GB
IP: Dinâmico
Teste
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
68
3.3 Construção
3.3.1 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 3.2.
3.3.2 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 3.2.3.
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
3.2.3.
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 3.2.3.
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.
3.3.3 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
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 2008.
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
'http://localhost/FARO' 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 3.7 - Tela inicial de login do sistema
Fonte: autoria própria
71
b) A figura 3.8 demonstra a tela para alteração de senha do usuário:
Figura 3.8 - Tela inicial de alteração de senha
Fonte: autoria própria
72
c) Caso o usuário esqueça a senha, é solicitado o e-mail de cadastro do
usuário para recuperação de senha conforme figura 3.9:
Figura 3.9 - Tela inicial de redefinição de senha
Fonte: autoria própria
73
d) A figura 3.10 mostra a tela Home do sistema com informações de alguns
dashboards e as opções do menu:
Figura 3.10 - Tela inicial com informações no dashboard e as opções do menu
Fonte: autoria própria
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 3.11 - Tela de manutenção de Clientes
Fonte: autoria própria
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 3.12 - Tela de manutenção de Fornecedores
Fonte: autoria própria
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 3.13 - Tela de manutenção de Inventário
Fonte: autoria própria
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 3.14 - Tela de manutenção de Tipo de Uso
Fonte: autoria própria
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 3.15 - Tela de manutenção de Usuário
Fonte: autoria própria
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 3.16 - Tela de manutenção de Peças
Fonte: autoria própria
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 3.17 - Tela de Registro de Entrada de Peças
Fonte: autoria própria
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 3.18 - Tela de Registro de Saída de Peças
Fonte: autoria própria
82
m) A figura 3.19 demonstra a tela “Contato” onde possui informações sobre os
desenvolvedores do sistema, neste caso os autores deste projeto:
Figura 3.19 - Tela de Contato com os autores
Fonte: autoria própria
83
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:
Figura 3.20 - Tela de Relatório Consolidado
Fonte: autoria própria
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 3.21 - Tela de Relatório Consolidado exportado para Excel
Fonte: autoria própria
85
p) A figura 3.22 demonstra a tela “Relatório de Peças com Quantidade
Críticas” onde demonstra uma posição do estoque com todas as suas peças com
quantidades críticas existentes:
Figura 3.22 - Tela de Relatório de Peças com Quantidades Críticas
Fonte: autoria própria
86
l) A figura 3.23 demonstra a tela “Relatório de Peças com Quantidade Críticas
exportada para Excel” onde demonstra uma posição do estoque com todas as suas
peças com quantidades críticas existentes, porém exportada para Excel:
Figura 3.23 - Tela de Relatório de Peças com Quantidades Critica exportado para Excel
Fonte: autoria própria
87
CONCLUSÃO
Para ganhar e manter competitividade em um mundo globalizado, as
empresas necessitam, além de criar produtos ou serviços inovadores, aperfeiçoar
constantemente seus processos internos e externos. Todas essas atividades
dependem, em menor ou maior grau, dos recursos disponibilizados pela área de
Tecnologia da Informação e Comunicação.
Nesse contexto a empresa objeto do estudo possui um processo de gestão de
estoque baseado em controles manuais, sujeito a erros de todo tipo, impossibilitando
aos gestores terem uma visão correta e completa de seu inventário de peças e
equipamentos. A partir desse cenário, foi proposto o desenvolvimento de um
software que contemplasse o controle automatizado desse inventário, e que
permitisse a tomada de decisões com base em informações completas e corretas.
Embasado nas melhores práticas da metodologia de desenvolvimento de
software, o protótipo gerado encontra-se totalmente alinhado com os requisitos e as
regras de negócio, inicialmente levantados, integrando os diversos cadastros que
fazem parte do processo de gerenciamento do estoque de peças e componentes da
empresa.
Ao término do projeto, considera-se o objetivo desse trabalho cumprido.
Concluindo, a Tecnologia da TI é uma ferramenta estratégica para as organizações,
pois permite controles eficientes e subsídios para tomada de decisões. Ressalta-se
que a criação de soluções de software deve ser embasada nos conceitos da
Engenharia de Software, pois, assim como qualquer outro produto, este deve
atender as expectativas e necessidades dos clientes.
88
BIBLIOGRAFIA
BALLOU, Ronald H.. Logística empresarial: transportes, administração de
materiais e distribuição física. São Paulo: Atlas, 1993.
BALLOU, Ronald H. Gerenciamento da cadeia de suprimentos/logística
empresarial. 5 ed. São Paulo: Bookman, 2004.
BARBACELI, Marco. A importância do TI na sua empresa. Disponível em:
http://www.gestaodecarreira.com.br/coaching/blog-de-ti/a-importancia-do-ti-na-suaempresa.html. Acesso em: 18.mar.2012.
BEAL, Adriana. Introdução à gestão de tecnologia da informação. Disponível em:
http://www.2beal.org/ti/manuais/GTI_INTRO.PDF Acesso em: 05.mai.2012.
BERTAGLIA, Paulo R.. Logística e gerenciamento da cadeia de abastecimento.
2 ed. São Paulo: Saraiva, 2009.
BRANDÃO, Vladimir; GONÇALVES, Ada Cristina V.. Brasil inovador: o desafio
empreendedor: 40 histórias de sucesso de empresas que investem em inovação.
Brasília: IEL-NC, 2006.
BRUSTELLO, Alexandre de Carvalho; SALGADO, Manoel Henrique. Elementos
básicos
de
uma
Cadeia
de
Suprimentos.
Disponível
em:
http://www.simpep.feb.unesp.br/anais/anais_13/artigos/677.pdf.
Acesso
em:
13.mai.2012.
CARLOS, Alberto de Faria. VANTAGEM COMPETITIVA: O Que e Como?
Disponível em: http://www.merkatus.com.br/10_boletim/120.htm. Acesso em:
12.mai.2012.
CARVALHO, Cristina M. J.; RIBEIRO, Leonor C. Os agentes econômicos e suas
relações.
Disponível
em:
http://prof.santana-esilva.pt/economia_e_gestao/trabalhos_06_07/word/Os%20Agentes%20Econ%C3%
B3micos%20e%20as%20suas%20rela%C3%A7%C3%B5es.pdf.
Acesso
em
17.mar.2012.
CARVALHO, Vininha F. A importância da inovação dentro das empresas.
Disponível
em:
http://www.revistaecotour.com.br/novo/home/default.asp?tipo=noticia&id=1903.
Acesso em: 17.mar.2012.
89
CAVAGNOLI, Irani. Sensibilização da Importância da Inovação. Disponível em:
http://gestaoeinovacao.com/?p=1678. Acesso em: 17.mar.2012.
CHAGAS, Carla P.; SOUZA, Simone; SIMÃO, Flávio P. A Relevância do Sistema
Informatizado para Controle de Estoques na Gestão Empresarial: Um Estudo de
Caso.
Disponível
em:
http://www.aedb.br/seget/artigos09/220_220_Relevancia_do_Sistema_Informatizado
_para_Controle_de_Estoques.pdf. Acesso em: 19.mai.2012.
CORRÊA, Henrique L., GIANESI, Irineu G. N., CAON, Mauro. Planejamento,
programação e controle da produção : MRP II/ERP : conceitos, uso e
implantação: base para SAP, Oracle Applications e outros softwares integrados de
gestão. 5 ed. São Paulo : Atlas, 2007.
FITZSIMMONS, James A., FITZSIMMONS Mona J. Administração de Serviços:
operações, estratégia e tecnologia da informação. 4. ed. São Paulo: Artmed, 2004.
GARCIA, Eduardo S. et al. Gestão de estoques: otimizando a logística e a cadeia
de suprimentos. Rio de Janeiro: E-Papers, 2006.
GUEDES, Gilleanes T. A.. UML 2: Uma abordagem prática. São Paulo: Novatec,
2009.
HABERKORN, Ernesto. Um bate papo sobre T.I.: Tudo que você gostaria de saber
sobre o ERP e a tecnologia da Informação, mas ficava encabulado de perguntar.
São Paulo: Saraiva, 2009.
LODDI, Sueli Aparecida. Tecnologia da Informação como suporte para a
competitividade: um estudo no setor de seguros. Disponível em:
http://www.uscs.edu.br/posstricto/administracao/dissertacoes/2006/Sueli_Aparecida_
Loddi/dissertacao.pdf. Acesso em: 20.abr.2012.
MARTINEZ, Marina. RUP. Disponível em http://www.infoescola.com/engenharia-desoftware/rup/#. Acesso em: 09.mai.2012.
MARTINS,
Eliane
F.
Gestão
de
Estoques.
Disponível
em:
http://www.administracao.ufcg.edu.br/adm_rec_mat_pat/Apostila%20Gestao%20de
%20Estoques%202009.2.pdf. Acesso em: 17.mar.2012.
MARTINS, José C. Cordeiro. Gerenciando projetos de desenvolvimento de
software com PMI, RUP e UML. 5. ed. Rio de Janeiro: Brasport, 2010.
90
MARTINS, Petrônio. G.; LAUGENI, Fernando P. Administração da produção. 1.
ed. São Paulo: Saraiva, 1998.
MARTINS, Petrônio G; LAUGENI, Fernando P. Administração da produção. 2. ed.
São Paulo : Saraiva, 2006.
PEREGRINO,
Fernanda.
O
que
é
inovação.
Disponível
em:
http://www.facadiferente.sebrae.com.br/2010/04/20/programa-02-o-que-e-inovacao/.
Acesso em: 01.mai.2012.
PORTER, Michael E. Estratégia competitiva: técnicas para análise de indústrias e
da concorrência. Rio de Janeiro : Elsevier, 2004.
RAMOS, Anatália S. M.; SILVA, Edwin A. J. da; ALVERGA, Patrick R. O papel
estratégico da TI nas micro e pequenas empresas. Natal: SEBRAE/RN, 2009.
RIKARD, Frank. A inovação como paradigma de competitividade. Disponível em:
http://www.administradores.com.br/informe-se/artigos/a-inovacao-como-paradigmade-competitividade/25592/ Acesso em: 09.mai.2012.
RODRIGUES, Washington L. H. P.; SANTIN, Nilson J. Gerenciamento da cadeia
de suprimentos. Disponível em: ftp://ftp.usjt.br/pub/revint/97_37.pdf. Acesso em:
17.mar.2012.
SANTOS, Edgard. Como lidar com o mercado competitivo. Disponível em:
http://www.recantodasletras.com.br/artigos/3422676 Acesso em: 05.mai.2012.
SANTOS, Marco A. C. dos. A Importância da TI nas Organizações. Disponível em:
http://www.baguete.com.br/artigos/636/marco-antonio-carvalho-dossantos/29/05/2009/a-importancia-da-ti-nas-organizacoes. Acesso em: 18.mar.2012.
SCHACH, Stephen R.. Engenharia de Software: Os paradigmas clássicos
orientado a objetos. 7. ed. São Paulo: McGraw-Hill, 2009.
SLACK, Nigel; CHAMBERS, Stuart; JOHNSTON, Robert. Administração da
produção. 3. ed. São Paulo: Atlas, 2009.
SOMMERVILLE, Ian. Engenharia de Software. 9. ed. São Paulo: Pearson Prentice
Hall, 2011.
91
SOUZA, Meidson Oliveira. A importância do controle diário da produção para
metas anuais: um estudo de caso na Vale S/A, São Luís – MA. Disponível em:
http://pt.scribd.com/doc/76259535/Controle-Diario-da-Producao-Um-estudo-de-caso.
Acesso em: 09.mai.2012.
MAIA,
Hugo.
As
fases
e
disciplinas
do
RUP.
http://hugohabbema.blogspot.com.br/2009/09/as-fases-do-rup.html.
09.jun.2012.
Disponível
em:
Acesso
em: