ModelageM de Processos

Unidade IV
7 MODELAGEM DA ARQUITETURA DE NEGCIO 7.1 Introduo

Processos de negcio so atividades previamente estabelecidas que tm como objetivo determinar a forma como o trabalho realizado numa organizao. Constituem um conjunto de aes, relacionadas entre si de forma lgica e coerente, a fim de promover uma sada favorvel organizao, tanto em termos internos como externos. Uma estrutura de processos de negcio mal concebida pode por em risco a eficincia e a eficcia de uma empresa por meio dos produtos e servios que gera e disponibiliza. Dada a similaridade das suas composies, funo de negcio e processo de negcio so conceitos que frequentemente suscitam dvidas entre as pessoas interessadas em formar um melhor entendimento a respeito dos elementos de uma arquitetura de negcios. Ambos so coisas que a empresa faz, entretanto, os processos so transfuncionais (ou horizontais), j que perpassam diversas barreiras funcionais dentro da organizao (por exemplo: adquirir bem, alienar bem, contratar funcionrio), enquanto que as funes, que em conjunto descrevem a misso da empresa, so verticais (por exemplo: contabilidade, vendas, logstica). Um outro aspecto relevante, e que pode representar uma mais valia na implementao dos processos de negcio numa organizao, tem a ver com a implementao de um sistema de informao bem estruturado. A existncia de uma boa rede de informao, entre todos os intervenientes nos processos de negcio da organizao, condio sine qua non, uma vez que permite a comunicao em tempo real, tornando possvel uma adequada tomada de deciso, resultante do ajuste contnuo de procedimentos que ir repercutir em toda a dinmica organizacional e, consequentemente, na excelncia dos seus resultados. Desse modo, quando se fala em processos de negcio, a abrangncia enorme, pois o seu mbito de atuao transversal e atua em todas as reas da organizao, com elevado impacto na qualidade dos servios e/ou produtos, na reduo de custos e no desenvolvimento do prprio negcio. Por outro lado, a existncia de uma interface entre os processos de negcio e uma rede de sistemas de informao constituem fatores-chave fundamentais, quer para a generalidade dos negcios dos tempos de hoje, quer para a produo de indicadores e instrumentos de controle efetivo para uma constante monitorizao das atividades da organizao. 103

Unidade IV
Assim, como a Figura 57 sugere, pode-se definir processos de negcio como um conjunto de atividades desenvolvidas a partir de um objetivo predefinido que ir concretizar-se num resultado especfico, em termos de produto ou servio que se pretenda realizar.
Pessoas Equipamento Informao

Objetivo

Processos de negcio

Resultado

Que tarefas especficas? Qual a prioridade? Quais os procedimentos? Figura 57 Processos de negcio

7.2 Modelagem de negcio

Para compreender uma organizao, necessrio entender seus processos de negcio. Profissionais da Tecnologia da Informao se empenham em construir solues que tm por finalidade auxiliar a empresa na conquista de maior espao no mercado globalizado. Nesse contexto, os processos so avaliados e, sempre que possvel, informatizados, de forma a promover vantagens competitivas a partir do alinhamento estratgico entre o sistema e o negcio da empresa. Para a OMG (Object Management Group, 2005), um processo de negcio corresponde a um conjunto coeso de atividades que criam um resultado, o qual garante a criao de valor a um cliente externo ou interno empresa, ou, visto de outra forma, pode ser um conjunto de tarefas regido por regras de negcio e que se desenvolve a partir de um determinado evento de negcio. Segundo Laudon e Laudon (2001), um processo de negcio refere-se maneira pela qual o trabalho organizado, coordenado e focado, para produzir um produto ou servio de valor. De um lado, processos de negcios so fluxos de trabalhos concretos de materiais, informaes e conhecimentos. De outro, referem-se tambm maneira singular de as organizaes coordenarem trabalho, informao e conhecimento, e de como a gerncia prefere coordenar o trabalho. J a modelagem de negcio uma tcnica de modelagem de alto nvel, que surgiu das dificuldades identificadas pelos analistas de sistemas. 104

ModelageM de Processos
uma abstrao voltada realidade dos administradores, assim, estudiosos e pesquisadores da rea de TI criaram uma tcnica de modelagem de alto nvel denominada de modelagem de negcio, que hoje parte integrante no processo de desenvolvimento de software e que serviu para facilitar a comunicao com as pessoas que fazem parte do negcio mas no possuem conhecimentos de Engenharia de software. Observao Os autores Michael Hammer e James Champy afirmam:
Um processo de negcio uma coleo de atividades que usam um ou mais tipos de entrada e criam uma sada que seja de valor para o cliente. Um processo de negcio tem um objetivo e afetado por eventos que ocorrem no mundo externo ou em outros processos.

Lembrete A tcnica de modelagem de negcio profundamente relacionada arquitetura de negcios. Observao J o autor Thomas Davenport aponta que o processo de modelagem de negcios: [...] um conjunto estruturado de atividades, desenhado para produzir um resultado especificado para um cliente ou um mercado em particular. Isso implica forte nfase sobre como o trabalho feito dentro da organizao, em contraste com o foco no produto. Um processo ento uma ordenao especfica de atividades de trabalho, por meio do tempo e do espao, com comeo e fim e entradas e sadas claramente dentificadas: uma estrutura para ao. 7.2.1 Conceitos de negcio Funes de negcio so estruturas conceituais idealizadas que servem para descrever a misso de uma organizao. Uma vez que tenham sido definidas e decompostas adequadamente, elas se mantm estveis ao longo do tempo, mesmo diante de reorganizaes da empresa. Como so perenes, as funes representam um ponto de referncia (conceitos comuns) ao se descrever diferentes negcios, que de outra forma exibiriam variaes significativas. 105

Unidade IV
A Figura 58 exemplifica o relacionamento dentro de uma organizao entre as funes de negcio e os processos de negcio a partir das atividades organizacionais e atividades de processos.
act Business Process Model

Funo de negcio

Atividade de negcio Atividade componente do processo

Processo de negcio

Subprocesso componente de processo

Figura 58 Funo de negcio, processo de negcio e seus relacionamentos

Como exemplo da aplicao dessa definio, temos o fato de que a funo contabilidade de uma empresa define o contador, a funo gerencial define o gerente e assim por diante. Funes de negcio so tambm alocadas a unidades ou reas organizacionais especficas (que exercero os diferentes papis) e so envolvidas e acionadas no decorrer do comportamento do negcio. A Figura 58 mostra que uma funo corresponde a uma srie de atividades relacionadas, envolvendo uma ou mais entidades de dados, realizadas com o objetivo de se cumprir um ou mais objetivos da misso da empresa. As atividades de negcio que compem uma funo de negcio so relacionadas entre si por afinidade, porque trabalham um grupo comum de entidade de dados (clientes e produtos) ou porque so sequenciais ou paralelas na realizao do trabalho associado a um resultado final comum. Observao A arquitetura de negcio busca uma viso conceitual e nica de uma atividade ou funcionalidade, de forma que se possa identificar quando e como ela se repete nos diversos processos de negcio, a fim de determinar 106

