ads:
ESTUDO DE CONCEITOS E TÉCNICAS DE MODELAGEM DE EMPRESAS:
PROPOSTA DE UMA ARQUITETURA DE REFERÊNCIA PARA O ERP5.
C
ARLOS MAGNO FERREIRA DA SILVA
U
NIVERSIDADE ESTADUAL DO NORTE FLUMINENSE – UENF
CAMPOS DOS GOYTACAZES – RJ
MARÇO DE 2006
I
ads:
Livros Grátis
http://www.livrosgratis.com.br
Milhares de livros grátis para download.
ESTUDO DE CONCEITOS E TÉCNICAS DE MODELAGEM DE EMPRESAS:
PROPOSTA DE UMA ARQUITETURA DE REFERÊNCIA PARA O ERP5.
C
ARLOS MAGNO FERREIRA DA SILVA
Dissertação submetida ao corpo docente do
Centro de Ciência e Tecnologia da
Universidade Estadual do Norte Fluminense,
como parte das exigências necessárias para
obtenção do grau de Mestre em Ciências de
Engenharia, na Área de Concentração de
Engenharia de Produção.
Orientador: Prof. Renato de Campos, DSc.
CAMPOS DOS GOYTACAZES – RJ
MARÇO DE 2006
II
ads:
ESTUDO DE CONCEITOS E TÉCNICAS DE MODELAGEM DE EMPRESAS:
PROPOSTA DE UMA ARQUITETURA DE REFERÊNCIA PARA O ERP5.
C
ARLOS MAGNO FERREIRA DA SILVA
Dissertação submetida ao corpo docente do
Centro de Ciência e Tecnologia da
Universidade Estadual do Norte Fluminense,
como parte das exigências necessárias para
obtenção do grau de Mestre em Ciências de
Engenharia, na Área de Concentração de
Engenharia de Produção.
Aprovada em 07/03/06
Comissão Examinadora
____________________________________________________
Prof. Renato de Campos, D.Sc. – UNESP.
____________________________________________________
Prof. Rogério Atem de Carvalho, D.Sc. – CEFET Campos.
____________________________________________________
Prof. Geraldo Galdino de Paula Júnior, D.Sc. – UENF.
____________________________________________________
Prof. Dalessandro Soares Vianna, D.Sc. – UCAM Campos.
III
AGRADECIMENTOS
À minha família, especialmente a meus pais,
pelo amor e dedicação.
A todos os amigos que desde longa data
sempre se fizeram presentes não só nas
horas de festa, mas também nos momentos
mais difíceis dessa caminhada, em especial
ao Thiago Duarte.
A todos os mestres e professores da
Universidade Estadual do Norte Fluminense
que participaram dessa caminhada, em
especial ao meu orientador D.Sc. Prof.
Renato de Campos, pela competência,
incentivo e amizade no decorrer não só da
elaboração desta dissertação, como em toda
essa jornada acadêmica.
E a todos aqueles que direta ou
indiretamente prestaram sua parcela de
contribuição na elaboração deste trabalho.
IV
SUMÁRIO
LISTA DE TABELAS .................................................................................................... VIII
LISTA DE FIGURAS E QUADROS .................................................................................... IX
CAPÍTULO 1 - INTRODUÇÃO ............................................................................................1
1.1. CONTEXTO......................................................................................................1
1.2. OBJETIVO.......................................................................................................4
1.3. JUSTIFICATIVA ................................................................................................4
1.4. ESTRUTURA DA DISSERTAÇÃO .........................................................................5
CAPÍTULO 2 - SISTEMAS DE INFORMAÇÃO E O ERP 5.......................................................7
2.1. SISTEMAS DE INFORMAÇÃO..............................................................................7
2.2. ERP...............................................................................................................8
2.3. ERP5...........................................................................................................11
2.3.1. DEFINIÇÃO ........................................................................................................11
2.3.2. CARACTERÍSTICAS ESPECÍFICAS DO ERP5....................................................12
2.3.3. CARACTERÍSTICAS INOVADORAS.....................................................................13
2.3.3.1. VARIAÇÕES PARA CUSTOMIZAÇÃO DE MASSA........................................13
2.3.3.2. META-ERP PARA META-PLANEJAMENTO ..............................................14
2.3.3.3. SINCRONIZAÇÃO.......................................................................................14
2.3.4. ARQUITETURA DO ERP5..................................................................................15
2.3.5. VARIAÇÕES NA ARQUITETURA DO ERP5........................................................16
2.3.6. TRANSFORMAÇÕES NA ARQUITETURA DO ERP5...........................................16
2.3.7. MOVIMENTOS E PEDIDOS (MOVEMENTS E ORDERS) ......................................17
2.3.8. PLANEJAMENTO DO CAMINHO (PATH PLANNING) ..........................................17
2.3.9. NÓS E META-NÓS (NODES E META-NODES) ...................................................18
2.3.10. CAPACIDADE (CAPACITY)............................................................................18
2.3.11. META-NÓS (META-NODES): AGREGAÇÃO DE NÓS (NODES)......................18
2.3.12. S
IMULANDO O FUTURO.................................................................................19
2.3.13. P
ERFIL ..........................................................................................................19
2.3.14. U
SANDO E EXTENDENDO A INFRAESTRUTURA ZOPE..................................19
2.3.15. WORKFLOWS................................................................................................20
2.4. C
ONSIDERAÇÕES FINAIS ................................................................................21
CAPÍTULO 3 - DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÕES .................................22
3.1. INTRODUÇÃO.................................................................................................22
3.2. UP (UNIFIED PROCESS).................................................................................23
3.2.1. O QUE É O UP?................................................................................................23
3.2.2. CARACTERÍSTICAS DO UP ...............................................................................25
3.2.2.1. PROCESSO ORIENTADO POR CASO DE USO............................................25
3.2.2.2. PROCESSO CENTRADO EM ARQUITETURA ..............................................25
3.2.2.3. P
ROCESSO ITERATIVO E INCREMENTAL ..................................................26
3.2.3. O
CICLO DE VIDA .............................................................................................27
3.2.4. I
TERAÇÕES .......................................................................................................27
3.2.5. F
ASES...............................................................................................................29
3.2.5.1. CONCEPÇÃO.............................................................................................29
3.2.5.2. ELABORAÇÃO...........................................................................................30
3.2.5.3. CONSTRUÇÃO...........................................................................................32
3.2.5.4. TRANSIÇÃO...............................................................................................33
V
3.2.6. WORKFLOWS....................................................................................................34
3.2.6.1. REQUISITOS..............................................................................................34
3.2.6.2. ANÁLISE....................................................................................................35
3.2.6.3. PROJETO ..................................................................................................36
3.2.6.4. IMPLEMENTAÇÃO......................................................................................36
3.2.6.5. TESTE .......................................................................................................37
3.3. RUP (RATIONAL UNIFIED PROCESS) ..............................................................37
3.4. UML............................................................................................................40
3.5. CONSIDERAÇÕES FINAIS ................................................................................44
CAPÍTULO 4 - MODELAGEM DE EMPRESAS E ARQUITETURAS DE REFERÊNCIA..................45
4.1. MODELAGEM E INTEGRAÇÃO DE EMPRESAS ....................................................45
4.2. ARQUITETURAS DE REFERÊNCIA ....................................................................46
4.2.1. TRABALHOS DE PADRONIZAÇÃO NA ISO........................................................48
4.2.2. CEN
ENV 40003.............................................................................................50
4.2.3. GIM
– GRAI INTEGRATED METHODOLOGY ....................................................50
4.2.4. PERA...............................................................................................................54
4.2.5. ARIS.................................................................................................................56
4.2.6. CIMOSA..........................................................................................................56
4.2.6.1.1. INFRA-ESTRUTURA DE INTEGRAÇÃO...................................................58
4.2.6.1.2. ESTRUTURA DE MODELAGEM CIMOSA.............................................59
4.2.6.1.3. CICLO DE VIDA DA EMPRESA ..............................................................61
4.2.6.2. PROCESSO DE MODELAGEM CIMOSA...................................................61
4.2.6.3. LINGUAGEM CIMOSA .............................................................................64
4.2.7. GERAM – ARQUITETURA DE REFERÊNCIA E METODOLOGIA GENERALIZADA
DE
EMPRESA.....................................................................................................................67
4.2.7.1. DEFINIÇÃO DOS COMPONENTES DA ESTRUTURA GERAM....................70
4.2.7.1.1. GERA – ARQUITETURA DE REFERÊNCIA DE EMPRESAS GENÉRICA 71
4.2.7.1.2. EEMS - METODOLOGIA DE ENGENHARIA DE EMPRESAS ..................71
4.2.7.1.3. EMLS – LINGUAGENS DE MODELAGEM DE EMPRESAS.....................71
4.2.7.1.4. GEMCS - CONCEITOS GENÉRICOS DE MODELAGEM DE EMPRESAS 72
4.2.7.1.5. PEM
S - MODELOS PARCIAIS DE EMPRESAS......................................72
4.2.7.1.6. EETS - FERRAMENTAS DE ENGENHARIA DE EMPRESAS ...................73
4.2.7.1.7. EMS - MODELOS DE EMPRESAS (PARTICULAR) ................................73
4.2.7.1.8. EMO
S - MÓDULOS DE EMPRESA........................................................74
4.2.7.1.9. EOSS - SISTEMAS OPERACIONAIS DE EMPRESAS (PARTICULAR)....74
4.3. C
ONSIDERAÇÕES FINAIS................................................................................74
C
APÍTULO 5 - PROPOSTAS METODOLÓGICAS PARA O ERP5...........................................76
5.1. INTRODUÇÃO.................................................................................................76
5.2. ARQUITETURA DE REFERÊNCIA ......................................................................77
5.3. METODOLOGIA DE MODELAGEM .....................................................................79
5.4. LINGUAGEM DE MODELAGEM .........................................................................80
5.5. CONCEITOS GENÉRICOS DE MODELAGEM DE EMPRESA ...................................83
5.6. MODELOS PARCIAIS DE EMPRESA ..................................................................85
5.7. FERRAMENTAS DE ENGENHARIA DE EMPRESA.................................................87
5.8. MÓDULOS DE EMPRESA.................................................................................89
5.9. M
ODELOS DE EMPRESA.................................................................................89
5.10. S
ISTEMAS OPERACIONAIS DE EMPRESA..........................................................90
5.11. CONSIDERAÇÕES FINAIS................................................................................90
VI
CAPÍTULO 6 - PROPOSTAS PARA UMA METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS
ERP BASEADA NA GERA............................................................................................91
6.1. INTRODUÇÃO.................................................................................................91
6.2. GERA – ARQUITETURA DE REFERÊNCIA DE EMPRESA GENERALIZADA.............92
6.2.1. CONCEITOS ORIENTADOS A PROCESSO ..........................................................92
6.2.2. CICLO DE VIDA ..............................................................................................93
6.2.3. FASES DO CICLO DE VIDA DE GERA ..............................................................93
6.2.3.1. FASE DE IDENTIFICAÇÃO DA ENTIDADE ....................................................93
6.2.3.2. FASE DE CONCEITO DA ENTIDADE ...........................................................93
6.2.3.3. FASE DE REQUISITOS DA ENTIDADE.........................................................94
6.2.3.4. FASE DE PROJETO DA ENTIDADE.............................................................94
6.2.3.5. FASE DE IMPLEMENTAÇÃO DA ENTIDADE .................................................95
6.2.3.6. FASE DE OPERAÇÃO DA ENTIDADE..........................................................95
6.2.3.7. FASE DE RETIRADA DA ENTIDADE............................................................95
6.3. ATIVIDADES PROPOSTAS ...............................................................................96
6.4. WORKFLOW PARA MODELAGEM DE NEGÓCIO..................................................98
6.5. W
ORKFLOW DE LEVANTAMENTO DE REQUISITOS...........................................101
6.6. W
ORKFLOW DE ANÁLISE E PROJETO............................................................104
6.7. METODOLOGIA PROPOSTA...........................................................................107
6.7.1. ABORDAGENS NA FASE DE IDENTIFICAÇÃO DA ENTIDADE...............................109
6.7.2. ABORDAGENS NA FASE DE CONCEITO DA ENTIDADE......................................109
6.7.3. ABORDAGENS NA FASE DE REQUISITOS DA ENTIDADE ...................................110
6.7.4. ABORDAGENS NA FASE DE PROJETO PRELIMINAR.........................................111
6.8. CONSIDERAÇÕES FINAIS..............................................................................113
CAPÍTULO 7 - CONCLUSÕES .......................................................................................114
REFERÊNCIAS BIBLIOGRÁFICAS..................................................................................117
ANEXO I....................................................................................................................123
VII
LISTA DE TABELAS
Tabela 4.1. Modelo de produção do chão de fábrica........................................................ 48
Tabela 4.2. Estrutura de Modelagem GIM........................................................................ 52
Tabela 5.1. Exemplos de utilização do gabarito para Recurso como Entidade Funcional 83
VIII
LISTA DE FIGURAS E QUADROS
Figura 1.1. Componentes da estrutura de GERAM.......................................................... 3
Figura 2.1. Estrutura conceitual dos sistemas ERP, e sua evolução desde o MRP......... 11
Figura 2.2. As Cinco Tecnologias Inovadoras do ERP5................................................... 13
Figura 2.3. Classes do Núcleo do ERP5 .......................................................................... 16
Figura 3.1. O “Gráfico de Baleias” (Adaptado de RUP, 2002).......................................... 28
Figura 3.2. As fases e os marcos de um projeto no UP. (Adaptado do RUP 2002)......... 29
Figura 3.3. As quatro fases e marcos do processo iterativo............................................. 39
Figura 4.1. Modelo Genérico de Atividade........................................................................ 49
Figura 4.2. Um Guia para Padronizações em Engenharia e Integração de Empresas.... 49
Figura 4.3. Método Estruturado GIM. ............................................................................... 53
Figura 4.4. Estrutura PÊRA .............................................................................................. 55
Figura 4.5. Derivação dos requisitos de informação e manufatura .................................. 55
Figura 4.6. Estrutura de Modelagem da Arquitetura ARIS ............................................... 56
Figura 4.7. Integrações entre Entidades Funcionais. ....................................................... 58
Figura 4.8. Estrutura de Modelagem CIMOSA ( ou cubo CIMOSA)................................. 59
Figura 4.9. Relações entre o Ciclo de Vida CIMOSA e Modelos (KOSANKE, 1995)....... 63
Figura 4.10. Principais etapas do Processo de Modelagem CIMOSA. ............................ 63
Figura 4.11. GERAM (Metodologia e Arquitetura de Referência de Empresas Generalizada)
Componentes da Estrutura................................................................................................ 70
Figura 5.1. Estrutura de Modelagem GERA com Vistas de Modelagem.......................... 78
Figura 5.2. Ícone de representação na UML para Componente de Recurso................... 81
Figura 5.3. Exemplo de Modelo de Recursos................................................................... 82
Figura 5.4. Processo de Previsão de Demanda............................................................... 86
Figura 5.5. Gabarito do Processo de Previsão de Demanda. .......................................... 86
Figura 6.1. Fases do Ciclo de vida de GERA para alguma empresa ou entidade. .......... 96
Figura 6.2. Workflow para Modelagem de Negócios........................................................ 100
Figura 6.3. Workflow de Levantamento de Requisitos. .................................................... 103
Figura 6.4. Workflow de Análise e Projeto........................................................................ 107
Quadro 6.1. Relacionamento entre as atividades dos Workflows e as Fases do Ciclo de Vida
de GERA............................................................................................................................ 108
Figura A.1. Modelagem de Definição de Requisitos (Zelm, 1995)................................... 124
Figura A.2. Modelagem da Especificação de Projeto (Zelm, 1995). ................................ 126
Figura A.3. Modelagem da Descrição de Implementação (Zelm, 1995). ......................... 128
IX
LISTA DE ABREVIATURAS
ARIS - Architecture for Integrated Information Systems
CCB - Change Control Board
CIM - Computer Integrated Manufacturing
CIMOSA - Computer Integrated Manufacturing Open Systems Architecture
EDI - Electronic Data Interchange
EEM - Enterprise Engineering Methodology
EETs - Enterprise Engineering Tools
EMLs - Enterprise Modeling Languages
EMOs - Enterprise Modules
EMs - Enterprise Models
EOS - Enterprise Operational Systems
ERP - Enterprise Resources Planning
GAM - Generic Activity Model
GEMCs - Generic Enterprise Modeling Concepts
GERA - Generic Reference Architecture
GERAM - Generalized Enterprise Reference Architecture and Methodology
GIM - GRAI Integrated Methodology
GLP - GNU Public License
GP - Gestão da Produção
GRAI - Graphes à Resultats et Activités Interreliés
IT - Itens de Trabalho
ITF - Itens de Trabalho Futuro
MDI - Modelo de Descrição da Implementação
MDR - Modelo de Definição de Requisitos
MEP - Modelo de Especificação de Projeto
MRP II - Manufacturing Resources Planning
MRP - Materials Requirements Planning
OPEN - Object-oriented Process, Environment and Notation
PEMs - Partial Enterprise Models
PERA - Purdue Enterprise Reference Architecture
PMEs - Pequenas e Médias Empresas
RPC - Remote Procedure Call
RUP - Rational Unified Process
SIGs - Sistemas Integrados de Gestão
TI - Tecnologia da Informação
UEML - Unified Enterprise Modeling Language
X
UML - Unified Modeling Language
UP - Unified Process
URL - Universal Resource Locator
USDP - Unified Software Development Process
XI
RESUMO
Devido aos novos desafios impostos às indústrias pela alta competitividade do
mercado, impulsionada pela globalização, as organizações têm sido forçadas a
investir em novas tecnologias, novos produtos e novas estratégias de gestão, para
manterem sua competitividade, e conseqüentemente sua sobrevivência. Nesse
contexto, as mesmas têm investido em avançadas ferramentas de gestão, como os
ERP (Enterprise Resource Planing), que devido ao alto custo e a complexidade de
implantação, sua adoção por Pequenas e Médias Empresas (PMEs) se torna difícil.
Isto motivou a criação do projeto ERP5, que oferece uma série de vantagens que
buscam reduzir esses problemas. Este projeto, que está sendo desenvolvido por um
consórcio de instituições e empresas da França e do Brasil, tem o objetivo de
projetar e desenvolver uma configuração completa de componentes de software
ERP e fornecer informação suficiente (jurídico, social, teórica) para que todos
possam entender e implementar o ERP em companhias de qualquer porte. Levando-
se em consideração esta questão e as demais características intrínsecas ao ERP5,
a criação de uma metodologia específica para o desenvolvimento e implantação
deste sistema torna-se essencial. Esta dissertação apresenta um estudo sobre
Arquiteturas de Referência, destacando a GERAM (Generalized Enterprise
Reference Architecture and Methodology) e sobre Metodologias de Modelagem de
Empresas, destacando o UP (Unified Process). Ao final são realizadas propostas
para a definição de componentes (metodologias, linguagens, ...) para o
desenvolvimento e implantação do ERP5, baseadas na Arquitetura de Referência
GERAM.
P
ALAVRAS-CHAVE
Modelagem e Integração de Empresas, ERP, CIMOSA, GERAM e UP.
XII
ABSTRACT
Due to the new challenges imposed to the industries by the high
competitiveness of the market, impelled by globalization, organizations have been
forced to invest in new technologies, new products and new management strategies,
in the search to maintain their competitiveness, and consequently their survival. In
that context, organizations have been investing in advanced management tools like
the ERP (Enterprise Resource Planning), that due to the high cost and the
deployment complexity, its adoption by Small and Medium Enterprises (SME) it
became impracticable. These motivated the creation of the project ERP5, that offers
a series of advantages to reduce those problems. This project is being developed by
a consortium of research institutions and companies of France and Brazil, and it has
the objective of designing and developing a complete configuration of ERP software
components and to supply enough information (juridical, social, theoretical) so that
anyone can understand and implement ERP in companies of any size. Being taken in
consideration this subject and the other ERP5 intrinsic characteristics, the creation of
a specific methodology for the development and deployment of this system becomes
essential. This dissertation presents a study on Reference Architectures, in special
GERAM (Generalized Enterprise Reference Architecture and Methodology), and on
Enterprise Modeling Methodologies, detaching the UP (Unified Process). At the end,
it suggests proposals to the definition of components (methodologies, languages, …)
to particular architecture for the development and deployment of the ERP5, based on
the GERAM Reference Architecture.
K
EY-WORDS
Enterprise Modeling and Integration, ERP, CIMOSA, GERAM and UP.
XIII
1
CAPÍTULO 1
INTRODUÇÃO
1.1. CONTEXTO
Há algum tempo, as empresas de uma forma geral, vêm enfrentando um
grande aumento na concorrência. E devido à globalização, as exigências impostas
pelos consumidores têm criado, numa velocidade muito grande, novas regras de
mercado, obrigando-as a se modernizar, investir em novas tecnologias para
acompanhar essas evoluções do mercado, além de se tornarem mais competitivas,
oferecendo produtos cada vez mais baratos e de alta qualidade.
Nesse cenário, as Pequenas e Médias Empresas (PMEs) passaram a sofrer
concorrência direta das grandes empresas que, por diversos motivos, possuem
melhores condições de adequação às novas exigências do mercado. Em geral,
essas grandes empresas utilizam avançadas ferramentas de gerenciamento, como
os Sistemas Integrados de Gestão, também conhecidos pela sigla ERP (Enterprise
Resources Planning) (CORRÊA et al., 2000).
O alto custo e a complexidade de implantação dos ERPs dificultam a sua
adoção pelas PMEs, o que as prejudica ainda mais em termos competitivos.
Esses fatos acabaram por motivar a criação do projeto ERP5, que oferece
uma série de vantagens que buscam reduzir os problemas citados anteriormente. O
projeto ERP5 nasceu em 2001 através da iniciativa da Nexedi, uma companhia de
consultoria em Informática da França, e da Coramy, uma das principais produtoras
de roupas da Europa. Ele é um projeto de um sistema ERP livre de Código Aberto
que tem como objetivo projetar e desenvolver uma configuração completa de
componentes de software ERP e fornecer informação suficiente (jurídica, social,
teórica) para que todos possam entender e implementar o ERP em companhias de
pequeno e médio porte (SMETS-SOLANES e CARVALHO, 2003).
Para que a evolução do projeto ERP5 seja bem sucedida e as PMEs
possam usufruir desta tecnologia a baixo custo, é necessário proporcionar a elas um
conjunto de conhecimentos necessário para que elas consigam, por si só, ou com
um menor custo de consultoria, desenvolver, adequar ou customizar o código
oferecido pelo ERP5, e também implantá-lo.
2
A proposta feita pelo projeto ERP5 é a de que a organização que o adotar
tenha total liberdade para utilizar e realizar as alterações no código dos
componentes disponíveis, ou desenvolver novos componentes para adequação do
ERP5 aos requisitos particulares da empresa, conforme for conveniente. Isto torna
mais importante ainda um processo/metodologia de desenvolvimento e implantação,
principalmente a atividade de levantamento de requisitos, já que é a partir desse
levantamento que se fará a customização/adaptação do ERP5. Após, a geração ou
modificação dos códigos será facilitada através de ferramentas de suporte, também
previstas no projeto.
Uma metodologia é um agregado de técnicas e ferramentas que tem por
objetivo padronizar o processo de desenvolvimento de sistemas em uma empresa
(GHEZZI et al., 1991 apud SILVEIRA e SCHMITZ, 2002). Uma metodologia para
desenvolvimento de sistemas especifica a seqüência de passos e a serem seguidos
durante o desenvolvimento de um Sistema de Informação.
Existem várias metodologias para desenvolvimento de Sistemas de
Informação. Dentre essas metodologias, podemos destacar o Processo Unificado
(UP - Unified Process), que é de domínio público, e o Processo Unificado da
Rational (RUP - Rational Unified Process), que disponibiliza apenas uma parte de
toda a metodologia (AZEVEDO, 2003).
Para se desenvolver um bom software e implantá-lo corretamente é
necessário que a metodologia utilizada contemple uma adequada fase de
engenharia de requisitos, que pode ser feita com a ajuda de técnicas para a
modelagem do negócio (ERIKSON & PENKER, 2000).
Assim como existem várias metodologias de sistemas, também, existem
vários métodos, técnicas e ferramentas de modelagem de empresas para facilitar a
implantação de sistemas de empresa, tal como Sistemas Integrados de Gestão
(SIGs ou ERPs). Exemplos são ARIS (Architecture for Integrated Information
Systems) e CIMOSA (Computer Integrated Manufacturing Open Systems
Architecture) (VERNADAT, 1996).
No projeto ERP5 busca-se, então, proporcionar conhecimentos, tal como
metodologias, linguagens e ferramentas, para o desenvolvimento e implantação para
3
seus componentes (módulos) baseadas em uma arquitetura de referência para
modelagem e integração de empresas. Tal necessidade é o que torna importante a
realização da pesquisa proposta neste projeto.
Pesquisas prévias, realizadas por várias entidades, produziram arquiteturas
de referência tais como CIMOSA, ARIS, GIM e PERA, que foram meios para
organizar todo o conhecimento para modelagem e integração de empresas, e
serviram como um guia em programas de integração de empresas. A Força-tarefa
IFAC/IFIP em Arquiteturas para Integração de Empresas desenvolveu uma definição
global de uma arquitetura generalizada, que foi intitulada ‘GERAM’ – Generalised
Enterprise Reference Architecture and Methodology, que tem em vista organizar o
conhecimento para integração de empresas. Em sua estrutura (Figura 1.1)
representa-se os componentes necessários para o desenvolvimento de sistemas de
empresas. Ela tem o potencial de ser aplicada a todos os tipos de empreendimento.
GERA EMLs
EEM
Arquitetura de Empresas
Generalizada
Linguagens de Modelagem
de Empresas
Metodologia de Engenharia
de Empresas
Identifica conceitos de
integração de empresas
Fornece construtores de modelagem
para modelagem de funções humanas
p
rocessos e tecnolo
g
ias
Descreve processos de
engenharia de empresas
utiliza
emprega
É im
p
lementado em
GEMCs
Conceitos Genéricos de
Modelagem de
Empresas
(Tecnologias e Definições)
PEMs EETs
Modelos Parciais de
Empresas
Ferramentas de Engenharia
de Empresas
Define o objetivo dos construtores de
modelagem de empresas
Fornece modelos de referência
reutilizáveis e projeta funções humanas,
processos e
tecnologias.
Apóia a engenharia de
empresas
apóia
usada para construir
EMs
Modelos de Empresa
Projeta empresas e modelos
para apoiar análises e
operações
EMOs
Figura 1.1. Componentes da estrutura de GERAM.
Fonte: IFIP–IFAC – Task Force on Architectures for Enterprise Integration GERAM: Generalised
Enterprise Reference Architecture and Methodology – Version 1.6.3, Março, 1999, página 5
EOS
Sistemas Operacionais de
Empresas
Apóia a operação de empresas
em particular
Módulos de Empresa
Fornece módulos implementáveis de
profissões humanas, processos
operacionais e tecnologias.
usada pa
ra implementar
4
1.2. OBJETIVO
O objetivo da pesquisa proposta é apresentar um estudo sobre arquiteturas
de modelagem e integração de empresas e metodologias para desenvolvimento de
software. A partir deste estudo, apresentar uma metodologia genérica para
modelagem e desenvolvimento de sistemas de Empresa a partir da Arquitetura de
Referência Generalizada de Empresa - GERAM e de conceitos e atividades de
metodologias de desenvolvimento de Sistemas de Software, como o Processo
Unificado (UP), e desenvolvimento de sistemas de empresa, como CIMOSA. Após,
pretende-se fazer propostas para a definição de uma arquitetura particular para
desenvolvimento e implantação do ERP5.
1.3. JUSTIFICATIVA
O ERP5 é um software bastante inovador, pois está sendo desenvolvido
através da tecnologia de banco de dados orientado a objetos, quando a maioria dos
softwares de ERP usa tecnologia de banco de dados relacional. Ele também
combina ERP e administração de conteúdo de uma maneira unificada, e é projetado
para ser distribuído a locais distantes por conexões de Internet lentas e não-
confiáveis.
A pesquisa proposta neste projeto se justifica pela necessidade do
desenvolvimento de uma metodologia de modelagem, desenvolvimento e
implantação adaptada às características específicas do ERP5, e assim aproveitar ao
máximo nos processos de negócios das empresas, as avançadas tecnologias
disponibilizadas pelo banco de dados adotado. Existem vários métodos, técnicas e
ferramentas de modelagem de empresa para facilitar o desenvolvimento de
Sistemas Integrados de Gestão (ou ERPs), mas estes não detalham como deve ser
realizado o desenvolvimento de software. Por outro lado, existem várias
metodologias de desenvolvimento de Sistemas de Informação (software), porém
essas são carentes no que diz respeito à engenharia de levantamento de requisitos
do negócio, por ser essa atividade ainda muito genérica. Além disso, a proposta feita
5
pelo projeto ERP5 é a de desenvolver um sistema baseado em código aberto de
software. Assim, as empresas que adotarem tal sistema, além de terem total
liberdade para realizar alterações, poderão desenvolver outros componentes para o
sistema, se assim acharem necessário, baseados na documentação dos códigos
existentes, acarretando a necessidade de uma metodologia fortemente apoiada em
modelos, dos quais originaram os códigos.
Levando-se em consideração estas questões, e as demais características
intrínsecas ao ERP5, a criação de uma arquitetura específica para o
desenvolvimento e implantação deste sistema torna-se essencial. Ainda, pelo fato do
sistema ser proposto para a utilização de várias empresas/usuários, a definição de
uma metodologia associada a uma Arquitetura de Modelagem e Integração de
Sistemas de Empresa facilitará a compreensão e integração dos sistemas sendo
desenvolvidos ou adaptados, por exemplo, através do reuso de modelos de
referências e de componentes já desenvolvidos em linguagens e protocolos padrões
(VERNADAT, 1996, ERIKSON & PENKER, 2000).
1.4. ESTRUTURA DA DISSERTAÇÃO
Além deste capítulo introdutório, a dissertação está organizada de acordo
com a estrutura a seguir:
Capítulo 2: Apresenta os principais conceitos sobre Sistemas de Informação,
ERP e o ERP5.
Capítulo 3: Apresenta algumas das principais técnicas para a modelagem e
o desenvolvimento de sistemas de informações, com detalhamentos sobre o UP e o
RUP, e sobre a UML.
Capítulo 4: Apresenta os conceitos, técnicas e linguagens para Modelagem
e Integração de Empresas, com detalhamentos sobre Arquiteturas de Referência,
destacando-se CIMOSA e GERAM.
6
Capitulo 5: Apresenta uma proposta de atividades para uma Metodologia de
Desenvolvimento de Sistemas para o ERP5 baseada no ciclo de vida da arquitetura
de referência GERAM.
Capítulo 6: Apresenta um conjunto de propostas para a definição de uma
arquitetura particular para o desenvolvimento e a implantação do ERP5.
Capítulo 7: Apresenta as conclusões finais sobre a dissertação, com
perspectivas para trabalhos futuros.
7
CAPÍTULO 2
SISTEMAS DE INFORMAÇÃO E O ERP 5
2.1. SISTEMAS DE INFORMAÇÃO
Com a atual tendência mundial de unificação dos mercados e a globalização
da economia, surge nas empresas a necessidade de novas formas para melhorar
seus processos e manterem a sua competitividade.
“Ser competitivo é ser capaz de superar a concorrência naqueles aspectos de
desempenho que os nichos de mercado visados mais valorizam”, cita CORRÊA et
al. (2000).
Cada vez mais, a qualidade e a produtividade dos processos organizacionais
deixam de ser responsabilidade exclusiva dos dirigentes, passando a comprometer
toda a estrutura organizacional, em qualquer nível.
Nessa busca por qualidade e produtividade, a tendência das organizações é a
de realizar mudanças no gerenciamento de suas operações, além de procurar
integrar as atividades entre operários e máquinas, facilitando a comunicação,
cooperação e coordenação das variadas funções técnicas, administrativas e de
suporte, por meio de avançadas ferramentas de Gestão da Produção (GP) e
Tecnologia da Informação (TI) (CHUNG e SNYDER, 2000).
A Tecnologia da Informação é um capacitador essencial para a melhoria das
operações da empresa porque viabiliza projetos de trabalho mais ágeis, menos
onerosos e mais eficazes, viabilizando uma grande quantidade de novos
procedimentos, técnicas ou metodologias administrativas (RODRIGUES, 1999 apud
SANTOS, 2001). No decorrer do tempo, o papel dessas tecnologias nas
organizações vem sofrendo diversas alterações. Atualmente, elas encontram-se na
origem de mudanças significativas ao nível dos modelos de negócios das empresas
e constituem um elemento fundamental para a obtenção das vantagens estratégicas
e competitivas. Por isso, elas não devem ser apenas utilizadas para a automação
dos processos de negócios existentes, mas devem servir de base para a
8
reformulação desses processos, a fim de atingir os objetivos do negócio e obter
diferencial competitivo.
Um sistema de informação é um conjunto integrado de recursos (humanos e
tecnológicos) cujo objetivo é satisfazer adequadamente a totalidade das
necessidades de informação de uma organização e os respectivos processos de
negócio (STAIR apud SILVEIRA e SCHMITZ, 2002).
Um sistema de informação é feito de todas as “partes” de dados e
informações usadas, armazenadas e processadas para as necessidades de usuários
e aplicativos da empresa. O sistema de informação de uma empresa armazena fatos
e conhecimento sobre os objetos da empresa, seu uso e evolução, seus
relacionamentos e suas restrições. O propósito de um sistema de informação é
gerenciar os dados e informações da empresa para suporte às atividades do sistema
físico e de decisão da empresa (VERNADAT, 2006).
A tecnologia de informação tem dado suporte aos processos relacionados
com o planejamento da produção através de sistemas que automatizam o
processamento de informações de forma cada vez mais evoluída. Após o surgimento
da automação do procedimento de Planejamento dos Requisitos de Materiais
através do sistema MRP (Materials Requirements Planning) que realiza a explosão
da lista de materiais, surgiu o sistema MRP II (Manufacturing Resources Planning)
que integra o processamento do MRP com o planejamento de recursos e
planejamento financeiro entre outras atividades. Com a junção de conceitos e
técnicas de Gestão da Produção e de Tecnologia da Informação surgiram mais
recentemente os sistemas integrados de gestão, conhecidos pela sigla ERP
(CHUNG e SNYDER, 2000).
2.2. ERP
ERP (Enterprise Resources Planning) é comumente definido como uma
arquitetura de software que facilita o fluxo de informações entre todas as atividades
da empresa como fabricação, logística, finanças e recursos humanos.
9
São Sistemas Integrados de Gestão, isto é, são avançadas ferramentas de
gerenciamento de empresas. Um sistema que se denomina ERP tem a pretensão de
suportar todas as necessidades de informação para a tomada de decisão de um
empreendimento como um todo. É, basicamente, composto de módulos que
atendem às necessidades de informação para apoio à tomada de decisão de setores
outros que não apenas aqueles ligados à manufatura: distribuição física, custos,
recebimento fiscal, faturamento, recursos humanos, finanças, contabilidade, entre
outros, todos integrados entre si e com módulos de manufatura, a partir de uma base
de dados única e não redundante (CORRÊA et al., 2000).
Ele é usado por grandes empresas desde o início dos anos 80 como um
sistema para gestão de conhecimento, pois possui uma estrutura informatizada
extremamente organizada, a fim de integrar os softwares de cada departamento em
uma única ferramenta, possibilitando a realização de uma gestão completa das suas
funções (contabilidade, finanças, logística e recursos humanos etc).
Considera-se o ERP como último e, provavelmente, mais significativo
desenvolvimento da filosofia de MRP básica. Em sua forma básica, a força do MRP
baseia-se no fato de poder explorar as conseqüências de quaisquer mudanças que
uma operação fosse solicitada a realizar. Assim, se a demanda mudasse, o sistema
MRP poderia calcular todos os efeitos e estabelecer instruções de acordo. O mesmo
princípio aplica-se ao ERP, mas em base muito mais ampla. Os sistemas de ERP
permitem que as decisões e a base de dados de todas as partes da organização
sejam refletidas nos sistemas de planejamento e controle do restante da
organização (SLACK apud SANTIAGO, 2005).
Os benefícios potenciais da utilização dos ERPs são imensos. Essa
integração, deve organizar, codificar e padronizar negócios e processos de cada
departamento, transformando os dados operacionais em informações úteis à tomada
de decisões. Isso é feito partindo das necessidades estratégicas, táticas e
operacionais e expresso em termos dos objetivos da organização, o que pode tornar
o sistema aplicável em qualquer tipo de organização.
O ERP oferece indicadores para controles gerenciais que auxiliam no
entendimento da empresa como algo único e completo, possibilitando aos usuários
do sistema, aproveitarem o valor acrescentado pela informação e pelo conhecimento
10
que circula na empresa. O ERP, por organizar e customizar procedimentos internos,
promove a redução de custos internos, agiliza a obtenção de informações por meio
do desenvolvimento e da modernização dos processos corporativos. Com isso, a
empresa passa a ser vista como um conjunto de processos e não de departamentos
isolados, pois possui uma fonte de dados única através de um banco de dados
único, diminuindo as possibilidades de distorções de informação.
Apesar disso, em muitas situações práticas, os usuários preferem adotar
alguns módulos do ERP que adquiriram e manter outros em uso, já completamente
adaptados às suas necessidades.
A principal motivação de grande número de empresas optarem por adotar o
ERP é a integração entre as várias áreas e setores funcionais da organização, todas
compartilhando uma mesma base de dados única e não redundante.
Ao implantar um ERP, mais do que colocar um novo programa nos
computadores da empresa, está sendo definida ou sendo adotada uma metodologia
de trabalho, um Workflow (fluxo de trabalho). Estão sendo definidos seus processos
para ganhar agilidade e com isso competitividade. A Figura 2.1 demonstra como
surgiu o conceito de ERP. O MRP conhecido como Planejamento de Necessidades
de Materiais, deu origem ao MRPII que agregou os módulos de programação-mestre
de produção (MPS), cálculo aproximado de necessidade de capacidade (RCCP),
cálculo detalhado de necessidade de capacidade (CRP), controle de fabricação
(SFC), controle de compras (PUR) e, por fim, o planejamento de vendas e
operações (S&OP). O ERP agregou aspectos contábeis, financeiros, administrativos,
recursos humanos e logísticos que incluí a distribuição física de produtos (DRP)
(CORREA et al.,2000).
11
Vendas/
Previsão
Figura 2.1. Estrutura conceitual dos sistemas ERP, e sua evolução desde o MRP.
Fonte: CORRÊA, H.L. et al. Planejamento, Programação e Controle da Produção – MRP II / ERP
Conceitos, uso e implementação, São Paulo – SP, 2000, página 350
2.3. ERP5
2.3.1. DEFINIÇÃO
O ERP5 é um projeto que visa o desenvolvimento de um sistema ERP
avançado e de Código Aberto, sendo que todos os componentes e plataformas onde
ele é desenvolvido são livres, permitindo que as organizações que o adotarem
tenham liberdade para alterar a forma de funcionar do sistema da maneira que
melhor lhe convier.
Seu principal objetivo é desenvolver e projetar um grupo compreensível de
componentes de software para ERP e fornecer informações suficientes para permitir
a todos, entender e implementar ERPs em pequenas e médias empresas. Em
conseqüência, as PMEs terão à disposição uma solução de baixíssimo custo e cuja
tecnologia se manterá atual por vários anos (SOLANES e CARVALHO, 2003).
MPS
MRP
S&OP
RCCP
CRP
PUR SFS
MRP II
ERP
Faturamento
DRP
Gestão de
Transportes
Workflow
Contabilidade
Geral
Custos
Recursos
Humanos
Contas a
Pagar
Contas a
Receber
Recebimento
Fiscal
Manutenção
Gestão de
Ativos
Folha de
Pagamento
Gestão
Financeira
12
2.3.2. C
ARACTERÍSTICAS ESPECÍFICAS DO ERP5
O ERP5 é baseado em cinco conceitos com alto nível de integração. São eles
(Figura 2.2) (SOLANES e CARVALHO, 2003):
• Multi: o sistema é multi-usuário, multi-organização, multi-linguagem, multi-
moeda, multi-custo e multi-cenário, isto é, linguagem e moeda são itens
parametrizáveis e o sistema pode lidar com vários usuários, unidades de
produção, cenários e itens de custo, simultaneamente, em uma mesma
instalação;
• Meta: oferece vários níveis de detalhe para um mesmo processo de
gestão e, graças à notação de meta-recurso e meta-nó, ele permite definir
níveis de detalhamento pertinentes ao processo de negócio executado por
um usuário que possui determinado papel;
• Distribuído: utiliza um mecanismo de sincronização avançado que permite
a distribuição e compartilhamento de dados por diferentes instalações,
sem que haja a necessidade de uma conexão permanente de rede;
• Baseado em Objetos: o emprego de um banco de objetos (ZODB) permite
modelar e implementar sistemas complexos de suporte à gestão da
produção, incluindo processos, dados estruturados e não estruturados.
Por ser baseado em objetos o ERP5 é uma solução muito mais poderosa
e flexível;
• Livre: ele é licenciado nos termos da GNU PUBLIC LICENSE (GLP), bem
como toda a informação gerada, tecnologias e metodologias
desenvolvidas pelos membros do projeto são livremente disponibilizadas.
13
Figura 2.2. As Cinco Tecnologias Inovadoras do ERP5
Fonte: CARVALHO, R.A. ERP5 - Desenvolvimento de Sistema ERP Avançado e de Código
Aberto para Pequenas e Médias Empresas, Campos dos Goytacazes – RJ, 2003
2.3.3. CARACTERÍSTICAS INOVADORAS
O ERP5 apresenta algumas características inovadoras que merecem
destaque. Elas são descritas a seguir.
2.3.3.1. V
ARIAÇÕES PARA CUSTOMIZAÇÃO DE MASSA
O ERP5 é capaz de administrar variações de um determinado recurso. A
noção de variação permite que um único descritor de recurso e uma coleção de
parâmetros opcionais definam milhões de variações de um determinado produto sem
criar milhões de registros em um banco de dados e sem ter que criar um número de
produto para cada variação de um mesmo produto. Este conceito é bem conhecido
na indústria de vestuário e ainda pouco usado em outras indústrias. Muitos softwares
de ERP não incluem variações.
Customização de massa pode ser entendida como um modo razoável de
administrar o reino de variações de necessidades do cliente sem perder os
benefícios de padronização.
14
2.3.3.2. M
ETA-ERP PARA META-PLANEJAMENTO
O ERP5 está baseado em um modelo que permite associar qualquer coisa a
uma categoria:
• Categoria de recursos (ex. serviço, matéria-prima, habilidade, dinheiro);
• Categoria de organizações (ex. um grupo de companhias, um grupo de
pessoas, uma cadeia de lojas varejista).
As categorias de recursos e as categorias de organizações podem ser
manipuladas, no ERP5, da mesma maneira que os recursos e organizações
habituais. Isto significa que é possível planejar recursos ao nível de um grupo de
companhias como também ao nível de um único escritório.
A meta-característica do ERP5 é muito útil para administrar um grupo de
companhias que pertencem a uma mesma holding ou administrar sociedades onde a
composição de diferentes instalações pode ser considerada uma organização
abstrata que é capaz de fornecer um certo tipo de produto.
2.3.3.3. S
INCRONIZAÇÃO
O ERP5 foi projetado para ser implementado em vários locais, com uma baixa
qualidade de conectividade à Internet. Isto exige que cada local seja capaz de
continuar operando até mesmo no caso de falhas na rede. O ERP5 implementa a
distribuição usando sincronização, uma extensão do protocolo SyncML.
A Sincronização permite definir um subconjunto de dados que duas
companhias querem compartilhar. Esta sincronização é chamada de visão
empresarial comum. A Sincronização permite implementar todas as características
padrões do EDI (Electronic Data Interchange). A sincronização de pedidos e
modelos é equivalente à transmissão de pedidos e modelos EDI.
15
2.3.4. A
RQUITETURA DO ERP5
O ERP5 está baseado num novo modelo de objeto de gestão de empresa,
que é capaz de representar qualquer processo de gerenciamento usando somente
cinco classes fundamentais. São elas (Figura 2.3) (SOLANES e CARVALHO, 2003):
• Resource (Recurso): descreve um recurso abstrato em um processo de
negócio (ex. uma habilidade de um indivíduo, uma matéria-prima, um
produto). Relações entre recursos permitem a definição de listas de
materiais bem como protótipos de produtos;
• Node (Nós): um Node é um lugar que pode receber e enviar quantidades
de recursos, podendo ser relativos a entidades físicas ou abstratas. Ações
são um tipo de Nó. Meta-nodes (Meta-nós) são nós que contém outros
nós. Uma empresa é um meta-nó. Um projeto é um recurso e um nó;
• Movement (Movimento): descreve um movimento de recursos entre nós,
em um dado instante, por uma dada duração;
• Path (Caminho): descreve uma forma que um nó acessa recursos dos
quais precisa. Preços e perfis comerciais podem ser anexados a um Path
para definir o preço padrão de um determinado recurso dado por um
fabricante. Um Path também pode definir o modo como um inventário
obtém recursos de uma ação. Um Path tem uma data de começo e uma
data de fim. Ele pode ser usado para representar a tarefa de um indivíduo
para um projeto temporário. São abstratos, sendo utilizados para
planejamento;
• Item: descreve uma instância física de um recurso. Um Movement pode
ser ampliado em uma série de Movements rastreáveis por Item. Permitem
definir como uma determinada quantidade de recursos foi transportada
(ex. encomenda, números de série de artigos em cada container, etc.)
16
Figura 2.3. Classes do Núcleo do ERP5
Fonte: CARVALHO, R.A. e SMETS-SOLANES, J-P. An Abstract Model for an Open Source ERP
System: The ERP5 proposal. in Proc. 8th International Conference on Industrial Engineering and
Operations Management, Curitiba, Brazil, 2002
.
2.3.5. VARIAÇÕES NA ARQUITETURA DO ERP5
A arquitetura do ERP5 inclui uma noção de variação. Variações são usadas
no ERP5 para representar as possíveis variações para um determinado recurso: cor,
tamanho, velocidade, etc.
Variações são usadas, em particular, para definir recursos complexos,
resultantes de sucessivas transformações. Cada transformação é representada
atualmente como uma coleção de transformações. Algumas das quais aplicam-se a
todas as variações, outras que somente aplicam-se a certas variações.
2.3.6. TRANSFORMAÇÕES NA ARQUITETURA DO ERP5
Transformações são usadas para representar um recurso complexo
construído da transformação de múltiplos recursos. Ao contrário de seguir um
modelo hierárquico, o ERP5 usa um modelo de encadeamento baseado na metáfora
das transformações químicas: A + B → C + D
Para facilitar a definição de conjuntos complexos de transformações, pelos
usuários, estas podem ser prototipadas, pois uma transformação pode ser
equivalente a outras com algumas pequenas diferenças. Isto permite qualquer um
criar novos recursos complexos derivado de recursos complexos já existentes.
17
Recursos equivalentes são úteis para implementar classes de recursos para
obtenção oriunda de diversas fontes.
Transformações no modelo do ERP5 são instanciadas em causalidades de
movimentos atuais entre nós. A única causalidade que existe em um processo
industrial complexo é a causalidade resultante da definição de uma transformação.
2.3.7. MOVIMENTOS E PEDIDOS (MOVEMENTS E ORDERS)
Movimentos (Movements) são onde o planejamento de recursos ocorre.
Movimentos podem incluir sub-movimentos gerados por regras de negócio. Eles
também podem ser associados a outros movimentos por causalidade. Por existir um
começo e um fim, toda a coleção de movimentos com datas passadas e datas
futuras representam todo o planejamento da empresa.
Porém, movimentos são objetos de baixo nível no ERP5. Não é suposto que
os usuários irão lidar com movimentos, exceto em casos raros (ex. no caso da
contabilidade). Então, movimentos são reunidos em Entregas (Deliveries). Entregas
são documentos utilizados, na prática, para administrar o planejamento de empresa.
2.3.8. PLANEJAMENTO DO CAMINHO (PATH PLANNING)
Em algumas empresas, em particular, empresas de serviço, pessoas são
nomeadas para projetos durante certo período de tempo (consultoria) ou enviadas
aos clientes por certo período de tempo (ex. serviços de reparo). Estas situações
podem ser representadas no ERP5 usando um Caminho (Path) temporário com uma
determinada data de começo e fim.
18
2.3.9. N
ÓS E META-NÓS (NODES E META-NODES)
O Sistema ERP5 é um ERP e um Meta-ERP. Uma das mais importantes
classes no Sistema ERP5 é a classe Nó (Node). Como citado anteriormente, um Nó
representa um lugar que pode receber e enviar quantidades de recursos.
2.3.10. CAPACIDADE (CAPACITY)
Cada Nó (Node) tem uma Capacidade (Capacity), esta consiste de:
• Capacidade de Estoque: definido em termos de quantidade máxima de
recursos que um Nó pode manter, o qual é definido por um conjunto de
inequações que devem ser satisfeitas pelo estoque. Cada equação leva
uma quantidade de um determinado recurso como variável e parâmetro de
capacidade para aquele recurso como parâmetro.
• Capacidade de produção: definida em termos de uma máxima ou mínima
quantidade de recursos que o Nó pode produzir em um determinado
período de tempo. Também está definido por um conjunto de inequações.
2.3.11. META-NÓS (META-NODES): AGREGAÇÃO DE NÓS (NODES)
Um Meta-nó (Meta-node) é uma agregação de Nós (Nodes). Em termos de
Movimentos (Movements), Meta-nós (Meta-nodes) podem receber movimentos vindo
de dentro e enviar movimentos para fora da mesma maneira que os Nós podem
fazer. Isto é útil para implementar planejamento a um Meta-nível, sem se preocupar
com detalhes de planejamento ao nível do Nó. O planejamento atual na empresa
requererá mudanças da fonte e do destino de movimentos do nível do Meta-nó para
um nível mais baixo, sempre que um planejamento mais detalhado for requerido.
Meta-nós possuem regras especiais de agregação para movimentos, além do
comportamento habitual do Nó: movimentos agregados de um Meta-nó consistem
em todos os movimentos vindo ou indo de um Nó, o qual o Meta-nó contém ou,
recursivamente, do Meta-nó pertencente ao Meta-nó. Movimentos agregados e
19
produções permitem conferir se um determinado plano de produção é compatível
com a capacidade agregada de um Nó.
2.3.12. SIMULANDO O FUTURO
Graças ao Modelo Abstrato do ERP5 (a Arquitetura do ERP5), é possível
simular o futuro de uma empresa: pedidos, contas, remessas, dinheiro, etc. O
processo de simulação no ERP5 é controlado por regras de negócio que
transformam os movimentos em outros movimentos e geram movimentos de entrega
que são transformados novamente em novos movimentos, etc.
Podemos sintetizar os conceitos genéricos da seguinte forma:
• Movimentos estão relacionados uns aos outros através de Causalidades;
• Causalidades estão relacionadas a uma Regra.
2.3.13. PERFIL
Todo processo de simulação às vezes precisa usar valores pré-definidos para
criar novos movimentos. Tais valores podem incluir preço, desconto, opções de
pagamento, etc. O conjunto inclusivo de tais valores é chamado, no ERP5, de Perfil
do Objeto. Eles podem ser anexados a Recursos (Resource), Nós (Node), Caminho
(Path), ou até mesmo Pedidos (Orders). Perfis de Objetos são agregados por regras
de negócio.
2.3.14. USANDO E EXTENDENDO A INFRAESTRUTURA ZOPE
O ERP5 usa o Zope (www.zope.org) como núcleo de suas fundações. Zope é
um servidor de aplicações e sistema de gerenciamento de conteúdo Open Source
baseado em Python. Zope roda sobre a maioria dos sistemas operacionais (Linux,
FreeBSD, Unix, MacOS X, Windows, etc.). Esta plataforma possui as seguintes
características:
20
• Banco de dados orientado a Objeto: o banco de dados Zope é totalmente
transacional e inclui noções de versão e histórico, o qual permite alterar
alguns dados do sistema de produção sem interferir com outros usuários
ou visualizar todas as transações em um objeto e o que ocorreu com ele
desde a sua criação.
• Publicação de Objetos: objetos e métodos são acessíveis por uma URL
(Universal Resource Locator). É possível chamar remotamente um método
em um objeto enviando um pedido HTTP ou um XML-RPC (XML Remote
Procedure Call).
• Listas de Controle de Acesso: o Zope inclui um modelo de segurança que
permite associar cada método para cada classe componente a um grupo
de segurança. A cada usuário é dado um ou mais direitos. Cada objeto no
banco de dados do Zope tem uma lista de controle de acesso que permite
definir quais perfis podem ter acesso a qual grupo de segurança de
métodos.
Zope pode ser estendido com componentes de software chamados de
Products na terminologia Zope.
2.3.15. W
ORKFLOWS
Os Workflows são séries de interações que ocorrem para completar uma
tarefa. Organizações comerciais tem muitas espécies de Workflows. O objetivo do
software Workflow é facilitar e trilhar atividades de Workflow, posto que diferentes
organizações têm diferentes processos de Workflow, o software de Workflow deve
ser flexível e fácil de customizar.
Workflows são características padrões do Zope. Eles são utilizados
extensivamente no ERP5 desde que permitam um consultor projetar e implementar
rapidamente e eficientemente um processo organizacional. O ERP5 os utiliza nas
seguintes situações:
• Adição de dados para o ERP5 (Wizard Workflow).
• Validando um pedido (Commercial Workflow).
21
• Planejamento de entregas (Simulation Workflow).
• Apoio ao cliente (Support Workflow).
2.4. CONSIDERAÇÕES FINAIS
Neste capítulo foi abordada a possibilidade de ERPs de código aberto e livre,
em específico o ERP5, serem usados pelas PMEs. Porém, para o desenvolvimento,
adaptação ou manutenção de qualquer software, são necessárias técnicas e
ferramentas de suporte. A disponibilização de conhecimento associado ao
desenvolvimento, adaptação e manutenção de sistemas de software se torna ainda
mais importante quando se supõe a possibilidade das PMEs permanecerem o
máximo possível independentes de desenvolvedores e consultores especialistas.
Espera-se que com adequadas técnicas e ferramentas se possa facilitar a adaptação
desses sistemas aos requisitos particulares de cada empresa. Assim, no próximo
capítulo será apresentada algumas das principais técnicas e ferramentas para o
desenvolvimento de sistemas de software.
22
CAPÍTULO 3
DESENVOLVIMENTO DE SISTEMAS DE INFORMAÇÕES
3.1. INTRODUÇÃO
No capítulo anterior foi ressaltada a importância de Sistemas de Informações
para a competitividade das organizações, sendo que atualmente os ERPs podem
ser um diferencial para as empresas. ERPs de Código Aberto podem ser uma
alternativa para as PMEs obterem vantagens competitivas com um menor custo.
Porém, para facilitar o desenvolvimento, manutenção e adaptação de qualquer
Sistema de Informações, são necessários métodos e ferramentas de suporte para a
Engenharia de Software adequados (PRESSMAN, 2002). Isto se torna mais
importante quando se supõe que as PMEs, para diminuir gastos com
desenvolvedores e consultores, devem ter acesso e dominar um certo conjunto de
conhecimentos e, assim, poder ser mais independentes de especialistas externos a
empresa (TIJUNELIS & BARRELLA, 2003) (MENEZES et al., 2005). Além disso,
para que esse conjunto de conhecimentos sobre o que existe disponível (modelos
de referências e códigos executáveis) e de como foi ou deve ser feito (metodologias,
linguagens e ferramentas para desenvolvimentos de novos modelos e códigos) em
termos de Softwares livres, é necessário que esse conhecimento seja sistematizado
e padronizado ao máximo para ser compartilhado entre os usuários e
desenvolvedores. Neste capítulo são apresentadas algumas das principais técnicas
para o desenvolvimento e manutenção de sistemas de informações. Conforme a
literatura, alguns estudos têm sido feitos, apresentando e comparando as vantagens
e desvantagens dessas técnicas, segundo vários critérios.
Por exemplo, HENDERSON-SELLERS et al. (2001) comparam o RUP
(Rational Unified Process) com o OPEN (Object-oriented Process, Enviroment and
Notation), destacando que o último possui vantagens em alguns aspectos por
incorporar, de forma mais completa, a teoria sobre o assunto. Porém, destaca que o
RUP tem um caráter mais pragmático, o que fornece vantagens práticas. Destaca
ainda que essas metodologias estão a frente das demais orientadas a objeto, como
a metodologia da OMT e de BOOCH.
23
HULL et al. (2002) resgata as melhores práticas relacionadas com
metodologias de desenvolvimento de software e avalia as três mais significativas
propostas nos últimos anos: Catalysis, OPEN e RUP.
SCHIMITZ & SILVEIRA (2002) propõem uma metodologia de
desenvolvimento simplificado para PMEs.
SANTIAGO (2005), em sua dissertação, propõe uma nova metodologia, que
tem como base o UP e é acrescida de atividades do XP, com o intento de se
adequar às necessidades das PMEs.
Com relação a linguagens para modelagem de sistemas de informações,
várias são as propostas, parte derivada do modelo de entidade-relacionamento, e
outras orientadas a objeto como a UML (PRESSMAN, 2002) (BOOCH et al., 2000).
Neste capítulo são apresentadas as metodologias de desenvolvimento UP e
RUP, seguido da linguagem UML.
3.2. UP (UNIFIED PROCESS)
3.2.1. O QUE É O UP?
Um processo de desenvolvimento de software, também conhecido como
um processo de engenharia de software, é um conjunto de passos que define quem
está fazendo o que, quando e como alcançar determinado objetivo durante o
desenvolvimento de software. Um processo de engenharia de software descreve
como requisitos são transformados num software (PRESSMAN, 2002).
O Processo Unificado de Desenvolvimento de Software (Unified Software
Development Process – USDP) é um processo padrão de engenharia de software
dos autores do UML. Ele é comumente referido como Processo Unificado ou UP
(Unified Process).
24
O projeto UML tem a intenção de prover uma linguagem visual e um
processo de engenharia de software (descrita na seção 3.4). A UML, por ser apenas
uma linguagem para modelagem orientada a objetos e amplamente independente de
processo, indica apenas como criar e ler modelos bem-formados, mas não aponta
quais modelos serão criados nem quando deverão ser criados. Essa tarefa cabe ao
processo de desenvolvimento de sistemas. O que é conhecido hoje como UML é a
parte da linguagem visual do projeto – o UP é a parte de processo. O UP utiliza a
UML como notação de uma série de modelos que compõem os principais resultados
de suas atividades.
O UP está baseado no trabalho de processo administrado de Ericsson (a
abordagem Ericsson – the Ericsson approach, 1967), da Rational (o Processo
Objetivo da Rational – the Rational Objectory Process, de 1996 até 1997) e outras
fontes das melhores práticas. Como tal, ele é um pragmático e testado método para
desenvolvimento de software que incorpora as melhores práticas de seus
predecessores (ARLOW & NEUSTADT, 2002).
O UP é um amadurecimento do processo de engenharia de software dos
autores da UML.
Segundo ARLOW & NEUSTAD (2002), o Processo Unificado proporciona
uma abordagem disciplinada para a atribuição de tarefas e de responsabilidades
dentro de uma organização de desenvolvimento. Sua meta é garantir a produção de
software de alta qualidade que atenda às necessidades dos usuários, dentro de uma
programação e um orçamento previsível.
O Processo Unificado captura muito das melhores práticas do
desenvolvimento de software moderno, de forma que possam ser adaptadas para
uma grande variedade de projetos e de organizações, como também assegurar uma
produção de alta qualidade de software, que realiza a necessidade do usuário
seguindo prazos e orçamentos.
O Processo Unificado representa a disponibilização de parte do RUP
(Rational Unified Process – proprietário da Rational) ao público geral.
25
3.2.2. C
ARACTERÍSTICAS DO UP
O UP se baseia em três características que o tornam único: é orientado
por caso de uso, tem arquitetura centrada e é iterativo e incremental. Estas três
características se relacionam e são igualmente importantes. A arquitetura fornece a
estrutura que guia o trabalho de cada iteração, os casos de uso definem as metas e
dirigem o trabalho de cada uma das iterações. Estas características são mais bem
descritas abaixo (SEABRA Jr., 2001):
3.2.2.1. P
ROCESSO ORIENTADO POR CASO DE USO
Um Caso de Uso é uma seqüência de ações de um sistema que devolve
ao usuário um valor como resultado. Um conjunto de Casos de Uso definido sob
determinado contexto forma o Diagrama de Casos de Uso que descreve a
funcionalidade do sistema sob este contexto.
Um processo orientado por Casos de Uso faz com que um sistema seja
desenvolvido sob a perspectiva de atender, especificamente, às necessidades de
cada usuário que interage com o sistema, evitando, desta forma, que o sistema
possa ser desenvolvido a ponto de apresentar funcionalidades desnecessárias.
Além de estarem ligados à especificação de requisitos do sistema, os Casos de Uso
também estão relacionados ao projeto, à sua implementação e a testes realizados
ao mesmo, isto é, os Casos de Uso definidos para um sistema são a base de todo o
processo de desenvolvimento. Baseados no Modelo de Caso de Uso, os
desenvolvedores criam uma série de modelos de projeto e implementações que
realizam no sistema as funcionalidades dos Casos de Uso. Os testes também são
realizados de forma a verificar se os componentes implementados implementam
corretamente as funcionalidades dos Casos de Uso.
3.2.2.2. PROCESSO CENTRADO EM ARQUITETURA
“A arquitetura é a visão de todos os modelos que juntos representam o
sistema como um todo” (JACOBSON et al., apud SEABRA Jr.). O conceito de
26
arquitetura engloba os aspectos estáticos e dinâmicos mais significantes do sistema.
A Arquitetura é uma visão do projeto do sistema como um todo, destacando suas
características mais importantes, sem detalhá-las.
Os Casos de Uso orientam o UP durante todo o ciclo de vida, mas as
atividades de projeto são centralizadas na noção da arquitetura de software. O foco
principal das iterações iniciais do processo, principalmente na fase de Elaboração, é
produzir e validar uma arquitetura de software, que no ciclo de desenvolvimento
inicial toma a forma de um protótipo arquitetural executável que gradualmente evolui
até se tornar o sistema final em iterações posteriores.
Esse processo ajuda o arquiteto a concentrar-se nas metas corretas, como
inteligibilidade, poder de recuperação para mudanças futuras e reutilização.
3.2.2.3. PROCESSO ITERATIVO E INCREMENTAL
O UP utiliza pequenos ciclos de projeto (mini-projetos) que correspondem
a uma iteração e que resultam em um incremento no software. Iterações referem-se
a passos no processo, e incrementos a evoluções do produto. Para serem mais
efetivas, as iterações devem ser executadas de modo planejado.
Para escolher o que será implementado em uma iteração, os
desenvolvedores se baseiam em dois fatores: primeiro, a iteração lida com um grupo
de casos de uso que juntos representam o funcionamento do sistema em
desenvolvimento; e, segundo, a iteração lida com os riscos significativos do
empreendimento. Iterações sucessivas constroem um conjunto de artefatos a partir
do estado em que estes foram deixados ao término da iteração anterior. Desta
forma, partindo dos casos de uso, as iterações prosseguem através dos fluxos de
trabalho subseqüentes (análise, projeto, implementação e teste) até alcançar a
forma de código executável.
Em cada iteração, os desenvolvedores identificam e especificam os casos
de uso relevantes, criam o projeto de acordo com a arquitetura escolhida,
implementam o projeto em componentes e verificam se os componentes satisfazem
os casos de uso. Se uma iteração alcançar seu objetivo, o que geralmente ocorre, o
27
desenvolvimento prossegue com a próxima iteração. Se não, os desenvolvedores
devem revisar as decisões tomadas anteriormente e tentar uma nova abordagem.
Por isso os desenvolvedores, para conseguir maior economia de recursos e tempo
durante o desenvolvimento, selecionam apenas as iterações necessárias para
alcançar as metas predefinidas.
Este processo de controle apresenta várias vantagens, como:
• redução no risco de custo para as despesas em um único incremento;
• redução do risco de violação de prazos;
• diminuição do tempo de desenvolvimento do projeto como um todo;
• torna mais fácil a adaptação do sistema a mudanças de requisitos.
3.2.3. O CICLO DE VIDA
O UP consiste da repetição de uma série de ciclos durante a vida de um
sistema. Cada ciclo é concluído com uma versão do produto pronta para distribuição
e é subdividido em quatro Fases relacionadas às metas ao longo do tempo. São elas
a Concepção, a Elaboração, a Construção e a Transição. Cada Fase, por sua vez, é
subdividida em iterações que passam por cinco Workflows (fluxos de trabalho) que
estão relacionados à natureza das atividades. Cada Workflow é responsável por
gerar seus respectivos artefatos através de um conjunto de atividades. Cada Artefato
corresponde a uma documentação (como um modelo) ou outro objeto de valor a ser
criado no desenvolvimento (como um componente de software). Por ser iterativo,
cada fase percorre todo o conjunto de fluxos de trabalho (Workflows). Por ser
incremental, cada iteração atualiza os artefatos gerados nas iterações anteriores.
3.2.4. ITERAÇÕES
Antes de sua conclusão, o ciclo de vida do UP passa por várias e
sucessivas iterações. Cada uma destas iterações resulta em uma versão de um
produto executável que constitui um subconjunto do produto final em
28
desenvolvimento e cresce de modo incremental de uma iteração para outra até se
tornar o sistema final.
Cada iteração corresponde a uma das quatro fases do ciclo de vida. Em
cada uma destas fases, ocorrem várias iterações, sendo que cada iteração passa
pelas cinco Workflows. A importância de cada Workflow para uma iteração depende
da fase em que esta se encontra, pois cada fase possui maior ênfase em
determinado Workflow. A Figura 3.1, conhecida como “Gráfico de Baleias” apresenta
o Workflow que é enfatizado em cada fase.
Figura 3.1. O “Gráfico de Baleias” (Adaptado de RUP, 2002)
Fonte: AZEVEDO Jr., D.P. Aplicação da Técnica de Modelagem de Negócio com UML a
Processos Iterativos de Desenvolvimento de Software, Campos dos Goytacazes – RJ, 2003,
página 30
Nessa Figura podem ser observadas duas dimensões:
• o eixo horizontal representa o tempo e mostra os aspectos do ciclo de vida
do processo à medida que se desenvolve;
• o eixo vertical representa os Workflows, que agrupam as atividades de
maneira lógica, por natureza.
A primeira dimensão representa o aspecto dinâmico do processo quando
ele é aprovado e é expressa em termos de fases, iterações e marcos.
A segunda dimensão representa o aspecto estático do processo, como ele
é descrito em termos de componentes, atividades, fluxos de trabalho, artefatos e
papéis do processo. O gráfico mostra como a ênfase varia através do tempo.
29
3.2.5. FASES
A partir de uma perspectiva de gerenciamento, o ciclo de vida de software
do UP é dividido em quatro fases seqüenciais. Cada fase refere-se a uma
determinada meta a ser atingida ao longo do desenvolvimento. As fases
correspondem a períodos determinados por pontos de controle ao longo do tempo.
Em cada ponto de controle, ou seja, ao final de cada fase, é esperado um
determinado estado de alguns artefatos do desenvolvimento. Em cada final de fase
é executada uma avaliação para determinar se os objetivos da fase foram
alcançados. Uma avaliação satisfatória permite que o projeto passe para a próxima
fase. As fases e seus marcos são apresentados na Figura 3.2.
Figura 3.2. As fases e os marcos de um projeto no UP. (Adaptado do RUP 2002)
Fonte: AZEVEDO Jr., D.P. Aplicação da Técnica de Modelagem de Negócio com UML a
Processos Iterativos de Desenvolvimento de Software, Campos dos Goytacazes – RJ, 2003,
página 31
A seguir descreve-se sucintamente cada uma dessas fases (SEABRA Jr.,
2001).
3.2.5.1. C
ONCEPÇÃO
O objetivo principal da fase de Concepção é conseguir a simultaneidade
entre o cliente e o desenvolvedor nos objetivos do ciclo de vida do projeto, isto é,
essa fase tem a meta de atingir o consenso entre todos os envolvidos no projeto, ao
determinar os objetivos do ciclo de vida do mesmo. Esta fase é muito importante
principalmente para novos esforços de desenvolvimento quando há um negócio
significativo e riscos requeridos que precisam ser esclarecidos antes do
30
procedimento do projeto. Para projetos focados ou aprimoramento de um sistema já
existente, a fase de Concepção é mais breve, mas ainda deve estar focalizada para
assegurar que o projeto ainda é válido e possível de ser feito.
Dentre os principais objetivos desta fase se destacam:
• Estabelecer o escopo do software do projeto e suas condições limite,
incluindo uma visão operacional, critérios de aceitação e o que deve ou
não estar no produto;
• Discriminar os dados de uso crítico do sistema, os cenários primários de
operação que levará as trocas principais do projeto;
• Sugerir e talvez demonstrar pelo menos uma arquitetura candidata contra
alguns cenários primários;
• Estimar o custo geral e a programação para todo o projeto;
• Estimar os riscos em potencial;
Ao final desta fase o escopo do projeto deve ser compreendido, e os
envolvidos que iniciam o projeto devem ter uma boa compreensão do retorno sobre
os investimentos do projeto, isto é, o que é retornado para o que custa o
investimento. Com esse conhecimento, é possível decidir se o desenvolvimento do
projeto deve prosseguir em plena escala ou não. Isto é, no final desta fase deve-se
ter definido o escopo do produto e ter demonstrado que o projeto é viável do ponto
de vista do negócio da organização.
3.2.5.2. ELABORAÇÃO
Na fase de Elaboração, os requisitos que não foram considerados na fase
de Concepção são reunidos e transformados em casos de uso; a base da
arquitetura que irá guiar os trabalhos nas próximas fases é estabelecida; e detalhes
adicionais do projeto são averiguados.
Nesse momento, o sistema é estudado mais amplamente, isto é, esta fase
tem uma visão mais abrangente do sistema sem considerar detalhes.
31
Seu objetivo principal é definir uma arquitetura do sistema preliminar para
prover uma base estável para o desenvolvimento do projeto e posteriores esforços
de implementação na fase de Construção. A arquitetura evolui pela consideração
dos requisitos mais significativos (aqueles que têm um grande impacto na arquitetura
do sistema e que correspondem a aproximadamente 80%) e uma estimativa de
risco. A estabilidade da arquitetura é avaliada através de um ou mais protótipos de
arquitetura.
Seus principais objetivos são:
• Assegurar que a arquitetura, os requisitos e os planos sejam bastante
estáveis, e os riscos sejam suficientemente suavizados para que se possa
detalhar o custo e o Cronograma Geral do desenvolvimento por completo;
• Endereçar todos os riscos significantes da arquitetura do projeto;
• Estabelecer a linha de base da arquitetura derivada pelo endereçamento
dos cenários significantes da arquitetura, que expõe tipicamente os altos
riscos técnicos do projeto;
• Produzir um protótipo evolucionário de produção e componentes de
qualidade, como também possivelmente um ou mais protótipos
exploratórios, disponibilizando protótipos para suavizar riscos específicos
como:
o Projetar requisitos de trocas;
o Reuso de componentes;
o A demonstração para investidores, clientes e usuários finais.
• Demonstrar que a linha de base da arquitetura vai suportar os requisitos
do sistema num custo e num tempo razoáveis;
• Estabelecer um ambiente de suporte.
Para atingir esses objetivos, é também importante configurar o ambiente
de suporte para o projeto. Isso inclui criar um caso de desenvolvimento, criar
templates e diretrizes, e configurar ferramentas.
Nesta fase são executadas iterações com objetivo de reduzir a arquitetura,
gerando visões bem descritas da mesma (visão de caso de uso, visão lógica, visão
de processos, visão da implantação, visão da implementação) e um protótipo de
32
arquitetura executável. A quantidade de iterações dependerá da complexidade do
sistema e dos riscos associados ao mesmo.
Ao final desta fase, estarão definidos o escopo e os objetivos detalhados
do sistema, a escolha da arquitetura e a solução para os principais riscos.
3.2.5.3. C
ONSTRUÇÃO
O principal objetivo da fase de Construção é esclarecer os requisitos
restantes e completar o desenvolvimento do sistema baseado na arquitetura de
base. A fase de Construção é sobretudo um processo de manufatura, onde a ênfase
é dada no gerenciamento de recursos e controle de operações para otimizar custos,
programação, e qualidade. Durante a fase de Construção são detalhados os casos
de uso remanescentes e a descrição arquitetural é modificada quando necessário.
Os Workflows prosseguem através de iterações adicionais, preenchendo os modelos
de análise, projeto e implementação. Subsistemas são interligados e testados, da
mesma forma que o sistema como um todo.
Dentre seus objetivos se destacam:
• Minimização de custos de desenvolvimento pela otimização de recursos e
evitando re-trabalhos desnecessários;
• Alcançar qualidade adequada de forma rápida e prática;
• Obter versões utilizáveis (alpha, beta, e outras versões de teste) rápido e
praticamente;
• Completar a análise, projeto, desenvolvimento e teste de todas as
funcionalidades requeridas;
• Desenvolver iterativamente e incrementalmente um produto completo
pronto para ser transmitido aos usuários. Isto implica em descrever os
casos de uso e outros requerimentos restantes, concluir o projeto,
completar a implementação, e testar o software;
• Decidir se o software, os locais e os usuários estão todos prontos para a
aplicação a ser implantada;
33
• Alcançar algum grau de paralelismo no trabalho de equipes de
desenvolvimento. Mesmo em pequenos projetos, geralmente existem
componentes que podem ser desenvolvidos independentemente uns dos
outros, permitindo um paralelismo natural entre equipes. Este paralelismo
pode acelerar significativamente as atividades de desenvolvimento, mas
também aumenta a complexidade de gerenciamento de recursos e
sincronização de fluxo de trabalho. Ter uma arquitetura robusta é
essencial para atingir um paralelismo significativo.
Enquanto as fases de Concepção e Elaboração estão ligadas diretamente
à modelagem do sistema, a fase de Construção é caracterizada pelo
desenvolvimento, isto é, a construção de um sistema ou produto dentro dos
parâmetros de custo e prazos.
3.2.5.4. TRANSIÇÃO
O foco da fase de Transição é assegurar que o software está pronto para
o usuário final. A fase de Transição pode transpor várias iterações, e inclui testes do
produto na preparação para liberação, e realizar ajustes mínimos baseados no
retorno dos usuários. Neste ponto do ciclo de vida, o retorno dos usuários deve focar
o ajuste fino do produto, na configuração, instalação e usabilidade.
Ao final do ciclo de vida da fase Transição, os objetivos devem ter sido
alcançados e o projeto concluído. Em alguns casos, o fim de um ciclo de vida de
Transição corrente pode coincidir com o início de outro ciclo de vida do mesmo
produto, levando a uma nova geração ou versão do produto.
Entra-se na fase de Transição quando um projeto está maduro o suficiente
para ser implantado no domínio do usuário final. Isto tipicamente requer que um
subconjunto utilizável do sistema tenha sido terminado com um nível de qualidade
aceitável e com documentação para o usuário (Manual do Usuário).
Dentre os objetivos da fase de Transição se destacam:
• Testes Beta para validar o novo sistema frente expectativas dos usuários;
34
• Operações paralelas de substituição do sistema legado;
• Treinamento dos usuários;
• Conserto de bugs;
• Preparar infra-estrutura de Hardware e Software do Cliente para receber o
novo sistema.
O principal fator que determinará a conclusão da fase de Transição, e
conseqüentemente a conclusão do projeto, é a “satisfação” do cliente.
3.2.6. WORKFLOWS
Cada uma das quatro fases do UP é dividida em iterações que por sua
vez, realizam atividades que são responsáveis por gerar artefatos ao fim de cada
uma dessas iterações. Ao conjunto dessas atividades dá-se o nome de Workflows
de processo. São eles (SEABRA Jr., 2001):
3.2.6.1. REQUISITOS
Seu objetivo é capturar os requisitos que serão atendidos pelo produto de
software. Os requisitos do sistema são especificados através da identificação das
necessidades de usuários e clientes. Eles são expressos em casos de uso através
do modelo de casos de uso. Um modelo de casos de uso é composto pelo conjunto
de diagramas de casos de uso que compõem o sistema , e especifica como esse
sistema será utilizado sob a perspectiva de clientes, usuários e desenvolvedores. A
identificação de requisitos é realizada através do estudo de como os usuários
precisam usar o sistema para realizar seu trabalho.
Durante a fase de Concepção, os requisitos mais importantes são
identificados, delimitando o domínio do sistema, e durante a fase de Elaboração, a
maioria dos requisitos remanescentes é capturada. Nada mais lógico, pois o objetivo
destas fases é o entendimento e a delimitação do escopo do produto de software. A
identificação da maioria dos requisitos permitirá aos desenvolvedores saber o quanto
deverão se empenhar para desenvolver o sistema. Os requisitos que sobram são
35
capturados e implementados durante a fase de Construção, enquanto, na fase de
Transição quase não há requisitos a serem capturados, a menos que ocorram
mudanças nos mesmos. O Workflow Levantamento de Requisitos aborda as
seguintes atividades:
• Identificar casos de uso;
• Priorizar casos de uso;
• Detalhar casos de uso;
• Estruturar o modelo de caso de uso.
Portanto, o Workflow de Levantamento de Requisitos foca suas atividades
na identificação de entidades que interagem com o sistema (atores) e dos requisitos
funcionais deste sistema para cada um dos atores (casos de uso) e no agrupamento
destes elementos sob determinado contexto de forma a construir diagramas de
casos de uso cujo conjunto formará o modelo de casos de uso.
3.2.6.2. ANÁLISE
Seu objetivo é o de criar o modelo de análise que tem como função refinar
os requisitos especificados no Workflow de Requisitos através da construção de
diagramas de classes conceituais, permitindo argumentações a respeito do
funcionamento intero do sistema. O modelo de análise fornece mais poder
expressivo e formalismo, como diagramas de interações e diagrama de gráficos de
estado que representam a dinâmica do sistema. Este Workflow é mais utilizado
durante a fase de Elaboração, contribuindo para a definição de uma arquitetura
estável e facilitando o entendimento detalhado dos requisitos.
Ao estruturar os requisitos do sistema, o modelo de análise fornece uma
estrutura com foco na manutenção dos mesmos. Esta estrutura serve, não só para a
manutenção de requisitos, como também serve de entrada para os Workflows de
Projeto e Implementação. Desta forma, o modelo de análise pode ser visto como o
primeiro passo para o desenvolvimento do modelo de projeto, mesmo sendo
considerado um modelo particular.
36
3.2.6.3. PROJETO
Neste Workflow o sistema é moldado e sua forma é definida de maneira a
suprir as necessidades especificadas nos requisitos. Também é definido um modelo
de projeto que é construído com base no modelo de análise definido no Workflow
anterior.
O modelo de projeto criado neste Workflow descreve o sistema a nível
físico, tendo como principal função obter uma compreensão detalhada dos requisitos
do sistema, levando em consideração fatores como linguagem de programação,
sistemas operacionais, tecnologias de banco de dados, interface com o usuário, etc.
Seu enfoque está entre o fim da fase de Elaboração e o início da fase de
Construção.
O Workflow de Projeto, muitas vezes é considerado uma extensão do
Workflow de Análise, pois, enquanto este último se interessa por o que o sistema
deve fazer, ele diz respeito a como os requisitos serão implementados.
3.2.6.4. IMPLEMENTAÇÃO
Este Workflow se baseia no produto resultante do Workflow de Projeto que
é o Modelo de Projeto. Ele tem como objetivos a organização do código em termos
de implementação de subsistemas, a implementação das classes e objetos em
termos de componentes, o teste dos componentes em termos de unidades e a
integração dos códigos produzidos.
O Workflow de Implementação produz um Modelo de Implementação que
se limita a:
• Planejar as integrações do sistema em cada iteração. Neste caso, o
resultado é um sistema que é implementado como uma sucessão de
etapas pequenas e gerenciáveis;
• Implementar os subsistemas encontrados durante o projeto;
37
• Testar as implementações e integrá-las, compilando-se em um ou mais
arquivos executáveis, antes de enviá-los ao próximo Workflow.
Ele é mais usado durante a fase de Construção e apesar de ter suas
características próprias, a maior parte de suas atividades é realizada de forma quase
mecânica, pelo fato das decisões mais difíceis terem sido tomadas durante o
Workflow de Projeto.
3.2.6.5. TESTE
Neste Workflow os componentes executáveis gerados no Workflow de
Implementação, são testados exaustivamente antes de serem disponibilizados aos
usuários finais. O principal objetivo deste Workflow é analisar, através de testes, se
os requisitos foram atendidos. Componentes que possuírem defeitos retornarão aos
Workflows anteriores onde seus problemas serão corrigidos.
Em suma, o papel do Workflow de Teste é verificar se os resultados do
Workflow de Implementação cumprem os requisitos estipulados por clientes e
usuários para que possa ser decidido se o sistema necessita de revisões ou se o
processo de desenvolvimento pode continuar. Sua ênfase será maior no final da
fase de Construção e no início da fase de Transição.
3.3. RUP
(RATIONAL UNIFIED PROCESS)
Existem várias variantes comerciais do UP disponíveis. Ao se pensar em
termos da UML, o UP define uma classe de processos de desenvolvimento de
software e suas variantes comerciais são como subclasses do UP. Sua variante
comercial mais amplamente utilizada é o RUP (ARLOW & NEUSTADT, 2002).
O RUP é um processo de engenharia de software que tem como objetivo
principal, assegurar a produção de software de alta qualidade que satisfaça às
necessidades de seus usuários finais, dentro de prazos e orçamentos previsíveis. É
38
também uma estrutura de processo que pode ser adaptada e estendida para compor
as necessidades de uma organização (KRUCHTEN, 2003).
Ele se baseia em seis das melhores práticas de desenvolvimento de
software, que são:
• Desenvolver software interativamente;
• Gerenciar exigências;
• Usar arquiteturas baseadas em componentes;
• Modelar visualmente o software;
• Verificar continuamente a qualidade do software; e,
• Controlar mudanças no software.
O RUP, em auxílio às práticas citadas, possui três características muito
importantes que são:
• O papel de casos de uso dirigindo muitos aspectos do desenvolvimento;
• Seu uso como uma estrutura de processo que pode ser adaptada e
estendida por uma organização que o esteja adotando; e,
• A necessidade de ferramentas de desenvolvimento de software para dar
suporte ao processo.
Sua arquitetura global é formada por duas estruturas: o tempo, que mostra
os aspectos do ciclo de vida do processo, como se desdobra e que representa o
aspecto dinâmico do processo como é ordenado, e é expresso em termos de ciclos,
fases, iterações e marcos; e, os fluxos essenciais do processo, que agrupam
logicamente as atividades por natureza e que representam o aspecto estático do
processo, isto é, sua descrição em termos de componentes de processo, atividades,
fluxos, artefatos e trabalhadores.
O Modelo RUP é construído em três entidades fundamentais: o
trabalhador, que pode ser entendido ou considerado como o conjunto de
comportamentos e responsabilidades de um indivíduo ou grupo de indivíduos que
trabalham juntos como uma equipe; a atividade, que é uma unidade do trabalho que
um indivíduo, naquele papel, pode ser pedido a desempenhar e que pode ser
39
expresso em termos da criação ou atualização de artefatos; e, o artefato, que é um
pedaço da informação que é produzida, modificada ou usada por um processo.
A estrutura do ciclo de vida do RUP, isto é, como esse processo se
desenrola com o passar do tempo, se baseia no conceito de desenvolvimento
iterativo, dividindo-se em quatro fases (Figura 3.3.):
Figura 3.3. As quatro fases e marcos do processo iterativo
Fonte: KRUCHTEN, P. Introdução ao RUP Rational Unified Process, Rio de Janeiro – RJ, 2003,
página 52
• O Início, que especifica a visão do produto final e seu caso empresarial, e
define a extensão do projeto. Essa fase tem como meta principal alcançar
o consentimento de todos os interessados nos objetivos do ciclo de vida
para o objeto;
• A Elaboração, que tem como objetivos planejar as atividades necessárias
e recursos exigidos; especificar as características e projetar a arquitetura.
Também tem como propósitos, analisar o domínio de problema,
estabelecer uma fundação arquitetônica sadia, desenvolver o plano de
projeto e eliminar os elementos de alto risco do projeto;
• A Construção, que tem como função construir o produto e evoluir a visão,
a arquitetura e os planos, até o produto estar pronto para entregar à sua
comunidade de usuários;
• A Transição, que inclui fabricar, entregar, treinar, apoiar e manter o
produto até que os usuários estejam satisfeitos. Seu propósito é levar o
produto de software à comunidade de usuário.
No RUP são definidos Workflows de apoio, para suprir lacunas deixadas
pelo UP e auxiliar na execução de seus Workflows principais. São eles:
Início Elaboração Construção Transição
Tempo
Ciclo de vida Ciclo de vida
Operação Inicial Produto
Objetivo Arquitetura
Capacidade Lançamento
Fatos Fatos
Fatos Fatos
40
• A Modelagem de Negócios, que provê um entendimento comum entre as
partes interessadas no sistema sobre quais os processos de negócio que
devem ser apoiados. Ela é feita através dos casos de uso de negócio;
• A Configuração e o Gerenciamento de Mudanças, que controla as
diversas versões dos artefatos produzidos durante o processo, garantindo
sua integridade;
• A Gerência de Projeto, que fornece uma estrutura para a gerência de
projetos, orientações para planejamento, alocação de recursos e gerência
de riscos.
• O Ambiente, que fornece uma descrição para a organização do ambiente
de desenvolvimento em termos de processos e ferramentas.
3.4. UML
A UML é uma linguagem utilizada para especificação, visualização,
construção e documentação de artefatos de sistemas de software, e, também
utilizada para a modelagem de negócios e outros tipos de sistemas. Ela é uma
representação das melhores práticas de engenharia (OMG, 2002 apud AZEVEDO,
2003).
Seus principais objetivos são (OMG, 2002 apud AZEVEDO, 2003):
1. Prover aos usuários uma linguagem de modelagem visual de forma
que eles possam desenvolver e trocar modelos;
2. Prover mecanismos de extensão e especialização para estender o
centro dos conceitos;
3. Ser independente de uma linguagem de programação específica e de
processo de desenvolvimento;
4. Prover uma base formal para o entendimento da linguagem de
modelagem;
5. Incentivar o crescimento de ferramentas de orientação a objeto no
mercado;
6. Suportar o desenvolvimento de conceitos de alto nível como
colaboração, arquiteturas de referência, padrões e componentes;
41
7. Integrar as melhores práticas.
Apesar de padronizar uma notação para descrever modelos, a UML não
padroniza um processo para produzir suas descrições, o que permite que a mesma
possa ser usada por diversos processos de desenvolvimento, mais ou menos
formalmente especificados.
Sua estrutura abrange três tipos básicos de blocos de construção
(BOOCH; JACOBSON; RUMBAUGH, 200 apud AZEVEDO, 2003):
• Os Itens, que são as abstrações identificadas em um modelo;
• Os Relacionamentos, que reúnem esses itens; e,
• Os Diagramas, que agrupam coleções interessantes de itens.
Os itens, na UML, podem ser de quatro tipos:
• Itens Estruturais: São as partes mais estáticas do modelo e representam
seus elementos conceituais ou físicos. Podem ser de sete tipos: Classes,
Interface, Colaborações, Casos de Uso, Classe Ativas, Componentes e
Nós. Esses componentes são os itens estruturais básicos que podem ser
incluídos em um modelo da UML.
• Itens Comportamentais: São as partes dinâmicas dos modelos de UML,
e representam seus comportamentos no tempo e no espaço. São de dois
tipos: Interação e Máquina de Estado. Esses itens costumam estar
conectados a vários elementos estruturais, classes principais,
colaborações e objetos.
• Itens de Agrupamento: São as partes organizacionais dos modelos de
UML e representam os blocos de modelos que podem ser decompostos.
Podem ser do tipo pacote. Esses itens servem para organizar modelos de
UML.
• Itens de Notação: São a partes explicativas dos modelos de UML,
formados por comentários, incluídos para descrever, esclarecer e fazer
uma observação sobre qualquer elemento de modelo, podendo ser de um
único tipo, a Nota. Esse é o único item que pode ser incluído em um
modelo de UML e é utilizado para aprimorar os diagramas com restrições
42
ou comentários que possam ser mais bem expressos por um texto formal
ou informal.
Existem quatro tipos de relacionamentos na UML:
• Dependência: é um relacionamento semântico entre dois itens, nos quais
a alteração de um pode afetar a semântica do outro;
• Associação: é um relacionamento estrutural que descreve um conjunto
de ligações, que são conexões entre objetos;
• Generalização: é um relacionamento de especialização/generalização, no
qual os objetos dos elementos especializados são substituíveis por objetos
do elemento generalizado;
• Realização: é um relacionamento semântico entre classificadores, em que
um classificador especifica um contrato que outro classificador garante
executar.
Os Diagramas da UML são apresentações gráficas de um conjunto de
elementos, geralmente representadas como gráficos de vértices e arcos, que
permitem a visualização de um sistema sob diferentes perspectivas, constituindo sua
projeção, isto é, uma visão parcial de seus elementos. A UML inclui nove diagramas:
• Diagrama de Classes: exibe um conjunto de classes, interfaces e
colaborações, bem como seus relacionamentos;
• Diagrama de Objetos: exibe um conjunto de objetos e seus
relacionamentos;
• Diagrama de Casos de Uso: exibe um conjunto de casos de uso, atores
e seus relacionamentos;
• Diagrama de Iterações: exibe uma iteração, consistindo de um conjunto
de objetos e seus relacionamentos, incluindo as mensagens que podem
ser trocadas;
• Diagrama de Seqüência: é um diagrama de iterações cuja ênfase na
ordenação temporal das mensagens;
• Diagrama de Colaborações: é um diagrama de iterações* cuja ênfase
está na organização estrutural dos objetos que enviam e recebem
mensagens;
43
• Diagrama de Gráficos de Estados: exibem uma máquina de estados,
formada por estados, transições, eventos e atividades;
• Diagrama de Atividades: é um tipo especial de diagrama de Gráfico de
Estado, exibindo o fluxo de uma atividade para outra no sistema;
• Diagrama de Componentes: exibe as organizações e as dependências
existentes em um conjunto de componentes;
• Diagrama de Implantação: mostra a configuração dos nós de
processamento em tempo de execução e os componentes neles
existentes.
Os Adornos são representações gráficas ou textuais de características e
detalhes dos elementos da UML. Eles são necessários porque, pelos elementos da
UML terem uma notação gráfica única e direta, essa notação proporciona uma
apresentação visual de seus aspectos mais importantes podendo deixar de lado
certos detalhes, que podem ser representados pelos adornos.
A UML permite que sua linguagem seja ampliada de uma maneira
controlada, através de mecanismos de extensibilidade, que tem os seguintes
propósitos:
• Adicionar elementos de modelagem na criação de modelos;
• Definir itens padrão não considerados ou complexos demais para serem
modelados diretamente pelos elementos do meta-modelo UML;
• Definir processos específicos ou implementar extensões de linguagens
específicas;
• Unir arbitrariamente informações semânticas e não semânticas a
elementos do modelo.
Esses mecanismos de Extensibilidade incluem:
• Estereótipos, que definem novos blocos construtores na UML, baseados
em blocos existentes;
• Valores Atribuídos, que estendem um elemento da UML através de uma
etiqueta (tag) e um valor (value);
• Restrições, que são regras aplicadas aos modelos UML para apenas um
ou vários de seus elementos.
44
A UML possui um grande potencial de expressão de modelagem, podendo
ser amplamente aplicada através de extensões. Porém, empresas e projetos devem
definir extensões apenas quando for realmente necessário introduzir novas notações
e terminologias. Os conceitos fundamentais não devem ser mudados mais que o
estritamente necessário (OMG, 2002 apud AZEVEDO, 2003).
3.5. CONSIDERAÇÕES FINAIS
Neste capítulo foram apresentadas algumas técnicas para o
desenvolvimento de sistemas de informações. O levantamento de requisitos de
informações e a definição de todas as necessidades de informatização através
dessas técnicas são críticos para o sucesso do produto de software. Para que estas
atividades sejam feitas de forma adequada é necessário que se faça, antes, o
levantamento dos reais objetivos e da funcionalidade dos processos negócios
(ERIKSSON, PENKER, 2000; SILVEIRA et al., 2002) . As informações só têm
sentido, se elas suportarem os processos de negócios, sejam eles gerenciais ou de
manufatura. De forma geral, para o desenvolvimento de ERPs, principalmente no
ambiente de manufatura, é necessário que se utilizem técnicas que considerem a
maioria dos aspectos de uma empresa, como suas funções (processos ou
atividades), seus recursos e sua organização, para que os aspectos de informações
sejam definidos de uma maneira completa (ODEH & KAMM, 2003; SHEN et al.,
2004). Isto pode ser realizado com a utilização de técnicas e ferramentas para a
modelagem de empresas. Algumas das principais são apresentadas no próximo
capítulo.
45
CAPÍTULO 4
MODELAGEM DE EMPRESAS E ARQUITETURAS DE REFERÊNCIA
4.1. MODELAGEM E INTEGRAÇÃO DE EMPRESAS
Condições essenciais para integração se relacionam com o livre, porém
controlado, fluxo de informações e conhecimento, e a coordenação de ações.
Integração é uma maneira de quebrar as barreiras criadas dentro da organização
pelo gerenciamento hierárquico. Um eficaz sistema de informação é, então, uma
condição para a integração e bom funcionamento da empresa. Uma das principais
motivações que justificam a modelagem de empresas é a integração das mesmas,
que têm como objetivos básicos possibilitar a comunicação entre suas várias
entidades funcionais, fornecer interoperabilidade de aplicações de TI e facilitar a
coordenação de entidades funcionais da empresa para a execução dos processos
de negócios e então atingir os objetivos do negócio (VERNADAT, 1996; ERIKSSON
& PENKER, 2000).
Então, um pré-requisito para a Integração de Empresas é a Modelagem de
Empresas, que é o processo de construção de modelos de toda ou de parte dessa
empresa. Um modelo nada mais é do que a representação desta empresa (ou parte
dela), contendo tudo o que esta considerar importante para suas operações
(VERNADAT, 2002; AGUILAR-SAVÉN, 2004).
A Modelagem de Empresas garante a real definição das necessidades e do
fluxo de dados relativos a um sistema de informação, permitindo tomar melhores
decisões sobre a operação, já que o gestor terá uma visão holística da empresa ou
da parte dela que importa no processo. A importância da Modelagem de Empresas
não se resume apenas a uma adequada maneira de levantamento de requisitos de
informações, mas também tem como objetivos principais fornecer modelos que
permitam o melhor entendimento da empresa, bem como, uma representação
uniforme da mesma, além de dar suporte para o projeto de novas partes e permitir o
controle e o monitoramento de suas operações. Além disso, a modelagem permite
que a empresa organize seu conhecimento adquirido de maneira que possa
reutilizá-lo posteriormente. Isto é, a modelagem de empresa é uma ferramenta
46
essencial para análise, projeto e gerenciamento de empresas (KALPIC & BERNUS,
2002; DOUMEINGTS et al., 2000; KIM & JANG, 2002).
Quando se fala em modelar uma empresa, é necessário preocupar-se com “O
que” modelar, “Como” as coisas são realizadas, “Quando” serão realizadas e quais
mudanças elas representam no estado da empresa, “Quem” realizará, “Quanto”
custará para realizar e “Onde” executar. A partir daí, pode-se definir quatro aspectos
básicos a serem modelados: aspectos funcionais, que descrevem “O que” deve ser
feito; aspectos comportamentais, que descrevem “Como” e “Quando” algo pode ser
feito; aspectos de informação, que definem os dados que serão usados ou
produzidos e seus relacionamentos; e os aspectos organizacionais, indicando
“Quem” deve fazer e “Onde”(VERNADAT, 1996).
Qualquer técnica de modelagem deve considerar alguns princípios básicos
como qual o objetivo do modelo, qual seu escopo, quais os aspectos da empresa
serão considerados e qual seu grau de detalhamento. Além desses princípios, para
a modelagem de empresa, é necessário considerar o assunto a ser tratado pelo
modelo, isto é, analisar a empresa por áreas ou domínios de atuação, possibilitando
uma quebra na sua complexidade. Como empresas são sistemas complexos e
dinâmicos definidos pela sua funcionalidade, funções maiores devem ser
decompostas em sub-funções, e essas em sub-sub-funções, e assim
sucessivamente, quebrando os objetivos de negócios em sub-objetivos, e então em
sub-sub-objetivos.
4.2. ARQUITETURAS DE REFERÊNCIA
Para definir uma metodologia de modelagem para a empresa, é importante a
escolha de uma Arquitetura de Referência que atenda às necessidades do Projeto
da Empresa e que, com sua utilização, os gestores sejam capazes de entender,
definir, especificar, analisar e implementar processos de negócios para todo ciclo de
vida da empresa, já que esse é o principal objetivo da Engenharia de Empresas.
Mas, “O que é Arquitetura de Referência?”.
47
A Arquitetura de Referência pode ser definida como sendo um conjunto de
padrões, criado para facilitar a análise, a discussão e a especificação de uma
determinada área de estudo. Ela é formada por modelos que descreve os vários
aspectos da empresa, em diferentes níveis de modelagem, e é usada para auxiliar o
gestor no processo de construção de sua própria arquitetura particular (VERNADAT,
1996; BERNUS & NEMES, 1997; MERTINS & JOCHEM, 2005).
Em geral, as arquiteturas de referência são constituídas por uma camada
genérica, formada de construtores da linguagem de modelagem, seus tipos e regras
de instanciação e derivação; e por uma camada de modelos parciais, que se
constitui de uma biblioteca desses modelos, podendo os mesmos ser adaptados às
necessidades específicas da empresa. Uma de suas funções chave, segundo
KOSANKE et al. (2000) é determinar quais características da empresa é necessário
analisar para alcançar um degrau a mais no aperfeiçoamento da integração da
empresa. Seus elementos seriam um sistema que indicaria as partes chaves na
empresa que deveriam ser consideradas, quando da criação, análise ou utilização
de um modelo de empresa. Este modelo de empresa fornecerá ao executivo ou
operador, humano ou máquina, um mapa da empresa e várias informações de quais
funções ela engloba, em qual estágio estão, e que capacidade existe, num
determinado momento, para efetuar uma saída.
Os padrões são importantes no processo de representação de empresas, e
por isso muitas arquiteturas de referência vêm sendo propostas, das quais podemos
destacar:
I. Trabalhos de Padronização na ISO;
II. CEN ENV 40 003;
III. GIM;
IV. PERA;
V. ARIS;
VI. CIMOSA; e,
VII. GERAM.
48
4.2.1. T
RABALHOS DE PADRONIZAÇÃO NA ISO
Um dos modelos de referência proposto pela ISO, está documentado no
Relatório Técnico ISO 10 314, que apesar de não ser um padrão, sugere uma
estrutura conceitual para a compreensão da manufatura de peças discretas; e pode
ser usado para identificar áreas de padronização necessárias para integrar sistemas
de manufaturas. Esse relatório é dividido em duas partes: a primeira descreve o
modelo de referência e uma metodologia para identificar as padronizações
necessárias na automação industrial; e a segunda, preocupa-se com a aplicação do
modelo de referência e da metodologia (VERNADAT, 1996).
O modelo de referência proposto se divide em três sub-modelos:
• Um Contexto para a Produção de Chão de Fábrica, que identifica suas
maiores funções e os maiores fluxos de informação entre essas funções;
• Um Modelo de Produção de Chão de Fábrica, que representa uma
hierarquia de atividades da produção do chão de fábrica, dividida em
quatro níveis, como apresentado na Tabela 4.1. Ele não é exatamente um
modelo, mas, apesar de não representar algo, é usado como referência
para fixar idéias e terminologias;
• O Modelo Genérico de Atividade (GAM) que descreve as atividades
encontradas em cada nível do modelo de produção de chão de fábrica e
os fluxos entre elas (Figura 4.1.).
Nível Sub-Atividade Responsabilidade
4
Seção
Área
Supervisionar a produção
Supervisionar e coordenar a
produção e suportar as operações
(jobs) e obter e alocar recursos
para as operações
3 Célula Coordenar processos de produção
Seqüenciar e supervisionar as
operações no processo de
produção
2 Estação Comandar o processo de produção Processo de produção
1 Equipamento Executar o processo de produção
Executar a operação de produção
de acordo aos comandos
Tabela 4.1. Modelo de produção do chão de fábrica.
Fonte: Adaptado de VERNADAT, FRANÇOIS B. Enterprise Modeling and Integration, Principles
and Aplications, Londres, Chapman & Hall, 1996, página 34
49
Figura 4.1. Modelo Genérico de Atividade.
Fonte: Adaptado de VERNADAT, FRANÇOIS B. Enterprise Modeling and Integration, Principles
and Aplications, Londres, Chapman & Hall, 1996, página 35
Além do modelo anterior, o grupo de trabalho WG1, que é o grupo
responsável pela área de desenvolvimento de padrões na ISO, está criando um guia
na área de representação de empresas para ajudar a planejar e priorizar os
trabalhos de padronização de empresas. A primeira tentativa de identificar as áreas
onde os padrões são necessários é representada pela Figura 4.2., na qual
identificam-se os padrões disponíveis, o estado da arte na padronização, itens de
trabalhos futuros e os padrões relacionados (KOSANKE; NELL, 1999).
Figura 4.2. Um Guia para Padronizações em Engenharia e Integração de Empresas
Fonte: KOSANKE, K.; NELL, J.G. Standardisation in ISO for Enterprise Engineering and
Integration, USA, 1999 página 4
Transporte / Transformação /
Verificação / Armazenamento
Informação Recursos
Material Material
Informação
Informação
Recursos
Recursos
Informação Recursos
ISO 14258:
Conceitos e Regras para Modelos de Empresa
ITF: Conceitos e Regras para
Infraestruturas
Padrões Relacionados
ISO 15704:
Requisitos para Arquiteturas de Referência de Empresa
Estado da Arte: GERA, Estrutura de Modelagem ENV 40003
ITF: Representação
Relacionadas a Humanos
ITF: Representação do Processo
ISO 9000
ITF
:Infra-estrutura de Integração
Estado da Arte: EMEIS
ENV 12204
Construtores para Modelagem
ITF:
Papéis Humanos
CEN IT:
Serviços de
Desenvolvimento de
ISO 14000
Modelos
ITF: Ícones para
Construtores de Modelagem
ITF: Representação de TI
Construtores de Modelagem
ITF:
Comportamento
Humano
CEN IT:
Serviços de
Execução de Modelos
ODP
ITF:
(Conhecimento
Humano?)
CEN IT:
Serviços Gerais
de TI
Outros
Legenda:
IT = Itens de Trabalho
ITF = Itens de Trabalho
Futuro
50
O WG1 produziu também o padrão ISO 14258, Conceitos e Regras para
Modelos de Empresas, que é um padrão de alto nível que define a natureza dos
modelos de empresa com a visão de que modelos compatíveis podem ser usados
para projetar, analisar e operar em empresas. Esse padrão se baseia na Teoria
Clássica dos Sistemas, que considera a empresa como um sistema, sendo que esta
pode ser projetada e analisada como tal. Outro padrão que vem sendo desenvolvido
pelo WG1, é o ISO 15704, Requisitos para Metodologias e Arquiteturas de
Referência de Empresas, cujo resultado foi a proposta do GERAM (IFIP-IFAC,
1999), a ser usada neste trabalho e detalhada mais adiante. Este padrão será útil
para guiar o processo de criação de uma arquitetura própria de empresas, destinada
a uma companhia ou indústria, ou para, melhorar a infra-estrutura de uma empresa
ou de seus processos. Ela ajudará a cumprir todos os tipos de projetos de criação da
empresa, ou melhorias incrementais, neste caso afetando apenas, parte de seu ciclo
de vida (KOSANKE; NELL, 1999).
4.2.2. CEN ENV 40003
Um trabalho semelhante ao apresentado na sessão anterior, foi o
desenvolvido pelo Comitê Europeu para Padronização (CEN), o ENV 40003,
Estrutura para Modelagem de Empresas, que determina uma estrutura para
atividades de padronização futura, na área de modelagem de empresa CIM
(VERNADAT, 1996). Esse trabalho é uma implementação prática das necessidades
citadas pelo ISO 15704. Ele define diferentes camadas para guiar a estruturação e o
desenvolvimento de padrões futuros para a modelagem de empresas, e se estrutura
de acordo com três dimensões: a Dimensão de Generalidades, a Dimensão de
Modelos e a Dimensão de Vistas, similar à estrutura de modelagem CIMOSA
(sessão 4.2.6.).
4.2.3. GIM – GRAI INTEGRATED METHODOLOGY
Uma outra arquitetura de referência que vem sendo proposta é a GIM –
GRAI Integrated Methodology, que é resultante da integração entre o GRAI
51
(Graphes à Resultats et Activités Interreliés), que é um método para modular e
analisar sistemas de manufatura automáticos, e Merise, que é uma metodologia para
análise e projeto de sistemas de informação (DOUMEINGTS et al., 2000;
VERNADAT, 1996).
Em sua raiz essa arquitetura apresenta um modelo conceitual que
considera que toda empresa é formada por quatro sub-sistemas:
• Um sistema físico que é composto por estações de trabalho formadas por
máquinas, trabalhadores, peças, componentes, etc, e é responsável por
transformar o fluxo de materiais;
• Um sistema operacional que controla o sistema físico em tempo real;
• Um sistema de decisões que é responsável pela tomada de decisões na
empresa, através de uma hierarquia organizada em níveis, formados por
centros de decisão; e,
• Um sistema de informação que transforma e guarda as informações e
possibilita a integração entre o sistema de decisão, o sistema físico e o
ambiente da empresa.
O método utilizado na arquitetura GRAI está baseado em duas
ferramentas (construtores) de modelagem:
• As grades GRAI que, quando utilizadas, realizam uma análise top-down do
domínio da empresa que está sendo estudado e se baseiam na análise
das relações entre os centros de decisão em termos de fluxo de
informações e de decisões; e,
• As redes GRAI que, ao serem usadas na análise dos centros de decisão
em termos de suas atividades, dos seus recursos de suporte e dos seus
objetos de entrada e saída, validam a análise realizada pelas grades
GRAI, já que estas realizam uma análise bottom-up do sistema estudado.
A metodologia GIM é uma tentativa de estender o método GRAI para
cobrir toda a estrutura dos sistemas de empresa. Ela se baseia em três níveis de
abstração, inspirados no Merise:
52
• O nível conceitual que modela a empresa, desconsiderando seus aspectos
técnicos ou organizacionais, numa tentativa de determinar “O que” realizar
na empresa;
• O nível organizacional ou estrutural, onde os aspectos organizacionais são
considerados, tentando determinar “Quem”, “Quando” ou “Onde” realizar;
e,
• O nível físico ou de realização, que procura considerar as restrições
técnicas do sistema, possibilitando uma escolha de componentes reais a
serem construídos.
A GIM considera, ainda, três vistas de modelagem: a vista de modelagem
de dados ou informações; a vista de modelagem de processos; e, a vista de
modelagem dos aspectos operacionais da empresa.
Na Tabela 4.2. é apresentada a estrutura de modelagem GIM onde, cada
uma de suas células é chamada de modelo, correspondendo à um submodelo de
todo o modelo da empresa. As maiores fases de seu método são apresentadas na
Tabela 4.2.
NÍVEIS DE
ABSTRAÇÃO
VISTAS
Informação Decisão Físico Funcional
Organização
Tecnologia
de Informação
Tecnologia
de Manufatura
Estrutura de Modelagem:
Parte Orientada à Tecnologia
Estrutura de Modelagem:
Parte Orientada ao Usuário
Conceitual
Estrutural
Realizacional
Tabela 4.2. Estrutura de Modelagem GIM.
Fonte: Adaptado de VERNADAT, FRANÇOIS B. Enterprise Modeling and Integration, Principles
and Aplications, Londres, Chapman & Hall, 1996, página 51
53
SISTEMA
REQUISITOS
DO USUÁRIO
Figura 4.3. Método Estruturado GIM.
Fonte: Adaptado de VERNADAT, FRANÇOIS B. Enterprise Modeling and Integration, Principles
and Aplications, Londres, Chapman & Hall, 1996, página 54
ESPECIFICAÇÕES ORIENTADAS
PELOS USUÁRIOS
REQUISITOS DE USUÁRIOS
CONSOLIDADOS
ANÁLISE DA
VISTA
FÍSICA
DETECÇÃO DE
INCONSISTÊNCIA
E
XISTENTE
INICIALIZAÇÃO
DEFINIÇÃO DO DOMÍNIO
DE ESTUDO
(Primeiro Nível de Modelo Funcional)
ANÁLISE DA
VISTA
DECISIONAL
ANÁLISE DA ANÁLISE DA
VISTA VISTA DE
INFORMAÇÃO
FUNCIONAL
FASE DE ANÁLISE
PROJETO DA
VISTA
FÍSICA
PROJETO DA
VISTA
DECISIONAL
PROJETO DA PROJETO DA
VISTA DE
INFORMAÇÃO
VISTA
FUNCIONAL
PROJETO ORIENTADO
AO USUÁRIO
ESPECIFICAÇÕES
TECNICO-ORIENTADAS
PROJETO DA
MANUFATURA
PROJETO DA
ORGANIZAÇÃO
PROJETO DA
INFORMAÇÃO
PROJETO ORIENTADO
À TECNOLOGIA
IMPLEMENTAÇÃO
54
4.2.4. PERA
A arquitetura de referência PERA – Purdue Enterprise Reference
Architecture (LI; WILLIAN, 2002; VERNADAT, 1996) é caracterizada por uma
estrutura em camadas, que tem como objetivo, cobrir todo o ciclo de vida da
empresa. Cada uma das camadas de sua estrutura define uma fase de tarefa, que
pode ser definida como um conjunto de procedimentos que tem como função,
orientar as aplicações dos usuários durante os procedimentos de integração da
empresa. Ela é uma metodologia completa e de fácil entendimento, pois é projetada
para que qualquer usuário, mesmo que não tenha conhecimentos em ciências de
computação, seja capaz de aplicá-la para sua empresa.
A aplicação da metodologia se inicia com a identificação, por parte da
gerência da área da empresa a ser estudada, e, então, se define a missão da
empresa em relação aos produtos e/ou serviços que serão oferecidos. Dando
continuidade, são definidos os requisitos básicos necessários à política de
informação, pessoal de manufatura, produto e unidade de manufatura. Após define-
se, também, os requisitos funcionais da empresa, isto é, são definidos os
instrumentos e os diagramas de controle, os requisitos de gerenciamento e o layout
da planta. Em conseqüência dos passos anteriores, é alcançada, nesse momento, a
fase de instalação de equipamentos, pessoal e organização da empresa (staffing),
treinamento e construção da planta, estando a mesma pronta para a operação, que
é a fase onde esta se desenvolve e seus processos podem ser afirmados, sofrendo
manutenção constante. O processo só termina com a obsolescência da empresa.
Essa metodologia e sua divisão em camadas é mostrada na Figura 4.4,
onde também pode ser observada a distinção feita por ela em consideração ao
sistema de informação, sistema organizacional e humano, e sistemas de
equipamentos de manufatura. Os aspectos humanos são totalmente cobertos por
essa metodologia que, por não fornecer suas próprias ferramentas de modelagem,
pode ser aplicada em parceria com qualquer técnica/linguagem de modelagem de
empresa.
55
IDENTIFICAÇÃO DA
ENTIDADE DE NEGÓCIOS
CIM
CAMADA DE CONCEITO
(MISSÃO, VISÃO E
VALORES)
CAMADA DE
DEFINIÇÃO
(Requisitos Funcionais)
CAMADA DE
ESPECIFICAÇÃO
(Projeto Funcional)
CAMADA DE
PROJETO DE TRABALHO
CAMADA DE
MANIFESTAÇÃO
CAMADA DE
OPERAÇÕES
Figura 4.4. Estrutura PERA
Fonte: Adaptado de VERNADAT, FRANÇOIS B. Enterprise Modeling and Integration, Principles
and Aplications, Londres, Chapman & Hall, 1996, página 56
Figura 4.5. Derivação dos requisitos de informação e manufatura
Fonte: Adaptado de VERNADAT, FRANÇOIS B. Enterprise Modeling and Integration, Principles
and Aplications, Londres, Chapman & Hall, 1996, página 57
ARQUITETURA
DE INFORMAÇÃO
ARQUITETURA
DE MANUFATURA
ARQUITERURA DE
SISTEMAS DE
INFORMAÇÃO
ARQUITERURA DE
ORGANIZAÇÃO
HUMANA
ARQUITERURA DE
EQUIPAMENTO DE
MANUFATURA
REQUISITOS
FUNCIONAIS
DE INFORMAÇÃO
REQUISITOS
FUNCIONAIS
DE MANUFATURA
56
4.2.5. ARIS
A arquitetura de empresa ARIS (Architecture for Integrated Information
Systems), é uma arquitetura que se dedica às questões ligadas aos negócios da
empresa e tem seu foco na engenharia de softwares e aspectos organizacionais no
projeto de integração de sistemas de empresa (SCHEER, 2000). Sua estrutura é
formada pela Vista de Função, Vista de Dados, Vista de Organização, Vista de
Controle e por três níveis de modelagem, equivalentes aos de CIMOSA. É uma
arquitetura aberta, onde seus formalismos não são fixos (Figura 4.6).
DEFINIÇÃO DE
REQUISITOS
ORGANIZAÇÃO
E
SPECIFICAÇÃO
DE
PROJETO
D
ESCRIÇÃO DA
IMPLEMENTAÇÃO
D
EFINIÇÃO DE
REQUISITOS
D
EFINIÇÃO DE
REQUISITOS
D
EFINIÇÃO DE
REQUISITOS
E
SPECIFICAÇÃO
DE
PROJETO
E
SPECIFICAÇÃO
DE
PROJETO
E
SPECIFICAÇÃO
DE
PROJETO
D
ESCRIÇÃO DA
IMPLEMENTAÇÃO
D
ESCRIÇÃO DA
IMPLEMENTAÇÃO
D
ESCRIÇÃO DA
IMPLEMENTAÇÃO
DADOS CONTROLE FUNÇÕES
Figura 4.6. Estrutura de Modelagem da Arquitetura ARIS
Fonte: SCHEER, A. ARIS – Business Process Modeling. 3ª ed., Berlim: Springer – Verlag, 2000.
4.2.6. CIMOSA
CIMOSA é uma arquitetura de empresa baseada em sistemas abertos,
desenvolvida pela associação AMICE e outros colaboradores. Seu objetivo é ajudar
empresas a gerenciar mudanças e integrar seus recursos e operações, tornando-as
mais competitivas. Para chegar a isso, ela oferece uma estrutura para a modelagem
e integração de empresa, compreendendo uma visão geral do escopo e da natureza
do sistema de integração, guias para sua implementação, uma descrição dos
57
sistemas e subsistemas que o constitui e uma estrutura em módulos, que é
compatível aos padrões internacionais (VERNADAT, 1996).
Essa arquitetura tem ajudado a promover o termo “processos de negócios”
(business process) e introduzido a análise baseada em processos para a
modelagem e integração de empresas ultrapassando os limites da organização,
oposto à análise baseada em funções ou atividades. Ela também introduz a idéia de
arquitetura de sistemas abertos para empresas CIM, constituídos de módulos
padrões, descritos em termos de seus aspectos funcionais, de informação, de
recursos, e aspectos organizacionais, projetados de acordo com um método
estruturado de engenharia. Assim, sistemas de empresa baseados nessa arquitetura
são compatíveis entre si, independente do fornecedor, e podem ser conectados uns
aos outros, de acordo com as necessidades dos usuários.
A arquitetura CIMOSA é constituída por três componentes básicos: (i) uma
Estrutura de Modelagem de Empresa; (ii) uma Infra-estrutura de Integração; e, (iii)
um Ciclo de Vida de Sistema a CIM. Ela possui, ainda, dois ambientes fundamentais:
um, onde os novos modelos de empresa são construídos, ou os já existentes são
reprojetados (Ambiente de Engenharia de Empresa); e outro, onde os modelos são
usados para dar suporte, controlar ou monitorar as operações da empresa, durante o
ciclo da vida do produto (Ambiente de Operações de Empresa).
Um conceito fundamental para essa arquitetura é o de Entidades
Funcionais, que são todos os recursos ativos, dentro ou fora da empresa, capazes
de executar operações básicas de uma atividade, tais como, mandar, receber, ou
processar mensagens. As Entidades Funcionais têm capacidade de processamento
para serem capazes de reagir a estímulos mandados para elas na forma de
mensagens. Elas precisam ser acessadas por uma linguagem e podem executar
ações básicas na operação.
CIMOSA define três tipos de entidades funcionais: as máquinas, o que
inclui os equipamentos de manufatura e os de informação; as aplicações, que são os
pacotes de softwares; e os humanos, que formam o mais importante e difícil tipo de
entidade funcional, pois, apesar de ser capaz de resolver problemas inesperados,
esse tipo de entidade funcional introduz muito indeterminismo no modelo.
58
A combinação de entidades funcionais ou a combinação de um recurso
passivo (tal como uma ferramenta) com uma entidade funcional forma, também, uma
nova entidade funcional.
Além de poderem ser acessadas por protocolos externos (linguagem),
receber e mandar mensagens, as entidades funcionais podem interagir umas com as
outras, como é mostrado na Figura 4.7.
Entidade Funcional 1
Armazenagem
Processo
Envio
Recebimento Envio
Recebimento
Armazenagem
Processo
Entidade Funcional 2
Canal de
Comunicação
Transações
Suportadas pela
Infra-estrutura de Integração
Resposta
Requisição
Figura 4.7.
Integrações entre Entidades Funcionais.
Fonte: Adaptado de VERNADAT, FRANÇOIS B. Enterprise Modeling and Integration, Principles
and Aplications, Londres, Chapman & Hall, 1996, página 43
Isso justifica a necessidade e existência da Infra-estrutura de Informação
de CIMOSA, que proporciona um canal de comunicação adequado, que possibilita e
dá suporte às trocas de mensagens das entidades funcionais e coordena suas
ações através da modelagem da empresa.
4.2.6.1.1. INFRA-ESTRUTURA DE INTEGRAÇÃO
A Infra-estrutura de Integração de CIMOSA é um conjunto de serviços
básicos de TI usados para possibilitar a integração de sistemas multi-fornecedores,
comunicação e interoperabilidade. Seu propósito é transformar um ambiente
heterogêneo, altamente distribuído, em um ambiente que trabalha de forma
centralizada [...] e homogênea [...]. (VERNADAT, 1996).
59
4.2.6.1.2. E
STRUTURA DE MODELAGEM CIMOSA
A Estrutura de Modelagem CIMOSA descreve a empresa através da
utilização de blocos de construção consistentes e que cobrem seus variados
aspectos (SHORTER, 1999; BERIO & VERNADAT, 1999).
Vista de Organização
Vista de Recursos
Vista de Informação
Vista de Função
G
ER
A
Ç
Ã
O
PARTICULARIZAÇÃO
DERIVAÇÃO
Nível de Modelagem
de Definição de Requisitos
Nível de Modelagem
de Especificação de Projeto
Nível de Modelagem
de Descrição de Implementação
Arquitetura
de Referência
Arquitetura
Particular
Blocos de
Construção
Genéricos
Modelos
Parcias
Modelo
Particular
Genérico
Parcial
Particular
Figura 4.8.
Estrutura de Modelagem CIMOSA (ou cubo CIMOSA).
Fonte: Adaptado de VERNADAT, FRANÇOIS B. Enterprise Modeling and Integration, Principles
and Aplications, Londres, Chapman & Hall, 1996, página 45
Ela é constituída de duas partes: uma arquitetura particular, formada por
um conjunto de modelos que documentam o ambiente da empresa, desde a análise
dos requisitos até a sua implementação; e, uma arquitetura de referência, que serve
para ajudar o usuário no processo de construção de sua arquitetura particular.
Essa estrutura é baseada em três princípios (VERNADAT, 1996):
• O princípio de derivação, que sugere a modelagem de empresas de
acordo com três níveis sucessivos:
a) definição de requisitos, que expressa as necessidades do negócio na
visão do usuário;
b) especificação de projeto, que constrói um modelo formal, conceitual e
executável do sistema da empresa, considerando o tempo; e,
60
c) descrição da implementação, que documenta detalhes e mudanças na
implementação, recursos instalados e mecanismos de gerenciamento
de exceções.
• O princípio da Particularização, que se baseia em três camadas:
a) uma camada genérica, que contém blocos de construção genéricos e
tipos de blocos de construção, tais como as construtoras da linguagem
de modelagem, para expressar modelos;
b) uma camada parcial, que contém uma biblioteca de modelos parciais,
classificados por setores da empresa, para serem copiados e usados
em modelos particulares; e,
c) uma camada particular, que contém os modelos particulares
específicos de uma determinada empresa.
• O princípio de geração, que define quatro pontos de vista básicos e
complementares:
a) a vista de função, que representa a funcionalidade e comportamento da
empresa, incluindo aspectos temporais e de gerência de exceções;
b) a vista de informação, que representa os objetos da empresa e seus
elementos de informação;
c) a vista de recursos, que representa os meios da empresa, suas
capacidades e seu gerenciamento;
d) a vista de organização, que representa níveis organizacionais,
autoridades e responsabilidades.
No centro de sua estrutura, CIMOSA apresenta um método de modelagem
baseado em processos dirigidos por eventos, que é a base de sua linguagem de
modelagem, composta de blocos e elementos de construção para as vistas citadas
anteriormente. CIMOSA considera as operações da empresa como um conjunto de
processos de negócios, executados por agentes que necessitam ser coordenados
apropriadamente.
61
4.2.6.1.3. C
ICLO DE VIDA DA EMPRESA
O ciclo de vida para os Sistemas CIM, é definido em CIMOSA como uma
seqüência de fases a serem seguidas para se construir uma arquitetura particular,
que vai da definição de requisitos até a instalação do sistema, seu teste e liberação,
e sua posterior manutenção. Esse ciclo de vida compreende as seguintes fases
(VERNADAT, 1996):
• Definição do Plano Mestre: definição de todos os objetivos do negócio, restrições
e guia para a estrutura organizacional;
• Definição de Requisitos: definição precisa de todos os processos e objetos da
empresa para cada um de seus domínios;
• Projeto do Sistema: especificação detalhada de todas as atividades da empresa
com determinação de recursos e tempos necessários, tratamento de exceções e
requisitos organizacionais, como também, estruturas de sistemas de informação;
• Construção do Sistema e Liberação: decisão de compra ou construção para os
componentes do sistema (hardware e software), instalação, testes de
conformidade e liberação para operação;
• Operação do Sistema: uso diário do sistema;
• Manutenção do Sistema e Mudanças: modificações do sistema, adição de novos
módulos, reengenharia de processos de negócios; e,
• Desmantelamento da Empresa: fim das operações do sistema.
4.2.6.2. P
ROCESSO DE MODELAGEM CIMOSA
Uma metodologia é um conjunto de métodos, modelos e ferramentas que
são usadas de modo estruturado para resolver um problema. Um método é
organizado em fases metodológicas e fases em tarefas. Fases, tarefas, métodos e o
uso de modelos devem ser documentados como parte da metodologia (VERNADAT,
1996).
As relações entre o Ciclo de Vida de Sistema da Empresa e o progresso
do processo de modelagem da empresa são ilustradas na Figura 4.9 (VERNADAT,
1996; KOSANKE, 1999). Como pode se perceber, a metodologia de modelagem é
62
descrita como se fosse um processo, constituido de um conjunto de atividades de
modelagem. Iniciando com os objetivos e restrições da empresa e usando os
construtores de modelagem fornecidos pela Arquitetura de Referência CIMOSA, os
requisitos do sistema são definidos no Modelo de Definição de Requisitos particular
(MDR). Este modelo é a base para o projeto do sistema. O projeto do sistema é
representado pelo Modelo de Especificação de Projeto particular (MEP), derivando
as especificações do MDR, reutilizando e adicionando novos elementos de
modelagem aos construtores do MDR. O sistema operacional é construído de
acordo com as especificações do MEP. A descrição do sistema operacional
implementado, incluindo todas as modificações de projeto do sistema, é
documentada no Modelo de Descrição da Implementação (MDI).
Para a obtenção dos modelos particulares (MDR, MEP, MDI) durante o
ciclo de vida da empresa é necessária uma metodologia para caminhar através da
Estrutura de Modelagem CIMOSA de modo consistente e otimizado, e aplicar seus
construtores (ou seja sua linguagem) devidamente para obter modelos particulares.
Assim, CIMOSA fornece a descrição de uma metodologia para modelagem chamada
Processo de Modelagem CIMOSA. Nesta seção, um processo de modelagem
simplificado, apresentado por CAMPOS (1998) baseado no Processo de Modelagem
CIMOSA, será apresentado como um conjunto de sub-processos decompostos em
outros sub-processos. A Figura 4.10. mostra os maiores sub-processos de
modelagem. Cada um desses sub-processos produzem um dos modelos (MDR,
MEP, e MDI). Uma descrição detalhada do processo de modelagem CIMOSA é
fornecida por CIMOSA Association (1996).
63
Arquitetura
de Referência
CIMOSA
Modelo da
Definição de
Requisitos
Particular
Modelo da
Especificação de
Projeto Particular
Modelo de
Descrição da
Implementação
Particular
Definição de
Requisitos do
Sistema
Especificação
de Projeto
do Sistema
O bjetivos e
Restrições do
Sistema
Entidades
Funcionais
Especificadas
Entidades
Funcionais
Instaladas
Entidades
Funcionais
Verificadas
Construção e
Liberação do
Sistema
Compra/
Construção
Verificação
Instalação
Liberação
Ambientes
da Empresa
Engenharia
Manutenção/
Mudança do
Sistema
Modelo
Modificado
Entidades
Funcionais
Modificadas
Engenharia
Modelo de
Descrição da
Implementação
Liberada
Operação do
Sistema
Entidades
Funcionais
Liberadas
Operação
Modelos
Ciclo de Vida
do Sistema
da Empresa
Mundo
Real
Figura 4.9. Relações entre o Ciclo de Vida CIMOSA e Modelos (KOSANKE, 1995).
Fonte: CAMPOS R.
Uma Proposta de Modelagem para Integração de Sistemas de Gestão de
Produção em Empresas de Manufatura
, Campinas – SP, 1998.
Processo de Modelagem de Empresa
Processo de Modelagem de Empresa
P1 - Modela
g
em da
Definição
de Re
q
uisitos
P2 - Modela
g
em da
Es
p
ecificação
de Pro
j
eto
P3 - Modela
g
em da
Descrição da
Im
p
lementação
PLANO
DIRETOR
MDR
MEP MDI
Figura 4.10. Principais etapas do Processo de Modelagem CIMOSA.
Fonte: CAMPOS R.
Uma Proposta de Modelagem para Integração de Sistemas de Gestão de
Produção em Empresas de Manufatura
, Campinas – SP, 1998.
Um maior detalhamento sobre as fases do processo de Modelagem de
Empresas, se envontra no Anexo I, no final deste trabalho.
64
4.2.6.3. L
INGUAGEM CIMOSA
A Linguagem de Modelagem CIMOSA é fornecida pela camada genérica
da Arquitetura de Referência CIMOSA e é composta de blocos e elementos de
construção para as vistas de função, informação, recursos e organização
(SHORTER, 1999; BERIO & VERNADAT, 1999; CIMOSA Association, 1996).
Um modelo CIMOSA é um conjunto consistente de construtores que,
quando completo, deve ser auto-explicativo e fornecer uma documentação precisa
das operações da empresa (CAMPOS, 1998). Seus principais construtores de
linguagem são apresentados a seguir.
• Vista de Função
CIMOSA utiliza-se de vários construtores para a modelagem funcional.
o O Domínio, que é constituído por um conjunto de processos centrais da
empresa, que satisfazem os objetivos e restrições da empresa;
o Os Eventos, que representam qualquer acontecimento solicitado ou
não solicitado da empresa requisitando algum processamento;
o Os Processos de Domínio, que indicam a seqüência de atividades da
empresa a ser executada para realizar o comportamento desejado por
ela;
o Os Processos de Negócios, que, apesar de serem similares a
processos de domínio, não podem ser disparados apenas por eventos,
necessitando ser acionados por um processo de domínio ou de
negócios de um nível mais alto. Suas condições de término devem ser
definidas através de estados finais, que são valores definidos pelo
usuário que caracterizam o estado final de execução do processo ou
atividade;
o As Atividades de Empresa, que definem a funcionalidade do sistema,
isto é, as coisas a serem realizadas pelo sistema. Essas atividades
representam um conjunto de ações elementares a ser considerado
como um todo, necessitando de recursos e tempo para sua execução;
o As Operações Funcionais, que são as unidades de funcionalidade e
não podem ser decompostas. Essas operações e seus argumentos são
65
especificados no construtor de entidade funcional da Vista de
Recursos.
• Vista de Informação
Seus dois principais construtores são:
o Os Objetos de Empresa, que representam entidades do mundo real da
empresa, possuindo uma identidade e existência própria. São
caracterizados por seu ciclo de vida e são descritos por um conjunto de
propriedades intrínsecas.
o As Vistas de Objetos, que são a imagem ou aparência do estado de um
ou mais objetos de empresa em um dado instante, podendo ser
classificadas como: Vistas de Objetos de Informação, referindo-se a
dados de objetos do mundo real; e, Vistas de Objetos Físicos,
referindo-se a objetos concretos.
Em termos matemáticos, uma vista de objeto pode ser definida como a
projeção de um ou mais elementos de informações de objetos de empresa sobre
alguns de seus elementos de informação (CAMPOS, 1998).
• Vistas de Recursos
Nessa vista a empresa é considerada como um conjunto de entidades
funcionais interconectadas, as quais podem enviar requisições e executar operações
funcionais. Ela é constituída de dois construtores essenciais:
o Conjunto de Capabilidades, que é constituído de elementos de
capabilidade que referem-se à funcionalidade de uma atividade de
empresa ou de um recurso;
66
o Os Recursos, que são classificados em:
Entidades Funcionais, que são recursos ativos capazes de executar
operações funcionais de uma atividade e fazer algum papel no
curso do processo; e,
Componentes, que são os recursos passivos, isto é, objetos que
não proporcionam funcionalidades por si só, precisando ser usados
ou manipulados por entidades funcionais, tornando-se, assim, parte
de uma entidade funcional agregada como, por exemplo,
ferramentas, equipamentos de medição e veículos dirigidos
manualmente.
• Vista de Organização
Seu objetivo é distribuir responsabilidades e autoridades sobre os vários
componentes das outras vistas e organizar essas responsabilidades e autoridades
em níveis organizacionais de estruturas hierárquicas de organização. Ela fornece
dois construtores:
o A Unidade de Organização, que é definida por uma lista de
capabilidades, responsabilidades e autoridades dentro de uma
estrutura de organização, associada e descrita por uma função de
tomada de decisão ou solução de problemas. Seu papel é tomar ações
apropriadas quando elementos do modelo sob sua responsabilidade
estão em problemas.
o A Célula de Organização, que é uma agregação de unidades de
organização e/ou células de organização, definindo uma área
organizacional da estrutura de organização.
Define, também, dois elementos de construção associados:
o A Responsabilidade, que é uma atribuição fornecida a uma unidade de
organização para tomar decisões e/ou ações em uma dada área de
competência; e,
67
o A Autoridade, que é uma atribuição fornecida a uma unidade de
organização para tomar decisões sobre outras unidades de
organização.
4.2.7. GERAM – ARQUITETURA DE REFERÊNCIA E METODOLOGIA GENERALIZADA
DE
EMPRESA
A arquitetura GERAM – Generalized Enterprise Reference Architecture
and Methodology (BERNUS; NEMES, 1994; WILLIAMS, 1995, apud VERNADAT,
1996) é uma generalização da GIM, da PERA e da CIMOSA, que se utiliza das
melhores partes dessas arquiteturas, com o intuito de servir como referência para
todos os envolvidos na área de integração de empresa. Para isso ela fornece
definições da terminologia, um ambiente de modelagem consistente, uma
metodologia detalhada, promovendo uma boa prática de engenharia, para a
construção de métodos reusáveis, testados e padronizados, e fornecendo uma
perspectiva unificada de produtos, processos, gerência, desenvolvimento de
empresas e gerenciamento estratégico (VERNADAT, 1996).
Ela é constituída por sete componentes considerados como essenciais
para a integração de empresas.
GERAM fornece uma descrição de todos os elementos recomendados na
engenharia e integração de empresas e assim prepara o padrão para a coleção de
ferramentas e métodos da qual qualquer empresa se beneficiaria com mais sucesso
ao cuidar do projeto inicial de integração, e um processo de mudança que pode
acontecer durante o tempo de vida operacional da empresa. Ela não impõe qualquer
coleção de ferramentas ou métodos em particular, mas define critérios a serem
satisfeitos por qualquer coleção de ferramentas e métodos selecionados. GERAM
considera modelos de empresas como um componente essencial para a integração
e engenharia de empresas; isto inclui várias técnicas formais (e menos formais) de
descrição de projetos utilizados no curso do projeto – como descrito em
metodologias de engenharia de empresas – como modelos computacionais, textuais
e gráficos para representações do projeto.
68
A coleção de componentes identificados em GERAM é mostrada na Figura
4.12. e é brevemente descrita a seguir (IFIP – IFAC, 1999).
A estrutura GERAM identifica em seu componente mais importante GERA
(Generalized Enterprise Reference Architecture – Arquitetura de Referência de
Empresas Generalizada) os conceitos básicos a serem usados na integração e
engenharia de empresas (por exemplo, entidades de empresa, ciclos-de-vida e
histórias de vida de entidades de empresa). GERAM faz distinção entre as
metodologias para engenharia de empresas (EEMs – Enterprise Engineering
Methodology – Metodologias de Engenharia de Empresa) e as linguagens de
modelagem (EMLs – Enterprise Modeling Languages – Linguagens de Modelagem
de Empresa) que são usadas pelas metodologias para descrever e modelar, a
estrutura, conteúdo e comportamento das entidades de empresas em questão. Estas
linguagens permitirão a modelagem da parte humana na operação da empresa
assim como partes dos processos da empresa e suas tecnologias de suporte. O
processo de modelagem produz modelos de empresas (EMs – Enterprise Models –
Modelos de Empresa) que representam todas ou parte das operações da empresa,
incluindo suas tarefas de produção ou de serviço, sua organização e seu
gerenciamento, e seu controle e sistemas de informação. Estes modelos podem ser
usados para guiar a implementação de sistemas operacionais da empresa (EOSs –
Enterprise Operational Systems – Sistemas Operacionais de Empresa) assim como
melhorar a habilidade da empresa para avaliar alternativas operacionais ou
organizacionais (por exemplo, por simulação), e assim aumentar seu desempenho
atual e futuro.
A metodologia e as linguagens usadas para a modelagem de empresas
são apoiadas por ferramentas de engenharia de empresas (EETs – Enterprise
Engineering Tools – Ferramentas de Engenharia de Empresas). A semântica das
linguagens de modelagem pode ser definida através de ontologias, meta modelos e
vocabulários que são coletivamente chamados conceitos de modelagem de
empresas genéricos (GEMCs – Generic Enterprise Modelling Concepts – Conceitos
Genéricos de Modelagem de Empresa). O processo de modelagem é aprimorado
pela utilização de modelos parciais (PEMs – Partial Enterprise Models – Modelos
Parciais de Empresa) que são modelos reutilizáveis de funções humanas, processos
e tecnologias.
69
O uso operacional de modelos de empresa é apoiado através de módulos
específicos (EMOs – Enterprise Modules – Módulos de Empresa) que fornecem
produtos pré-fabricados como perfis de habilidades humanas para profissões
específicas, procedimentos empresariais comuns (por exemplo, regras de
contabilidade e imposto) ou seus serviços de infra-estrutura, ou qualquer outro
produto que pode ser usado como um componente na implementação do sistema
operacional (EOSs – Enterprise Operational Systems – Sistemas Operacionais de
Empresa), tal como um sistema de informação.
Potencialmente, todas arquiteturas de referência e metodologias propostas
podem ser caracterizadas em GERAM de forma que desenvolvedores de
arquiteturas particulares poderiam tirar vantagens se forem capazes de se referir
comumente às capacidades de suas arquiteturas, sem ter que reescrever seus
documentos por completo para obedecer à GERAM. Usuários destas arquiteturas se
beneficiariam da GERAM porque as definições da GERAM lhes permitiriam
identificar o que eles podem (e o que eles não podem) esperar de qualquer
arquitetura particular escolhida em conjunto com uma metodologia de integração de
empresas seus componentes de apoio propostos (IFIP – IFAC, 1999).
70
GERA
Arquitetura de
Empresas Generalizada
Identifica conceitos de
integração de empresas
EOS
Sistemas Operacionais
de Empresas
Apóia a operação de
empresas em particular
EMOs
Módulos de Empresa
Fornece módulos implementáveis
de profissões humanas, processos
operacionais e tecnologias.
EMs
Modelos de Empresa
Projeta empresas e
modelos para apoiar
análises e operações
EETs
Ferramentas de
Engenharia de Empresas
Apóia a engenharia de
empresas
PEMs
Modelos Parciais de
Empresas
Fornece modelos de referência
reutilizáveis e projeta funções
humanas, processos e tecnologias.
GEMCs
Conceitos Genéricos de
Modelagem de
Empresas
(Tecnologias e Definições)
Define o objetivo dos construtores de
modelagem de empresas
EEM
Metodologia de
Engenharia de Empresas
Descreve processos de
engenharia de empresas
EMLs
Linguagens de
Modelagem de Empresas
Fornece construtores de modelagem
para modelagem de funções
humanas processos e tecnologias
em
p
re
g
a
usada
p
ara construir
É implementado em
utiliza
a
p
óia
usada
p
ara im
p
lementar
Figura 4.11. GERAM (Metodologia e Arquitetura de Referência de Empresas Generalizada)
Componentes da Estrutura
Fonte: Adaptado de IFIP-IFAC Task Force GERAM: Generalised Enterprise Reference
Architecture and Methodology – Version 1.6.3, March 1999, página 5
4.2.7.1. D
EFINIÇÃO DOS COMPONENTES DA ESTRUTURA GERAM
A seguir são descritos os componentes da arquitetura GERAM comforme
IFIP – IFAC (1999).
71
4.2.7.1.1. GERA – ARQUITETURA DE REFERÊNCIA DE EMPRESAS
GENÉRICA
GERA define os conceitos genéricos de empresas relacionados,
recomendados para uso em projetos de integração e engenharia de empresas.
Estes conceitos podem ser categorizados como:
a) Conceitos Orientados a Humanos:
1) descrevem o papel de humanos como uma parte integrante da
organização e operação de uma empresa; e
2) apóiam os humanos durante o projeto, a construção e a
mudança da empresa.
b) Conceitos orientados a processo para uma descrição dos processos de negócios
da empresa;
c) Conceitos orientados a tecnologia para a descrição do processo empresarial que
apóia a tecnologia envolvida na operação da empresa e nos esforços de
engenharia da empresa (apoio usado na modelagem e no modelo).
4.2.7.1.2. EEMS - METODOLOGIA DE ENGENHARIA DE EMPRESAS
EEMs descrevem os processos de integração e engenharia de empresas.
Uma metodologia de engenharia de empresas pode ser expressa na forma de um
modelo de processo ou procedimento estruturado com instruções detalhadas para
cada atividade de integração e engenharia de empresa (ver exemplo na sessão
4.2.6.2.).
4.2.7.1.3. EMLS – LINGUAGENS DE MODELAGEM DE EMPRESAS
EMLs definem construtores de modelagem genéricos para modelagem de
empresas adaptados às necessidades das pessoas que criam e usam os modelos
de empresa. Na modelagem de empresas particulares as linguagens de modelagem
de empresas proverão construtores para descrever e modelar funções humanas,
72
processos operacionais e seus conteúdos funcionais, como também as tecnologias
de suporte à informação, à gerência e à produção.
4.2.7.1.4. GEMCS - CONCEITOS GENÉRICOS DE MODELAGEM DE
EMPRESAS
GEMCs definem e formalizam os conceitos mais genéricos de modelagem
de empresas. Conceitos Genéricos de Modelagem de Empresas podem ser
definidos de vários modos. Em ordem crescente de formalidade conceitos genéricos
de modelagem de empresas podem ser definidos como:
• Explicação natural da linguagem do significado de conceitos de
modelagem (vocabulários);
• Alguma forma de meta modelo (por exemplo, meta esquema de
relacionamento de entidades) descrevendo a relação entre os conceitos
de modelagem disponíveis nas linguagens de modelagem de empresa;
• Teorias Ontológicas que definem o significado (semântica) das linguagens
de modelagem de empresas para melhorar a capacidade analítica das
ferramentas de engenharia, e através delas a utilidade dos modelos de
empresas. Tipicamente, estas teorias seriam construídas dentro das
ferramentas computacionais de engenharia de empresa.
4.2.7.1.5. PEMS - MODELOS PARCIAIS DE EMPRESAS
PEMs (modelos reutilizáveis, ou paradigmáticos, ou típicos) – capturam
características comuns para muitas empresas dentro ou através de um ou mais
setores industriais. Assim estes modelos capitalizam em conhecimentos prévios
permitindo bibliotecas de modelo para ser desenvolvidos e usados novamente de
uma forma ‘plug-and-play’, ao invés de desenvolver modelos do nada. Modelos
parciais tornam o processo modelagem mais eficiente.
O escopo destes modelos se estende a todos os componentes possíveis
da empresa assim como os modelos de funções humanas (habilidades e
73
competências de humanos na operação e no gerenciamento de empresas),
processos operacionais (funcionalidade e comportamento) e componentes de
tecnologia (para atividades de serviço e manufatura), componentes de infra-estrutura
(tecnologia de informação, energia, serviços etc.).
O modelo parcial pode abranger o todo ou uma parte de uma empresa
típica. Eles podem interessar a várias entidades de empresa tal como produtos,
projetos, companhias, e pode representá-los de vários pontos de vista como
modelos de dados, modelos de processo, modelos de organização, para nomear
alguns.
Modelos parciais de empresa também são referidos na literatura como
‘Modelos de Referência’, ou ‘Arquiteturas de Referência Tipo I’ em GERAM. Estes
termos têm o mesmo significado. Arquiteturas de Referência baseadas no ciclo de
vida da empresa (como o GERA) são consideradas ‘Arquitetura de Referência Tipo
II’.
4.2.7.1.6. EETS - FERRAMENTAS DE ENGENHARIA DE EMPRESAS
EETs suportam os processos de engenharia e integração de empresas
pela implementação de uma metodologia de engenharia de empresas e fornecendo
linguagens de modelagem. Ferramentas de Engenharia devem dar suporte para
análise, projeto e uso dos modelos de empresa.
4.2.7.1.7. EMS - MODELOS DE EMPRESAS (PARTICULAR)
EMs representam empresas particulares. Os modelos de empresas podem
ser expressos usando linguagens de modelagem de empresas.
EMs podem ser usados para vários projetos, modelos preparados para
análise, modelos executáveis para apoiar a operação da empresa, etc. Eles podem
consistir de vários tipos de modelos que descrevem vários aspectos (ou visões) da
empresa.
74
4.2.7.1.8. EMO
S - MÓDULOS DE EMPRESA
EMOs são produtos que podem ser utilizados na implementação de
empresas. Exemplos de módulos de empresas são recursos humanos com
determinados perfis de habilidade (profissões específicas), tipos de recursos de
manufatura, equipamentos de negócio comuns ou de infra-estrutura de integração
(software e hardware) cuja intenção é apoiar o uso operacional dos modelos de
empresa.
Ênfase especial está em sua infra-estrutura que apoiará as operações da
empresa assim como também a engenharia de empresas. Os serviços de sua infra-
estrutura fornecerão duas funções principais:
a) portabilidade e interoperabilidade de modelo provendo uma infra-estrutura de
integração através de ambientes heterogêneos de empresas;
b) suporte à operação dirigida por modelos (apoio à decisão e monitoramento e
controle de operação) provendo acesso em tempo real ao ambiente de empresa.
Esta última funcionalidade será especialmente útil nas tarefas de
engenharia de atualização e modificação de modelos. Acesso a dados reais de
mundo fornece cenários muito mais realísticos para a validação e verificação de
modelo, do que através de simulações baseadas em dados ‘artificiais’.
4.2.7.1.9. EOSS - SISTEMAS OPERACIONAIS DE EMPRESAS (PARTICULAR)
EOSs apóiam a operação de uma empresa particular. Sua implementação
é guiada pelo modelo particular de empresa que fornece as especificações do
sistema e identifica os módulos de empresa usados na implementação do sistema
particular da empresa.
4.3. C
ONSIDERAÇÕES FINAIS
Este capítulo apresentou várias Arquiteturas de Referências para
Engenharia de Empresas. GERAM constitui um trabalho da ISO visando uma
75
padronização na área, considerando os principais conceitos de outras arquiteturas já
desenvolvidas, e quando foi necessário, desenvolveu novos conceitos. Um dos
conceitos de GERAM é o seu ciclo de vida. No próximo capítulo será proposto um
conjunto de atividades para uma metodologia para desenvolvimento do ERP5
baseado no ciclo de vida de GERAM, que integra principalmente atividades das
metodologias UP e CIMOSA.
76
CAPÍTULO 5
PROPOSTAS METODOLÓGICAS PARA O ERP5
5.1. INTRODUÇÃO
Este capítulo tem o objetivo de propor um conjunto de componentes
(métodos, modelos e ferramentas) de uma Estrutura Metodológica particular para o
ERP5, utilizando como base a Metodologia e Arquitetura de Referência de Empresa
Generalizada - GERAM.
Conforme já apresentado, GERAM define um ‘kit’ de conceitos para projetar
e manter empresas por todo o seu ciclo de vida. Ela tem como propósito organizar o
conhecimento de engenharia e integração de empresas existentes, e sua estrutura
tem o potencial para ser aplicada a todos os tipos de empreendimento, por ser
genérica. Outras arquiteturas de referência podem manter sua própria identidade,
enquanto identificam suas deficiências e se complementam através de GERAM.
Ela fornece uma descrição de todos os elementos recomendados na
engenharia e integração de empresas e assim prepara o padrão para a coleção de
ferramentas e métodos, da qual qualquer empresa se beneficiaria com mais sucesso
ao cuidar do projeto inicial de integração, e um processo de mudança que pode
acontecer durante o tempo de vida operacional da empresa. Ela não impõe qualquer
coleção de ferramentas ou métodos em particular, mas define critérios a serem
satisfeitos por qualquer coleção de ferramentas e métodos selecionados (IFIP-IFAC,
1999).
Assim, neste capítulo são realizadas análises e propostas de componentes
sugeridos pelo GERAM (ver Figura 4.12) para o projeto ERP5, considerando os
métodos, modelos e ferramentas pesquisados na revisão bibliográfica durante este
trabalho acadêmico.
77
5.2. A
RQUITETURA DE REFERÊNCIA
No Capítulo 4 foram apresentadas várias arquiteturas de referência para a
engenharia de empresas, tais como as de CIMOSA, GIM, PERA, ARIS e a de
GERAM (a GERA).
GERA é proposta para o Projeto ERP5, pois a mesma é originada por um
organismo de padrão internacional (a ISO), e também se justifica pelo fato da
GERAM incluir em seu escopo, o conhecimento necessário para a integração e
engenharia de empresas, incluindo os melhores conceitos e práticas das outras
propostas anteriormente concebidas (IFIP-IFAC, 1999).
GERA é o componente mais importante da estrutura GERAM, pois através
dela é possível identificar os conceitos básicos a serem usados na integração e
engenharia de empresas, como, por exemplo, as entidades de empresa, os ciclos-
de-vida e o histórico das entidades de empresa. GERA, tal como GERAM, foi criado
como um trabalho que visa ser um padrão da ISO e se baseou em pesquisas
prévias, realizadas pelo AMICE (que desenvolveu CIMOSA), pelo Laboratório GRAI
(desenvolveu GRAI e GIM) e pela Universidade de Purdue (desenvolveu a PERA). A
Força-tarefa IFIP/IFAC analisou estas pesquisas e, a partir da avaliação dessas
arquiteturas de integração de empresas, desenvolveu uma definição global de uma
arquitetura generalizada, da qual interessados na engenharia e integração podem se
basear para projetar a sua própria empresa, a arquitetura GERAM. Sua estrutura
generalizada tem a capacidade de descrever os componentes necessários em todos
os tipos de processos de integração e engenharia de empresas. Sua intenção é
facilitar a unificação de métodos de várias disciplinas usadas em processos de
mudança, tais como métodos de engenharia industrial, técnicas de gerenciamento,
engenharia de controle, tecnologia de comunicação e informática. Quer dizer,
permitir seu uso combinado, ao invés de sua aplicação segregada.
Outro aspecto importante de sua estrutura é que esta unifica duas
abordagens distintas da integração de empresas, uma baseada em modelos de
produtos e outra baseada no planejamento de processos de negócio. GERAM
encara modelos de empresas como um componente essencial para a integração e
engenharia de empresas. GERA provê uma estrutura de análise e modelagem que é
baseada no conceito de ciclo-de-vida e identifica três dimensões para definir o
78
escopo e o conteúdo da modelagem de empresa, semelhante à de CIMOSA (ver
Figura 5.1):
• Dimensão de Ciclo-de-vida: suportando o processo controlado de
modelagem de entidades de empresa de acordo com as atividades do
ciclo-de-vida.
• Dimensão de Generalidade: suportando o processo controlado de
particularização (instanciação) do genérico e parcial para o particular.
• Dimensão de Vista: suportando a visualização controlada de vistas
específicas da entidade de empresa.
Subdivisão de
acordo com a
generalidade
Figura 5.1. Estrutura de Modelagem GERA com Vistas de Modelagem
Fonte: Adaptado de IFIP-IFAC Task Force GERAM: Generalised Enterprise Reference
Architecture and Methodology Version 1.6.3, March 1999, página 22.
Projeto
Identificação
Conceito
Requisitos
Projeto preliminar
Projeto detalhado
Implementação
Operação
Retirada
Fases do
Ciclo-de-vida
Ar
q
uitetura de Referência Ar
q
uitetura Particular
Instanciação
Genérica
Parcial
Vistas
Particula
r
Serviço ao Cliente
Subdivisão de acordo
com a proposta de
atividade
(Customer service)
Gestão e Controle
Subdivision according
to purpose of activity
(Mangement and
Control)
Subdivisão de
acordo com a
manifestação
física
Software
Hardware
Recurso
Subdivisão de
acordo com o
conteúdo do
modelo
Or
g
aniza
ç
ão
Informa
ç
ão
Fun
ç
ão
Subdivisão de
acordo com os
objetivos da
implementação
Má
q
uina
Humano
79
5.3. M
ETODOLOGIA DE MODELAGEM
Como citado no Capítulo 3, pode-se dizer que “Metodologia é um sistema de
métodos e princípios usado numa disciplina particular. Método é uma maneira de
proceder ou fazer alguma coisa; é a técnica ou plano de trabalho para um campo
particular” (KOSANKE, 1996).
As Metodologias de Engenharia de Empresa descrevem os processos de
integração de empresas. Conforme descrito na seção anterior, uma metodologia
Generalizada semelhante às arquiteturas generalizadas é aplicável à qualquer
empresa independente da indústria envolvida. Elas guiam o usuário nas tarefas de
engenharia e modelagem de empresa. Diferentes metodologias podem ser
consideradas, as quais contemplam aspectos diferentes nos processos de mudança
de empresa. Estes podem ser processos completos de desenvolvimento e
integração de empresas ou podem ser mudanças incrementais, como em programas
de melhorias continua na empresa (IFIP-IFAC, 1999).
Diferente do caso de arquiteturas de referência, das quais se obteve uma
grande quantidade de informações na literatura, na revisão bibliográfica, sobre
metodologias não se obteve informações detalhadas. Isto se deve ao fato de várias
delas serem proprietárias. A outra questão, relacionado a anterior, é que muitas
delas são propostas visando o atendimento de um tipo específico de projeto (ou
entidade) ou o atendimento de aspectos particulares de usuários que as propõem.
Como exemplo de metodologias apresentadas nesta dissertação estão
CIMOSA (para a engenharia de empresas), o UP e o RUP (para a engenharia de
sistemas).
Para o projeto ERP5 possíveis usuários e/ou desenvolvedores podem utilizar
o UP ou uma metodologia mais simplificada.
Como alternativa, no capítulo seguinte é apresentado um esforço no sentido
de propor Workflows e respectivas atividades para a definição de uma metodologia
de referência de acordo com o GERA, considerando principalmente o UP e o RUP,
como também a metodologia CIMOSA. Essa proposta foca as primeiras fases
metodológicas para incorporar aspectos relativos a empresas de manufatura, com o
80
objetivo de melhor levantar os requisitos para o Desenvolvimento de ERPs. Ela
propõe uma estrutura de base, para que em um trabalho futuro se detalhe todas as
suas fases e atividades. Então, usuários e desenvolvedores, utilizando o ERP5
podem usar a metodologia de referência para criar a sua própria metodologia
(particular).
5.4. LINGUAGEM DE MODELAGEM
A engenharia de uma empresa é um exercício altamente sofisticado de
gestão multidisciplinar, planejamento e implementação durante o qual são criadas
várias formas de descrições e modelos de empresa, utilizando linguagens de
modelagem.
Linguagens de modelagem de empresas podem ser definidas através de
construtores de modelagem. Construtores de Modelagem representam os diferentes
elementos da entidade de empresa modelada e melhora a eficiência da modelagem
e a compreensão do modelo. A forma (representação) dos construtores de
modelagem tem que ser adaptada às necessidades das pessoas que criam e usam
os modelos de empresa. Então, podem existir linguagens separadas para acomodar
os aspectos de diferentes usuários (por exemplo os gerentes e usuários de
empresas, projetistas de sistemas, especialistas em modelagem de Tecnologia de
Informação, e outros) (IFIP-IFAC, 1999). Então, linguagens que suportem não
apenas a descrição de modelos, mas também que suportem a análise, checagem de
consistência e simulação desses modelos são necessárias, como os modelos
baseados em Redes de Petri (VERNADAT, 1996).
Várias linguagens são atualmente propostas para a modelagem de
empresas (como a CIMOSA, a ARIS, a GRAI e o padrão para construtores de
modelagem ENV 12 204) e para a modelagem de sistemas de informações (como o
modelo de entidade-relacionamento e a UML).
A linguagem CIMOSA é uma das mais completas e expressivas para a
modelagem de empresas. Por outro lado, a UML se transformou em um padrão de
fato para o desenvolvimento de software.
81
Nesse sentido, a linguagem proposta para o projeto ERP5 é a UML, porém,
utilizando o seu mecanismo de extensão para incluir construtores de modelagem de
empresas, semelhante a proposta de OLIVEIRA (2003). Ele propôs extensões da
UML para a modelagem de empresas a partir de uma análise das extensões
propostas por ERIKSSON e PENKER (2000) e principalmente baseadas nos
construtores de linguagem de CIMOSA.
Exemplificando, em CIMOSA, os recursos podem ser Entidades Funcionais
ou Componentes de Recursos. Componentes são os recursos passivos, que podem
ser usados ou manipulados por Entidades Funcionais (ex: ferramentas,
equipamentos diversos). O estereótipo proposto por OLIVEIRA (op. cit.) para
representar a classe Componente de Recurso, através da extensão da UML, é
representado pelo ícone mostrado na Figura 5.2.
Figura 5.2. Ícone de representação na UML para Componente de Recurso
Fonte: OLIVEIRA, C.L.P.
Proposta de Extensões da Unified Modeling Language para
Modelagem de Empresas
,2003.
Em OLIVEIRA (op. cit.), o Modelo de Recursos é representado como um
diagrama de classes estereotipadas da UML, onde é mostrada a organização dos
Recursos, conforme ilustra o exemplo da Figura 5.3.
82
Figura 5.3. Exemplo de Modelo de Recursos
Fonte: OLIVEIRA, C.L.P.
Proposta de Extensões da Unified Modeling Language para
Modelagem de Empresas
,2003.
Uma das mais importantes diferenças entre as linguagens de modelagem
CIMOSA e UML está no fato da UML dar ênfase à visualização gráfica através de
diagramas, enquanto CIMOSA, fornece uma descrição textual do modelo da
empresa, através de gabaritos.
No trabalho de Oliveira (2003), o detalhamento das características dos
construtores de Recursos é descrito no gabarito que acompanha esta classe. Um
exemplo da utilização do gabarito da classe Recurso especializado como Entidade
Funcional é apresentado na Tabela 5.1.
As extensões apresentadas neste trabalho podem ser incorporadas nas
ferramentas de modelagem UML disponíveis no mercado que permitem a inclusão
de extensões.
83
Tipo: Célula de Manufatura
Identificador: EF-200
Nome: Célula de Perfuração
Autoridade de Projeto: C. Oliveira / Engenheiro
DESCRIÇÃO: É composta por máquinas de usinagem e um robô
CONJUNTO DE
CAPABILIDADES:
CC-200 / Capabilidades da célula de operação
CLASSE: Célula Recurso
CONJUNTO DE OPERAÇÕES: /* Lista de Operações Funcionais executáveis pela
célula controladora */
VISTA DE OBJETO: VO-200 / Célula de Perfuração
ESTRUTURA
CONSISTE DE: EF-300 / ASEA-RB-60
EF-401 / FANUC-RT50
EF-410 / MILLACRON-P20
Tabela 5.1. Exemplos de utilização do gabarito para Recurso como Entidade Funcional
Fonte: OLIVEIRA, C.L.P.
Proposta de Extensões da Unified Modeling Language para
Modelagem de Empresas
,2003.
Outra proposta que pode vir a ser utilizada para criar extensões para a
modelagem de empresas através da UML é a utilização da UEML (MACHADO,
2003), que define um conjunto de construtores de modelagem, visando unificar as
propostas de linguagens de modelagem de empresas existentes, e definir um
padrão na área.
5.5. CONCEITOS GENÉRICOS DE MODELAGEM DE EMPRESA
Conceitos Genéricos de Modelagem de Empresa são os conceitos e as
definições na área de integração e modelagem de empresas mais genericamente
usados. Três formas de definição do conceito são utilizados, em ordem crescente de
formalidade (IFIP-IFAC, 1999):
• Glossários;
• Meta-modelos; e
• Teorias Ontológicas.
84
A terminologia usada em integração de empresa pode ser definida em
linguagem natural como um Glossário de Termos. Tal Glossário é uma exigência
obrigatória para uma completa arquitetura e metodologia de integração generalizada
de empresa. Como uma exigência mínima, o Glossário tem que definir todos os
conceitos que estão definidos nos Meta-modelos semi-formais e/ou Ontologias
formais.
No contexto de GERAM, Meta-modelos são modelos conceituais da
terminologia componente de linguagens de modelagem. Eles descrevem os
conceitos usados, suas propriedades e relacionamentos, como também algumas
restrições básicas, tais como restrições de cardinalidade.
Meta-modelos estão situados entre expressões formais e informais.
Normalmente, eles são representados em um esquema entidade-relacionamento ou
numa linguagem similar em poder de expressão. A terminologia definida no meta-
esquema integrado também pode ser considerado como o esquema de um banco de
dados de modelos de empresa incluída na ferramenta de engenharia de empresa
utilizada.
Teorias Ontológicas também podem ser vistas como modelos formais dos
conceitos que são usados nas representações de empresa. Eles capturam regras e
limitações do domínio de interesse, permitindo conclusões úteis serem esboçadas,
analisadas, executadas (por exemplo para propósitos de simulação), através de
checagem cruzada (conferência) e validação de modelos.
Teorias Ontológicas são um tipo de modelo genérico de empresa,
descrevendo os aspectos mais genéricos dos conceitos relatados da empresa
(função, estrutura, dinâmica, custo, e assim por diante), e definem a semântica das
linguagens de modelagem usadas. Elas têm um papel similar ao que ‘modelos de
dados’ tem no projeto do banco de dados.
Linguagens de modelagem de empresas apoiadas por teorias ontológicas (e
suas ferramentas de apoio de engenharia de empresas) provêem o usuário com
capacidades de análise aumentadas (IFIP-IFAC, 1999).
85
Em específico para o ERP5, alguns (ou parte de) glossários, meta-modelos
e ontologias já existentes atualmente podem ser adotados, ou novos podem ser
desenvolvidos conforme necessidades. Esses conceitos se tornam mais importantes
quando supomos que o ERP5 é aberto e livre, e que uma boa documentação e
entendimento comum dos modelos do sistema é essencial para os possíveis
usuários e desenvolvedores adaptarem o ERP (conceitos já definidos no ERP5
podem ser mapeados em definições já consagradas na teoria ou em padrões).
5.6. MODELOS PARCIAIS DE EMPRESA
Modelos parciais de empresa (modelos de referência reutilizáveis) são
modelos que capturam conceitos comuns para muitas empresas. Eles são usados
na modelagem de empresas para aumentar a eficiência do processo de modelagem.
No processo de engenharia de empresa estes modelos parciais podem ser usados
como componentes testados para construir modelos particulares de empresa.
Porém, em geral tais modelos ainda precisam ser adaptados (ou completados) para
a entidade particular de empresa. Modelos parciais podem ser expressos como
(IFIP-IFAC, 1999):
• Modelos que capturam alguma parte comum de uma classe de empresas;
• Modelos Paradigmáticos (referência ou prototipação) que descrevem uma
empresa típica de uma classe. Modelos de protótipos podem ser
subseqüentemente modificados para ajustar-se a um caso particular;
• Modelos Abstratos de uma parte ou de toda uma classe de empresas que
capturam as coisas mais comuns mas omitem detalhes específicos. Este tipo
de modelo é do tipo ‘fill-in-the-blank’ (preencher o espaço em branco).
Modelos parciais têm sido propostos por instituições de pesquisa ou por
desenvolvedores particulares, e o projeto ERP5 pode adotar e/ou adaptar tais
modelos e/ou desenvolver os seus próprios.
Por exemplo, SANTOS (2001) propôs um modelo de referência para o
processo (através da linguagem CIMOSA) e um modelo de referência para sistema
de informação (através da linguagem UML) para a previsão de demanda de produtos
(exemplo de modelo de processo e respectivo gabarito nas Figuras 5.4. e 5.5.).
86
Start
Analisar_Requisicao
Ajustar_Dados
Gerar_Cenarios
Revisao_Gerencial
Apresentar_Previsao
Finish
RequisicaoAnalisada
DadosAjustados
CenariosGerados
RevisãoRealizada
NovoCenario
Fim-Previsao
Figura 5.4. Processo de Previsão de Demanda
Fonte: SANTOS, L.R.
Modelagem de Processos de Empresas e Projeto de Sistema de
Informação: Uma Aplicação para auxilio a Previsão de Demanda de Produtos
,2001.
DOMAIN PROCESS
Name: Previsao_Demanda
Identifier: PD3- Previsao_Demanda
Type:
Design Authority: Luciana Rocha
OBJECTIVES:
Realizar a previsão de demanda de produtos conforme definido no projeto do processo.
CONSTRAINTS:
DESCRIPTION:
O Processo de Previsão de Demanda consiste em realizar a previsão de demanda pelo analista de previsão e demais participantes,
utilizando-se o sistema de informação de auxílio à previsão. Este processo é realizado de forma automática pelo sistema de
previsão, após o projeto (ou reprojeto) do processo de previsão, e posteriormente de forma periódica.
Este processo inicia com uma análise da requisição de previsão, passando pelo ajuste dos dados de demanda, definição de
previsões baseadas em modelos matemáticos e possíveis cenários. Então é feita uma revisão gerencial e após a apresentação dos
resultados finais do processo de previsão aos seus usuários.
Event: EV-Req_Previsao_Demanda
EV-Rever_Previsao
PROCEDURE:
Start = Analisar_Requisicao
Analisar_Requisicao RequisicaoAnalisada Ajustar_Dados
Ajustar_Dados DadosAjustados Gerar_Cenarios
Gerar_Cenarios CenariosGerados Revisao_Gerencial
Revisao_Gerencial RevisãoRealizada Apresentar_Previsao
Revisao_Gerencial NovoCenario Gerar_Cenarios
Apresentar_Previsao Fim-Previsao Finish
COMPONENTS:
Analisar_Requisicao
Ajustar_Dados
Gerar_Cenarios
Revisao_Gerencial
Apresentar_Previsao
Figura 5.5. Gabarito do Processo de Previsão de Demanda.
Fonte: SANTOS, L.R.
Modelagem de Processos de Empresas e Projeto de Sistema de
Informação: Uma Aplicação para auxilio a Previsão de Demanda de Produtos
,2001.
87
5.7. F
ERRAMENTAS DE ENGENHARIA DE EMPRESA
presa empregam linguagens de
modelagem de empresa para apoio às metodologias de engenharia de empresas, e
espec
processo de modelagem e prover capacidades de análise úteis para o uso dos
model
ositório compartilhado, ou banco
de dados, que permita a gestão de todos os modelos e descrições parciais e
particu
ritos, muito ainda precisa ser feito no sentido de
incluí-los nesse tipo de ferramenta. Mas já existem trabalhos de definição de
ferram
de modelos de empresa sugerem que
algum tipo de ferramenta apóie a sua construção e manutenção, assim como para o
ERP5.
As Ferramentas de Engenharia de Em
ificamente tem que apoiar a criação, uso, e gestão de modelos de empresa.
As Ferramentas de Engenharia de Empresa também têm que apoiar o teste e
avaliação dos modelos (ou descrições) da empresa, e permitir a interpretação
computacional dos modelos para simulação. Estas funções são necessárias para
decisões de projeto feitas no decorrer da engenharia de empresa (IFIP-IFAC,1999).
As ferramentas de engenharia deveriam prover orientação ao usuário para o
os no processo de engenharia de empresa.
Ainda, as ferramentas devem prover um rep
lares que são usados ou produzidos no processo de engenharia de empresa,
incluindo modelos formais e qualquer outra descrição informal de projeto,
documento, etc. Alguns exemplos de ferramentas de engenharia baseados em
linguagens de modelagem (quando a entidade de empresa em questão é a empresa
ou seu próprio projeto de empresa) são: conjunto de ferramentas ARIS (para a
metodologia ARIS), FirstSTEP (CIMOSA), MOGO (IEM), Ferramentas KBSI, METIS,
e Processwise (IFIP-IFAC, 1999).
Quanto à questão dos gaba
entas de modelagem CIMOSA que incluem esta funcionalidade. Dentre elas,
podem-se destacar o CimTool (René Ganches Consultant in Production), que
foi utilizada por SANTOS (2001) (ver figura 5.4), e também o trabalho de Oliveira
(2000), que visou o desenvolvimento de uma ferramenta baseada em CIMOSA e
que possa fazer alguns tipos de simulações.
Então, o tamanho e a complexidade
Para essa proposta, a inclusão das extensões, pela ferramenta de
88
modelagem, que suportem a UML, torna-se fundamental para ela ser adotada na
metodologia proposta para o ERP5.
Diversas ferramentas encontradas no mercado suportam a inclusão de
extens
Ferramentas livres e de código aberto, acompanhando a idéia do projeto
ERP5,
Carvalho e Campos (2006) apresentam uma visão resumida de um processo
de de
ões da UML, e outras estão sendo projetadas. As ferramentas Case baseadas
na linguagem UML são softwares que de alguma forma colaboram para a execução
das atividades de engenharia de software (FERREIRA, 2005). Pode-se citar o
Describe Enterprise 5.8, que possibilita a definição e associação de novos
estereótipos à UML. O Rational Rose, que é uma das ferramentas mais completas
do mercado, sendo totalmente orientada à UML. O Visual Paradigm for UML ou VP
UML, que é uma ferramenta gratuita, disponível nas versões Standard ou
Professional (www.visual-paradigm.com). O Poseidon Linux for UML, que é uma
distribuição GNU/Linux e nasceu a partir da necessidade de ter-se um desktop
amigável e completo baseado em software livre para a comunidade
acadêmica/científica brasileira. Ele possui todas as ferramentas para um estação de
trabalho, como por exemplo: suíte office (com corretor ortográfico), navegadores
web, leitores de e-mail, programas de mensagens instantâneas, etc. O Argo/UML,
que é uma Ferramenta CASE em Java para design orientado a objetos. Ele inclui os
mesmos recursos de edição e geração de códigos encontrados em ferramentas
CASE comerciais, mas foca sua atenção naqueles que melhoram a utilização e
suporte de necessidades cognitivas de designers. Usa formatos baseados em XML
como PGML e XMI e tem suporte a OCL, opção de repositório SQL e diagramas de
Deployment e Collaboration.
para a modelagem com a UML podem ser interessantes, mas dificilmente
existe disponível uma ferramenta com todas as características descritas
anteriormente na teoria, tais como simulações, checagem de consistência, biblioteca
de modelos parciais, etc. O desenvolvimento de uma ferramenta deste tipo pode
representar um considerável esforço de trabalho dentro do projeto considerado.
senvolvimento, e lista de métodos e ferramentas, baseados nas melhores
práticas, visando o aumento da produtividade e qualidade no desenvolvimento.
Algumas das técnicas e ferramentas propostas são bem estabelecidas, e outras
89
foram especificamente desenvolvidas ou adaptadas para o ERP5. O objetivo destas
propostas é embutir o máximo de conhecimento necessário para tornar o
desenvolvimento de uma nova instância do sistema o mais sistemática e
automatizada possível.
5.8. MÓDULOS DE EMPRESA
Módulos de empresa são blocos de construção ou sistemas implementados
(produ
No projeto ERP5, o foco é o desenvolvimento de sistemas de ERPs, sendo
que m
5.9. MODELOS DE EMPRESA
O objetivo da modelagem de empresa é criar e continuamente manter um
model
tos, ou famílias de produtos), que podem ser utilizados como recursos comuns
na engenharia de empresa e na integração de empresa. Essas entidades físicas
(sistemas, subsistemas, software, hardware, recursos humanos/profissões
disponíveis) são acessíveis na empresa, ou podem estar facilmente disponíveis no
mercado. Em geral, Módulos de Empresas são implementações de modelos parciais
identificados na área como produtos comumente exigidos para os quais há um
mercado. Módulos de empresa podem ser oferecidos como um conjunto, tal que se
o projeto da empresa está seguindo os modelos parciais que formam a base deste
conjunto, então o sistema de negócio de empresa particular resultante pode ser
implementado usando alguns ou todos os módulos deste conjunto de módulos. Um
conjunto de módulos de empresa de grande importância é a Infra-estrutura de
Integração que implementa os Serviços de Integração de Tecnologia de Informação
(IFIP-IFAC, 1999).
ódulos de empresa seriam os componentes de softwares já desenvolvidos ou
a serem desenvolvidos para atender a alguma finalidade.
o de uma entidade de empresa particular. Um modelo deveria representar a
realidade da operação da empresa de acordo com as exigências do usuário e suas
aplicações. Isto significa que a granularidade do modelo tem que ser adaptada às
necessidades particulares, mas ainda permitir interoperabilidade com modelos de
90
outras empresas (IFIP-IFAC, 1999). Para projeto ERP5, modelos (particulares) de
empresa incluem aquelas descrições, projetos, e modelos formais da empresa
particular que são criados ao longo da sua história de vida e foram utilizados para
adaptar e implementar o ERP5, conforme os requisitos particulares dos possíveis
usuários.
5.10. SISTEMAS OPERACIONAIS DE EMPRESA
Os Sistemas Operacionais de Empresa apóiam a operação de uma empresa
particu
5.11. CONSIDERAÇÕES FINAIS
Neste capítulo foram apresentadas propostas para os componentes que
poderã
No próximo capítulo será apresentada uma proposta no sentido de estruturar
uma m
lar. Eles consistem em todo hardware e software necessários para cumprir os
objetivos e metas da empresa. Seus conteúdos são derivados de requisitos da
empresa e sua implementação é guiada pelos modelos de projeto que fornecem as
especificações do sistema e identificam os módulos de empresa usados na
implementação do sistema (IFIP-IFAC, 1999). No caso do projeto ERP5, o sistema
operacional corresponde ao sistema ERP5 implantado na empresa particular.
o fazer parte de uma arquitetura de referência para o ERP5. Um maior
aprofundamento nos estudos referentes a essa proposta, é sugerido para pesquisas
futuras.
etodologia de desenvolvimento de sistemas de informação para o ERP 5.
91
CAPÍTULO 6
PROPOSTAS PARA UMA METODOLOGIA DE DESENVOLVIMENTO DE SISTEMAS
ERP BASEADA NA GERA
6.1. INTRODUÇÃO
Como citado anteriormente, a Força-tarefa IFAC/IFIP em Arquiteturas para
Integração de Empresas desenvolveu, a partir da avaliação de arquiteturas de
integração de empresas existentes como CIMOSA, GRAI/GIM e PERA, uma
definição global de uma arquitetura generalizada que foi intitulada ‘GERAM’
(Metodologia e Arquitetura de Referência de Empresas Generalizada). Essa
arquitetura deve orientar a definição de métodos, modelos e ferramentas que são
necessários para construir e manter a integração de empresas seja este uma parte
de um empreendimento, um único empreendimento ou uma rede de
empreendimentos (empresas virtuais ou empresas estendidas).
A Arquitetura de Referência de GERAM (GERA), sugere um Ciclo de Vida
dividido em fases, nas quais grupos de atividades devem executadas durante toda a
História de Vida de uma empresa ou de uma entidade de empresa. Porém, GERA
não detalha essas fases em atividades. Supondo o desenvolvimento de um ERP, um
dos objetivos dessa dissertação é a de sugerir atividades a serem executadas
durante as primeiras fases do Ciclo de Vida do desenvolvimento de um ERP.Essas
atividades devem contemplem de forma integrada a definição de aspectos do
negócio e do sistema ERP, visando principalmente a adequada definição de
requisitos. Então, baseado nas fases do Ciclo de Vida de GERA, são definidas e
agregadas atividades adaptadas dos Workflows do UP e RUP. São agregadas,
também, outras atividades provenientes da metodologia sugerida por AZEVEDO Jr.
(2003), que integra os objetivos do negócio com os processos e o sistema de
informação, além de atividades provenientes da metodologia CIMOSA que visam a
incorporação da análise e da modelagem de aspectos típicos de uma empresa. Elas
devem levar à melhor definição dos requisitos para o desenvolvimento de um ERP, e
também podem servir para a integração com projetos de outros tipos de sistemas de
empresa, como sistemas de manufatura e sistemas organizacionais. Todas estas
atividades propostas poderão ser consideradas a base para a metodologia de
desenvolvimento de sistema de informação (em específico para o ERP5).
92
Assim, neste capítulo, são apresentadas a Arquitetura de Referência
GERA, uma descrição das atividades sugeridas e seus respectivos produtos
resultantes, além das possíveis utilizações dessas atividades em cada uma das
fases do Ciclo de Vida de GERAM, visando a definição de parte (foco nas primeiras
fases) de uma metodologia de desenvolvimento para o ERP5.
6.2. GERA – ARQUITETURA DE REFERÊNCIA DE EMPRESA GENERALIZADA
Como citado no Capítulo 4, GERA é uma Arquitetura de Referência de
Empresa Generalizada que define os conceitos genéricos recomendados para uso
em projetos de engenharia e integração de empresas. Estes conceitos podem ser
classificados como: Conceitos Orientados a Humanos, Conceitos Orientados a
Processo e Conceitos Orientados a Tecnologia. Uma descrição mais detalhada dos
Conceitos Orientados a Humanos e a Tecnologia é encontrada em IFIP – IFAC
(1999). Este trabalho concentra-se nos Conceitos Orientados a Processo.
6.2.1. CONCEITOS ORIENTADOS A PROCESSO
A Modelagem de Negócios Orientada a Processo visa descrever os
processos na empresa capturando suas funcionalidades (isso é, o que tem que ser
feito) e o seu comportamento (isso é, quando as coisas são feitas e em qual
seqüência). Para alcançar uma descrição completa dos processos vários conceitos
têm que ser reconhecidos na direção da metodologia. Os conceitos orientados a
processo definidos em GERA são:
• Ciclo de vida de entidade de empresa e fases do ciclo de vida;
• História de vida (histórico);
• Tipos de entidades de empresa; e,
• Modelagem de empresa com representação de modelos integrados e
vistas de modelos.
Nesse Capítulo destaca-se o Ciclo de Vida definido em GERA. Os outros
conceitos podem ser vistos com mais detalhes em IFIP – IFAC (1999).
93
6.2.2. CICLO DE VIDA
A Figura 6.1. mostra o ciclo de vida de GERA para qualquer empresa ou
quaisquer de suas entidades. As diferentes fases do ciclo de vida definem tipos de
atividades que são pertinentes durante a vida da entidade. Atividades do ciclo de
vida abrangem todas atividades desde a identificação até a retirada (ou fim de vida)
da empresa ou da entidade. Um total de sete tipos de atividades do ciclo de vida são
definidas, as quais podem ser subdivididas conforme necessidades de detalhes na
metodologia, como mostra a Figura 6.1 para atividades da fase de projeto, que foi
subdividida em dois níveis para maior detalhamento de atividades (baseado na
subdivisão entre fase preliminar de projeto e fase detalhada de projeto, típica em
muitas outras metodologias) (IFIP-IFAC, 1999).
6.2.3. FASES DO CICLO DE VIDA DE GERA
6.2.3.1. FASE DE IDENTIFICAÇÃO DA ENTIDADE
Este é o conjunto de atividades que identificam os conteúdos da entidade
particular sendo considerado, em termos de seus limites e suas relações com seus
ambientes internos e externos. Estas atividades incluem a identificação da existência
e da natureza de uma carência (ou necessidade de mudança) para a entidade
particular. Em outras palavras, elas são as atividades que definem qual é a entidade
que está sendo considerada no ciclo de vida.
6.2.3.2. FASE DE CONCEITO DA ENTIDADE
É o conjunto de atividades que são necessárias para desenvolver os
conceitos da entidade definida como alvo de desenvolvimento ou melhoria. Estes
conceitos incluem a definição da missão, visão, valores, estratégias, objetivos,
conceitos operacionais, políticas, planos empresariais para entidade.
94
6.2.3.3. F
ASE DE REQUISITOS DA ENTIDADE
São as atividades necessárias para desenvolver descrições dos requisitos
operacionais da entidade da empresa, seus processos relevantes e a coleção de
suas necessidades funcionais, comportamentais, informacionais e capabilidades.
Esta descrição inclui exigências de manufatura e de serviço, e exigências de gestão
e controle da entidade – não importando se estes serão satisfeitos por humanos
(indivíduos ou entidades organizacionais), ou máquinas (incluindo tecnologia de
manufatura, de informação, de comunicação, de controle, ou qualquer outra
tecnologia).
6.2.3.4. F
ASE DE PROJETO DA ENTIDADE
São as atividades que apóiam a especificação da entidade com todos os
componentes que satisfazem os requisitos da entidade. O escopo das atividades de
projeto inclui o projeto de todas as tarefas humanas (tarefas de indivíduos e das
entidades organizacionais), e todas as tarefas de máquina relacionadas com os
produtos serviços de clientes da entidade e relativas funções de gestão e controle. O
projeto dos processos operacionais inclui a identificação das informações e recursos
necessários (incluindo tecnologia de manufatura, de informação, de comunicação,
de controle- ou qualquer outra tecnologia). Qualquer fase do ciclo de vida pode ser
subdividida em subfases para permitir uma estruturação adicional de atividades do
ciclo de vida. Exemplo na Figura 6.1. dividindo o projeto no projeto (ou
especificação) funcional e projeto detalhado para permitir a separação de:
a) especificações globais de empresa (suficiente para obter custos
aproximados e aprovação da gerência do projeto); e
b) trabalho principal do projeto necessário para o projeto completo do
sistema adequado para fabricação do sistema físico final.
95
6.2.3.5. FASE DE IMPLEMENTAÇÃO DA ENTIDADE
São as atividades que definem todas as tarefas que devem ser realizadas
para construir ou re-construir (isto é manifestar) a entidade. Isto inclui
implementação de forma geral, cobrindo:
a) nomear, adquirir, (re)configurar ou desenvolver todo serviço, industrial e controle
de software como também recursos de hardware;
b) contratar e treinar pessoal, e desenvolver ou mudar a organização humana;
c) testar e validar componentes, integrar sistemas, testar e validar (ensaio) e liberar
para operação.
A descrição da implementação (documentação) pode divergir da
especificação de projeto da entidade devido a preferências ou indisponibilidade de
componentes especificados.
6.2.3.6. FASE DE OPERAÇÃO DA ENTIDADE
São as atividades da entidade que são necessárias durante sua operação para
produzir os produtos ou serviços dos consumidores que é sua missão especial junto com
todas as tarefas necessárias para monitorar, controlar e avaliar a operação. Assim os
recursos da entidade são administrados e controlados a fim de realizar os processos
necessários para a entidade cumprir sua missão. Desvios de metas e objetivos ou qualquer
estimulo do ambiente podem levar a requisições de mudanças, que incluem reengenharia
de empresa ou melhoria contínua de seus recursos humanos (operários, funcionários) e de
tecnologia, seus processos de negócio e sua organização.
6.2.3.7. FASE DE RETIRADA DA ENTIDADE
Estas atividades são necessárias (requeridas) para redefinição da missão,
re-treinamento, re-projeto, reciclagem, preservação, transferência, licenciamento,
96
separação ou disposição de toda ou parte da entidade ao término de sua vida útil em
operação.
Antes de detalhar as fases do Ciclo de Vida de GERA, fazem-se
necessários, alguns comentários sobre as atividades propostas nessa dissertação.
Após, essas atividades são identificadas e relacionadas a cada uma das fases,
identificando, também, sua influência e os resultados gerados por elas (seção 6.7).
Projeto
Identificação
Conceito
Requisitos
Projeto preliminar
Projeto detalhado
Implementação
Operação
Retirada
Fases do Ciclo de Vida
Figura 6.1. Fases do Ciclo de vida de GERA para qualquer empresa ou entidade.
Fonte: Adaptado de IFIP-IFAC Task Force GERAM: Generalised Enterprise
Reference Architecture and Methodology Version 1.6.3, March 1999, página 10
6.3. ATIVIDADES PROPOSTAS
Como apresentado no Capítulo 3, o ciclo de vida do UP é dividido em
quatro fases, concepção, elaboração, construção e transição, semelhante ao RUP
(KRUCHTEN, 2003; AZEVEDO, 2003). Cada uma dessas fases, por sua vez, é
subdividida em iterações que passam por todos os Workflows do processo
(levantamento de requisitos, análise e projeto, implementação, teste e implantação)
resultando em uma versão de um produto executável que constitui um subconjunto
do produto final em desenvolvimento e crescendo de modo incremental de uma
97
iteração para outra até se tornar o produto final (por exemplo, um módulo de ERP). A
importância de cada Workflow nessas fases depende da fase em que a iteração se
encontra. Por exemplo no UP, as atividades do Workflow de levantamento de
requisitos existem em todas as fases do desenvolvimento, porém com maior ênfase
nas fases de Concepção e Elaboração. Na fase de Concepção existe uma maior
ênfase na identificação dos requisitos, mas não na especificação detalhada dos
mesmos. Desenvolve-se o diagrama de Casos de Uso sem detalhar a especificação
de cada um. O maior esforço na atividade de especificação de requisitos está na
fase de Elaboração. Assim, a partir das informações de negócio e necessidades dos
clientes levantadas em forma de casos de uso na fase de Concepção, as
especificações dos casos de uso são realizadas em maior parte na fase de
Elaboração.
A diretriz para as propostas é que metodologias genéricas para
desenvolvimento de software podem sem adaptadas para o desenvolvimento ERPs
através da incorporação de novas atividades ou de adaptação de atividades originais
propostas pelo RUP (ou UP) utilizando conceitos de modelagem de negócios (ou de
processos de empresas), visando principalmente a melhor definição dos requisitos
de negócios e o seu alinhamento com os requisitos de software. As adaptações das
atividades e dos Workflows são derivadas de propostas de Azevedo (2003) e
CIMOSA (2003). Elas devem ser consideradas dentro do ciclo de vida de empresa
de GERA, supondo a entidade de empresa a ser considerada um ERP. A
preocupação com esta adaptação é mais importante nos primeiros Workflows nas
primeiras fases, sendo que, garantido a identificação e modelagem dos requisitos de
negócios e de sistemas, as demais fases e atividades não necessitam de grandes
adaptações, podendo as demais atividades (como as relativas a implementação) ser
semelhantes a uma metodologia genérica.
Assim, a proposta se concentra nas fases de Identificação, Conceito
Requisitos e Projeto do ciclo de vida de GERA, e não são consideradas as fases de
Implementação, Operação e Retirada (ver figura 6.1). Com relação a Workflows, o
trabalho considera o Workflow de Modelagem de Negócios, Levantamento de
Requisitos e de Análise e Projeto, e não se considera Workflows relativos a
implementação, teste, e implantação. Para saber sobre todas as fases e os
Workflows (inclusive os não considerados) pode-se ler Santiago (2005), KRUTCHEN
98
(2003) ou outra referência de metodologia baseada na proposta original do RUP ou
UP.
A seguir são descritas as atividades que compõem os Workflows citados
anteriormente para uma metodologia de desenvolvimento supondo que a entidade a
ser considerada um ERP. Após, essas atividades são relacionadas às fases de
GERA.
6.4. WORKFLOW PARA MODELAGEM DE NEGÓCIO
A Figura 6.2 mostra o Workflow de Modelagem de Negócios. Seu objetivo
principal é o de modelar o negócio para entender sua estrutura e sua dinâmica, além
de assegurar que todos os interessados tenham um entendimento comum da
organização. Essas atividades são baseadas nas propostas de atividades
apresentadas por AZEVEDO (2003) e por CIMOSA (1996):
Avaliar Estado de Negócio: nessa primeira atividade será avaliado o estado da
empresa na qual o eventual sistema (no caso um ERP) será implementado. Nela são
descritos o estado atual da empresa e uma definição prévia dos objetivos e metas do
trabalho de modelagem de negócios. Produtos Resultantes: Avaliação da
Organização Alvo e Documento de Visão Empresarial.
Modelar os Objetivos do Negócio: a modelagem dos objetivos deve identificar os
principais objetivos e sub-objetivos do negócio numa estrutura hierárquica que
permita a visualização de dependência entre tais objetivos. Este modelo servirá de
base para a definição dos processos de negócio. A modelagem dos objetivos do
negócio deve ser feita com base em entrevistas realizadas com os conhecedores do
negócio. Produto Resultante: Diagrama de Modelo de Objetivos.
Modelar os Processos da Empresa: os processos de negócio devem ser definidos
buscando a realização dos objetivos identificados no Modelo de Objetivos do
Negócio. Porém, não é necessário haver uma relação 1 para 1 entre processos de
negócios e objetivos do negócio pois muitos processos auxiliares não estarão
necessariamente relacionados a um objetivo do Modelo de Objetivos do Negócio.
Entrevistas com os envolvidos no negócio também devem ser realizadas para
99
fornecer subsídios à definição dos processos de negócio. As atividades são
identificadas, mas não são detalhadas nesta etapa. A intenção é poder estrutura-las
e definir o processo e o seu respectivo comportamento conforme as regras de
negócios da empresa. Produto Resultante: Gabaritos e Diagramas de Processos de
Negócio e respectivos diagramas de estado.
Modelar as Atividades dos Processos: refere-se a descrição e detalhamento das
atividades dos processos que serão apoiados pelo sistema ERP, levantadas no
passo anterior. A análise das atividades possibilita a identificação das informações
(documentos) e recursos materiais ou humanos (incluindo suas capabilidades)
necessários e utilizados na operação da empresa. Isto permite a identificação de
todas as fontes e pontos de consumo de objetos. A derivação de objetivos e
restrições para a atividade de empresa orienta a identificação do conjunto de
capabilidades necessárias para a transformação dos objetos de entradas em objetos
de saídas. Entradas e saídas de recursos e entradas e saídas de controle
complementam a descrição da atividade de empresa fornecendo informação para a
sua execução ou identificando informação criada no curso de seu processamento.
Inicialmente, pode se identificar apenas as capabilidades de recursos, as quais
identificam as características e necessidades funcionais, sendo que em uma
atividade ou fase posterior, os recursos que atendem essas capabilidades
levantadas são definidos de forma detalhada. A definição de estados finais fornece
informações sobre o término da atividade de empresa para o processamento do
conjunto de regras de comportamento, as quais controlam a continuidade de
processos. Produto Resultante: Gabaritos de Atividades.
Modelar Informações, Recursos e Organização: as unidades organizacionais, os
recursos e as informações identificadas nas atividades de modelagem anteriores
devem ser modelados, em detalhes através de gabaritos, e em suas respectivas
estruturas através dos diagramas de estrutura. A modelagem destes elementos deve
ser feita de forma paralela, após a atividade de modelagem de processos e de
atividades a fim de se ter um melhor entendimento dos termos relacionados ao
negócio e conseqüentemente uma maior consistência na modelagem do mesmo. Os
objetos (de entradas e saídas das atividades de empresas) relevantes são descritos
através de seus atributos. Objetos de empresas e seus relacionamentos são
100
definidos e arranjados em estruturas hierárquicas de objetos. Seguindo uma análise
similar, são estabelecidas ambas as vista de recursos (descrição de capabilidades e
recursos) e vista de organização (responsabilidades e autoridades para unidades de
organização e células de organização). Nestas duas vistas, estruturas hierárquicas
podem ser projetadas tanto para os recursos como para a organização da empresa.
Deve-se modelar o comportamento dos recursos através de um diagrama de estado.
Produtos Resultantes: Gabaritos e Modelos de Estrutura de Recursos, de
Informações e de Organização, e Diagrama de Estado de Recursos.
Definir Papéis e Responsabilidades: Cada processo de negócio deve possuir um
responsável, uma vez que ele geralmente não estará ligado a uma única unidade
organizacional, mas sim passando por mais de uma delas. Cada processo por sua
vez define um fluxo de eventos que podem envolver um ou mais atores. É
necessário definir que atores agem em cada um dos processos. Isto pode ser feito
através de uma análise do fluxo de eventos e associação destes aos atores
envolvidos no processo. Produto Resultante: Tabela de Papéis e Responsabilidades.
Figura 6.2. Workflow para Modelagem de Negócios.
Modelagem
dos processos
Modelagem
dos Objetivos
Modelagem
das atividades
Modelagem
das
Modelagem da
organização
Modelagem
dos Recursos
início das
atividades
Avaliar Estado
do Negócio
Modelagem da
or
g
aniza
ç
ão
Fim das
atividades
101
6.5. WORKFLOW DE LEVANTAMENTO DE REQUISITOS
A Figura 6.3 mostra o Workflow de Levantamento de Requisitos. O
Gerenciamento de Requisitos envolve um trabalho de equipe para estabelecer e
manter acordo entre os interessados e a equipe de desenvolvimento no que o
sistema deve fazer. Num projeto de um software de ERP devem ser considerados
vários tipos de Requisitos, como características de alto-nível, requisitos funcionais e
não-funcionais detalhados e casos de uso. Este Workflow tem como objetivo captar
e gerenciar efetivamente os requisitos do projeto e, para isso, descreve como definir
uma visão do sistema e traduzi-la num modelo de caso de uso que, com
especificações adicionais, define as exigências de software detalhadas do sistema.
Tudo isso, tendo como objetivo atender ao resultado das análises de negócios
obtidas com o Workflow anterior. Suas atividades são baseadas no RUP
(KRUCHTEN, 2003) e em AZEVEDO (2003):
• Analisar o Problema: Nesta atividade deve-se ganhar o acordo numa
declaração do problema considerado, identificar os interessados,
identificar os limites e sujeições do sistema.
• Entender as Necessidades do Interessado: Nesta atividade usam-se
várias técnicas de extração para se reunir solicitações dos usuários e
obter uma compreensão clara das reais necessidades dos interessados do
sistema, por exemplo, através de entrevistas e de modelos de processos
já desenvolvidos anteriormente.
• Definir o Sistema: Esta atividade baseia-se na contribuição dos
interessados para estabelecer o conjunto de características do sistema a
ser considerado para entrega, determinar os critérios que serão usados,
para priorizá-los e começar a fixar, com os interessados, expectativas
realistas sobre como as características serão entregues e identificar os
processos, atores e casos de uso necessários para cada característica
fundamental. Para complementar/detalhar esta atividade são propostos
duas atividades:
a) Identificar Necessidades de Informatização: Nesta atividade deve-se
associar os processos de negócio aos sistemas de informação que lhes
102
dão suporte e assim identificar a possível necessidade de novos sistemas
de informação através da identificação de carências de suporte
automatizado de informação e operações aos processos. Sugere-se a
utilização do Diagrama de Linha de Montagem como base para a
realização desta atividade. Produto Resultante: Diagrama de Linha de
Montagem com os pacotes de linha de montagem identificados.
b) Derivar Casos de Uso dos Processos de Negócio: Os casos de uso
devem ser identificados com base nos processos de negócio. Esta
atividade deve resultar em uma Relação de Casos de Uso na qual deve-se
associar cada caso de uso identificado ao processo (ou processos) de
negócio a que este atende. Sugere-se a utilização do Diagrama de Linha
de Montagem como base para a realização desta atividade. A identificação
dos casos de uso no Diagrama de Linha de Montagem se dá através do
agrupamento de referências (entre o processo e os sistemas) de mesma
natureza. Produto Resultante: Diagrama de Linha de Montagem com
casos de uso identificados.
Atividades descritas acima forma o Modelo de Casos de Uso que quando
descrito em detalhes, mostra passo a passo como o sistema interage com
os Atores e o que faz em cada Caso de Uso.
Produto Resultante: Documento de Visão, que representa as
necessidades fundamentais dos interessados e as características do
sistema (incluindo os diagramas de linha de montagem com casos de uso
identificados).
• Administrar a Extensão do Sistema: Esta atividade se resume em
coletar informações importantes de interessados no projeto e mantê-las –
junto aos requisitos – como atributos de requisitos, para serem usadas na
priorização e alcance do Conjunto de Acordo de Requisitos, assim o sistema
pode ser entregue a tempo e num orçamento que satisfaça as expectativas
dos clientes.
• Refinar a Definição do Sistema: Nesta atividade deve-se voltar a utilizar
o Diagrama de Montagem e o Modelo de Casos de uso e detalhar os
requisitos de software do sistema para fazer um acordo com o cliente sobre
103
a funcionalidade do sistema e também captar outros requisitos importantes,
como Requisitos não-funcionais, sujeições de projeto e assim
sucessivamente.
• Administrar Mudanças de Requisitos: Esta atividade se resume em
usar atributos de requisitos e rastreamento para avaliar o impacto das
mudanças de requisitos no sistema, usar uma autoridade central, como um
Painel de Controle de Mudança, que nada mais é do que um grupo de
vários interessados técnicos e administrativos, para controlá-las, manter
acordo com o cliente e estabelecer as expectativas realistas no que será
entregue.
Os Produtos Resultantes das três últimas atividades são as
Especificações Suplementares, que representam um importante
complemento ao Modelo de Casos de Uso, porque juntos eles captam
todos requisitos de software (funcional e não-funcional) que precisam ser
descritas para servirem como Especificação Completa de Requisitos de
Software.
Figura 6.3. Workflow de Levantamento de Requisitos.
Fonte: Adaptado de KRUCHTEN P. Introdução ao RUP – Rational Unified Process, 2003
, página
138
Definição de
Re
q
uisitos Com
p
leta
Administrar Mudança
de Re
q
uisitos
[Sistema novo] [Sistema
existente]
[Nova
Contribuição]
Analisar o Problema Entender
Necessidades do
[Problema
incorreto]
Definir o Sistema Administrar a Extensão
do Sistema
[Endereçar
problema correto]
[Não pode fazer
todo o trabalho]
Trabalhar no
alcance
[Mais iterações]
Refinar a definição do
Sistema
104
6.6. WORKFLOW DE ANÁLISE E PROJETO
A Figura 6.4 mostra o Workflow de Análise e Projeto. A proposta desse
Workflow é traduzir os Requisitos numa especificação que descreva como
implementar o sistema. Para isso, é necessário entender os Requisitos e transformá-
los num Projeto de Sistema, selecionando a melhor estratégia de implementação. No
início do Projeto, é necessário estabelecer uma arquitetura robusta, de forma que
possa ser projetado um sistema fácil de entender, construir e evoluir. Após, são
realizados ajustes no projeto para combinar com o ambiente de implementação,
projetando-o para desempenho, robustez, escalabilidade e teste, entre outras
qualidades.
Neste Workflow chamaremos suas atividades de Detalhe do Workflow,
pois cada um deles é composto por uma ou mais atividades, executadas pelos
trabalhadores do projeto que são o Arquiteto, que conduz e coordena as atividades
técnicas e artefatos ao longo do projeto, e o Projetista, que define as
responsabilidades, operações atributos e relações de uma ou várias classes, e
determina como eles deveriam ser ajustados ao ambiente de implementação. Os
Detalhes desse Workflow são (KRUTCHEN, 2003):
• Definir uma Arquitetura Candidata: Este Detalhe é composto das
atividades Análise Arquitetônica, executada pelo Arquiteto, e Análise de
Caso de Uso, executada pelo Projetista. Seu propósito é:
Criar um esboço inicial da Arquitetura do Sistema, definindo:
- um conjunto inicial de elementos arquiteturalmente significantes
para ser usado como base para a análise;
- um conjunto inicial de mecanismos de análise;
- a formação de camadas e organização inicial do sistema; e,
- as realizações de Caso de Uso para ser endereçado na iteração
atual.
Identificar as Classes de Análise dos Casos de Uso arquiteturalmente
significantes.
105
Atualizar as realizações de Caso de Uso com as Iterações de Classe
de Análise.
• Refinar a Arquitetura: Este Detalhe é composto das atividades
Identificar Mecanismo de Projeto, Identificar Elementos de Projeto,
Incorporar Elementos de Projeto Existentes, Descrever Arquitetura de
Execução e Descrever Distribuição, todas executadas pelo Arquiteto, e a
Revisão da Arquitetura, executada pelo Revisor de Arquitetura, que é um
trabalhador que pode ser incluído opcionalmente a este Workflow. O
propósito deste Detalhe é:
Fornecer a transição natural das atividades de análise para as
atividades de projeto, identificando:
- os elementos de projeto apropriados dos elementos de análise;
e,
- os mecanismos de projeto apropriados dos mecanismos de
análise relacionados.
Manter a consistência e integridade da Arquitetura, assegurando que:
- os elementos novos de projeto identificados para a iteração
atual estejam integrados com os elementos de projeto
preexistentes; e,
- a reutilização máxima de componentes disponíveis e de
elementos de projeto seja alcançada, assim que possível, no
trabalho do projeto.
Descrever a Organização da Execução do Sistema e a Arquitetura de
Distribuição.
Organizar o Modelo de Implementação para fazer a transição entre o
Projeto e a Implementação sem emenda.
• Analisar o Comportamento: Este Detalhe é composto das atividades de
Caso de Uso, executada pelo Projetista, Identificar Elementos do Projeto,
executada pelo Arquiteto, e Revisão do Projeto, executada pelo Revisor do
Projeto. Seu propósito é transformar as descrições de comportamento
106
fornecidas pelos Casos de Uso num conjunto de elementos nos quais o
projeto possa ser baseado.
• Projetar Componentes: Este Detalhe é composto das atividades Projetar
Caso de Uso, Projetar Classe e Projetar Subsistema, executadas pelo
Projetista, e a Revisão de Projeto, executada pelo Revisor do Projeto. Seu
propósito é:
Refinar as definições dos Elementos de Projeto, resultando nos
detalhes de como os elementos de projeto implementam o
comportamento requerido.
Refinar e atualizar as realizações de Caso de Uso baseando-se em
novos elementos de projeto introduzidos, mantendo assim atualizadas
as realizações de Caso de Uso.
Revisar o Projeto quanto a sua evolução.
Os Detalhes de Workflow Projetar Componentes de Tempo Real e
Projetar Banco de Dados, são detalhes opcionais do Workflow de Análise e
Projeto, sendo que não serão comentados neste trabalho.
Na seção seguinte serão descritas sucintas dos objetivos das fases do
Ciclo de Vida de GERA e, após cada uma dessas descrições, serão sugeridas
atividades a serem executadas em cada uma delas. Essa proposta está resumida no
quadro 6.1. Então, assim como no RUP todos os seus Workflows são utilizados em
todas as fases, com algumas atividades tendo um maior ou menor ênfase,
teoricamente, todos os Workflows propostos neste trabalho podem ser são utilizados
nas fases do GERA, sendo que suas atividades possuem maior ou menor ênfase.
Na prática, são definidas algumas atividades de cada Workflows para serem
realizadas com abordagens diferentes em cada fase.
107
Figura 6.4. Workflow de Análise e Projeto.
Fonte: Adaptado de KRUCHTEN P. Introdução ao RUP – Rational Unified Process, 2003
, página
149
6.7. METODOLOGIA PROPOSTA
Como relatado anteriormente, apenas os primeiros Workflows e primeiras
fases são consideradas, pois neles estão as atividades relacionadas com o
alinhamento dos objetivos dos negócios e o ERP a ser desenvolvido.
[Tempo não
real]
Projetar o Banco de
Dados
Projetar Componentes
de Tempo Real
[Iteração de
elaboração
anterior
]
Definir a Arquitetura
Candidata
[Iteração de
elaboração]
Analisar o
Comportamento
Projetar Componentes
Refinar a Arquitetura
[Opcional] [Tempo real]
108
Quadro 6.1. Relacionamento entre as atividades dos Workflows e as Fases do Ciclo de Vida de GERA
Projeto
Workflows
Fases do
GERAM
Atividades e
Detalhes
Identificação Conceito Requisitos
Preliminar Detalhado
Implementação Operação Retirada
Avaliar Estado de
Negócio
X X
Modelar os
Objetivos do
Negócio
X X
Modelar os
Processos de
Negócio
X X X
Modelar as
Atividades dos
Processos
X X
Modelar
Informações,
Recursos e
Organização
X X
Modelagem de Negócios
Definir Papéis e
Responsabilidades
X X
Analisar o
Problema
X X
Entender as
Necessidades do
Interessado
X X
Definir o Sistema
X X X
Identificar
Necessidades de
Informatização *
X X X
Derivar Casos de
Uso dos
Processos de
Negócio*
X X X
Administrar a
Extensão do
Sistema
X X X
Refinar a Definição
do Sistema
X X
Levantamento de Requisitos
Administrar
Mudanças de
Requisitos
X X
Definir uma
Arquitetura
Candidata
X X
Refinar a
Arquitetura
X X
Analisar o
Comportamento
X X
Projetar
Componentes
X X
Análise e Projeto
Projetar Banco de
Dados
X X
Fonte: Própria autoria, Fevereiro 2006.
109
6.7.1. ABORDAGENS NA FASE DE IDENTIFICAÇÃO DA ENTIDADE
Avaliar Estado de Negócio – São definidos e descritos os problemas do negócio e
identificada a entidade a ser desenvolvida ou afetada por mudanças e melhorias.
Esta atividade identifica as maiores áreas de negócios da entidade particular sendo
considerado, em termos de seus limites e suas relações com elementos de seu
ambiente externo. Inclui a identificação da existência e da natureza de uma carência
(ou necessidade de mudança) para a entidade particular. Em outras palavras, define
qual é a entidade que está sendo considerada no ciclo de vida de desenvolvimento
ou melhoria. A Avaliação da Organização Alvo representando o estado atual da
entidade em questão é elaborado;
Modelar os Objetivos do Negócio – É realizada uma definição preliminar de
questões estratégicas incluindo planos e objetivos das áreas de negócio afetadas. É
criado um Documento de Visão Empresarial parcial, representando os principais
objetivos do negócio;
Modelar os Processos de Negócio – Os (macro) processos relacionados com os
principais objetivos de negócios da empresa são relacionados, identificando aqueles
que estariam diretamente envolvidos no desenvolvimento ou mudanças a serem
realizadas. Os processos não são detalhados em termos de um modelo, mas
apenas uma breve descrição com os objetivos e resultados finais desses processos
são descritos;
Analisar o Problema – Se busca criar uma declaração do problema em termos de
TI, além de identificar os interessados e fazer uma primeira delimitação do sistema.
6.7.2. ABORDAGENS NA FASE DE CONCEITO DA ENTIDADE
Avaliar Estado de Negócio – São detalhadas e esclarecidas questões pendentes
(do estado do negócio descrito anteriormente) com relação ao escopo (limites) da
entidade a ser considerada, o problema e contexto em questão, de forma a defini-los
completamente;
Modelar os Objetivos do Negócio – Os objetivos do negócio da empresa são
consolidados, destacando-se aqueles diretamente relacionados com o problema
(objetivos estratégicos para a área de TI pode ser levantados), consolidando a
definição da missão, visão, valores, estratégias, metas, conceitos operacionais,
políticas, e planos empresariais para entidade;
Modelar os Processos de Negócio – São revisados a lista de processos de
negócios da empresa anteriormente levantados. Os processos que estão
diretamente ligados ao problema e objetivos identificados como alvo de intervenção
e serão suportados pelo sistema têm a sua descrição detalhada;
110
Definir Papéis e Responsabilidades – São indicados responsáveis (possíveis
usuários) para cada um dos processos definidos anteriormente, os quais poderão
participar na definição dos requisitos do futuro sistema;
Analisar o Problema – Definido o escopo, os objetivos e os processos do negócio,
é necessário uma melhor compreensão do ponto de vista do sistema. Esta atividade
visa realizar um trabalho que mantenha um equilíbrio e um primeiro acordo entre os
interesses dos responsáveis pelos processos, usuários e a equipe de
desenvolvimento, no que diz respeito ao o que o sistema considerado deve fazer,
limites, objetivos e metas.
6.7.3. ABORDAGENS NA FASE DE REQUISITOS DA ENTIDADE
Modelar os Processos do Negócio – Apenas os processos que serão suportados
pelo sistema, identificados na fase anterior, são revisados, modelados e definidos
em detalhes, principalmente com relação a sua estrutura e comportamento. Seus
possíveis resultados finais (saída) são verificados para confirmar se estão de acordo
com os objetivos estratégicos e metas definidos para o negócio;
Modelar as Atividades dos Processos – As atividades dos processos que serão
suportados pelo sistema são modeladas levantando os objetos de informações e
materiais que serão transformados pela atividades; levantando os recursos
(humanos, de manufatura ou de tecnologia de informação) necessários; assim como
as unidades de organização com responsabilidade e autoridade para necessários
para controlar cada atividade. O procedimento para cada atividade é desenvolvido,
porém concentrando-se em requisitos e não em detalhes tecnológicos;
Modelar Informações, Recursos e Organização – Os objetos de informações
levantados anteriormente na modelagem das atividades dos processos são
modelados em termos de seus atributos e estrutura. Também, são descritos os
objetos de recursos e de organização levantados na atividade anterior, tudo isso
através de gabaritos e diagramas. Deve se enfatizar a descrição das capabilidades
necessárias para os recursos e as unidades de organização visando a realização da
atividade do processo, mas ainda não necessariamente enfatizar como informatizar
(questões tecnológicas);
Definir Papéis e Responsabilidades – Baseado nas atividades anteriores, são
revisados os principais responsáveis, usuários e atores envolvidos nos processos,
que devem confirmar junto com a equipe de desenvolvimento os requisitos do
negócio e do sistema;
Analisar o Problema – Em função do levantamento de requisitos dos negócios, são
revisados o acordo entre os interesses dos responsáveis pelos processos, usuários
e a equipe de desenvolvimento, e novos requisitos podem ser definidos e
complementados no que diz respeito ao o que o negócio considerado deve fazer,
limites, objetivos e metas, refinando a compreensão do ponto de vista do sistema;
111
Entender as Necessidades do Interessado – também é importante neste ponto
listar com clareza, as reais necessidades dos usuários específicas do sistema.
Durante este processo, são realizadas inúmeras entrevistas com cada usuário e,
através delas e de outras técnicas de extração de requisitos são estabelecidos o
conjunto de característica e critérios do sistema considerado.
Definir o Sistema
Identificar Necessidades de Informatização – para cada um dos processos
a serem suportados pelo sistema, necessidades em termos de leituras e
gravações são levantadas, identificando sistemas de informações já
existentes ou a carência de novos (módulos de) sistemas a serem
desenvolvidos, através do Diagrama de Linha de Montagem ;
Derivar Casos de Uso dos Processos de Negócio – para cada processo, é
realizada a identificação de casos de uso no Diagrama de Linha de
Montagem, que se dá através do agrupamento de referências (entre o
processo e os sistemas) de mesma natureza;
Administrar a Extensão do Sistema – se resume em coletar informações
importantes de interessados no projeto e mantê-las como atributos de requisitos;
Definir uma Arquitetura Candidata – se cria um esboço inicial da arquitetura do
sistema, e onde através da atividade Identificar Classes a partir da arquitetura de
negócio, busca-se a identificação das principais Classes do Sistema com base na
análise dos Modelos de Recursos e de Informações;
Outras atividades relativas aos Workflows de Implementação, Teste e
Implantação.
6.7.4. ABORDAGENS NA FASE DE PROJETO PRELIMINAR
Modelar as Atividades dos Processos – Os procedimentos para cada atividade
são consolidados e as entradas e saídas de objetos de informações, recursos e
organização são revistos, e também encontrado novos objetos, em função de
possíveis novos requisitos;
Modelar Informações, Recursos e Organização – modelos de informações, de
recursos e unidades organizacionais são revisados e detalhados em função da
atividade anterior, sendo que também pode-se identificar objetos de informações
que espelhem os objetos de recursos e de organização, importantes não só para o
projeto do banco de dados, mas também para o possível projeto sistemas de
Workflow e sistemas especialistas para trabalhar de forma integrada ao sistema
(ERP) da empresa (por exemplo para programação da produção);
Entender as Necessidades do Interessado – revisar a extração de requisitos e o
conjunto de características e critérios do sistema considerado.
112
Definir o Sistema
Identificar Necessidades de Informatização – são revisados e consolidados
as leituras e gravações necessárias em função de atualizações no modelo relativas
ao negócio;
Derivar Casos de Uso dos Processos de Negócio – casos de uso
anteriormente identificados são revisados e novos casos de uso são definidos;
Administrar a Extensão do Sistema – requisitos de projeto já documentados são
revisados e novos são acrescidos em função da identificação de necessidades de
usuários;
Refinar a Definição do Sistema – Consolidados novos requisitos, são refinadas as
necessidades de informatização e a derivação de casos de uso dos processos de
negócio;
Administrar Mudanças de Requisitos – ao longo das atividades anteriores, deve
se avaliar o impacto de mudanças de requisitos do sistema;
Definir uma Arquitetura Candidata – a arquitetura do sistema esboçada
anteriormente é revisada e atualizada através de novas classes, como aquelas
oriundas de alterações nos modelos de recursos e de informações do negócio;
Refinar a Arquitetura – a arquitetura é refinada visando a transição da fase de
análise para a fase de projeto detalhada, mantendo consistência e organização da
arquitetura;
Analisar o Comportamento – transformar as descrições de comportamento
fornecidas pelos Casos de Uso num conjunto de elementos nos quais o projeto
possa ser baseado;
Projetar Banco de Dados – baseado no modelo de informações o projeto do banco
de dados deve ser iniciado, com maior preocupação em atender os requisitos
funcionais do sistema e com menor ênfase tecnológica (maior ênfase em questões
tecnológica visando a implementação é deixada para o projeto detalhado);
Projetar Componentes – objetivo é refinar e atualizar algumas definições e
monitorar a evolução do projeto realizando revisões;
Outras atividades relativas aos Workflows de Implementação, Teste e Implantação.
113
6.8. C
ONSIDERAÇÕES FINAIS
Algumas observações são feitas com relação a essa proposta:
• a principal motivação para a proposta é a inclusão de aspectos de engenharia de
empresas, visando uma melhor definição de requisitos para o desenvolvimento e
adaptações de um ERP para empresas (de manufatura ou de serviço).
• ela está ainda a nível acadêmico, necessitando revisão e testes para validações
na prática;
• ela se concentra em atividades de modelagem, durante o desenvolvimento de
sistemas de empresa (por exemplo, não aborda questões relacionadas ao
gerenciamento do projeto);
• não atende todos os aspectos propostos pela estrutura de modelagem GERA,
devendo os demais aspectos serem abordados em pesquisas futuras;
• a metodologia de referência não é uma receita pronta para ser usada, sendo que
para cada caso, o usuário ou desenvolvedor pode fazer uma adaptação, incluindo,
ou não, as atividades relacionadas na proposta, para o seu objetivo particular;
• caso o objetivo de desenvolvimento seja simples, essa proposta pode ser muito
complexa e não considerada;
• ela ainda não considera a utilização de modelos de referência;
• ela não propõe atividades para todas as fases do ciclo de vida de GERAM (no
caso da fase de implementação do sistema ERP5, as atividades não deveriam se
diferenciar muito das atividades originalmente propostas pelo UP ou RUP).
Neste capítulo foi apresentada uma proposta de metodologia de desenvolvimento
de sistemas de informação baseado nas fases do Ciclo de Vida de GERA, com o
objetivo de melhor definir os requisitos para o desenvolvimento de um ERP para
empresas de manufatura, e também pode servir para a integração com o projeto de
outros sistemas de empresa, como sistemas de manufatura e sistema
organizacionais.
114
CAPÍTULO 7
CONCLUSÕES
Devido aos novos desafios impostos às indústrias pela alta
competitividade do mercado, impulsionada pela globalização, as organizações têm
sido forçadas a investir em novas tecnologias, novos produtos e novas estratégias
de gestão, para manterem sua competitividade, e conseqüentemente sua
sobrevivência. Nesse contexto, as mesmas têm investido em avançadas ferramentas
de gestão,os ERP (Enterprise Resource Planing), que devido ao alto custo e a
complexidade de implantação, sua adoção por Pequenas e Médias Empresas
(PMEs) se tornou impraticável, motivando assim, a criação do projeto ERP5, que
oferece uma série de vantagens que buscam reduzir esses problemas. Este projeto,
que está sendo desenvolvido por um consórcio de instituições e empresas da França
e Brasil, e tem o objetivo de projetar e desenvolver uma configuração completa de
componentes de software ERP e fornecer informação suficiente (jurídico, social,
teórica) para que todos possam entender e implementar o ERP em companhias de
qualquer porte. Levando-se em consideração esta questão, e as demais
características intrínsecas ao ERP5, tornou-se necessário a criação de uma
metodologia específica para o desenvolvimento e implantação deste sistema. Esta
dissertação apresentou um estudo sobre Arquiteturas de Referência, destacando o
GERAM (Generalized Enterprise Reference Architecture and Methodology) e sobre
Metodologias de Modelagem de Empresas, destacando o UP (Unified Process), e ao
final sugeriu uma proposta de Framework para o desenvolvimento e implantação dos
componentes do projeto ERP5.
A metodologia de desenvolvimento genérica proposta no Capítulo 6 foi
baseada na arquitetura GERAM, pelo fato de proporcionar uma arquitetura de
referência genérica, fruto de avançadas pesquisas e demais metodologias em
engenharia de empresa e engenharia de sistemas. Assim, a metodologia que teve
com metodologia central a metodologia CIMOSA e o UP (entre outras), sendo que
foram inseridas atividades ligadas a modelagem de vários aspectos de empresas (e
não apenas ligadas a aspectos de informações).
No Capítulo 5 foram propostos os componentes para uma arquitetura
particular a ser utilizadas pelos desenvolvedores e usuários do ERP5, baseados no
GERAM.
115
Assim, a arquitetura de engenharia de empresa adotada foi a própria
arquitetura de referência de GERAM, o GERA. É claro que esta deve funcionar
também como uma arquitetura de referência, sendo que cada usuário ou
desenvolvedor pode desconsiderar algo ou até mesmo acrescentar algo a mais,
conforme as reais necessidades.
Com relação a metodologia, foi proposta uma metodologia simplificada,
conforme estudo apresentado no Capítulo 6, baseada principalmente no UP e
CIMOSA, mas que também pode ter atividades e artefatos acrescentados ou
eliminados, em função dos requisitos do usuários. Lembrando, a estrutura da
metodologia deve seguir a arquitetura adotada.
A linguagem adotada deve ser a UML, padrão de fato, e sua capacidade
de expressão pode ser ampliada com o uso de extensões, como já exemplificado.
Existem várias ferramentas para suporte a modelagem com UML, sendo
que critérios como possibilidade de utilizar extensões e a capacidade de transformar
modelos em código executáveis, direta, ou indiretamente (através de exportação de
modelos em XMI por exemplo).
Modelos de referência podem ser utilizados para facilitar o processo de
modelagem, e tem sido propostos por pesquisadores do Brasil e exterior. No caso do
projeto ERP5, eles devem ser desenvolvidos (ou adotados os já propostos) e
documentados para ser disponibilizados aos usuários e desenvolvedores.
Conceitos e ontologias de empresas ainda são questões a serem
investigadas, sendo que não há, mesmo a nível internacional, muitos estudos e
propostas já consolidadas.
Módulos de sistemas são os componentes de softwares propostos pelo
sistema ERP5, e outros sistemas que podem estar ligados por exemplo a sistemas
de manufatura.
A inserção dos vários aspectos de modelagem de empresas passa a ser
mais importante quando se refere ao desenvolvimento de sistemas integrados de
gestão (ou ERPs). Assim, a importância do trabalho realizado está na proposta de
todos os componentes necessários para o desenvolvimento de sistemas conforme
116
GERAM, que foi originado de estudos visando um padrão. Procurou-se reunir, então,
os conceitos, técnicas e ferramentas necessários para o desenvolvimento do ERP5,
considerando não só os aspectos de informações, mas também aqueles aspectos
principais necessários ao projeto de uma empresa, o que deve contribuir para
facilitar o desenvolvimento e que o sistema desenvolvido com o ERP5 capture os
reais requisitos para a gestão da empresa.
Alguns componentes propostos aqui são de difícil questionamento, como a
proposta da UML como linguagem a ser adotada. Algumas outras propostas
carecem de melhores estudos, principalmente a questão referente a conceitos e
ontologias de empresa. E outras questões, como a metodologia proposta, são mais
questionáveis, pois dependem das necessidades de cada usuário ou desenvolvedor.
O que não invalida tecnicamente a proposta feita aqui.
Como perspectiva para trabalhos futuros, fica a melhor definição de
questões/aspectos conceituais que não foram possíveis de serem aprofundados
neste trabalho (por exemplo, detalhes de como os modelos de referência seriam
considerados na metodologia), e a realização de trabalhos de caráter mais práticos,
como modelos de referência, o desenvolvimento de módulos de sistemas utilizando
a metodologia proposta, entre outros trabalhos.
117
REFERÊNCIAS BIBLIOGRÁFICAS
AGUILAR-SAVÉN, R.S. Business process modelling: Review and Framework,
International Journal of Production Economics, v. 90, n. 2, P. 129-149, 2004.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 1227, Ciclo de Vida e
Processo de Desenvolvimento. Brasil 1998.
ASSOCIAÇÃO BRASILEIRA DE NORMAS TÉCNICAS. NBR ISO/IEC 9000-3,
Desenvolvimento e Documentação de Software. Brasil 1998.
ARLOW J.; NEUSTADT I. UML and the Unified Process – Practical Object-
Oriented Analysis & Design, London: Editora Addison Wesley., 2002.
AZEVEDO Jr., D. P. Sistematização do Levantamento de Requisitos a Partir de
Modelos de Negócio em Processos Iterativos de Desenvolvimento de Software,
Campos dos Goytacazes – RJ, 2003. Dissertação (Mestrado em Ciências de
Engenharia) Universidade Estadual do Norte Fluminense – UENF.
BERIO, G. & VERNADAT, F.B. New developments in enterprise modelling using
CIMOSA, Computers in Industry, V. 40, p. 99-114, 1999.
BERNUS P.; NEMES, L.. Requirements of the Generic Enterprise Reference
Architecture and Mehodology, v. 21, p. 125-136, 1997.
BOOCH, G.; JACOBSON, I.; RUMBAUGH, J. UML – Guia do Usuário. Rio de
Janeiro: Campos, 2000.
CAMEIRA, F. R.; CHALLHOUB, F.; VICENTE, L. Engenharia de Processos e
Engenharia de Sistemas: construindo Arquiteturas Integradas de Sistemas
Componentizados a partir da concepção dos processos de negócio com uso
de UML, Ouro Preto – MG: ENEGEP, 2003.
CAMPOS, R. Uma Proposta de Modelagem para Integração de Sistemas de
Gestão de Produção em Empresas de Manufatura, Campinas – SP, 1998. Tese
de Doutorado
118
CARVALHO, R. A. ERP5 – Desenvolvimento de Sistema ERP Avançado e de
Código Aberto para Pequenas e Médias Empresas, Campos dos Goytacazes –
RJ, 2003.
CARVALHO, R. A.; CAMPOS, R. A Development Process Proposal for the ERP5
System. In: IEEE INTERNATIONAL CONFERENCE ON SYSTEMS, MAN, AND
CYBERNETICS, Taipei, 2006. Proceedings of the 2006 IEEE International
Conference on Systems, Man, and Cybernetics. 2006.v. 1.
CHUNG, S. H.; SNYDER, C. A. ERP Adoption: a technological evolution
approach, International journal of Agile Management Systems. Vol. 2, n. 1, pg
24-32, 2000.
CIMOSA Association, CIMOSA technical baseline, CIMOSA Association,
Stockholmerst 7, D-70731, Boblingen, Germany, 1996.
CORRÊA, H. L.; GIANESI, I. G. N.; CAON M. Planejamento, Programação e
Controle da Produção – MRP II / ERP Conceitos, Uso e Implantação, São Paulo
– SP, Ed. Atlas S.A., 2000.
FERREIRA, A.S. Um Modelo de Referência para o Planejamento, Programação
e Controle da Produção em um ERP de Código Aberto, Campos dos Goytacazes
– RJ, 2005. Dissertação (Mestrado em Ciências de Engenharia) Universidade
Estadual do Norte Fluminense – UENF.
HABERKORN, E. Teoria do ERP – Enterprise Resource Planning, São Paulo –
SP: MAKRON Books, 1999.
HENDERSON-SELLERS, B.; COLLINS, G.; DUÉ, R.; GRAHAM, I. A qualitative
comparison of two process for object.
HULL, M.E.C.; TAYLOR, P.S.; HANNA, J.R.P.; MILLAS, R.J. Software
development process – an assessment, Information and Software Technology.
IFIP – IFAC Task Force on Architectures for Enterprise Integration GERAM:
Generalised Enterprise Reference Architecture and Methodology – Version
1.6.3, Março 1999.
119
KALPIC, B.; BERNUS, P. Business process modelling in industry - the powerful
tool in enterprise management. Computers in Industry, v. 47, n. 3, p. 299-318,
2002.
KIM, C.; WESTON, R.H.; HODGSON, A.; LEE, K. The Complementary Use od
IDEF and UML Modeling Aproaches, Computers in Industry, v. 50, p. 35-56,
2003.
KOSANKE, K.; VERNADAT, F.; ZELM, M. CIMOSA: Enterprise Engineering and
Integration. Computers in Industry, v.40, n. 2, p. 83-97, 1999.
KOSANKE, K.; NELL, J. G. Standardisation in ISO for enterprise engineering and
integration, ELSEVIER: Computers in Industry – Volume 40, Pages 311-319, 1999.
KOSANKE, K.; ZELM, M. CIMOSA modelling processes, ELSEVIER: Computers
in Industry – Volume 40, Pages 141-153, 1999.
KRUCHTEN, P. Introdução ao RUP – Rational Unified Process, Rio de Janeiro:
Editora Ciência Moderna Ltda., 2003.
KRUCHTEN, P. B. The 4+1 View Model of Architecture. Piscataway, NJ: IEEE
Software, 1995.
LI, H.; WILLIAMS, T.J. Management of complexity in enterprise integration
projects by the PERA methodology, v. 13, p. 417-427, 2002
MERTINS, K. & JOCHEM R. Architectures, methods and tools for enterprise
engineering, International Journal of Production Economics, V. 98, N. 2, P. 179-
188, 2005.
MENEZES, A.M.P.B.; SOUZA, I.F. Análise do software livre como uma
ferramenta de TI para as PMEs, Anais do XXV Encontro Nacional de Engenharia
de Produção, Porto Alegre, 2005.
NORAN, O. An analysis of the Zachman framework for enterprise architecture
from Geram perspective, Annual Reviews in Control, v. 27, p. 163-183, 2003.
120
NORAN, O. A systematic evaluation of the C4ISR AF using ISO 15704 Annex A
(GERAM), Computer in Industry, v. 56, p. 407-427, 2005.
ODEH, M.; KAMM, R. Bridiging the gap between business models and system
models, Information and Software Technology, v. 45, p. 1053-1060, 2003.
OLIVEIRA, C.L.P. Proposta de Extensões da Unified Modeling Language para
Modelagem de Empresas, Campos dos Goytacazes – RJ, 2003 Dissertação
(Mestrado em Ciências de Engenharia) Universidade Estadual do Norte Fluminense
– UENF.
OLIVEIRA, C.M. Protótipo de um Ambiente de Modelagem de Empresa,
Campinas – SP, 2000 Dissertação (Mestrado em Engenharia Mecânica)
Universidade Estadual de Campinas.
MACHADO, A.; CAMPOS, R. O projeto Unified Enterprise Modelling Language e
a necessidade de integração entre metodologias em modelagem de processos
de negócio, Ouro Preto – MG, ENEGEP 23, 2003; UFOP, 2003.),
PRESSMAN, R. S. Engenharia de software. 5 Ed. Rio de Janeiro: McGraw-Hill,
2002.
PINHEIRO, V.L.O. Processo de Desenvolvimento de Software para Projetos de
Curta Duração, Gravataí – RS, 2002 Trabalho de Conclusão do Curso de
Graduação em Ciência da Computação – Universidade Luterana do Brasil.
SANTIAGO, A.S.R.E. Um Processo de Modelagem para o Sistema ERP5
baseado no Processo Unificado, Campos dos Goytacazes – RJ, 2005.
Dissertação (Mestrado em Informática Aplicada) Universidade Candido Mendes –
UCAM.
SANTOS, L.R. Modelagem de Processos de Empresas e Projeto de Sistema de
Informação: Uma Aplicação para auxilio a Previsão de Demanda de Produtos,
Campos dos Goytacazes – RJ, 2001. Dissertação (Mestrado em Ciências de
Engenharia) Universidade Estadual do Norte Fluminense – UENF.
121
SCHEER, A. ARIS – Business Process Modeling. 3ª ed., Berlim: Springer –
Verlag, 2000.
SEABRA Jr., R.M. Análise e Projeto Orientado a Objetos usando UML e o
Processo Unificado, Belém – PA, 2001 Trabalho de Conclusão do Curso de
Graduação em Ciência da Computação – Universidade Federal do Pará – UFPA.
SHEN, H.; WALL, B.; ZAREMBA, M.; CHEN, Y.; BROWNE J. Integration of
business modelling methods for enterprise information system analysis and
user requirements gathering . Computers in Industry, V.54, n. 3, p. 307-323 ,
2004.
SHORTER, D. CEN standardization activities related to CIMOSA, Computers in
Industry, V. 40, p. 305-310, 1999.
SILVEIRA, D.; SCHMITZ, E. Uma Metodologia de Desenvolvimento de sistemas
de Informação em Empresas de Pequeno e Médio Porte, Anais do XXV Encontro
da ANPAD, Salvador – BA, 2002.
SILVEIRA, D.; CRUZ, P.O.S.; SCHMITZ, E. Uma Abordagem Sistemas de
Informações Focada em Modelagem de Processos, Anais do XXV Encontro da
ANPAD, Salvador – BA, 2002.
SMETS-SOLANES, J.-P.; CARVALHO, R. A. An Abstract Model for an Open
Source ERP System: The ERP5 Proposal in Proc. 8th International Conference on
Industrial Engineering and Operations Management, Curitiba, Brazil, 2002.
SMETS-SOLANES, J.-P.; CARVALHO, R. A. ERP5: A Next-Generation, Open-
Source ERP Architecture. IEEE IT Professional, V.5, n.4, pp.38-44, Jul, 2003.
SMETS-SOLANES, J.-P. ERP5: a Technical Introduction, (march 02, 2004),
disponível em
http://www.en.erp5.org/sections/documentation/articles/linuxtag.html/view.
TIJUNELIS, P. & BARRELLA, W.D. Adaptação de ERPs, Anais do XXIII Encontro
Nacional de Engenharia de Produção, Ouro Preto – MG, 2003.
122
VERNADAT, F. B. Enterprise Modeling and Integration, Principles and
Aplications, Londres, Chapman & Hall, 1996.
123
ANEXO I
FASES DO PROCESSO DE MODELAGEM DE EMPRESAS
P1 - MODELAGEM DA DEFINIÇÃO DE REQUISITOS
A primeira fase de modelagem do Processo de Modelagem consiste na
definição de requisitos para a área ou parte da empresa a ser modelada (domínios
de modelagem). Os requisitos do sistema são expressos em termos de construtores
CIMOSA oferecidos pela Arquitetura de Referência CIMOSA. A definição dos
requisitos de negócios resulta no MDR. Este modelo expressa todas as
necessidades de negócios relativas a funções, informações, recursos e organização,
que devem ser implementadas no sistema CIM da parte da empresa sob
consideração. Este modelo define “O QUE” tem que ser feito, sem considerar
restrições de implementação. Com o objetivo de controlar o processo de
modelagem, Autoridades de Projeto são definidas para todos os elementos
relevantes do modelo criado durante o Processo de Modelagem de Negócios
CIMOSA. No primeiro nível de decomposição sete subprocessos são identificados
os quais representam a tarefa global do Processo P1 (Figura A.1). O processo P1
inicia com P1.1 para a definição e estabelecimento da área de negócios a ser
modelada (Estabelecimento de Domínios). As funções e seu comportamento
(dinâmica ou fluxo de controle) são analisadas e documentadas nos dois seguintes
processos (P1.2 e P1.3). O resultado desta modelagem são analisados e
estruturados de acordo com critérios específicos em modelos de informação, de
recursos e organização (P1.4, P1.5 e P1.6). Esses modelos são um subconjunto do
modelo total da empresa. Porém, as três tarefas são independentes uma da outra, e
as três etapas podem ser realizadas em paralelo. A tarefa final do processo P1
concerne com a consistência do MDR (P1.7). Este modelo representa o
comportamento e a funcionalidade dos negócios. Uma ferramenta de suporte
utilizada na modelagem deve fornecer a animação dos modelos de processo,
suportando a verificação de consistência do modelo dinâmico. Cada um dos sete
sub-processos identificados é brevemente descrito a seguir.
124
P1.1
Estabelecimento
de Domínios
P1.2
Análise do
Comportamento
P1.5
Análise de
Recursos
P1.4
Análise da
Informação
P1.3
Análise
Operacional
P1.6
Análise da
Organização
P1.7
Verificação de
Consistência
MDR
P1 - Modelagem da Definição de Requisitos
Plano Diretor - Objetivos, restrições e diretrizes de projeto
MDR - Modelo de Definição de Requisitos
Plano
Diretor
Figura A.1. Modelagem de Definição de Requisitos (Zelm, 1995).
Fonte: CAMPOS R.
Uma Proposta de Modelagem para Integração de Sistemas de Gestão de
Produção em Empresas de Manufatura
, Campinas – SP, 1998.
P1.1 - ESTABELECIMENTO DE DOMÍNIO: As áreas de negócios (Domínios) devem ser
modeladas e suas vizinhanças são definidas pela identificação de entradas e saídas.
Entradas e saídas de domínios são eventos disparados e/ou objetos físicos e/ou de
informação (vistas de objetos), todos tendo origem e destino distintos. Objetivos e
restrições de domínios são derivados daqueles definidos para toda a empresa.
Dependências entre entradas e saídas de domínios identificam as transformações
necessárias, isto é, os diferentes processos de domínios necessários para
transformá-las. Todas as partes relativas à descrição dos domínios são
documentadas nos gabaritos de domínio.
P1.2 - ANÁLISE COMPORTAMENTAL: Cada um dos processos de domínio identificados
na etapa de modelagem anterior são estruturados em processos de negócios e
atividades de empresa. Esta estruturação pode ser tanto top-down como bottom-up.
Top-down pela decomposição funcional dos processos de domínio e bottom-up
através da agregação do conjunto de atividades de empresa identificadas em
processos de negócios. O nível de detalhe do modelo do processo de domínio
particular depende da intenção do modelador e seu interesse no controle do
processo. Do mesmo modo, atividades de empresa devem ser definidas somente se
existe uma necessidade no controle e monitoração desta sub-tarefa ou dos
resultados que ela produz. Objetivos e restrições de domínio são combinados e
representados como regras declarativas. Entradas e saídas, em termos de vistas de
objetos, dos processos são identificadas e listadas.
P1.3 - ANÁLISE OPERACIONAL: Esta parte do Processo de Modelagem de Negócios
CIMOSA diz respeito a descrição detalhada de funcionalidades (atividades de
125
empresa) identificadas no passo anterior. CIMOSA considera a atividade de
empresa como o ponto de utilização de informação e recursos e de identificação de
informações na operação da empresa. Isto permite a identificação de todas as fontes
e pontos de consumo de material, informação operacional e capabilidades de
recursos necessários. A derivação de objetivos e restrições para a atividade de
empresa suporta a identificação do conjunto de capabilidades necessárias para a
transformação de entradas de função em saídas de função. Entradas/saídas de
recursos e entradas/saídas de controle complementam a descrição da atividade de
empresa fornecendo informação para a sua execução ou identificando informação
criada no curso de seu processamento. Entrada de recurso é deixada vazia nesta
fase de modelagem sendo que as capabilidades de recursos identificam as
características e necessidades funcionais em recursos. Os estados finais fornecem
informações sobre o término da atividade de empresa para o processamento do
conjunto de regras de comportamento, as quais controlam a continuidade de
processos de domínio.
P1.4 - ANÁLISE DE INFORMAÇÃO: Após estabelecer o comportamento e funcionalidade
do processo de domínio, vista de função de CIMOSA, as informações identificadas,
capabilidades e aspetos organizacionais devem ser analisadas e estruturadas. As
vistas de objetos (entradas e saídas das atividades de empresas) relevantes são
descritas através de seus atributos. Objetos de empresas e seus relacionamentos
são definidos e arranjados em estruturas hierárquicas de objetos.
P1.5 - ANÁLISE DE RECURSOS E P1.6 - ANÁLISE DA ORGANIZAÇÃO: Seguindo uma
análise similar são estabelecidas ambas as vista de recursos (descrição de
capabilidades e recursos) e vista de organização (responsabilidades e autoridades
para unidades de organização e células de organização). Nestas duas vistas,
estruturas hierárquicas podem ser projetadas tanto para os recursos como para a
organização da empresa.
P1.7
- VERIFICAÇÃO DE CONSISTÊNCIA: O processo de Modelagem de Requisitos da
Empresa é completo com a verificação da consistência do modelo. A consistência
estática do modelo (função, informação, recurso, e organização) é avaliada em
função de walk-through estruturado, e a dinâmica do modelo é analisada através da
animação do modelo.
126
P2
- MODELAGEM DA ESPECIFICAÇÃO DE PROJETO
O propósito da fase de projeto do sistema é especificar “COMO” os
requisitos do sistema devem ser implementados, levando em consideração as
políticas relevantes da empresa, objetivos, restrições da empresa. No curso desta
fase, o Modelo de Especificação de Projeto (MEP) é iterativamente projetado e
otimizado. Enquanto que o Modelo de Definição de Requisitos é produzido pelo
usuário, a Modelagem da Especificação de Projeto deve ser executada por
especialistas, porém, com intensa interação com esses usuários. As especificações
de projeto são derivadas do MDR pelo detalhamento e acréscimo de blocos e
elementos de construção. Então, os construtores de modelagem relativos a fase de
definição de requisitos, não são apenas acrescidos por atributos adicionais (tempo,
local, etc.), mas também incluem outros construtores de modelagem (operação
funcional, entidade funcional) e construtores de modelagem de TI (esquemas,
modelo de dados, modelo de transações de dados, etc.). Os subprocessos
compondo a Modelagem da Especificação de Projeto são apresentados na Figura
A.2.
P2.8
Verificação
do Projeto
P2.1
Consolidação
do MDR
P2.2
Projeto do
Comportamento
P2.3
Projeto
Operacional
P2.5
Projeto do Sist.
de Recursos
P2.4
Projeto do Sist.
de Informação
P2.6
Projeto da
Organização
P2 - Modelagem da Especificação de Projeto
MEP
MDR - Modelo de Definição de Requisitos
MEP - Modelo de Especificação de Projeto
MDR
Figura A.2. Modelagem da Especificação de Projeto (Zelm, 1995).
Fonte: CAMPOS R.
Uma Proposta de Modelagem para Integração de Sistemas de Gestão de
Produção em Empresas de Manufatura
, Campinas – SP, 1998.
P2.1 - CONSOLIDAÇÃO DO MDR: O Modelo de Definição de Requisitos é revisto
considerando toda a empresa e suas restrições operacionais. Por exemplo, no nível
de MDR os conjuntos de capacidade podem conter redundâncias, já que esses
foram definidos, negligenciando a potencial reutilização através de todos os
processos de domínio identificados. Os passos de modelagem P2.2 e P2.3 são
executados de modo iterativo.
127
P2.2 - PROJETO DO COMPORTAMENTO: Alternativas para o comportamento de
processos a nível de MDR, as quais levam aos mesmos resultados do processo de
domínio são avaliadas. Para as atividades de empresa o comportamento da
atividade de empresa é definido, o qual controla a execução das operações
funcionais identificadas. Tempos e prioridades são adicionadas à definição de
eventos.
P2.3 - PROJETO OPERACIONAL: Atividades de empresas são decompostas em
operações funcionais com o nível de detalhe controlado pela condição: cada
operação funcional deve ser executada por uma entidade funcional. Informações
sobre tempos de processamento para as atividade de empresa são fornecidas. Os
passos de modelagem P2.4, P2.5 e P2.7 também são realizados de modo iterativo.
P2.4 - PROJETO DO SISTEMA DE INFORMAÇÃO: As vistas de objetos identificadas nas
diferentes entradas e saídas das atividades de empresa são a base para o modelo
de informação. As vistas de objetos definidas pelos usuários são preservadas.
Partindo das vistas de objetos são derivados os esquemas de informação
(esquemas conceituais e externos). A parte de projeto da TI (Tecnologia de
Informação) as especificações de projeto são derivadas do MDR particular pelo
detalhamento e acréscimo de blocos de construção genérico.
P2.5 - PROJETO DO SISTEMA DE RECURSOS: O projeto de sistemas de recursos
considera os recursos de manufatura e de TI. Os diferentes Recursos preenchendo
as Capabilidades Requeridas são identificados e estruturados em termos de
entidades funcionais que satisfazem a lista de operações funcionais identificadas no
MDR. O projeto do sistema de recursos também inclui avaliação e definição de
alternativas de recursos, sua distribuição espacial, capacidades necessárias, a
definição de estruturas de gerenciamento de recursos (hierarquias, redes, etc.) em
termos de células lógicas e físicas.
P2.6 - PROJETO DA ORGANIZAÇÃO: As responsabilidades/autorizações operacionais
(unidades de organização) identificadas são consolidadas e as estruturas
organizacionais necessárias (hierarquias, redes, etc.) são definidas como células de
organização (departamentos, divisões, células, etc.).
128
P2.7 - VERIFICAÇÃO DE PROJETO: O Modelo de Especificação de Projeto é validado e
verificado através de simulação, usando diferentes cenários de testes representando
operações particulares da empresa.
P3 - DESCRIÇÃO DA IMPLEMENTAÇÃO
A fase de construção e liberação do sistema é relativa à implementação do
sistema da empresa. Isto envolve essencialmente a provisão de recursos
(reutilização, compra ou construção), instalação, integração e testes no ambiente de
engenharia de empresas. O MEP é atualizado em função de modificações do projeto
durante o processo de Modelagem da Descrição da Implementação (MDI). Estas
modificações são registradas no conjunto de construtores de modelagem já definidos
ao nível de Modelagem da Especificação de Projeto. Ao nível de MDI, não são
fornecidos mais construtores de modelagem de negócios, mas somente construtores
de modelagem de TI. Os subprocessos definidos para a Modelagem da Descrição
da Implementação são ilustrados pela Figura A.3.
MEP
P3.1
Provisão
de Recursos
P3.2
Atualização
do MEP
P3.4
Atualização
do MDI
P3.3
Instalação
de Recursos
P3.7
Liberação
do MDI
MDI
P3 - Modelagem da Descrição de Implementação
P3.6
Atualização
do MDI
P3.5
Verificação
de Operação
MEP - Modelo de Especificação de Projeto
MDI - Modelo de Descrição de Implementação
Figura A.3. Modelagem da Descrição de Implementação (Zelm, 1995).
Fonte: CAMPOS R.
Uma Proposta de Modelagem para Integração de Sistemas de Gestão de
Produção em Empresas de Manufatura
, Campinas – SP, 1998.
P3.1 - PROVISÃO DE RECURSOS: Seguindo o Modelo de Especificação de Projeto os
recursos disponíveis em estoque e/ou no mercado são identificados, avaliados e os
inexistentes são construídos de acordo com as especificações de projeto.
P3.2
- ATUALIZAÇÃO DO MEP: Todas as modificações das especificações dos recursos
selecionados são registradas nos construtores de modelagem (gabaritos) relativos.
O MEP torna-se então o MDI.
129
P3.3 - INSTALAÇÃO DE RECURSOS: Os recursos são instalados seguindo a
especificação de projeto em termos de localização física e interconexões logísticas.
P3.4 - ATUALIZAÇÕES DO MDI: Modificações na instalação dos recursos selecionados
durante a especificação de projeto são registrados no modelo. Também, qualquer
outra modificação do MEP é registrada.
P3.5 - VERIFICAÇÃO DA OPERAÇÃO: A operação da empresa é validada e verificada,
através de simulações de modelos, e execução da operação seguindo os diferentes
cenários identificados na especificação de projeto, e modificados de acordo com as
atualizações feitas no curso da implementação do sistema.
P3.6
- ATUALIZAÇÃO DO MDI: Todas as modificações do modelo ocorridas na fase de
verificação são registradas no MDI.
P3.7
LIBERAÇÃO DO MDI: O MDI é liberado para operação da empresa e para o uso
no controle e monitoração de funções, conforme os objetivos de projeto.
Livros Grátis
( http://www.livrosgratis.com.br )
Milhares de Livros para Download:
Baixar livros de Administração
Baixar livros de Agronomia
Baixar livros de Arquitetura
Baixar livros de Artes
Baixar livros de Astronomia
Baixar livros de Biologia Geral
Baixar livros de Ciência da Computação
Baixar livros de Ciência da Informação
Baixar livros de Ciência Política
Baixar livros de Ciências da Saúde
Baixar livros de Comunicação
Baixar livros do Conselho Nacional de Educação - CNE
Baixar livros de Defesa civil
Baixar livros de Direito
Baixar livros de Direitos humanos
Baixar livros de Economia
Baixar livros de Economia Doméstica
Baixar livros de Educação
Baixar livros de Educação - Trânsito
Baixar livros de Educação Física
Baixar livros de Engenharia Aeroespacial
Baixar livros de Farmácia
Baixar livros de Filosofia
Baixar livros de Física
Baixar livros de Geociências
Baixar livros de Geografia
Baixar livros de História
Baixar livros de Línguas
Baixar livros de Literatura
Baixar livros de Literatura de Cordel
Baixar livros de Literatura Infantil
Baixar livros de Matemática
Baixar livros de Medicina
Baixar livros de Medicina Veterinária
Baixar livros de Meio Ambiente
Baixar livros de Meteorologia
Baixar Monografias e TCC
Baixar livros Multidisciplinar
Baixar livros de Música
Baixar livros de Psicologia
Baixar livros de Química
Baixar livros de Saúde Coletiva
Baixar livros de Serviço Social
Baixar livros de Sociologia
Baixar livros de Teologia
Baixar livros de Trabalho
Baixar livros de Turismo
