FABIO SANTANA REIS

Integrao do cho de fbrica com sistemas ERP

Monografia
apresentada

Escola
Politcnica da Universidade de So Paulo
para obteno do Ttulo de Especialista em
Tecnologia da Informao.
Orientador:
Prof. Dr. Nelson Tanomaru

So Paulo
2012

FABIO SANTANA REIS

Integrao do cho de fbrica com sistemas ERP

Monografia
apresentada

Escola
Politcnica da Universidade de So Paulo
para obteno do Ttulo de Especialista em
Tecnologia da Informao.

So Paulo
2012

FICHA CATALOGRFICA

Reis, Fabio Santana

Integrao do cho de fbrica com sistemas ERP / F.S.
Reis. -- So Paulo, 2012.
65 p.
Monografia (MBA em Tecnologia da Informao) - Escola
Politcnica da Universidade de So Paulo. Programa de Educao Continuada em Engenharia.
1. Manufatura (Produo; Controle; Sistemas) I. Universidade de So Paulo. Escola Politcnica. Programa de Educao
Continuada em Engenharia II. t.

AGRADECIMENTOS
Ao Prof. Dr. Nelson Tanomaru, pela sua indispensvel orientao, tendo
compartilhado comigo seu tempo, conhecimento e experincia durante a elaborao
deste trabalho.
minha famlia que sempre me apoiou e esteve ao meu lado nos momentos mais
difceis de minha vida.

RESUMO

Em busca de uma melhor integrao entre as diferentes funes de negcio dentro

de uma empresa, cada vez mais comum o uso de sistemas corporativos,
denominados ERP (Enterprise Resource Plannning) nesta tarefa. No entanto,
tratando-se do cho de fbrica, em muitos casos, este tipo de sistema no oferece
informaes confiveis em tempo real sobre o processo de manufatura, dependendo
da interferncia humana. Diante dessa lacuna no fluxo de informaes existente
entre o cho de fbrica e o sistema ERP, este trabalho prope um processo para
elaborao de um software, classificado como MES (Manufacturing Execution
System), cujo objetivo a integrao de ambos, oferecendo assim maior
sincronismo das informaes geradas.
Dessa maneira, um estudo preliminar baseado tanto em publicaes de entidades
internacionais quanto em outros trabalhos acadmicos relacionados ao tema, foram
fundamentais para uma abordagem mais concisa dos conceitos que envolvem este
trabalho. Alm disso, foram estudadas tambm as melhores prticas de TI e
engenharia de software, nas quais foram baseadas o processo de elaborao do
software proposto.
Como resultado, a obteno do processo que disciplina e estrutura a tarefa de
desenvolvimento de um MES, demonstrou-se satisfatria. Pois, desse modo, tem-se
um processo repetvel e, na medida do possvel, independente da pessoa que ir
execut-lo.

Palavras-chave: Enterprise Resource Planning, cho de fbrica, Manufacturing

Execution System, processos de software.

ABSTRACT

Seeking for a better integration between different business functions within a

company, it is increasingly common the use of corporate systems, called ERP
(Enterprise Resource Plannning) in this task. However, talking about shop floor, in
many cases, this type of system does not provide reliable information in real time
about manufacturing process, depending on human interference. Given this gap in
information flow between the shop floor and ERP system, this paper proposes a
process for development of software, classified as MES (Manufacturing Execution
System), whose objective is the integration of both, providing greater synchronization
of information generated.
Thus, a preliminary study based on both publications of international agencies and
other academic papers related to the topic, were essential for a more concise
concepts that surround this work. Moreover, it was studied the best practices in IT
and software engineering, which were based on the process of drafting the proposed
software.
As a result, the achievement of the process that guides and structures the
development task of MES, shown satisfactory. Because, this way, it has a repeatable
process, and as far as possible independent of the person who will perform it.
Keywords: Enterprise Resource Planning, shopfloor, Manufacturing Execution
System, software process.

SUMRIO

LISTA DE ANEXOS E FIGURAS.................................................................................. 9

LISTA DE TABELAS................................................................................................. 10
LISTA DE ABREVIATURAS E SIGLAS.......................................................................11

1.

Introduo................................................................................................... 1

1.1.

Contexto Inicial............................................................................................. 1

1.2.

Objetivo....................................................................................................... 1

1.3.

Justificativa.................................................................................................. 2

1.4.

Abrangncia................................................................................................. 2

1.5.

Metodologia................................................................................................. 3

2.

Conceitos utilizados.................................................................................. 4

2.1.

Sistemas Integrados de Gesto Empresarial.....................................................4

2.2.

Sistemas de cho de fbrica...........................................................................6

2.3.

Manufacturing Execution System....................................................................7

2.4.

Business Process Modeling Notation...............................................................9

2.5.

Engenharia de Software............................................................................... 12

2.6.

Processos de Software................................................................................ 13

2.7.

Modelos de Processos de Software...............................................................14

2.7.1.

Modelo Cascata................................................................................. 15

2.7.2.

Modelo Incremental...........................................................................16

2.7.3.

Modelo Orientado a Reuso.................................................................17

2.8.

Detalhamento da Proposta...........................................................................18

2.9.

UML.......................................................................................................... 21

3.

Integrao do cho de fbrica com sistemas ERP............................23

3.1.

Introduo.................................................................................................. 23

3.1.1.

Contextualizao do ambiente corporativo.......................................24

3.1.2.

Contextualizao do MES..................................................................25

3.1.3.

Atividades do Projeto.........................................................................27

3.1.4.

Planejamento..................................................................................... 29

3.1.5.

Levantamento de Requisitos.............................................................30

3.1.6.

Anlise e modelagem do software.....................................................32

3.1.7.

Projeto............................................................................................... 33

3.1.8.

Implementao.................................................................................. 35

3.1.9.

Verificao......................................................................................... 36

3.1.10. Implantao....................................................................................... 36
3.2.

Experimentao.......................................................................................... 37

3.2.1.

Planejamento..................................................................................... 38

3.2.2.

Levantamento de Requisitos.............................................................39

3.2.3.

Anlise e Modelagem........................................................................44

3.2.4.

Projeto............................................................................................... 45

3.2.5.

lmplementao.................................................................................. 47

3.2.6.

Verificao......................................................................................... 48

3.2.7.

Implantao....................................................................................... 48

3.3.

Anlise de resultados.................................................................................. 49

4.

Concluso................................................................................................. 51

5.

Referncias bibliogrficas......................................................................53

LISTA DE ANEXOS E FIGURAS

Figura 1 - Sistema Integrado de Gesto Empresarial

Figura 2 - Fluxo de informaes: sistemas de controle, MES e ERP
Figura 3 Modelo em cascata
Figura 4 Desenvolvimento Incremental
Figura 5 Engenharia de Software orientada a reuso
Figura 6 Diagramas definidos pela UML
Figura 7 Contexto do MES
Figura 8 Etapas do Processo de Elaborao do Middleware
Figura 9 Middleware que preenche a lacuna entre ERP e cho de fbrica
Figura 10 Tringulo da Gerncia de Projeto
Figura 11 Tcnicas para levantamento de requisitos
Figura 12 Viso geral da atividade de projeto
Figura 13 BPMN AS IS
Figura 14 BPMN AS TO BE
Figura 15 Casos de Uso
Figura 16 Diagrama de Classes MES
Figura 17 Diagrama de Sequencia MES
Figura 18 Diagrama de Arquitetura do Sistema
Figura 19 Diagrama de Implantao

LISTA DE TABELAS
Tabela 1 - Objetos de Fluxo
Tabela 2 - Objetos de Conexo
Tabela 3 - Swinlanes
Tabela 4 - Artefatos
Tabela 5 - Atributos essenciais de um bom software
Tabela 6 - Atividades para elaborao do MES
Tabela 7 - Estimativa de horas
Tabela 8 - Caso de Uso 1
Tabela 9 - Caso de Uso 2

LISTA DE ABREVIATURAS E SIGLAS

API

Application Programming Interface

BPMI

Business Process Management Initiative

CIM

Computation Independent Model

COTS

Commercial off-the-shelf

CRM

Customer relationship management

ERP

Enterprise Resource Planning

IDE

Integrated Development Environment

ISA

Industry Standard(s) Architecture

MES

Manufacturing Execution System

MESA

The Manufacturing Execution Systems Association

MRP

Material Requirement Planning

MRPII

Manufacturing Resource Planning

OLE DB

Object Linking and Embedding Database

PIM

Platform Independent Model

SCADA

Sistemas de Superviso e Aquisio de Dados

SDCD

Sistema digital de controle distribudo

SGBD

Sistema Gerenciador de Banco de Dados

SIGE

Sistema Integrado de Gesto Empresarial

SQL

Structured Query Language

WIP

Work in process

1. Introduo

1.1. Contexto Inicial

crescente a utilizao de sistemas de gesto como forma de aumentar

significativamente a integrao entre todos os processos de negcio envolvidos nas
empresas, tendo como foco a empresa como um todo e no apenas os limites
departamentais.
Uma das maneiras mais utilizadas para se obter tal integrao atravs da
utilizao dos sistemas ERP, porm estudos tm demonstrado que existe uma
lacuna entre esses sistemas e o cho de fbrica das empresas. [2]
Essa lacuna preenchida por meio de um middleware MES (Manufacturing
Execution System) que permite a obteno de informaes mais confiveis a fim de
controlar melhor os processos de uma empresa, possibilitando dessa maneira a sua
contnua melhoria, pois uma eventual falha poderia ser corrigida muito mais
rapidamente.