ModelageM de Processos
a generalizao dos conceitos de tarefas comuns, identificando atividades compartilhadas e administrando seu reuso por meio da distribuio dos componentes que as suportam. Da mesma forma, os sistemas de informao que suportam tais funes estaro focados em aspectos especficos do funcionamento do negcio, independentemente da forma como a empresa est organizada. As atividades so direcionadas a dados e so iniciadas por transaes ou solicitaes de dados. Elas so a poro ativa das funes e tendem a ser repetitivas e formalizadas. Observao importante notar: Uma maneira de se diferenciar o conceito de funes e atividades que, geralmente, as funes so gerenciadas e atividades so realizadas. Funes so gerenciais e atividades so operacionais. J um processo de negcio definido como a sequncia completa de um comportamento de negcio, provocado por algum evento, que produz um resultado significativo para o negcio e que, de preferncia, tenha foco no cliente. No percurso do processo, desde o evento inicial at a produo de um determinado resultado, vrias funes do negcio podem estar envolvidas. Assim, diz-se que os processos so elementos transfuncionais, j que perpassam diversas funes dentro da organizao. Se uma funo composta de atividades que representam um papel ou razo de existir da organizao, os processos de negcio executam essas atividades de forma que, individualmente ou combinadas, realizem o trabalho de uma determinada funo. Um estudo de aplicao de modelagem de processo de negcio para apoiar a especificao de requisitos de um sistema Antes de entrarmos em duas notaes de modelagem de processos seria interessante analisarmos os resultados obtidos com a aplicao da modelagem apresentada no artigo Um estudo de aplicao de modelagem de processo de negcio para apoiar a especificao de requisitos de um sistema, dos autores Adriana Andrade, Andriele Ribeiro, Eduardo Borges e Wolber Neves, apresentado no VI Simpsio Internacional de Melhoria de Processos de Software, em So Paulo, em 2004. 107

Unidade IV
No item resultados obtidos, os autores afirmam: A aplicao da modelagem de processos de negcio trouxe resultados bastante positivos. A execuo dessa etapa antes da realizao do levantamento dos requisitos do sistema foi um fator de reduo de riscos, tanto para o cliente quanto para o fornecedor. O cliente pde ter uma viso melhor do seu negcio, identificando as reas que realmente seriam beneficiadas pela construo do sistema, evitando assim o desperdcio de recursos. Foi interessante observar que, durante as oficinas, o cliente pde perceber que determinados processos no estavam sendo executados da melhor forma. Diante desta percepo, alguns processos foram remodelados, evitando que o sistema fosse construdo sobre uma base operacional deficiente. Para o fornecedor, a execuo da modelagem de processos de negcio resultou em maior facilidade na gesto dos requisitos do sistema. Muitas das constantes mudanas que ocorrem durante o desenvolvimento de um sistema decorrem da inexistncia de um consenso entre os representantes do cliente sobre a melhor forma de se executar um processo. A modelagem de processos de negcio fez com que esse consenso fosse alcanado antes do incio do levantamento dos requisitos do sistema, tornando esta etapa mais eficiente. A identificao dos casos de uso do sistema (UML) tambm foi bastante facilitada. Como passaram a conhecer melhor a realidade do cliente, os engenheiros de requisitos puderam ser mais proativos nessa atividade, contribuindo com sugestes e ponderaes baseadas em conhecimento mais slido. Esta proatividade mostrou-se especialmente til nas primeiras oficinas, j que naquele momento os representantes do cliente ainda no estavam totalmente seguros com a metodologia de levantamento dos requisitos. Outro benefcio trazido pela modelagem de processos de negcio diz respeito rastreabilidade dos requisitos. Uma caracterstica de qualidade importante para uma especificao de requisitos a facilidade em se determinar os resultados do desenvolvimento que sero afetados por cada requisito (rastreabilidade para frente), bem como a origem de cada um (rastreabilidade para trs). Como os requisitos foram derivados diretamente do modelo de processos de negcio, a rastreabilidade para trs foi garantida documentando-se, para cada requisito, o processo de negcio que o gerou. Um ponto importante no desenvolvimento de um sistema, especialmente quando seu porte no pequeno, a sua diviso em produtos. A diviso uma maneira formal de se 108

ModelageM de Processos
exercitar o desenvolvimento incremental, j que produtos coesos e de menor porte so entregues em menor tempo do que um nico mdulo que contemple todas as funes. Isto importante tanto do ponto de vista tcnico quanto do de negcio, j que muitas vezes o cliente no dispe de recursos para construir todo o sistema de uma s vez, e a priorizao de requisitos dentro de um mdulo nico no uma tarefa simples. Esse foi tambm um ponto em que a modelagem de processos de negcio foi benfica. Antes de sua realizao, cliente e fornecedor imaginavam que o sistema seria composto por trs produtos. Aps a modelagem, percebeu-se que o nmero de produtos era realmente trs, mas a composio dos mesmos foi bastante modificada. Dois dos produtos foram agrupados em um nico, e um produto de controle de fluxo de trabalho (workflow) foi identificado. Apenas um produto permaneceu conforme tinha sido concebido no incio. A diviso inicial dos produtos espelhava a diviso funcional da empresa, o que no se mostrou uma boa idia do ponto de vista de sistemas. A modelagem de processos de negcio fez com que cliente e fornecedor percebessem que duas das reas eram muito integradas, o que justificaria um nico produto para atend-las. Da mesma forma, o problema de controle de fluxo de trabalho era comum a todas as reas funcionais, o que justificaria um produto genrico para este fim, e no a insero de funcionalidades correlatas em um dos produtos especficos para determinada rea. Aps a diviso dos produtos, um deles foi escolhido para ser especificado e construdo. Seria necessrio, portanto, realizar uma estimativa do tamanho do produto em pontos de funo, para orar-se a fase de elaborao. O melhor conhecimento da organizao, conseguido por meio da modelagem de processos de negcio, tambm foi fundamental para que essa estimativa fosse bem prxima da contagem oficial de pontos de funo, realizada alguns meses depois (aps o fim da elaborao). Percebeu-se inclusive que a aproximao do nmero real foi maior do que em projetos em que a modelagem de processos de negcio no foi usada. Como ltimo resultado importante, podemos citar o artefato resultante da modelagem de processos de negcio. Esse documento importante para o cliente, j que a documentao dos processos da organizao. Mas tambm do ponto de vista do fornecedor o documento foi de grande utilidade, pois serviu para dar uma viso geral s pessoas que entravam no projeto depois de seu incio. Foi uma forma simples e barata de integrar novas pessoas equipe.
Adaptado de: <www.simpros.com.br>. Acesso em: 13 jul. 2012.

109

Unidade IV
7.2.2 Extenso de negcio da UML Segundo Paul e Serrano (2003), o estudo sobre processo de negcio no deve ser isolado, sendo importante seu relacionamento com a rea de TI, pois ela considerada sua grande modificadora. O processo de negcio geralmente confia no suporte fornecido pelos Sistemas de Informao (SI) para a realizao de suas atividades. Similarmente, esses sistemas dependem da infraestrutura de comunicao, normalmente oferecido por rede de computadores (RC). A Figura 59 demonstra o relacionamento existente entre processos, sistemas de informao e redes de computadores, no qual mudanas ocorridas em alguns dos domnios devem afetar os demais.
Processo1 SI1 Processo2 SI2 ... Processon SIn

TI

RC1

RCn

Figura 59 Relacionamento de processos, Sistemas de Informao (SI) e Redes de Computadores (RC)

