MODELAGEM DE PROCESSOS E LINGUAGEM DE MODELAGEM UNIFICADA: UMA ANLISE CRTICA

Leonardo Silva Sciammarella Vicente

TESE SUBMETIDA AO CORPO DOCENTE DA COORDENAO DOS PROGRAMAS DE PS-GRADUAO DE ENGENHARIA DA UNIVERSIDADE FEDERAL DO RIO DE JANEIRO COMO PARTE DOS REQUISITOS

NECESSRIOS PARA A OBTENO DO GRAU DE MESTRE EM CINCIAS EM ENGENHARIA DE PRODUO

Aprovada por:

__________________________________________ Prof. Heitor Mansur Caulliraux, Dsc.

__________________________________________ Prof. Renato Flrido Cameira, Dsc.

__________________________________________ Prof. Eber Assis Schmitz, Dsc.

RIO DE JANEIRO, RJ BRASIL MARO DE 2004

VICENTE, LEONARDO SILVA SCIAMMARELLA Modelagem de Processos e Linguagem de Modelagem Unificada (UML) uma anlise crtica [Rio de Janeiro] 2004 XIV, 176 p. 29,7 cm (COPPE/UFRJ. M.Sc., Engenharia de Produo, 2004) Tese - Universidade Federal do Rio de Janeiro, COPPE 1. Modelagem de Processos 2. UML I. COPPE/UFRJ II. Ttulo (srie)

ii

DEDICATRIA

A todos aqueles que me ajudaram ao longo de minha vida e contriburam direta ou indiretamente na elaborao desse trabalho, destacando-se minha me, Maria Alice, meu pai, Duarte (in memorian), minhas irms, Luciana e Tatiana e meu amor, Fernanda. Amo vocs.

iii

Resumo da Tese apresentada COPPE/UFRJ como parte dos requisitos necessrios para a obteno do grau de Mestre em Cincias (M.Sc.)

MODELAGEM DE PROCESSOS E LINGUAGEM DE MODELAGEM UNIFICADA (UML): UMA ANLISE CRTICA

Leonardo Silva Sciammarella Vicente

Fevereiro/2004

Orientador: Heitor Mansur Caulliraux

Programa: Engenharia de Produo

Essa dissertao apresenta os principais conceitos relacionados Engenharia de Processos de Negcio e Linguagem de Modelagem Unificada (Unified Modeling Language UML). Tem como principal objetivo analisar as tcnicas de modelagem de processos de negcio e de sistemas e propor uma metodologia de modelagem de processos e requisitos de negcio que possa apoiar uma especificao e projeto de um sistema de negcio que integre de forma consistente os requisitos de negcio com os requisitos de sistemas.

iv

Abstract of Thesis presented to COPPE/UFRJ as a partial fulfillment of the requirements for the degree of Master of Science (M.Sc.)

PROCESS MODELING AND UNIFIED MODELING LANGUAGE (UML): A CRITICAL ANALYSIS

Leonardo Silva Sciammarella Vicente

February/2004

Advisor: Heitor Mansur Caulliraux

Department: Production Engineering

This work presents the main concepts related to the Business Process Engineering and to the Unified Modeling Language (UML). It has as main objective to analyze the techniques of systems modeling and business process modeling and to define a methodology of business processes and requirements modeling that can support a specification and project of a business system that integrates of consistent form the business requirements with the systems requirements.

SUMRIO
NDICE DE FIGURAS ............................................................................................................................. X NDICE DE TABELAS .........................................................................................................................XII LISTA DE SIGLAS.............................................................................................................................. XIII 1 INTRODUO.................................................................................................................................1 1.1 1.2 1.3 2 CONSIDERAES INICIAIS ..........................................................................................................1 JUSTIFICATIVA DO TRABALHO ...................................................................................................3 ESTRUTURA DO TRABALHO........................................................................................................4

OBJETIVOS DELIMITAES E MTODO DE TRABALHO ................................................6 2.1 2.2 2.3 2.4 OBJETIVO GERAL .......................................................................................................................6 OBJETIVOS ESPECFICOS ............................................................................................................6 DELIMITAES DO TRABALHO ...................................................................................................6 MTODO DE TRABALHO .............................................................................................................7

ENGENHARIA DE PROCESSOS DE NEGCIO .....................................................................10 3.1 3.2 3.2.1 3.2.2 3.2.3 A VISO POR PROCESSOS .........................................................................................................15 PRINCPIOS, FERRAMENTAS E METODOLOGIAS DE MODELAGEM DE PROCESSOS DE NEGCIO 20 Princpios de Modelagem ...................................................................................................21 Ferramentas de Modelagem de Processos de Negcio ......................................................22 Arquiteturas e Metodologias de Modelagem de Processos de Negcio .............................25
CIMOSA (Computer Integrated Manufacturing Open System Architecture) ......................... 26 IDEF (Integrated DEFinition) ................................................................................................. 28 ARIS (Architecture of Integrated Information Systems)......................................................... 29

3.2.3.1 3.2.3.2 3.2.3.3

3.3 3.3.1 3.3.2

CONCEITOS DE MODELAGEM DE PROCESSO DE NEGCIO E MODELOS TRADICIONAIS .............31 Conceitos de Modelagem de Processo de Negcio ............................................................31 As Vistas da Metodologia ARIS e seus Modelos.................................................................34
A Vista de Funes ................................................................................................................. 34 A Vista de Dados .................................................................................................................... 36 A Vista de Organizao........................................................................................................... 38 A Vista de Processos ............................................................................................................... 39

3.3.2.1 3.3.2.2 3.3.2.3 3.3.2.4

3.4 3.5 3.5.1 3.5.2 3.5.3 3.5.4 3.5.5

NVEL DE AGREGAO DA MODELAGEM DE PROCESSOS DE NEGCIO ....................................41 APLICAES DA EPN...............................................................................................................43 Anlises Organizacionais ...................................................................................................43 Indicadores de Desempenho...............................................................................................43 Gesto do Conhecimento....................................................................................................44 Gerncia Eletrnica de Documentos (GED) e Workflow...................................................44 Gesto da Cadeia de Suprimento .......................................................................................44

vi

3.5.6 3.5.7 3.5.8 3.5.9 3.5.10 3.5.11 3.6 3.6.1 3.6.2 3.6.3 3.6.4 3.6.5 3.6.6 3.7 4

Organizao da Documentao Tcnica............................................................................45 Benchmarking.....................................................................................................................45 Modelos de Negcios Eletrnicos ......................................................................................45 Uniformizao de entendimentos e integrao organizacional .........................................45 Implantao dos Sistemas Integrados de Gesto...........................................................45 Projetos de Sistemas de Informao..............................................................................46

GANHOS GERAIS ESPERADOS COM A EPN ...............................................................................52 Uniformizao de Entendimentos sobre a Forma de Trabalho..........................................52 Melhoria do Fluxo de Informaes ....................................................................................52 Padronizao dos Processos ..............................................................................................53 Melhoria da Gesto Organizacional ..................................................................................53 Reduo de Tempo e Custos dos Processos .......................................................................53 Aumento da Conceituao Organizacional sobre Processos .............................................53 CONSIDERAES FINAIS ..........................................................................................................53

UNIFIED MODELING LANGUAGE (UML) .............................................................................55 4.1 4.2 4.2.1 4.2.2 4.2.3 4.2.4 4.2.5 4.2.6 4.2.7 4.3 4.4 4.4.1 4.4.2 4.4.3 4.5 4.5.1 4.5.2 4.5.3 4.5.4 4.5.5 4.6 4.6.1 4.6.2 4.6.3 DEFINIO E HISTRICO DA UML ...........................................................................................55 PRINCIPAIS CONCEITOS BSICOS DA ORIENTAO A OBJETO VISO GERAL ........................57 O Paradigma da Orientao a Objeto ...............................................................................57 Objeto e Classe...................................................................................................................59 Mensagem...........................................................................................................................60 Encapsulamento .................................................................................................................60 Polimorfismo ......................................................................................................................60 Herana ..............................................................................................................................61 Acoplamento e Coeso .......................................................................................................61 OBJETIVOS DA UML ................................................................................................................62 CONCEITOS BSICOS DA UML.................................................................................................64 Blocos de Construo.........................................................................................................64 Regras da UML ..................................................................................................................66 Mecanismos da UML..........................................................................................................66 ARQUITETURA DA UML...........................................................................................................67 Vista de Caso de Uso..........................................................................................................68 Vista de Projeto ..................................................................................................................68 Vista de Processo................................................................................................................69 Vista de Implementao......................................................................................................69 Vista de Implantao ..........................................................................................................69 MODELOS DA UML - VISO GERAL.........................................................................................69 Diagramas de Casos de Uso...............................................................................................70 Diagramas de Classes ........................................................................................................72 Diagramas de Objetos ........................................................................................................76

vii

4.6.4

Diagramas de Interao.....................................................................................................76
Diagramas de Seqncia ......................................................................................................... 77 Diagramas de Colaborao...................................................................................................... 78

4.6.4.1 4.6.4.2

4.6.5 4.6.6 4.6.7

Diagramas de Grficos de Estados ....................................................................................79 Diagramas de Atividades....................................................................................................80 Diagramas de Implementao............................................................................................81

Diagramas de Componentes.................................................................................................... 82 Diagramas de Implantao ...................................................................................................... 82

4.6.7.1 4.6.7.2

4.7 4.8 5

FERRAMENTAS DE MODELAGEM DE SOFTWARE COM UML.....................................................83 CONSIDERAES FINAIS ..........................................................................................................86

EPN E UML: CONTEXTUALIZAO DA UML NA MODELAGEM DE PROCESSOS DE

NEGCIO.................................................................................................................................................87 5.1 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.2 5.2.1 5.2.2 5.2.3 5.2.4 5.3 6 MODELAGEM DE PROCESSOS DE NEGCIO COM UML: ANLISE CRTICA DOS MODELOS .......87 Modelagem de Negcio e Diagrama de Casos de Uso.......................................................88 Modelagem de Negcio e Diagramas de Atividades ..........................................................90 Modelagem de Negcio e Diagrama de Classes ................................................................92 Diagrama de Grficos de Estados......................................................................................97 Modelagem de Negcio e Diagramas de Interao ...........................................................98 EXTENSES DA UML PARA MODELAGEM DE NEGCIO ...........................................................99 Vista de Viso do Negcio................................................................................................101 Vista de Processos de Negcio .........................................................................................102 Vista de Estrutura do Negcio..........................................................................................104 Vista de Comportamento do Negcio ...............................................................................105 CONSIDERAES FINAIS ........................................................................................................106

MODELAGEM DE PROCESSO DE NEGCIO E O RATIONAL UNIFIED PROCESS

(RUP) .......................................................................................................................................................107 6.1 6.2 6.2.1 PRINCIPAIS ETAPAS PARA MODELAGEM DE PROCESSOS DE NEGCIO....................................107 PROCESSOS PRODUTIVOS DE DESENVOLVIMENTO DE SISTEMAS ............................................110 Principais Caractersticas do RUP ..................................................................................111
Processo Orientado a Casos de Uso ...................................................................................... 112 Processo Centrado na Arquitetura ......................................................................................... 112 Desenvolvimento Iterativo e Incremental.............................................................................. 113

6.2.1.1 6.2.1.2 6.2.1.3

6.2.2 6.2.3

O Ciclo de Vida de um Sistema no RUP...........................................................................117 Fases da Metodologia ......................................................................................................118

Concepo............................................................................................................................. 118 Elaborao............................................................................................................................. 120 Construo ............................................................................................................................ 122 Transio............................................................................................................................... 122

6.2.3.1 6.2.3.2 6.2.3.3 6.2.3.4

6.3

CONSIDERAES FINAIS ........................................................................................................123

viii

PROPOSTA METODOLGICA DE MODELAGEM DE PROCESSOS E REQUISITOS DE

NEGCIO PARA DESENVOLVIMENTO DE SISTEMAS.............................................................124 7.1 7.1.1 7.2 8 MODELAGEM DE NEGCIO PARA SISTEMAS PRINCIPAIS FASES A ARTEFATOS ....................124 Modelagem e Levantamento de Requisitos de Negcio....................................................128 CONSIDERAES FINAIS ........................................................................................................136

CASOS DE APLICAO DA METODOLOGIA PROPOSTA..............................................138 8.1 8.1.1 8.1.2 DESCRIO DO CASO DA EMPRESA DE TI ..............................................................................138 Componentizao e Padronizao de Processos de Negcio ..........................................139 O Caso do Produto TelVip ...............................................................................................143
Modelagem e Levantamento de Requisitos de Negcio........................................................ 144 Modelagem dos Objetivos do Negcio ............................................................................ 144 Modelagem dos Processos de Negcio ............................................................................ 144 Levantamento de Requisitos Funcionais e No Funcionais ............................................. 146 Identificao e Modelagem de Casos de Uso................................................................... 146 8.1.2.1.1 8.1.2.1.2 8.1.2.1.3 8.1.2.1.4

8.1.2.1

8.2 8.2.1

DESCRIO DO CASO DA EMPRESA DO SETOR FARMACUTICO .............................................149 Modelagem e Levantamento de Requisitos de Negcio....................................................150
Modelagem dos Objetivos do Negcio ................................................................................. 150 Modelagem dos Processos de Negcio ................................................................................. 151 Levantamento de Requisitos Funcionais e No Funcionais................................................... 153 Identificao e Modelagem de Casos de Uso ........................................................................ 155 Modelagem do Diagrama de Classes .................................................................................... 160

8.2.1.1 8.2.1.2 8.2.1.3 8.2.1.4 8.2.1.5

8.3 9

CONSIDERAES FINAIS ........................................................................................................162

CONCLUSES E PERSPECTIVAS DE DESENVOLVIMENTO .........................................163 9.1 9.2 CONCLUSES .........................................................................................................................163 PERSPECTIVAS DE DESENVOLVIMENTO ..................................................................................169

10

REFERNCIAS BIBLIOGRFICAS ........................................................................................170

ix

NDICE DE FIGURAS
FIGURA 1: VISO FUNCIONAL X VISO POR PROCESSOS ............................................................................16 FIGURA 2: INTEGRAO DA CADEIA DE SUPRIMENTOS ...............................................................................18 FIGURA 3: AS TENDNCIAS ORGANIZACIONAIS. .........................................................................................19 FIGURA 4: EVOLUO DE CONCEITOS E SISTEMAS DE INTEGRAO ............................................................20 FIGURA 5: COMPARAO DE FERRAMANETAS DE MODELAGEM DE PROCESSOS .........................................23 FIGURA 6: MTODO DE ANLISE DE ADEQUAO DAS FERRAMENTAS DE MODELAGEM A UM PROJETO ...24 FIGURA 7: O CUBO CIMOSA......................................................................................................................28 FIGURA 8: AS VISTAS E NVEIS DE IMPLEMENTAO DA METODOLOGIA ARIS............................................29 FIGURA 9: METAMODELO DE PROCESSO DE NEGCIO.................................................................................32 FIGURA 10: EXEMPLO DE DIAGRAMA DE OBJETIVOS ..................................................................................35 FIGURA 11: EXEMPLO DE DIAGRAMA DE RVORE DE FUNO ...................................................................35 FIGURA 12: MODELO DE DADOS COM CLUSTERS E ERM............................................................................37 FIGURA 13: EXEMPLO DE ORGANOGRAMA..................................................................................................38 FIGURA 14: EXEMPLO DE EPC ....................................................................................................................41 FIGURA 15: ENGENHARIA DE PROCESSOS DE NEGCIO E APLICAES .......................................................43 FIGURA 16: ARQUITETURA DE PROCESSOS DE NEGCIO COM DESDOBRAMENTO PARA SISTEMAS DE INFORMAO.....................................................................................................................................46 FIGURA 17: PROJETO DE SISTEMAS COM ENGENHARIA SIMULTNEA .........................................................49 FIGURA 18: COMPONENTES DE PROCESSOS E DE SISTEMAS ........................................................................51 FIGURA 19 ARQUITETURA DE UM SISTEMA .................................................................................................68 FIGURA 20 DIAGRAMAS DA UML ............................................................................................................70 FIGURA 21: DIAGRAMAS DE CASOS DE USO ................................................................................................72 FIGURA 22: NOTAO DE UMA CLASSE .......................................................................................................73 FIGURA 23: DIAGRAMA DE CLASSES ...........................................................................................................75 FIGURA 24: DIAGRAMA DE OBJETOS ...........................................................................................................76 FIGURA 25: DIAGRAMA DE SEQNCIA.......................................................................................................78 FIGURA 26: DIAGRAMA DE COLABORAO ................................................................................................79 FIGURA 27: DIAGRAMA DE GRFICO DE ESTADOS ......................................................................................80 FIGURA 28: DIAGRAMA DE ATIVIDADES .....................................................................................................81 FIGURA 29: DIAGRAMA DE COMPONENTES .................................................................................................82 FIGURA 30: DIAGRAMA DE IMPLANTAO ..................................................................................................83 FIGURA 31: COMPARAO DAS FERRAMENTAS DE MODELAGEM DE SOFTWARE ........................................84 FIGURA 32: EXEMPLO DE CASO DE USO DE NEGCIO ...................................................................................89 FIGURA 33: NVEIS DE DETALHAMENTO ENTRE CASOS DE USO E EPC.........................................................90 FIGURA 34: RELAO ENTRE EPC E DIAGRAMA DE ATIVIDADES ...............................................................92 FIGURA 35: ESTRUTURA DO OEPC..............................................................................................................94 FIGURA 36: EPC DE ALTO NVEL COM PACOTES ..........................................................................................95

FIGURA 37: DIAGRAMA DE CLASSES AGRUPADO NUM PACOTE ...................................................................95 FIGURA 38: EPC DE NVEL INTERMEDIRIO COM CLASSE............................................................................96 FIGURA 39: EPC CAPTURAR REQUISITOS DETALHADO COM ATRIBUTOS E OPERAES ..............................96 FIGURA 40: COMPARAO ENTRE EPC E DIAGRAMA DE ESTADOS .............................................................97 FIGURA 41: DIAGRAMA DE ATIVIDADES E ESTERETIPOS DE PROCESSOS DE NEGCIO .............................101 FIGURA 42: DIAGRAMA DE OBJETIVOS E PROBLEMAS ..............................................................................102 FIGURA 43: DIAGRAMA DE PROCESSOS .....................................................................................................103 FIGURA 44: DIAGRAMA DE LINHA DE MONTAGEM ...................................................................................104 FIGURA 45: DIAGRAMA ORGANIZACIONAL ...............................................................................................105 FIGURA 46: PROCESSO DE MODELAGEM DE NEGCIO...............................................................................108 FIGURA 47: PROCESSO DE MODELAGEM DE NEGCIO COM DESDOBRAMENTO PARA SISTEMAS ...............109 FIGURA 48: MODELO CASCATA DE DESENVOLVIMENTO DE SOFTWARE ...................................................114 FIGURA 49: UM PROCESSO ITERATIVO E INCREMENTAL ...........................................................................115 FIGURA 50: ABORDAGEM ITERATIVA E INCREMENTAL .............................................................................115 FIGURA 51: ESTRUTURA DO RUP..............................................................................................................117 FIGURA 52: DIAGRAMA DE PROCESSOS MOSTRANDO A RELAO ENTRE PROCESSOS DE NEGCIO E SISTEMAS FONTE: ADAPTADA DE ERIKSSON E PENKER (1999) .................................................125 FIGURA 53: ANLISE COMPARADA ENTRE ETAPAS DE MODELAGEM DE PROCESSOS DE NEGCIO E DE DESENVOLVIMENTO DE SISTEMAS ...................................................................................................127 FIGURA 54: FLUXO DE MODELAGEM E LEVANTAMENTO DE REQUISITOS DE NEGCIO .............................129 FIGURA 55: DERIVAO DE CASOS DE USO A PARTIR DE PROCESSOS DE NEGCIO ....................................131 FIGURA 56: ELABORAO DE UMA ESPECIFICAO DE PROCESSOS E REQUISITOS DE NEGCIO. .....143 FIGURA 57: PARTE DO PROCESSO DE ATIVAO DO TELVIP.....................................................................146 FIGURA 58: PARTE DO DIAGRAMA DE CASOS DE USO DO PRODUTO TELVIP...............................................147 FIGURA 59: DIAGRAMA DE OBJETIVOS DO PROCESSO DE MANUTENO ..................................................150 FIGURA 60: PROCESSO DE MANUTENO .................................................................................................152 FIGURA 61: FAD ALOCAR MO-DE-OBRA.................................................................................................153 FIGURA 62: DIAGRAMA DE CASOS DE USO PARA ELABORAO DO SISCOM. ...........................................157 FIGURA 63: ATIVIDADE ALOCAR MO-DE-OBRA E CLASSES ASSOCIADAS ...........................................160 FIGURA 64: DIAGRAMA DE CLASSES
PARA ELABORAO DO SISCOM....................................................161

xi

NDICE DE TABELAS
TABELA 1 - COMPARAO: ORGANIZAO FUNCIONAL VS ORIENTADA POR PROCESSOS ...................16 TABELA 2: MODELO FURPS DE CLASSIFICAO DE REQUISITOS ..............................................................120 TABELA 3: FASES E ARTEFATOS DA METODOLOGIA PROPOSTA ................................................................134 TABELA 4: COMPARAO ENTRE O EPC X CASOS DE USO X DIAGRAMA DE CLASSE..........................136 TABELA 5: LISTA DE ATIVIDADES E EXECUTORES CANDIDATOS A CASOS DE USO E ATORES ......................156 TABELA 6: PROCESSO DE MANUTENO (EPC X CASOS DE USO X DIAGRAMA DE CLASSES).............159

xii

LISTA DE SIGLAS AIS - Arquitetura Integrada de Sistemas ARIS - Arquitecture of integrated Information System BPM - Business Process Management BPMS - Business Process Management System B2B - Business to Business B2C - Business to Customer CASE - Computer Aided Software Enginneering CBD - Component-Based Development CIM - Computer Integrated Manufacturing CIMOSA - Computer Integrated Manufacturing Open System Architecture COM - Component Object Model CORBA - Common Object Request Broker Architecture CRM - Customer Relationship Management EAI Enterprise Application Integration EJB - Entreprise Java Beans EPC Event-Driven Process Chain EPN - Engenharia de Processos de Negcios ERP - Enterprise Resources Planning ES - Engenharia de Software FAD - Function Allocation Diagram GED - Gerncia Eletrnica de Documentos IDEF - Integrated DEFinition KM - Knowledge Management MER - Modelo de Entidades e Relacionamentos OE Order Entry oEPC - object-Oriented Event-Driven Process Chain OMG - Object Management Group OMT - Object Modeling Technique OOSE - Object-Oriented Software Enginneering OT - Ordens de Trabalho OSTN - Object State Transition Network xiii

PCP Planejamento e Controle da Produo PPM - Process Performance Management RUP - Rational Unified Process SA Sistema de Aprovisionamento SIG - Sistemas Integrados de Gesto SISCOM - Sistema de Controle e Manuteno SCM - Supply Chain Management TI - Tecnologia da Informao UML - Unifed Modeling Language VAC - Value Added Chain

xiv

INTRODUO

1.1

Consideraes Iniciais
As constantes e crescentes transformaes no mundo dos negcios esto

tornando o mercado cada vez mais competitivo e esto levando as organizaes a repensarem suas estratgias de atuao dentro de seus respectivos nichos, tendo que se adaptarem, quase que em tempo real, s mudanas do ambiente no qual esto inseridas. Tais mudanas podem ser observadas no dia a dia atravs dos jornais impressos ou online, atravs dos telejornais, das revistas e dos livros especializados em negcios que permitem a observao de fatores e tendncias do mercado que norteiam as tomadas de decises das organizaes. Segundo DAVENPORT (2000), tais fatores e tendncias incluem a globalizao, o surgimento de modelos de negcio com rpida percepo e resposta s necessidades do cliente, a necessidade do realinhamento horizontal corporativo para suportar com maior eficincia os processos de transaes internos e externos empresa, o crescimento das organizaes virtuais que esto diretamente relacionadas ao comrcio eletrnico e a formao de cadeias de valores e, por fim, a acelerao do processo de inovao e criao de novos produtos. Diante desse contexto, como pode ser observado por SANTOS (2002), as organizaes esto demandando a todo o momento mais dinmica, integrao, flexibilidade e inovao para se manterem competitivas, buscando alcanar seus objetivos estratgicos atravs da reduo de custos e do tempo de atendimento ao cliente, atravs do aumento da taxa de inovao com a conseqente reduo no tempo de desenvolvimento de novos produtos, atravs de parcerias com outras organizaes, entre outras aes que podem contribuir para a sustentao da competitividade no longo prazo. A constatao desse ambiente pode ser observado em diversas obras de diversos autores. PROENA (1999) faz uma abordagem dinmica no que se refere s estratgias organizacionais frente s mudanas ambientais. O autor coloca que para se construir uma vantagem competitiva desejvel por um longo prazo importante analisar a estratgia de forma dinmica e no sob uma perspectiva esttica e pontual de um determinado momento. 1

GALBRAITH (apud SANTOS, 2002) considera que diante da complexidade do ambiente de negcios, a dinmica das organizaes um elemento fundamental para justificar projetos organizacionais mais aderentes. VERNADAT (1996), por exemplo, ressalta as mudanas e tendncias do ambiente de atuao das organizaes como: a integrao de mercados com a formao dos blocos econmicos com reas de livre comrcio, a integrao da funo manufatura com projeto, centros de desenvolvimento e fornecedores e, por fim, a integrao dos componentes de hardware e software de diversos fornecedores. Este mesmo autor tambm ressalta, diante de solues cada vez mais modernas e baseadas na Tecnologia da Informao (TI), a importncia e a necessidade das organizaes apresentarem flexibilidade tanto a nvel gerencial com a reorganizao dos processos de negcios e estruturas organizacionais, quanto a nvel tcnico com a capacidade de modificar rapidamente as tecnologias e as caractersticas de projeto que compem o produto oferecido, em funo das tendncias do mercado e das customizaes para clientes. Tambm pode-se observar em CAMEIRA (2003) o conceito de hiper-integrao desenvolvido e sustentado pelos quadros conceituais: Engenharia de Processos, Tecnologia da Informao (TI) e Modelos de Negcio Tecnologicamente Habilitados. O autor define hiper-integrao como:

... o resultado de um movimento no apenas quantitativo, incremental, conseqncia da TI, com do sua uso acumulativo, de

capacidade

armazenamento e processamento de informaes, de automao e de comunicao, mas tambm qualitativo. Em certos nveis de acmulo, de integrao, este movimento provoca mudanas do contexto no qual a TI aplicada, modificando o ambiente de forma no apenas incremental. (CAMEIRA, 2003, p.1).

Este mesmo autor destaca a relao do conceito de hiper-integrao com a DIFI, relacionando a integrao ao desenvolvimento de sistemas, a dinmica ao menor tempo de resposta as mudanas do ambiente, a flexibilidade a rpida reconfigurao do fluxo

de informaes suportado pelos processos hiper-integrados e por uma Arquitetura Integrada de Sistemas (AIS) baseada em componentes e em agentes inteligentes e, por fim, a inovao como conseqncia da hiper-integrao dos processos, da capacidade de dinamicidade de resposta ao ambiente e da flexibilidade de redesenho. Todas essas mudanas no ambiente de negcio e as aes que as organizaes esto tomando para se adaptarem as diversas configuraes de cenrios a que esto expostas em seus cotidianos, so suportadas por diversos fatores de ordem poltica, econmica, social, cultural, financeira, tecnolgica, entre outros. Esta tese no se prope a analisar todos esses fatores, considerando, principalmente, dentre os citados acima, o fator tecnolgico como habilitador das transformaes na maneira de se fazer negcios. Dentro dos fatores tecnolgicos que motivam tais transformaes, pode-se citar a Tecnologia da Informao que tem sido referenciada em diversas obras de diversos autores como, por exemplo, DAVENPORT (1994, 2000) e HAMMER e CHAMPY (1994) que atribuem a TI um papel fundamental para se realizar a reengenharia de processos. Como conseqncia da evoluo da TI, surge a Internet que passa a ser encarada como um grande meio de comunicao que possibilita o aumento do fluxo de informaes e a integrao virtual intra e interorganizacional, os quais so desenvolvidos novos softwares e hardwares com capacidade de armazenamento de dados e processamento de informaes cada vez maior, novos meios e tecnologias de transmisso em telecomunicaes que, por exemplo, possibilitam, atravs da banda larga, uma maior vazo de dados, voz e imagem e surgem sistemas de informao que buscam a no replicao de dados e a integrao organizacional, entre outros fatores que fazem da TI um pr-requisito fundamental para a subsistncia das organizaes. Nesse contexto, fica difcil considerar um negcio sem a presena da TI que deve ser pensada de maneira sistmica com os processos de uma organizao (CAMEIRA, 2003).

1.2

Justificativa do Trabalho
Diante do cenrio abordado acima, destaca-se a relevncia da TI e mais,

precisamente, do desenvolvimento de sistemas de informao que possibilitem, atravs do fluxo de informaes horizontal, a integrao funcional de uma organizao suportada pelos seus processos de negcio. Essa sinergia entre sistemas de informao e

processos de negcio deve existir com um dos principais objetivos para realizar de forma eficiente a estratgia de uma organizao. Porm, a realizao da estratgia desejada atravs do uso da TI e processos de negcio no uma tarefa fcil e direta. Muitas empresas apresentam dificuldades para desenvolverem processos de negcios e sistemas com qualidade e em tempo hbil para se manterem competitivas no mercado. Diante da necessidade de dinmica, integrao, flexibilidade e inovao, as empresas esto buscando novas tecnologias, conceitos e tcnicas de modelagem de processos e de sistemas que possam contemplar essa necessidade. Assim, algumas tecnologias, metodologias e conceitos sero tratados neste trabalho com o intuito de esclarecer e facilitar a converso da estratgia desejada em processos de negcio e, adiante em sistemas de informao. Dessa forma, o trabalho tem como base um referencial terico que leva em considerao a Engenharia de Processos de Negcios (EPN) e sua relao com o desenvolvimento de sistemas de informao, bem como a Unifed Modeling Language (UML) enquanto uma linguagem padro para elaborao de estrutura de projetos de software (JACOBSON et al., 2000).

1.3

Estrutura do Trabalho
Esse tpico tem como principal objetivo descrever a estrutura do trabalho

mostrando, de forma breve, os contedos dos captulos envolvidos nessa dissertao. No captulo 2 ser mostrado o mtodo de trabalho utilizado, ou seja, a maneira como a pesquisa foi conduzida, quais so as delimitaes a que se restringe o trabalho e quais so os objetivos principais e especficos do mesmo. No captulo 3, a dissertao apresenta um breve quadro conceitual sobre Engenharia de Processos de Negcio (EPN) ressaltando alguns princpios, metodologias e ferramentas de modelagem de processo, alguns de seus ganhos e algumas de suas aplicaes como, por exemplo, o desenvolvimento de sistemas de informao. O captulo 4 busca apresentar as principais caractersticas e objetivos da UML, dando destaque para os tipos de modelos que a compem e qual o papel de cada modelo dentro da lgica de um processo de desenvolvimento de software. Essa compreenso do papel de cada modelo ajuda a entender como os requisitos e os processos de negcio podem ser levantados, analisados e implantados pela UML.

O captulo 5 tem como objetivo relacionar os dois captulos anteriores, buscando comparar os modelos de processos com os modelos da UML, mostrando as principais vantagens e desvantagens de se utilizar a UML para modelagem de processos de negcio. Alm disso, mostra tambm uma proposta de extenso da UML para modelagem de processos de negcio. O captulo 6 apresenta conceitos referentes a metodologias de modelagem de processos de negcio para desenvolvimento de sistemas e tambm apresenta uma metodologia de desenvolvimento de software denominado de Rational Unified Process (RUP). O captulo 7 tem como objetivo elaborar uma metodologia de modelagem de processos orientada para desenvolvimento de sistemas que mostra, atravs dos modelos de processos e dos modelos da UML, a transio de requisitos de negcio para a anlise e desenvolvimento de sistemas. A idia dessa metodologia tentar estabelecer um elo entre os processos de negcio e a anlise / levantamento de requisitos de negcio para desenvolvimento de sistemas O captulo 8 apresenta a aplicao de metodologia proposta atravs da utilizao de casos levantados a partir de dados reais. O captulo 9 apresenta as concluses finais do trabalho mostrando seus principais resultados e perspectivas para desdobramentos de trabalhos futuros. Por fim, o captulo 10 apresenta as referncias bibliogrficas utilizadas na elaborao do trabalho.

OBJETIVOS DELIMITAES E MTODO DE TRABALHO

Este captulo tem como principal finalidade definir os principais objetivos da tese, suas delimitaes e, por fim, o mtodo de trabalho adotado durante a pesquisa.

2.1

Objetivo Geral
Este trabalho tem como objetivo desenvolver uma proposta de metodologia de

modelagem de processos e requisitos de negcio orientada para desenvolvimento de sistemas de negcio com base em dois quadros conceituais envolvendo a Engenharia de Processos de Negcio (EPN) e a Unified Modeling Language (UML) e seus modelos, alm dos processos de desenvolvimento de software.

2.2

Objetivos Especficos
Esse trabalho apresenta alguns objetivos especficos que daro suporte para a

realizao do objetivo geral colocado acima, a saber: Apresentar um breve quadro conceitual referente Engenharia de Processos de Negcio, abordando suas principais aplicaes, metodologias e arquiteturas de referncia para modelagem de processos; Apresentar um quadro conceitual referente UML e seus modelos, mostrando de que maneira a UML pode contribuir para a formulao de uma metodologia de modelagem de processos voltada para sistemas; Analisar e relacionar os modelos tradicionais da EPN com os modelos da UML, mostrando o papel deles dentro da metodologia de modelagem de processos;

2.3

Delimitaes do Trabalho
O presente trabalho tem seu framework conceitual na relao entre a Engenharia

de Processos de Negcio e a Engenharia de Software. Portanto, importante colocar as delimitaes inerentes a cada rea com o intuito de focar a tese para a realizao de seus objetivos.

Com relao Engenharia de Processos de Negcio, importante ressaltar que nem todos os conceitos abordados por ela sero aprofundados na dissertao. Dentro do contexto proposto para o trabalho, no sero detalhados, por exemplo, desdobramentos da EPN como a Gesto do Relacionamento com o Cliente, a Gesto do Conhecimento, Gesto da Cadeia de Suprimentos, Re-projeto Organizacional, Gesto de Indicadores de Desempenho, Workflow e GED e Implantao de Sistemas Integrados de Gesto. A nfase ser dada ao desdobramento referente ao Projeto de Sistemas de Informao. No que tange Engenharia de Software, vale ressaltar que no ser analisado nenhum tipo de linguagem de programao de desenvolvimento de software, nem as ferramentas que suportam a modelagem orientada a objeto. Alm disso, no se pretende detalhar os tipos metodologias orientadas a objeto, interessando a este texto o entendimento de que forma essas tecnologias podem contribuir para uma metodologia de modelagem de processos orientada para sistemas. As delimitaes citadas acima visam tornar factvel o desenvolvimento da dissertao bem como suas concluses, pois, ajudam a afunilar o escopo da mesma.

2.4

Mtodo de Trabalho
Esse tpico tem como principal objetivo descrever o tipo de pesquisa utilizada

para elaborar essa dissertao, justificando sua escolha e apresentando suas principais caractersticas de natureza, forma, objetivos e procedimentos tcnico utilizados, alm de mostrar as principais etapas realizadas durante a pesquisa. Conforme pode ser observado em YIN (2001, p. 19), toda estratgia de pesquisa apresenta vantagens e desvantagens, dependendo do tipo de questo da pesquisa, do controle que o pesquisador tem sobre os eventos comportamentais efetivos e do foco em fenmenos histricos, em oposio a fenmenos contemporneos. Analisando as caractersticas dos diferentes tipos de pesquisa e considerando as principais questes que se pretende investigar, foi possvel concluir que quanto a sua natureza, a pesquisa pode ser classificada como aplicada e com relao abordagem do problema em anlise, a pesquisa pode se caracterizar como qualitativa, pois, considera que nem tudo pode ser quantificvel e traduzido em nmeros e que existe uma relao subjetiva e dinmica entre o mundo real e o objeto de estudo, onde o pesquisador tende a analisar seus dados intuitivamente. Alm disso, a pesquisa realizada buscou uma 7

melhor compreenso do foco abordado pela tese, podendo ser classificada, de acordo com as classificaes propostas por GIL (1991), como sendo exploratria com relao aos seus objetivos, pois, visa proporcionar maior familiaridade com o problema com vistas a torn-lo explcito, envolve levantamento bibliogrfico, entrevistas com pessoas que tiveram experincias prticas com o problema pesquisado e anlise de casos que estimulem a compreenso. Alm disso, com relao aos procedimentos tcnicos usados na dissertao, a pesquisa pode ser classificada como sendo do tipo estudo de caso e no participante, pois apesar de ter existido algum grau de interao com as equipes de indivduos que faziam parte dos casos, o autor no participou ativamente destes fenmenos, no tomando parte ou exercendo influncia sobre o comportamento dos fenmenos estudados. Como estratgia de pesquisa, o estudo de caso pode ser definido como uma pesquisa emprica que investiga um fenmeno contemporneo dentro de um contexto da vida real, quando as fronteiras entre o fenmeno e o contexto no so muito evidentes, e que mltiplas fontes de evidncia so usadas. Isto particularmente valioso para responder questes do tipo quem, porque e como dentro da gesto da pesquisa. YIN (2001). Os casos apresentados na dissertao proporcionaram a contextualizao real da aplicao experimental da metodologia de modelagem de processos e requisitos de negcio orientado para desenvolvimento de sistemas de negcio. Porm, importante ressaltar que durante a pesquisa e o desenvolvimento dos casos, algumas evidncias levantadas apontavam para a reformulao de algumas questes iniciais e o surgimento de novas questes. Esta reformulao nas questes relevantes levou o autor redefinir o projeto de pesquisa, tendo que por algumas vezes retornar e reavaliar as evidncias bibliogrficas e prticas levantadas no que se refere ao tipo e relevncia dos dados a serem levantados e a forma de anlise dos mesmos (YIN, 2001, p. 65). A partir das classificaes citadas acima, a metodologia de pesquisa adotada foi realizada nas seguintes etapas (REMENYI et al., 1998):

1. Estudo da bibliografia com a utilizao de livros e artigos referentes ao tema abordado na tese. Buscou-se com esse estudo subsdios e bases tericas para realizar uma pesquisa que agregue valor ao trabalho, procurando transferir o 8

conhecimento contido no estado-da-arte para o estudo de caso contemplado na tese. Alm disso, o estudo bibliogrfico ajudar a guiar e se necessrio ajustar o tema proposto;

2. Levantamento de dados ou evidncias, atravs de estudo de casos em organizaes, por intermdio da documentao da organizao e de entrevistas com seus profissionais, da metodologia de modelagem de processos de negcio e levantamento de requisitos para construo de sistemas corporativos da empresa e demais dados relevantes para uma melhor descrio dos problemas enfrentados dentro do escopo abordado;

3. Fazer a anlise dos dados coletados buscando uma melhor compreenso dos problemas contidos dentro do tema proposto. Para tornar essa anlise consistente foi utilizado como base todo o leque bibliogrfico explorado durante a pesquisa e as evidncias levantadas nos casos;

4. Redao e elaborao da documentao final, apresentando o problema tratado, as concluses oriundas dos conhecimentos adquiridos com o estado-da-arte e daqueles adquiridos com os casos, os resultados obtidos, as contribuies realizadas e propostas de pesquisas futuras.

O prximo captulo inicia o desenvolvimento da dissertao com uma reviso literria do tpico Engenharia de Processos de Negcios (EPN), mostrando suas principais caractersticas e seus desdobramentos como, por exemplo, o desenvolvimento de sistemas de informao.

ENGENHARIA DE PROCESSOS DE NEGCIO

Segundo SANTOS (2002, p.1), a Engenharia de Processos de Negcio (EPN) pode ser definida como ... uma arquitetura (framework) para entendimento, anlise e melhoria dos processos dentro e entre organizaes.... Em CAMEIRA e CAULLIRAUX (2000) pode-se encontrar a seguinte definio de EPN:

...a EPN uma tcnica muito utilizada quando se deseja entender ou mapear como uma parte de uma organizao, uma organizao ou, at, um conjunto de organizaes (uma cadeia de suprimento, por exemplo) opera, como so realizados os processos, como a informao flui atravs desses processos, suas

interfaces, quais os recursos so utilizados, quem realiza as diversas atividades, etc., permitindo entender as cadeias de valor existentes..

Dentro da Engenharia de Produo, diversos so os quadros conceituais abordados por muitos autores que esto relacionados com a EPN como, por exemplo, a Reengenharia (DAVENPORT, 1994; HAMMER, CHAMPY, 1994) que para muitos, apesar de ter sido mal aplicada em muitas empresas, foi, no incio da dcada de 90, a grande responsvel pela difuso da viso orientada a processos, ainda podem ser citados quadros como o Controle de Qualidade Total (FALCONI, 1996), Sistema Toyota de Produo (SHINGO, 1996a, 1996b; SHINGO, 2000), Teoria das Restries (STEIN, 1996), etc. Independente do quadro conceitual abordado, a EPN tem como um dos seus principais objetivos o mapeamento dos processos de negcio que envolve parte ou a totalidade dos relacionamentos de uma ou mais organizaes com o intuito de compreender as inter-relaes existentes entre os objetos envolvidos com o(s) processo (s) de negcio em questo.

10

Existem diversos conceitos atrelados definio de processo de negcio. Para entender melhor esses conceitos, importante citar algumas das definies de processo de negcio encontradas na literatura, a saber:

Um processo um grupo de atividades realizadas numa seqncia lgica, com o objetivo de produzir um bem ou um servio que tem valor para um grupo especfico de clientes. (HAMMER e CHAMPY, 1994)

Um processo uma ordem especfica de atividades de trabalho que so realizadas atravs do tempo com um lugar definido, com incio e fim, e com inputs e outputs claramente identificados. (DAVENPORT, 1993)

Uma cooperao de atividades distintas para a realizao de um objetivo global, orientado para o cliente final que lhes comum. Um processo repetido de maneira recorrente dentro da empresa. A um processo correspondem: Um desempenho

(performance), que formaliza o seu objetivo global (um nvel de qualidade, um prazo de entrega etc.); Uma organizao que materializa e estrutura

transversalmente a interdependncia das atividades do processo, durante sua durao; Uma co-

responsabilidade dos atores nesta organizao, com relao ao desempenho global; Uma responsabilidade local de cada grupo de atores ao nvel de sua prpria atividade. (ZARIFIAN apud SALERNO, 1999, p.105)

Segundo SALERNO (1999, p.104), as caractersticas de um processo seriam:

Uma organizao estruturada, modelada em termos e trocas entre as

11

atividades constitutivas. Esta organizao se constitui pela ligao ao cliente final;

Entradas tangveis (produtos, faturas, pedidos, etc.) ou intangveis (deciso de lanar novo produto, demanda de investimentos, etc.);

Sadas: o resultado do processo. um ponto de partida para a construo da organizao;

Recursos: no o somatrio de recursos locais, mas a utilizao racional dos recursos que so, ao mesmo tempo, necessrios e teis ao processo. possvel que alguns recursos fiquem dedicados a um processo, mas outros no, podendo ter um uso variado;

Custo dos recursos globais, valorizados, do o custo de um processo;

Um desempenho global, medido por alguns (poucos) indicadores, deve ser explicitado em desempenhos locais para cada atividade. Esses indicadores seriam a nica referncia de avaliao sobre o resultado do processo, o nico critrio de coresponsabilidade entre os atores;

Fatores de desempenho ligados aos pontos crticos: so pontos privilegiados de reflexo sobre a gesto econmica do processo e sobre os principais instrumentos de ao. Pontos crticos podem ser atividade ou coordenaes;

Um desenrolar temporal, dado que um evento detona o processo (ex.: chegada de um pedido) e outro o fecha (entrega). O processo se desenrola segundo uma temporalidade organizvel e mensurvel.

processos podem ser melhor entendidos se percebidos como uma estruturao-coordenao-disposio lgicotemporal de aes e recursos com o objetivo de gerar um ou mais produto(s)/servio(s) para os clientes da organizao. Os processos esto intrinsecamente

12

relacionados aos fluxos de objetos na organizao. Os processos podem estar em diferentes nveis de abstrao ou detalhamento, relacionado a atividade finalsticas ou de apoio, possurem um responsvel por seu

desempenho global e responsveis locais direcionados ao andamento de suas partes-constituintes e,

comumente, serem transversais a forma atravs da qual a organizao se estruturou (por funo, por produto, por eixo geogrfico etc.). Aos processos cabe o desenvolvimento ou desenrolar dos fluxos de objetos enquanto s funes ou unidade organizacionais cabe a concentrao de conhecimentos por semelhana, dentro das organizaes. Os processos so a organizao em movimento, so, tambm, uma estruturao para ao para a gerao de valor (SANTOS, 2002, p.40).

SANTOS et al (2002) analisa que diante da necessidade de se mapear processos para uma melhor compreenso da organizao como um todo, a EPN tem por base modelos de processos, cujas finalidades bsicas so: representao, anlise e melhoria da forma que o trabalho realizado nas organizaes, horizontalmente, orientado para produtos, clientes e mercados. Com os modelos de processos de negcios mapeados possvel realizar anlises e, por conseqncia, melhorias dos processos em questo, almejando, por exemplo, uma normalizao e certificao da qualidade atravs das sries ISO, reduo de custos e do lead-time de produo, simulaes computacionais de diversos cenrios, seleo e desenvolvimento de sistemas integrados de gesto orientado a processos, entre outras. VERNADAT (1996) coloca que os principais objetivos da modelagem de processos so: Uniformizao do entendimento da forma de trabalho, gerando integrao; Anlise e melhoria do fluxo de informaes; Explicitao do conhecimento sobre os processos, armazenando, assim, o know how organizacional; Realizao de anlises organizacionais e de indicadores (processos, financeiros e outros); 13

Realizao de simulaes, apoiando tomada de decises; Gesto da organizao.

SANTOS (2002) citou os principais resultados da aplicao da EPN nas organizaes podem ser citados os seguintes (SANTOS, 2002):

Uniformizao de entendimentos sobre a forma de trabalho atravs da difuso da viso por processos, suportada ferramentas e modelos que permitem a visualizao do trabalho executado pelas unidades organizacionais, possvel se criar uma viso holstica e homognea do negcio por parte de todos os envolvidos em uma organizao ou at mesmo em um conjunto de organizaes;

Melhoria do fluxo de informaes atravs da modelagem de processos possvel identificar as informaes de entrada e sada necessrias para a execuo das atividades que estabelecem interfaces entre unidades organizacionais de uma mesma empresa ou de empresas diferentes. Destaca-se o papel da TI com a utilizao de sistemas de informao como, por exemplo, os sistemas de workflow que apiam a automatizao dos processos e do fluxo de informao;

Padronizao dos processos - importante se definir padres na forma como as pessoas esto modelando os processos, pois, isso facilita sobremaneira a legibilidade e a homogeneidade dos modelos trabalhados, facilitando a uniformizao do entendimento sobre a forma de trabalho. Nesse sentido, importante definir uma ferramenta de modelagem, os modelos que sero utilizados, os objetos dos modelos que sero utilizados, como estes objetos estaro dispostos no modelo, entre outros aspectos que ajudam a formular um referencial de conformidade. Cabe ressaltar que importante o envolvimento de pessoas que possam garantir a consistncia da padronizao entre os diversos modelos trabalhados por diversas pessoas de vrias reas de uma organizao;

Melhoria da gesto organizacional relacionando-se os processos modelados aos indicadores de desempenho de uma organizao, possvel melhorar a gesto

14

organizacional atravs de prticas de monitorao, avaliao, controle, etc.;

Aumento da conceituao organizacional sobre processos como conseqncia da aplicao de mtodos e prticas relacionadas EPN, as organizaes passam a aplicar prticas baseadas em processos, gerando o desenvolvimento e o aprimoramento organizacional; e

Reduo de tempo e custos dos processos com a modelagem das operaes, recursos e mtricas envolvidas nos processos, torna-se possvel identificar as melhorias diretamente ligadas a maior eficincia organizacional com a reduo de tempo e custos.

3.1

A Viso por Processos

Conforme foi possvel observar acima, a EPN fundamenta-se na viso por

processos e na modelagem dos processos de negcio para retratar parte das variveis que compem um determinado ambiente de negcio real, substituindo ou no mnimo complementando a viso funcional vigente, at o momento, em boa parte das organizaes presente no mercado de trabalho. No que tange a viso funcional, como pode ser observadas em ANTUNES, JR., CAULLIRAUX e NEVES (1998), esta pode gerar distores de percepo. Como exemplo, pode-se tomar como base uma compra em grande quantidade de um determinado produto, reduzindo o custo por unidade adquirida, o que gera um indicador positivo para a rea de compras. Porm, devido falta de viso processual, essa grande quantidade de produto pode gerar um aumento do custo de estocagem que venha a invalidar o ganho proporcionado pela rea de compras. De uma maneira geral, a viso por processos busca a integrao dos timos locais para atingir os timos globais. Na figura e na tabela abaixo podem ser visualizados os contrastes entre a lgica processual e funcional:

15

Organizao

Processos
Processo 1

Funo A

Funo B

Funo C

Produtos

Processo 2

M ercado

Atividades ou Operaes
Figura 1: Viso Funcional X Viso por Processos Fonte: RUMMLER e BRACHE (1994) apud Antunes, Jr., Caulliraux, Neves (1998)

Tabela 1 - Comparao: Organizao Funcional vs Orientada por Processos

Organizao Funcional

Organizao por Processos

Consumidor como uma varivel criadora Objetivos ajustados pelos consumidores de distrbio Estruturas organizacionais rgidas Foco no projeto organizacional Estruturas organizacionais flexveis Foco no projeto do comportamento Controle flexvel do processo por gerentes

Controle do Processo por gerentes de de fluxo de trabalhos (Workflow) coordenao

Fonte: KELLER, TEUFEL (1998), apud SANTOS (2002, p. 27)

CAMEIRA e CAULLIRAUX (2000) colocam como principais caractersticas da viso por processos, a possibilidade de se realizar uma anlise das funes de uma organizao a partir de uma seqncia lgica e temporal das atividades mapeadas, o foco dado em clientes iniciais e finais (clientes, preferencialmente, externos as organizaes), a articulao de diversos objetos que compem os processos (dados, recursos, unidades organizacionais, etc.), uma classificao consistente

metodologicamente dos objetos e uma hierarquia entre os modelos e, por fim, a possibilidade de navegao pelos processos em qualquer direo seja das atividades aos

16

macro-processos (abordagem botton up) ou dos macro-processos para as atividades (abordagem top down). Estes mesmos autores tambm relacionam a viso por processos TI enquanto habilitadora da integrao do fluxo de informaes que proporciona o encadeamento e o link das atividades realizadas pelas diversas reas de uma empresa, facilitando as quebras das barreiras funcionais. A Tecnologia da Informao, por natureza, influencia de maneira drstica o comportamento da sociedade como um todo, alterando a vida das pessoas e das diversas organizaes das quais elas fazem parte. Independente do porte, do mercado e da sua cultura organizacional, importante que uma organizao considere em seus planejamentos o uso eficaz e eficiente da TI. Dessa forma, a TI tem um papel importantssimo dentro dos processos empresariais, influenciando de maneira significativa na execuo e gesto do trabalho. Na realizao do trabalho, a TI proporciona desde mudanas na forma individual de trabalhar at a forma pela qual as organizaes se relacionam em processos interorganizacionais. de extrema importncia que as empresas procurem entender a lgica da forma como seus resultados so obtidos e ajustar as atividades e a tecnologia empregada de modo a otimizar o emprego dos recursos e a eficincia geral dos processos. Para entender essa lgica de funcionamento necessrio um estudo do trabalho para analisar a maneira pela qual ele realizado e quais so os recursos envolvidos na execuo do mesmo. Alm disso, vale ressaltar que a TI se aplicada em processos problemticos, pode no representar ganho de eficincia, aumentando apenas a velocidade com os quais os processos so realizados. necessrio que a empresa defina seus processos chaves escolhendo cuidadosamente os processos a serem tratados para que possa garantir um resultado realmente importante para o seu negcio, evitando, desta forma, grandes investimentos em tecnologia na automao de processos que geram pouco ou nenhum valor para o cliente da empresa e, portanto, ao seu negcio. A evoluo da Tecnologia da Informao (TI), tanto na rea de computao quanto na rea de telecomunicaes, permitiu a drstica reduo dos custos de transferncia de informao e o aumento da velocidade e da qualidade das comunicaes dentro e fora das organizaes. Alm disso, o surgimento de novas

17

tecnologias e conceitos como Supply Chain Management (SCM), Knowledge Management (KM), Customer Relationship Management (CRM) e E-business1 est permitindo que a lgica por processos seja aplicada tanto para integrar reas de uma mesma empresa quanto para integrar as empresas que venham a fazer parte de uma mesma cadeia ou rede de valor. Como visto anteriormente, a viso por processos busca derrubar os muros funcionais e proporcionar uma melhor integrao entre as reas de uma empresa. Sendo assim, importante para uma empresa que deseja manter ou ganhar mercado nos dias de hoje considerar a viso por processos dentro de sua estrutura organizacional. Conforme pode ser visto na figura abaixo, uma empresa tambm deve se preocupar com a sua cadeia de suprimentos e procurar se posicionar da melhor maneira possvel dentro dela. Deve reduzir custos atravs de parcerias com outras empresas, terceirizando atividades e processos que no so chaves e no esto ligados s suas competncias centrais. Assim, cada empresa pode focar seus recursos em processos chaves e se especializar em determinada etapa do processo de produo que agora passa a estar espalhado pela cadeia de suprimento. Esses processos que formam toda a cadeia podem ser chamados de processos colaborativos.

Fornecedor de MP

Indstria

Distribuio

Varejo

=> Matria-prima, Produtos Intermedirios, Produtos Acabados, etc. => Capacidades, Tempos de Entrega, etc. => Crditos, Termos de Pagamentos, Faturas

Figura 2: Integrao da Cadeia de Suprimentos Fonte: NEVES (1999, p. 6)

Nesse contexto, as empresas dentro, de um ambiente de negcio colaborativo, podem compartilhar informaes, conhecimentos, processos e responsabilidades com
1

Negcios realizados atravs da Internet, utilizando os seus recursos

18

seus parceiros, buscando adquirir vantagens competitivas para a cadeia como um todo e no somente para uma empresa. A figura abaixo mostra a evoluo da viso orientada a processos desde a tradicional organizao por funo at o dinmico ambiente colaborativo do e-business.

e-Economia
A PARTIR

Comunidades Orientadas por Processos Cooperao dinmica com e-Business

Organizaes Funcionais Muros

Organizaes Orientadas por Processos Sistemas Logsticos Integrados

Redes de Processos Especficos Planejamento integrado e implementao com SCMs

Figura 3: As Tendncias Organizacionais. Fonte: IDS Scheer AG (2000)

Essa relao direta da viso por processos com TI pode ser comprovada atravs do histrico relacionado aos sistemas integrados de gesto (SIG), passando por conceitos e tecnologias abordadas pela Manufatura Integrada por Computador (ou Computer Integrated Manufacturing CIM), pelos sistemas Enterprise Resources Planning (ERP) com a integrao intra-organizacional e pelos sistemas de Gesto da Cadeia de Suprimento (Supply Chain Management SCM) que buscam fazer o elo entre todos os sistemas ERP das empresas que formam a cadeia, em uma integrao interorganizacional. Na figura abaixo possvel visualizar essa evoluo de conceitos e tecnologias relacionados integrao organizacional.

19

Supply Chain Management

JIT MRP/ MRPII TOC

JIT MRP/ MRPII TOC JIT MRP/ MRPII TOC

CIM

ERP CIM

CIM

ERP

Empresa 1

ERP

Empresa 2

Empresa N

Figura 4: Evoluo de conceitos e sistemas de integrao Fonte: CAMEIRA (1999, p.3)

Como citado anteriormente, diante de um ambiente complexo torna-se necessria a existncia de modelos que facilitem a compreenso e gesto da realidade. Sendo assim, importante entender alguns princpios de modelagem e as principais metodologias de modelagem de processos que suportam a viso por processos.

3.2

Princpios, Ferramentas e Metodologias de Modelagem de Processos de Negcio

Nesse tpico sero abordados alguns dos princpios de modelagem citados e

considerados por alguns autores como base para a criao de um modelo claro e eficiente, ser vista uma anlise de mercado das ferramentas de modelagem de processos e uma proposta de metodologia de seleo de uma ferramenta e, por fim, sero mostradas algumas das principais arquiteturas de modelagem de processos de negcio utilizadas no mercado.

20

3.2.1 Princpios de Modelagem Segundo PIDD (1999), um modelo uma representao externa e explcita de parte da realidade vista pela pessoa que deseja usar aquele modelo para entender, mudar, gerenciar e controlar parte daquela realidade. Porm, para que um modelo possa ser eficaz e eficiente necessrio que ele represente de forma clara e objetiva a situao a que est disposto a explicitar. Para isso, importante seguir alguns princpios de modelagem que so citados por alguns autores como pode ser observado abaixo. Para PIDD (1999), os principais princpios de modelagem so:

Modele simples, pense complicado; Seja parcimonioso, comece com pouco e acrescente; Divida e conquiste, evite mega-modelos; Use metforas, analogias e similaridades; No se apaixone pelos dados.

Em VERNADAT (1996), podem ser encontrados os seguintes princpios de modelagem:

Separao de focos para reduzir a complexidade; Decomposio funcional; Modularidade; Generalidades do modelo; Re-usabilidade; Separao do comportamento e funcionalidade; Descasamento entre processos e recursos; Conformidade; Visualizao do modelo; Simplicidade versus adequao; Gesto da complexidade; Rigor na representao; Separao de dados e controle.

21

Para ROSEMANN (apud SCHEER, 1998) e AALST (apud SANTOS 2002) pode-se encontrar os seguintes princpios de modelagem:

Aderncia realidade; Relevncia ou suficincia no nvel de detalhamento dos modelos de acordo com o objetivo fim da modelagem; Custo / benefcio de se criar um modelo analisando o quo til ser e quanto tempo ser utilizado; Clareza dos modelos para melhor compreenso dos usurios; Capacidade de comparabilidade entre modelos diferentes, pressupondo-se a utilizao da mesma linguagem de modelagem com os mesmos objetos, mesma metodologia e nveis de detalhamento homogneos; Estruturao sistemtica dos modelos que devem apresentar, atravs de uma metodologia consistente, integrao entre diferentes pontos de vista de uma mesma realidade.

importante observar que os princpios de modelagem apresentam relaes de interdependncia e muitos so complementares. Porm, para que haja uma modelagem consistente e de fcil entendimento necessrio que tais princpios sejam aplicados de maneira eficaz proporcionando uma modelagem uniforme e integrada sendo, portanto, importante a existncia de ferramentas suportadas por arquiteturas / metodologias que sirvam de referncia para a modelagem. A seguir sero mostradas brevemente algumas dessas ferramentas e metodologias. 3.2.2 Ferramentas de Modelagem de Processos de Negcio Como mencionado anteriormente, a viso por processos habilitada e realizada atravs da TI e de suas ferramentas informticas. Assim, todas as arquiteturas, metodologias e aplicaes citadas acima necessitam de ferramentas de modelagem que tenham capacidades e funcionalidades suficientes para a realizao dos objetivos de um projeto especfico. Porm, o processo de seleo e compra de uma ferramenta de modelagem deve

22

seguir alguns critrios que permitam comparaes que apiem na tomada de deciso. A escolha da ferramenta deve levar em considerao uma srie de fatores como o escopo do projeto ou dos projetos em que ser utilizada, o tempo estimado de vida til dessa ferramenta dentro da organizao, a poltica do fornecedor com relao manuteno e atualizao da ferramenta, a facilidade de utilizao da mesma, a existncia de base de dados, entre outros fatores que devem ser levados em conta. Conforme pode ser observado na figura abaixo, algumas consultorias como, por exemplo, o Gartner Group, realizam anlises de ferramentas de modelagens de processos segundo alguns critrios, podendo ser levadas em considerao no processo de seleo e compra.

Mercado de Modelagem/Anlise de Processos de Negcios

Pioneiros Lderes

Capacidade de suporte

Atores do Nicho

Visionrios

Figura 5: Comparao de Ferramanetas de Modelagem de Processos Fonte: Gartner Group (2002)

23

O Gartner Group utiliza dois critrios para a classificao das ferramentas, que so a abrangncia da viso relacionada aos possveis desdobramentos e aplicaes em que a ferramenta pode ser utilizada, variando de ferramentas de uso especfico a uso mais geral e a capacidade de suporte ao mercado. Em complemento a figura acima, CAMEIRA e BASTOS (2000) demonstram uma proposta de mtodo de anlise e adequao das ferramentas de modelagem a um projeto com a definio dos objetivos do projeto, a verificao de ferramentas disponveis no mercado para o cumprimento dos objetivos, a anlise de adequao da ferramenta ao escopo do projeto2 e a escolha da ferramenta. Alm desse mtodo, os autores propem outros critrios para anlise, classificao e seleo de ferramentas de modelagem, conforme pode ser observado na figura abaixo:
Verificao de possibilidades, ferramentas disponveis Escolha de ferramenta

Definio dos objetivos

Anlise de adequao

Conhecimento em modelagem

Figura 6: Mtodo de Anlise de Adequao das Ferramentas de Modelagem a um Projeto Fonte: BASTOS, CAMEIRA (2000, p.8)

Os mesmos autores ainda citam outros critrios que julgam importante para avaliar uma ferramenta de modelagem como: Existncia de base de dados O primeiro critrio e corte utilizado pelos autores est relacionado existncia de base de dados nas ferramentas de modelagem. Com uma base de dados associada possvel armazenar e integrar modelos e objetos de forma consistente, alm de proporcionar outras funcionalidades como a gerao e anlise de diversos tipos de relatrios de modelos e objetos armazenados, a possibilidade de criao de filtros, mecanismos de busca, etc.
2

Nessa etapa do mtodo os autores ressaltam que a experincia e o conhecimento em modelagem

contribui significativamente nessa anlise de adequao da ferramenta ao projeto em questo.

24

Existncia de referencial metodolgico - O segundo critrio utilizado foi a existncia de um referencial metodolgico intrnseco a ferramenta, permitindo uma crtica automtica na criao dos modelos, de seus respectivos objetos e de seus relacionamentos. Alm dessas vantagens, a existncia de um referencial metodolgico significa um ponto de partida e uma referncia para os usurios da ferramenta trabalharem de forma padronizada e homognea. As principais ferramentas analisadas no trabalho foram as seguintes: Corel Draw (Corel Software), Flow Charter (Micrografix), is/Modeler (Modus Operandi), ARIS Tool Set (IDS Prof. Scheer GmbH.), Ithink (High Performance Systems), Live Model (Intellicorp), MicroSaint (Systems Modeling), MS Power Point (Microsoft

Corporation), System Architect (Popkin) e Visio Professional. Um outro trabalho interessante e detalhado sobre ferramentas de modelagem pode ser observado em SANTOS (2003, p.114 a p.139) onde o autor faz anlises comparadas de mtodos, aplicaes, funcionalidades (operacionais e de gesto) e de preo para as seguintes ferramentas: ARIS Toolset (IDS Prof. Scheer GmbH.), MS Power Point (Microsoft Corporation), System Architect (Popkin), Visio Professional e Casewise. Todos os trabalhos citados neste tpico apontam a ferramenta de modelagem ARIS Toolset (IDS Prof. Scheer GmbH.) como a melhor para a modelagem de processos por ser suportada por uma base de dados, por uma metodologia, por ser abrangente em termos de escopo de projeto, entre outros critrios que lhe proporcionaram esse status. Considerando-se o resultado acima e que o objetivo deste trabalho apresentar uma metodologia de modelagem de processos orientada para levantamento de requisitos de desenvolvimento de sistemas, a ferramenta ARIS Toolset foi selecionada como base de estudo para o desenvolvimento da metodologia proposta. Dessa forma, conforme ser visto no prximo tpico, importante entender algumas metodologias de modelagem, dando destaque metodologia ARIS e alguns dos modelos utilizados por essa ferramenta. 3.2.3 Arquiteturas e Metodologias de Modelagem de Processos de Negcio Diante da necessidade de criao de vistas organizacionais apoiadas por modelos

25

de todos os tipos, diversas metodologias de modelagem empresarial relacionadas diretamente a EPN, conforme observado em VERNADAT (1996), foram desenvolvidas por diversas organizaes de padronizao com o intuito de facilitar o processo de modelagem empresarial atravs de metodologias pr-definidas que podem ser reutilizadas de maneira integral ou, dependendo do objetivo a ser alcanado por um projeto ou aplicao especfica, servirem como ponto de referncia para o desenvolvimento de uma metodologia prpria e customizada. A partir dessas metodologias de referncia possvel criar uma linguagem padro intra ou, no caso de uma cadeia de organizaes, inter organizacional que facilita a uniformizao de entendimentos por parte das pessoas envolvidas no projeto em questo, tornando a modelagem empresarial mais uniforme, integrada e consistente com os objetivos aos quais pretende realizar. Neste tpico ser apresentada uma viso geral de algumas das principais metodologias desenvolvidas e utilizadas na busca de padres de modelagem. 3.2.3.1 CIMOSA (Computer Integrated Manufacturing Open System

Architecture) Elaborada e documentada por um consrcio de empresas denominado AMICE, trata-se de uma arquitetura cujo objetivo ajudar as organizaes a gerenciar mudanas e integrar suas facilidades e operaes com vista a alcanar preo, qualidade e tempo de entrega competitivos. CIMOSA introduziu a idia de arquitetura de sistemas abertos para CIM, padronizando mdulos, descritos em termos de sua funo, informao, recurso e aspectos organizacionais. Apresenta uma arquitetura consistente tanto com a modelagem quanto com a integrao empresarial como requerido no ambiente CIM e que possui 3 componentes principais: estrutura de modelagem empresarial, a infraestrutura de integrao e ciclo de vida do sistema CIM. Pode ser aplicada tanto no ambiente de engenharia empresarial, no qual, atravs de melhoria contnua ou reengenharia, novos modelos so criados e modelos existentes so melhorados ou pode tambm ser aplicada no ambiente de operaes empresariais nos quais modelos so usados para suportar, controlar ou monitorar o dia-a-dia de operaes atravs do ciclo de vida dos produtos.

26

A estrutura de modelagem apresentada por CIMOSA, conforme pode ser vista na figura abaixo, conhecida como CUBO CIMOSA e se divide em arquitetura de referncia e arquitetura particular. Em sendo tridimensional, a estrutura caracterizada por trs princpios ortogonais: Princpio da Derivao Esta dimenso composta por trs nveis cujo objetivo o de dividir o modelo de negcio em diferentes nveis de abstrao. No primeiro nvel, denominado "Requirements Definition", devem ser registradas as necessidades do negcio de acordo com a viso dos usurios. No segundo nvel, denominado "Design Specification", os requisitos definidos no primeiro nvel so detalhados com o intuito de construir um modelo de negcio executvel. No ltimo nvel, denominado "Implementation Description", acrescenta-se o nvel anterior detalhado para a implementao do modelo de negcio definido. Princpio da Instanciao Este princpio tem como base trs vistas: genrica, parcial e particular. A

primeira vista, denominada de genrica, contm objetos e regras genricas que juntos podem criar uma linguagem de modelagem para expressar modelos gerais ou particulares. A segunda vista, denominada de parcial, tem por objetivo a descrio de modelos gerais como, por exemplo, modelos relacionados a um determinado tipo de indstria que podem ser reutilizados e adaptados para um modelo particular. E, por fim, a vista particular que tem como objetivo a descrio de modelos especficos para uma determinada organizao. As vistas genrica e parcial esto inseridas na arquitetura de referncia e a ltima vista na arquitetura particular. Princpio da Gerao Este princpio composto por quatro vistas complementares: organizao, recursos, informao e funo. A vista de organizao est relacionada representao dos nveis organizacionais, autoridade e responsabilidade. A vista de recursos est relacionada aos seres humanos, mquinas e sistemas e suas capacidades de gerir e executar as funes do negcio. A vista de informao representa os objetos organizacionais e seus elementos de informao. E, por fim, a vista de funo que representa numa lgica temporal o comportamento (processos, atividades e eventos) e as funes organizacionais. 27

Figura 7: O Cubo CIMOSA Fonte: (VERNADAT, 1996, p.45)

3.2.3.2 IDEF (Integrated DEFinition) A metodologia IDEF comeou a ser criada no incio dos anos 70 em um programa da fora area dos Estados Unidos da Amrica denominado de ICAM (Integrated Computer Aided Manufacturing). Inicialmente pensada para engenharia de sistemas, a IDEF com o passar dos anos foi agregando novos mtodos relacionados a diversos aspectos organizacionais que no somente sistemas de informaes. Assim, a IDEF composta por sub-mtodos como o IDEF 0 relacionado a modelagem funcional, o IDEF 1 para modelagem de informaes, o IDEF 2 desenvolvido para suportar simulaes, o IDEF 3 para descrio e captura de processos, IDEF 4 para modelagem orientada a objetos e IDEF 5 para descrio de ontologias. Ainda existem mtodos que esto em desenvolvimento e outros que ainda sero desenvolvidos como, por exemplo,

28

o IDEF 14 para projeto de rede e o IDEF 12 para projeto organizacional. Como citado anteriormente, o mtodo IDEF 3 est diretamente relacionado a modelagem de processos, sendo composto por dois modelos denominados de Fluxo de Processo (Process Flow) e o Rede de Transio de Estado de Objeto (Object State Transition Network (OSTN)). O primeiro modelo tem como objetivo descrever como as coisas so feitas dentro de um determinado processo de produo. O segundo modelo descreve os eventos, pelos quais um objeto passa em um determinado processo. importante ressaltar que ambos os modelos possuem unidades de informao e podem, portanto, serem usados na descrio de sistemas de informao. (GROVER, 2000, p. 170/173), VERNADAT (1996, p. 136/143) e MAYER et. al, apud SANTOS, 2002) 3.2.3.3 ARIS (Architecture of Integrated Information Systems) A metodologia ARIS tem como principal objetivo, atravs de modelos, estabelecer uma viso holstica, integrada e homognea de uma organizao, permitindo o desenvolvimento de sistemas de informao mais aderentes ao negcio. Com o intuito de reduzir a complexidade da modelagem das diversas partes que compem uma organizao, conforme pode ser observado na figura abaixo, a arquitetura se divide em cinco vistas (Organizao, Funo, Dados, Controle ou Processo e Sada) e cada vista se divide em trs nveis (Definio de Requisitos, Projeto e Especificao e, por fim, Implementao).

Figura 8: As vistas e nveis de implementao da metodologia ARIS Fonte: Adaptao de SCHEER (1998, p. 41) apud SANTOS (2002, p. 120)

29

Diversos so os modelos associados a cada vista, entre os quais se destacam o Diagrama de Objetivos, o Organograma, a Cadeia de Valor Agregado, a Cadeia de Eventos Orientados a Processos, Diagrama de Caso de Uso, entre outros que, atravs da lgica da metodologia, se inter-relacionam, mostrando de maneira consistente desde a concepo e do entendimento estratgico da organizao at o nvel de implantao dos componentes de TI que daro suporte operacional estratgia concebida. A subdiviso das vistas em trs nveis faz lembrar, como visto anteriormente, o cubo da arquitetura CIMOSA e tambm lembra muito, conforme ser visto mais a frente, os estgios de desenvolvimento de sistemas de informao (BOOCH et al., 1999). Com relao aos nveis de descrio e conforme pode ser observado em ARIS Methods (2000), o nvel Definio de Requisitos tem como principal objetivo descrever de forma estruturada a aplicao do negcio, se aproximando muito da viso de negcio do usurio. nesse nvel que deve ocorrer a descrio, atravs de modelos como a Cadeia de Eventos Orientados a Processos e Diagrama de Objetivos, dos principais conceitos e idias da organizao, definindo os principais requisitos de negcio que daro suporte ao desenvolvimento das aplicaes de TI. No nvel de Projeto e Especificao deve ser modelado aps de Definio e Requisitos, descrevendo de forma detalhada informaes referentes aplicao da TI. Neste nvel, deve ocorrer a descrio, atravs de, por exemplo, modelos como os da UML, dos requisitos de negcio definidos no nvel anterior e dos requisitos funcionais da aplicao a ser desenvolvida. Por fim, o nvel de Implementao com base nos modelos descritos no nvel anterior define os componentes de software e hardware que iro compor a aplicao final. Nesse nvel, modelos da UML como o Diagrama de Componentes e de Implantao podem apoiar a modelagem. importante observar, conforme pode ser visto em ARIS Methods (2000), que os nveis citados possuem ciclos de vida diferentes, variando com a proximidade da aplicao da TI. Ou seja, o nvel de Projeto e Especificao e principalmente o nvel de Implementao possuem ciclos de vida mais reduzidos, pois, esto mais prximos da TI que se renova com muita freqncia num curto espao de tempo. Isto j no acontece

30

com o nvel de Definio de Requisitos, pois este est diretamente ligado viso de negcio que no muda com mesma velocidade da TI.

3.3

Conceitos de Modelagem de Processo de Negcio e Modelos Tradicionais

Nesse tpico sero descritos alguns dos principais conceitos envolvidos com a

modelagem de um negcio, englobando, portanto, os conceitos relacionados a processos de negcio j citados em algumas das definies de alguns autores no incio do captulo. Alm disso, para exemplificar os modelos utilizados pela EPN para modelagem de negcio, ser utilizada nesse tpico a metodologia ARIS3 e alguns dos seus modelos. Essa metodologia foi escolhida pelo fato de ser suportada por uma ferramenta de modelagem considerada pelo Gartner Group como lder de mercado de anlise e modelagem de processos de negcio (conforme foi apresentado no tpico 3.3.2) e pelo fato do autor possuir alguma experincia de utilizao da ferramenta em projetos envolvidos com modelagem de processos e desdobramentos afins. 3.3.1 Conceitos de Modelagem de Processo de Negcio Diversas so as definies de processo de negcio propostas por inmeros autores que apresentam similaridades conceituais (HAMMER e CHAMPY, 1994, DAVENPORT, 1993, ZARIFIAN apud SALERNO, 1999, SALERNO, 1999, SANTOS, 2002, ERIKSSON E PENKER, 2000).

A metodologia ARIS foi apresentada no tpico 3.2.3.3

31

Com base na similaridade desses conceitos possvel elaborar um metamodelo4 como o elaborado por JACKOWSKI (2003). Segundo o autor, um metamodelo pode ser utilizado como padro para a criao de modelos de processos de negcio especficos. Conforme pode ser observado na figura abaixo, atravs do metamodelo, que pode ser representado, por exemplo, por um diagrama de classes da UML, possvel representar os conceitos de negcio.

Figura 9: Metamodelo de Processo de Negcio Fonte: JACKOWSKI (2003)

Tambm importante ressaltar que esses conceitos relacionados modelagem de negcio possuem relacionamentos entre si, podendo uma determinada regra definir a maneira de como os recursos so estruturados, os recursos, por sua vez, so utilizados na forma de insumo, produto e mecanismos envolvidos na execuo dos processos de negcio, os objetivos esto diretamente ligados razo de existir dos processos de negcio, entre outros tipos de relacionamentos que existem entre esses conceitos.

O conceito de metamodelo foi definido no captulo 4.

32

Esses conceitos representados por classes de objetos so descritos abaixo (JACKOWSKI, 2003, ERIKSSON E PENKER, 2000):

Processo de Negcio - O conceito de processo, conforme pode ser observado na figura acima, se relaciona com a maior parte dos demais conceitos e apresenta os atributos de descrio e de medidas. O primeiro atributo est relacionado com a descrio textual ou grfica do processo, mostrando como o processo executado e quais so os recursos de entrada (processados e consumidos pelo mesmo) e quais so os de sada. O segundo atributo est diretamente relacionado s mtricas (indicadores) do processo, considerando fatores de qualidade, tempo, custo, entre outros. Alm disso, importante ressaltar que um processo pode ser desdobrado em subprocessos, representando vrios nveis de detalhamento do negcio, est associado pelo menos uma unidade organizacional responsvel por sua gesto e controle, composto por uma ou mais atividades que so executadas por trabalhadores ou sistemas do negcio, regido por regras de negcio e, por fim, iniciado a partir de eventos externos ou internos a organizao e ao ser finalizado gera algum tipo de evento indicando que seu objetivo foi realizado.

Objetivos do Negcio - so propsitos gerais que um negcio pretende alcanar, podendo ser ramificados em sub-objetivos divididos, por exemplo, por reas funcionais do negcio. Alm disso, todo processo deve estar associado direta ou indiretamente pelo menos um objetivo estratgico que pode ser definido por uma ou mais regras de negcio e corresponde ao estado em que o recurso estar ao final do processo. Tambm importante destacar que a realizao de um objetivo depende de problemas ou fatores crticos que limitam o seu alcance.

Recursos

(Objetos

de

Negcio)

so

elementos

que

apresentam

relacionamentos entre si como materiais, pessoas, informaes ou produtos que so manipulados por processos de negcio e podem ser classificados como elementos fsicos, abstratos e informacionais. Conforme definido no conceito de 33

processo, esses objetos podem ser de entrada (material ou informao) sendo transformado ou consumido pelo processo e podem ser de sada representando um resultado coerente com o objetivo do processo. importante ressaltar que um objeto de sada de um processo pode fazer o papel de entrada de outro processo. Alm disso, conforme pode ser visto na figura acima, um objeto de negcio pode ser fornecido por uma ou mais organizaes externas ao negcio.

Regras de Negcio constituem de afirmaes que definem ou limitam alguns aspectos do negcio e representam o conhecimento do negcio. As regras determinam como o negcio deve se comportar, ou seja, como os processos de negcio devem ser executados e como os recursos utilizados so estruturados e se relacionam entre si. As regras podem ser definidas a partir de leis externas ou definidas internamente ao negcio, para que sejam alcanados os objetivos, podendo ser expressas tanto de forma textual como de forma grfica atravs de modelos. 3.3.2 As Vistas da Metodologia ARIS e seus Modelos Conforme citado anteriormente, a arquitetura da metodologia se divide em cinco vistas (Organizao, Funo, Dados, Controle ou Processo e Sada) e cada vista se divide em trs nveis (Definio de Requisitos, Projeto e Especificao e, por fim, Implementao). Nesse tpico sero descritos de maneira breve alguns dos modelos associados a cada vista e ao nvel de Definio de Requisitos que representam os principais conceitos envolvidos com a modelagem de processos de negcio. 3.3.2.1 A Vista de Funes Segundo ARIS Methods (2001), uma funo pode ser definida como uma tarefa tcnica ou ao realizada sobre um objeto para suportar um ou mais objetivos de uma organizao. De acordo com essa definio, pode-se concluir que a existncia de uma funo dentro de uma organizao s faz sentido se esta estiver associada pelo menos um objetivo organizacional desdobrado da estratgia de atuao definida. Assim, a ferramenta de suporte a metodologia, ARIS Toolset, apresenta no nvel de Definio de Requisitos, conforme pode ser observado nas figuras abaixo, modelos como o Diagrama 34

de Objetivos e Diagrama de rvore de Funo que auxiliam na identificao e entendimento das relaes entre as funes e objetivos e suas hierarquias.
Maximizar participao no mercado Reduzir Custos

Lotes de produo Aumentar ndices de crescimento Melhorar qualidade Cumprir prazos de entrega Tamanho dos estoques

Penetrar mercado asitico

Controle de Produo

Figura 10: Exemplo de Diagrama de Objetivos Fonte: Adaptada de SCHEER (1999)

Processo de Negcio

Compra

Produo

Venda

Controle de Produo

Plano de Produo

Figura 11: Exemplo de Diagrama de rvore de Funo Fonte: O autor, adaptado de ARIS Methods (2001,p.42)

No exemplo de Diagrama de Objetivos, a funo Controle de Produo, representada por um retngulo de bordas arredondadas, est associada aos objetivos, representados por pentgonos no formato de casa, de melhoria de qualidade e ao de cumprimento do prazo de entrega, que por sua vez esto associados aos objetivos hierarquicamente superiores maximizar participao no mercado e reduzir custos. Alm 35

disso, as elipses associadas aos objetivos representam os fatores crticos de sucesso atrelados ao cumprimento dos objetivos. No exemplo, os fatores crticos de sucesso lotes de produo e tamanho dos estoques devem ser considerados para alcanar os objetivos de cumprir prazo de entrega e reduzir custo. O Diagrama de rvore de Funo tem como principal objetivo permitir uma anlise funcional orientada pelos objetivos associados s funes, determinando para cada funo as suas subfunes at que se chegue ao nvel de funo elementar que no deve ou no pode ser decomposta em unidades menores. (ARIS Methods, 2001). Para VERNADAT (1996), o principal objetivo de uma modelagem funcional a descrio da funcionalidade e o comportamento de uma organizao at o nvel de detalhamento requerido pelo usurio. No exemplo, a funo processos de negcio se subdivide, por exemplo, em processo de produo que por sua vez subdividido em processos de planejamento e controle da produo. Atravs da identificao das funes associadas aos objetivos e de suas hierarquias, torna-se possvel saber quais so as funcionalidades que devem ser executadas para o alcance dos objetivos desejados. Existem outros modelos associados vista de funes e aos nveis de Projeto e Especificao e Implementao que no foram citados, pois, no esto no escopo dessa dissertao. 3.3.2.2 A Vista de Dados A quantidade de dados processados e armazenados todos os dias dentro de uma organizao enorme, sendo que a estruturao desses dados em informaes pode variar desde uma pequena nota em um pedao de papel at sofisticados arquivos eletrnicos como guias de usurios, arquivos de banco de dados, documentos tcnicos, etc. (VERNADAT, 1996). Assim, muito importante, conforme pode ser observado em ARIS Methods (2001), que se realize uma modelagem semntica dos dados, expressando de forma clara a especificao para aplicaes que suportam as funes, processos e objetivos estratgicos da organizao. O principal modelo para realizar esse levantamento o modelo de entidades e relacionamentos (MER) que tem como principal objetivo apresentar a estrutura de 36

dados de uma determinada aplicao atravs da descrio das entidades de dados e seus relacionamentos. (CHEN apud SILVA, 2001) SCHEER (1999) prope uma modelagem preliminar ao MER que proporcione uma viso macro dos dados que estariam relacionados a uma organizao, agregando conjunto de dados relacionados em objetos de dados complexos determinados como clusters. Conforme pode ser observado na figura abaixo, aps o mapeamento de uma viso geral dos clusters necessrios a uma aplicao, poder-se-ia, ento, utilizar o MER para detalhamento de cada cluster.
Modelo de Dados da Organizao

Modelos de Dados de Manufatura

Modelo de Dados de Vendas

Pedido do Cliente

Cliente

Envia

Pedido

Figura 12: Modelo de Dados com Clusters e ERM Fonte: O autor, com base em SCHEER (1999)

Podemos perceber que, como mostrado na figura acima, os clusters ou objetos complexos de dados so representados pelos retngulos avermelhados, enquanto que o MER relacionado ao cluster Pedido do Cliente est representado pelas entidades Cliente e Pedido, representadas por retngulos da cor azul, que por sua vez esto relacionados por um losango amarelo que mostra o relacionamento que existe entre as duas entidades.

37

3.3.2.3 A Vista de Organizao Uma organizao pode ser considerada uma estrutura social complexa, constituda de unidades funcionais e que deve possuir regras e padres para lidar com sua complexidade. Alm disso, essas unidades funcionais so providas de tecnologias para executar um determinado trabalho (ARIS Methods, 2001; VERNADAT, 1996). A modelagem e a anlise da estrutura organizacional de uma empresa podem contribuir bastante na anlise dos processos de negcio, pois, determina a forma como se d a diviso do trabalho, a hierarquia de responsabilidades e coordenao, entre outras informaes que agregam valor na anlise de um negcio. O principal modelo relacionado ao nvel de Definio de Requisitos o organograma que pode ser definido, segundo VERNADAT (1996), como uma estrutura hierrquica que define as reas funcionais ou unidades organizacionais de competncia identificadas em uma empresa, indicando quem responsvel pela rea funcional e a quem se reporta na estrutura. Com a modelagem do organograma, possvel atribuir responsabilidades e determinar quem executar as funes e respectivamente os objetivos definidos na vista de funes. A figura abaixo mostra um exemplo de organograma que pode ser modelado no ARIS Toolset.
Gerncia de Operaes Gerente de Operaes Valter Luis

Gerncia de Manuteno de Processos

Gerncia de Novos Processos

Gerente de Processos

Joo Silva

Coordenador do Produto X Claudio Reis

Alexandre

Figura 13: Exemplo de Organograma Fonte: O autor

Uma caracterstica importante da ferramenta ARIS Toolset est relacionado ao fato de que as conexes existentes entre os objetos guardam informaes como, por exemplo, relacionamentos de hierarquia entre os objetos de um organograma. Para 38

exemplificar, a linha que liga o Joo Silva ao cargo de Gerente de Processos possui a informao de que o Joo ocupa aquele cargo e a linha que liga o cargo Coordenador do Produto X a unidade organizacional Gerncia de Novos Processos possui a informao de essa gerncia composta daquele cargo. Com informaes relacionadas ao tipo de relacionamento existente entre os objetos, possvel, por intermdio de relatrios gerados pela ferramenta ARIS Toolset, realizar anlises mais precisas da estrutura organizacional. 3.3.2.4 A Vista de Processos Segundo ARIS Methods (2001), a vista de processos ou de controle, a responsvel pela integrao das demais vistas. Um modelo de processo normalmente construdo com diversos objetos que se encontram nas demais vistas e representa o aspecto dinmico e comportamental de uma organizao (SCHEER, 1999). Como modelos principais envolvidos na vista de processos, pode-se citar a Cadeia de Valor Agregada (Value Added Chain - VAC), Cadeia de Processos Orientada a Evento (Event Driven Process Chain EPC) e o Diagrama de Alocao de Funes (Function Alocation Diagram FAD). O primeiro modelo, VAC, apresenta como agregado o valor durante a realizao das atividades e processos na organizao. Facilita sobremaneira a viso macro dos processos mapeados, como eles se concatenam, como trafega a informao e os materiais (documentos, por exemplo) na organizao. A partir dele pode-se realizar a navegao logicamente estruturada pelos processos detalhados, os EPCs. A construo dos VACs, concatenando os diversos EPCs mapeados, garante a consistncia na interligao dos processos entre sees e desenha, claramente, as linhas de processo horizontais organizao. Essas linhas horizontais percorrem as diversas sees, de forma independente estrutura funcional prescrita pelos organogramas formais da empresa. Em outras palavras, ela apresenta como efetivamente a informao percorre as diversas reas e como o trabalho realizado, a sua seqncia, entre as diversas reas. Em suma, o responsvel por permitir a viso do fluxo de informao dos processos, permitindo a visualizao dos macroprocessos que permeiam a unidade organizacional.

39

Adicionalmente, explicita os links com outras unidades organizacionais e permite a visualizao de pontos finais de processos (aonde ele no mais se desenvolve, nem internamente unidade organizacional, nem indicando conexo outra seo ou diviso). Dessa forma, atravs do VAC pode ser obtida uma viso agregada dos processos. A partir do VAC poder-se- acessar, na ferramenta ARIS Toolset, qualquer EPC. O segundo modelo, EPC, encadeia seqencialmente as atividades realizadas em um dado processo, bem como os eventos que as motivam, associando a cada atividade os recursos por elas consumidos (relatrios, sistemas, meios de comunicao, etc.) e os indivduos ou unidades organizacionais responsveis pela sua realizao, utilizando operadores lgicos para descrever a lgica de encadeamento das atividades. Isto pode ser observado na figura abaixo, onde as atividades so representadas pelos objetos verdes, os eventos pelos objetos rosas, as unidades organizacionais pelos objetos amarelos, as interfaces de processos pelos objetos brancos no incio e no final do processo e os sistemas, informaes, conhecimentos e documentos necessrios para a realizao das atividades so representados pelos objetos, azul, vermelho, roxo e branco do lado esquerdo das atividades respectivamente. O EPC pode ser considerado, dentre os diversos modelos existentes nesta vista, o mais importante, pois, atravs desse modelo possvel visualizar, para cada processo, seus executores, clientes e fornecedores, bem como os insumos necessrios realizao do mesmo e os produtos por ele gerados. Alm desses modelos, existe o FAD que normalmente utilizado quando se deseja reduzir a complexidade do EPC quando este apresenta muitas informaes. Este modelo serve para representar tanto recursos, como insumos e produtos gerados por uma atividade. As figuras abaixo mostram um exemplo de um EPC e um exemplo de VAC linkado a alguns dos seus EPCs que esto associados a FADs.

40

Interface de Processo

Evento 1

Organizational unit

Atividade

Application system type

OU

Evento 2

Evento 3

Organizational unit

Atividade

Knowledge category

Organizational unit

Atividade

Document

Evento

Evento

OU

Organizational unit

Atividade

Cluster

Evento

Interface de Processo

Figura 14: Exemplo de EPC Fonte: O autor

Macro-processo VAC

Processo EPC

Detalhamento (Processos)

Atividade FAD

Figura 14: Exemplo de VAC e EPCs associados Fonte: O autor.

3.4

Nvel de Agregao da Modelagem de Processos de Negcio

Um aspecto importante a ser considerado dentro de qualquer projeto que venha a

envolver modelagem, o nvel de agregao dos modelos que deve estar adequado o suficiente para a realizao dos objetivos definidos no projeto. Dependendo do escopo do projeto, o nvel de detalhamento dos modelos pode variar podendo, por exemplo, ter 41

um alto nvel de detalhamento num projeto de desenvolvimento de sistemas de informaes e um nvel mais baixo no caso, por exemplo, de um projeto para divulgao de processos referentes procedimentos operacionais bsicos ou em um projeto cujo objetivo entender de forma rpida os macro-processos que compem uma organizao. Porm, mesmo dentro de um escopo definido podem existir nveis de detalhamento diferentes, pois, as pessoas que so entrevistadas ou que executam a

modelagem podem apresentar nveis de conhecimento e de experincia diferentes refletindo no nvel de agregao dos modelos. Para CAMEIRA (2003), o nvel de detalhamento uma varivel fuzzy no existindo uma regra exata em sua definio. Este mesmo autor coloca que apesar de ser uma varivel fuzzy, existem alguns pontos balizadores que ajudam a identificar o nvel de detalhamento adequado (CAMEIRA, 2003 e CAMEIRA, CAULLIRAUX, 2000). Quando o objetivo da modelagem , por exemplo, o entendimento do fluxo de informao que atravessa os processos operacionais de uma organizao, os processos modelados devem ter um grau de detalhamento mnimo para expressar de forma clara esse fluxo de informao e / ou materiais suportado por eles. No caso em que um processo apresenta um alto grau de detalhamento sem necessidade, importante saber identificar se o que est sendo descrito no um procedimento como, por exemplo, em que campos de que telas de um determinado sistema um usurio deve executar a atividade registrar os dados de um cliente. No caso em que o objetivo da modelagem o rpido entendimento dos macroprocessos de uma organizao para definio, por exemplo, de objetivos estratgicos, um baixo nvel de detalhamento pode ser suficiente. Se o objetivo da modelagem for, por exemplo, o desenvolvimento de um sistema de informao, o nvel de detalhamento dos modelos deve ser suficiente para a compreenso dos requisitos de negcio, funcionais e tcnicos que sero necessrios para o desenvolvimento e implantao do sistema. Esse processo de desenvolvimento de um sistema de informao engloba tanto modelos de processos de negcio, macros e detalhados, quanto modelos de dados como, por exemplo, os modelos da UML que definem, no caso de um desenvolvimento orientado a objeto, as classes, os objetos e seus relacionamentos.

42

3.5

Aplicaes da EPN
A EPN tem como atividade central o levantamento, modelagem, validao e

redesenho de processos de negcio. A partir dessa anlise dos processos de negcio, podem ser identificadas diversas melhorias alm do desdobramento de diversas frentes e aplicaes conforme pode ser observado no texto e na figura abaixo:
Integrao organizacional Uniformizao de entendimentos Sistemas Integrados de Gesto Projeto de sistemas de informao Indicadores de desempenho

Gerncia do conhecimento

Representao, Anlise e Melhorias de processos Redesenho de Processos MTODOS: Aris, Cimosa, Idef 3

. Benchmarking

Modelos de negcios eletrnicos Anlises organizacionais . Cadeia de Suprimentos Workflow e Gerncia de documentos

Organizao de documentao tcnica

Figura 15: Engenharia de Processos de Negcio e Aplicaes Fonte: Adaptada de SANTOS e CAMEIRA, 2000 e SANTOS et al. (2002, p. 3)

3.5.1 Anlises Organizacionais Atravs da modelagem de processos possvel realizar projetos de organizaes orientados pela viso por processos possibilitando reflexo sobre a estrutura organizacional existente e uma possvel transio para uma nova estrutura como, por exemplo, a transio de estrutura funcional e muito hierarquizada para uma matricial e at mesmo para uma totalmente orientada por processos. 3.5.2 Indicadores de Desempenho A modelagem de processos facilita a identificao de indicadores de desempenho locais e globais diretamente relacionados a um determinado processo ou a uma rea de uma organizao. Identificados e implementados, tais indicadores servem de base para atividade de monitorao da organizao como um todo, apoiando as tomadas de deciso. Nesse sentido, algumas ferramentas esto sendo desenvolvidas como, por exemplo, o Process Performance Management (PPM), desenvolvido pela

43

IDS Scheer AG, que tem o intuito de realizar o acompanhamento automtico dos indicadores dos processos durante a operao de Sistemas Integrados de Gesto. 3.5.3 Gesto do Conhecimento Atravs da modelagem dos processos possvel realizar anlises dos conhecimentos necessrios e disponveis para a execuo das atividades de uma organizao, podendo identificar gaps de conhecimento que podem ser preenchidos atravs de programas de treinamento e capacitaes. Alm disso, os modelos originados pela modelagem dos processos representam de forma explcita parte do conhecimento de uma organizao que pode ser armazenado, passado e reutilizado por qualquer pessoa. (DAVENPORT, 2000) 3.5.4 Gerncia Eletrnica de Documentos (GED) e Workflow Conforme pode ser observado em SILVA (2001), um outro desdobramento possvel realizado atravs da modelagem de processos est relacionado a projetos de implantao de sistemas do tipo Workflow e Gerncia Eletrnica de Documentos (GED) que tem como objetivo automatizar os processo de negcio e seus respectivos fluxos de informaes. A metodologia de modelagem aplicada em um projeto como esse tem como base o desenho e redesenho dos fluxos de processos de negcios e o levantamento da documentao associada a esses fluxos. 3.5.5 Gesto da Cadeia de Suprimento Como j citado anteriormente, a viso por processos pode ser expandida para alm das fronteiras organizacionais sendo aplicada tambm em cadeias de suprimentos que envolvam diversas organizaes que dentro de um cenrio colaborativo interajam de maneira integrada atravs dos processos de fornecimento, produo e distribuio de produtos ao mercado. Nesse cenrio, a competio se d entre cadeias e no mais entre organizaes, sendo de extrema importncia a realizao de parcerias e aquisies de organizaes que possuam competncias chave para contribuir com o desempenho global da cadeia.

44

3.5.6 Organizao da Documentao Tcnica Uma outra aplicao da modelagem de processos est relacionada a organizao da documentao tcnica referente elaborao e reviso de normas, procedimentos e manuais. Atravs de modelos de processos com diferentes nveis de detalhamento, pode-se ter uma integrao consistente entre documentos organizacionais para atender, por exemplo, uma certificao segundo as normas ISO. 3.5.7 Benchmarking Com seus modelos de processos mapeados, uma organizao pode compar-los com modelos de referncias, baseados nas melhores prticas do mercado, ou at mesmo compar-los, caso tenha acesso, a modelos de outras organizaes com intuito de manter competitividade atravs do ganho de novos conhecimentos que podem gerar novas oportunidades de negcio. 3.5.8 Modelos de Negcios Eletrnicos Com possibilidade de troca de informaes via Internet, diversos modelos de negcios virtuais surgem com o intuito de estabelecer vrios tipos de relacionamentos entre empresas (Business to Business B2B), entre empresas e clientes (Business to Customer B2C), entre outros. No que tange a essa aplicao, os modelos de processos podem ser usados para a simulao dessas relaes virtuais possibilitando o dimensionamento dos recursos necessrios para a implantao desses modelos de negcios. 3.5.9 Uniformizao de entendimentos e integrao organizacional A modelagem de processos permite a uniformizao de entendimentos sobre a forma de trabalho e a integrao das unidades organizacionais atravs da divulgao dos processos pela organizao e da identificao das interfaces organizacionais, o que possibilita viso homognea e integrada do negcio. 3.5.10 Implantao dos Sistemas Integrados de Gesto A modelagem de processos pode ser usada para apoiar todo o processo de implantao de um Sistema Integrado de Gesto (SIG), passando pela definio da 45

estratgia de implantao na fase de pr-implantao onde devem ser feitas anlises com relao ao tempo de implantao total, custos e adaptaes do sistema a organizao e vice-versa; a fase de implantao propriamente dita onde sero implantados e testados com os usurios os mdulos do SIG para verificar sua consistncia com os processos modelados e com a estratgia definida na fase anterior; e, por fim, a fase de ps-implantao quando o SIG est em operao, sendo, portanto, necessrio o treinamento dos usurios finais do sistema baseado nos processos modelados. 3.5.11 Projetos de Sistemas de Informao Dentro da Engenharia de Processos de Negcio existem algumas abordagens relacionadas ao desenvolvimento de sistemas de informao e, portanto, aos sistemas de software. Conforme pode ser observado em SCHEER (1998) a estrutura proposta apresenta cinco nveis com o desdobramento dos processos de negcio ao nvel de implementao dos sistemas de informao e tem como base a metodologia de modelagem de processos ARIS apresentada no tpico 3.2.3.3. A figura abaixo mostra essa estrutura e a seguir so descritos esses nveis.

Figura 16: Arquitetura de Processos de Negcio com Desdobramento para Sistemas de Informao. Fonte: SCHEER (1998)

46

No primeiro nvel, Engenharia de Processo, os processos so modelados mostrando como a organizao ou conjunto de organizaes realiza as atividades relacionadas ao negcio em questo, levando-se em considerao alguns

desdobramentos da EPN como aplicao de modelos de referncia, gesto do conhecimento, controle de qualidade, simulao para teste de cenrios propostos, etc. O segundo nvel, Planejamento e Controle do Processo, est relacionado a tcnicas de planejamento, controle e monitorao dos processos, definindo capacidade de recursos, anlise de custos, indicadores de desempenho e outros aspectos que servem de parmetros para a melhoria contnua dos processos definidos no nvel anterior. No prximo nvel, Workflow do Processo, ocorre a gesto do fluxo dos objetos de negcio (informao, materiais, pessoal, etc) estando, portanto, relacionado com o controle de execuo dos processos definidos no primeiro nvel e com a transio da documentao entre postos de trabalhos. Alm disso, os dados (tempo de execuo das tarefas, alocao de unidades organizacionais, etc.) obtidos nesse nvel, servem de entrada para o controle exercido no nvel dois. No ltimo e quarto nvel, Aplicaes, existe a anlise e o projeto de sistemas de aplicaes diversas, variando dos mais simples at sistemas corporativos, com o intuito de dar suporte ao processamento de objetos de negcio definidos pelos processos modelados no nvel um. Alm disso, a execuo dessas aplicaes se d no nvel trs. Em VERNADAT (1996) pode ser observada uma outra abordagem dentro da EPN ligada ao desenvolvimento de sistemas de informao. O autor desenvolveu uma estrutura voltada para a construo de sistemas integrados e modulares de manufatura com o intuito de modelar os processos de negcio, atender aos requisitos dos usurios, suportar o projeto e anlise de sistemas de informao, selecionar entidades funcionais que devem ser instaladas, prever o desempenho do sistema e automatizar a produo de cdigos do sistema de informao a ser implantado. A proposta do autor procura cobrir todas as fases de desenvolvimento de um sistema de informao, passando pelo planejamento estratgico, definio de requisitos, projeto de especificaes, definio de implementao, instalao e operacionalizao do sistema. O desenvolvimento de um sistema de informao baseado na viso por processos apresenta algumas vantagens como a possibilidade de se evitar sistemas redundantes pela organizao, a possibilidade de existncia de base de dados nica, 47

integrada e consistente, maior eficincia no fluxo de informaes que atravessa a organizao ou a cadeia na qual est inserida, etc. Nesse tipo de aplicao importante que sejam modelados no somente os processos, mas tambm as informaes e dados necessrios para o desenvolvimento do sistema. No que tange a modelagem de dados, a utilizao de uma ferramenta Computer Aided Software Enginneering (CASE) que suporte uma linguagem padro como, por exemplo, a Unified Modeling Language (UML)5, facilita o processo de

desenvolvimento. Um outro fator importante em que a EPN pode contribuir com o desenvolvimento de sistemas de informaes, est relacionado identificao de componentes de processos que podem ser reutilizados para a criao e lanamento de um novo produto no mercado, reduzindo o tempo de desenvolvimento de produto e de sistemas de informao. Alm disso, tambm importante ressaltar o conceito de Engenharia Simultnea enquanto habilitadora na reduo do tempo de desenvolvimento de um sistema de informao. De acordo com a definio abaixo, possvel compreender o conceito de Engenharia Simultnea.
"Engenharia Simultnea uma metodologia de desenvolvimento de produtos, na qual vrios requisitos (X-abilities) so consideradas parte do processo de desenvolvimento de produtos (manufatura, servio, qualidade, entre outros). Esses requisitos no servem somente para se atingir as funcionalidades bsicas do produto, mas para definir um produto que atenda todas as necessidades dos clientes" (HARTLEY, 1992 apud PRASAD, 1996)

Conforme pode ser observado em CAMEIRA et.al (2002), a utilizao do conceito de Engenharia Simultnea no processo de desenvolvimento de um sistema de informao somado a padronizao e construo de componentes de processos de negcio associados a componentes de sistema, pode reduzir o reduo do lead time

O detalhamento da UML e de seus modelos pode ser visto no captulo 4.

48

entre a percepo da necessidade de mudana, em funo de sinais do ambiente de atuao das organizaes, e a implementao de um novo sistema de informao. A figura abaixo facilita a compreenso do que foi colocado acima.

Figura 17: Projeto de Sistemas com Engenharia Simultnea Fonte: SANTOS (2002, p 115)

Conforme possvel observar em CAMEIRA (2003), com o apoio de uma boa ferramenta de modelagem que possa realizar a componentizao de processos de negcio, possvel obter as seguintes vantagens: Formalizao e padronizao da modelagem de processos isto ocorre devido possibilidade de associar pedaos de processos semelhantes, de forma bastante granularizada, que sejam baseados em sistemas. Por exemplo, funes semelhantes em um sistema que controla os processos de roteamento de equipes de manuteno, para dois produtos diferentes comercializados. Auxilia, portanto, a identificao do pedao de processo que delimitar um componente de software; Armazenamento de representaes reutilizveis de processos visando que estas representaes possam ser reutilizadas em futuras modelagens, dotando de flexibilidade a (re)construo de processos e sistemas a eles associados.

49

Isto conseguido relacionando-se a viso de sistemas, atravs dos modelos da UML, viso do negcio, com modelos tradicionais da Engenharia de Processo. A partir desta relao, com a descrio dos processos e suas relaes com a estrutura organizacional, busca-se facilitar o entendimento dos relacionamentos que um sistema dever suportar, quais os atributos de uma dada atividade, etc.; Apoio melhoria dos processos e do desenvolvimento de sistemas de suporte operao a partir da formalizao, padronizao, armazenamento e conseqente reutilizao, os esforos futuros em EPN e Engenharia de Sistemas podero produzir retornos mais substanciais, pois o foco da ao est, por assim dizer, componentizado; Maior facilidade para o gerenciamento dos processos o uso de ferramentas de modelagem leva a uma maior simplicidade do gerenciamento e manuteno dos processos, bem como da capacidade de ao sobre eles. No limite facilita, por desdobramento at o nvel de sistema, a realizao da estratgia e dos objetivos do negcio. Por exemplo, facilita sobremaneira a operacionalizao de sistemas de Workflow, usualmente de rdua implantao e complexa manuteno; Acelerao da capacidade de desenvolvimento e de adequao dos sistemas que suportam os produtos e servios talvez a principal vantagem, o tempo total de desenvolvimento e operacionalizao de processos, apoiados por sistemas e, conseqentemente, de produtos ou servios entregues ao mercado, diminudo. Reflexos diretos em custos, minorados; Aumento da flexibilidade frente s variaes da demanda esta maior facilidade e esta capacidade de reutilizao, somadas, dotam a organizao de maior capacidade de refletir, em seus processos, as necessidades de ajustes decorrentes de variaes do ambiente competitivo no qual se insere a organizao; Melhoria das interfaces processuais refere-se facilidade de integrao sistmica dos processos, dos fluxos de informao entre uma determinada rea da organizao e suas reas conexas, internamente e externamente, na cadeia. 50

Segundo CAMEIRA (2003) a componentizao de processo pode reduzir os tempos de desenvolvimento dos sistemas de informao, pois identificado padres de comportamento e solues implementadas pelos processos de negcio possvel criar uma biblioteca de componentes de processo e relacion-los a componentes de software. Como exemplo, o autor coloca que aps a implantao do primeiro sistema componentizado baseado em processos com grande nmero de atividades iguais, o desenvolvimento do segundo passa a ser focado apenas nas diferenas, podendo reaproveitar os componentes de software criados anteriormente. Na figura abaixo possvel visualizar a situao descrita acima, mostrando a relao entre processos de negcio, modelos da UML e componentes de software.
Sales processing
Windows client
Anlise da Order Entry (piloto)

Order Entry aceita (integral ou parcialmente) Verificar localizao do Centro de Cliente

Determine customer request

Applicatio n frame

M. Bernardy
User input Editor Check

GIC-N

Marketing
Precheck

Sales processing

Production planing

Centro de cliente no exterior

Centro de cliente no Brasil Identificar a prxima fase do processo de telefonia Sistema Suporte de Telefonia

Application server

00001001 11001000 10101010 ... 11010100

00001001 11001000 10101010 ... 11010100

Export control

V. Stark

Master data

GIC-N

Customer requests
Human resource

Necessidade de utilizao de acesso

Necessidade de utilizao da Rede E1

Necessidade de configurao de Rede de Servio

Necessidade de configurao de funcionalidades de servio

Necessidade de implantao de CPE

Customer order
Master data administration

Obteno de Acesso

Facilidades de Rede (Telefonia - piloto)

Implantao de CPE (Telefonia)

Use Case

Actor
Organiza tional unit Org. n

Acesso obtido

Rede E1 configurada

M. Bernardy

T. Becker

V. Stark

Configurao de Rede de Servio (Telefonia - piloto)

Open cus tomer inquiry Custom er inquir y [created]

Customer text (created)

Cus tomer r eques t [product configured]

Custo mer Customer n Create custo mer data Delete custo mer data Cha nge custo mer data Analyze c. da ta

Customer inquiry Date Create c. reque st Read c. reque st Delete c. reque st Analyze c. inquieries Customer inquiry positions Create c. request po s. Analyze c. inquiry pos. Read c. request po s.

Article Article n

00001001 11001000 10101010 ... 11010100

00001001 11001000 10101010 ... 11010100 00001001 11001000 10101010 ... 11010100

Houve emisso de OTS para o acesso Chamar componente genrico Sistema Suporte de Telefonia

No houve emisso de OTS para o acesso

Rede internacional configurada

C riao da Order E ntry

Corr e d o a Or d Ent y er r ( ea d M ercad r e o)

Configure produc t

Order E ntry c riad a An e d lis a O rder E ntry G IC-N N ecess ida de de ut li a i z o da Rede E1 Todos o s ite d OE ns a es t OK o Verif c ar se i Si tem s a dado da OE s por t de e s o s uf c ie e s p/ Su i nt o a al c a fac . r e o r de Telef ni Anal s ar i O rder E ntry

Or d Ent y er r c orrigi a d

Ex istem itens d O E a que n o es t o O K

Customer text Customer text (read) (modified) Customer text (created)

Custom reques t er [ex port control executed] Proces s documents

G IC-N

Regis t ar r obj es e Verifi ar se c p s e f z er os v l a v ali ao d parcia l

Determine price P ric e infor m ation [Bas e price determ ined] Determine s urcharges / disc ounts Determine taxes Tax information

Customer inquiry texts Create c. texts Read c. texts Delete c. texts Modify customer text

Componente genrico chamado

EPC M acr o

Fac il da s i de O bten o de Rede de Acess o (T elefo a - pi oto) ni l

Dad d OE os a s o s ufi ie s c nte p/ alocar fac . rede Verifi ar se c ne es srio c Config o E1 ura aprov s o n i i ar red E1 e

Da dos da O E no s o s uf c ie s p/ i nte alocar a c . re f de Soluo de Pend ncia s

G IC-N

N ecess ida de de confi u a gr o de R e de de S vo er i

R ed E1 e c on urad fig a

Ac e s o s obti o d EPC M ac ro necess r o i aprov s o n i i ar red E1 e N o nec ess rio aprov s o n i i ar r ed E1 e

pos s e v l faz erv al d o i a parc ia l Pend ncia resolv d a i

No poss el fa er v z v al da o i par ia c l

Preparao do Centro Local (piloto)

C i ur r C CR -R NT onf g a RTD C Verifi ar se c Si tem a s hou e em s so v i por t de e de OTS pa ra Su Telef ni o a o aces s o

Centr de o c i ent n l e o ex t r o r e i

i ar C onf g a E1 Aprov s ion i ur o R ed E1 e

G C -N I E PC M ro ac

Ac ei ar t Or d Ent y er r ( n tegr l o i a u parc a lm en ) i te Or d Ent y er r ac ei a ( n t gra t i e l ou p a lm e arc i nte)

GIC -N

Es o r n t en t ar i s no OKpara c orr o e

GIC- N

Estornar O rder E ntry par c or e a r o

Centr de o C o urar nfig C onf g. d R e i e de r ed e n I tern io l n tern io l ac na i ac na R ed e n tern io l i ac na c onfi ur d g aa

nfig Config o E1 C o urar ura R ed E1 e Centr o Loca l C L da pla rm a tafo Confi ura g o de Rede d e Serv io (Telef ni ) o a Dados d a OE s o s ufi ie c ntesp/ prep. do CL

Com po nte ne genri o c c ham do a V f ic a s e er i r dad da OE so os s ufi ie c ntes p/ pr e a d CL par o o

C orre da o O rder E ntry ( rea de M ercado) EPC M ro ac

Houve em ss o i de O TSpa a r o acess o

No h v e ou e is s de m o OTS para o ac ess o

R ed E1 e c onfi ur d g aa

Pr ice infor mation [c om pleted]

Convey export chec k

Dad d os a O E n s o o s uf c e nt s p/ i i e prep do CL . Solu o de Pend c ia n s

Delete c. inquiry pos. Modify c. request po s.

Super vise customer order

Velocidade acima de 2 M e existe extenso de servio

EPC M ro ac

Velocidade abaixo de 2 M

C onf g i ura de o Fu o na de nc i lida s de Se i o rv (T elefon - pil to) a i o

Pend c ia n resolv d a i

Centro Local

V f ic a s e h er i r necess id e de ad ex te nso d e s erv o i

Teste Preliminar (piloto)

N o exis te necess id e de ad e te x ns o de serv o i C entr o Loc a l

Ex is t e nec ess d ad de i e ex te nso de ser v o i Coorde nar ex e u d c o a ex t n o no es s outro C L s s C on exo f ic a p/ s ex te nso d e s erv . realizad a

Customer inquiry [texts determ ined]

Customer inquiry positions Article Date

One customer inquiry position

00001001 11001000 10101010 ... 11010100

00001001 11001000 10101010 ... 11010100

Concluso do teste preliminar registrado

Pr o gram a o e Despac h o (AT)

C ent o r L a oc l

Ex ecutar c on para ex es o c ircuit o Testar fia e es ex t n e es s R egi trar s c onclu o s da pre para o d C e r o Lo a o nt c l Verif c ar i v elo ida c de e ex te nso de serv o i Sis t m a e Suport e Serv io

Pr epa o do ra C ent o Loc a r l (pil to) o Veloc d i ade ac m a de 2 M e i ex s te ex t nso i e de serv o i

C ent o r L a oc l

C ent o r L a oc l

Agend c om o ar c lient d p e ata / realizao d o tes t pr lim e e inar Veloc d a i de ac m a de 2 M e i ex s te ex t ns o i e de s erv o i T te es Prelim inar (pil to) o

Request item

1 Check price

Configurao de Funcionalidades de Servio (Telefonia - piloto)

Veloc d i ade ab o aix de 2 M

One customer Check production costs 1:1 inquiry Product position 1:2 Check decreases and increases Conditions

Customer Delivery date Delivery place Quantity Unit Organization

EPC M ac ro

Tes t e Preli n ar mi ( pi ot ) l o Conc u so l do te t se preli n ar mi r egi tr do s a

Prepa do ra o C ent o Loc a r l ( p o) ilot Velocid ade ac im d 2 M e a e ex is t ex te e nso de serv o i

Problem s a durant o e age am e o nd nt c om o c lie e nt Pr o gram a o e Despac h o (AT) Tc ni o de c C am po Terc eiri a z da

Agend e am nto c / c i ent p l e / r eal z . d teste i o pr el m i inar OK Ac o na Tc n i r ico de C a po o m u terc eirizad p a / v s ita ao c li nte i e Solic t ar t s te i e c ont n ad i uid e c om Cent o r Loca l Reali ar z tes e t preli inar m

EP M ro C ac

N ecess ida de de config o ura de fun o nal d es ci i ad de s erv o i

Tc ni o de c C am po Confi ura g o PAA Verifi ar c ex is t a nc i de a nc io n

Terc eiri a z da

EPC M ac ro

RI configurada

No existem facilidades de RI

C onf g a i ur o de Rede d e Serv io (T elefo a - pi oto) ni l

No e is t x e Ann io c / n I tercepta o do ti o PAA p Confi u a gr o PAA

Ex is t An o e nc i / Interc e ptao do ti o PAA p C onf g a i ur r pl taf r m a o a de a nncio / intercepta o

Pend a s nc i no te t se prelim inar

Tes te prelim inar re alizad c om o s uc ess o Pr og ram ao R egistrar e D espa h c o c on lu do c s o (AT) teste pr li inar em

Com po nte ne Tel foni e a Sat lit e cham o ad

No h v e ou em s d is o e O TS p a ar o ac e s o s

GIC- N

R ed e int r n o na e ac i l c onfig a da ur

Age ndarte te s i f m a-fi m

Soluo de P endn a s ci

C on lu o c s do t s t e e prelim inar regis t ad r o

1:3 Check value-added tax

Tes te fim a f m - -i age ndad o Verifi ar a c fam a do li s erv io que s er t s ta e do S tem is a S upor t e Serv io

Pend c ia n r esolvid a CC R- RI Verifi ar c e is t a de x nc i a i f c il dad RI es E PC M ro ac

Problem as no a nd ent ge am o do t s t e e fi -a-fim m

Tax item

Ex s tem i a i f c il dad es de RI

N o ex s tem i a i f c il dad es de RI CC R Intern io l ac na

C C R-RI

Chamar componente TelefoniaSatlite Componente TelefoniaSatlite chamado Concluso Tcnica (Telefonia e Satlite - piloto)

C on urar fig RI

Serv io qu e s er tes a t do d fam i a a l Telef ni o a C C R-R N T Ex ecutar t s t e e fim f m de -a- i Telef ni o a

S v o qu er i e s er testa do da fam a li Sat li e t As s is t n a ci Tc ni a c Ex ecutar e s e t t i f m a-fi de m Sat li e t

Sistema Suporte de Telefonia

RI c onf g i urad a

Problem s a na real z a i o do tes t e i f m a-fi m EPC M a r o c GIC- N Sol o d u e Pend nc a is

Tes te fim f m -a- i reali a z do c om s u e so c s At v ar i e t c nicam e ent o s er io v At v a i o tc nica d c ir uit o c o conc u d l a

Create c. request pos. Analyze c. inquiry pos. Read c. request pos. Delete c. inquiry pos. Modify c. request pos.

00001001 11001000 10101010 ... 11010100

00001001 11001000 10101010 ... 11010100

Pend c ia n resolv d a i

Processo Central (chama os processos componentizados)

Banco de Dados de Processos Componentizados

Conjunto de Modelos da UML

Figura 18: Componentes de Processos e de Sistemas Fonte: CAMEIRA (2003)

Uma outra discusso atual que vem ocorrendo sobre processos de negcio a respeito da criao de novas arquiteturas de sistemas que possibilitem a definio, implementao e gerenciamento dos processos nas empresas ocorra de forma mais flexvel. Dado que processos so suportados por sistemas e a construo destes foi historicamente orientada funcionalmente, a questo como fazer para que os sistemas retratem, em sua arquitetura, uma viso por processos. Um exemplo interessante que pode ser citado so os sistemas ERP que apesar proporcionarem a integrao do fluxo de informao transversal organizao, possibilitando que a organizao se oriente para processos, eles no permitem que estes mesmos processos sejam alterados e gerenciados com facilidade. Dessa forma, muitas vezes as organizaes acabam ficando "engessadas" tendo que se adaptar aos sistemas de informao, limitando qualquer implantao de inovao em termos de processos de negcio. 51

Essa discusso gira em torno do que foi considerado por SMITH e FINGAR (2003) como a terceira onda do Business Process Management (BPM)6, onde os processos de negcio so o foco principal para o desenvolvimento de sistemas de informao tendo influncia direta nas arquiteturas dos sistemas. Os autores afirmam que os novos sistemas criados a partir dessa nova onda, teriam suas arquiteturas centradas em processos e poderiam ser totalmente desenvolvidos sem precisar dos processos de desenvolvimento de software tradicionais inerentes a Engenharia de Software. Analisado os principais desdobramentos da EPN o prximo tpico vai mostrar os principais ganhos gerados pela utilizao da EPN.

3.6

Ganhos Gerais Esperados com a EPN

A EPN em suas diversas aplicaes pode gerar alguns ganhos importantes para

as organizaes, conforme citado nos tpicos a seguir (SANTOS, 2003). 3.6.1 Uniformizao de Entendimentos sobre a Forma de Trabalho A modelagem de processos, idealmente realizada com uma mesma ferramenta e notao, pode proporcionar para uma organizao, atravs da viso por processos, a difuso das relaes de trabalho entre as diversas unidades organizacionais que passam a entender melhor e a ter uma viso homognea do negcio. 3.6.2 Melhoria do Fluxo de Informaes Considerando-se que um dos principais objetivos da modelagem de processos a identificao do fluxo de informaes que corta uma organizao, fica clara a importncia da viso por processos possibilitada e suportada pela TI na automatizao desse fluxo e no melhor entendimento, principalmente, das informaes trocadas nas interfaces organizacionais.

As duas primeiras ondas foram respectivamente a Administrao Cientfica e a Reengenharia de

Processos.

52

3.6.3 Padronizao dos Processos Este ganho est diretamente relacionado uniformizao do entendimento da forma de trabalho, pois, diante de um referencial de conformidade com uma mesma linguagem de modelagem (modelos com uma mesma notao) compreendida por todos, fica mais fcil definir um padro de modelagem e representao dos processos de negcio. 3.6.4 Melhoria da Gesto Organizacional A associao dos processos modelados com indicadores de desempenho locais e globais proporciona melhorias na gesto organizacional em termos de monitoramento, controle e coordenao do trabalho, entre outras. 3.6.5 Reduo de Tempo e Custos dos Processos A modelagem de processos proporciona a oportunidade de identificao e melhoria de problemas relacionados ao seqenciamento das atividades, alocao de recursos, atividades que no agregam valor ao produto final, entre outros que esto diretamente relacionados reduo de tempo e custos operacionais. 3.6.6 Aumento da Conceituao Organizacional sobre Processos Este ganho est relacionado diretamente a todos os demais ganhos, pois, uma premissa bsica para a consolidao e alavancagem da viso por processos dentro da organizao que passa a trabalhar orientada total ou parcialmente a processos.

3.7

Consideraes Finais
Este captulo procurou mostrar os principais conceitos, metodologias,

ferramentas, aplicaes e ganhos da Engenharia de Processos de Negcio. Dentre os principais conceitos apresentados a captulo procurou focar no entendimento e importncia da utilizao da viso por processos e da tecnologia da informao para a modelagem de um negcio. Dentre as aplicaes da EPN, foi dado destaque ao desdobramento para desenvolvimento de sistemas de informao, ressaltando a importncia da integrao e 53

do alinhamento entre a estratgia concebida para um negcio, seus processos e os sistemas que o suportam. Para entender melhor a relao entre a EPN e sistemas de informao, ser descrito no prximo captulo os conceitos e modelos associados a Unified Modeling Language (UML), considerada pela Object Management Group (OMG) como linguagem padro de desenvolvimento de sistemas de software.

54

UNIFIED MODELING LANGUAGE (UML)

Este captulo tem com principal objetivo apresentar o histrico e descrever as principais caractersticas e conceitos atrelados a Unified Modeling Language (UML), mostrando seus principais modelos e os papis destes dentro de um processo de modelagem orientado para o desenvolvimento de sistemas de software.

4.1

Definio e Histrico da UML

A UML uma linguagem para especificar, visualizar, construir, e documentar

artefatos (documentos) de sistemas de softwares, bem como para modelagem de negcio e outros sistemas que no so softwares. Ela representa uma coleo das melhores prticas de engenharia que tem sido aprovadas com sucesso na modelagem de sistemas complexos e de grande escala (OMG Unified Modeling Language Specification, 2003). A definio acima talvez seja a definio mais completa sobre a UML. Porm, existem outras definies de outros autores, a saber:

A UML definida como uma linguagem padro para a visualizao, especificao, construo e documentao de artefatos que fazem parte do processo de elaborao da estrutura de projetos de sistemas complexos de software (BOOCH et al., 2000).

Segundo BEZERRA (2002) a UML pode ser definida como uma linguagem de modelagem visual com um conjunto de notaes e semntica correspondente para representar visualmente uma ou mais perspectivas de um sistema.

Para LARMAN (2000) a UML uma notao para modelagem de sistemas, usando conceitos orientados a objeto.

Independente da definio possvel observar que a UML antes de tudo uma linguagem de modelagem. Em sendo uma linguagem, apresenta vocabulrio e regras 55

prprias que orientam a criao e a leitura de modelos bem formatados, porm, pelo fato de no ser um mtodo, a UML por si s no associa e no relaciona seus modelos com uma metodologia / processo de desenvolvimento de software, no indicando quais modelos devem ser criados e nem quando cri-los dentro de um projeto de desenvolvimento de software. A criao e o momento da criao dos modelos vai depender da metodologia adotada que alm da presena da UML deve tambm apresentar os principais passos do processo de desenvolvimento, indicando quais artefatos sero produzidos, quem ir produzi-los e de que maneira esses artefatos iro medir e controlar o projeto como um todo. A UML tem como principal motivao para sua criao a necessidade dentro da comunidade de desenvolvimento de softwares da existncia de uma linguagem padro que possa, atravs de uma nica semntica e notao, suportar arquiteturas de diversos nveis de complexidade dentro de diversos domnios de desenvolvimento de sistemas. Diante da necessidade da existncia de uma linguagem padro e com o surgimento das tcnicas de anlise orientada a objetos na dcada de 90, surgem na primeira metade da dcada de 90 diversas propostas de tcnicas de modelagem de sistemas orientados a objeto como, por exemplo, o Mtodo Booch de Grady Booch, o Object-Oriented Software Enginneering (OOSE) de Ivar Jacobson, Object Modeling Technique (OMT) com a participao de James Rumbaugh, entre outros. Esse perodo que durou de 1889 a 1994 ficou conhecido como Guerra dos Mtodos, pois, muitas linguagens e mtodos foram desenvolvidos e muitos usurios tiveram problemas de encontrar uma linguagem que pudesse cobrir todos os aspectos relacionados ao desenvolvimento de uma arquitetura de software (FOWLER e SCOTT, 2000). Logo, percebendo essa dificuldade, os especialistas Grady Booch e Jim Rumbaugh, ambos funcionrios da empresa Rational Software, resolveram em outubro de 1994 juntar seus mtodos, j citados acima, que eram at ento considerados e reconhecidos como os principais mtodos orientados a objeto, e criaram o Mtodo Unificado apresentado comunidade de software em Outubro de 1995 na conferncia de OOPSLA 95. Alm disso, durante a conferncia, anunciaram a compra da empresa Objectory pela Rational Software e que Ivar Jacobson iria se juntar equipe. A partir desse momento, com a juno dos trs principais mtodos num esforo de estabelecer um nico, a Guerra dos Mtodos parecia ter chegado ao fim.

56

Em 1996 os trs especialistas, conhecidos tambm como os trs amigos, trabalharam seu mtodo sob o novo nome de Unified Modeling Language (UML). Porm, alguns especialistas da comunidade de metodologia orientada a objeto ainda relutavam contra a UML enquanto padro e foi necessria a criao de uma fora de trabalho conhecida como Object Management Group (OMG)7 para julgar e definir um mtodo nico orientado a objeto. Assim, em janeiro de 1997, diversas organizaes submeteram a OMG propostas para um padro de metodologias e dentre essas propostas estava a verso 1.0 da UML da Rational. Houve ainda um pequeno perodo de discusso sobre os mtodos analisados, mas logo em seguida a UML j ento na verso 1.1 foi escolhida pela OMG como linguagem padro qualquer tipo de desenvolvimento de sistema orientado a objeto. Desde ento, diversas modificaes propostas por diversos colaboradores de diversas empresas foram feitas na UML com o intuito de torn-la mais clara e til, gerando com isso a elaborao de novas verses. Atualmente, a UML j se encontra na verso 1.5 lanada em maro de 2003 e sua especificao pode ser obtida gratuitamente no site da OMG (www.omg.org).

4.2

Principais Conceitos Bsicos da Orientao a Objeto Viso Geral

Como foi possvel observar acima, a UML tem como principal base para seu

desenvolvimento orientao a objeto e, por isso, antes de falar sobre a linguagem UML cabe ressaltar, de forma breve, as principais caractersticas da orientao a objeto. 4.2.1 O Paradigma da Orientao a Objeto A orientao a objeto tem sido foco de discusso dentro do meio de desenvolvimento de sistemas desde a dcada de 80 quando os objetos comearam a sair dos laboratrios de pesquisa e comearam a se concretizar no mercado sob a forma de linguagem de programao como, por exemplo, a Smalltalk uma das linguagens pioneiras no mundo dos objetos. A idia de se criar um sistema com a tecnologia de objeto teve alguns pensadores dentre os quais pode-se citar Alan Kay, um dos pais do paradigma da

O OMG um consrcio internacional de empresas que define e ratifica padres na rea da

orientao a objeto (www.omg.org).

57

orientao a objeto, que vislumbrou, atravs da chamada analogia biolgica, o funcionamento de um sistema semelhante ao funcionamento de um ser vivo. Nesse sistema, cada clula cada clula, em sendo uma unidade autnoma, interagiria com outras clulas atravs de mensagens com o intuito de realizar um determinado objetivo. Atravs dessa analogia, Alan Kay conseguiu estabelecer alguns princpios da orientao a objeto, a saber, (BEZERRA, 2002):

Qualquer coisa um objeto; Objetos realizam tarefas atravs da requisio de servios a outros objetos; Cada objeto pertence a uma determinada classe que, por sua vez, agrupa objetos similares; Classe um repositrio para comportamento associado ao objeto; Classes so organizadas em hierarquia.

Esses princpios podem ser observados no comportamento humano como, por exemplo, no processo de entrega em domiclio de um remdio. Nesse processo, um cliente, Leonardo, liga para a farmcia, faz seu pedido e fala o endereo de entrega. Em seguida, o atendente, Joo, anota o pedido, separa o produto e entrega-o a Marcos, o entregador. Finalmente, o produto chega s mos do cliente pelo entregador. Nesse pequeno processo possvel observar que h diversos objetos (Leonardo, Joo, Marcos) que colaboram entre si para que o objetivo final seja alcanado. Ou seja, at o momento pode-se confirmar os dois primeiros princpios listados acima. Alm disso, o comportamento esperado pelo Marcos o mesmo de qualquer outro entregador, confirmando o terceiro princpio de que Marcos em sendo considerado um objeto pertence classe entregador. O comportamento esperado de qualquer entregador, incluindo Marcos, o de entregar o produto no endereo especificado, confirmando-se o quarto princpio. Por fim, Joo, o atendente, um tipo de animal, que tambm mamfero, ser humano, etc., confirmando o ltimo princpio. Pode-se perceber, atravs do exemplo acima, que o paradigma da orientao a objeto apresenta uma conexo com o mundo real onde existe um elemento qualquer (pessoa, produto, animal, etc.), denominado de objeto, que considerado uma entidade autnoma que contem seus prprios dados que so manipulados atravs dos processos

58

definidos para prprio objeto que, por sua vez, interage, atravs de mensagens, com outros objetos para alcanarem um objetivo comum. A partir dessa analogia com o mundo real, pode-se dizer que a tecnologia de objetos permite a criao de um sistema de software com uma coleo de objetos, onde cada objeto tem tarefas especficas para realizar e que atravs da interao e da troca de mensagens entre esses objetos que se realiza uma tarefa de mbito maior onde todos contribuem para sua execuo. A seguir sero colocados, de forma breve, alguns dos principais conceitos da orientao a objeto. 4.2.2 Objeto e Classe Para AMBLER (1998) um objeto pode ser definido como qualquer indivduo, lugar, evento, coisa, tela, relatrio ou conceito que possa ser aplicado a um sistema. Para o mesmo autor, uma classe uma categoria de objetos semelhantes e caracteriza-se como uma planta baixa a partir da qual os objetos so criados. Segundo BEZERRA (2002) um objeto pode ser representado por qualquer coisa do mundo real como, por exemplo, um cliente, uma venda, um pedido de compra, um fornecedor, etc. O mesmo autor considera que na terminologia da orientao a objeto uma idia que forma na mente humana como, por exemplo, a idia cavalo, pode ser denominada de classe de objetos ou simplesmente classe. Os objetos da idia cavalo seriam cavalos com caractersticas diferentes como raa, altura, etc. Para FURLAN (1998) um objeto uma ocorrncia ou instncia especfica de uma classe e um elemento do mundo real. Uma classe para o autor pode ser definida como um agrupamento de objetos similares que apresentam os mesmos atributos e operaes. Os atributos de um objeto definem os dados de um objeto, enquanto que as operaes definem as funcionalidades de um objeto determinando e que ele faz. Com as definies acima, pode-se perceber que uma classe pode ser encarada como uma abstrao das caractersticas de um conjunto de elementos (objetos) do mundo real. Num projeto de desenvolvimento de sistemas, uma classe, deve representar uma abstrao de apenas caractersticas relevantes do mundo real que venham a se enquadrar dentro do escopo do projeto.

59

4.2.3 Mensagem Um outro conceito importante dentro da orientao ao objeto o conceito de mensagem. Para que cada objeto execute suas operaes necessrio que este receba um estmulo atravs de uma mensagem enviada por um outro objeto. A lgica funciona como o funcionamento de uma indstria de manufatura, onde o cho de fbrica recebe uma ordem de produo (mensagem enviada, por exemplo, pelo PCP), utiliza matria prima (atributos), processa a ordem (operaes) e entrega o produto final (mensagem de concluso da ordem de produo). Em termos de desenvolvimento de sistemas orientados a objeto, os objetos trocam mensagens entre si para realizarem alguma tarefa no sistema no qual esto inseridos. 4.2.4 Encapsulamento Partindo-se do pressuposto de que classes e objetos realizam operaes e, por tanto, possuem um comportamento, pode-se dizer que o encapsulamento restringe o acesso a esse comportamento por parte de outras classes ou objetos, mantendo-se a autonomia dos objetos. A nica coisa que um objeto deve saber com relao a outros qual a sua interface, ou seja, quais tarefas realizam e o que eles conhecem. A maneira como eles implementam sua interface, ou seja, como eles realizam tais tarefas no interessam uns aos outros. A grande vantagem de utilizar o conceito de encapsulamento a de evitar um cdigo de programao de acoplamento forte, pois, quando isso ocorre, ao se fazer uma mudana em uma parte do cdigo, pode ser necessrio reescrever demais partes do cdigo. 4.2.5 Polimorfismo O conceito de polimorfismo significa a capacidade de abstrair vrias implementaes diferentes atravs de uma nica interface, onde um objeto pode enviar uma mensagem para objetos semelhantes que implementam sua interface de diversas formas. Para melhor compreenso desse conceito, pode-se citar como exemplo o desenvolvimento de kits de soquetes para porcas (objetos). Esses soquetes (operaes)

60

apresentam diversos tamanhos cada um adequado a um tipo de porca (classe) e possuem na sua parte traseira um conector comum (mesma interface) que se acopla a uma chave de toro (objeto). A aplicao do conceito de polimorfismo est na aplicao de uma operao comum (polimrfica) que a de girar uma chave de toro acoplada a um soquete que funciona para qualquer tamanho ou classe de porca. Ou seja, atravs de uma nica interface que o conector comum, vrias porcas de diversos tamanhos ou classes diferentes de porcas podero ser apertadas ou implementadas. 4.2.6 Herana Como citado anteriormente, uma classe pode ser definida como uma abstrao de um conjunto de objetos que apresentam caractersticas e comportamentos comuns. O conceito de herana apresenta a mesma lgica de abstrao, porm aplicada entre classes, onde uma classe pode assumir o papel de classe pai ou superclasse e dar origem a uma classe filho ou subclasse, estabelecendo-se uma hierarquia de classes. Ao ser criada, a subclasse herda todas as propriedades e comportamentos da superclasse evitando-se replicar trechos do cdigo de programao. 4.2.7 Acoplamento e Coeso Para AMBLER (1998), esses dois conceitos talvez sejam os conceitos mais importantes dentro da orientao a objeto, pois, para desenvolver um sistema com um baixo custo e com uma manuteno simples, importante que sejam desenvolvidas classes com baixo acoplamento e alta coeso. O conceito de acoplamento est diretamente relacionado ao quanto s classes esto interconectadas referindo-se ao quanto uma classe conhece da outra. Tal conceito est diretamente relacionado com o conceito de encapsulamento que delimita esse nvel de conhecimento entre classes e objetos. O conceito de coeso mede o quanto uma classe e suas operaes fazem sentido. O principal objetivo maximizar a coeso para assegurar um agrupamento consistente de operaes na classe, evitando-se dessa forma maiores esforos com manuteno do cdigo de programao.

61

4.3

Objetivos da UML
Como pode ser observado em OMG Unified Modeling Language Specification

(2003), os principais objetivos da UML so:

Fornecer aos usurios uma linguagem de modelagem expressiva que ajude no desenvolvimento e na troca de modelos significativos:

importante que o padro de Anlise e Projeto Orientado a Objeto suporte uma linguagem de modelagem que possa fornecer aos usurios um conjunto de conceitos de modelagem que so aceitos por muito mtodos e ferramentas de modelagens. Tais conceitos so necessrios em muitos projetos de diversas reas de desenvolvimento e aplicao de sistemas sendo, portanto, bem suportados por uma linguagem padro como a UML.

Oferecer mecanismos de extenso e especializao dos principais conceitos:

A filosofia da OMG com relao a UML est relacionada ao constante desenvolvimento da linguagem atravs da anlise de novas necessidades e de novos domnios de aplicao que venham a surgir, porm sempre com a preocupao de no redefinir os principais conceitos para cada situao nova que aparece, mantendo a UML dentro de um mesmo padro. Em sendo necessrio tratar uma nova situao no contemplada pelos principais conceitos da linguagem, a UML dispe de mecanismos de extenso que possam suportar excees, sem ter que mudar os conceitos principais. Dessa forma, os usurios da UML devem poder criar modelos usando os principais conceitos sem ter que utilizar os mecanismos de extenso para aplicaes normais, podem criar novos conceitos e notaes para atender situaes no contempladas pelos conceitos principais e devem poder especializar conceitos, notaes e restries para um domnio de aplicao particular.

62

Suportar especificaes que sejam independentes de qualquer linguagem de programao e processo de desenvolvimento:

A UML pode suportar qualquer linguagem de programao razovel e vrios mtodos e processos de desenvolvimento e construo de modelos sem muita dificuldade.

Fornecer uma base formal para entendimento da linguagem de modelagem: A UML fornece atravs da utilizao de um metamodelo8 expressado por diagramas de classes (um dos diagramas que compem a UML) uma definio formal do formato esttico de um modelo, ajudando ao usurio na definio e criao de um modelo bem formado e sintaticamente correto. Esse metamodelo serve como referncia de modelagem e ponto de partida para que os usurios da UML compreendam suas notaes.

Estimular o crescimento do mercado de ferramentas voltadas para orientao a objeto:

Atravs a existncia de uma linguagem de modelagem padro, os fornecedores de softwares de modelagem passam a ter que desenvolver ferramentas que suportem os modelos da UML, permitindo a troca desses modelos entre usurios sem a perda de informaes. Logo, isso tambm leva a uma padronizao e uma maior interoperabilidade entre as diversas ferramentas do mercado.

Metamodelo pode ser definido como um diagrama que define a notao de uma linguagem. (Fowler

e Scoot, 2000).

63

Suportar conceitos de desenvolvimento de alto nvel como componentes, colaboraes, frameworks e padres:

A possibilidade de suportar esses conceitos faz com que a UML possa obter um melhor aproveitamento dos benefcios do desenvolvimento orientado a objeto e do reuso de prticas, modelos, cdigos e arquiteturas comuns de projeto.

Integrar a melhores prticas:

A principal motivao para o desenvolvimento da UML tem sido integrar as melhores prticas de modelagem do mercado, englobando uma grande variedade de vistas baseadas em diferentes nveis de agregao, domnios de aplicao, arquiteturas, tecnologias de implementao, entre outros fatores que fazem da UML uma linguagem que passa a ser vista como uma integrao das melhores prticas.

4.4

Conceitos Bsicos da UML

Definidos os principais objetivos da UML, importante entender que para

compreend-la necessrio conhecer o modelo conceitual da linguagem que tem como base trs elementos principais: os blocos de construo bsicos, as regras que determinam como tais blocos podem ser combinados e, por fim, alguns mecanismos comuns aplicados na UML. Com a compreenso desses elementos, a leitura da notao e a criao dos modelos que formam a linguagem tornam-se mais fceis. Para uma melhor compreenso da linguagem, esses trs elementos sero, resumidamente, explicados abaixo. 4.4.1 Blocos de Construo Existem trs tipos de blocos de construo que so os itens, que so abstraes identificadas como cidados de primeira classe de um modelo, os relacionamentos, que renem os itens e, por fim, os diagramas que agrupam colees de itens. Dentro dos itens, ainda existe uma subdiviso sendo estes classificados em itens estruturais (classes, interfaces, colaboraes, casos de uso, classes ativas, componentes e ns) que so as partes mais estticas do modelo, os itens comportamentais (interaes 64

e mquinas de estado) que so as partes dinmicas dos modelos e representam o comportamento dos modelos no tempo e no espao, os itens de agrupamento (pacotes) que so as partes organizacionais dos modelos da UML caracterizando blocos em que os modelos podem ser decompostos e, por fim, os itens anotacionais (nota) que so partes explicativas dos modelos caracterizando-se por comentrios para descrever, esclarecer e fazer observaes sobre qualquer elemento do modelo. Como no caso dos itens, tambm existe uma subdiviso dos tipos de relacionamentos que podem existir entre os itens. O primeiro deles a dependncia que se caracteriza com um relacionamento semntico entre dois itens, nos quais a alterao do item independente pode alterar o item dependente. O segundo tipo a associao que um relacionamento estrutural que descreve um conjunto de conexes entre objetos como, por exemplo, a agregao que um tipo de relacionamento entre o todo e suas partes. O terceiro tipo a generalizao que um relacionamento de especializao / generalizao nos quais nos os filhos (objetos dos elementos especializados) so substituveis por objetos pais (objetos do elemento generalizado). O quarto e ltimo tipo a realizao que um relacionamento semntico em que um classificador especifica um contrato9 que o outro classificador garante executar, podendo ser encontrado entre interfaces e classes ou componentes que as realizam ou entre casos de uso e as colaboraes que as realizam. Por fim, como terceiro e ltimo elemento dos blocos de construo tem-se os diagramas da UML que so a representao grfica de um conjunto de itens e relacionamentos e permitem a visualizao de um sistema sob diferentes perspectivas que devem estar consistentes com as cinco vistas da arquitetura de um sistema complexo de software, a saber: vista de caso de uso, vista de projeto, vista de processo, vista de implementao e vista de implantao. De acordo com essas vises, a UML inclui nove diagramas: diagrama de classes, de objetos, de casos de uso, de seqncias, de colaboraes, de grfico de estados, de atividades, de componentes e de implantao.

Um contrato pode ser definido como um documento que descreve o que uma operao se

compromete a atingir, definindo o que deve ser feito pela operao e no o como. Normalmente so expressos por mudanas de estado definidas por pr-condies e ps-condies (LARMAN, C., 2000).

65

Os diagramas citados sero mais bem detalhados mais adiante mostrando seus papis dentro do processo de desenvolvimento de um sistema e suas respectivas notaes. Alm disso, a arquitetura tambm citada acima ser mais detalhada mostrando o relacionamento das vistas com os diagramas. 4.4.2 Regras da UML Os blocos de construo citados anteriormente no podem ser aleatoriamente combinados sem que haja regras para facilitar a elaborao de modelos bem formados semanticamente consistente. Para tal, a UML dispe de regras semnticas para nomes (quais nomes podem ser atribudos a coisas), escopo (o contexto que determina um significado especfico para um nome), visibilidade (como os nomes podem ser vistos e utilizados pelos outros), integridade (como os itens se relacionam de forma integrada e consistente) e execuo (o que significa executar ou simular um modelo dinmico). 4.4.3 Mecanismos da UML Dentro da UML existem quatro mecanismos bsicos que ajudam na compreenso e simplificao da linguagem:

Especificaes Para cada notao grfica da linguagem existe uma especificao capaz de oferecer uma declarao textual da sintaxe e da semntica do bloco de construo em questo. Como exemplo, pode-se citar o item estrutural classe que visualmente pode apresentar apenas parte de sua especificao que engloba a descrio de um conjunto completo de atributos, operaes e comportamentos da classe.

Adornos Um adorno pode ser considerado um tipo de especificao que ajuda a representar, atravs de textos ou grficos, muitos detalhes da respectiva notao. Como exemplo, pode-se citar para o caso do item estrutural classe o sinal + que ao ser colocado na frente de uma operao indica que esta operao pblica e pode ser visualizada por outros objetos.

Divises comuns Dentro da modelagem orientada a objeto existem 66

basicamente duas formas de diviso, sendo a primeira relacionada com as classes e objetos onde uma classe uma abstrao e um objeto uma manifestao concreta dessa abstrao e a segunda relacionada com a separao entre interface e implementao onde uma interface representa um contrato e a implementao representa a realizao completa desse contrato.

Mecanismos de extenso Os mecanismos de extenso existem para oferecer certa flexibilidade a UML com o intuito de expressar todas as situaes no contempladas pelos principais conceitos da linguagem. Existem trs tipos de mecanismos: esteretipos, valores atribudos e restries. Com o primeiro, o vocabulrio da UML pode ser ampliado com a criao de novos blocos de construo derivados dos j existentes. Com o segundo, podem ser criadas novas informaes na especificao de um bloco de construo e, por fim, com o terceiro mecanismo possvel ampliar as semnticas dos blocos de construo, permitindo a incluso de novas regras ou modificar as j existentes. Cabe ressaltar que esses mecanismos devem ser usados de maneira controlada para que a linguagem no seja descaracterizada a ponto de comprometer o seu principal objetivo de comunicao.

4.5

Arquitetura da UML
Conforme definido anteriormente, a UML tem como principais objetivos a

visualizao, a especificao, a construo e a documentao de sistemas complexos de softwares. Para executar essas tarefas, a equipe (usurios do sistema, analistas, programadores, gerentes de projetos, etc.) envolvida no projeto de desenvolvimento deve visualizar o sistema sob diversas perspectivas para melhor entendimento, gesto e controle do projeto. Diante da necessidade de se visualizar um sistema sob vrias perspectivas, considerando aspectos relacionados estrutura, ao comportamento, funcionalidade, flexibilidade, reutilizao, ao desempenho, entre outros, os autores da UML sugeriram a subdiviso de uma arquitetura de um sistema em cinco vistas (BOOCH et al., 2000). Conforme pode ser observado na figura abaixo e no texto abaixo, cada vista tem um foco em determinado aspecto do sistema, mas todas elas esto interligadas de alguma forma:

67

Vista de Projeto

Vista da Implementao

Vista de Caso de Uso Vista do Processo Vista da Implantao

Figura 19 Arquitetura de um sistema Fonte: O autor, adaptada de BOOCH et al. (2000. p. 33)

4.5.1 Vista de Caso de Uso Essa vista descreve o sistema do ponto de vista de um agente externo ao sistema, ou seja, descreve comportamento do sistema sob o ponto de vista de seus usurios finais. Portanto, esta vista est diretamente relacionada com o levantamento de requisitos de negcios que devero ser implementados pelo sistema, sendo criada inicialmente e servindo como base de direcionamento para a criao das demais vistas. Dentro da UML, modelos que esto relacionados so os diagramas de casos de uso que capturam o aspecto esttico do sistema e os modelos que representam os aspectos dinmicos do sistema como os diagramas de interao, diagramas de grficos de estado e diagramas de atividades. 4.5.2 Vista de Projeto Nessa vista dado nfase aos aspectos que do suporte estrutural e comportamental s funcionalidades do sistema, ou seja, os servios que o sistema dever fornecer aos seus usurios finais. Essas funcionalidades devem ser validadas e estar de acordo com os requisitos de negcio definidos na vista de caso de uso. Na UML, os principais modelos que constituem essa vista so os diagramas de classes e objetos que esto relacionados aos aspectos estticos do sistema. Para representar os aspectos dinmicos do sistema podem-se citar os mesmos diagramas da vista de casos de uso.

68

4.5.3 Vista de Processo Essa vista est relacionada aos processos que formam os mecanismos de concorrncia (paralelismo) e sincronizao do sistema, cuidando dos aspectos relacionados ao desempenho do sistema. Nesse caso, os aspectos estticos e dinmicos so capturados pelos mesmos modelos da vista de projeto, porm com nfase nas classes ativas10 que representam esses processos. 4.5.4 Vista de Implementao Est relacionada gesto da configurao das verses do sistema, composta por componentes e arquivos responsveis pela montagem do sistema fsico. Os aspectos estticos dessa viso podem ser capturados pelos diagramas de componentes e os dinmicos pelos mesmos modelos j citados anteriormente em outras vistas. 4.5.5 Vista de Implantao Corresponde distribuio fsica do sistema abrangendo os ns que formam a topologia de hardware em que o sistema executado. Com a UML, os aspectos estticos do sistema so capturados em diagramas de implantao e os dinmicos pelos mesmos modelos j citados anteriormente em outras vistas. Apesar da possibilidade de serem tratadas isoladamente de acordo com o aspecto do sistema que mais interessar, importante destacar que dependendo da complexidade do projeto nem todas as vistas precisam ser construdas e que as vistas apresentam interaes entre elas. Como exemplo, podem-se citar os ns da vista de implantao que possuem componentes da vista de implementao que nada mais so do que a realizao fsica de classes, interfaces e colaboraes originadas pelas vistas de projeto, processo e caso de uso.

4.6

Modelos da UML - Viso Geral

A arquitetura e as vistas que compem um sistema de software, descritos no

tpico anterior, esto relacionados diretamente a uma srie de documentos textuais ou

10

Classes ativas so classes que possuem objetos ativos que representam processos capazes de iniciar

atividades de controle.

69

grficos que auxiliam na construo do sistema. Assim, qualquer processo de desenvolvimento de um sistema que venha a utilizar a UML como linguagem de modelagem gera diversos tipos de documentos que como visto anteriormente costumam ser chamados de artefatos de software ou simplesmente artefatos. Logo, o objetivo principal deste tpico apresentar uma viso geral dos artefatos grficos da UML, ou seja, dos diagramas que podem ser produzidos num processo de desenvolvimento de um sistema e suas principais notaes. Na figura abaixo possvel visualizar os tipos de diagramas da UML.
Diagramas da UML

Diagramas de Interao

Diagramas de Casos de Uso

Diagramas de Objetos

Diagramas de Grficos de Estado

Diagramas de Implementao

Diagramas de Sequncia

Diagramas de Colaborao

Diagramas de Classes

Diagramas de Atividades

Diagramas Diagramas de de Componentes Implantao

Figura 20 Diagramas da UML Fonte: O autor

4.6.1 Diagramas de Casos de Uso Esse diagrama da UML teve origem a partir da metodologia OOSE, proposta por Jacobson, com o intuito de documentar e formalizar os requisitos de sistema, que at ento se encontravam apenas nas cabeas dos especialistas do negcio e dos analistas de sistema envolvidos com o planejamento do projeto. De uma maneira geral, pode-se dizer que um caso de uso um conjunto de cenrios que descrevem interaes entre usurios (atores) e sistemas. Tais cenrios representam diversas situaes vivenciadas pelos usurios do sistema, incluindo caminhos alternativos para soluo de erros e imprevistos que venham a aparecer no meio do processo de interao. Normalmente, um caso de uso descrito textualmente podendo apresentar um formato bsico que inclui pr e ps-condies que determina como, por exemplo, um sistema deve estar antes e depois da realizao do caso de uso, inclui tambm um fluxo normal de eventos que descreve os principais passos para a realizao de um caso de

70

uso e, por fim, os fluxos de caminhos alternativos que ocorrem com menos freqncia incluindo situaes incomuns que possam acontecer dentro de um caso de uso (SCHNEIDER, WINTERS, 1998; KULAK, GUINEY, 2000). Este diagrama apresenta basicamente quatro objetos que o constroem. O primeiro objeto seria o caso de uso que representado por uma elipse contendo o seu nome no interior ou abaixo da elipse. O segundo objeto o ator que representado por um stick man e significa um papel exercido por um usurio ou at mesmo por um outro sistema com relao ao sistema que se pretende desenvolver. O terceiro objeto o relacionamento entre casos de uso, entre atores e entre casos de uso e atores que podem ser de:

Comunicao - indica que um ator est relacionado a um determinado caso de uso, significando que esse ator interage com o sistema. Este relacionamento representado no diagrama por uma linha reta que liga o ator ao caso de uso.

Incluso indica que um determinado caso de uso apresenta uma seqncia de interaes que pode ser reutilizada por demais casos de uso. Logo, para evitar repetio esse tipo de relacionamento pode ser utilizado. Este relacionamento representado no diagrama por uma seta pontilhada entre os casos de uso com o esteretipo inclui.

Extenso ocorre quando um comportamento opcional de um caso de uso tem que ser descrito. Assim, quando existe um relacionamento de extenso de um caso de uso A para um caso de uso B, uma instncia de B pode incluir o comportamento especificado por A. Este relacionamento representado no diagrama por uma seta pontilhada entre os casos de uso com o esteretipo estende.

Generalizao uma generalizao de um caso de uso (ou de um ator) A para um caso de uso (ou um ator) B indica que A uma especializao de B, ou seja, A herda todas as caractersticas de B, tendo-se que se definir apenas as caractersticas de especializao de A. Este relacionamento representado por

71

uma seta cheia que liga os casos de uso ou atores envolvidos.

Por fim, o ltimo objeto, que pode ser opcional, um retngulo que envolve apenas os casos de uso mantendo de fora os atores e representando a fronteira entre interior e o exterior do sistema. A figura abaixo mostra alguns diagramas de caso de uso e seus principais elementos:
Sistema de Caixa Eletrnico Realizar Saque <<inclui>>

Fornecer Identif icao Cliente Obter Extrato

<<inclui>>

Realizar Pagamento Cliente <<generaliza>> Realizar Pagamento em Dinheiro Cliente

Realizar Pedido

<<estende>> Requisitar Catlogo do Pedido

Figura 21: Diagramas de Casos de Uso Fonte: O autor

4.6.2 Diagramas de Classes Os diagramas de classes descrevem os tipos de objetos que existem dentro de um sistema, bem como seus atributos, operaes, regras e os vrios tipos de relacionamentos estticos existentes entre eles. No que se refere ao desenvolvimento dos diagramas de classes, estes podem ser criados a partir de trs perspectivas que podem ser utilizadas em conjunto ou no dependendo do processo de desenvolvimento adotado:

Conceitual Nessa perspectiva so levantados os principais conceitos que esto envolvidos no domnio que est sendo estudado e tais conceitos sero relacionados classes que iro represent-los no diagrama. No existe um 72

comprometimento com a implementao podendo ser considerado independente do software e da linguagem de programao que sero utilizados.

Especificao Nessa perspectiva o software passa a ser considerado sendo identificadas as interfaces de cada tipo de dados previsto, no considerando a implementao. importante ressaltar que os conceitos de interface e implementao so diferentes e que essa diferena chave para uma boa programao orientada a objeto que deve ser voltada para a programao de interface de classe em vez de ser voltada para implementao.

Implementao Essa a perspectiva mais utilizada e est relacionada diretamente com a codificao das classes projetadas.

importante ressaltar que tais perspectivas no so definidas formalmente na UML, mas podem ser muito valiosas nos processos de modelagem e reviso dos modelos (FOWLER, SCOTT, 2000). Conforme pode ser visto na figura abaixo, a notao definida pela UML para representar uma classe um retngulo que pode, dependo da perspectiva adotada, apresentar at trs divises delimitadas para o nome, os atributos e as operaes da classe.

Nome da Classe Atributos Operaes

Figura 22: Notao de uma classe Fonte: O autor

Com relao aos tipos de relacionamentos estticos entre as classes, pode-se classific-los em dois grupos:

73

Associao Esse tipo de relacionamento ocorre quando objetos de uma classe contm referncias ou usam servios de outras classes, ou seja, representam relaes entre instncias de classe.

Generalizao Esse tipo de relacionamento, j citado anteriormente para casos de uso, tambm existe entre classes e seus objetos. Ocorre quando um tipo de objeto do sistema generaliza um comportamento comum, ampliado ou modificado em um ou mais subtipos (classes filhos) mantendo as caractersticas de origem do supertipo (classe pai).

Ainda com relao ao tipo de relacionamento associao, existem diversos adornos que podem estar relacionados a uma associao, dos quais podem ser destacados:

Multiplicidades representam a cardinalidade dos objetos envolvidos na associao, ou seja, estabelecem o limite inferior e superior da quantidade de objetos aos quais um outro objeto pode estar associado.

Agregao significa que um determinado objeto do sistema composto por outros objetos, ou seja, uma conexo entre objetos que possuem uma relao todo-parte entre si.

Composio significa um tipo de agregao mais forte, pois, nesse caso, quando um objeto faz parte do outro, esse deve ser criado e removido juntamente com o objeto da qual ele faz parte.

Nome de associao, direo de leitura e papis esse trs recursos de notao definidos pela UML ajudam na compreenso do diagrama de classes. O nome da associao posicionado no meio da linha de associao, a direo de leitura representada por uma seta ao lado do nome e, por fim, os papis que as classes representam numa associao so colocados nas extremidades da linha de associao junto as suas respectivas classes.

74

Dependncia um relacionamento em que uma classe ou objeto independente e a outra classe ou objeto dependente, ou seja, uma mudana no elemento independente afeta o elemento dependente. Classes Associativas esse relacionamento permite atributos e operaes as associaes, ocorrendo quando existem atributos e operaes que no podem ser atribudas a nenhuma das classes pertencentes associao.

Todos esses relacionamentos ajudam na compreenso do domnio que est sendo estudado, mas devem ser utilizados com cautela para no comprometer o entendimento dos principais conceitos envolvidos no diagrama de classes. Na figura abaixo se pode encontrar um exemplo de um diagrama de classes com alguns desses elementos citados acima.
Pedido Cliente cdigoDoCliente limiteDeCrdito incluirPedido( ) Operaes atenderPedido( ) 1 Agregao Associao

Multiplicidade * Pedido, item quantidade Atributos Produto incluirItemPedido( ) calcularTotalPedido( ) Generalizao Superclasse

Chocolate

Subclasse

Empresa nome telefone endereo

Papel contratante

Nome da Associao Contrata

Papel contratado

Pessoa razoSocial endereo

Emprego salrio dataContratao Classe Associativa

Figura 23: Diagrama de Classes Fonte: O autor

75

4.6.3 Diagramas de Objetos Os diagramas de objetos ou diagramas de instncias podem ser vistos como instncias dos diagramas de classes da mesma forma que objetos so instncias de classes. um tipo de diagrama estrutural e esttico tendo como principal objetivo representar um comportamento de um sistema em determinado momento exibindo as interaes entre objetos conforme seus atributos e ligaes. Esse tipo de diagrama utilizado com pouca freqncia, tendo utilidade para representar e facilitar o entendimento de algum tipo de relacionamento complexo de um diagrama de classes, alm de apresentar a mesma notao utilizada nos diagramas de interao que sero visto a seguir. Com relao notao, um objeto representado, conforme pode ser observado na figura abaixo, por um retngulo com duas divises, onde na parte superior est o nome do objeto e classe a que pertence e na inferior os atributos definidos pela classe do objeto.
produto20 : Produto nome = "Caderno M" descrio = "Caderno em espiral tamanho mdio" preoUnitrio = 4,50 desconto = 15 item1: ItemPedido quantidade = 6 Pedido1:Pedido data = 13/09/2002 hora = 10:00am item2: ItemPedido quantidade = 20 produto12 : Produto nome = "Caneta ESF" descrio = "Caneta esferogrfica 5mm" preoUnitrio = 1,20 desconto = 2

item3: ItemPedido quantidade = 1

produto07 : Produto nome = "Esquadro" descrio = "Esquadro de acrlico 20cm" preoUnitrio = 2,35 desconto = 10

Figura 24: Diagrama de Objetos Fonte: BEZERRA (2002, P.129)

4.6.4 Diagramas de Interao Diagramas de interao so modelados para representar os aspectos dinmicos 76

dos sistemas, mostrando como os sistemas agem internamente para que um determinado ator alcance seu objeto atravs da realizao de um caso de uso. Para isso, tais diagramas mostram a seqncia de mensagens enviadas e recebidas pelos objetos que participam de um caso de uso. Esse tipo de diagrama representado dentro da UML pelos diagramas de seqncia que d nfase na ordem temporal das mensagens trocadas entre os objetos e pelo diagrama de colaborao que d nfase aos relacionamentos existentes entre os objetos que participam da execuo de um caso de uso. A utilizao de um, outro, ou os dois diagramas dentro de um processo de desenvolvimento depende do foco que se deseja visualizar as interaes entre os objetos, tendo sempre como principal objetivo o entendimento dessas interaes. Tais diagramas so definidos a seguir. 4.6.4.1 Diagramas de Seqncia Os principais elementos que compem um diagrama de seqncia so os atores que participam da realizao dos casos de uso que esto sendo representados e apresentam a mesma notao do diagrama de caso de uso, ou seja, um stick man; os objetos que esto envolvidos com a execuo dos casos de uso e tem a mesma notao do diagrama de objetos; as classes que eventualmente podem aparecer quando da necessidade de se enviar mensagens para elas; as linhas de vida que determinam os tempos de existncia dos objetos e so representadas por uma linha vertical pontilhada; as mensagens que so trocadas entre os objetos do diagrama sendo representadas por setas, podendo ser de quatro tipo (simples, sncrona, assncrona e de retorno); os focos de controle que so representados por retngulos posicionados sobre as linhas de vida e servem para indicar quando um objeto est recebendo ou enviando mensagens; a criao de objetos que est relacionada posio vertical dos objetos no diagrama, ou seja, os objetos que existem desde do incio da interao devem ser posicionados no topo do diagrama e os demais conforme forem sendo criados devem se posicionar mais abaixo; e, por fim, a destruio dos objetos que representada no diagrama por um X ao final dos focos de controle, indicando que os objetos no so mais necessrios na interao. A figura abaixo colabora para um melhor entendimento dos principais elementos que esto relacionados ao diagrama de seqncia.

77

Ator Objeto 1 Objeto 2 Objeto 3 Objeto 4

mensagem 0 mensagem 1 mensagem 2

Linha de vida

Foco de controle

mensagem 3

Figura 25: Diagrama de Seqncia Fonte: O autor

4.6.4.2 Diagramas de Colaborao Os diagramas de colaborao so bem semelhantes aos diagramas de objetos, tendo como principal diferena utilizao de setas e rtulos de mensagens nas ligaes entre os objetos. Assim como os diagramas de seqncia, esse tipo de diagrama busca representar as trocas de mensagens (interaes) entre os objetos que executam os casos de uso. Conforme pode ser observado na figura abaixo, os principais elementos que compem esse diagrama so os objetos ou classes cujas notaes so as mesmas que so utilizadas no diagrama de seqncia; as linhas ou ligaes entre os objetos que representam os tipos de relacionamentos (agregaes, associaes, etc.) entre os objetos; as setas que indicam as direes das mensagens sendo posicionadas prximas aos rtulos das mensagens; e, por fim, os identificadores seqenciais que, atravs de seqncias numricas, indicam a ordem de envio das mensagens.

78

Objeto : Janela de Entrada de Pedido 1: prepare() Mensagem

: Pedido

2*[para todas as linhas de pedido]:prepare() 3: tem Estoque := verificar() 4: [temEstoque] := remover() linha Macallan:Linha de Pedido Nmero de Sequncia 7:[temEstoque]:new : Item de Entrega 6:[precisaReposio]:new

estoque Macallan: Item de Estoque

: Item de Reposio

Figura 26: Diagrama de Colaborao Fonte: O autor, adaptada de FOWLER e SCOTT (2000, p.76)

4.6.5 Diagramas de Grficos de Estados O diagrama de grficos de estados tem como principal objetivo descrever o comportamento de uma determinada classe e conseqentemente de seus objetos, mostrando todos os possveis estados que os objetos podem ser assumir durante seus ciclos de vida. Neste diagrama, conforme pode ser observado na figura abaixo, cada estado representado por um retngulo com bordas arredondadas, com exceo dos estados iniciais e finais que so representados respectivamente por um crculo totalmente preenchido e por um crculo parcialmente preenchido. As transies de estados so representadas por setas podendo ser opcionalmente rotuladas por trs partes de acordo com a seguinte notao: Evento [Guarda] / Ao. A primeira parte corresponde ao evento que dispara a transio, a segunda representa a condio para que a transio ocorra ou no (condio de guarda) e, por fim, a ltima parte se refere ao realizada resultante da transio. Alm disso, os estados podem estar aninhados dentro de um superestado com o intuito de facilitar a compreenso do diagrama. Demais adornos so definidos pela UML para aplicao nesse diagrama,

79

acrescentando alguns detalhes aos estados e transies, permitindo a modelagem de estados concorrentes, onde um mesmo objeto pode apresentar um ou mais estados independentes.
Estado de Incio Nome do Superestado

Ativado
[Nem todos itens verificados] / pegar prximo item [Todos os itens verificados && todos od itens disponveis]

Verificando do / verificar item

Expedindo do / iniciar entrega

[Todos os itens verificados && alguns itens no esto em estoque] Item recebido [alguns itens no esto em estoque] Item recebido [todos os itens disponveis]

Aguardando

Cancelado

Cancelado

Entregue

Estado de Final

Figura 27: Diagrama de Grfico de Estados Fonte: O autor, adaptada de FOWLER e SCOTT (2000, p.116)

4.6.6 Diagramas de Atividades Os diagramas de atividades podem ser considerados tipo de diagrama de grficos de estados, onde os estados representados referem-se a atividades e no a objetos. Tais atividades representam o andamento e execuo das operaes e as transies caracterizam o trmino dessas operaes, ou seja, esse tipo de diagrama particularmente til para modelagem do fluxo de operaes onde h a possibilidade de processamento paralelo. Conforme pode ser observado na figura abaixo, alm dos elementos j definidos para o diagrama de grficos de estados, esse diagrama pode apresentar pontos de sincronizao, representados por barras entre as transaes, e pontos de deciso representados por losangos.

80

Estado Inicial

Receber o Pedido

Separao Atividade
Preencher o Pedido Envia a Fatura

Guarda
[pedido urgente]

Desvio
[seno]

Entrega durante a noite

Entrega Regular

Recebe o Pagamento

Intercalao Juno

Fechar o Pedido

Estado Final

Figura 28: Diagrama de Atividades Fonte: O autor, adaptada de FOWLER e SCOTT (2000, p.122)

4.6.7 Diagramas de Implementao Os diagramas de implementao recebem destaque principalmente na modelagem de sistemas complexos com o objetivo de descrever a arquitetura fsica do sistema, mostrando os componentes fsicos e suas interdependncias. Dentro da UML, esse tipo de diagrama representado pelos diagramas de componentes e de implantao que sero descritos a seguir.

81

4.6.7.1 Diagramas de Componentes Esse tipo de diagrama mostra as dependncias entre os componentes11 de um sistema mostrando suas interfaces e os servios que realizam. Um mdulo de sistema (arquivo de cdigo fonte, um arquivo executvel, etc.), por exemplo, pode ser considerado um componente. A UML define alguns esteretipos para componentes, a saber:

Executvel quando um componente pode ser executado; Documento quando o componente um documento como, por exemplo, um manual do usurio; Tabela quando uma tabela de um banco de dados; Arquivo quando um arquivo de dados; Biblioteca quando se refere a uma biblioteca de objetos ou de funes. Na figura abaixo possvel observar os principais elementos que formam esse tipo de diagrama.
Componente
Alunos

Interface
Lanamento de Notas Professores

Relao de Dependncia

Turmas

Figura 29: Diagrama de Componentes Fonte: O autor, adaptada de BEZERRA (2002, p.250)

4.6.7.2 Diagramas de Implantao Os diagramas de implantao tm como principal objetivo mapear os relacionamentos fsicos existentes entre os componentes de hardware e software do sistema, tendo como seus principais elementos os ns que so representados por cubos e significam um recurso computacional fsico que normalmente apresenta alguma memria e capacidade de processamento, e as conexes que so representadas por
11

importante entender que um componente materializa um conjunto de elementos lgicos como,

por exemplo, as classes.

82

linhas cheias que significam meios fsicos ou protocolos de comunicao que ligam os ns. importante ressaltar que quando o sistema est sendo executado, os seus componentes residem em ns que por sua vez podem ser de vrios tipos como processadores, sensores, roteadores, etc. A figura abaixo ilustra os principais elementos de um diagrama de implantao.
N fsico
Servidor de Aplicao <<HTTP>> Cliente: Browser Alunos SGBD Lanamento de Notas Professores Persistncia <<ODBC>> Banco de Dados Corporativo

Conexo

<<LAN>> Turmas Impressora

Figura 30: Diagrama de Implantao Fonte: O autor, adaptada de BEZERRA (2002, p.252)

4.7

Ferramentas de Modelagem de Software com UML

Os mesmos critrios de processo de seleo e compra de ferramentas de

modelagem de processos de negcio citados no tpico 3.2.2 podem se aplicar s ferramentas de modelagem de processos de software. Nesse caso, a escolha da ferramenta tambm deve levar em considerao uma srie de fatores como o escopo do projeto ou dos projetos em que ser utilizada, o tempo estimado de vida til dessa ferramenta dentro da organizao, a poltica do fornecedor com relao manuteno e atualizao da ferramenta, a facilidade de utilizao da mesma, a existncia de base de dados, entre outros fatores. Da mesma forma que existem consultorias que avaliam ferramentas de modelagem de processos de negcio, tambm existem aquelas avaliam ferramentas de modelagem de software como, por exemplo, a Yphise, que em seu relatrio de avaliao de software de novembro de 2002, apresenta a classificao de ferramentas segundo

83

alguns critrios. O resultado dessa classificao pode ser observado na figura abaixo.

Figura 31: Comparao das Ferramentas de Modelagem de Software Fonte: YPHISE (2002)

Na classificao acima, a consultoria avalia as ferramentas com base em cinco critrios, a saber:

Abrangncia da Modelagem Capacidade de modelar com preciso as aplicaes e arquiteturas especificadas, implementando todos os conceitos e diagramas da UML com funcionalidade de extenso e adaptao a outros tipos de modelagem.

Fcil Adaptao A equipe de desenvolvimento necessita de uma ferramenta que fcil de adaptar e usar. O ambiente de desenvolvimento deve ser fcil de 84

configurar para adaptar requisitos e mtodos especficos da organizao. A ferramenta tambm deve possibilitar incorporar facilmente tanto o cdigo existente como os componentes atravs de engenharia reversa12.

Reteno de informaes durante o ciclo de desenvolvimento A ferramenta deve ser capaz de reter e fornecer informaes como, por exemplo, modelos e documentos desenvolvidos durante todo ciclo de desenvolvimento do sistema, ajudando a manter a qualidade, produtividade e sincronizao entre os requisitos definidos e o cdigo gerado.

Controle da Qualidade dos Modelos Define a capacidade da ferramenta de controlar a consistncia dos modelos atravs de definio, verificao e correo de nomes e regras de notao da linguagem (UML) utilizada.

Gesto da Eficincia da Equipe de Desenvolvimento A ferramenta deve est adequada para suportar projetos que envolvem um grande nmero de equipes e pessoas, apresentando segurana no processo de modelagem com restries de acesso e privilgios por tipo de usurio, deve apresentar capacidade de acesso ao mesmo tempo por muitos usurios, entre outros.

Com base nesses critrios utilizados na avaliao da Yphise, a melhor ferramenta de modelagem de software do mercado o Rational Rose da empresa Rational Software fundada pelos criadores da UML e do Rational Unified Process (RUP)13. Atualmente, a Rational Software pertence a IBM tendo sido adquirida no final de 2002.

12

A Engenharia Reversa a capacidade que a ferramenta tem de gerar a partir dos cdigos existentes

modelos de software. O processo inverso chamado de Engenharia de Produo.

13

O RUP uma metodologia de referncia para desenvolvimento de software que utiliza a UML

como linguagem de modelagem e suporta a ferramenta Rational Rose. Esse processo ser melhor explicado no prximo captulo.

85

Os critrios citados por CAMEIRA e BASTOS (2000) com relao existncia de base de dados e metodologia de suporte a ferramenta tambm se aplicam nessa situao. O critrio referente existncia de base de dados no est explcito nos critrios definidos acima, mas se enquadra no critrio de reteno de informaes durante o ciclo de desenvolvimento. A existncia de uma metodologia associada ferramenta, apesar desse critrio no ser considerado para avaliao da Yphise, pode tambm ser considerado um critrio importante no processo de seleo e compra da ferramenta. Com relao a esse critrio, a ferramenta Rational Rose apresenta, conforme j citado, o RUP como metodologia de referncia.

4.8

Consideraes Finais
Neste captulo foram apresentadas os principais conceitos, caractersticas e

ferramentas de modelagem inerentes UML, mostrando a sua origem e importncia dentro da comunidade de desenvolvimento de sistemas de software orientados a objeto. Dessa forma, foi possvel perceber que a UML, em sendo uma linguagem padro de modelagem, contribui em muito para aumentar a qualidade de um processo de desenvolvimento de software, pois, atravs de seus diagramas consegue expor e uniformizar os entendimentos desde o usurio final do sistema at o nvel de programao de cdigo. Foi possvel perceber tambm que a UML apenas uma linguagem, podendo ser adaptada e utilizada em diferentes metodologias de modelagem de processos e de sistemas. Assim, o prximo captulo, baseado nos conceitos, metodologias e diagramas tanto de EPN como da UML, tem como principal objetivo apresentar algumas das principais abordagens de extenso da UML para modelagem de negcio, fazendo tambm a comparao entre seus modelos e os modelos tradicionais da EPN.

86

EPN

UML:

CONTEXTUALIZAO

DA

UML

NA

MODELAGEM DE PROCESSOS DE NEGCIO

Como foi possvel observar no captulo 3, um dos principais desdobramentos da Engenharia de Processos de Negcio (EPN) est relacionada modelagem de processos de negcio orientada para o desenvolvimento de sistemas de informao. Porm, para melhor compreenso do relacionamento entre a EPN e a Engenharia de Software (ES) foram descritas no captulo 4 as principais caractersticas e modelos da UML, considerada pela OMG como linguagem padro universal para desenvolvimento de sistemas de softwares orientados a objeto. Esse captulo tem como principal objetivo analisar e comparar os principais conceitos e modelos que suportam a EPN e a ES, fazendo-se uma anlise crtica dos modelos da UML, da verso 1.5 de maro de 2003, enquanto linguagem para modelagem de negcio.

5.1

Modelagem de Processos de Negcio com UML: Anlise Crtica dos Modelos

Conforme a prpria definio da OMG citada no captulo 4, a UML alm de ser

uma linguagem utilizada para modelagem de software, tambm pode ser utilizada para modelagem de negcio. Mas, para que a UML seja utilizada para modelagem de negcio, necessria criar algumas extenses e customizar a linguagem. Assim, como ser visto nesse tpico, da forma como os modelos esto definidos pela OMG, ainda existem limitaes com relao representao de alguns conceitos relacionados modelagem de processos de negcio. Nesse tpico, sero mostrados os diagramas da UML sob a tica de utilizao dos mesmos para modelagem de negcio e, portanto, de processos de negcio. No sero considerados nessa anlise os diagramas de implementao, pois, estes no apresentam nenhum tipo de relao direta com os conceitos de modelagem de negcio. Alm disso, como base de comparao, ser utilizado o EPC como modelo de processos de negcio, mostrando, atravs da comparao entre o EPC e os diagramas da

87

UML, as principais diferenas e semelhanas entre a modelagem de processos de negcio e a modelagem orientada a objeto. 5.1.1 Modelagem de Negcio e Diagrama de Casos de Uso Conforme apresentado no captulo 4, um caso de uso um conjunto de cenrios que descrevem interaes entre usurios e sistemas. Tais cenrios representam diversas situaes vivenciadas pelos usurios do sistema, incluindo caminhos alternativos para soluo de erros e imprevistos que venham a aparecer no meio do processo de interao. O diagrama de casos de uso apresenta alguns conceitos de modelagem de negcio como, por exemplo, a interao entre atores e casos de uso, que podem ser representados por unidades organizacionais, os sistemas e as metas de processos que podem estar associadas execuo de um caso de uso ou um conjunto de casos de uso. Em considerando a utilizao desse diagrama para modelagem de negcio, o sistema com o qual os usurios interagem, passa a ser o prprio negcio. A partir desse princpio, surgem os chamados casos de uso de negcio que representam os processos de negcio que definem a interao entre entidades (atores do negcio) que esto fora do negcio como, por exemplo, clientes, fornecedores, parceiros, entre outros, e o prprio negcio. Logo, um diagrama de caso de uso de negcio representa visualmente a interao entre os principais servios (casos de uso de negcio) que o negcio fornece e aqueles (atores do negcio) que utilizam esses servios (RATIONAL, 2001b). Dentro de um diagrama de caso de uso de negcio, a descrio do fluxo de trabalho relacionado a um caso de uso de negcio (processo de negcio) pode ocorrer de duas formas. Conforme foi dito no tpico 4.6.1, uma das formas de representar textualmente com a utilizao de um formato bsico de descrio, onde se descreve o fluxo normal de eventos que descreve os principais passos do processo, os fluxos alternativos de situaes incomuns, etc. Uma outra forma seria atravs da utilizao do diagrama de atividades que descreveria graficamente os passos do caso de uso de negcio. A utilizao de uma forma de descrio ou outra fica a critrio dos envolvidos com a modelagem dos casos de uso. Dependendo da situao, tanto a descrio textual como a grfica apresentar vantagens e desvantagens, podendo tambm us-las em conjunto para expressar o fluxo de trabalho do processo de negcio. 88

A figura abaixo mostra de que forma o diagrama de caso de uso pode ser utilizado para modelagem de processos de negcio.

Figura 32: Exemplo de caso de uso de negcio Fonte: Rational (2001b)

Porm, conforme pode ser observado em LOOS e ALLWEYER (1998) e em LOOS e FETTKE (2001), o modelo de casos de uso no apresenta nenhuma forma de representao grfica de fluxo de controle, caracterstica importante para melhor descrio e compreenso dos processos de negcio, pois, dificulta a identificao e compreenso de, por exemplo, pontos de deciso, paralelismo, entre outros aspectos que podem ser mais bem representados de forma grfica. Assim, importante ressaltar que existe a necessidade, principalmente com relao ao conceito de caso de uso de negcio, de mostrar as relaes e formas de integrao entre os casos de uso e um modelo como o EPC. Para LOOS e ALLWEYER (1998) essa integrao pode se d em nveis de detalhamento diferente conforme pode ser observado na figura abaixo. 89

Necessidade de organizar conferncia Comit de organizao Selecionar palestrantes potenciais Palestrantes potenciais selecionados Escrever convites
Secretria Digitar texto

Ocorrncia de requisito

Criar requisito

Levantar requisito Assis tente de Vendas

Requisito criado

Secretria

Formatar texto

Definir produto e quantidade Produto e quantidade definidos

Convites escritos

Salvar documento

Figura 33: Nveis de detalhamento entre casos de uso e EPC Fonte: Traduzida de LOOS e ALLWEYER (1998)

Conforme pode ser observado no lado esquerdo da figura, possvel gerar a partir de um EPC, mais especificamente da funo escrever convites que executada pela unidade organizacional secretria um diagrama de casos de uso onde o ator a secretria que est relacionado com trs casos de uso que so necessrios para execuo desta funo: digitar o texto, formatar o texto e salvar o documento. Numa outra abordagem, do lado direito da figura, possvel observar o detalhamento do caso de uso capturar requisio executado pelo ator representado pelo assistente de vendas que est sendo desdobrado em um EPC com duas funes: criar requisio e definir produto e quantidade. Dependendo do nvel de detalhamento em que se esteja trabalhando, ainda tambm possvel ter a relao de uma funo para um caso de uso. Em todos os casos, possvel utilizar os mesmos papis (ator representado por um stick man ou unidades organizacionais representadas por elipses) para ambos diagramas. 5.1.2 Modelagem de Negcio e Diagramas de Atividades O diagrama de atividades, dentre os diagramas da UML, o que mais se aproxima dos modelos tradicionais de modelagem de processos de negcio como, por exemplo, o EPC, o IDEF 3, entre outros. Dessa forma, esse tipo de diagrama, inicialmente concebido com o intuito de modelar o fluxo de trabalho relacionado ao comportamento de um sistema, tambm pode ser utilizado para modelagem de processos de negcio podendo ser denominado de diagrama de atividades de negcio. 90

Assim como os demais diagramas tradicionais utilizados para modelagem de processos de negcio, esse diagrama permite modelar o fluxo de trabalho considerando situaes de sincronismo e de deciso, permite relacionar, atravs de colunas (swimlanes), papis e unidades organizacionais responsveis pela execuo das atividades do processo e tambm pode mostrar, atravs de extenses da UML, os comportamentos e relacionamentos entre as entidades de negcio e as atividades em execuo. Demais elementos relacionados sintaxe e semntica do diagrama como, por exemplo, barras de sincronismo, foram explicados no tpico 4.6.6. Segundo RATIONAL (2001b), se a modelagem do negcio conseguir representar com clareza os requisitos do sistema a ser desenvolvido, algumas das entidades de negcio podem se tornar de forma direta uma classe de anlise no projeto do sistema, reutilizando artefatos de negcio e dando agilidade ao ciclo de vida de desenvolvimento de um sistema de informao. Mas, apesar do diagrama de atividades apresentar um grande potencial de representao de modelagem de processos de negcio, comparando-o com o EPC, possvel destacar alguns problemas como, por exemplo, a ausncia de uma representao do operador lgico OU, possuindo apenas barras de sincronizao e pontos de deciso representados por losango que no EPC so respectivamente equivalentes ao operador lgico E e OU exclusivo. Alm disso, apesar de atravs das swimlanes estabelecer responsabilidades organizacionais pela execuo das atividades, o diagrama de atividades no capaz de representar relacionamentos organizacionais mais detalhados como no EPC em que uma unidade organizacional pode apresentar diversos tipos de relacionamentos com uma determinada funo como, por exemplo, responsvel por, executa, deve ser informado do resultado, deve ser aprovado por, entre outros. Porm, apesar das diferenas citadas acima, o diagrama de atividades pode suportar a modelagem de processos de negcio, pois, tambm apresenta objetos que podem representar tanto atividades, como operadores lgicos, insumos e produtos, unidades organizacionais, eventos, etc. Na figura abaixo, possvel visualizar a semelhana entre o diagrama de atividades e o EPC.

91

Figura 34: Relao entre EPC e Diagrama de Atividades Fonte: LOOS e ALLWEYER (1998)

Na figura acima, as unidades organizacionais do EPC so representadas nas swimlanes, as funes so convertidas de forma direta para as atividades, o operador lgico OU exclusivo convertido de forma direta para um losango e o objeto de negcio requisio mantido de forma idntica nos dois diagramas. Os eventos intermedirios no so representados no diagrama de atividades que representa apenas, de forma diferente, os eventos inicias e finais do processo. importante destacar que os dois modelos (diagrama de atividades e EPC) podem contemplar de forma satisfatria a modelagem de processos de negcio, mas o EPC ainda mais utilizado pelos analistas de negcio na prtica de modelagem de processos de negcio pelo fato de ser bastante difundido dentro da comunidade de processos de negcio e de ser um modelo da ferramenta lder do mercado de modelagem de processos. 5.1.3 Modelagem de Negcio e Diagrama de Classes Conforme foi possvel observar no captulo 4, os diagramas de classes e de objetos mostram os relacionamentos entre classes e conseqentemente objetos que estruturam um sistema. Porm, pensando em termos de modelagem de negcio, as entidades de negcio tambm podem ser representadas como classes e objetos, o que faz 92

desses diagramas candidatos para aplicao de parte dos conceitos relacionados modelagem de negcio como, por exemplo, a modelagem de estruturas organizacionais mostrando os relacionamentos entre as unidades organizacionais num organograma, a modelagem dos relacionamentos entre unidades organizacionais e demais entidades de negcio utilizadas como recursos para execuo dos processos de negcio e a modelagem dos relacionamentos entre os prprios recursos. Outros conceitos relacionados, principalmente, modelagem de processos de negcio no so contemplados por esses modelos como os conceitos de fluxo de controle de material e de informao, de atividades, de evento, metas, indicadores, entre outros. Alguns autores como NTTGENS, FELD e ZIMMERMANN (1997) e LOOS e ALLWEYER (1998) fazem uma comparao entre o EPC e os diagramas da UML com o intuito de apresentar uma sinergia entre os conceitos de processos e da orientao a objeto, buscando tirar vantagens das duas abordagens. No que diz respeito ao diagrama de classes, o primeiro autor coloca que o EPC, enquanto processo de negcio, pode se relacionar de duas formas com o diagrama de classes. Na primeira delas, que o autor chama de abordagem de transformao, o EPC pode contribuir de forma direta na construo do diagrama de classes. Essa identificao se daria atravs do detalhamento de objetos de informao processados e das atividades executadas no processo. Na segunda forma, denominada de abordagem de integrao, o autor sugere a criao do object-oriented event-driven process chain (oEPC) colocando que esse modelo estaria integrado com os conceitos de orientao a objeto e ao mesmo tempo preservaria a lgica de processos do EPC. Conforme pode ser visto na figura abaixo, a principal diferena entre o oEPC e o EPC que as funes (atividades) so substitudas por objetos de negcio pertencentes a classes de negcio, objetos esses que apresentam seus atributos e suas operaes. Alm disso, os eventos descrevem os estados de transio dos objetos de negcio de acordo com as operaes executadas, as mensagens entre os objetos so representadas pelo fluxo de controle apoiado por mecanismos de deciso e de controle como, por exemplo, os operadores lgicos e, por fim, considerando que um dos principais objetivos da modelagem de processos de negcio

93

identificar e resolver problemas organizacionais, possvel associar aos objetos de negcio tanto unidades organizacionais quanto os recursos utilizados.

Objeto de Negcio Atributo Inativo Atributo a1 a2

Evento classe 0 triggers Objeto de negcio a1 l triggers AND 1 triggers executores Organizao unidade 1

Atributo a3
Operao

Evento classe 1 triggers Organizao unidade 2 executores Objeto de negcio l 2

Evento classe 2 triggers Objeto de negcio l 3 executores Organizao unidade 3

Evento classe 3

Evento classe 4

Figura 35: Estrutura do oEPC Fonte: Traduzida de NTTGENS, FELD e ZIMMERMANN (1997)

Para LOOS e ALLWEYER (1998) a relao do EPC com o diagrama de classes a mais importante dentre os demais modelos da UML, pois, o diagrama de classes pode ser considerado a parte central da UML sendo base fundamental para o desenvolvimento orientado a objeto. Nessa abordagem, os autores sugerem trs nveis de detalhamento entre o EPC e os elementos que formam o diagrama de classes. No nvel mais agregado, conforme pode ser vista na figura abaixo, as funes agregadas do EPC se relacionariam com pacotes (conjunto de objetos logicamente agrupadas) onde o sentido da seta indica, por exemplo, que informaes contidas nos objetos de um pacote servem de entrada para execuo de uma determinada funo, representado nesse caso por uma seta com sentido do pacote para a funo, e que objetos daquele pacote tiveram seus estados alterados pela funo, representado por uma seta com sentido da funo para o pacote.

94

Pedido do Cliente Pedidos do cliente Pedido de Resoluo do problema

Vendedor

Pedido em produo

^
Requisio feita Procurao Procurao Procurao

Providencia do material

^
Produo Produo Produo Produto final

Figura 36: EPC de alto nvel com pacotes Fonte: LOOS e ALLWEYER (1998)

A figura abaixo ajuda na compreenso da abordagem citada acima, mostrando que os pacotes relacionados s funes apresentam em seu detalhamento diagramas de classes e seus respectivos elementos.
Procurao
Material Nome Quantidade em Estoque

1..

Pedido Data Status

Item do Pedido Estoque Status Determinar Material() Determinar Estoque()

Requisitos

Empregado

0.. 1
Determinar Receptor()

Figura 37: Diagrama de Classes agrupado num pacote Fonte: LOOS e ALLWEYER (1998)

95

No nvel intermedirio, conforme pode ser observado na figura abaixo, os autores relacionam as funes um pouco mais detalhadas diretamente com os objetos que na abordagem anterior estavam contidos nos pacotes, mostrando quais objetos so utilizados e modificados pelas funes.
Requisito Material ocorreu

Empregado

Capturar requisito

Assistente de vendas

Requisito Requisito Capturado

Verificar material em Material XOR

Procurador especialista

Material em estoque

Material em falta

Figura 38: EPC de nvel intermedirio com classe Fonte: Traduzida de LOOS e ALLWEYER (1998)

Conforme pode ser observado na figura abaixo, no terceiro e ltimo nvel, as funes j em um nvel bem desagregado se relacionam diretamente com atributos e operaes dos objetos das classes.
Requisito ocorrido Criar requisito

Requisito criado Determinar Determinar qtd() Status Determinar materiais e quantidade

Material e quantidade determinados

Determinar

Determinar receptor

Requisito capturado

Figura 39: EPC Capturar Requisitos detalhado com atributos e operaes Fonte: Traduzida de LOOS e ALLWEYER (1998)

96

Os autores colocam que nesse nvel as funes esto muito prximas das operaes, onde cada operao que relevante para o negcio executada por uma funo, reduzindo, desta forma, o gap entre funes e operaes durante a definio de requisitos. 5.1.4 Diagrama de Grficos de Estados O diagrama de grfico de estados, conhecido tambm como apenas diagrama de estados, est normalmente associado a um nico objeto de sistema, sendo utilizado quando necessrio entender de forma mais clara o comportamento desse objeto. Por ser muito especfico e voltado para modelagem de estados de um nico objeto, esse diagrama, apresenta limitaes para modelagem de negcio, sendo relevante em algumas situaes no nvel de anlise e projeto de um sistema. Apesar desse tipo de diagrama no apresentar qualquer tipo de relao com os conceitos de modelagem de negcio possvel fazer uma comparao com o EPC, conforme pode ser observado na figura abaixo.

Figura 40: Comparao entre EPC e Diagrama de Estados Fonte: LOOS e ALLWEYER (1998)

97

LOOS e ALLWEYER (1998) ressaltam a importncia de se definir os estados dos possveis objetos associados s funes, pois, como pode ser visto na figura acima, a funo retirar material do estoque s pode ser executada quando o objeto de entrada requisio estiver no estado de verificada. Dessa forma, possvel acompanhar as transies e mudanas de estados de um determinado objeto dentro de um processo de negcio. Alm disso, importante ressaltar que existe alguma redundncia entre os eventos do EPC e os estados do diagrama de estados. Em muitos casos, o prprio evento j indica uma mudana de estado de um determinado objeto que est sendo utilizado durante o processo como, por exemplo, o evento requisio capturada que redundante com o objeto de sada requisio no estado de capturada. Nessas situaes basta a utilizao de uma das notaes. Mas, nem sempre essa relao direta como pode ser visto no caso em que o objeto requisio se encontra no estado de verificada e pode ter dois eventos relacionados material em estoque e material no existe em estoque. 5.1.5 Modelagem de Negcio e Diagramas de Interao Os diagramas de interao (diagrama de seqncia e de colaborao), conforme j citado no captulo 4, tm como principal objetivo modelar as interaes que ocorrem entre dois ou mais objetos atravs do envio e recebimento de mensagens para realizar as execues das operaes requeridas. Pensando em termos de conceitos de modelagem de negcio e considerando que esses diagramas normalmente esto relacionados s realizaes dos casos de uso eles podem representar interaes entre entidades de negcio, os atores e as metas de processo relacionadas execuo dos casos de uso.

98

Mas, para LOOS e FETTKE (2001), apesar desses diagramas apresentam alguns aspectos do fluxo de processos de negcio, eles normalmente so utilizados no nvel de implementao, apresentando detalhes tcnicos e, portanto, no sendo adequados para modelagem de negcio. LOOS e ALLWEYER (1998) tambm afirmam que esses diagramas esto muito prximos do nvel de implementao, pois, enquanto o EPC, por exemplo, est focado na modelagem de funes e objetos relevantes sob o ponto de vista do negcio, os diagramas de interao descrevem as trocas de mensagens entre os objetos de forma mais detalhada do ponto de vista da implementao do sistema. Os autores colocam que apesar de existirem informaes redundantes entre os diagramas no possvel transformar um EPC diretamente em um diagrama de interao.

5.2

Extenses da UML para Modelagem de Negcio

Para ERIKSSON e PENKER (2000), a modelagem de negcio base

fundamental para modelagem de outros modelos como, por exemplo, os modelos relacionados ao desenvolvimento de qualquer sistema de informao que dar suporte ao negcio. Os autores destacam algumas vantagens de se realizar a modelagem de negcio, a saber:

Melhorar o entendimento e os mecanismos de funcionamento do negcio atravs do uso de modelos; Serve de base para a modelagem de sistemas de informao que daro suporte ao negcio, definindo de forma mais clara os principais requisitos que determinaro as funcionalidades dos sistemas, tornando o processo de desenvolvimento de sistemas orientado ao negcio; Serve de base para melhoria contnua tanto da estrutura como da operao do negcio; Possibilita a elaborao de um plano de ao para gerar, atravs de mudanas radicais ou incrementais, inovao nos processos de negcio;

99

Realizao de benchmarking, atravs da comparao de tecnologias, prticas e modelos de negcio de outras empresas; Identificao de oportunidades de terceirizao de partes do negcio que no so consideradas chaves para o negcio. Nesse caso, os modelos referentes essas partes que no so chaves para o negcio serviriam de referncia para a operacionalizao dos terceiros.

Diante dessas vantagens, os autores apresentam em sua proposta uma extenso da UML para modelagem de negcio, mostrando como uma mesma linguagem pode ser utilizada para tanto para modelagem de negcio quanto para de software. Reconhecendo as diferenas entre os conceitos que envolvem a modelagem de negcio e a de software como, por exemplo, recursos (pessoas e mquinas), regras e objetivos atrelados execuo dos processos de negcio, os autores criaram um conjunto de extenses da UML para que a linguagem pudesse representar, atravs da criao de novos cones, os principais elementos relacionados execuo e modelagem de negcio. Para criar esses cones relacionados modelagem de negcio, foram utilizados os mecanismos de extenso da UML (esteretipos, valores atribudos e restries), descritos e explicados no tpico 4.4.3 dessa dissertao, para representar, segundo os autores, os principais conceitos envolvidos na modelagem de um negcio. Em sua abordagem, os autores consideram o diagrama de atividades como o principal modelo de representao de modelagem de negcio, pois, tais diagramas conseguem representar diversos aspectos de negcio como, por exemplo, paralelismo de execuo entre atividades, recursos usados, consumidos e produzidos por uma atividade, identificao de responsabilidades por atividades, relacionamentos e dependncias entre atividades, entre outros. Assim, conforme pode ser observado na figura abaixo, os autores criaram um diagrama para representar atravs de um smbolo de processo, estereotipado do elemento atividade do diagrama de atividades, as extenses para modelagem de negcio de acordo com a sintaxe da UML.

100

<<objetivo>> Objetivo

<<recurso>> Entrada: l

<<processo>> Processo A

<<recurso>> Sada: l

<<recurso>> Recurso A

<<recurso>> Recurso B

Figura 41: Diagrama de Atividades e esteretipos de processos de negcio Fonte: Traduzida de ERIKSSON e PENKER (1999)

Em sua abordagem, os autores tambm propem vistas de negcio como, por exemplo, as citadas na metodologia ARIS, que buscam diminuir a complexidade de entendimento do negcio atravs da diviso em vistas que podem ser expressas por um ou mais modelos. Para os autores, a arquitetura de um negcio pode ser quebrada em quatro vistas: 5.2.1 Vista de Viso do Negcio Essa vista se caracteriza por apresentar os objetivos estratgicos do negcio que serviro de guia para a realizao das demais vistas. Assim, os principais resultados dessa vista podem ser expressados pelos artefatos: declarao da viso do negcio que pode se caracterizar por um breve documento textual que define a viso do futuro da organizao; um modelo de objetivos e problemas, representado por um diagrama de objetos da UML, e que pode ser detalhado em diferentes nveis para mostrar objetivos, sub-objetivos e os problemas que limitam o alcance dos objetivos; e um modelo 101

conceitual, representado por diagrama de classes da UML, que define conceitos e relacionamentos dentro do negcio com o intuito de criar um conjunto de terminologias comum a todos envolvidos com o negcio. A figura abaixo exemplifica um diagrama de objetivos e problemas que mostra a hierarquia existente entre objetivos e seus respectivos problemas.
Muitos Clientes: Objetivo Quantitativo Valor_Objetivo = 500000 Valor_Atual = 0 Unidade_de_Medida = "Clientes cadastrados"

<<problema>> Clientes no esto querendo se registrar

(Completo)

<<problema>> Clientes no gostam do preo

<<problema>> Site no conhecido

(Incompleto)

Muitos Visitantes da Internet: Objetivo Quantitativo

Muitos Clientes Registrados: Objetivo Qualitativo

Muitos Clientes Inscritos: Objetivo Qualitativo

(Incompleto)

<<problema>> Clientes no conhecem as vantagens

Links de Outros Sites: Objetivo Quantitativo

Site Avaliado em Outras Mdias: Objetivo Qualitativo

Visvel nos Sites de Busca: Objetivo Quantitativo

Tornar Registro Interessante: Objetivo Qualitativo

Comunicar servios prmio para membros: Objetivo Qualitativo

Preo Atrativo: Objetivo Quantitativo

Prover bons servios prmio: Objetivo Quantitativo

<<problema>> Outros sites no colocam links

<<causa>> No interesse de proprietrios de outros sites atrair visitas para este site

<<ao>> Prover incentivos para outros sites (como prmios para cada visitante encaminhado)

<<pr-requisito>> Meios financeiros para prover bonificao

Figura 42: Diagrama de Objetivos e Problemas Fonte: Traduzida de ERIKSSON e PENKER (1999)

5.2.2 Vista de Processos de Negcio Esta vista se caracteriza como a principal vista da modelagem de negcio, pois, apresenta todos os processos de negcio, os relacionamentos entre eles, entre os recursos utilizados em suas execues e entre os objetivos estratgicos definidos. Como pode ser observado na figura abaixo, o principal modelo utilizado nessa vista o diagrama de processos que tem como base o diagrama de atividades e apresenta os principais elementos envolvidos com os processos como as unidades organizacionais

102

envolvidas na execuo dos processos, os eventos de negcio que iniciam ou finalizam os processos, os recursos consumidos ou produzidos pelos processos entre outros.

Figura 43: Diagrama de Processos Fonte: ERIKSSON e PENKER (1999)

Os autores tambm propem um modelo denominado de diagrama de linha de montagem que uma variante do diagrama de processos original, servindo como base de modelagem para os processos que so diretamente implementados por um sistema de informao. Conforme pode ser observado na figura abaixo, no topo do diagrama de linha de montagem est o diagrama de processos. Na parte inferior encontra-se um conjunto de pacotes horizontais que so denominados de pacotes de linha de montagem, onde cada um representa um conjunto de objetos. Esses pacotes so elementos da UML e recebem o esteretipo de <<linha de montagem>>. O principal objetivo desse diagrama mostrar os relacionamentos entre os processos e os objetos de informao, mostrando como a informao acessada pelo sistema e como utilizada pelos processos.

103

<<processo>> Confirmao de Venda

<<processo>> Registro de Transao

<<processo>> Envio do Pedido

Receber Informaes do pedido

<<linha de montagem>> Sistema de Contabilidade

<<linha de montagem>> Sistema de Vendas

sada entrada
<<linha de montagem>> Sistema de Inventrio

Figura 44: Diagrama de Linha de Montagem Fonte: Adaptada de JUNIOR (2003)

importante ressaltar que esse diagrama apresenta as interfaces dos processos de negcio e dos sistemas de informao que, dentro da concepo da modelagem orientada a objeto, so representadas por casos de uso. Com esse diagrama, possvel identificar tanto as funcionalidades (casos de uso) que os sistemas devem ter como os atores (executores dos processos) relacionados com essas funcionalidades. Assim, esse diagrama facilita a identificao dos casos de uso que devem ser modelados, ajudando a realizar com mais eficincia a conexo entre a modelagem de processos de negcio e os requisitos funcionais dos sistemas que sero desenvolvidos. 5.2.3 Vista de Estrutura do Negcio Conforme pode ser visto na figura abaixo, essa vista mostra a estrutura de recursos, produtos e de informao do negcio, incluindo modelos como, por exemplo, o organograma. A vista de processos tem relao com essa vista, pois, mostra quais 104

Receber Lista de Pacotes

Identificar como enviado-cliente

Registrar como vendido

Identificar Vendedor

Identificar pedido

recursos so utilizados para a execuo dos processos e, portanto, elas podem ser modeladas em paralelo mantendo consistncia entre elas.
Diagrama de Classe Diagrama de Objeto
Software Inc.: Unidade Organizacional Corporao: Tipo de organizao

Tipo de organizao Descrio

Produo: Unidade Organizacional

Dep. Vendas: Unidade Organizacional

Desenvolvimento: Unidade Organizacional Departamento: Tipo de organizao

Unidade Organizacional Equipe OOA: Propsito Unidade Organizacional Equipe Java: Unidade Organizacional Equipe BM: Unidade Organizacional Equipe OOD: Unidade Organizacional

Equipe: Tipo de organizao

Figura 45: Diagrama Organizacional Fonte: Traduzida de ERIKSSON e PENKER (1999)

5.2.4 Vista de Comportamento do Negcio Essa vista mostra os comportamentos individuais dos recursos e processos bem como suas interaes. De uma maneira geral, o comportamento dos recursos orientado pela vista de processos de negcio que determina o fluxo de controle do trabalho realizado. Mas, quando se deseja detalhar o comportamento de um determinado objeto mostrando seu estado, o comportamento em cada estado e possveis estados de transio a modelagem ocorre nessa vista. Nessa vista, tambm possvel determinar as interaes entre diferentes processos bem como definir responsabilidades para diferentes atividades e mapear o comportamento de cada recurso envolvido nos processos de negcio. Nessa vista so utilizados diagramas de estado, seqncia, colaborao e tambm de processos quando h a necessidade de mostrar interao entre processos.

105

5.3

Consideraes Finais
Nesse captulo foi possvel observar e comparar alguns dos conceitos e modelos

envolvidos com a modelagem de processos de negcio e a modelagem orientada a objeto, mostrando as vantagens e desvantagens da utilizao dos modelos da UML para realizar a modelagem de processos de negcio. Foi possvel concluir que uma proposta de modelagem de negcios com os modelos da UML, apesar de apresentar vantagens de entendimento por parte dos analistas de desenvolvedores de sistemas apresenta limitaes de entendimento por parte dos analistas de negcio, pois, conforme observado na comparao com o EPC, os modelos da UML no representam de forma satisfatria alguns conceitos relacionados a modelagem de negcio. Uma outra desvantagem dessa abordagem est relacionada ao fato de no possuir nenhum tipo de arquitetura voltada para modelagem de negcio como, por exemplo, a estrutura de vistas da metodologia ARIS, tendo como base as vistas da arquitetura da UML apresentada no captulo 4, vistas essas que foram criadas para suportar conceitos de modelagem de sistemas de software e no de negcio. Alm dessa comparao dos modelos da UML com EPC, foi apresentada uma proposta de extenso da UML por ERIKSSON e PENKER (1999,2000), onde percebese a existncia de conceitos relacionados a modelagem de negcio com uma proposta de arquitetura dividida em vistas suportadas por modelos e extenses da UML. Essa abordagem j se aproxima mais da modelagem de processos de negcio, utilizando alguns diagramas da UML, principalmente, o diagrama de atividades, para representar conceitos inerentes aos conceitos de processos de negcio. As principais limitaes dessa abordagem so a falta de capacidade de abstrao no considerando nveis de detalhamento diferentes se limitando a um nvel macro de modelagem e a limitao para representar sistemas de informao que suportem estruturas de processos de negcio mais complexas, podendo ser eficiente para modelar sistemas de informao mais simples. Diante da anlise acima, o objetivo do prximo captulo definir uma proposta de metodologia de modelagem de processos com foco em desenvolvimento em sistemas, mesclando as principais etapas de modelagem de processos de negcio com as do RUP.

106

MODELAGEM

DE

PROCESSO

DE

NEGCIO

RATIONAL UNIFIED PROCESS (RUP)

Um dos maiores problemas com a maior parte dos
esforos relacionados engenharia de negcios que as comunidades de engenharia de software e a engenharia de negcios no se comunicam de forma adequada. Com isso, o produto da engenharia de negcios no usado de forma correta como insumo para os esforos de engenharia de softwares, e viceversa. (RATIONAL, 2001a)

Diante da afirmao acima, esse captulo tem como principal objetivo definir uma metodologia de modelagem de processos e requisitos de negcio utilizando como base de desenvolvimento alguns dos modelos da metodologia ARIS, modelos da UML e conceitos do RUP, considerando suas respectivas fases e artefatos. O principal objetivo dessa metodologia o de integrar, se no totalmente, mas pelo menos parcialmente, as comunidades de engenharia de negcios e de desenvolvimento de softwares atravs da utilizao de duas metodologias que so suportadas por duas ferramentas, ARIS Toolset e Rational Rose, consideradas lderes de mercado em seus respectivos segmentos, desenvolvimento de processos de negcio e desenvolvimento de software e que conforme pode ser observado em IDS SCHEER (2002), podem ser integradas, pois, a ferramenta ARIS Toolset , alm dos modelos tradicionais de processo tambm suporta os modelos da UML e atravs de um mdulo denominado de TOOLBUS pode importar os modelos da UML para e Rational Rose e vice-versa.

6.1

Principais Etapas para Modelagem de Processos de Negcio

A modelagem de processo de negcio, como foi possvel observar no captulo 3,

apresenta diversas aplicaes como o projeto de desenvolvimento de sistemas de informao, gesto de conhecimento, anlise de indicadores desempenho, gesto da cadeia de suprimento, entre outros. Sendo assim, no existe uma nica metodologia de modelagem de processos de negcio, pois, a abordagem da modelagem varia de acordo com o objetivo para o qual se est modelando.

107

Para VERNADAT (1996), existem muitos processos ou metodologias de modelagem de processos de negcio que podem ser definidos de acordo com os objetivos da modelagem, tipo de anlise a ser realizada sobre os modelos ou at mesmo em funo da experincia dos usurios. Diante dessa afirmao, o mesmo autor prope uma estrutura geral de um processo de modelagem de processos de negcio com desdobramento para sistemas de informao que pode ser observada na figura abaixo.
Engenharia Ontolgica Bibliotecas de Modelos

Definio do Domnio do Negcio

Engenharia de Processos de Negcio

Projeto do Sistema e Validao

Implantao e Lanamento do Sistema

Processo de Melhoria Contnua

Operao do Sistema

Figura 46: Processo de Modelagem de Negcio Fonte: Adaptado de VERNADAT (1996)

Dentro das etapas propostas pelo autor, importante destacar a existncia de bibliotecas de modelos relacionados tanto com os modelos de processos de negcio quanto com os modelos relacionados ao projeto do sistema. Essas bibliotecas de modelos so construdas com o tempo atravs de experincias vivenciadas em diversos projetos e situaes que moldam um conjunto de modelos que armazenam conhecimentos que podem servir de referncia, podendo ser reutilizados para situaes futuras. Esses modelos que apresentam um grande potencial de reutilizao sejam processo de negcios ou modelos de sistemas como, por exemplo, os das UML, so verdadeiros padres de solues para uma gama de problemas, se caracterizando como componentes ou modelos pr-fabricados que variam desde componentes de processos de negcio at os componentes de software. Outro aspecto importante do modelo a iterao existente dentro do processo de modelagem, mostrando a preocupao da melhoria contnua envolvendo a etapa de Operao do Sistema e Engenharia de Processo de Negcio. 108

Uma outra proposta de modelagem de processo de negcio com desdobramento para sistemas pode ser vista em IDS SCHEER AG (2002), conforme mostra a figura abaixo.

Definio do Mapa Estratgico

Desenvolvimento da Estratgia e Arquitetura

Modelagem dos Processos Atuais

Anlise e Redesenho dos Processos Futuros

Implementao dos Processos Futuros

Figura 47: Processo de Modelagem de Negcio com Desdobramento para Sistemas Fonte: Adaptada de IDS SCHEER (2002)

Nessa abordagem, os principais processos de negcio relacionados aos sistemas de informaes so levantados e direcionados de acordo com os objetivos estratgicos definidos pela organizao. Assim, antes de se desenvolver qualquer tipo de sistema que venha a automatizar qualquer processo de negcio chave, deve-se, conforme observado nas duas primeiras etapas, definir, entender, documentar e difundir a viso estratgica da organizao, estabelecendo uma relao direta entre os objetivos estratgicos, funes e processos de negcio que sero suportadas pelos sistemas de informao. Alm disso, cabe definir as ferramentas de modelagem que daro suporte a modelagem de processos e de sistema. Na etapa seguinte ocorre a modelagem e dos processos de negcio atuais com o levantamento de informaes importantes para a realizao da anlise da atual estrutura de negcio e de TI, identificando, dentro da lgica de melhoria contnua, oportunidades de melhorias futuras. Identificadas as possibilidades de melhorias futuras, na prxima fase ocorre o redesenho ou remodelagem dos processos de negcio onde informaes detalhadas servem de base para a definio dos requisitos funcionais e da arquitetura do sistema a ser criado. Por fim, ocorrem a implementao dos processos futuros onde so realizadas atividades como desenvolvimento do cdigo fonte, testes operacionais com uma verso beta do sistema, definio de manuais de utilizao do sistema, treinamento dos usurios, migrao de dados entre sistemas quando necessrio e a entrega da verso final que entrar em produo.

109

 importante destacar que para a realizao da modelagem consistente e de fcil entendimento da estrutura do negcio como um todo, incluindo os processos de negcio e a arquitetura dos sistemas de informao, importante, conforme observado no tpico anterior, quebrar a modelagem em vistas suportadas por modelos que possam representar de forma simplificada e integrada diferentes aspectos da modelagem realizada.

6.2

Processos Produtivos de Desenvolvimento de Sistemas

Atualmente, algumas das principais metodologias de desenvolvimento de

sistemas esto levando em considerao o levantamento e modelagem de processos de negcio como parte fundamental para identificao de requisitos de sistemas que possam alinhar e orientar o desenvolvimento de componentes de software e suas interfaces de servios com as necessidades dos usurios e com os objetivos estratgicos definidos por uma organizao ou conjunto de organizaes (cadeias ou redes de empresas). Como exemplo, pode-se citar a metodologia de desenvolvimento de software Rational Unified Process (RUP), que ser detalhada nesse tpico, e que leva em considerao em suas etapas iniciais do projeto de desenvolvimento de software a modelagem de processos de negcio. A metodologia RUP foi escolhida como base de estudo pois uma das principais metodologias de desenvolvimento de software do mercado, sendo suportada, de acordo com a classificao apresentada no item 4.7 dessa dissertao, pela melhor ferramenta de modelagem de software do mercado que tem a UML como linguagem padro de modelagem.14 importante destacar que a viso por processos mencionada no captulo 3 est presente em alguns processos ou metodologias de desenvolvimento de software, como por exemplo, o RUP, proporcionando vantagens j citadas anteriormente como a uniformizao do entendimento e padronizao da forma de trabalho, melhoria no fluxo de informaes, reduo dos tempos e custos dos processos, etc. A constatao da viso por processos dentro da comunidade de desenvolvimento de software pode ser comprovada por alguns autores como BOOCH et al. (2000) que

14

Cabe ressaltar que alm da metodologia RUP, no sero abordadas demais variaes das metodologias

de Engenharia de Software, pois, est fora do escopo dessa dissertao.

110

afirmam que um processo, dentro da Engenharia de Software, um conjunto de passos parcialmente ordenados com a inteno de atingir a meta de entregar, de maneira eficiente e previsvel, um produto de software capaz de atender as necessidades de seu negcio. ARLOW e NEUSTADT (2002) apud JUNIOR (2003) colocam que um processo de desenvolvimento de software transforma os requisitos dos usurios em software e define quem e o que ir desenvolver, como e quando ser desenvolvido o software. J para LARMAN (2000) um processo de desenvolvimento de software um mtodo para organizar as atividades relacionadas com a criao, entrega e manuteno dos sistemas de software. Para BEZERRA (2002), um processo de desenvolvimento de software compreende todas as atividades necessrias para definir, desenvolver, testar e manter um produto de software, tendo como principais objetivos definio das atividades que sero executadas, quando, como e por quem essas atividades sero executadas. Alm disso, o autor destaca os objetivos de prover pontos de controle e padronizao do processo. Conforme colocado acima o RUP um processo de desenvolvimento de software e se baseia na UML como linguagem padro de modelagem. Assim, o RUP tem como principal meta permitir a produo de software de alta qualidade que atenda as necessidades do usurio final dentro do prazo e oramento previsto para o projeto em questo. Alm disso, apresenta as ditas melhores prticas do mercado em desenvolvimento de software dotando de uma flexibilidade para adaptao a diferentes tipos de projeto e empresas e tambm permite uma gesto disciplinada do processo atravs atribuies e controle das atividades e responsabilidades dos atores envolvidos no projeto. Para um melhor entendimento do RUP sero descritas a seguir as suas principais caractersticas incluindo suas fases, iteraes e artefatos utilizados como, por exemplo, os modelos da UML. 6.2.1 Principais Caractersticas do RUP So trs caractersticas principais que servem de base para construo do RUP: processo orientado por casos de uso, centrado na arquitetura e iterativo e incremental. A seguir essas caractersticas so detalhadas.

111

6.2.1.1 Processo Orientado a Casos de Uso Um processo orientado a casos de uso significa que os casos de uso no so artefatos ligados apenas especificao dos requisitos do sistema, servindo tambm de base para os demais fluxos de trabalho do processo de desenvolvimento. Assim, os casos de uso, pelo fato de expressarem as necessidades dos usurios do sistema, servem de base e orientam os demais fluxos de trabalho envolvidos como anlise e projeto, implementao e teste do sistema. Ou seja, todos os modelos de anlise, projeto e implementao so gerados a partir dos modelos de casos de uso que tambm orientam a construo da arquitetura do sistema. 6.2.1.2 Processo Centrado na Arquitetura Uma arquitetura de software tem relao direta com a estrutura e o comportamento dos elementos de um sistema, com a flexibilidade de reutilizao, desempenho, capacidade de recuperao e funcionalidades desses elementos, com tecnologias e custos envolvidos no projeto, com a esttica das interfaces de usurios, entre outros aspectos que envolvem um sistema. Uma das abordagens que contribui para a construo de um arquitetura flexvel o desenvolvimento baseado em componente (Component-Based Development CBD), pois facilita a gesto e a reutilizao ou customizao de componentes de software adquiridos no mercado ou desenvolvidos internamente pela organizao. Existem alguns modelos e padres de arquiteturas disponveis no mercado de software como o Modelo de Objeto Componente (Component Object Model COM) da Microsoft, o Common Object Request Broker Architecture (CORBA) do Object Management Group (OMG) e Entreprise Java Beans (EJB) da Sun Microsystems que oferecem plataformas com um ambiente adequado para o desenvolvimento, implementao, gesto e manuteno dos componentes de software. A cada iterao do processo de desenvolvimento de software possvel medir, testar e avaliar a arquitetura frente aos requisitos definidos, permitindo que a equipe envolvida evite os riscos mais importantes para o projeto. Dessa forma, para que a arquitetura de um sistema seja desenvolvida permitindo a evoluo futura do sistema necessrio que os arquitetos trabalhem com base nos principais casos de uso que

112

representam os requisitos funcionais chaves do sistema. Tambm cabe ressaltar a importncia da utilizao de padres de projeto na definio de arquiteturas. Segundo LARMAN (2000), um padro pode ser definido como um par nomeado problema / soluo, que pode ser utilizado em novos contextos, com conselhos sobre como utiliz-lo em novas situaes. Um dos padres utilizados para definio de arquiteturas com base em componentes o padro de camadas, onde um componente somente pode acessar componentes de sua camada ou na camada imediatamente abaixo, facilitando a compreenso e organizao do desenvolvimento de sistemas complexos, pois, reduz as dependncias entre as camadas j que as camadas inferiores no conhecem os detalhes de interfaces das camadas superiores, ajudando dessa forma na identificao de elementos reutilizveis. Cada camada pode ser representada por um conjunto de pacotes de classes que apresentam um mesmo nvel de generalizao e volatilidade15 em interfaces. Tambm importante ressaltar que um componente ou um conjunto de componentes de software representam um conjunto de artefatos fsicos (fichrios de cdigo, de documentos com regras de negcio, etc.) que implementam um sistema e por conseqncia todos os requisitos de negcio definidos nas fases de concepo e elaborao, onde so definidos os objetivos estratgicos, as regras e os processos de negcio envolvidos com o sistema. 6.2.1.3 Desenvolvimento Iterativo e Incremental Os processos clssicos de desenvolvimento de software, conforme pode ser observado na figura abaixo, costumam seguir o ciclo em cascata onde existe uma abordagem linear de desenvolvimento iniciando com a modelagem de negcio, levantamento de requisitos, anlise e projeto, implementao e teste.

15

As camadas mais baixas conservam por mais tempo suas interfaces, pois esto relacionadas a

aplicaes mais genricas, enquanto que as mais altas tratam de necessidades especficas da aplicao e possuem interfaces menos estveis.

113

Modelagem de Negcio Levantamento de Requisito

Anlise e Projeto

Implementao

T este

Implantao

Figura 48: Modelo Cascata de Desenvolvimento de Software Fonte: Fonte: Adaptada de BEZERRA (2002)

A grande desvantagem desse tipo de abordagem est no adiamento dos riscos inerentes ao processo tornando tardia e cara a correo de erros de fases anteriores. Como opo a abordagem em cascata, surge o processo iterativo e incremental. Essa abordagem tem como base o modelo espiral onde os riscos que envolvem o projeto so identificados com antecedncia no ciclo de vida, possibilitando uma reao mais pontual e eficiente aos riscos a cada iterao. Alm da identificao antecipada dos riscos que envolvem o processo, esta abordagem tambm apresenta outras vantagens como uma melhor monitorao e controle do projeto a cada teste de iterao, aprendizado contnuo dos envolvidos com o projeto com uma melhoria contnua do processo, distribuio mais uniforme da carga de trabalho da equipe como um todo, identificao antecipada de inconsistncias entre requisitos, construes e

implementaes, o maior contato com o usurio final que participa e valida os requisitos definidos em vrios momentos do ciclo de vida, etc. Para cada iterao, so identificados e especificados os principais casos de uso que sero implementados ao final da iterao, so criados os modelos de projeto do sistema com base na arquitetura definida, esses modelos de projetos so implementados atravs de componentes de sistemas e, por fim, tais componentes so testados de acordo com as funcionalidades definidas pelos casos de uso. Caso as funcionalidades testadas ao final de uma iterao sejam validadas, o desenvolvimento prossegue com uma nova iterao que contemplar novas funcionalidades e aperfeioar outras em

114

desenvolvimento. Caso ao contrrio, as decises tomadas devem ser revistas, tentandose uma nova abordagem. As figuras abaixo ajudam na compreenso da abordagem iterativa e incremental.

Figura 49: Um Processo Iterativo e Incremental Fonte: Adaptada de KRUCHTEN (2003)

Modelagem de Negcio Levantamento de Requisito

Modelagem de Negcio Levantamento de Requisito

Modelagem de Negcio Levantamento de Requisito

Anlise e Projeto

Anlise e Projeto

Anlise e Projeto

Implementao

Implementao

Implementao

Teste

Teste

Teste

Implantao

Implantao

Implantao

Figura 50: Abordagem Iterativa e Incremental Fonte: Adaptada de BEZERRA (2002)

Alm dessas trs caractersticas principais, o RUP engloba demais caractersticas que tambm so consideradas como as melhores prticas de software do mercado, a saber (KRUCHTEN, 2003): 115

Gesto de Requisitos de um sistema de software Os requisitos para a construo de sistemas de softwares representam uma condio ou capacidade que um sistema deve possuir para atender aos objetivos estratgicos para o qual foi concebido, assim como as necessidades dos usurios envolvidos. Alm disso, cabe ressaltar que nem todos os requisitos sejam funcionais ou no, so definidos num nico momento, sendo necessria uma gesto dinmica e contnua para identific-los, avali-los e reformul-los durante o desenvolvimento do sistema. A adequada gesto de requisitos pode evitar riscos e problemas tpicos de um processo de desenvolvimento de software atravs da identificao antecipada de inconsistncias, do estabelecimento dos critrios de priorizao dos requisitos, da avaliao objetiva de funcionalidades e desempenhos do sistema, etc.

Modelagem com a UML A modelagem visual ajuda a entender a complexidade de um sistema, principalmente quando suportada por uma linguagem padro de mercado como a UML, facilitando a uniformizao de entendimentos a todos envolvidos no desenvolvimento, mantendo consistncia entre os artefatos (modelos da UML) relacionados com os requisitos, a construo e a implementao. Em sendo apoiada por uma boa ferramenta de modelagem possvel, dentro da lgica iterativa, sincronizar os modelos e o cdigo-fonte a cada iterao, identificar arquiteturas no modulares e inflexveis, aumentar a qualidade da aplicao, estabelecer nveis de detalhamento adequados, etc.

Verificao Contnua da Qualidade do Software Segundo KRUCHTEN (2003), os problemas de software so de 100 a 1000 vezes mais custosos de serem solucionados aps a entrega do sistema. Por isso, torna-se fundamental uma avaliao contnua da qualidade das funcionalidades atravs de testes iterativos em pontos crticos que envolvem os principais cenrios e cdigos desenvolvidos. Tambm importante avaliar o desempenho e confiabilidade do sistema, entre outros aspectos que contribuem para identificao antecipada de inconsistncias,

116

reduzindo-se de forma radical os custos relacionados aos problemas encontrados. Controle de Mudanas do Software crucial existir uma coordenao adequada das atividades e artefatos gerados pelos diversos membros das equipes envolvidas no projeto para evitar o caos e, portanto, a falta de controle do processo de desenvolvimento. Assim, importante que a cada concluso de uma iterao exista uma linha base testada que permita rastrear e identificar os elementos de software impactados pelas mudanas. 6.2.2 O Ciclo de Vida de um Sistema no RUP O RUP consiste de vrios ciclos durante a vida de um sistema, sendo que cada ciclo apresenta como resultado uma verso do sistema pronta para operao e subdividido em quatro fases, concepo, elaborao, construo e transio. Alm disso, em cada fase ocorrem vrias iteraes, sendo que cada iterao representa um ciclo de desenvolvimento, que passa pelos seguintes fluxos de trabalho: modelagem de negcio, requisitos, anlise e projeto, implementao e teste. Conforme pode ser observado na figura abaixo, essa lgica estruturada em duas dimenses, onde o eixo horizontal representa o tempo e mostra, atravs das fases, de que forma os aspectos do ciclo de vida do sistema se desdobram e o eixo vertical representa os fluxos de trabalho que agrupam logicamente as atividades por natureza.

Figura 51: Estrutura do RUP Fonte: Adaptada de KRUCHTEN (2003)

117

Os prximos tpicos descrevem brevemente as fases do RUP com os principais fluxos de trabalho e artefatos envolvidos. 6.2.3 Fases da Metodologia Para BOOCH et. al (2000), uma fase pode ser definida como um perodo de tempo entre dois importantes marcos do processo de desenvolvimento em que um conjunto bem definido de objetivos alcanado, artefatos so concludos e decises so tomadas em relao a passagem para a fase posterior. A seguir so descritas as fases e suas principais caractersticas. 6.2.3.1 Concepo Segundo BOOCH et.al (2000), durante a fase de concepo, tambm conhecida como fase de incio ou de origem, so definidos critrios de sucesso do projeto incluindo avaliao dos riscos, estimativa e alocao de recursos e um planejamento dos principais pontos de controle do projeto. Para KRUCHTEN (2003), os principais objetivos dessa fase so: estabelecer o escopo do projeto delimitando o que deve ou no estar no produto, descriminar os casos de uso crticos do sistema que serviro de referncia para as demais fases do processo, mostrar pelo menos uma proposta de arquitetura candidata perante os casos de uso crticos, estimar o custo global e os riscos do projeto. Nesta fase se inicia o levantamento e a modelagem dos processos de negcio e dos requisitos de negcio que devem ser convertidos em casos de uso de sistema. Como um dos principais artefatos gerados nessa fase, pode-se citar o documento de Viso do Projeto, responsvel por expor os riscos, as funcionalidades do sistema, os fatores crticos para o sucesso do projeto, os propsitos e objetivos do negcio, as regras de negcio, etc. Outros artefatos podem ser citados como resultado dessa fase como um glossrio do projeto, modelo de domnio, modelo preliminar com a listagem dos casos de uso e atores identificados num primeiro momento, prottipos, entre outros. Conforme pode ser observado na figura acima, os principais fluxos de trabalho envolvidos nessa fase so a Modelagem do Negcio e Levantamento de Requisitos. A proposta de modelagem de negcio no RUP leva em considerao tcnicas de engenharia de software para levantar e modelar diversos aspectos estruturais e 118

comportamentais de uma organizao com intuito de entender melhor o domnio do negcio atravs de seus objetivos estratgicos, seus recursos, suas regras e processos de negcio, sua estrutura organizacional, entre outros aspectos que agregam valor na definio de um sistema de informao. Os principais modelos da UML envolvidos nessa fase so o modelo de casos de uso de negcio e o modelo de objetos de negcio16. Alm desses modelos, existem outros artefatos como documentos que definem a viso, as regras, a arquitetura, o glossrio do negcio, entre outros. No fluxo de trabalho de requisitos so identificados os requisitos mais relevantes para definio do escopo e da arquitetura do sistema. Com base na modelagem de negcio, os analistas de sistemas podem atravs dos modelos de casos de uso de negcio e de objetos de negcio identificar os principais casos de uso de sistemas e seus respectivos atores tendo como resultado o primeiro modelo de caso de uso de sistema. Alm disso, importante ressaltar que dentro do fluxo de trabalho de requisitos so levantados requisitos funcionais e no funcionais. Os funcionais so todos aqueles que refletem as necessidades diretas dos usurios do sistema e que, portanto, definem o comportamento e aes que o sistema deve executar. J os requisitos no funcionais esto ligados a demais atributos no relacionados diretamente as funcionalidades do sistema como, por exemplo, performance, confiabilidade, etc. Conforme pode ser observado em KRUCHTEN (2003), existem atributos necessrios da qualidade de um sistema de software que so definidos no modelo FURPS cujo significado apresentado na tabela a seguir.

16

Esse modelo representa a maneira como os processos de negcio (casos de uso) so implementados

internamente, descrevendo atravs de diagramas de atividades, classe e de interao, os trabalhadores do negcio, as entidades de negcio e os relacionamentos entre eles, mostrando de que maneira os processos de negcio so realizados.

119

Tabela 2: Modelo FURPS de classificao de requisitos

Tipo de Requisito
Functional (Funcional) Usability (Usabilidade)

Definio
Funes, segurana e capacidade do sistema. Fatores humanos (esttica, facilidade de uso e aprendizado), documentao de usurio e materiais de treinamento.

Reliability (Confiabilidade)

Freqncia de falhas, recuperao, previsibilidade e preciso.

Performance (Performance)

Tempo de resposta, de recuperao, de uso de recursos como, por exemplo, uso de memria para execuo de uma determinada ao do sistema.

Supportability (Suporte)

Manuteno, capacidade de testes e adaptabilidade.

Fonte: O autor

Ainda na fase de concepo, existem outros fluxos de trabalho relacionados como anlise e projeto em que criado, a partir dos casos de uso de sistema modelados no fluxo de requisitos, um modelo inicial de anlise com a identificao de algumas classes e seus relacionamentos sendo o primeiro passo para obteno da viso da arquitetura do sistema. Alm disso, dentro desse mesmo fluxo de trabalho e criado, com base no modelo de anlise, um modelo de projeto inicial com a identificao de algumas poucas classes de projeto. Os fluxos de implementao e teste que no apresentam muita relevncia nessa fase, dado que os objetivos principais da fase de definio do escopo do sistema e descrio inicial de sua arquitetura so alcanados entre os fluxos de modelagem de negcio e projeto. 6.2.3.2 Elaborao BOOCH et.al (2000) coloca que as principais metas da fase de elaborao so a anlise do domnio do problema, a definio de uma arquitetura slida, o desenvolvimento do plano do projeto e a eliminao dos principais riscos do projeto. Segundo KRUCHTEN (2003) os principais resultados dessa fase so:

120

Um modelo de caso de uso com a maior parte (pelo menos 80%) dos casos de uso, atores e descries dos casos de uso definidos; Levantamento da maioria dos requisitos que no estejam associados diretamente aos casos de uso como, por exemplo, os requisitos no funcionais; Uma descrio da arquitetura de software. Um prottipo arquitetnico executvel; Uma lista de riscos revisada; Um plano de desenvolvimento para o projeto global com estabelecimento de critrios de avaliao para cada iterao; Um manual de usurio preliminar.

Ao final dessa fase, com os resultados acima, possvel visualizar de forma detalhada o escopo e os objetivos do sistema, a arquitetura escolhida e as solues para os principais riscos do projeto. Dessa forma, possvel estimar com preciso os custos e o cronograma para o projeto, alm de avaliar o prosseguimento para a prxima fase, a fase de construo. Os principais fluxos de trabalho dessa fase so requisitos e, principalmente, anlise e projeto. Nessa fase, as atividades do fluxo de trabalho de requisitos esto relacionadas identificao de casos de uso adicionais que no foram identificados na fase de concepo. O modelo de casos de uso elaborado nessa fase deve ter em torno de no mnimo 80% dos casos de uso referentes ao sistema com as respectivas descries dos casos de uso principais para embasar a compreenso dos requisitos funcionais e a criao da arquitetura do sistema. As atividades do fluxo de anlise e projeto esto voltadas para os casos de uso significantes para a arquitetura do sistema, onde os modelos de anlise e projeto da fase de concepo so refinados com a definio de classes de anlise e de projeto, seus relacionamentos e atributos. Nessa fase tanto a anlise quanto o projeto so realizados num nvel arquitetural envolvendo casos de uso, classes, pacotes e subsistemas importantes para arquitetura. importante destacar o papel do arquiteto dentro do projeto do sistema, pois ele realiza o projeto da arquitetura em camadas, onde as camadas mais baixas representam os mecanismos em que o sistema ir operar como, por

121

exemplo, sistemas de banco de dados e as camadas mais altas prximas s aplicaes da arquitetura e, portanto, prximas aos usurios do sistema. Os fluxos de trabalho de implementao e teste na fase de elaborao tm como principais objetivos implementar e testar, com base no modelo de projeto, os elementos da arquitetura do sistema, incluindo requisitos funcionais e no funcionais como, por exemplo, performance do sistema. 6.2.3.3 Construo na fase de construo em que o sistema, enquanto produto completo, desenvolvido estando pronto para a operacionalizao e transio aos usurios. Segundo KRUCHTEN (2003) os principais resultados dessa fase so o produto de software integrado com as plataformas adequadas e os manuais de usurios com a descrio do sistema. Durante essa fase, no que se refere ao fluxo de trabalho de requisitos, so detalhados os casos de uso remanescentes e so construdos prottipos de interface com usurio. Com relao ao fluxo de anlise e projeto tanto os modelos de anlise quanto de projeto devem ser complementados com os casos de uso remanescentes para todos os casos de uso sejam contemplados na arquitetura do sistema. O fluxo de implementao se caracteriza como principal fluxo de trabalho dessa fase, pois, com base no modelo de projeto revisto e atualizado no fluxo anterior, implementa o sistema em termos de componentes de software, ou seja, cdigo fonte, arquivos executveis, entre outros. Por fim, no fluxo de teste onde ocorrem os testes da primeira verso operacional do sistema. 6.2.3.4 Transio O principal objetivo dessa fase disponibilizar inicialmente uma verso beta do sistema para a comunidade de usurios para identificao de questes que requerem algum desenvolvimento adicional com objetivo de ajustar o sistema para o lanamento da verso final que entrar em produo. Outras questes tambm so levadas em considerao nessa fase como, por exemplo, o treinamento dos usurios, a migrao de 122

dados do legado para o novo sistema, entre outras. Ao final dessa fase, os objetivo do ciclo de vida do projeto so avaliados, determinando a necessidade de se iniciar um outro ciclo de desenvolvimento e as lies aprendidas com o projeto so assimiladas para projetos futuros.

6.3 Consideraes Finais

Neste captulo foram apresentadas algumas das principais etapas para modelagem de processos de negcio e algumas das principais caractersticas dos processos de desenvolvimento de sistemas, tomando como referncia o RUP da empresa Rational Software. Foram mostradas as fases de desenvolvimento de um sistema de software e seus respectivos artefatos. Atravs dessa metodologia, foi possvel entender de que forma os diagramas da UML so utilizados na criao de um software, incluindo fluxos de trabalho como a "Modelagem de Negcio" que utiliza os diagramas de casos de uso para modelar processos de negcio. Foi verificado que o RUP enquanto processo de desenvolvimento de sistemas, apesar de apresentar um fluxo de trabalho denominado de "Modelagem de Negcio" ainda apresenta algumas deficincias com relao modelagem de processos de negcio, pois, utiliza como base para modelagem de processos de negcio o modelo de casos de uso que apresenta limitaes como, por exemplo, a no visualizao do fluxo de controle dos processos. Alm disso, no utiliza nenhum tipo de modelo para explicitar os objetivos estratgicos que devem suportar os processos e no apresenta nenhuma proposta de uma arquitetura de negcio quebrada em vistas, o que dificulta a compreenso e a anlise de um negcio.

123

PROPOSTA PROCESSOS

METODOLGICA E REQUISITOS

DE DE

MODELAGEM NEGCIO

DE

PARA

DESENVOLVIMENTO DE SISTEMAS
Nesse captulo ser apresentada uma proposta de metodologia de modelagem de processos de requisitos de negcio para desenvolvimento de sistemas, considerando alguns dos principais modelos tradicionais da EPN e da UML.

7.1 Modelagem de Negcio para Sistemas Principais Fases a Artefatos

ERIKSSON e PENKER (1999) colocam que a modelagem de negcio utilizada para os seguintes aspectos da modelagem de software:

Identificar informaes de sistemas que possibilitem um melhor suporte a operao do negcio; Identificar requisitos funcionais atravs de um conjunto correto de funes ou casos de uso que o sistema deve fornecer aos processos de negcio; Identificar requisitos no funcionais que no so especificados nos casos de uso como, por exemplo, questes relacionadas a segurana, tempo de acesso, desempenho, qualidade, entre outros. Identificar classes de negcio candidatas a se tornarem classes de sistemas como, por exemplo, um ator de um caso de uso. Identificar componentes de negcio que possam encapsular uma especfica funcionalidade de negcio de tal forma que possa ser reutilizada para diferentes propsitos de modelagem de negcio e que possam ser desdobrados em componentes tcnicos, ou seja, componentes de software.

A figura abaixo ajuda a entender melhor o relacionamento entre o processo de modelagem de negcio e o processo de desenvolvimento de sistemas de informao, mostrando que os processos de negcio devem estar relacionados com os objetivos de uma organizao para que possam ser modelados de forma consistente com a estratgia adotada e para que possam gerar requisitos funcionais e no funcionais mais consistentes com o negcio, o que leva ao desenvolvimento de sistemas de informaes 124

alinhados tanto aos processos de negcios quanto aos objetivos estratgicos da organizao.

<<goal>> Eliminao do problema: Objetivo qualitativo <<abstract>> Objetivos e vises do negcio <<abstract>> Problema <<abstract>> Estratgias Desc_Objetivo: Para melhorar o negcio e seus sistemas eliminando todos os problemas percebidos durante a nalise.

<<process>> <<abstract>> Contexto Modelagem de Processsos de Negcio

<<abstract>> Melhorias no negcio

<<information>> Requisitos funcionais e no funcionais do sistema

<<process>>

Desenvolvimento de Sistemas de Informao

<<physical>> Sistema Legado

<<abstract>> Documentao existente e modelos

<<abstract>> Padres de Projeto

<<abstract>> Conhecimento

<<physical>> Novos componentes

Figura 52: Diagrama de Processos mostrando a relao entre Processos de Negcio e Sistemas Fonte: Adaptada de ERIKSSON e PENKER (1999)

Apresentado o RUP e algumas abordagens de metodologia de modelagem de processos de negcio, este tpico tem como principal objetivo comparar as abordagens citadas e estabelecer uma transio mais clara das informaes levantadas na modelagem de um negcio para a modelagem de um sistema de informao. Para melhor compreenso dessa modelagem de negcio para sistemas, sero utilizados os modelos da metodologia ARIS e os modelos da UML. Conforme foi possvel observar na figura abaixo, um projeto cuja modelagem de processos de negcio est orientada para desenvolvimento de sistemas pode ser dividida em cinco etapas (Definio do Mapa Estratgico, Desenvolvimento da Estratgia e Arquitetura, Modelagem dos Processos Atuais, Anlise e Redesenho dos Processos Futuros e Implementao dos Processos Futuros). Comparando essas etapas com os fluxos de trabalho do RUP, conforme observado na figura abaixo (Modelagem de Negcio, Levantamento de Requisitos, Anlise e Projeto, Implementao e Teste) pode125

se dizer que a etapa de Modelagem de Negcio do RUP deveria contemplar as quatro primeiras etapas: Definio do Mapa Estratgico, Desenvolvimento da Estratgia e Arquitetura, Modelagem dos Processos Atuais e Modelagem dos Processos Futuros. Todas as informaes documentadas nessas trs etapas servem de requisitos de negcio para o desenvolvimento de sistemas. Porm, a modelagem de negcio no RUP realizada com base em tcnicas de modelagem de software, mais especificamente os casos de uso de negcio, para representar processos de negcio. Mas, esta proposta apresenta limitaes quanto a representao e modelagem dos fluxos dos processos de negcio e suas integraes e quanto ao alinhamento dos casos de uso identificados com os objetivos do negcio. Na figura abaixo possvel visualizar essa comparao.

126

Modelagem de Processos de Negcio

Definio do Mapa Estratgico

Desenvolver Estratgia e Arquitetura

Modelagem dos Processos Atuais

Anlise e Redesenho dos Processos Futuros

Implementao dos Processos Futuros

Modelagem de Sistemas de Informao

Modelagem de Negcio

Levantamento de Requisito

Anlise e Projeto

Implementao

Teste

Implantao

Figura 53: Anlise comparada entre etapas de Modelagem de Processos de Negcio e de Desenvolvimento de Sistemas Fonte: O autor, adaptada de IDS SCHEER (2002)

Cabe ressaltar que essa dissertao no pretende detalhar na metodologia proposta as fases de Implementao, Teste e Implantao bem como seus artefatos. Assim, o foco principal ser dado nas fases de Concepo e Elaborao do RUP no que se refere aos fluxos de Modelagem de Negcio, Levantamento de Requisitos e parte da fase Anlise e Projeto considerando apenas o diagrama de classes que envolve os principais conceitos do negcio.

127

Conforme a figura acima mostra, a fase de Modelagem de Negcio pertencente metodologia de modelagem de sistemas de informao deve contemplar o levantamento e modelagem das diretrizes estratgicas que devem ser sustentadas e associadas aos processos de negcio modelados. Dessa forma, considerando a lgica de melhoria contnua dentro de um processo de desenvolvimento de sistemas iterativo e incremental, a fase de Anlise de Redesenho dos Processos de Negcio, pertencente metodologia de modelagem de processos de negcio, seria a fronteira entre a especificao do negcio realizada pelo Analista de Negcio e a especificao funcional de sistemas realizada pelo Analista de Sistemas. Assim, a fase de modelagem de negcio como um todo deve contemplar de forma satisfatria o levantamento dos requisitos de negcio necessrios para que o Analista de Sistema possa fazer anlise e projeto do sistema de forma consistente com as necessidades do negcio. Logo, boa parte dos artefatos levantados na fase de Levantamento de Requisitos deve ser de responsabilidade do Analista de Negcio, estando, portanto, essa fase relacionada de forma estreita ou at mesmo sendo parte da fase Modelagem de Negcio, o que faz com que estas fases possam ser definidas em uma nica fase denominada de "Modelagem e Levantamento de Requisitos de Negcio". Em seguida deve ser executada a fase de "Anlise e Projeto" onde o Analista de Sistema, com base nos artefatos gerados na fase "Modelagem e Levantamento de Requisito de Negcio", identifica as classes de objetos que representam os principais conceitos do negcio, bem como seus atributos e operaes. importante observar que dentro da lgica iterativa e incremental estabelecida pelo RUP, todos os artefatos gerados nessas fases devem ser definidos na fase de Concepo e se necessrio refinados na fase de Elaborao. Nos tpicos a seguir, so descritas as fases de Modelagem e Levantamento de Requisitos de Negcio e os artefatos relacionados s mesmas. 7.1.1 Modelagem e Levantamento de Requisitos de Negcio Nessa fase devem ser levantados os objetivos, processos e recursos do negcio, considerando as oportunidades de melhoria relacionadas aos processos de negcio atuais, para que estes possam ser remodelados numa situao futura e que a partir deles possam ser derivados os casos de uso.

128

Na figura abaixo possvel visualizar de que forma deve ser executada essa fase, mostrando as principais atividades que devem ser executadas pelo Analista de Negcio para que se elabore uma especificao de negcio adequada ao desenvolvimento de sistemas de informao. Para a representao desse processo, foi utilizado o modelo EPC da ferramenta ARIS Toolset17.
Necessidade de definio do negcio Analista de Negcio Modelar objetivos do negcio Modelo de Objetivos

Analista de Negcio

Modelar processos de negcio atuais

Modelos de processos atuais

Analista de Negcio

Identif icar necessidade de melhorias

Lista de Problemas e Solues

Analista de Negcio

Modelar processos de negcio futuros

Modelos de processos futuros

Analista de Negcio

Derivar casos de uso dos processos

Modelos de Casos de Uso

Analista de Sistema

Modelar diagrama de classes conceitual

Modelo de Classes

Requisitos de negcio levantados

Fase de Anlise e Projeto

Figura 54: Fluxo de Modelagem e Levantamento de Requisitos de Negcio Fonte: O autor.

Conforme pode ser observado no fluxo acima, o primeiro passo a ser realizado pelo Analista de Negcio a definio dos objetivos da organizao com um todo, desdobrando, de forma hierrquica, esses objetivos em sub-objetivos, mostrando as relaes de dependncia desde os objetivos estratgicos at os operacionais. Aps a

17

O modelo EPC e suas notaes foram explicados no tpico 3.3.4 e foi utilizado para descrever os

demais processos listados abaixo.

129

identificao dos objetivos deve-se associ-los aos processos de negcio que iro suport-los. importante destacar que as relaes entre objetivos e processos pode ser tanto de um para um como de um para muitos, ou seja, um processo pode estar associado a um ou mais objetivos e um objetivo pode estar associado a um ou mais processos. Como resultado dessa atividade deve-se ter um modelo de objetivos. Em seguida, o Analista de Negcio deve identificar e modelar os processos de negcio atuais descrevendo numa lgica temporal as seqncias de atividades que devem ser executadas em cada processo para se alcanar os objetivos definidos anteriormente. Alm disso, o Analista de Negcio tambm deve identificar e modelar os recursos ( sistemas, informaes de entrada e sada, unidades organizacionais responsveis, etc) que sero necessrios para execuo dos processos de negcio como, por exemplo, o modelo de organograma que define a hierarquia entre as unidades organizacionais e serve de base para definio de papis e responsabilidades na execuo dos processos de negcio, o diagrama de grfico de estados que serve de base para definir os comportamentos de determinados recursos ao longo dos processos de negcio como, por exemplo, uma ordem de servio que pode assumir diversos estados ao longo de sua "vida" til como, por exemplo, ordem de servio solicitada, em produo, cancelada, finalizada, alterada, etc. Como resultado dessa atividade tm-se os processos de negcio associados aos recursos identificados, permitindo realizar anlises para identificar oportunidades de melhorias nos processos. Na prxima atividade o Analista de Negcio deve identificar as necessidades de melhorias nos processos de negcio, devendo identificar os principais problemas, prioriz-los e solucion-los. Como exemplo de melhoria, pode-se identificar a necessidade de se automatizar carncias de suporte automatizado de informaes nos processos de negcio o que leva a definio de novos sistemas de informao, etc. Como resultado dessa atividade pode-se citar, por exemplo, uma listagem de problemas e solues (novos requisitos de negcio) que devem ser implantadas. Identificado os principais problemas e solues a serem adotadas, o Analista de Negcio deve modelar os novos processos e, caso necessrio, os novos recursos que estaro sendo implantados para execuo do negcio. Com os processos futuros identificados e com os demais requisitos de negcio identificados o Analista de Negcio deve identificar os casos de uso associados aos processos de negcio. importante ressaltar que a derivao dos casos de uso dos 130

processos de negcio muitas vezes no uma relao direta um para um, podendo ser um para muitos, ou seja, um processo ou uma atividade de um processo, dependendo do nvel de detalhamento em que estejam modelados, podem gerar apenas um ou vrios casos de uso. Alm disso, os casos de uso podem ser derivados de diferentes nveis de detalhamento. Conforme pode ser visto na figura abaixo, um caso de uso foi derivado do macroprocesso representado pelo modelo VAC e outros dois foram derivados das atividades do EPC que apresenta um nvel de detalhamento maior que o VAC.

Figura 55: Derivao de casos de uso a partir de processos de negcio Fonte: O autor.

Cabe ao Analista de Negcio identificar o nvel de detalhamento adequado para identificao e descrio dos casos de uso. As descries dos casos de uso devem considerar os objetivos dos mesmos, os fluxos de eventos normais e alternativos, as pr e ps-condies para execuo do mesmo, entre outros fatores que auxiliam na definio dos requisitos de negcio. Essas descries normalmente so feitas de forma textual. Uma discusso interessante, vivenciada pelo autor em alguns projetos de desenvolvimento de sistemas, est relacionada a papis e responsabilidades de modelagem que envolve tanto o Analista de Sistema como o Analista de Negcio. Essa discusso gira em torno da responsabilidade de modelagem dos diagramas de casos de 131

uso que so os diagramas da UML que fazem a principal ponte entre as necessidades do negcio e, portanto, dos usurios e a anlise e projeto de um sistema. Na experincia vivenciada pelo autor, os Analistas de Negcio envolvidos nos projetos inicialmente no conseguiram utilizar os diagramas de caso de uso, pois, no apresentavam domnio da tcnica de modelagem do mesmo e apresentavam resistncia em seu aprendizado pelo fato de ser uma tcnica originalmente relacionada a desenvolvimento de sistemas. Com a falta de domnio e resistncia ao aprendizado, a modelagem de casos de uso era realizada por Analistas de Sistema que acompanhavam o desenvolvimento e modelagem dos processos de negcio e interagiam de forma estreita com os Analistas de Negcio. Com o tempo, os Analistas de Negcio passaram a realizar a modelagem dos casos de uso porque perceberam que a elaborao dos diagramas de casos de uso facilitava consideravelmente o trabalho do Analista de Sistema e que as informaes contempladas nos casos de uso s poderiam ser fornecidas pelos prprios Analistas de Negcio, pois, envolviam conceitos e regras de negcio que no eram do domnio do Analista de Sistema. Logo, os Analistas de Negcio passaram a elaborar uma especificao de negcio orientada para o desenvolvimento de um sistema de informao com a utilizao dos diagramas de casos de uso o que reduziu o tempo de desenvolvimento dos sistemas, pois, reduziram os conflitos e as dvidas entre os Analistas de Negcio e de Sistema. Aps a modelagem dos diagramas de casos de uso, o Analista de Sistema deve levantar um artefato que geralmente no de domnio do Analista de Negcio que o diagrama de classes conceitual. O Analista de Sistema deve analisar os requisitos de negcio levantados para modelar o diagrama de classes conceitual e em paralelo deve tambm analisar os requisitos no funcionais levantados pelo Analista de Negcio, complement-los se necessrio e levantar outros requisitos no funcionais. Feito isso, a prxima fase seria a de "Anlise e Projeto" onde sero desenvolvidos outros diagramas voltados para implementao do sistema como, por exemplo, os diagramas de classes de sistemas. Para melhor compreenso da metodologia proposta, a tabela abaixo mostra as principais fases e artefatos que devem ser gerados pelo Analista de Negcio para a criao de uma especificao de negcio bem como as fases e artefatos que devem ser gerados pelo Analista de Sistemas para elaborao de uma especificao funcional.

132

Na fase de Modelagem e Levantamento de Requisitos de Negcio, os artefatos que devem ser gerados pelo Analista de Negcio, esto representados na tabela abaixo pela cor vermelha. J os artefatos gerados pelo Analista de Sistema esto representados pela cor amarela importante colocar que algumas vezes o artefato Requisitos No Funcionais pode ser feito em parte pelo Analista de Negcio, pois so definidos requisitos como, por exemplo, tempo de acesso s informaes e segurana do sistema que so definidos e validados de acordo com as necessidades do negcio e tambm de acordo com as tecnologias envolvidas na soluo. Porm, a responsabilidade de levantamento desse artefato do Analista de Sistema.

133

Tabela 3: Fases e Artefatos da Metodologia Proposta

Modelo objetivos do negcio nessa etapa so levantados todos objetivos e sub-objetivos estratgicos que justificam e existncia do negcio e servem de base
Maximizar participao no mercado Reduzir Custos

para a modelagem dos processos e dos sistemas de

Aumentar ndices de crescimento Melhorar qualidade Cumprir prazos de entrega

Lotes de produo

negcio.

Esse

levantamento

pode

ser

realizado
Penetrar mercado asitico Controle de Produo

T amanho dos estoques

textualmente ou graficamente como, por exemplo, pelo diagrama de objetivos. Modelo de processos e de requisitos de negcio nessa etapa so modelados os processos de negcio que so criados a partir dos objetivos estratgicos definidos
Ex.

Processos EPC Macro-processo VAC

e so ressaltados os recursos, insumos, produtos, regras de negcio e objetivos associados aos processos. Esse levantamento deve seguir os princpios de modelagem definidos, deve ser sustentado por uma boa ferramenta de modelagem de processos, podendo ser realizado por diagramas como, por exemplo, o VAC, EPC, FAD entre outros apresentados no captulo 3. Alm disso, devem ser levados com relao ao levantamento de dados, importante levantar o dicionrio de dados18 que envolve o sistema em desenvolvimento.So levantados tambm os requisitos funcionais que definem o que o sistema deve fazer e ajudam a estabelecer o escopo do sistema a ser desenvolvido. Esto diretamente atrelados as regras de negcio. Costumam ser explicitados textualmente. Nesse momento, tambm so identificados alguns requisitos no funcionais identificados tanto pelo Analista de Negcio quanto pelo Analista de Sistemas e podem ser descritos textualmente.

Ex.

18

O dicionrio de dados ajuda na definio dos campos de um sistema, considerando aspectos como

tipo do campo (alfa, numrico,..), sua descrio, tamanho, origem, se editvel ou no, entre outros.

134

Modelos de Casos de Uso aps a modelagem dos processos de negcio e identificao dos sistemas de informao que iro suportar esses processos, so
Cliente Sistema de Caixa Eletrnico Realizar Saque <<inclui>> Fornecer Identif icao Obter Extrato

identificados e descritos os casos de uso que iro representar as funcionalidades e as interfaces entre os diversos atores do processo com o sistema de informao. Esses casos de uso podem ser derivados diretamente das funes dos processos de negcio conforme pode ser observado no item 5.1.1. Modelos de Classes a partir dos diagramas de casos de uso e de seqncia possvel identificar as classes do sistema, suas operaes e atributos. Cabe ressaltar que esse diagrama de classe do tipo conceitual. Conforme observado no tpico 4.6.2, nessa perspectiva so levantados os principais conceitos que esto envolvidos no domnio que est sendo estudado e tais conceitos sero relacionados classes que iro represent-los no diagrama.
Fonte: O autor.
Empresa nome telefone endereo Atributos
Realizar Pagamento Cliente

<<inclui>>

Realizar Pedido Cliente

<<estende>> Requisitar Catlogo do Pedido

<<generaliza>> Realizar Pagamento em Dinheiro

Pedido

Cliente cdigoDoCliente limiteDeCrdito

incluirPedido( ) Operaes atenderPedido( ) 1 Agregao

Associao

Multiplicidade * Pedido, item quantidade Produto incluirItemPedido( ) calcularTotalPedido( ) Generalizao Superclasse

Chocolate

Subclasse

Papel contratante

Nome da Associao Contrata

Papel contratado

Pessoa razoSocial endereo

Emprego salrio dataContratao Classe Associativa

Na proposta metodolgica citada acima foram utilizados como exemplo de artefatos para a realizao da fase Modelagem e Levantamento de Requisitos de Negcio alguns dos modelos tradicionais da EPN como os Diagramas de Objetivo, VAC e EPC pertencentes metodologia ARIS e suportados pela ferramenta ARIS Toolset, bem como descries das regras e requisitos de negcio associados ao desenvolvimento do sistema e aos modelos de casos de uso e diagrama de classes conceitual pertencente a UML. Para melhor entender dentro da metodologia proposta a transio dos elementos entre os modelos EPC, caso de uso e diagrama de classes, foi criada a tabela abaixo que exemplifica e demonstra os principais elementos de cada modelo e suas relaes.

135

Tabela 4: Comparao entre o EPC x Casos de Uso x Diagrama de Classe.

EPC
(Elementos)

Casos de Uso
(Descrio e Di agrama)

Diagrama de Classes Conceitual

Executor
Ator

Extraem-se algumas classes conceituais

Classes

Atividade
Caso de Uso

Fonte: O autor

possvel verificar que atravs dos elementos do EPC, pode-se extrair Descrio de Casos de Uso e dessas descries pode-se extrair classes conceituais para o Diagrama de Classes Conceitual. Como apresentado acima, o elemento Executor do EPC torna-se Ator do Caso de Uso. O elemento Atividade do EPC torna-se o prprio Caso de Uso e atravs desse Caso de Uso que se extrai algumas classes conceituais para o Diagrama de Classes Conceitual.

7.2 Consideraes Finais

Nesse captulo foi proposta uma metodologia de modelagem de processos de negcio orientada para desenvolvimento de sistemas onde foi possvel utilizar como artefatos tanto modelos de negcio tradicionais como os modelos da UML. Foi proposta a juno das fases "Modelagem de Negcio" e "Levantamento de Requisitos" em uma fase denominada de "Modelagem e Levantamento de Requisitos de Negcio" cuja responsabilidade de execuo foi delegada em parte ao Analista de Negcio e em parte ao Analista de Sistema. No prximo tpico sero descritos dois exemplos baseados em experincias prticas que demonstram a metodologia proposta acima e a transio dos modelos

136

tradicionais de negcio para os modelos de caso de uso que servem de ponte e linguagem comum entre o Analista de Negcio e o Analista de Sistema.

137

CASOS DE APLICAO DA METODOLOGIA PROPOSTA

Este captulo tem como objetivo aplicar a metodologia proposta atravs da

descrio de dois casos baseados num projeto em uma empresa de TI e um outro baseado num trabalho de projeto final apresentado Pontifcia Universidade Catlica do Rio de Janeiro (PUC-RJ) no curso de Ps-Graduao em Anlise, Projeto e Gerncia de Sistemas (ROCHA, et al, 2003) que teve como base um estudo em uma empresa do setor farmacutico. importante ressaltar que o projeto realizado na empresa de TI utilizou tanto o EPC enquanto modelo de EPN e o caso de uso enquanto modelo da UML. No segundo exemplo, cabe ressaltar que o projeto apenas considerou a utilizao dos modelos da UML, no considerando demais modelos relacionados modelagem dos processos de negcio. O autor da dissertao, atravs da anlise do relatrio final do projeto e de entrevistas com seus autores complementou o projeto com os demais modelos de negcio da metodologia proposta, mostrando a transio dos requisitos de negcio para os de sistemas. Alm disso, o exemplo considera que todos os problemas e oportunidades de melhorias j foram identificadas e levantadas, partindo-se da atividade de modelagem dos processos futuros da fase "Modelagem e Levantamento dos Requisitos de Negcio". Cabe ressaltar que os exemplos foram inseridos nessa dissertao com o intuito de melhor explicitar a metodologia proposta e no pretende demonstrar todos os artefatos gerados durante o projeto, mostrando apenas aqueles mais relevantes. Alm disso, por questes de sigilo, os nomes das empresas e alguns dados foram alterados.

8.1

Descrio do Caso da Empresa de TI

A Empresa WTelcom uma organizao do setor de telecomunicaes focada no

aprovisionamento de produtos de dados e voz para o mercado de massa e corporativo. Seus clientes diretos so, em sua maioria, grandes e mdios clientes. Neste contexto, a mesma busca alcanar uma posio competitiva de liderana em custos e prazos de ativao de seus produtos frente a seus competidores. importante ressaltar que esse caso resultado de algumas experincias prticas vivenciadas em alguns projetos que foram realizados ao longo de quatro anos de trabalho na WTelcom. Alm disso, importante colocar que todos os projetos foram 138

realizados no mbito da Gerncia de Processos Operacionais da empresa, se limitando aos processos de negcio relacionados a essa rea. Um desses projetos foi utilizado como estudo de caso para a elaborao da metodologia proposta. No entanto, outro projeto realizado ao longo desse perodo de quatro anos, denominado de Componentizao e Padronizao de Processos de Negcio, serviu de base para a realizao do estudo de caso e, portanto, ser descrito brevemente a seguir. 8.1.1 Componentizao e Padronizao de Processos de Negcio Dentro da Gerncia de Processos Operacionais da WTelcom, para que um produto e seu respectivo sistema de informao seja desenvolvido necessrio elaborar uma especificao operacional, que consiste em um relatrio contendo todas os requisitos e processos do produto. Este documento passado para a rea de TI para servir de suporte construo do sistema de aprovisionamento do produto em questo. Porm, todo o processo de elaborao da especificao operacional, por vezes, no apresentava muita agilidade para colocar o produto em tempo hbil no mercado, pois reiniciava-se a cada lanamento de um novo produto, sem aproveitar praticamente nada do que j existia disponvel. Entretanto, foi identificado que os diferentes produtos construdos apresentavam processos de aprovisionamento com bastantes semelhanas, sendo que, por vezes, at diferentes aes de aprovisionamento19 de um mesmo produto, apresentavam processos muito parecidos. Com a necessidade de reduzir o tempo de desenvolvimento dos novos produtos, foram demandadas tcnicas que pudessem agilizar a modelagem e levantamento dos seus processos e requisitos de negcio, denominados de sistemas de aprovisionamento. Neste sentido, foi iniciado um projeto na empresa cuja a primeira fase consistiu na modelagem e anlise de processos com base na idia de componentizao de processos , buscando uma melhor execuo e gesto das atribuies e objetivos da gerncia responsvel pelos mesmos, subsidiando a tomada de deciso, em nvel da alta gerncia.

19

Aes de processos pode ser entendido como os tipos de processos comumente envolvidos no

setor de telecomunicaes: Ativao, Alterao, Desativao, Bloqueio, etc.

139

Desta maneira, buscou-se realizar a componentizao dos processos de aprovisionamento dos diferentes produtos, ou ainda das diferentes aes de aprovisionamento de um mesmo produto, de forma que a modelagem dos processos operacionais tornasse mais rpida tanto a divulgao dos processos internamente, como a elaborao das suas especificaes tcnicas e conseqentemente o desenvolvimento dos sistemas corporativos necessrios para o seu aprovisionamento. Durante este trabalho de componentizao de processos e com vistas componentizao de sistemas realizado na empresa WTelcom, foi possvel obter modelos padres para as diversas etapas dos processos que compem o servio/ produto, desde a sua contratao at operacionalizao e cancelamento, que devero ser seguidos, doravante, pelos analistas de processos de todas as famlias de produtos/servios da empresa. Com esta padronizao, espera-se atingir vrios benefcios no mbito da Gerncia, da rea de TI e, sistemicamente, com resultados claros nos indicadores da Gerncia envolvida no projeto. Terminada a primeira fase, foi dado incio uma outra fase onde foram levantados os principais dados/informaes referentes aos componentes de processos definidos na fase anterior. Com relao ao escopo dessa fase, ficou definido que diante do prazo estabelecido, seria dada prioridade ao levantamento dos dados das fases de aprovisionamento do Macroprocesso Padro de Ativao, resultado da primeira fase, que estivessem diretamente relacionadas s plataformas de rede e suas funcionalidades. Estas fases foram definidas e padronizadas anteriormente no Projeto de Padronizao de Processos Operacionais. Neste contexto, optou-se pelo levantamento e modelagem dos dados de algumas das fases do macroprocesso. O levantamento e modelagem dos dados das demais fases do Processo Padro de Ativao e das fases referentes s demais aes de aprovisionamento (Desativao, Cancelamento, Alterao, etc.) ficou para uma prxima fase do projeto. Como base de desenvolvimento para o projeto foram utilizados documentos j existentes como, por exemplo, o relatrio resultante da primeira fase do projeto, documentos tcnicos relacionados aos equipamentos e plataformas de rede envolvidas no aprovisionamento, documentos de marketing com premissas de desenvolvimento de

140

produtos, entre outros. Alm disso, as telas de sistemas de aprovisionamento j implantados ajudaram no levantamento das informaes. Estes documentos e mais as reunies que foram realizadas com analistas de negcio de outras reas (como, por exemplo, a rea de Engenharia), deram subsdios para os analistas de negcio da Gerncia de Processos Operacionais iniciarem o levantamento das informaes tcnicas de aprovisionamento. Assim, os especialistas de cada famlia de produto ficaram com a responsabilidade de realizar o levantamento das funcionalidades e respectivos dados das plataformas de rede envolvidas com a soluo do cliente e associ-los aos processos definidos na primeira fase do projeto. Aps a identificao dos dados para configurao de funcionalidades nas plataformas, ou nos elementos de rede de uma plataforma, realizada pelos analistas de processos da Gerncia de Processos Operacionais, foi iniciada a modelagem destes dados na ferramenta ARIS Toolset, de acordo com a metodologia adotada no escopo do projeto. Para cada famlia de produtos foram identificadas e levantadas as principais plataformas, suas funcionalidades, campos e frames (conjunto de campos) e em seguida essas informaes foram modeladas na ferramenta ARIS Toolset. O objetivo final a que o projeto se prope alcanar, no entanto, mais ambicioso, envolvendo a obteno de componentes de processos genricos que possam ser utilizados diretamente para a modelagem de processos e tambm serem desdobrados em componentes de sistemas, de forma a acelerar sobremaneira o desenvolvimento de novos servios/produtos na empresa WTelcom. O projeto teve como seu principal resultado o levantamento dos dados das principais plataformas de configurao levantadas para cada famlia de produto, detalhando esses dados em frames e campos. O mapeamento desses dados permite Gerncia de Processos Operacionais identificar de forma mais rpida as funcionalidades existentes nas plataformas podendo gerar especificaes de novos produtos num menor tempo de desenvolvimento. Alm disso, com esse levantamento possvel identificar as potencialidades dessas plataformas que podem ser utilizadas para darem suporte s solues customizadas. Os principais benefcios gerados com esse projeto esto listados abaixo:

141

Formalizao e padronizao da modelagem de processos dentro da rea de Processos Operacionais; Apoio melhoria dos processos e desenvolvimento de sistemas de suporte operao; Maior facilidade para o gerenciamento dos processos; Acelerao do desenvolvimento e adequao dos sistemas que suportam os produtos atravs da identificao e modelagem de dados por tecnologia utilizada;

Aumento da flexibilidade frente s variaes da demanda e para atender de forma rpida solues customizadas; Reduo do tempo total de desenvolvimento e operacionalizao de produtos; Melhora das interfaces processuais com respectivos fluxos de informao entre as reas de operaes, faturamento e vendas, por exemplo.

Como uma das sugestes para dar continuidade ao projeto, foi sugerido uma maior interao com a rea de TI para definio da camada de apresentao, avaliandose a utilizao dos diagramas de casos de uso da UML como linguagem comum entre as reas de negcio e de TI. No mbito desta atividade est includa a integrao das atividades de concepo de processos, desenvolvimento, implementao,

operacionalizao e manuteno de sistemas. Alm disso, demais conceitos e tecnologias relacionadas automao dos processos de negcio e definio de arquiteturas de sistemas de informao como, por exemplo, os Business Process Management Systems (BPMS), as tecnologias de workflow e integrao entre aplicativos (Enterprise Aplication Integration EAI), entre outros, devem ser considerados para viabilizar o desenvolvimento de sistemas com arquiteturas mais flexveis e centradas em processos de negcios e no somente em tecnologia de desenvolvimento. Na figura abaixo possvel visualizar a relao entre os processos de negcios, seus dados e os caso de uso.

142

REPOSITRIO DE COMPONENTES DE PROCESSOS E REQUISITOS DE NEGCIO

Opo com menor grau de granularidade

Macro-processo Macro processo

Opo com menor grau de granularidade

Diagrama de Casos de Uso

S istema de Caixa Eletr nico

Processos (EPC)

Realizar <<inclui>> Saque Fornece r Identificao Cliente Obter Extrato <<inclui>>

Diagrama de Funes (FAD)

CCR RI SP

Realizar Pagamento Cliente <<gene raliza>> Realizar Pagamento em Dinheiro Cliente

<<estend e>> Requisitar Realizar Catlogo do P edido Pedido

Dados de Entrada Configurao RI NEC

Configurar RI NEC

Dados de Sada Configurao RI NEC

Especificao de Processos e Requisitos de Negcio

Ex .

PO - Config RI NEC.doc

Sistema da Plataforma RI NEC

Figura 56: Elaborao de uma Especificao de Processos e Requisitos de Negcio. Fonte: O autor.

A seguir ser visto um caso onde foi realizado a especificao de negcio um produto da WTelcom. 8.1.2 O Caso do Produto TelVip O caso construdo com base em um dos novos produtos que foi desenvolvido e que necessitava de um sistema de suporte para sua operacionalizao. um produto de voz destinado prioritariamente ao mercado empresarial e denominado de TelVip que deve ser suportado pelo sistema denominado de Sistema de Aprovisionamento (SA). Consiste no entroncamento direto da Central da WTelcom ao cliente, permitindo a realizao de chamadas locais. Em virtude desse entroncamento, este novo servio capaz de prover um elevado grau de qualidade no escoamento do trfego, aumentando a taxa de ligaes completadas e oferecendo descontos por volume. Alm disso, este produto dever oferecer facilidade de acesso remoto para realizao de chamadas telefnicas, atravs do uso de cdigos de autorizao. Portanto, chamadas podem ser originadas de telefones fixos ou pblicos pertencentes rede Pblica de Telefonia. Essas chamadas, bem como 143

as chamadas locais, interurbanas e internacionais devero ser agregadas numa nica fatura. Foram realizadas entrevistas com os especialistas do produto para o levantamento, dos processos detalhados e dos casos de uso, principais modelos utilizados na elaborao da especificao de negcio. A seguir sero mostardas as principais etapas da metodologia proposta para esse caso. 8.1.2.1 Modelagem e Levantamento de Requisitos de Negcio Nessa fase, o Analista de Negcio deve levantar os principais objetivos do negcio que envolve o desenvolvimento do novo sistema que suportar o novo produto, deve levantar os processos e regras de negcio que suportaro o novo sistema, os requisitos funcionais e, por fim, os casos de uso. 8.1.2.1.1 Modelagem dos Objetivos do Negcio Nesse caso, no foi utilizado nenhum modelo grfico para representar os objetivos do negcio, mais precisamente os objetivos do novo produto que foi desenvolvido. Conforme pode ser observado na descrio do caso, os principais objetivos para o desenvolvimento do novo produto so: prover um elevado grau de qualidade no escoamento do trfego, aumento da taxa de ligaes completadas, oferecer descontos por volume de trfego e consolidar as chamadas locais, interurbanas e internacionais em uma nica fatura. 8.1.2.1.2 Modelagem dos Processos de Negcio Definidos os objetivos do TelVip, o Analista de Negcio teve que levantar os principais processos de negcio que suportam o produto. Dentre os principais processos de negcio que normalmente envolvem um produto de telecomunicaes (Ativao, Alterao, Cancelamento, Desativao, Correo, Bloqueio, etc) foi dado foco no processo de Ativao para simplificar e facilitar a compreenso da metodologia proposta exemplificado no caso. Antes de realizar a modelagem do processo de Ativao, foram levantados de forma textual os principais conceitos e regras de negcio envolvidas no produto como, 144

por exemplo, o conceito de Order Entry (OE) que uma ordem de servio gerada quando o servio contratado pelo cliente necessitar de atividades de construo, configurao e ativao a serem executadas na rea de operaes. Alm desse conceito, importante destacar o conceito de Ativao que pode ser definido como uma ao de processo que definir as atividades operacionais para construo e configurao de um novo servio para o cliente. Foram definidas, tambm de forma textual, algumas regras de negcio com relao ao produto como: No dever ser gerada Order Entry de aprovisionamento nos casos de alteraes contratuais e comerciais que no necessitem de interveno da rea de operaes. Toda a vez que for feita uma solicitao de aprovisionamento, a Order Entry dever ser identificada com um nmero nico. Ao ser recebida na interface do usurio do Sistema de Suporte, os dados de Order Entry passaro por uma anlise para verificar se as informaes tcnicas e operacionais so suficientes e/ou esto consistentes para execuo das atividades operacionais. Caso as informaes da Order Entry no estejam consistentes, a Order Entry ser estornada para a rea de Mercado. O estorno de uma Order Entry significa que as informaes tcnicas e operacionais devero ser revistas, corrigidas ou completadas. O servio pode at mesmo ser cancelado caso comprovada a inviabilidade. Levantados os principais conceitos e regras de negcio que estavam envolvidos no negcio, foi levantado atravs de entrevistas com os especialistas do produto o processo de Ativao do TelVip, levantando as principais atividades, executores, interfaces de processos e a lgica de controle do processo. O processo foi modelado utilizando o modelo EPC do ARIS e procurou as principais atividades para realizar a ativao do produto TelVip. Cabe ressaltar que atravs da utilizao dos modelos pr-definidos pelo projeto de componentizao de processos foi possvel modelar, em termos de processo de negcio, apenas as diferenas inerentes ao produto em questo, fato que agilizou o desenvolvimento da especificao operacional e conseqentemente a de sistemas de informao tambm. Para simplificar a compreenso do caso, este exemplo vai focar no detalhamento da atividade Analisar Order Entry, mostrando apenas a parte do processo de 145

Ativao do produto que est relacionada a essa atividade. O processo pode ser parcialmente visualizado na figura abaixo.
Elaborao da Order Entry (rea de Mercado) Order Entry (OE) elaborada Gerente de Implantao Analisar Order Entry SA

OU

Order Entry validada

Order Entry no validada

Gerente de Implantao

Construir Acesso

SA

Gerente de Implantao

Estornar Order Entry

SA

Configurador

Configurar Rede do Servio

SA

Order Entry estornada

Continuao do processo

Elaborao da Order Entry (rea de Mercado)

Figura 57: Parte do Processo de Ativao do TelVip Fonte: O autor.

Com a modelagem do processo de Ativao do produto foram levantados, de forma textual, para cada atividade os principais dados necessrios para suas execuo e as regras de negcio relacionadas. No caso da atividade Analisar Order Entry foram levantados os dados que deveriam ser analisados e validados pelo gerente de implantao como, por exemplo, os dados cadastrais do cliente, dados do contrato, dados tcnicos do produto, entre outros. 8.1.2.1.3 Levantamento de Requisitos Funcionais e No Funcionais importante ressaltar que nesse caso no foram levantados requisitos no funcionais e que os requisitos funcionais do sistema a ser desenvolvido foram levantados a partir da identificao a modelagem dos casos de uso do sistema conforme pode ser visto no tpico a seguir. 8.1.2.1.4 Identificao e Modelagem de Casos de Uso

146

Aps o levantamento do processo de negcio e dos dados necessrios para sua execuo, foi necessrio para o Analista de Negcio identificar, modelar e descrever os principais casos de uso envolvidos na elaborao do sistema de suporte ao produto. Considerando a escolha da atividade Analisar Order Entry como exemplo de aplicao da metodologia neste caso, pode ser visualizado na figura abaixo apenas a parte do diagrama de casos de uso referente s funes do Gerente de Implantao que aparecem no processo modelado acima. Em seguida pode ser visualizada a descrio do caso de uso Analisar Order Entry. importante ressaltar que o nvel de detalhamento de modelagem do Processo de Ativao, permitiu fazer a relao de uma atividade para um caso de uso. Logo, a atividade Analisar Order Entry se tornou de forma direta um caso de uso.
Analisar Order Entry

Gerente de Implantao

Construir Acesso

Figura 58: Parte do diagrama de casos de uso do produto TelVip Fonte: O autor

Descrio do Caso de Uso Analisar Order Entry

Caso de Uso: Analisar Order Entry Ator: Gerente de Implantao Pr-condio: A Order Entry deve estar no grid da fase Anlise de Order Entry Ps-condio: A Order Entry aceita ou recusada. Fluxo Normal de Eventos: O ator seleciona no Sistema de Aprovisionamento (SA) a opo de produto de voz e o nome do seu posto de trabalho. O SA exibe a tela de Anlise de Order Entry (OE) com todos os itens que esto sob sua responsabilidade. O ator seleciona o item da OE que vai ser analisado. O SA exibe os dados referentes ao item escolhido. 147

Para cada item aberto, a seqncia de passos abaixo realizada: Se todas as informaes do item estiverem OK, o ator aceita o item clicando no campo Data de Aceite. Se houver inconsistncia ou falta de dados o ator recusa o item clicando no campo Data de Recusa. Se o item foi recusado, o SA exibe uma tela onde a causa de recusa deve ser informada. O SA fecha a tela daquele item e abre a tela do prximo item daquela OE pendente de anlise. Se for o ltimo item da OE o sistema analisa: Se houver pelo menos um item que tenha sido recusado, o sistema abre o Lotus Notes e envia um e-mail para rea de Mercado contendo o(s) motivo(s) da recusa da OE. O contedo do e-mail ser composto de uma concatenao dos motivos de cada item recusado. O e-mail ser nico, no importando se mais de um item foi recusado. Se todos os itens analisados foram aceitos, o sistema encaminha todos os itens da OE para a prxima fase do processo. O ator preenche o 'Ramal' em seguida clica no boto 'Arquivar'. O sistema de suporte dever registrar o login, nome, data e hora. Fim do caso de uso.

importante ressaltar que a modelagem do diagrama de classes conceitual no foi realizada, pois o desenvolvimento do SA foi realizado de forma estruturada e no orientada a objeto. Logo, nesse caso, no houve participao direta de um Analista de Sistema na fase de Modelagem de Levantamento de Requisitos de Negcio. No prximo tpico ser visto um outro caso de aplicao da metodologia proposta.

148

8.2 Descrio do Caso da Empresa do Setor Farmacutico

O Laboratrio Zaffiman uma empresa internacional que se dedica sade do homem, foi fundada em 1910 na Holanda, baseou-se na tica e dedicou-se essencialmente na pesquisa de novas e mais seguras drogas, estabelecendo e conquistando novos conhecimentos sobre reas fundamentais da sade. O caso analisado foi focado no Setor de Manuteno da empresa, que tem como objetivo principal realizar a conservao da fbrica, pois o sistema de manuteno em operao apresentava algumas deficincias. Localizado em Nova Iguau no Rio de Janeiro, o setor responsvel pela manuteno e conservao da fbrica, atendendo aos diversos setores desta filial. No setor so realizados servios de manuteno preventiva, programada e emergencial nos equipamentos de produo, nos equipamentos de apoio e nas instalaes prediais. Possui um almoxarifado tcnico que, quando necessita, solicita a compra de material ao Setor de Compras. Seus objetivos so evitar interrupo na produo de medicamentos, evitar o risco de acidentes, evitar falha de funcionamento dos equipamentos, conservao e reparos em mobilirio, instalaes e equipamentos. Para cumprir com esses objetivos o setor conta com mo-de-obra especializada como mecnicos, eletricistas, serralheiros, encanadores, instrumentistas, marceneiros, pedreiros, pintores e bombeiros hidrulicos. O Setor de Manuteno utilizava um sistema informatizado para o seu controle. Tal sistema no atendia por completo as necessidades de seus usurios. Decorrente de diversas dificuldades como interao, processo, tecnologia ultrapassada, falta de manuteno e diversos erros internos de implementao, acabou perdendo a credibilidade gerando a necessidade do desenvolvimento de um novo sistema. Diante dos problemas apresentados acima foi necessrio construir um sistema mais confivel que permitisse planejar e controlar os servios e custos de manuteno atravs de Ordens de Trabalho (OT), melhorando assim alguns aspectos como: segurana no armazenamento de dados, aumento na preciso das informaes fornecidas pelo sistema, aumento na velocidade de execuo das tarefas, eliminao dos congelamentos do sistema e reduo do trfego na rede.

149

8.2.1

Modelagem e Levantamento de Requisitos de Negcio Esta fase deve ser executada pelo Analista de Negcio que deve levantar os

principais objetivos do negcio a serem aplicados no projeto do novo sistema, os processos e regras de negcio que suportaro o novo sistema, os requisitos funcionais e parte dos requisitos no funcionais e, por fim, os casos de uso. 8.2.1.1 Modelagem dos Objetivos do Negcio Conforme mencionado no caso, o principal objetivo do Setor de Manuteno e, portanto, do processo de manuteno a conservao da fbrica. Os sub-objetivos associados a esse objetivo principal seriam os de evitar interrupo na produo de medicamentos, evitar o risco de acidentes, evitar falha de funcionamento dos equipamentos, conservao e reparos em mobilirio, instalaes e equipamentos. Com base nessas informaes foi modelado o Diagrama de Objetivos mostrado na figura abaixo, mostrando a hierarquia entre os objetivos do Setor de Manuteno, bem como a associao desses objetivos ao processo de manuteno. O modelo escolhido para realizar a modelagem foi o Diagrama de Objetivos da ferramenta ARIS Toolset.20

Processo de Manuteno

Conservao
da fbrica

Evitar o risco de acidentes

Evitar falha de funcionamento dos equipamentos

Conservar e reparar mobilirio, instalaes e equipamentos

Figura 59: Diagrama de objetivos do Processo de Manuteno Fonte: O autor

20

Os significados dos objetos utilizados podem ser vistos no tpico 3.3.1 dessa dissertao.

150

A associao dos objetivos do negcio, desde um nvel mais estratgico at um nvel operacional, facilita a transio da estratgia desejada para a realizada, pois, os processos de negcio passam a ser executados em funo da viso e dos objetivos da organizao. 8.2.1.2 Modelagem dos Processos de Negcio De acordo com a metodologia proposta, o prximo passo a ser executado pelo Analista de Negcio a modelagem do processo de manuteno. Para realizar a modelagem do processo, o autor tomou como base as informaes e os pseudo-cdigos descritos no projeto. Conforme pode ser observado nas figuras abaixo, foram utilizados os modelos EPC e FAD da ferramenta ARIS Toolset para representao do processo e de seus insumos e produtos. Os significados dos objetos apresentados no modelo podem ser vistos no tpico 3.3.4 dessa dissertao. Logo, com a modelagem do processo de manuteno, foi possvel identificar as principais atividades, insumos, produtos e recursos envolvidos no processo como seus executores e o sistema de informao utilizado denominado de Sistema de Controle e Manuteno (SISCOM). Com o intuito de simplificar o exemplo, foram levantados apenas os dados de entrada e de sada da atividade Alocar mo-de-obra. Com relao ao levantamento dos dados importante ressaltar que esses dados devem estar presentes no dicionrio de dados Com relao aos executores importante destacar que tanto o Solicitante quanto o Executor esto representados por uma elipse que apresenta o significado do conceito de grupo e no de cargo. Ou seja, vrios cargos dentro da organizao podem solicitar um servio de manuteno e tambm execut-los. Alm disso, foram identificadas e diferenciadas as atividades manuais das suportadas pelo sistema, pois, somente as atividades com interfaces previstas com o sistema poderiam ser consideradas como candidatas a se tornarem casos de uso.

151

Necessiadade de manuteno identificada Solicitar servio de manuteno Cadastrar solicitao de servio Encaminhar servio para setor responsvel

Solicitante

Atendente da CAP

SISCOM

Atendente da CAP

SISCOM

Supervisor de Manuteno

Gerar OT

SISCOM

Supervisor de Alocar Manuteno mo-de-obra

SISCOM

Executor

Checar OT a ser executada Verificar necessidade de material para execuo da OT

OU

SISCOM

Executor

Material necessrio

Material no necessrio

Executor

Solicitar material ao Almoxarife

Almoxarife

Verificar disponibilidade em estoque

OU

Material no disponvel Avisar ao Supervisor necessidade de compra de material Solicitar compra de material Compra de material solicitada

Material disponvel

OU

Executor

OU

Supervisor de Manuteno

SISCOM

Executor

Executar OT

Executor

Entregar OT executada ao Supervisor Atualizar status da OT para concluda

Processo de Compras

Supervisor de Manuteno

SISCOM

Material comprado

Atendente da CAP

Dar baixa do servio Servio de manuteno concludo

SISCOM

Almoxarife

Receber material

SISCOM

Material disponvel

Figura 60: Processo de Manuteno Fonte: O autor.

152

Quantidade de executores

Tipos de executores Alocar mo-de-obra Quantidade de horas para tarefa Nmero da OT

Nome do executor

Figura 61: FAD Alocar mo-de-obra Fonte: o autor

Com o levantamento do processo de manuteno foi possvel identificar alguns casos de uso em potencial como, por exemplo, as atividades "Gerar OT", "Alocar mode-obra", "Encaminhar servio para setor responsvel" e todas as demais que apresentavam interface com o sistema. 8.2.1.3 Levantamento de Requisitos Funcionais e No Funcionais Nesta etapa o Analista de Negcio deve levantar todos os requisitos funcionais para o novo sistema a ser projetado. Alm disso, ele deve levantar em conjunto com o Analista de Sistema os requisitos no funcionais como, por exemplo, tempo de resposta do sistema, segurana do mesmo e etc. Abaixo pode ser vista a listagem dos principais requisitos levantados para o desenvolvimento do SISCOM.

Requisitos Funcionais

Possibilitar a desativao de um determinado cliente no sistema; Possibilitar verificao do prazo de garantia de um equipamento; Cadastrar equipamentos e setores separadamente; Emitir Log Book (documento com a relao de todos os servios executados em cada equipamento com a validao de uma assinatura eletrnica) por equipamento; Emitir listagem de clientes em ordem alfabtica; 153

Emitir listagem de clientes por grupo de equipamento; Emitir listagem de clientes por TAG; Emitir listagem de clientes por setor; Emitir listagem de clientes por centro de custo; Emitir listagem de clientes que apresentaram um nmero muito alto de manutenes emergenciais ou programadas; Emitir listagem de setores; Emitir listagem de grupos de equipamento; Emitir listagem de situaes; Emitir listagem de tipos de servio; Emitir listagem de executores; Emitir listagem de funcionrios da manuteno; Emitir listagem de servios que no viraram OTs; Emitir listagem de OTs por situao; Emitir listagem de OTs por perodo; Emitir listagem de OTs por tipo de OT; Emitir listagem de OTs por tipo de executor; Emitir listagem de OTs por funcionrio executor; Emitir listagem de OTs por solicitante; Emitir listagem de OTs por cada setor da manuteno; Emitir listagem de custo de servios por centro de custo; Emitir listagem de custo de servios por equipamentos; Emitir listagem de servios programados por executor; Emitir listagem de servios programados por solicitante; Emitir listagem de servios programados por cada setor da empresa; Emitir listagem de servios programados por cada setor da manuteno; Emitir listagem de servios programados por perodo; Emitir automaticamente OTs para servios programados; Emitir listagem de materiais de estoque por ordem alfabtica; Emitir listagem de materiais de estoque por grupo de material; Emitir listagem de materiais de estoque por tipo de material; Emitir listagem de materiais de estoque por localizao; 154

Emitir listagem de movimento de entrada e sada por material; Emitir listagem de materiais de estoque com quantidade abaixo ou igual ao mnimo estabelecido; Emitir listagem de materiais em compras;

Requisitos no funcionais

Migrar dados atuais do Sistema Administrativo para o banco de dados do SISCOM; Automatizar a confirmao de OTs concludas ou OTs canceladas para os seus respectivos solicitantes, atravs de correio eletrnico; Automatizar a emisso de OTs programadas e preventivas; Reduzir o tempo de resposta em consultas para no mximo 10 segundos; Definir design de telas intuitivo; Definir nveis de acesso permitindo a utilizao de fluxos ordenados da informao; Automatizar a transferncia das solicitaes de compras criadas no sistema do Setor de Manuteno para o sistema utilizado pelo Setor de Compras; Automatizar a transferncia das entradas de materiais (recebimento de material) executadas no sistema utilizado pelo setor de compras para o sistema do setor de manuteno; Publicar relatrios na WEB; 8.2.1.4 Identificao e Modelagem de Casos de Uso Com a modelagem do processo de manuteno foi possvel identificar as atividades candidatas a se tornarem casos de uso e os executores candidatos a se tornarem atores. Tais atividades, que podem ser observadas na tabela abaixo, so aquelas que apresentam interfaces com o sistema.

155

Tabela 5: Lista de atividades e executores candidatos a casos de uso e atores

Atividades Cadastrar solicitao de servio

Executores Atendente da CAP

Encaminhar servio para setor responsvel Atendente da CAP Gerar OT Alocar mo-de-obra Checar OT a ser executada Solicitar compra de material Atualizar status da OT para concluda Dar baixa do servio Receber material
Fonte: O autor.

Supervisor de Manuteno Supervisor de Manuteno Executor Supervisor de Manuteno Supervisor de Manuteno Atendente da CAP Almoxarife

Analisando as atividades citadas acima percebe-se que apesar de todas serem candidatas a se tornarem casos de uso, a relao pode no ser direta de uma atividade para um caso de uso. Como exemplo, pode-se citar as duas primeiras atividades "Cadastrar solicitao de servio" e "Encaminhar servio para setor responsvel". Nesse caso, pelo prprio nome das atividades j possvel intuir que a primeira atividade provavelmente possui mais passos a serem executados no sistema do que a segunda. Logo, a atividade "Encaminhar servio para setor responsvel" pode passar a ser o ltimo passo da atividade "Cadastrar solicitao de servio" que ir se transformar num caso de uso cujo ator o executor da atividade, ou seja, o Atendente da CAP. Esse exemplo foi citado para mostrar que nem sempre a relao entre atividades e casos de uso um para um. Isso vai depender do nvel de detalhamento da modelagem dos processos de negcio. Num outro exemplo, podemos encontrar uma relao um para um entre atividades e casos de uso, como o caso da atividade "Alocar mo-de-obra" que envolve uma quantidade relativa de interaes com o sistema e pode se tornar um caso de uso. Nesse caso, o executor da atividade, "Supervisor de Manuteno", se transforma no ator do caso de uso. 156

Com a identificao dos casos de uso e seus respectivos atores foi possvel construir o diagrama de casos de uso da figura abaixo.

Sistema de Controle de Manuteno

Executor

Gerar OT Atualizar OT <<estende>> Cadastrar Servio <<inclui>>

Atendente da CAP

Executor Interno Alocar Mo-de-Obra

Executor Terceirizado

Programar Tarefa

Devolver Material

Requisitar Material Supervisor Almoxarife

Solicitar Compra de Material Sistema de Compras Sistema Administrativo

Importar Dados do Sistema Administrativo

Receber Material

Figura 62: Diagrama de casos de uso para elaborao do SISCOM. Fonte: ROCHA, et al (2003)

possvel perceber no diagrama acima a presena de demais casos de uso que no podem ser diretamente derivados do processo de manuteno como, por exemplo, o caso de uso "Importar Dados do Sistema Administrativo" que se caracteriza como um requisito no funcional necessrio para manter o SISCOM sempre atualizado com os dados do Sistema Administrativo. Esse caso de uso foi modelado a partir da lista de requisitos no funcionais, mostrando que nem todos os casos de uso podem ser derivados do processo de manuteno. Tambm possvel perceber no diagrama as relaes entre os caso de uso "Gerar OT" que tem uma relao de incluso com o caso de uso "Alocar mo-de-obra" e apresenta uma relao de extenso com o caso de uso "Programar Tarefa". A relao de incluso tem como principal objetivo quebrar um caso de uso complexo em um ou mais casos de uso para facilitar o entendimento do comportamento do sistema. No exemplo citado, todos os passos descritos no caso de uso "Alocar mo-de-obra" sempre fazem 157

parte dos passos do caso de uso "Gerar OT". J a relao de extenso tem o objetivo de representar um comportamento que eventualmente ocorre como o caso de uso "Programar Tarefa. Para exemplificar como seria uma descrio de um caso de uso, foi escolhido o caso de uso "Alocar mo-de-obra" que ser descrito no prximo tpico.

Descrio de Caso de Uso Alocar mo-de-obra

Caso de Uso: Alocar mo-de-obra. Ator: Supervisor. Pr-condio: O supervisor deve estar autenticado no sistema. Descrio: Esse Caso de Uso se inicia quando o supervisor informa os dados dos executores responsveis para execuo das tarefas. Caso necessrio ser contratada mo-de-obra externa. Fluxo Normal de Eventos: Sistema solicita quantidade de executores. Supervisor informa quantidade de executores. Sistema solicita tipo de executores. Supervisor informa tipo de executores. Sistema solicita nome do executor. Supervisor informa nome do executor. Sistema obtm e exibe matrcula do executor. Sistema exibe total de horas disponveis no dia por executor. Sistema solicita quantidade de horas estipuladas da tarefa. Supervisor informa quantidade de horas estipuladas da tarefa. Sistema solicita confirmao dos dados. Supervisor confirma os dados. Sistema aloca mo-de-obra para tarefa. Fim do caso de uso. Fluxo Alternativo Passo 12 do Curso Tpico: Supervisor no confirma os dados. Supervisor solicita cancelamento do caso de uso Alocar mo-de-obra Fim do caso de uso.

158

Finalizada as descries dos casos de uso a prxima etapa seria a elaborao do diagrama de classes. Conforme pode ser visto na tabela abaixo, para facilitar a identificao das classes, recomenda-se utilizao da tabela de relacionamentos entre os modelos EPC, Caso de Uso e Diagrama de Classes.
Tabela 6: Processo de Manuteno (EPC x Casos de Uso x Diagrama de Classes)

Processo de Manuteno

EPC
(Elementos)

Casos de Uso
(Descrio e Di agrama)

Diagrama de Classes Conceitual X X

Solicitante Solicitar servio de manuteno Atendente da CAP Cadastrar solicitao de servio

Solicitante X

Atendente da CAP Cadastrar Servio

X Servio Setor Funcionrio

Atendente da CAP Encaminhar servio para setor responsvel Supervisor de Manuteno Gerar OT Supervisor de Manuteno Alocar mo-de-obra

Atendente da CAP X Supervisor de Manuteno Gerar OT Supervisor de Manuteno Alocar mo-de-obra

X X X

OT X

Tarefa Mo-de-obra

...
Fonte: O autor

...

...

159

Atravs dessa tabela j podem ser identificadas algumas classes que iro compor o diagrama de classes como, por exemplo, as classes Tarefa e Mo-de-obra que esto relacionadas atividade e ao caso de uso Alocar mo-de-obra. Logo, a associao entre as atividades e classes, conforme proposta por LOOS e ALLWEYER (1998) no tpico 5.3.1, torna possvel a reduo do tempo de implantao de novos requisitos de negcio, o que proporciona uma maior agilidade na implantao de qualquer melhoria de processos de negcio que tenham que ser refletidas nos sistemas de informao. Para exemplificar essa situao no caso do exemplo apresentado, a figura abaixo mostra a relao entre a atividade "Alocar mo-de-obra" e as classes "Tarefa" e "Funcionrio", que a implementam.

Tarefa Supervisor de Manuteno Alocar mo-de-obra

Funcionrio

SISCOM

Figura 63: Atividade Alocar mo-de-obra e classes associadas Fonte: O autor

Com esse mapeamento, que deve ser realizado pelo Analista de Sistema, possvel identificar, atravs do diagrama de seqncias, as principais classes do SISCOM que interagem com a atividade Alocar mo-de-obra. 8.2.1.5 Modelagem do Diagrama de Classes O diagrama de classes do projeto buscou demonstrar os principais conceitos do sistema, estando classificado, conforme pode ser observado no tpico 4.6.2, na perspectiva conceitual sendo, portanto, independente da linguagem de implantao. Na figura abaixo possvel visualizar apenas parte do diagrama de classes que est relacionada com o caso de uso descrito acima "Alocar mo-de-obra".

160

Solicitante Trabal ha 1..* Ramal Criar() ObterDados() 1

Funcionario Matricula Nome Cargo ObterDados() 1 Setor de Manute 1 Cadastra

Solicita Necessita

1..* Setor de M anuteno Supervisor ObterSupervisor() 1 0..* Necessita 0..* Encaminha 1..*

0..* Servio Numero Descricao DataSolicitacao PerdaProducao DataPrevistaInicio Situacao Cri ar() SalvarSituacao() Cri arTarefa() GerarNumero() SalvarDataSolicitacao() ObterEquipamento() Encaminhar() 1 0..* 0..* 1 Tipo Executor Codigo Nome 0..1 Prioridade de Servi o Codigo Nome 1..* Seto Obte Obte

Material

0..*

Empresa Codigo Nome

Aloca

Sobressalente 1 0..* nto 0..* Tarefa Externa AlocarMaodeObraExterna() 1 1

T arefa Descricao DuracaoPrevista DataPrevi staInicio Criar() AlocarMaoDeObra() GerarOT () ObterDados() Programar() 0..* Roteiro 0..* T arefa Programada NumeroDias QuantidadeExecutores

Gera O

Figura 64: Diagrama de classes para elaborao do SISCOM Fonte: ROCHA, et al (2003)

161

A definio das classes que representam os principais conceitos do sistema e a representao e descrio dos casos de uso facilitam a modelagem dos diagramas de seqncia que so importantes para a visualizao da realizao dos casos de uso e para, se caso necessrio, a reavaliao do diagrama de classes.

8.3

Consideraes Finais
Este captulo mostrou aplicaes da metodologia proposta para modelagem de

processos orientada para desenvolvimento de sistemas e buscou mostrar de forma consistente de que maneira so gerados os principais artefatos e as relaes entre eles. Alm disso, foi possvel mostrar que possvel derivar casos de uso de processos de negcio de forma que o Analista de Negcio possa passar informaes mais consistentes para o Analista de Sistema, possibilitando a associao das classes do sistema com as atividades executadas pelos processos de negcio, o que permite uma maior agilidade na implementao de novos requisitos de negcio.

162

CONCLUSES E PERSPECTIVAS DE DESENVOLVIMENTO

9.1

Concluses
Nessa dissertao foi possvel mostrar os principais conceitos, metodologias,

ferramentas, aplicaes e ganhos da Engenharia de Processos de Negcio. Dentre os principais conceitos apresentados pode-se destacar o entendimento e a importncia da utilizao da viso por processos e da tecnologia da informao para a modelagem de um negcio. Foi possvel perceber que a anlise dos processos de negcio de uma organizao de fundamental importncia para a sua efetiva reestruturao, resultando em retornos significativos sobre os investimentos realizados. Os processos descrevem a seqncia de atividades realizadas pela empresa e, atravs delas, mostram os recursos utilizados, os produtos gerados (insumos, informaes, etc.), tempo e custo e quem as realizam. Portanto, todo processo tem incio e fim e os seus relacionamentos (inputs / outputs) so passveis de ser claramente identificados. Ao descrever seus processos, se tem a possibilidade de entender melhor a organizao e a maneira como ela opera. O surgimento de organizaes focadas nos seus processos talvez seja um marco na administrao de empresas, uma mudana de paradigma. Antes disso, o foco era na estruturao funcional, que provocava uma grande especializao dos colaboradores e uma viso compartimentada do funcionamento de toda organizao. J as organizaes orientadas por processos expem as ligaes entre as funes e possibilitam a quem exerce uma funo ter a noo mais geral de funcionamento da organizao, entendendo quais e como so as atividades antes e depois da realizada por ele. Nessas organizaes, o foco central passa a ser o cliente, isto , procura-se agregar maior valor nas atividades no que diz respeito a aumentar a satisfao do cliente. Assim, uma empresa ao levantar e modelar seus processos evidencia os seus problemas, facilita uma reestruturao organizacional e a concepo e implantao de uma arquitetura integrada de sistemas. Deste modo, uma organizao que conhece os seus processos tem maior potencial de resultados na integrao entre suas reas. Com relao ao estudo da EPN realizado foi possvel chegar aos seguintes resultados: 163

Frente aos problemas acarretados por uma viso estritamente funcional, foi possvel perceber a importncia e as vantagens da viso por processos e o papel da TI enquanto ferramenta habilitadora da construo e implantao dessa viso nas organizaes; Foi possvel perceber a importncia da existncia de um aparato metodolgico com a definio de princpios de modelagem e seleo de ferramentas de software para realizar a implantao da viso por processos. A percepo da abrangncia dos principais desenvolvimentos possveis da EPN, sendo difcil imaginar a no aplicao da TI, principalmente, no

desenvolvimento de sistemas de informao que implementam os processos de negcio. Dentre as aplicaes da EPN, foi dado destaque ao desdobramento para desenvolvimento de sistemas de informao, ressaltando a importncia da integrao e do alinhamento entre a estratgia concebida para um negcio, seus processos e os sistemas que o suportam. Para entender melhor a relao entre a EPN e sistemas de informao, foram apresentados os principais conceitos e modelos associados a Unified Modeling Language (UML), considerada pela Object Management Group (OMG) como linguagem padro de desenvolvimento de sistemas de software. Com relao ao estudo da UML e dos modelos que a suportam e levando-se em considerao seu relacionamento com os conceitos e modelos tradicionais da EPN foi possvel obter os seguintes resultados: A UML enquanto linguagem padro para desenvolvimento de software, no est amarrada a nenhum processo especfico de desenvolvimento de software e contribui em muito para aumentar a qualidade de um processo de desenvolvimento de software, pois, atravs de seus diagramas consegue expor e uniformizar os entendimentos na comunidade de desenvolvimento de software; A UML pelo fato de ter sido desenvolvida para desenvolver softwares no possui nenhum tipo de arquitetura voltada para modelagem de negcio como, por exemplo, a estrutura de vistas da metodologia ARIS, tendo como base as vistas da arquitetura da UML apresentada no captulo 4, vistas essas que foram 164

criadas para suportar conceitos de modelagem de sistemas de software e no de negcio. Foi possvel concluir que uma proposta de modelagem de negcios com os modelos da UML, apesar de apresentar vantagens de entendimento por parte dos analistas e desenvolvedores de sistemas apresenta limitaes de entendimento por parte dos analistas de negcio, pois, conforme observado na comparao com o EPC, os modelos da UML ainda -no representam de forma satisfatria alguns conceitos relacionados modelagem de negcio, sendo necessria utilizao dos mecanismos de extenso da linguagem para se criar perfis voltados para a modelagem de negcio. Foi apresentada uma proposta de extenso da UML criada por ERIKSSON e PENKER (1999,2000), onde j possvel visualizar uma proposta arquitetura dividida em vistas suportadas por modelos e extenses da UML. Essa abordagem j se aproxima mais da modelagem de processos de negcio, utilizando alguns diagramas da UML, principalmente, o diagrama de atividades, para representar conceitos inerentes aos conceitos de processos de negcio. As principais limitaes dessa abordagem so a falta de capacidade de abstrao no considerando nveis de detalhamento diferentes se limitando a um nvel macro de modelagem e a limitao para representar sistemas de informao que suportem estruturas de processos de negcio mais complexas, podendo ser eficiente para modelar sistemas de informao mais simples. Diante dos resultados acima foi identificada a necessidade de se definir uma proposta de metodologia de modelagem de processos com foco no desenvolvimento em sistemas, mesclando as principais etapas de modelagem de processos de negcio com as algumas das etapas de modelagem de sistemas de informao. Para elaborar a proposta foi necessrio realizar um estudo sobre os processos de desenvolvimento de software, tomando como base de referncia o Rational Unified Processo (RUP) como metodologia de desenvolvimento de sistemas de informao. Atravs da anlise do RUP, foi possvel entender de que forma os diagramas da UML so utilizados para a modelagem de negcio num processo de desenvolvimento de um sistema de negcio. Ao analisar o RUP, sob o ponto de vista de modelagem de negcio, foi possvel chegar as seguintes concluses: 165

O RUP trabalha na lgica de desenvolvimento iterativo e incremental o que minimiza os riscos de um projeto de desenvolvimento, possibilitando uma maior integrao entre a rea de negcios e de sistemas, o que facilita, dentro de uma lgica de melhoria contnua, a implementao de requisitos de negcio em sistemas de informao; Apesar do RUP j contemplar e reconhecer em seu processo de desenvolvimento a modelagem do negcio como sendo fundamental para o desenvolvimento de sistemas, utiliza tcnicas de modelagem de software, mais especificamente os casos de uso de negcio, para representar processos de negcio. Mas, esta proposta apresenta limitaes quanto a representao e modelagem dos fluxos dos processos de negcio e suas integraes e quanto ao alinhamento dos casos de uso identificados com os objetivos do negcio; A modelagem de negcio do RUP tambm no contempla nenhum tipo de arquitetura de negcio quebrada em vistas como as vistas da metodologia ARIS e da proposta de ERIKSSON e PENKER (1999,2000), dificultando a compreenso do negcio como um todo. Como base, a nica arquitetura que o RUP utiliza, mesma da UML onde as vistas propostas foram criadas para suportar conceitos de modelagem de sistemas de software e no de negcio.

Diante das deficincia do RUP com relao a modelagem de negcio, importante ressaltar que mapeamento dos processos de negcio pode ser bastante til para o desenvolvimento de software e devemos entender requisito como uma condio ou habilidade, da qual o usurio precisa para que seja solucionado um problema ou alcanado um objetivo. A modelagem de processos de negcio identifica a maneira como o negcio deve ser executado. A partir desta identificao, podem ser mapeados quais so os requisitos do usurio e, a partir destes, o software propriamente dito. Quando se inicia o desenvolvimento de software diretamente a partir do mapeamento do sistema, os analistas conseguem encontrar solues tcnicas, mas que muitas vezes so baseadas em artifcios puramente relativos a tecnologia que podem no atender ao negcio de forma plena, ou ainda atender de forma incorreta.

166

Boa parte dos problemas tidos como clssicos no desenvolvimento de software so originados pela no realizao deste estudo, destacando-se a instabilidade de requisitos e, conseqentemente, o contnuo aumento do escopo dos sistemas. Esta instabilidade ocorre normalmente porque os requisitos de usurio no tm justificativa slida nos processos executados pelo negcio, ou ainda porque a forma como so executados no est otimizada. Todos so beneficiados quando h realizao de modelagem de processos de negcio para subsdio do desenvolvimento do software, pois, o usurio passa a ter domnio sobre as tarefas que executa no dia-a-dia (inclusive custos) e com isso percebe com maior clareza quais so seus anseios, permitindo identificao mais segura de que o software vai atender s suas necessidades; os analistas e desenvolvedores trabalham com maior segurana e estabilidade at a entrega de seu produto final e a alterao de requisitos s justificada a partir de mudanas no negcio. Dessa forma, a metodologia proposta teve o intuito integrar de forma mais consistente os conceitos de modelagem de processos de negcio com os conceitos de modelagem de sistemas, buscando reduzir o tempo de transio dos processos de negcio para o desenvolvimento de sistemas de informao e procurando uniformizar o entendimento entre analistas de negcio e de sistemas. Para elaborar a metodologia proposta, foram utilizados alguns dos modelos tradicionais da EPN e da UML, bem como as fases de Concepo e Elaborao do RUP e alguns de seus artefatos. Os principais benefcios da metodologia proposta foram:

Diante das deficincias do RUP para modelagem de negcio foi proposta a criao de um fluxo de Modelagem de Negcio dentro da lgica do RUP, mas com base em tcnicas de EPN e no em tcnicas de modelagem de software; Foi possvel visualizar, atravs da descrio dos casos de uso, a transio entre os modelos tradicionais da EPN e os modelos da UML, mostrando que importante e possvel construir sistemas alinhados com os objetivos estratgicos definidos; Realizando a transio atravs da metodologia proposta foi possvel mapear e relacionar as classes de um sistema com as atividades envolvidas num processo 167

de negcio, o que reduz o tempo de implementao de melhorias propostas com base nos processos de negcio, pois, ao mudar uma determinada parte do processo possvel identificar com mais facilidade a parte do sistema que deve ser alterado; Foram analisados os papis do Analista de Sistema e de Negcio e com base na bibliografia levantada e na experincia prtica do autor, foi proposto que o levantamento dos casos de uso bem como suas descries e demais artefatos relacionados fase de Levantamento de Requisito do RUP fossem levantados pelo Analista de Negcio, pois, o autor acredita que a tcnica de modelagem de casos de uso de fcil assimilao, eficiente e fundamental para fazer a ponte entre a modelagem de negcio e de sistemas; Foi proposta a juno das fases "Modelagem de Negcio" e "Levantamento de Requisitos" em uma fase denominada de "Modelagem e Levantamento de Requisitos de Negcio" cuja responsabilidade de execuo foi delegada ao Analista de Negcio e em parte delegada ao Analista de Sistema. As principais limitaes da metodologia proposta foram: A derivao de processos de negcio para casos de uso nem sempre direta, variando com o nvel de detalhamento do processo modelado, ou seja, cabe ao Analista de Negcio saber o nvel de modelagem suficiente para derivar casos de uso. A definio correta do nvel de detalhamento adequado para derivao dos casos de uso varia de acordo com a experincia do Analista de Negcio e de acordo com a situao vivenciada. Nem todas as classes de negcio so identificadas e derivadas de forma direta a partir dos processos e requisitos de negcio, sendo importante a experincia e conhecimento do Analista de Sistema para a criao do diagrama de classes conceitual. A responsabilidade atribuda ao Analista de Negcio de modelar os diagramas de caso de uso pode ser uma limitao para aplicao da metodologia, pois muitos Analistas de Negcio no possuem base conceitual e experincia prtica para realizar a modelagem de casos de uso, o que, por vezes gera resistncias no 168

aprendizado dessa tcnica de levantamento de requisitos funcionais de negcio para o desenvolvimento de sistemas de informao.

9.2

Perspectivas de Desenvolvimento
Considerando que a modelagem de negcio e, portanto, a modelagem de

processos de negcio uma prtica fundamental para modelagem de sistemas podem ser sugeridas as seguintes perspectivas de desenvolvimento: Realizar uma anlise aprofundada de interfaces entre ferramentas de modelagem de processos e ferramentas de modelagem de sistemas, verificando a possibilidade de viabilizar uma maior integrao entre a rea de negcios e de sistemas de informao. Associar a metodologia proposta os conceitos de componentizao de processos e de sistemas, entendendo melhor de que forma isso pode agilizar o desenvolvimento tanto de processos de negcio quanto de sistemas de negcio; Verificar at que ponto as novas tecnologias que esto surgindo dentro do quadro conceitual de BPM, inviabilizam ou complementam o desenvolvimento tradicional de software; Complementar a metodologia proposta com as demais fases de desenvolvimento no contempladas nessa dissertao; Aplicao da proposta de extenso da UML de ERIKSSON e PENKER (2000) na metodologia definida; Estudar de que forma o conceito de Engenharia Simultnea pode ajudar na relao entre os especialistas de negcio e de sistemas, reduzindo o tempo de desenvolvimento dos sistemas de negcio.

169

10

REFERNCIAS BIBLIOGRFICAS

AALST, W. et al., 2000, Business Process Management: Models, Techniques and Empirical studies. Berlin: Springer-Verlag. Apud SANTOS, R., 2002, Engenharia de Processos: Anlise do Referencial Terico Conceitual, Instrumentos, Aplicaes e Casos com a Finalidade de Sntese sobre sua Estrutura, Conhecimentos, Falhas e Resultados. 317 p. Dissertao (Mestrado em Engenharia de Produo) COPPE, Universidade Federal do Rio de Janeiro, Rio de Janeiro. AMBLER,W., S., 1998, Anlise e Projeto Orientados a Objeto, Volume 2: Seu Guia para Desenvolver Sistemas Robustos com Tecnologia de Objetos. Rio de Janeiro: Infobook, 1 ed, 472p. ANTUNES J.; CAULLIRAUX, H.; NEVES, M., 1998, A organizao por processos. In: SAP UNIVERSE, So Paulo. ARIS Methods. Verso 6.0 Setembro 2001. IDS SCHEER AG. ARLOW, J., NEUSTADT, I., 2002, UML and the Unified Process: Pratical ObjectOriented Analysis & Design. Great Britain: Addison-Wesley. Apud JUNIOR, R., 2003, Extenses da UML para descrever processos de negcio. 95 p. Dissertao (Mestrado em Engenharia de Produo) Universidade Federal de Santa Catarina, Florianpolis. BASTOS, A.; CAMEIRA, R., 2000, Ferramentas de apoio engenharia de processos de negcios: critrios de classificao e mtodo de anlise de adequao a um projeto. In: ENCONTRO NACIONAL DE ENGENHARIA DE PRODUO, 20., So Paulo. Anais Eletrnicos... Rio de Janeiro: ABEPRO. 1 CD. BEZERRA, E., 2002, Princpios de Anlise e Projeto de Sistemas com UML. Rio de Janeiro: Campus, 1 ed, 286p. CAMEIRA, R., 2003, Hiper-Integrao: Engenharia de Processos, Arquitetura Integrada de Sistemas Componentizados com Agentes e Modelos de Negcios

170

Tecnologicamente Habilitados. 432 p. Tese (Doutorado em Engenharia de Produo) COPPE, Universidade Federal do Rio de Janeiro, Rio de Janeiro. CAMEIRA, R., 1999a, Aplicaes das Redes de Comunicao: Estratgia e Organizao. In: ENCONTRO NACIONAL DE ENGENHARIA DE PRODUO, 19. Rio de Janeiro. Anais Eletrnicos... Rio de Janeiro: ABEPRO, 1CD. __________, 1999b, Sistemas Integrados de Gesto: Perspectivas de Evoluo e Questes Associadas. In: ENCONTRO NACIONAL DE ENGENHARIA DE PRODUO, 19., Rio de Janeiro. Anais Eletrnicos... Rio de Janeiro: ABEPRO, 1CD. CAMEIRA, R.; CAULLIRAUX, H.; PROENA, A.; SANTOS, R., 2002, Componentized integrated systems architecture and business process engeneering: methodological aspects. In: INTERNATIONAL CONFERENCE ON INDUSTRIAL ENGINEERING AND OPERATIONS MANAGEMENT, 8, Curitiba, PR. Anais Porto Alegre: ABEPRO. CAMEIRA, R.; CAULLIRAUX, H., 2000, Engenharia de processos de negcios: consideraes metodolgicas com vistas anlise e integrao de processos. In:

SIMPSIO DE ADMINISTRAO DA PRODUO, LOGSTICA E OPERAES INTERNACIONAIS, 3., So Paulo. Anais Eletrnicos... So Paulo: FGV. 1CD. CAULLIRAUX, H. M.; CAMEIRA, R., 2000, A Consolidao da Viso por Processos na Engenharia de Produo e Possveis Desdobramentos. In: ENCONTRO NACIONAL DE ENGENHARIA DE PRODUO, So Paulo. Anais Eletrnicos... So Paulo: ABEPRO. 1 CD. DAVENPORT, T. H., 2000, Mission Critical: realizing the promise of enterprise systems. Boston, MA: Harvard Business School Press, 334 p. __________________, 1994, Reengenharia de Processos. Rio de Janeiro: Campus, 408 p. ERIKSSON, H.E.; PENKER, M., 1999, Business Modeling with UML. Disponvel em: http://www.therationaledge.com. Acesso em: 23.set. 2003. 171

ERIKSSON,

H.E.;

PENKER,

M.,

2000,

Business

Modeling

with

UML:

BusinessPatterns at Work. New York: OMG Press. FALCONI, V., 1999, TQC Controle da qualidade total (no estilo Japons). Belo Horizonte: Ed. Campos, 8a ed. FOWLER, M. , SCOTT, K., 2000, UML Essencial: Um breve guia para a linguagempadro de modelagem de objetos. Porto Alegre: Bookman, 2 ed., 169p. FURLAN, J., D., 1998, Modelagem de Objetos Atravs da UML The Unified Modeling Language. So Paulo: Makron Books. 1 ed, 329p. GARTNER GROUP, 2003, The BPA Market Catches Another Major Updraft. Disponvel em: http://www.gartner.com . Acesso em: 1 nov. 2003. GIL, A., C., 1991, Como elaborar projetos de pesquisa. So Paulo: Atlas. GROVER, V. & W.R. KETTINGER, 2000, Process Think: Winning Perspectives For Business Change in the Information Age. Idea Group Inc. ISBN: 1-878-28968-3. Apud SANTOS, R., 2002, Engenharia de Processos: anlise do referencial terico conceitual, instrumentos, aplicaes e casos com a finalidade de sntese sobre sua estrutura, conhecimentos, falhas e resultados. 317 p. Dissertao (Mestrado em Engenharia de Produo) COPPE, Universidade Federal do Rio de Janeiro, Rio de Janeiro. HAMMER, M. E CHAMPY, J., 1994, Reengenharia: repensando a empresa em funo dos clientes, da concorrncia e das grandes mudanas da gerncia. Rio de Janeiro: Campus, 1 ed. IDS SCHEER AG, 2000, ARIS 5 E-Business Suite Version. Heidelberg: SpringerVerlag Berlin, February. White paper. Disponvel em: http://www.ids-scheer.com . Acesso em: 12 mar. 2001. IDS SCHEER AG, 2002, System Design with ARIS HOBE and Rational Unified Process. Heidelberg: Springer-Verlag Berlin, February. White paper. Disponvel em: http://www.ids-scheer.com . Acesso em: 04 jun. 2002.

172

JACKOWSKI, Z., 2003, Business Modeling with UML: A Business Process Centrede Architecture. Disponvel em: http://www.agillealliance.com . Acesso em: 22 out. 2003. JUNIOR, R., 2003, Extenses da UML para descrever processos de negcio. 95 p. Dissertao (Mestrado em Engenharia de Produo) Universidade Federal de Santa Catarina, Florianpolis. KELLER, G.; TEUFEL, T., 1998, SAP R/3 Process-oriented Implementation. Harlow, England: Addison Weley Longman, 844 p. KRUCHTEN, P., 2003, Introduo ao RUP Rational Unified Process. Rio de Janeiro: Cincia Moderna Ltda., 255p. KULAK, D., GUINEY, E., 2000, Use Cases: Requirements in Context. New York: ACM Press, 329 p. LARMAN, C., 2000, Utilizando UML e Padres: Uma Introduo Anlise e ao Projeto Orientados a Objeto. Porto Alegre: Bookman, 492p. LOOS, P., ALLWEYER, T., 1998, Process Orientation and Object-Orientation An Approach for Integrating UML and Event-Driven Process Chains (EPC). In: Publication of the Institut fr Wirtschaftsinformatic University of Saarland, Saarbrcken, Germany, March. LOOS, P., FETTKE, P., 2001, Towards an Integration of Business Process Modeling and Object-Oriented Software Development. In:The Proceeding of the Fifth International Symposium on Economic Informatics Bucharest, Bucharest. MAYER, R. et al., 1995, Information Integration for Concurrent Engineering Compendium of Methods Report. Ohio: Armstrong Laboratory Logistics Research/ Division Wright-Patterson Air Force Base, Jun. Apud SANTOS, R., 2002, Engenharia de Processos: anlise do referencial terico conceitual, instrumentos, aplicaes e casos com a finalidade de sntese sobre sua estrutura, conhecimentos, falhas e resultados. 317 p. Dissertao (Mestrado em Engenharia de Produo) COPPE, Universidade Federal do Rio de Janeiro, Rio de Janeiro.

173

NEVES, M., 1999, A Organizao por Processos para a Gesto da Cadeia de Suprimentos. In: SAPPHIRE, Nice, Grupo de Produo Integrada/ COPPE-EE/ UFRJ. NTTGENS, M., FELD, T., ZIMMERMANN, V., 1997, Business Process Modeling with EPC and UML Transformation or Integration?, In: Schader, M.; Korthaus, A. (Hrsg): The Unified Modeling Language Technical Aspectes and Apllications, Proceedings, Heidelberg. OMG Unified Modeling Language Specification, 2003,Version 1.5, March. Disponvel em: http://www.omg.org . Acesso em: 03 abril. 2003. PIDD, M., 1998, Modelagem Empresarial: ferramentas para tomada de deciso. So Paulo: Bookman, 316 p. PRASAD, B., 1996, Concurrent Engineering Fundamentals: integrated product and process development. v. 1. New Jersey, Prentice Hall, 321p. RATIONAL SOFTWARE, 2001a, Best Practices for Software Development Teams White paper. Disponvel em: http://www.rational.com . Acesso em: 19 abr. 2002. RATIONAL SOFTWARE, 2001b, Business Modeling with UML and Rational Suite AnalystStudio. White paper. Disponvel em: http://www.rational.com . Acesso em: 14 mai. 2002. REMENYI, D. et al., 1998, Doing Research in Business and Management. Wiltshire, England: Sage Publications, 309p. ROCHA, A., SILVA, E., ARRUDA, L. et al., 2003, Projeto Final 2003.2. 399 p. Projeto de Sistema (Ps-Graduao em Anlise, Projeto e Gerncia de Sistema) CCE, Pontifcia Universidade Catlica do Rio de Janeiro, Rio de Janeiro. RUMBAUGH, J., JACOBSON, I., BOOCH, G., 1999, The Unified Modeling Language Reference Manual. Massachusetts. EUA: Addison Wesley Longman, Inc., 1st. Ed., 550 p. RUMBAUGH, J., JACOBSON, I., BOOCH, G., 2000, UML: Guia do Usurio. Rio de Janeiro: Campus, 472 p. 174

RUMMLER, G. A.; BRACHE, A. P., 1994, Melhores Desempenhos das Empresas. So Paulo: Makron Books. SALERNO, M. S., 1999, Projeto de Organizaes Integradas e Flexveis: processos, grupos e gesto democrtica via espaos de comunicao-negociao. So Paulo: Atlas, 1 ed. SANTOS, R., 2002, Engenharia de Processos: anlise do referencial terico conceitual, instrumentos, aplicaes e casos com a finalidade de sntese sobre sua estrutura, conhecimentos, falhas e resultados. 317 p. Dissertao (Mestrado em Engenharia de Produo) COPPE, Universidade Federal do Rio de Janeiro, Rio de Janeiro. SANTOS, R.; CAMEIRA, R.; CLEMENTE, A.; CLEMENTA, R., 2002, Engenharia de processos de negcios: aplicaes e metodologias. In: ENCONTRO NACIONAL DE ENGENHARIA DE PRODUO, 22., Curitiba. Anais Eletrnicos... Porto Alegre: ABEPRO, 2002. 1 CD. SCHEER, A.-W., 1998, ARIS Business Process Frameworks. Heidelberg: Springer Verlag, Berlin, 2st Ed. ______________, 1999, ARIS Business Process Modeling. Heidelberg: Springer Verlag, Berlin, 2st Ed. SCHNEIDER, G., WINTERS, J., P., 1998, Applying use cases: A Pratical Guide. Massachusetts: Addison-Wesley Longman, 188p. SHINGO, S., 2000, Sistema de Troca Rpida de Ferramenta. Porto Alegre: Bookman, 1 Ed. ______________, 1996a, O Sistema Toyota de Produo. Porto Alegre: Bookman, 1 Ed. ______________, 1996b, Sistemas de Produo com Estoque Zero. Porto Alegre: Bookman, 1 Ed.

175

SILVA, A. V., 2001, da Modelagem de processos para implementao de workflow: uma avaliao crtica. 211 p. Dissertao (Graduao em Engenharia de Produo) COPPE, Universidade Federal do Rio de Janeiro, Rio de Janeiro. SMITH, H. e FINGAR, P., 2003, Business Process Management The Third Wave. Tampa, Florida: Megahn-Kiffer Press, 1 ed. STEIN, R. E., 1996, Re-Engineering the Manufacturing System - Applying the Theory of Constraints. New York: Marcel Dekker, 1 ed. VERNADAT, F. B., 1996, Enterprise Modeling and Integration: Principles and Applications. London: Chapman & Hall, 1 ed. YIN, R., K., 2001, Estudo de Caso: Planejamento e Mtodos. Porto Alegre: Bookman, 2 ed. YPHIS, 2000, Software Evaluation Report : UML Modeling Tools. Disponvel em: http://www.rational.com . Acesso em: 09 mai. 2002.

176