1.2. Objetivo

O objetivo do trabalho estabelecer um processo (sequencia sistemtica de

atividades) para elaborao de um middleware que realize a integrao entre o cho
de fbrica e um sistema ERP. Dessa maneira, apoiado nas melhores prticas de
engenharia de software, prope-se um processo que visa estabelecer um guia
prtico para a construo de um MES.

1.3. Justificativa

Apesar de ser uma excelente ferramenta de apoio tomada de deciso, medida

que os profissionais envolvidos com a implementao de solues ERP comeam a
entender melhor sua funcionalidade, percebem que existe um grande vazio entre os
sistemas de planejamento corporativo e a efetiva execuo (cho de fbrica) [15].
Deste modo, para preencher esta lacuna prope-se o MES, uma ferramenta que
controla a execuo das atividades, fluxo de matria-prima, produtos, status das
ordens de produo, etc. alm de facilitar a comutao de dados e aes entre o
cho de fbrica e outras reas da empresa visando ganhos estratgicos.[15].
Diante das diversas implementaes desta ferramenta no mercado, sendo grande
parte delas apenas mdulos isolados [5] e justificado pela extrema relevncia do
assunto, empresas e rgos reguladores tm proposto solucionar tal deficincia
informativa (criada por esta lacuna) com metodologias e produtos para esse fim [15]
[16].
Assim, devido s restries de tais mdulos ou dependendo das particularidades da
empresa, a adequada integrao dos dados de controle e superviso do cho de
fbrica com as informaes corporativas e estratgicas do ERP demandam a
elaborao de um MES com atributos que atendam s necessidades no cenrio
proposto.

1.4. Abrangncia

Este trabalho restringe-se ao estabelecimento de atividades que devem orientar o

processo de elaborao de um middleware que integre o cho de fbrica a um
sistema ERP, preenchendo assim, uma lacuna de informao entre ambos.
Embora, o processo tenha sido implementado a fim de experiment-lo na prtica
aquilo que se prope em teoria, no sero abrangidos neste trabalho documentos de
verificao, cdigo-fonte ou mesmo os manuais do sistema implementado.

1.5. Metodologia

Para a elaborao desta monografia, foram realizadas as seguintes atividades:

Identificao do tema: aps pesquisas baseadas em publicaes de
entidades voltadas rea de automao industrial, trabalhos acadmicos afins
e maior entendimento sobre as dificuldades enfrentadas por profissionais
envolvidos neste contexto, chegou-se ao tema proposto na monografia;
Criao do processo: visando aliar as mais difundidas tcnicas de
engenharia de software ao objetivo estabelecido, foram identificadas as
seguintes etapas para a criao do processo que dever ser um guideline na
obteno de um sistema MES: levantamento de requisitos, anlise e
modelagem, projeto, implementao, verificao, implantao e produo;
Aplicao do processo: para validao da proposta, foi escolhido um
processo de cho de fbrica, onde foram aplicadas as atividades propostas
para a elaborao de um MES que fornecesse informaes sobre a linha de
produo em tempo real ao ERP.
Coleta de resultados: como resultado, o processo possibilitou maior controle
sobre a execuo de um projeto com etapas pr-definidas e padronizadas,
permitindo um melhor aproveitamento dos recursos envolvidos.

2. Conceitos utilizados

Sero abordados como objeto deste captulo os seguintes tpicos conceituais:

Sistemas Integrados de Gesto Empresarial, Sistemas de cho de fbrica, MES,
BPMN e Engenharia de software.

2.1. Sistemas Integrados de Gesto Empresarial

A partir da dcada de 1950, comearam a surgir os primeiros sistemas de controles

de estoques que ainda eram extremamente caros e lentos. Duas dcadas depois,
com a maior difuso da computao, so desenvolvidos os sistemas MRPs (Material
Requirement Plannig ou Planejamento de Requisies de Materiais) que evoluram
dando origem a sistemas de maior abrangncia de controles sobre a mo-de-obra e
maquinrio na dcada de 1980 que denominados MRP II.
Tais sistemas antecederam o surgimento dos sistemas ERP (Enterprise Resource
Planning ou SIGE - Sistema Integrado de Gesto Empresarial) ocorrido na dcada
de 1990 e fortemente disseminado nesta poca amparado pela evoluo nas redes
de comunicao entre computadores. Outro fator que importante que contribuiu para
esse boom foi a substituio do uso de mainframes pela arquitetura cliente/servidor
que consiste em microcomputadores ligados a servidores, uma opo com preo
mais competitivo.
Do ponto de vista do negcio, o fenmeno da difuso destes sistemas a partir dos
anos 90 pode ser justificado ainda pelas presses competitivas sofridas pelas
empresas obrigando-as a buscar alternativas para a reduo de custos, agilidade e
eficincia. [7]
Desse modo, os sistemas ERP integram e oferecem suporte s diversas operaes
de uma empresa (suprimentos, manufatura, manuteno, administrao financeira,
contabilidade, recursos humanos etc.) em um nico sistema com base de dados
centralizada[4] o que facilita o fluxo de informaes entre todas as atividades da
empresa, desde o fornecimento de matria-prima at a venda de produtos ao
cliente, conforme figura a seguir:

Fonte [10]: Figura 1 - Sistema Integrado de Gesto Empresarial

Assim, as informaes da empresa so armazenadas em um banco de dados
corporativo que deve servir como fonte de consulta numa eventual tomada de
deciso ou mesmo para analisar relaes de causa e efeito, acompanhar o resultado
de aes planejadas etc. Tudo isso, com o uso de um ERP, pode ser realizado de
maneira integrada, consolidando as operaes do negcio, com mais consistncia,
confiabilidade, rapidez e eficincia.
Dentre as vantagens de um sistema ERP, destacam-se as seguintes:

Eliminar o uso de interfaces manuais;

Reduzir custos e estoques;

Otimizar o fluxo da informao e a qualidade da mesma;

Facilitar o processo de tomada de deciso;

Eliminar redundncia de informaes;

Reduzir o tempo de resposta s mudanas de mercado;

Aumentar a competitividade;

Melhorar a produtividade;

Melhorar os servios prestados aos clientes;

Melhorar o planejamento e alocao de recursos, etc.

2.2. Sistemas de cho de fbrica

O termo cho de fbrica, consagrado durante a Revoluo Industrial ocorrida no

sculo XVIII, remete a idia de um lugar onde ocorre a transformao da matriaprima em produto acabado. Naquela poca, o modo de produo artesanal deu
lugar ao regime de produo mecanizada em massa proporcionando maior
produtividade e padronizao com reduo de custos. A partir de ento, o cho de
fbrica passou a sofrer transformaes buscando sempre aprimorar o processo de
produo.[11].
Nesse sentido, surgiram os sistemas de cho de fbrica especficos para o setor de
produo, orientados para melhoria dos processos, integrando as informaes
geradas por este ao ERP e possibilitando assim, um melhor planejamento,
programao e controle da produo aos gestores.
Com estes sistemas, possvel identificar gargalos de produo ocasionados pelos
mais diversos motivos tais como indisponibilidade do equipamento ou da matriaprima. Assim, no caso de problemas como esses, por exemplo, possvel uma
rpida reao como resposta, evitando perdas por qualquer desvio de procedimento.
Desta maneira, o uso de um sistema desta categoria, fornece informaes
essenciais como:

Quantidade de peas produzidas por OP;

Quantidade de peas produzidas por turno;

Nmero de peas defeituosas;

Tempo de espera;

Tempo de fila;

Tempo de set-up;

Tempo de mquina parada;

Tempo de processamento;

Tempo de movimentao;

Identificao de mquinas gargalo;

Rastreabilidade do lote;

Capacidade utilizada, etc.

2.3. Manufacturing Execution System

O conceito de MES (Manufacturing Execution System ou Sistema de Execuo de

Manufatura) baseado num outro conceito conhecido desde a dcada de 1970
como CIM (Computer Integrated Manufacturing ou Manufatura Integrada por
computador), sendo que ambos se baseiam no uso da Tecnologia da Informao
como meio para suportar a integrao entre departamentos, atividades e sistemas
de uma empresa.
Este tipo de software surgiu da necessidade de se estreitar a lacuna existente entre
a rea corporativa que faz uso das informaes disponveis no ERP ao cho de
fbrica, disponibilizando assim, informaes confiveis e em tempo real sobre o
cho de fbrica. Tal ferramenta, possibilita desta maneira, a melhor utilizao das
funcionalidades do ERP.
Assim, o termo MES foi criado por Bruce Richardson da AMR (Advanced
Manufacturing Research of Cambridge) para descrever sistema de informaes
localizados no cho de fbrica que permitem o fluxo de informaes deste setor de

maneira automtica s demais reas de empresa, integrando-se ao ERP. [5]