De acordo com Dalal et al (2004), muitas tcnicas para modelagem dos processos empresariais, incluindo DFDs (Diagramas de Fluxo de Dados), Idef0 (Definies Integradas para Modelagem por Funes, em nvel 0) e diagramas de casos de uso de negcio, tm suas razes nos processos de desenvolvimento de software. De acordo com as orientaes da UML 2.0 Superstructure Specification, disponibilizada a partir de outubro de 2004 pela OMG, os casos de uso so meios de especificar os requisitos de um sistema de informao. Todavia, quando casos de uso documentam processos de negcio de uma organizao, o Sistema sob Discusso (SsD), do ingls System under Discussion (SuD), a prpria organizao. Os stakeholders ou atores de negcio so os acionistas da companhia, clientes, vendedores e as agncias governamentais regulamentadoras. Os atores primrios incluem os clientes da companhia e talvez seus fornecedores. Um caso de uso apenas documenta um processo, ele no faz reEngenharia, ou seu projeto novamente (COCKBURN, 2005). Um caso de uso especifica o comportamento de um sistema ou de parte de um sistema e uma descrio de um conjunto de sequncias de aes, incluindo variantes realizadas pelo sistema para produzir um resultado observvel do valor de um ator. 110

ModelageM de Processos
Alm disso, os casos de usos podem ser aplicados para captar o comportamento pretendido do sistema que est sendo desenvolvido, sem ser necessrio especificar como esse comportamento implementado. Tambm fornecem uma maneira para os desenvolvedores chegarem a uma compreenso comum com os usurios finais do sistema e com os especialistas do domnio e servem para ajudar a validar a arquitetura e para verificar o sistema medida que ele evolui durante seu desenvolvimento (BOOCH et al, 2000). Quando utilizados para representar processos de uma organizao, os casos de uso so identificados como casos de uso de negcio. Em outras palavras, um caso de uso de negcio representa o que a organizao faz (BOGGS e BOGGS, 2002). O escopo de um caso de uso pode abranger uma escala de assuntos: Uma empresa ou uma linha de negcio: este nvel de modelo utilizado para descrever como os sistemas se integram. Um sistema individual: este o nvel mais utilizado na abordagem por casos de uso. Um simples subsistema simples ou componente: este nvel descreve os mecanismos de implementao de um elemento do modelo. Para descrever um processo de trabalho de um negcio. Para focar discusso sobre futuros requisitos de software. Para ser os requisitos funcionais de um sistema. Para documentar o projeto do sistema. Para ser escrito em um grupo pequeno e restrito, ou em um grupo grande ou distribudo. O modelo de casos de uso de negcio um modelo das funes pretendidas do negcio. usado como base para identificar papis e produtos liberados na organizao. Os casos de uso de negcios so identificados e possivelmente resumidos no incio da fase de iniciao, para ajudar a definir o escopo do projeto (RUP, 2001). Quadro 8 Propriedades de um caso de uso de negcio
Nome da propriedade Nome Breve descrio Metas Metas de desempenho Descrio O nome do caso de uso de negcio. Uma breve descrio do papel e da finalidade do caso de uso de negcios. Uma especificao das metas ou objetivos mensurveis do caso de uso de negcios. Uma especificao das mtricas relevantes ao caso de uso de negcios e uma definio das metas de utilizao dessas mtricas.

111

Unidade IV
Uma descrio textual do fluxo de trabalho representado pelo caso de uso de negcios. O fluxo deve descrever o que o negcio faz para oferecer vantagens a um ator de negcio, e no como esse negcio resolve os problemas. A descrio deve ser compreensvel para qualquer pessoa dentro do negcio. Se o caso de uso de negcios pertence categoria central, suporte ou gerenciamento. Uma especificao dos riscos de executar e/ou implementar o caso de uso de negcios. Uma descrio do potencial de melhoria estimado do caso de uso de negcios. Uma definio de quem o proprietrio do processo de negcios: a pessoa que gerencia e planeja as mudanas. As caractersticas do caso de uso de negcio no cobertas pelo fluxo de trabalho conforme descrito. Uma lista dos locais dentro do fluxo de eventos do caso de uso de negcios em que um comportamento adicional pode ser inserido por meio do relacionamento de extenso. Os relacionamentos (como associaes de comunicao, relacionamentos de incluso e de extenso) dos quais o caso de uso participa. Esses diagramas mostram a estrutura do fluxo de trabalho. Esses diagramas mostram os relacionamentos que envolvem o caso de uso. Resultados ou esboos manuscritos provenientes das sesses de encenao. Adaptado de: RUP, 2001.

Fluxo de trabalho Categoria Risco Possibilidades Proprietrio do processo Requisitos especiais Pontos de extenso Relacionamentos Diagramas de atividades Diagramas de casos de uso Ilustraes do fluxo de trabalho

De acordo com o RUP (2001), os elementos de um modelo de caso de uso de negcio podem ser demonstrados conforme o quadro 9. Quadro 9 Componentes do diagrama de caso de uso de negcio
Nome Ator de negcio Notao Descrio Um ator de negcio representa um papel desempenhado em relao ao negcio por algum ou algo no ambiente do negcio. Um caso de uso de negcios define uma instncia de negcio, no qual cada instncia uma sequncia de aes realizada por um negcio que produz um resultado de valor observvel para um determinado ator de negcio.

Caso de uso de negcio

Modelo de caso de uso de negcio

O modelo de casos de uso de negcios um modelo das funes pretendidas do negcio. usado como base para identificar papis e produtos liberados na organizao.

112

ModelageM de Processos

Generalizao de ator

Um relacionamento de generalizao de uma classe de ator de negcio (descendente) com outra classe de ator de negcios (ascendente) indica que o descendente herda o papel que o ascendente pode assumir em um caso de uso de negcios. Uma associao de comunicao entre um caso de uso e um ator indica que uma instncia do caso de uso e uma instncia do ator iro interagir. Um relacionamento de extenso aquele que se estabelece entre um caso de uso de extenso e um caso de uso base, especificando como o comportamento definido para o caso de uso de extenso pode ser inserido no comportamento definido para o caso de uso de base. Ele inserido implicitamente, ou seja, a extenso no exibida no caso de uso base. Um relacionamento de incluso aquele que se estabelece entre um caso de uso base e um caso de uso de incluso, especificando como o comportamento definido para o caso de uso de incluso inserido de forma explcita no comportamento definido para o caso de uso base. Uma generalizao de casos de uso um relacionamento de um caso de uso filho com um caso de uso pai, especificando como um filho pode adotar todo o comportamento e as caractersticas descritas para o pai. Um diagrama de casos de uso mostra os atores de negcios, os casos de uso de negcios, os pacotes de casos de uso e seus relacionamentos.

Associao de comunicao

Relacionamento de extenso

extenso

Relacionamento de incluso

incluso

Generalizao de casos de uso

Diagrama de casos de uso

De acordo com o RUP (2001), a projeo realizada pela Engenharia de negcio fundamental para a realizao do sistema. As atividades do negcio e os relacionamentos identificados entre elas, bem como a atuao dos envolvidos, determinaro os objetivos a serem alcanados pelo software a ser desenvolvido. A Figura 60 apresenta uma conexo entre essas duas reas.
Proposta para informatizao Proposta de software Engenharia de processo de negcio Modelo de negcio Figura 60 O relacionamento entre Engenharia de processo de negcio e Engenharia de software Engenharia de software

113

Unidade IV
7.2.3 Vises de modelos de negcio O modelo de negcios a forma pela qual uma empresa cria valor para todos os seus principais pblicos de interesse. Sua utilizao ajuda a ver de forma estruturada e unificada os diversos elementos que compem todas as formas de negcios da organizao. O modelo de negcio de uma empresa composto por 5 principais elementos: Modelo de proposta de valor: a forma pela qual a empresa define qual o seu diferencial no mercado, a forma pela qual nica e se destaca de todas as demais empresas que participam desse mesmo mercado. Modelo de interface com o consumidor: o que escreve onde, quando e como uma empresa interage com os seus consumidores. Essa interao pode se dar por meio de lojas, embalagens de produtos, comerciais, SAC, website etc. Modelo de operao: como que uma empresa faz para levar o seu produto at o seu consumidor. Esse modelo deve prever todos as etapas necessria para viabilizar sua produo, passando por logstica, at chegar s mos de quem compra o seu produto ou servio. Modelo estratgico: a descrio de como uma empresa ir atingir os seus objetivos estratgicos. Nesse modelo onde visualiza-se a misso de uma empresa, sua viso, seus valores e todas as competncias necessrias para que a empresa funcione de forma adequada. Modelo econmico: onde se demonstra a viabilidade financeira de uma empresa. Esse modelo mostra como uma empresa ganha recursos e paga suas despesas a fim de atingir a sustentabilidade.
7.3 OCL e sua utilizao na modelagem de processo de negcio

A OCL (Object Constraint Language) uma notao que permite se dar mais preciso nas especificaes ou modelos que usam a UML. Lembrete A OCL baseada na lgica e matemtica discreta. Assim como a UML, uma linguagem de modelagem e no uma linguagem de programao. uma linguagem de modelos tipada. Inicialmente, a OCL era uma extenso para a UML, agora parte da UML padro.

114

ModelageM de Processos
Por que a OCL? Um diagrama UML, tal como o diagrama de classes, tipicamente no refinado o suficiente para permitir-se ter todos os aspectos relevantes de uma especificao. H a necessidade de se descrever restries adicionais sobre os objetos de um modelo. A linguagem natural inerentemente ambgua. Linguagens formais tradicionais so dificeis para usurios de negcio ou modeladores de sistemas. A OCL uma linguagem formal que permanece simples para ler e escrever. Quando se deve usar a OCL? A linguagem OCL usada para expressar condies constantes de restries de especificaes para sistemas que esto sendo modelados. Para especificar invariantes nas classes e tipos no modelo de classes. Para especificar tipos invariantes para esteretipos. Para descrever pr e ps-condies nas operaes e mtodos. Para especificar restries nas operaes. A OCL suportada para os seguintes tipos de diagramas da UML 2.0, como mostrta a quadro 10. Quadro 10 Diagramas com suporte OCL
Tipo de diagrama Use case (caso de uso) Classes (classe, namespace e comunicao) Interao (sequncia e comunicao) Mquina de estado Verso da UML UML 2.0 UML 1.5 e 2.0 UML 2.0 UML 2.0 Como o suporte provido Restries para o comportamento associado com os casos de uso como expresses OCL. Por exemplo, uma interao escolhida como um comportamento. Restries na criao de objetos so suportadas. Restries de invarincia de estado para linhas de vida e restries dos operandos de fragmentos combinados como expresses OCL. Condies de guarda de transies como expresses OCL.

Como os modelos de negcio so suportados pelos diagramas de casos de uso a OCL, esses apoiaro as restries das pr e ps-condies para execuo de um caso de uso de negcio. 115

Unidade IV
7.4 Integrao com o desenvolvimento de software

Num processo iterativo de desenvolvimento de software, a equipe do projeto segue uma srie de fases, cada uma focando diferentes partes do negcio ou sistema. Existem duas abordagens para a modelagem de negcio em um ambiente iterativo: Primeiro, terminar toda a modelagem de negcio e, na sequncia, iniciar as atividades iterativas (anlise, design, codificao, teste e implantao). Alternativamente, pode-se incluir a modelagem de negcio nas iteraes (BOGGS e BOGGS, 2002). Para Boggs e Boggs (2002), tanto num processo iterativo, como num modelo de processo do tipo cascata, a modelagem de negcio surge nas fases iniciais. As razes pelas quais isso ocorre que a modelagem de negcio determina o contexto para o projeto. As figuras 60 e 61 mostram o aparecimento da modelagem de negcio nos processos de desenvolvimento de software.
Modelagem de negcio Anlise

Implantao Teste

Design
Implementao

Figura 61 Processo iterativo aps o surgimento da modelagem de negcio

Modelagem de negcio Implantao Teste

Anlise

Design
Implementao

Figura 62 Modelagem de negcio como fase integrante do processo iterativo

7.4.1 Processo de desenvolvimento de software Existem inmeros caminhos para reproduzir modelos de negcio dentro dos processos de desenvolvimento de software, incluindo o uso de outras notaes tais como Idef0 (modelagem funcional), ou mesmo descries textuais do processo. 116

ModelageM de Processos
No entanto, a UML um padro bem definido, suportado por muitas tcnicas. a linguagem de modelagem dominante, usada em sistemas de informao orientados a objeto. A UML na atualidade o padro que possui a melhor definio, suportada por muitas ferramentas e, dessa forma, tornou-se a linguagem de modelagem dominante na aplicao da tecnologia da orientao a objetos. Alm disso, pode ser utilizada para a modelagem de negcio e tambm para a modelagem de outros sistemas, ou seja, para aqueles que no sero utilizados para o desenvolvimento de softwares (OMG, 2005). Para Widrig e Leffingwell (2003), os principais modelos para a modelagem de negcio so: business use-case e business object model. Diagramas num modelo de negcio ajudaro a compreender o que a organizao fornece de valor, dentro de um relacionamento. Enquanto a maioria dos diagramas da UML foca no sistema que ser construdo, o modelo de casos de uso de negcio se concentra no negcio em torno desse sistema (BOGGS e BOGGS, 2002). O modelo de caso de uso de negcio consiste na interao entre atores e casos de uso, para demonstrar a sequncia de eventos necessrios na realizao de um trabalho. Juntos, atores e casos de uso descrevem o que est envolvido nas atividades do negcio e tambm como ele ocorre (WIDRIG e LEFFINGWELL, 2003). 7.4.2 Arquitetura de negcio e arquitetura de software Um dos principais esforos da investigao relacionada com a Engenharia de software tem sido a definio e representao de modelos que descrevam os processos de software, garantindo que esses correspondam fidedignamente s necessidades efetivas (em forma e contedo) dos processos de negcio. Deparamo-nos ento com duas realidades complementares: a modelagem dos processos de negcio e a modelagem do software, que tambm podem ser chamadas de arquitetura de negcio e arquitetura de software, na qual esta ltima tem cada vez mais a necessidade de estar em sintonia com toda a abrangncia do negcio (RODRIGUES, 2004). As modelagens de negcio e de sistema (software) so frequentemente desenvolvidas como parte de dois diferentes projetos com dois diferentes times. Ambas devem possuir boa definio, pois so ferramentas importantes para o gerenciamento da complexidade da amplitude e dificuldade do sistema (PENKER e ERIKSSON, 2000). Rodrigues (2004), ao avaliar o contexto da modelagem de negcio para a modelagem de sistema, especifica que ainda existe um caminho a ser percorrido para que a ponte entre esses dois domnios seja estabelecida de forma suave e sem sobressaltos. 117

Unidade IV
A Figura 63 mostra a integrao proposta por Rodrigues (2004).

Modelagem do processo

Modelagem de sistema

O que existe para fazer a ponte efetiva entre modelagem de negcio e sistema? Figura 63 Integrao entre modelagem de negcio e sistema

No RUP (2001), a integrao entre negcio e sistema tem incio nas primeiras atividades da iterao do ciclo de desenvolvimento do sistema, definida como iniciao. Nesse momento, a maior parte dos esforos, para as disciplinas Modelagem de Negcios e Requisitos, utilizada com o propsito de obter as informaes necessrias para a conduo do projeto e elaborao do software. A Figura 64 demonstra, no detalhe, o esforo necessrio na fase inicial da iterao, a partir do desenho de viso geral do RUP.