A importncia do MES na rea de manufatura motivou o surgimento da MESA
(Manufacturing Enterprise Solutions Association) International [12] que uma
entidade global de representantes da indstria de manufatura e fornecedores de
solues com o objetivo de melhorar a produtividade e a gesto de operaes,
utilizando-se da aplicao eficaz de solues de tecnologia e melhores prticas.
Esta associao define o MES como um sistema de cho de fbrica orientado
melhoria de desempenho que complementa e aperfeioa os sistemas integrados de
gesto planejamento e controle da produo, a exemplo do MRPII incorporado
nos sistemas ERP, o qual capaz de controlar o andamento de uma ordem de
produo em progresso.
A figura a seguir ilustra o fluxo de atualizao das informaes entre sistemas de
controle, MES e, onde possvel observar a funo de coletor do MES, que obtm
as informaes do cho de fbrica, confrontando e consolidando esses dados com
os disponveis no ERP possibilitando a gerao de relatrios gerenciais e dados de
acompanhamento.[5]

Fonte [5] : Figura 2 - Fluxo de informaes: sistemas de controle, MES e ERP

2.4. Business Process Modeling Notation

A BPMN (Business Process Modeling Notation ou, em portugus, Notao de

Modelagem de Processos de Negcio) uma notao grfica composta por uma
srie de smbolos padres utilizados para representar processos de negcio de uma
maneira organizada.
Assim, o objetivo desta ferramenta lanada no ano de 2004 e suportada atualmente
pela OMG(Object Management Grou) oferecer suporte ao gerenciamento do
processo do negcio, tanto para os usurios tcnicos quanto para os usurios
atrelados ao negcio propriamente, pois ela fornece uma notao intuitiva para
esses usurios, tornando-os capazes de representarem processos complexos sem
grandes dificuldades.
A BPMN define um diagrama de processo de negcio (BPD), baseado em uma
tcnica de diagrama de fluxo para modelagem dos processos de negcio que tm
suas atividades e controles de fluxos (representados por elementos grficos)

10

definidas numa ordem de execuo. Dessa maneira, possvel entender o negcio

da organizao, suas necessidades e principais problemas atuais (AS IS). Uma vez
compreendidos estes problemas, buscam-se alternativas para minimiz-los ou
resolv-los e, de forma geral, otimizar os processos analisados atendendo as
expectativas dos usurios envolvidos (AS TO BE).
Desde o incio quando foi proposta em 2001, a BPMN foi apoiada por vrias
empresas de renome mundial no segmento de modelagem de processos, sendo
uma resposta independente de fornecedor de soluo demanda de modelagem de
processos.
Abaixo, tm-se alguns dos principais elementos da BPMN agrupados em suas
categorias bsicas de modo simplificado:

Objetos de Fluxo: so os principais elementos grficos para definir o

comportamento do processo de negcio. Existem trs tipos de objetos de fluxos:

atividades, eventos e decises:
Evento: algo que acontece ao longo do
curso de um processo de negcio,
afetando o fluxo do processo.
Atividade:

termo

genrico

para

trabalho realizado em uma empresa.

Tipos: Tarefa e Sub-Processo

Gateway(Decisor):

controla

divergncia e a convergncia de um
fluxo de sequencia, determinando as
decises.
Tabela 1 - Objetos de Fluxo

Objetos de Conexo: conectam objetos de fluxo. Podem ser: fluxo de

11

sequencia, fluxo de mensagem e associao;

Fluxo de Sequencia: mostra a ordem
(sequencia) das atividades que sero
realizadas em um processo.
Fluxo de Mensagem: mostra o fluxo de
mensagens entre dois participantes de
processos separados.
Associao: associa dados, texto e
outros artefatos com objetos de fluxo.
Tabela 2 - Objetos de Conexo

Swinlanes

(raias

de

natao):

agrupam

elementos

do

processo

normalmente associados a unidades organizacionais, departamentos ou grupos.

Pool

(piscina):

representa

um

participante em um processo

Lane

(raia):

organiza

categoriza

atividades em um Pool. uma partio

do Pool

Tabela 3 - Swinlanes

Artefatos: fornecem informaes adicionais sobre o processo. Alguns

exemplos de artefatos so: objeto de dados, grupos e anotao.

Objeto de dados: denotam o uso de
documentos em um processo e tambm
pode ser usado para definir entradas e
sadas das atividades

12

Grupo: destaca sees de um diagrama

e no afeta o fluxo de sequencia

Tabela 4 Artefatos

2.5. Engenharia de Software

Visando melhorar a qualidade dos produtos de software e aumentar a produtividade

no processo de desenvolvimento de software, surgiu a Engenharia de Software [16]
que consiste na aplicao de princpios de engenharia de maneira sistemtica,
disciplinada e quantificvel para o desenvolvimento, operao e manuteno do
software.[17].
Sendo assim, a engenharia de software trata de tcnicas que auxiliam a
especificao, projeto e evoluo do software com os seguintes atributos: [1]

Caractersticas

Descrio

Manutenibilidade O MES deve ser codificado de modo que sua evoluo seja
facilitada a fim de atender a eventuais mudanas de requisitos
solicitadas pelo usurio.

Confiana
proteo

e Confiabilidade, proteo e segurana devem ser caractersticas

intrnsecas ao middleware, pois no caso de uma falha do sistema,
deve-se garantir a integridade do processo de negcio.
Dessa maneira, medidas de segurana so fundamentais para
evitar ataques de usurios mal intencionados que possam

13

prejudicar o sistema.

Eficincia

O software no deve desperdiar os recursos do sistema, como

memria e ciclos do processador. Portanto, eficincia inclui
capacidade de resposta, tempo de processamento, uso de
memria etc.

Aceitabilidade

O MS produzido deve ser compreensvel, usvel e compatvel

com outros sistemas, reduzindo assim o risco de rejeio.

Adaptado de Fonte [1]: Tabela 5 - Atributos essenciais de um bom software

2.6. Processos de Software

O conjunto de atividades exercidas na elaborao de um software bem como os

mtodos que visam aumentar a produtividade e a qualidade do mesmo constituem
um processo de software. Tais atividades podem ser classificadas quanto ao seu
propsito em:

Atividades de Desenvolvimento: so as atividades que contribuem para o

desenvolvimento do produto de software propriamente e tm-se como
exemplos destas atividades: especificao e anlise de requisitos, projeto e
implementao.

Atividades de Gerncia: relacionadas ao planejamento e acompanhamento

gerencial do projeto, tais como realizao de estimativas, elaborao de
cronogramas, anlise de riscos do projeto etc.

Atividades de Garantia da Qualidade: ligadas garantia da qualidade do

produto em desenvolvimento e do processo de software utilizado.[17]

Deste modo, o uso de um processo sistemtico baseado em modelos e princpios de

engenharia so imprescindveis quando se deseja produzir um software eficiente a
baixo custo e dentro de um prazo estabelecido.

14

Segundo Sommerville[1], os processos de softwares so muitos e variados, mas

todos compartilham das seguintes atividades fundamentais:
1.Especificao de software: descreve os requisitos do sistema de modo claro, sem
ambiguidades, de maneira concisa e consistente;
2.Projeto e implementao de Software: o software produzido de acordo com a
especificao;
3.Validao de Software: para garantir que o software atenda aos requisitos e as
expectativas dos clientes, necessria sua validao.
4.Evoluo do software: requisitos podem mudar e consequentemente o software
deve evoluir para atender novas demandas.
Na prtica, estas atividades, presentes em todos os processos de software so
complexas em si e, para facilitar a sua execuo, so divididas em subatividades.

2.7. Modelos de Processos de Software

Um modelo de processo de software uma representao simplificada dos objetos e

atividades envolvidas no processo de software que facilita o gerenciamento destas.
Cada modelo oferece uma perspectiva ou abordagem particular do desenvolvimento
de software com informaes parciais sobre tal tarefa. Assim, considerando-se as
caractersticas particulares de cada modelo, a escolha de um deles pode ser
entendida como uma referncia para o processo de desenvolvimento de software
tomando-se como base as recomendaes deste e, assim, adapt-lo ao contexto
onde ser implementado o middleware proposto.
Sommerville [1] adota em sua bibliografia os seguintes modelos clssicos:

Modelo Cascata;

Desenvolvimento incremental;

Engenharia de software orientada a reuso.

15

Tais modelos podem ser combinados de acordo com o grau de aderncia das
caractersticas de cada um ao sistema proposto.

2.7.1.

Modelo Cascata

Trata-se de um tpico processo dirigido a planos, o que significa que as atividades do

processo so todas planejadas e programadas antes de serem executadas. [1].
Na figura a seguir, observa-se que as atividades de desenvolvimento so
estruturadas de tal modo que a sada de uma a entrada para a prxima.

Fonte [1] : Figura 3 Modelo em cascata

Conforme a ilustrao, os principais estgios deste modelo so:

1.Anlise e definio de requisitos: nesta etapa, realizado o levantamento de
requisitos do software junto ao usurio, observando-se quais as suas expectativas e
benefcios esperados para reduzir o risco de rejeio por parte deste em relao ao
sistema.
2.Projeto de sistema e software: os requisitos so estruturados, sendo alocados para

16

sistemas

de

disponibilidade,

hardware

(capacidade

de

processamento

armazenamento,

etc) ou de software (banco de dados, arquitetura do sistema,

interfaces,etc). Esta etapa tem como objetivo a produo de artefatos que