Fases Disciplinas Modelagem de negcios Requisitos Concentrao de esforos nas fases iniciais. Figura 64 O esforo da modelagem de negcios e requisitos Iniciao Elaborao Construo Transio

A Figura 64 mostra que as disciplinas de Modelagem de Negcios e Requisitos do Sistema so perfeitamente integradas e dependentes ao longo do processo de desenvolvimento iterativo RUP. Um conceito atual que vem sendo tratado pelos autores e as empresas de tecnologia o gerenciamento de processos de negcio ou business process management. 118

ModelageM de Processos

Saiba mais Vale a pena conferir o documento Business Process Management Enabled by SOA, da IBM de 2009, em que o gerenciamento de processos de negcio mais frequentemente associado com o ciclo de vida de um de processos de negcios. O ciclo de vida de processo de negcio abrange identificar e melhorar os processos que proporcionam capacidade de negcios para implantar e gerenciar os seus processos quando estiver operacional. O que frequentemente esquecido a gesto do desempenho do processo depois que operacional. De certa forma, essa provavelmente a fase mais importante do ciclo de vida de processos. Depois que um processo de negcio implantado, ele deve ser gerenciado, e, para gerenciar o processo de negcio, deve-se ter visibilidade do desempenho de processos. Quando um processo no atingir mais o seu desempenho de seus objetivos, hora de voltar ao ciclo de vida para avaliar a causa raiz do problema de desempenho e buscar oportunidades de melhoria adicionais. Subjacente, BPM tambm governana. Governana um componente essencial de BPM porque fornece a estrutura que garante que a estratgia de negcios e metas sejam implementadas no nvel operacional. A estrutura de governana tambm permite negcio e alinhamento de TI, fornecendo mecanismos que aumentem a colaborao e cooperao entre os dois mundos, os processos de negcio e a tecnologia da informao.
8 A MODELAGEM DE pROCESSOS DE NEGCIO 8.1 Viso Erikson e penker

Antes que a OMG se preocupasse com a modelagem de negcios com a linguagem UML, os autores Erikson e Penker (2000) propuseram um metamodelo para a modelagem dos processos de negcio, o qual apresenta: Uma viso de mais alto nvel, visando identificar a situao do negcio que ser abordada. Nessa viso, deve-se definir o contexto e o escopo, sendo que: o contexto o que est relacionado, qual a situao, descrio do problema; e o escopo at onde vai, contorno ou limite. 119

Unidade IV
Essa viso pode incluir FCSs (Fatores Crticos de Sucesso). As metas e objetivos (do original Goal) podem ser decompostos em diferentes nveis, como, estratgico/ttico/operacional, sendo que: o objetivo qualificvel; e a meta quantificvel. Nesse modelo, os processos de negcio: possuem uma meta; possuem entradas e sadas especficas; usam recursos; possuem um nmero de atividades, realizadas em alguma ordem, que podem ser vistas como subprocessos; afetam mais de uma unidade da organizao; criam valor para algum consumidor (interno ou externo). A figura 65 apresenta os elementos ou smbolos propostos para o modelo de Erikson e Penker.
<<processo>> Processo A

<<processo>> Subprocesso A1

<<processo>> Subprocesso A1

<<processo>> Subprocesso A1

Atividade A2a

Atividade A2b

Atividade A2c

Atividades podem ser entendidas como processos atmicos

Figura 65 Notao de Erikson e Penker para modelagem de negcio

120

ModelageM de Processos
As atividades ou processos atmicos so: Diretas: diretamente envolvidas na criao do produto ou servio, que o valor criado pelo processo. Indiretas: d suporte s atividades diretas, como manuteno, administrao etc. Garantia de qualidade: atividades que garantem a qualidade de outras atividades, como inspeo, controle, reviso e validao. A figura 66 ilustra os passos de um processo de negcio nesta notao.
<<processo>> Furao <<processo>> Fazer furo Calibrar Ler instruo Ligar furadeira Furar

Processo contendo 3 subprocessos: dois atmicos e um composto Figura 66 Passos de um processo

A figura 67 mostra um exemplo de um processo de negcio com recepo e emisso.

Ordem de compra <<processo>> Administrao de compra de ao Compra de ao no mercado

<<processo>> Demanda do cliente por ao

Ordem de venda

<<processo>> Administrao de venda de ao

Venda de ao no mercado

Figura 67 Processo de recepo e emisso

121

Unidade IV
Como novo exemplo, a figura 68 apresenta um modelo de processo de furao de chapas em uma indstria qualquer.
<<goal>> chapas furadas por dia: Meta Quantitativa Valor = 100 <<achieve>> <<information>> instrues de fucao <<physical>> chapa de ao Figura 68 Exemplo de um processo de furao de chapa <<processo>> furao <<physical>> chapa perfurada

A notao de Erikson e Penker ainda hoje utilizada, e algumas ferramentas Case, tal como a ferramenta EA, mantm essa notao.
8.2 A modelagem de processos de negcio com a BpM

A notao BPMN surgiu como um padro alternativo UML, tambm sendo grfica, porm seus smbolos so um pouco diferentes, pois a BPMN (Business Process Modeling Notation) foi criada especificamente para modelar processos de negcio. Essa notao no oferece qualquer suporte para modelar dados, atores, estados de ciclo de vida, ou sistemas. Quem desenvolveu o BPMN foi o Business Process Management Initiative (BPMI), iniciativa oriunda da OMG que lanou a especificao 1.0 ao pblico em maio de 2004. Tanto a UML como a BPMN so notaes mantidas pela OMG. Os objetivos do esforo do grupo que desenvolveu o BPMN so: Fornecer uma notao que seja fcil. Ser compreensvel por todos os usurios de negcios. Envolver os analistas de negcio, os desenvolvedores, os tcnicos responsveis pela aplicao dos sistemas que iro executar os processos e as pessoas de negcios. 122

ModelageM de Processos
A BPMN define um Business Process Diagram (BPD), que baseado em um fluxograma adaptado para a criao de modelos grficos de tarefas dos processos de negcio. Para a BPMN, um modelo de processo de negcios uma rede de objetos grficos, denominados de atividades, e do fluxo de controle, que define a ordem de execuo. As grandes empresas de software, tais como a IBM, a Oracle, a SAP e outras, vm investindo em sistemas que automatizam a gesto de processos de negcio (execuo, controle e monitorao). Esses sistemas so os denominados BPMS (Business Process Management Suite), que do suporte ao mapeamento, execuo, monitorao e controle dos processos de negcio de uma organizao. Tipicamente, inclui: o mapeamento dos processos de negcio ponta-a-ponta; desenho dos fluxos e formulrios eletrnicos; definio de workflow; regras de negcio; integradores; monitorao em tempo real das atividades; e alertas. uma poderosa ferramenta de gesto, para garantir que os processos esto sendo efetivamente executados como modelados, contribuindo para os objetivos da organizao. Os softwares utilizados na operacionalizao e gerenciamento de processos de negcio so um dos principais facilitadores da gesto do conhecimento referente ao processo, sendo considerada a maior facilidade para obteno, distribuio e anlise dos dados. H algumas funcionalidades que podem ser disponibilizadas via software, inclusive nos softwares BPMS, que, quando disponveis, aumentam a capacidade dos gestores e demais envolvidos com o processo em estabelecer uma troca de imagens e idias, nos ambientes onde ocorre a gerao do conhecimento. Observao A soluo BPMS no prope a substituio dos sistemas existentes na organizao os conhecidos como sistemas legados, e sim disponibiliza um ambiente de integrao de sistemas de informao, que permite definir: 123

Unidade IV
fluxo de execuo; regras; eventos; demais especificaes necessrias operao e gerenciamento do processo de negcio. Dessa forma, permite atender a outra caracterstica do processo de negcio: a de ser extremamente dinmico, permitindo, por exemplo, uma substituio rpida e simples de um software por outro, necessria quando uma empresa parceira da organizao substituda, demandando a integrao com um novo software disponvel no ambiente computacional do novo parceiro. De acordo com vrios autores, um BPMS completo teria os seguintes mdulos ou funcionalidades: Funcionalidades mnimas para uma soluo poder se classificar como BPMS: ferramenta de modelagem e desenho do processo; engenho de execuo do processo; orquestrao de web services; interface de workflow para usurios. Para ter um produto mais completo, seria necessrio: suporte para regras de negcio complexas; Business Activity Monitoring (BAM); controle de verso dos documentos anexados a instncias do processo. E para um produto completo, seria acrescentado de: Enterprise Service Bus (ESB); Repositrio de metadados; Uma suite de business intelligence.

124

ModelageM de Processos
Um BPD formado por um conjunto de quatro elementos grficos, que so: objetos de fluxo; objetos de conexo; raias (swimlanes); e artefatos. 8.2.1 Objetos de fluxo Um BPD apresenta trs objetos de fluxo: evento, atividade e gateway. Os objetos de fluxo so os principais elementos grficos para definir o comportamento de um processo de negcio. 8.2.1.1 Evento Um evento algo que acontece no decurso de um processo de negcio. Esses eventos afetam o fluxo do processo e normalmente tm uma causa (trigger) ou um impacto (resultado). Somente os eventos tm a capacidade de iniciar ou terminar um processo, porm no executam tarefas nesse. Os eventos ainda podem forar a execuo ou desviar para uma determinada atividade. H trs tipos de eventos, com base em quando eles afetam o fluxo: evento de incio, evento intermedirio e evento de fim, com notao apresentada na figura 69.
BPMN BPMN

Evento incio

Evento intermedirio

Evento fim

Figura 69 Smbolos de eventos da BPMN

125

Unidade IV
O evento incio define a inicializao em um processo. O evento intermedirio define um evento intermedirio em um processo. J o evento fim define o trmino de um evento em um processo. Um processo pode ser iniciado por diferentes circunstncias. Essas circunstncias so chamadas de gatilhos (triggers), tais como, uma mensagem chegando ou um temporizador. 8.2.1.2 Atividade Uma atividade organiza e especifica participao de comportamentos subordinados, tais como, as sub-atividades ou aes, para refletir o controle e o fluxo de dados de um processo. As atividades so usadas nos diagramas de atividades para vrios propsitos de modelagem: para a modelagem do desenvolvimento de uma aplicao tpica, para modelagem de um processo de negcio ou para modelar um workflow. Durante a criao, ou em edies mais tarde, uma atividade pode ser definida como um elemento composto. Contudo, quando se cria uma atividade composta, possvel usar tambm o elemento atividade estruturada, que foi criada para esse propsito. A especificao da OMG UML1 estabelece: Uma atividade especfica coordenao da execuo de comportamentos subordinados, usando um controle e modelo de fluxo de dados. Os comportamentos subordinados coordenados por esses modelos podem ser iniciados porque outros comportamentos no modelo iro concluir a execuo, ou porque os objetos e os dados ficam disponveis, ou porque ocorrem eventos externos para o fluxo. O fluxo de execuo modelado como atividades, os ns so ligados por arestas. Um n pode ser a execuo de um comportamento do subordinado, como um clculo aritmtico, uma chamada para uma operao, ou a manipulao do contedo do objeto. Atividades podem formar hierarquias invocando outras atividades, em ltima anlise, para resolver as aes individuais. Em um modelo orientado a objetos, as atividades so geralmente chamadas indiretamente de mtodos vinculados s operaes que estejam diretamente invocadas. As atividades podem descrever processos de computao. Nesse contexto, so os mtodos correspondentes s operaes nas classes. As atividades podem ser aplicadas modelagem organizacional para a Engenharia de processos de negcio e workflow. Nesse sentido, eventos geralmente se originam de dentro do sistema, tais como o acabamento de uma tarefa, mas tambm de fora do sistema, como uma chamada de cliente.
1

UML Superestrutura Especificao, verso 2.1.1, p. 318.

126

ModelageM de Processos
As atividades tambm podem ser utilizadas para a modelagem de sistema de informao, para especificar os processos ao nvel do sistema. As atividades podem incluir aes de vrios tipos (funes primitivas, operaes aritmticas etc.). Uma atividade representada por um retngulo de bordas arredondadas e um termo genrico para o trabalho que a empresa realiza. Uma atividade pode ser atmica (tarefa) ou no atmica (composta subprocesso).
analysis Diagrama Estrutura de Verso

Atividade

Sub_processo

Figura 70 Atividade atmica e no atmica

8.2.1.3 Gateway Utilizado para controlar a divergncia e convergncia da sequncia de fluxos, determina as decises tradicionais de bifurcao, fuso e unio de caminhos. Marcadores internos indicam o tipo de controle do comportamento.
analysis Diagrama Estrutura de Verso

Figura 71 Elemento gateway

Gateways so os mecanismos padronizados na notao BPMN para desvios. Eles controlam como o processo diverge ou converge, ou seja, representam pontos de controle para caminhos dentro do processo. Eles separam e juntam o fluxo de um processo por meio do fluxo de sequncia.
8.2.2 Objetos de conexo Os objetos de fluxo so conectados ao diagrama pelos objetos de conexo, para criar o esqueleto estrutural bsico de um processo de negcio. Um BPD tem trs objetos de conexo: fluxo de sequncia, fluxo de mensagem e associao. 127

Unidade IV
8.2.2.1 Fluxo de sequncia Um fluxo de sequncia usado para mostrar a ordem (sequncia) que as atividades so realizadas em um processo. A figura 72 mostra um exemplo de fluxo de sequncia.
BPMN BPMN

Atividade 1

Fluxo de sequncia

Atividade 2

Figura 72 Fluxo de sequncia

8.2.2.2 Fluxo de mensagem Um fluxo de mensagem usado para mostrar mensagens entre dois participantes do processo (entidades empresariais ou papis de negcio) que enviam e recebem mensagens.
BPMN BPMN

Atividade 1

Fluxo de mensagem

Atividade 2

Figura 73 Fluxo de mensagem

8.2.2.3 Associao Uma associao usada para associar dados, textos e outros artefatos com os objetos de fluxo. Associaes so utilizadas para mostrar as entradas e sadas de atividades.
analysis Diagrama Viso Estrutura de Verso

Documento

Activity2

IntermediateEvent3

Figura 74 Associao

128

ModelageM de Processos
A figura 75 mostra um exemplo de um pedao de um processo utilizando os elementos apresentados.
class BPMN

No EndEvent

StartEvent

Repeat for Each Supplier

Limite do tempo excedeu

YES

Send RFQ

Receive Quote

Add Quote

Marca que mostra que o subprocesso tem loop

Evento intermedirio para um time out

Figura 75 Exemplo de um processo

8.2.3 Raias (Swimlanes)

Swimlanes um mecanismo para organizar atividades em categorias visuais separadas, que organizam as diversas capacidades ou responsabilidades. Os objetos swimlanes do BPD so:
Pool; Lane.