representem os requisitos obtidos de uma forma que permita a codificao do
software.
3.Implementao e teste unitrio: seguindo o velho lema dividir para conquistar,
nesta etapa, o projeto do software dividido em unidades denominadas programas
que so implementados individualmente. Da mesma maneira, tais programas devem
ser testados para verificar se esto de acordo com os requisitos pr-estabelecidos.

4.Integrao e teste de sistema: Os programas so integrados, constituindo assim o

todo (sistema) formado pelas partes (programas). No entanto, para assegurar o bom
funcionamento do sistema completo e o cumprimento dos requisitos, faz-se
necessrio o teste das funcionalidades antes da entrega ao cliente.
5.Operao e manuteno: Uma vez disponibilizado para uso (em operao), o
software poder apresentar erros que no foram detectados anteriormente. Deste
modo alm de corrigi-los, nesta etapa tambm realizada a melhoria do software
em resposta a eventuais mudanas de requisitos.

2.7.2.

Modelo Incremental

Este modelo consiste na entrega de implementaes parciais que atendam parte

dos requisitos a partir de uma rpida implementao inicial baseada em
especificaes abstratas. Desse modo, o processo se repete e, a cada nova verso,
os erros da verso anterior so corrigidos alm do incremento de novas
funcionalidades. Este ciclo repetido at que se entregue uma verso final do
software que atenda a todos os requisitos.[1]
Na figura a seguir, possvel observar um diagrama que representa as seguintes
etapas do modelo - especificao, desenvolvimento e validao - intercaladas com
feedback associado a cada uma delas.

17

Fonte [1] : Figura 4 Desenvolvimento Incremental

2.7.3.

Modelo Orientado a Reuso

Esse tipo de abordagem aumenta a produtividade uma vez que evita esforos
desnecessrios de programao com o aproveitamento da experincia de projetos
anteriores, reduzindo assim os riscos. [1]
Na figura a seguir, observam-se os estgios do processo de desenvolvimento de
software baseado no reuso:

Fonte [1] : Figura 5 Engenharia de Software orientada a reuso

Esse modelo se diferencia por possuir atividades especficas, tais como:

1.Anlise de componentes: Tendo a especificao de requisitos, realizada uma

18

busca por componentes a fim de implementar a especificao;

2.Modificao de requisitos: Aps pesquisa de componentes, os requisitos so
analisados e se necessrio, devero sofrer modificaes para atender as limitaes
dos componentes disponveis. Na impossibilidade disso acontecer, deve-se
considerar voltar ao passo anterior;
3.Projeto do sistema com reuso: Neste estgio, o sistema projetado em mdulos
levando-se em considerao os componentes que sero reusados;
4.Desenvolvimento e integrao: Quando no h possibilidade de adquirir um
software externo, este dever ser desenvolvido e integrado aos componentes e
sistemas COTS utilizados.

2.8. Detalhamento da Proposta

Tendo em vista o tpico anterior, h vrios aspectos a serem considerados na

escolha de um modelo adequado de processo de software. Fatores como modelo de
ciclo de vida, detalhamento das atividades, escolha de mtodos, tcnicas, roteiros,
recursos e a necessidade de produo de artefatos podem conduzir a definio do
processo que ser instanciado
Sendo assim, considerando-se o domnio da aplicao, neste projeto ser adotado o
Modelo em Cascata, onde as etapas de desenvolvimento seguem uma abordagem
sistemtica e seqencial. Desse modo, pressupe-se que o cliente participa
ativamente do processo validando cada uma das etapas antes de passar seguinte.
No entanto, o modelo ser apenas uma referncia, pois o processo no tem
necessariamente todas as etapas deste. Algumas fases foram substitudas e outras
adicionadas para se obter um modelo mais aderente ao contexto. Desta maneira,
tem-se na figura abaixo um diagrama simplificado com as etapas descritas no
processo de software proposto:

19

Figura 8 - Etapas do Processo de Elaborao do Middleware

Cabe ressaltar que este processo independente da tecnologia de implementao a
ser escolhida para a construo de um middleware cuja responsabilidade a
integrao entre o cho de fbrica e o sistema ERP, tendo em vista a existncia de
uma interface em cada um dos extremos, conforme figura abaixo:

Figura 9 - Middleware que preenche a lacuna entre ERP e cho de fbrica

20

As interfaces (cho de fbrica e ERP) ilustradas tm a funo de trafegar dados

simplesmente e, no caso em questo, o MES dever acessar diretamente a base de
dados corporativa via OLE DB (Object Linking and Embedding Database) que uma
API (Application Programming Interface) desenvolvida pela Microsoft para o acesso
universal a diversas fontes de dados.
Para isso, as classes de persistncia devem ser desenvolvidas tendo em vista o
conhecimento da base de dados do ERP (BPCS) no qual se apia esta aplicao.
Desse modo, ser elaborado um guia que abrange todas as etapas do
desenvolvimento desta ferramenta (MES) com as seguintes atribuies:

Definir expectativas a serem alcanadas;

Definir viabilidade econmica;

Estabelecer cronograma de entrega dos produtos ou artefatos;

Definir os produtos (documentos ou outros artefatos) a serem entregues;

Definir a seqncia de aplicao de mtodos (em cada uma das etapas de

desenvolvimento).

2.9. UML

A UML(Unified Modeling Language) uma linguagem de modelagem visual que tem

sido adotada como padro por ser independente tanto de linguagens de
programao quanto de processos de desenvolvimento.
Esta linguagem consiste de um conjunto de notaes e semntica correspondente
para representar visivelmente uma ou mais perspectivas de um sistema por meio
dos seguintes diagramas [6]

21

Fonte [6] : Figura 6 Diagramas definidos pela UML

Os diagramas, de maneira resumida tm os seguintes objetivos:

Diagrama de Casos de uso: utilizados para auxiliar no levantamento de

requisitos, este diagrama representa em alto nvel de abstrao quais os
elementos e funcionalidades do sistema, destacando como estes interagem;

Diagrama de Classe: descrevem as classes do sistema com seus

respectivos mtodos e atributos, alm de estabelecer como estas se
relacionam;

Diagrama de Objetos: um diagrama complementar ao diagrama de classes

que fornece uma viso dos valores armazenados pelos objetos de um
diagrama de classes em um determinado momento da execuo de um
processo;

Diagrama de Interao: descreve como os grupos de objetos colaboram

entre si em um determinado momento;
o Diagrama de Sequencia: descreve como as mensagens entre os
objetos so trocadas no decorrer do tempo para a realizao de uma
operao;
o Diagrama de Colaborao: de maneira semelhante ao diagrama de
sequencia, este diagrama ilustra as interaes entre os objetos com a
diferena de que a dimenso do tempo representada por uma
numerao;

22

Diagrama de Transio de Estados: permite descrever o ciclo de vida de

objetos de uma classe, os eventos que causam a transio de um estado
para outro e a realizao de operaes resultantes;

Diagrama de Atividades: este diagrama possui notao para representar

aes concorrentes (paralelas), juntamente com sua sincronizao. Possui
como elementos: estado ao, estado atividade, estados inicial e final com
condio de guarda, transio de trmino e pontos de ramificao e unio;

Diagrama de Implementao: representa a arquitetura fsica de um sistema;

o Diagrama de Componentes: exibe os vrios componentes de
software de um sistema e suas dependncias, tais como arquivo
executvel, documento, tabela de um banco de dados, arquivo de
dados e biblioteca de objetos.
o Diagrama de Implantao: aborda a topologia fsica do sistema
apresentando um mapeamento entre os componentes de software e o
hardware utilizado pelo sistema.

3. Integrao do cho de fbrica com sistemas ERP

3.1. Introduo

A Engenharia de software uma abordagem sistemtica de tcnicas para a

produo de software tendo em vista questes prticas de custo, prazo e confiana,
assim como as necessidades dos clientes e produtores de software.[8]
No entanto, a maneira como estas tcnicas so aplicadas pode variar dependendo
de alguns fatores como a cultura da organizao responsvel pelo desenvolvimento
do software, a natureza do projeto, mtodos e ferramentas a serem usados,
controles e artefatos solicitados e tambm as pessoas envolvidas nesta atividade.

23

Deste modo, o trabalho prope a aplicao das melhores prticas da Engenharia de

Software na elaborao de um sistema MES (Manufacturing Execution System) que
dever integrar-se ao ERP (Enterprise Resource Planning) buscando oferecer
informaes proveitosas e mais precisas gesto via ERP sobre a realidade do
cho de fbrica.
Assim, este captulo visa estabelecer um processo baseado no Modelo Cascata
composto por um conjunto coerente de atividades para a elaborao do sistema
mencionado. A escolha do modelo mencionado justificada por ser o mais rgido
dentre aqueles estudados refletindo assim a criticidade do software que, para ser
construdo, exige disciplina por realizar operao de transao de estoque afetando
dessa maneira os resultados financeiros de uma empresa.
Pretende-se com este experimento criar uma metodologia de elaborao de um
software cuja finalidade integrar informaes geradas no cho de fbrica ao ERP
e, em seguida, aplicar a proposta de processo de desenvolvimento apresentada
neste trabalho.

3.1.1.

Contextualizao do ambiente corporativo