Swinlanes ou raias ajudam a dividir e organizar atividades em diferentes categorias visuais em um diagrama, de forma a ilustrar diferentes capacidades funcionais ou responsabilidades. Pools so utilizados quando o diagrama envolve duas entidades empresariais e so separados fisicamente no diagrama. As atividades dentro de grupos separados so consideradas processos autocontidos.
Os fluxos de sequncia no podem cruzar a fronteira de um pool. Deve-se usar o fluxo de mensagem como mecanismo para mostrar a comunicao entre dois participantes em pools diferentes. 8.2.3.1 Pool

Pool representa um participante em um processo (pessoa, rea, empresa, outro processo etc.). Atua como um container grfico para o particionamento de um conjunto de atividades de um ou mais processos de um participante.
129

Unidade IV
class BPMN

<<Pool>>

Cliente

Figura 76 Exemplo de um diagrama com pool

8.2.3.2 Lane

Lane uma subpartio dentro de um pool que vai se estender a todo comprimento do pool, tanto verticalmente quanto horizontalmente. Lanes so usadas para organizar e categorizar atividades.
As lanes so elementos que so posicionados dentro de pools para indicar mais de um perfil que colaboram para a execuo de um processo. Lanes criam subparties para os objetos dentro de um pool. Essas participaes so usadas para agrupar elementos do processo. So frequentemente usadas para separar as atividades associadas com uma funo ou papel de uma determinada empresa. Os fluxos de sequncia podem atravessar as fronteiras das lanes dentro de um pool. O fluxo de mensagem no pode ser usado entre fluxos de objetos nas lanes de um mesmo pool.
class BPMN

<<Pool>> HELPDESK CAC

Cliente

Figura 77 Uma pool com duas lanes

A figura 78 mostra um exemplo de um BDP com duas pools, sendo que essas somente possuem uma lane cada. 130

ModelageM de Processos
class BPMN

<<Pool>>

PACIENTE

Ocorre doena

Envia pedido mdico

Eu quero ver o mdico

Recebe pedido sintomas

Envia sintomas
Eu me sinto doente

Recebe receita

Consultrio Mdico

<<Pool>>

O mdico pede sintomas

Pegue sua receita para comprar os remdios

Envia pedido mdico

Recebe pedido sintomas

Envia sintomas

Recebe receita

Figura 78 Exemplo de pools e lanes juntas

8.2.4 Artefatos A notao BPMN permite aos modeladores o uso de extenses de notao. Um nmero qualquer de artefatos pode ser adicionado ao diagrama, conforme as necessidades apropriadas ao contexto de negcio sendo modelado. A verso corrente do BPMN predefine trs tipos de artefatos BPD: objeto de dados; grupo; e anotao. Os modeladores podem criar seus prprios tipos de artefatos, que podem adicionar mais detalhes sobre como o processo executado. A figura 79 mostra um diagrama com lanes dentro de uma pool e com adicionamento de artefatos.

131

Unidade IV
class BPMN

Administrao

Informaes pagamento

<<Group>> Prepara ordem de pagamento +

Web Service

E-mail requisio aprovao

Aprova requisio

Gerenciamento

Despacha para aprovao

Estas atividades podem ser iniciadas ao mesmo tempo

Figura 79 Uso de artefatos no BPD

8.2.4.1 Objeto de dados So mecanismos para mostrar que dados so requeridos ou produzidos pelas atividades. So conectados s atividades a partir das associaes.
BPMN BPMN

<<Group>> Grupos

Objetos de dados Anotaes

Figura 80 Artefatos do BPD

8.2.4.2 Grupo Um grupo pode ser usado para documentao, mas no afeta o fluxo de mensagens. 8.2.4.3 Anotao um mecanismo para um modelador colocar textos de informaes adicionais no diagrama.

132

ModelageM de Processos
8.3 Concluso do BpMN

Um objetivo-chave da BPMN foi criar uma ponte entre a notao da modelagem de processos de negcios e a modelagem de linguagens orientadas para TI, que ir implementar os processos dentro de um sistema de gesto de processos de negcios. Observao Os objetos grficos da BPMN, apoiados por um rico conjunto de atributos de objeto, foram mapeados para o Business Process Execution Language for Web Services (BPEL4WS v 1.1), o padro de fato para a execuo do processo. Resumo Esta unidade mostrou os conceitos envolvidos com a modelagem de negcios que precede a modelagem de sistemas de informao. Mostrou tambm que a UML prope uma notao e um padro de modelagem voltados para a especificao das regras de negcio de uma funo e processo de negcio de uma organizao. A OMG tambm vem propondo o uso da nova notao denominada BPMN, que est sendo preparada para novas ferramentas de automao de aplicaes a partir dos modelos de negcio. O uso dessa combinao tem como grande objetivo colocar a rea de desenvolvimento de sistemas totalmente casada com s reas de negcio e construindo aplicaes que agreguem valor ao negcio. Com relao s organizaes, elas esto descobrindo que a modelagem de processos de negcio pode ser uma excelente ferramenta para disseminar o conhecimento organizacional. Uma vez que as organizaes passam a compreend-lo como um recurso, a modelagem de processos de negcio pode tornar-se uma excelente fonte para a vantagem competitiva. Processos de negcio estruturados na cooperao, integrao e no alinhamento entre todas as reas organizacionais constituem o segredo de sucesso de uma organizao. Atualmente, o modelo de caso de uso de negcio pode ser aplicado nos modelos de desenvolvimento em cascata, na fase de levantamento 133

Unidade IV
de requisitos de negcio, e no modelo iterativo RUP, na fase de iniciao, tambm para modelagem dos requisitos de negcio que precedem as definies e especificaes dos modelos dos sistemas de informao da organizao. Exerccios Questo 1. Os autores definem que processos de negcio so um conjunto de atividades previamente estabelecidas cujo objetivo determinar como o trabalho ser realizado em uma organizao por uma rea de negcio. Diz-se que uma estrutura de processos de negcio mal concebida pode por em risco a eficincia e a eficcia da organizao por meio dos produtos e servios gerados e disponibilizados. Considerando os conceitos sobre processos de negcio, analise as afirmaes a seguir e assinale a alternativa incorreta: A) Uma funo de negcio a mesma coisa que um processo de negcio, j que ambos representam o conjunto de atividades de uma organizao. B) Processos de negcio so atividades transfuncionais previamente estabelecidas para tratar um determinado negcio da organizao. C) Um sistema de informao bem estruturado implementa processos de negcio de uma empresa ou organizao. D) Uma Funo de Negcio representa a estrutura funcional da Organizao, j que um Processo de Negcio um conjunto de atividades ou aes que so transfuncionais, isto , atravessam diversas reas ou funes de negcio. E) Os processos de negcio devem funcionar de forma alinhada em relao a toda a estrutura organizacional, pois somente dessa forma ser possvel atingir os objetivos transversais de qualquer organizao. Resposta: Alternativa A. Alguns autores definem processo de negcio ou processo organizacional como sendo um conjunto de atividades. Nesse conjunto, uma organizao deve ser estruturada com o objetivo de produzir valor para os seus clientes. Anlise das alternativas A) Incorreta. Funo de negcio uma representao de uma estrutura dentro de uma organizao. Por exemplo: o departamento financeiro uma funo de negcio; j um sistema financeiro (processo de negcio financeiro), atua em diversas reas da empresa. Quando se mapeia o processo de negcio financeiro, torna-se necessrio entender diversas reas ou 134