No mundo corporativo, a concorrncia motivao constante para a busca de

eficincia operacional, pois este um fator decisivo para o aperfeioamento dos
processos e maior competitividade para a sobrevivncia da empresa.
Considerando o contexto de um ambiente industrial, certamente, uma das funes
de negcio de maior destaque a produo, setor encarregado da transformao da
matria-prima em produto acabado.
Dessa maneira, alinhado ao interesse estratgico que prioriza o nvel operacional de
fbrica como diferencial competitivo diante da acirrada disputa por melhores preos
sem deixar de lado a qualidade do produto, as empresas do setor secundrio da

24

economia buscam sua excelncia operacional por meio da melhoria contnua em

seus processos.
Para comprovar se realmente houve alguma melhoria, so adotados indicadores que
devero ser verificados frequentemente, baseados nas informaes disponveis no
ERP da empresa. Como no se pode melhorar aquilo que no pode ser medido ou
verificado, essencial que se possa ter dados confiveis nos quais so baseadas as
tomadas de decises estratgicas que determinam a direo da organizao no seu
posicionamento de mercado diante de fornecedores, clientes, funcionrios, etc.
Justamente por este motivo, a tecnologia auxilia o gestor por meio de softwares
como o ERP que, integrado ao MES, acelera o fluxo de informaes, substituindo
relatrios impressos ou comunicao verbal por meios eletrnicos. Isto permite a
disponibilizao da informao on-line, diminuindo assim, o tempo de reao a
qualquer evento adverso. Da a chamada gesto em tempo real que se baseia na
tomada de decises no momento em que acontecem os eventos, pois atrasos dessa
natureza podem comprometer a estratgia corporativa.
Um exemplo disso o caso de uma indstria de autopeas que ser objeto de um
caso de estudo adiante. Uma correo do processo em tempo hbil, poderia evitar
um recall milionrio de automveis se um eventual problema fosse identificado no
momento da produo, denotando uma falha deste processo.
3.1.2.

Contextualizao do MES

Num contexto em que crescente a utilizao de sistemas ERP como forma de

integrar todos os processos de uma empresa tratando esta entidade como um todo e
no apenas os limites departamentais, faz-se necessria a utilizao de informaes
confiveis no menor tempo possvel para tomada de deciso.
Tais informaes, geralmente esto disponveis por meio do ERP que na maioria das
vezes no perfeitamente aderente aos processos no nvel operacional de fbrica.
Assim, para preencher esta lacuna, diante dessa deficincia constatada na
integrao das informaes do cho de fbrica, surgiu o conceito de MES que
dever ser o produto do processo proposto.

25

Fonte [5] : Figura 7 Contexto do MES

Diante de tantas alternativas de MES j disponveis no mercado, deve-se lembrar
que nem todas as empresas podem se beneficiar desta ferramenta, pois alm de
custos elevados que podem superar at mesmo o investimento realizado no ERP, os
processos tm suas particularidades, variando de empresa para empresa.
Por outro lado, a vantagem da integrao dos mdulos como proposto na figura
anterior, permite diagnosticar reas mais e menos eficientes para que se possa focar
em processos e ter o desempenho melhorado com a ajuda da tecnologia.
Segundo a Norma ANSI/ISA S-95.00 [3], para que se possa desfrutar dos benefcios
advindos da integrao entre sistemas de negcio e fabricao, ou seja, sistemas
corporativos (ERP) e sistemas de cho de fbrica (MES), necessria a adoo de
mtodo adequado de conexo entre ambos com algumas caractersticas, dentre

26

elas:
O mtodo deve ser completo o suficiente para lidar com a maioria das interaes
entre negcio e fabricao;
O mtodo deve separar processos de negcios dos processos de fabricao, de
modo a diminuir a complexidade da integrao.
O mtodo deve ser independente de qualquer sistema especfico de negcios e da
arquitetura do sistema de cho de fbrica.
A norma ANSI/ISA S-95.00 [3], desenvolvida e compilada pela ISA (Instrumentation
Society of America), define um modelo eficaz e padronizado para atingir esses
objetivos. Sua meta principal evitar a criao de modelos distintos de integrao
entre ERP, MES e fabricao, facilitando a comunicao entre eles com interfaces
seguras, confiveis e compatveis, alm de precisas e com rapidez de informaes.
Segundo a MESA [16], o MES pode ser justificado pelos benefcios proporcionados
tais como:

Reduo do tempo de ciclo da manufatura;

Reduo ou eliminao de entrada de dados manualmente;

Reduo do WIP;

Reduo do uso de papel;

Apoio manufatura enxuta;

Apoio melhoria contnua;

Melhora da confiabilidade do produto final (melhor qualidade);

Aumento da visibilidade das atividades relacionadas ao cho de fbrica,

assim como daquelas ligadas aos custos do processo de manufatura.

27

3.1.3.

Atividades do Projeto

O guia elaborado ao longo deste trabalho, prope uma seqncia de atividades

tendo como produtos os respectivos artefatos que ajudam a descrever o processo
de negcio bem como a arquitetura e o design do software. Tais atividades esto
relacionadas juntamente com os artefatos que devem ser produzidos ao longo de
sua execuo:

Seqncia Atividade
1

Planejamento

Artefatos Produzidos
Escopo;
Estimativa de recursos, prazos e
custo para que possa ser analisada a
viabilidade do projeto;

Levantamento de Requisitos

Diagrama BPMN;
Diagrama de Casos de Uso;

Anlise e modelagem

Diagrama de Classe;
Diagrama de Seqncia;

Projeto

Diagrama de Arquitetura do Sistema;

Diagrama de Implementao

Implementao

Sistema codificado

Verificao

Relatrio de testes

Implantao

Manuais do sistema;
Treinamentos;
Software liberado em produo

Tabela 6 - Atividades para elaborao do MS

.Para acompanhar a automao de um processo, ento primordial mape-lo e

28

document-lo. Isso facilita o seu gerenciamento, uma vez que dessa forma,
possvel obter uma viso mais clara do fluxo de atividades e dos recursos envolvidos
em tal processo.
Depois desse mapeamento, o guia proposto define quais atividades devem ser
realizadas na seqncia e determina as atividades so executadas posteriormente
alm das relaes ou dependncias entre elas; estabelece, tambm, critrios para a
transio entre tarefas como a entrega de um determinado artefato, compreendendo
o processo de desenvolvimento de software. Em outras palavras, o processo guia o
desenvolvimento desde sua concepo quando os clientes (ou usurios) expressam
quais funcionalidades (ou requisitos do sistema) eles desejam at a entrega do
produto final que consiste na elaborao do software caracterizado como
middleware.
Sendo assim, dentre os inmeros processos existentes numa empresa, adotou-se o
processo de apontamento da produo como um "case", onde dever ser aplicada a
metodologia proposta, possibilitando desse modo, sua anlise e aperfeioamento.
Para tanto, ser realizado um levantamento detalhado do processo para identificar
os responsveis, participantes e recursos envolvidos a fim de estrutur-lo e facilitar o
seu entendimento. Alm disso, assim ser possvel tambm ter uma viso detalhada
do fluxo de execuo das operaes e neste caso, se necessrio, otimizar o
processo diminuindo custos e tempo de execuo considerando-se a qualidade do
produto.

3.1.4.

Planejamento

O estouro de cronograma e oramentos parte da rotina da maioria dos

profissionais de software [19], causando enormes transtornos e prejuzos. Por isso,
visando o sucesso desse projeto, foi realizado um planejamento levando-se em
considerao variveis como: escopo, tempo e custo que formam na figura a seguir
o triangulo da gerncia de projeto.

29

Fonte [20]: Figura 10 - Tringulo da Gerncia de Projeto

Escopo desenvolvimento de um software com a finalidade de integrar

informaes (consumo da matria-prima e apontamento da produo)
geradas no cho de fbrica ao ERP.

Tempo utilizando-se da tcnica de anlise de pontos de funo, foi

estimado entre a fase de planejamento e implantao um total de 770 horas
de trabalho, mas isso depende muito da experincia dos profissionais
envolvidos.

Custo o projeto exige diferentes competncias e, baseado nisso, tomando o

valor mdio de R$ 75,00/hora de um profissional para esta tarefa, possvel
estimar o custo de recurso humano de aproximadamente R$ 57.750,00. Com
relao aos custos de hardware, isso no ser estipulado tendo em vista que
a infra-estrutura para o projeto j est disponvel para o ERP e dever
compartilhar tais recursos com este novo projeto.

Para um produto ser vivel, no basta que atenda aos requisitos desejados; tem de
ser produzido dentro de certos parmetros de prazo e custo. Se isto no for
possvel, o produto pode no ser vivel do ponto de vista de mercado, ou pode ser
prefervel adquirir outro produto, ainda que sacrificando alguns dos requisitos.
Portanto, necessrio considerar tambm o prazo e o custo como expectativas do
cliente. [19]
Esta atividade pode ser comparada, por exemplo, a um plano de negcio que nada
mais do que um documento em que dentre outras variveis, deve-se identificar a

30

misso, a viso e os valores de uma empresa antes de sua concepo para que se
possa eventualmente prevenir riscos.
Como produto desta etapa, deve-se produzir um documento onde consta o escopo
do software (requisitos) com estimativas de recursos, prazos e custo para que se
possa constatar a viabilidade do projeto.

3.1.5.

Levantamento de Requisitos

Os requisitos do middleware foram divididos em:

Funcionais: apontamento da produo, transferncia de armazm lgico da matriaprima e emisso de etiquetas de identificao de paletes;
No Funcionais: performance, disponibilidade, usabilidade etc.
A identificao destes requisitos no uma atividade to trivial como pode parecer,
pois, em geral, um problema pode ser visto por diferentes ngulos sem que se
consiga identific-lo em sua essncia para que seja solucionado. Alguns dos
obstculos mais comuns nesta tarefa so:

Cliente no sabe definir suas expectativas, ou seja, no sabe exatamente o

que deseja do software;

Rudos de comunicao ocasionados pelo meio utilizado (e-mail, telefone,

reunies, etc) ou por dificuldade de relacionamento entre o usurio e quem
realiza o levantamento. Isto causa problemas de interpretao podendo afetar
negativamente

resultado

final

com

entrega

de

um

software

completamente diferente do que se esperava;

Requisitos volteis que complicam a sequencia das etapas seguintes, pois

necessrio que se realize adequaes para acomod-los;

Alm disso, muitas informaes, por serem implcitas e por serem bvias demais
para os usurios acabam sendo omitidas. Dessa maneira, prope-se tambm o
mtodo de observao do processo para que se possa tirar dvidas ou comparar o

31

relato do usurio ao processo propriamente dito.

Outro aspecto to importante quanto o levantamento de requisitos do sistema, a
abstrao das aspiraes do usurio, pois assim, evita-se a resistncia do mesmo
quanto ao uso futuro do software. Alm disso, um levantamento de requisitos
realizado adequadamente pode evitar consequncias tais como:

mais manuteno;

mais custos;

mais tempo;

menos credibilidade;

perda de clientes, etc.

Algumas das tcnicas mais utilizadas nesta tarefa so as seguintes:

Fonte [14]: Figura 11 Tcnicas para levantamento de requisitos

Desta maneira, utilizando-se inicialmente das tcnicas tradicionais, pretende-se
obter como produto desta etapa um diagrama BPMN denominado AS IS que
representa as atividades do processo de negcio considerando-se o encadeamento
e a sequencia destas.
Em seguida, com maior entendimento do problema, se houver alguma proposio de

32

melhoria que visa deixar todo o fluxo de dados de uma forma mais eficiente, dever
ser elaborado um novo diagrama BPMN denominado AS TO BE indicando as
sugestes de melhoria.
Outro diagrama produzido ao fim desta etapa o diagrama UML de Casos de Uso
que identifica os atores que interagem com o sistema e quais so suas atribuies.

3.1.6.

Anlise e modelagem do software

Tendo-se os diagramas gerados como artefatos da etapa anterior, neste estgio ser
realizado um estudo detalhado dos requisitos levantados. A partir desse estudo,
sero construdos modelos para representar simplificadamente o sistema a ser
construdo, pois dessa maneira, possvel delimitar o problema estudado, dividindoo em vrios problemas menores, restringindo a ateno um nico aspecto por vez
at chegar soluo. [21]
Dessa maneira, dentre as tcnicas de modelagem, considerando-se os tipos de
modelos definidos (objetos, dinmico e funcional) [21], no processo de software
proposto, adotou-se o diagrama de classes (modelo de objetos) que descreve a
esttica de um sistema representado por suas classes e relacionamentos entre si.
Alm disso, como artefato desta etapa, tambm dever ser produzido o diagrama de
seqncia (modelo dinmico) que representa a colaborao das classes por meio de
troca de mensagens ao longo do tempo.
E para que o problema seja completamente definido, tais diagramas devem ser
validados e verificados junto aos stakeholders responsveis por meio de
documentos de aceitao assinados por estes. Assim, pode-se assegurar que as
necessidades do cliente esto sendo atendidas pelo sistema e tambm que os
modelos construdos esto em conformidade com os requisitos definidos. [6]

3.1.7.

Projeto

33

Nesta fase, determina-se como o sistema funcionar para atender aos requisitos,
fornecendo as diretrizes para a transio do domnio da aplicao para o domnio da
soluo, conforme ilustra a figura a seguir.

Fonte [17]: Figura 12 Viso geral da atividade de projeto

Assim, foram considerados os recursos tecnolgicos existentes a fim de aproveitar
toda infra-estrutura j existente para suportar o ERP, tais como servidores, bancos
de dados, rede, etc.
Diante disso, no contexto tecnolgico, foram tomadas as seguintes decises:

Arquitetura do sistema: o sistema ser construdo com base na arquitetura

cliente/servidor divido em camadas de modo a facilitar a manuteno do
mesmo. Neste aspecto, inclusive, deve-se levar em conta a granularidade do
mesmo visando sempre um grau de acoplamento que seja razovel;

Linguagem de Programao: ser adotado como o Visual C# verso 4.0 da

Microsoft como linguagem de programao sobre a plataforma Windows por
ser uma linguagem um tanto quanto fcil, permitindo assim, um menor tempo

34

de implementao;
Gerenciador de Banco de Dados: para gravar informaes complementares
ao MES como etiquetas impressas, cadastro de usurios, etc. ser
compartilhado o SGBD do prprio ERP, pois assim, no haver custo de
licena neste requisito. No entanto, por questes de segurana, integridade e
at mesmo melhor organizao das informaes, ser criada uma nova base
de dados separada para uso exclusivo do MES.
Por fim, nesta fase, ser utilizado o diagrama de implementao da UML como
artefato para ilustrar os ns do sistema. Alm disso, ser apresentado tambm o
diagrama de arquitetura do sistema que d uma viso da distribuio dos recursos
de hardware utilizados em de como eles esto conectados.

3.1.8.

Implementao

Esta fase consiste basicamente na codificao do software que pode ser explicada
como a traduo da descrio computacional da fase de projeto em cdigo
executvel utilizando-se para isso de uma ou mais linguagens de programao.[6]
Desse ponto de vista, luz da programao orientada a objetos, a soluo dever
ser dividida em classes que devero ser instanciadas ao longo da execuo do
software.
Na elaborao de tais classes, consideradas artefatos bsicos desta etapa,
importante pensar nas questes relacionadas legibilidade, facilidade de alterao e
reutilizao. Por isso, tendo em vista que, num trabalho em equipe haja a
necessidade de integrar, testar e alterar cdigo produzido pelos integrantes desta
equipe, importante o estabelecimento de padres organizacionais para a fase de
implementao. Foram adotados como boa prtica os seguintes padres:

Nomes de variveis: o primeiro nome deve ser todo em letras minsculas e os

termos seguintes iniciam com maiscula.Ex: minhaNovaVariavel;

Nomes de constantes: inteiramente em maisculas. Ex: PI;

35

Mtodos: iniciam com verbo no infinitivo. Ex: apontarProducao;

Classes: em geral, seus nomes so formados por substantivos ou adjetivos.

Ex: ListaMaterial;

Interfaces: idem classes;

Como produto desta fase, deve-se obter o software codificado de acordo com os
padres definidos.

3.1.9.

Verificao

Testar o software uma maneira de verificar e validar o seu funcionamento. Desse

modo, depois de implementado o cdigo de uma aplicao, deve-se test-la
levando-se em conta a especificao feita na fase de projeto. Assim, ser possvel
detectar defeitos e corrigi-los antes mesmo da entrega ao cliente.
Desta maneira, o middleware desenvolvido dever ser verificado ao longo cada fase
e, somente depois de comprovado por meio de um documento assinado ou mesmo
um e-mail do stakeholder responsvel, ser autorizado o prosseguimento para a
fase seguinte.
No caso de deteco de uma falha cometida numa etapa anterior, conforme a figura
do item 3.2, o processo dever retomar da etapa inicial que o planejamento, pois
possvel que a falha detectada cause impactos no previstos inicialmente. E assim,
o processo reiniciado.

3.1.10.

Implantao

A instalao do software no ambiente do usurio no meramente uma formalidade

[17], pois se faz necessrio a elaborao da documentao que dever ser utilizada
como material de referncia para a soluo de problemas ou como informaes

36

adicionais. Dentre os documentos que podem acompanhar o sistema, destacam-se:

manual do usurio, tutoriais, ajuda (help).
Dessa maneira, faz parte da implantao tambm o treinamento do usurio. Caber,
assim, a um membro da equipe envolvida no processo treinar alguns usurios
denominados usurios-chave que devero ser escolhidos estrategicamente dentre
o pblico alvo do software. Por exemplo: pode-se escolher um usurio de cada turno
para ser treinado, restringindo assim o trabalho deste membro da equipe do
processo.
Estes usurios-chave devero por sua vez replicar o conhecimento adquirido
dentre seus pares para que todos conheam as funcionalidades do MES. E, no caso
de qualquer problema, o usurio-chave ser o ponto de contato entre os demais
usurios e a equipe responsvel pela manuteno do software.

3.2. Experimentao

Esta seo, discorrer sobre a experincia da aplicao da metodologia proposta