ModelageM de Processos
funes da empresa, que, de alguma forma, utilizam ou precisam tratar com as informaes financeiras da empresa. B) Correta. Os processos de negcio esto diretamente ligados aos negcios da empresa e independem da estrutura organizacional. Normalmente atravessam as fronteiras das funes de negcio. C) Correta. Um sistema de informao automatiza atividades dos processos de negcio, e, se ficarem estritamente ligados a uma funo da empresa, no sero eficazes na busca de valor para a instituio. D) Correta. uma funo de negcio representa uma estrutura funcional de uma empresa, por exemplo: rea de TI, rea de Logstica etc. E um processo de negcio seria a venda de carros de luxo de uma montadora de veculos. E) Correta. A venda de carros de luxo de uma montadora possuir atividades espalhadas por toda a estrutura de uma montadora: rea de marketing, design de veculos, linha de produo, e assim por diante. Questo 2. Na atualidade, com propsito de se ter sistemas de informaes abrangentes e que agreguem valor ao negcio de uma organizao, evolue-se para duas vises complementares: a modelagem de negcio e a modelagem de sistemas de informao. Normalmente, as modelagens de negcio e de sistemas (software) so desenvolvidas como parte de dois diferentes projetos, com dois diferentes times. A modelagem de negcios trata todas as atividades envolvidas com o negcio, e a modelagem de sistemas verifica o aspecto de automao a partir do modelo de negcio. Ambas devem possuir boa definio, pois so ferramentas importantes para o gerenciamento da complexidade da amplitude e dificuldade do sistema. Considerando os conceitos sobre Arquitetura de negcio, Arquitetura de Software e exemplos apresentados nesta unidade, analise as afirmaes a seguir e assinale a alternativa incorreta: A) Para a modelagem de negcio, utiliza-se a notao BPMN, a qual surgiu como um padro alternativo UML, j que esta foi desenvolvida para abranger somente as atividades de desenvolvimento de software. B) A modelagem de negcio com BPMN grfica, porm, para representar as atividades existentes nos processos de negcio, seus smbolos so um pouco diferentes da UML. C) Quem desenvolveu o BPMN foi o Instituto de Engenharia de Software, em 1991. D) Pode-se afirmar que o processo de modelagem de negcios um conjunto estruturado de atividades, desenhado para produzir um resultado especfico para um cliente ou um mercado em particular. E) A modelagem de negcio leva em considerao que um processo uma ordenao especfica de atividades de trabalho, por meio do tempo e do espao, com comeo, fim e entradas e sadas claramente identificadas: uma estrutura para ao. Resoluo desta questo na plataforma. 135

FIGURAS e ILUSTRAeS Figura 2

Estrutura de um modelo de AOO. Adaptada de YOURDON, E.; ARGILA, C. Anlise e projeto orientados a objetos, So Paulo: Makron Books, 1998.
Figura 3

Exemplo de uma aplicao da AOO. Adaptada de YOURDON, E.; ARGILA, C. Anlise e projeto orientados a objetos, So Paulo: Makron Books, 1998.
Figura 57

Processos de negcio. Disponvel em: <http://www.trainning.com.br/analistadenegocios_bpm_artigo. asp>. Acesso em: 14 mai. 2012.
Figura 59

Relacionamento de processos, Sistemas de Informao (SI) e Redes de Computadores (RC). PAUL, R. J.; SERRANO, A. Simulation for business processes and information systems design. Anais da Conferncia de Simulao de Inverno de 2003. Departamento de Sistemas de Informao e Computao, Universidade de Brunel, U.K.: Uxbridge Middlesex, 2003.
Figura 60

O relacionamento entre Engenharia de processo de negcio e Engenharia de software. RUP. Rational Unified Process. Rational Software Corporation, verso 2002.05.00, 2001.
Figuras 61 e 62

Processo iterativo aps o surgimento da modelagem de negcio e Modelagem de negcio como fase integrante do processo iterativo. BOGGS; BOGGS. Mastering UML with Rational Rose. SYBEX Sample Chapter. 2002.
Figura 63

Integrao entre modelagem de negcio e sistema. RODRIGUES, V. M. S. Mapeamento de processos de negcio com base nas extenses de penker e eriksson para casos de uso. Portugal. 2004.
Figura 64

O esforo da modelagem de negcios e requisitos. RUP. Rational Unified Process. Rational Software Corporation, verso 2002.05.00, 2001.
136

ReFeRNCIAS BRANCO, I. V. C. Modelagem de processos organizacionais integrada s aplicaes prticas de aprendizagem organizacional e compencias conversacionais. Dissertao de Mestrado da UCB, Brasilia, Brasil, 2007. BOGGS; BOGGS. Mastering UML with Rational Rose. SYBEX Sample Chapter. 2002. BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML guia do usurio. Rio de Janeiro: Editora Campus, 2000. COCKBURN, A. Escrevendo casos de uso eficazes um guia prtico para desenvolvedores de software. Traduo de Roberto Vedoato. 1 ed. Porto Alegre: Bookman, 2005. DALAL, N. et al. Toward an integrated framework for modeling enterprise processes. Communications of the ACM, v. 47, n 3, 2004. ERIKSON, H.; PENKER, M. Business modeling with UML: business patterns at work. John Wiley & Sons, 2000. HUCKVALE, T.; OULD, M. Process modeling: why, what and how., New York, EUA: Jonh Wiley, 1993. FURLAN, J. D. Modelagem de objetos atravs da UML, So Paulo: Makron Books, 1998. JACOBSON, I; BOOCH, G; RUMBAUGH, J. The unified software development process. Indianpolis, EUA: Addison Wesley, 1999. JACOBSON, I; BOOCH, G; RUMBAUGH, J. The unified modeling language user guide. Massachusetts, EUA: Addison Wesley, 1999. LAUDON, K. C.; LAUDON, J. P. Gerenciamento de sistemas de informao. Rio de Janeiro: LTC, 2001. MEDEIROS, E. Desenvolvendo software com UML. So Paulo: Makron Books, 2004. OMG. Object management Group. Disponvel em: <http://www.uml.org/>. Acesso em: 17 ago. 2005. PAUL, R. J.; SERRANO, A. Simulation for business processes and information systems design. Anais da Conferncia de Simulao de Inverno de 2003. Departamento de Sistemas de Informao e Computao, Universidade de Brunel, U.K.: Uxbridge Middlesex, 2003. PFLEEGER, S. L. Engenharia de software teoria e prtica. So Paulo: Prentice hall, 2004. RUMBAUGH, J. et al. Modelagem e projetos baseados em objetos. So Paulo: Editora Campus, 1994. REED JR., P. R. Desenvolvendo aplicativos com Visual Basic e UML. So Paulo: Makron Books, 2000. 137

RODRIGUES, V. M. S. Mapeamento de processos de negcio com base nas extenses de Penker e Eriksson para casos de uso. Portugal, 2004. RUP. Rational Unified Process. Rational Software Corporation, verso 2002.05.00, 2001. SENGE, P. M. A quinta disciplina: arte, teoria e prtica da organizao de aprendizagem. So Paulo: Best Seller, 1990. SZILAGYI, D. C. Modelagem de processos de negcio um comparativo entre BPML e UML. Dissertao de Mestrado da Pontifcia Universidade Catlica So Paulo, 2010. YOURDON, E.; ARGILA, C. Anlise e projeto orientados a objetos, So Paulo: Makron Books, 1998. WIDRIG, D.; LEFFINGWELL, D. Managing software requirements: a use case approach. 2 ed. Addison Wesley, 2003.

138

139

140

141

142

143

144

Informaes: www.sepi.unip.br ou 0800 010 9000