(processo de software) que consiste na execuo das fases descritas anteriormente.
Desse modo, no contexto de uma indstria de manufatura discreta, levando-se em
considerao o seu grau de importncia dentro do negcio, foi escolhido o processo
referente ao apontamento da produo que tem impacto direto sobre as
movimentaes de estoque.
Neste caso especfico, para contextualizar, o ERP utilizado o BPCS (Business
Planning and Control System) cuja implementadora a System Software Associates
(SSA). Sendo assim, assumindo que os processos internos deste ERP so
conhecidos pela equipe que dever desenvolver o software de integrao, as
interfaces ilustradas na Figura 9 devero acessar diretamente a base de dados (IBM
DB2) do ERP para efetuar a operao de apontamento. Isto envolve transaes de
estoque entre os armazns que sero tratadas via comandos SQL (Structured Query
Language).

37

3.2.1.

Planejamento

Para a realizao do planejamento, deve-se levar em considerao diversos

aspectos como a experincia dos profissionais envolvidos no projeto, experincias
de projetos anteriores, ferramentas disponveis de hardware e software, etc.
De qualquer maneira, no caso de aplicao, a estimativa para a realizao de cada
uma das tarefas consta na tabela abaixo:

Atividade

Tempo estimado em horas/pessoa

Planejamento

40

Levantamento de Requisitos

120

Anlise e modelagem

80

Projeto

80

Implementao

300

Verificao

100

Implantao

50

TOTAL

770
Tabela 7 - Estimativa de horas

Partindo da estimativa de horas, para estimar o custo, basta multiplicar o total de

horas pelo valor/hora de cada profissional de acordo com a respectiva tarefa na qual
est alocado.
Foi tomada a deciso de continuidade do projeto tendo em vista que este se mostrou
economicamente vivel em virtude de seu custo compensar os prejuzos causados
pelo gap de informao entre o cho de fbrica e o ERP (que disponibiliza a
informao aos gestores) devido a ajustes de inventrio, eventuais multas
contratuais ocasionadas por atrasos de produo, estoque desnecessrio, etc.

38

3.2.2.

Levantamento de Requisitos

Nesta fase foram utilizadas as mais tradicionais tcnicas de levantamento de

requisitos, conforme Figura 11. Dessa maneira, aps uma srie de reunies com a
finalidade de entender o problema da perspectiva do usurio, foram levantados os
requisitos tomando-se como principais ferramentas para esta tarefa a aplicao de
questionrios, entrevistas, observao e anlise de documentos, etc.
Assim, tendo sido realizado o levantamento de requisitos, para confirmar o
entendimento do cenrio atual com suas atividades e os respectivos responsveis,
utilizando-se da BPMN, foi elaborado um diagrama que representa o processo de
negcio escolhido AS IS.

Figura 13 BPMN AS IS
Esse diagrama ento utilizado como uma ferramenta de comunicao entre os
"stakeholders" que devem, neste momento, discuti-lo e identificar gargalos ou
possveis tarefas que possam ser suprimidas ou otimizadas. Aps esta discusso,

39

um novo diagrama com as possveis melhorias elaborado. Tal diagrama

denominado AS TO BE.

Figura 14 BPMN AS TO BE
Para a construo do cenrio AS TO BE, ilustrado na figura acima,

imprescindvel ter uma boa comunicao com os stakeholders responsveis pelo

fornecimento de informaes. Isto permite otimizar o processo de negcio e elaborar
assim, um software que seja aderente aos anseios do cliente, reduzindo-se uma
eventual possibilidade de rejeio ao mesmo. E o processo otimizado
representado na figura acima.
Com uma projeo do cenrio proposto, foram construdos os diagramas de caso de
uso onde se ilustram os atores do sistema e suas funcionalidades.

40

Figura 15 Casos de Uso

41

A seguir, uma breve descrio dos casos de uso ilustrados:

Nmero do Caso de Uso

Nome do Caso de Uso

Transferir material para produo

Ator

Usurio que trabalho no almoxarifado

Descrio

Movimenta a matria-prima no estoque de acordo

com o seu deslocamento fsico para o armazm de
produo

Pr-condies

Deve haver matria-prima suficiente para a produo

da ordem de produo

Ps-condies

Registro da transao de transferncia

Cenrio Principal

1.Usurio consulta no ERP as ordens de

produo(OP) do dia;
2.De acordo com a classificao das OPs j
programadas, o usurio separa a matria-prima que
ser consumida em cada ordem;
3.O material enviado ento linha de produo e
correspondentemente sua movimentao fsica,
tambm realizada uma movimentao lgica do
estoque;
Tabela 8 - Caso de Uso 1

Nmero do Caso de Uso

42

Nome do Caso de Uso

Apontar produo

Ator

Linha de Produo (LP)

Descrio

A cada palete preenchido, a linha de montagem envia

a informao ao ERP indicando a adio de produto
acabado no estoque.

Pr-condies

Produo correspondente a um palete

Ps-condies

Criao de um novo produto com o consumo da

matria-prima

Cenrio Principal

1.LP recebe a matria-prima e ordem a ser

executada;
2.A medida em que os produtos da OP so
finalizados, LP conta-os at que preencham um
palete;
3.Com a quantidade suficiente para preencher o
palete, uma transao de estoque lana a quantidade
produzida no sistema ERP dando baixa na matriaprima consumida simultaneamente. Em paralelo, uma
etiqueta para identificao deste palete, ser emitida.
4.Passo 1 at finalizao da OP;
Tabela 9 - Caso de Uso 2

43

3.2.3.

Anlise e Modelagem

Como forma de representar uma soluo que seja mais facilmente compreendida,
esta foi dividida em classes e devidamente representada pelo respectivo diagrama
UML.

Figura 16 Diagrama de Classes MES

E para demonstrar a colaborao entre as classes, foi construdo o diagrama de

sequencia:

44

Figura 17 Diagrama de Sequencia MES

3.2.4.

Projeto

No projeto, foram definidos os seguintes aspectos:

Projeto da Arquitetura do Software: foi definido que o software dever ser

codificado em camadas para facilitar futuras manutenes;

Projeto de Dados: dado persistido pelo software ser a etiqueta impressa ao

final do processo de apontamento da produo;

Projeto de Interfaces: como interface interna, foi estabelecido uma classe que
persiste informaes no ERP, considerando-se que o banco de dados
utilizado por este software conhecido. Do mesmo modo, estabeleceu-se
tambm que deve haver uma classe de leitura do mesmo banco de dados
para que o MS obtenha as informaes necessrias sua execuo.

Abaixo tem-se um diagrama da arquitetura do sistema ilustrando os elementos de

hardware que o compem .

45

Figura 18 Diagrama de Arquitetura do Sistema

46

Outro artefato produzido nesta fase o diagrama de implantao que representa a

topologia fsica do sistema

Figura 19 Diagrama de Implantao

3.2.5.

lmplementao

Adotou-se nesta fase a IDE (Integrated Development Environment) da Microsoft

denominada Visual Studio 2010. Alm disso, o software foi desenvolvido sob o .NET
Framework 4.0 do mesmo fornecedor.
A escolha de tal ferramenta justifica-se pela experincia da equipe envolvida no
projeto que considerou uma ferramenta extremamente intuitiva e de fcil
aprendizado. No entanto, existem alternativas de mercado, como por exemplo, a
plataforma Java.
O artefato desta etapa o cdigo-fonte do software.

47

3.2.6.

Verificao

medida que o software elaborado ao longo das etapas descrita no processo

proposto, verificaes pontuais foram realizadas a fim de minimizar a propagao de
eventuais falhas para fases posteriores.
E nesta fase, apesar de todo o trabalho de planejamento, levantamento de
requisitos, etc, foram detectados erros de implementao que foram imediatamente
corrigidos. Tais erros eram provenientes basicamente por falta de entendimento
entre o que se esperava do sistema e o que foi entregue. Parece que o usurio no
sabe exatamente o que quer ou no sabe explicar ou ainda: o analista no soube
entender. Enfim, a comunicao mostrou-se essencial para que falhas possam ser
previstas e no corrigidas.
Como artefatos,

so esperados nesta etapa documentos de validao das

funcionalidades de acordo com os requisitos levantados no inicio do processo.

Dentre os documentos, constam e-mails que comprovam a aceitao dos usurios
responsveis pela verificao.

3.2.7.

Implantao

O sistema finalmente foi entregue ao solicitante (cliente) para que possa usufruir os
benefcios proporcionados.

Mas antes mesmo da entrega, foram escolhidos os

usurios-chave que, em sua maioria so os mesmos que participaram dos processo

fornecendo informaes durante o levantamento de requisitos ou validando o que
tinha sido feito em cada uma das etapas antes de passar s seguintes.
Aps ter sido colocado em produo, o software mostrou-se extremamente til e
obteve alto ndice de aceitao em diferentes nveis hierrquicos o que comprova a
eficcia do processo proposto.
No entanto, como qualquer sistema, o seu ciclo de vida no terminou aqui, pois
imediatamente comearam a surgira novas sugestes para sua melhoria gerando

48

uma demanda por manuteno do programa. Uma das sugestes, inclusive, foi a
apresentao dos dados processados por meio de uma interface.
Outra sugesto foi o desenvolvimento de um middleware, que nada mais do que
uma camada de software, neste caso, intermediria entre o cho de fbrica e o ERP,
similar para atender uma linha de produo de outra filial da empresa que apresenta
os mesmos problemas.

3.3. Anlise de resultados

Neste captulo, aps a apresentao do processo de software proposto e sua

aplicao num caso prtico, foi possvel perceber a importncia de cada uma das
fases em que foi dividida a tarefa de elaborao do MES e seus respectivos
artefatos produzidos.
Pois o processo elaborado um guia de referncia que situa os envolvidos no
projeto, dando a idia no somente do status atual, mas tambm do que ser feito
adiante, ou seja, como se fosse uma receita de bolo que norteia os esforos para
atingir um fim.
Dessa maneira, os resultados certamente comprovam a vantagem de um
middleware como este que realiza a integrao entre o cho de fbrica e a rea
corporativa diminuindo assim o vcuo de informao existente entre tais reas
aumentando assim a vantagem competitiva do negcio.
Como principais resultados, pode-se destacar:

Reduo do tempo total de manufatura em pelo menos 20%, uma vez que a
tarefa de apontamento cabe ao sistema e no mais a um funcionrio;

Maior confiabilidade nos dados disponveis no ERP, uma vez que estes no
so mais preenchidos mo, o que ocasionava distores seja por confuses
relacionadas caligrafia, seja por falta de ateno no momento em que se
anotava os dados. Enfim, o processo substituiu de maneira mais eficiente a
interao humana responsvel por fornecer dados do cho de fbrica que,

49

agora, alm de mais confiveis so disponibilizados em poucos segundos,

dependendo da disponibilidade da rede utilizada, claro.

Baseado em informaes mais confiveis, possvel saber com maior

preciso a quantidade de itens produzidos disponveis em estoque. Dessa
forma, a produo pode ser melhor gerenciada, pois dada uma ordem de
produo ser possvel produzir, por exemplo, somente a quantidade
complementar disponvel em estoque para atender quela que foi solicitada.

Melhoria na qualidade do produto, uma vez que o foco do operrio volta-se

produo, eliminando-se o tempo de parada para anotar em papel a
produo.

Rastreabilidade do produto por meio de identificao com etiquetas com

maior quantidade de informaes como a data e hora da produo,
funcionrio que produziu, numerao de lote, etc. Essa foi uma melhoria bem
visvel se compararmos s etiquetas padro anteriores que continham
simplesmente a identificao do item e a quantidade contida no palete que
tambm era padronizada.

Por outro lado, uma vez que o processo aborda tcnicas dos Modelos em Cascata e
Incremental, as desvantagens destas metodologias podem tambm ser detectadas
no processo proposto, tais como: dificuldades em acomodar mudanas de requisitos
e falta de flexibilidade devido diviso de estgios bem definidos.

50

4. Concluso

O processo proposto mostrou-se satisfatrio de maneira geral, pois assim foi

possvel estruturar e disciplinar a tarefa do desenvolvimento de software, tornando-a
mais organizada e menos sujeita a riscos seja de cronograma, oramento, etc.
Problemas anteriores como a m gesto do projeto que gerava dvidas sobre o seu
status ao longo da execuo, requisitos mal definidos e completamente
desnecessrios ou mesmo contraditrios s expectativas dos usurios, puderam ser
detectados antes mesmo que se comeasse a codificar o software. Isto muitas
vezes s acontecia quando o projeto j estava muito avanado, o que tornava o
custo das mudanas extremamente altos em virtude do impacto causado sobre o
projeto como um todo.
Por exemplo, uma vez detectado um defeito num mdulo, poderia no ser suficiente
corrigir este nico mdulo, ou seja, nem sempre se tratava de uma correo pontual,
pois a dependncia entre as funcionalidades do software poderia tornar a correo
bem mais complexa do que poderia parecer.
Outra vantagem do processo, certamente, foi a obteno de artefatos que no s
serviram como documento essencial para o entendimento do problema a ser
resolvido, mas tambm como uma linguagem de comunicao visual por meio dos
diagramas que podem facilmente ser entendidos at mesmo por pessoas no
atreladas atividade tcnica. Dessa maneira, essas pessoas puderam participar do
processo ativamente, dar suas opinies e sugestes reduzindo assim uma possvel
reduo na rejeio do software entregue.
Assim, os artefatos produzidos numa etapa, so essenciais para o perfeito
entendimento desta e tambm para o desenvolvimento da prxima; e assim
sucessivamente.
Conclui-se portanto que o uso deste processo de software proposto atende os
objetivos propostos, pois oferece uma metodologia de trabalho guiada por boas
prticas e alinhada s recomendaes da associaes voltadas a este tipo de
soluo como a MESA. Alm disso, estabelece um padro que orienta os esforos
de maneira a se obter um MES que seja a melhor soluo para o problema

51

proposto.
Deste modo, segue como sugesto para futuros estudos:
1) Estudos de vantagens e desvantagens dos MES disponveis no mercado
dependendo do escopo e do oramento do projeto, no vale a pena reinventar a
roda no caso de haver uma soluo que atenda demanda disponvel no mercado.
Para isso importante conhecer quais so estas opes e suas respectivas
vantagens e desvantagens para que se possa tomar uma deciso mais
fundamentada;
2) Interfaces de comunicao para atualizao de dados no ERP diante das
diversas opes tanto de ERPs quanto de SGBDs disponveis no mercado, um
produto de software que realizasse a integrao entre estas duas instncias de
maneira padronizada seria muito vantajosa do ponto de vista prtico.

52

5. Referncias bibliogrficas

[1] SOMMERVILLE, Ian. Engenharia de Software 9 edio. So Paulo: Pearson,

2011.
[2] MARDEGAN, Ronaldo & MARTINS, Vinicius & OLIVEIRA, Joo Fernando
Gomes. Estudo da integrao entre sistemas scada, mes e erp em empresas de
manufatura discreta que utilizam processos de usinagem. XXIII Encontro Nac. de
Eng.
de
Produo.
In:
http://www.abepro.org.br/biblioteca/ENEGEP2003_TR0101_1570.pdf, 01/02/2012
[3] Norma Enterprise-Control System Integration Part 1: Models and Terminology ANSI/ISA S-95.00.01-2000, ISA (Instrumentation Society of America), julho/2000
[4]

Sistema
Integrado
de
Gesto
Empresarial.
http://pt.wikipedia.org/wiki/Sistema_integrado_de_gest%C3%A3o_empresarial,
10/02/2012

In:

[5] GIUNCHETTI, Frederico Frana. Coordenao de projetos para implementao

de sistemas MES. 2004. 71p. Ps-graduao em engenharia eltrica Universidade
Federal de Itajub, Itajub
[6] BEZERRA, Eduardo. Princpios de Anlise e Projeto de Sistemas com UML.
Rio de Janeiro: Elsevier, 2007
[7] SOUZA, Srgio Alexandre & ZWICKER, Ronaldo. Ciclo de Vida de Sistemas
ERP. Caderno de Pesquisas em Administrao, So Paulo, ano 1, n 11, p. 46 57,
mar. 2000
[8] Filho, Antnio Mendes da Silva. Natureza do software e a necessidade de
princpios e processos. Engenharia de Software, Rio de Janeiro, v. 3, n. 25, p. 6-12,
2010
[9]

Desenvolvimento
Iterativo
e
Incremental.
In:
http://pt.wikipedia.org/wiki/Desenvolvimento_iterativo_e_incremental, 22/02/2012
[10]

ERP
(Enterprise
Resource
Planning).
http://www.ligueinfomusic.com.br/informaticaerpjp.htm, 19/02/2012

In:

[11] CHIAVENATO, Idalberto. Introduo teoria geral da administrao. So

Paulo: Editora Campus, 2003.
[12] Mesa International. In: http://www.mesa.org, 02/02/2012
[13] Business Process Management Initiative. In: http://www.bpmi.org, 04/02/2012

53

[14] MORAES, Janaina Bedani Dixon. Introduo a abordagens de identificao de

requisitos. In: Engenharia de Software Magazine. Ano 1, Vol 2, pags: 54-58
[15] JOAQUIM, Ricardo Cezar. Novas Tecnologias para comunicao entre o Cho
de Fbrica e o Sistema Corporativo. Dissertao de Mestrado. So Carlos:
Universidade de So Paulo, 2006.
[16] MESA International (1994), The Benefits of MES: A Report from the Field,
MESA International, Pittsburg, PA, 1994
[17]

FALBO,
Ricardo
Almeida.
Engenharia
de
Software.
http://www.inf.ufes.br/~falbo/download/aulas/es-g/2005-1/NotasDeAula.pdf,
28/02/2012

In:

[18] PRESSMAN, Roger S. Engenharia de Software 6 edio. So Paulo:

McGraw-Hill, 2006
[19] FILHO, Wilson de Pdua Paula. Engenharia de Software Fundamentos,
Mtodos e Padres 3 edio. So Paulo: LTC, 2009
[20] Gerente X Capataz. In: http://qualidadebr.wordpress.com/category/gerenciade-projetos/, 10/02/2012
[21]

ESPNDOLA,
Evandro
Camarini.
http://www.linhadecodigo.com.br/artigo/1293/a-importancia-do-modelagem-deobjetos-no-desenvolvimento-de-sistemas.aspx, 28/02/2012

In: