BPM Beyond Process Modelling

Tamanho: px
Começar a partir da página:

Download "BPM Beyond Process Modelling"

Transcrição

1

2 Introdução 1.1.Contextualização A partir dos anos 90 as empresas passaram a estruturar-se através da gestão por processos, buscando uma maior integração e eficiência de suas operações. A gestão por processos está calcada em modelos de processos e notações de processos. O primeiro representa a um conjunto de atividades que expressa um processo na empresa e o segundo seria a regra para a representação dessas das atividades no processo. Assim sendo, algumas empresas começaram a enxergar essa iniciativa de gestão por processo com uma boa oportunidade de mercado e começaram a prestar serviços em Business Process Management e softwares, criando seus próprios padrões de modelagem. Em conseqüência disso, o mercado passou a apresentar uma série de notações para modelagem, mas que representavam um grande problema para as organizações, já que não apresentavam uma linguagem comum na modelagem de seus processos. Este fato acabava por criar uma série de ruídos ao tentar integrar processos modelados em linguagens diferentes, já que notações diferentes dificultam a comparabilidade entre processos, além de inibir a utilização de modelos de referencia e benchmarking na melhoria dos processos. O interesse atual na abordagem de notações e modelagem de processos fez com que inúmeras expectativas surgissem no mercado. Quer se trate de Business Process Reengineering (BPR), Business Process Management (BPM), Activity Based Costing (ABC), ou Business Activity Monitoring (BAM), a notação de processos e a sua modelagem participam cada uma destas abordagens. A chegada de padrões de modelagem já está resultando na racionalização de processos, criando uma base de conhecimentos que pode ser partilhada pelos players no mercado.

3 Dado esse cenário, começaram a surgir alguns grupos na tentativa de unificar as notações existentes. Em junho de 2005 foi criado o Business Modeling & Integration (BMI), Domain Task Force (DTF), através da fusão entre o Business Process Management Initiative (BPMI.org) e o Object Management Group (OMG ). Com essa união, alguns padrões de modelagem foram criados, sendo o Business Process Management Notation (BPMN) um dos mais importantes. 1.2.Definições Abaixo seguem algumas definições que serão utilizadas no decorrer desse wiki. Tabela 1 Definições (FONTE: ELO Group) Conceito Definição Exemplo Business Process Modeling (BPM) Modelo BPM é uma abordagem utilizada para identificar, desenhar, documentar, mensurar, monitorar e controlar tanto processo de negócios automatizados quanto não-automatizados com o objetivo de alcançar resultados que estejam alinhados com as metas estratégicas da organização. ABPMP CBOK Um modelo pode ser entendido como uma representação explícita e externa de parte da realidade vista por pessoas que desejam usar o modelo para: entender, mudar, gerenciar e controlar esta parte da realidade de alguma forma. Pidd (1999). Não aplicável Desenho com a representação de uma rede hidráulica de uma casa Modelo de Processo Modelo de processo é um conjunto de atividades envolvidas na criação de representações de um processo novo ou de um já existente. ABPMP CBOK Passo-a-passo de como se cozinha um arroz. Notação de modelo de processos Conjunto de sinais com que se faz essa representação ou designação. Dicionário Michaellis BPMN, UML, IDEF A figura a seguir exemplifica as definições apresentadas anteriormente:

4 Figura 1 Princípio da modelagem de processo (FONTE: ELO Group) 1.3.Motivações e Benefícios Esperados Segundo Vernadat ² apud Chaulhoub (2004), a modelagem de processos de negócios apresenta os seguintes benefícios e motivações: Representar como são realizadas as atividades dentro da empresa, possibilitando um melhor entendimento de como ela funciona; Armazenar conhecimentos adquiridos e know-how organizacional para uma possível reutilização no futuro; Racionalizar e assegurar os fluxos de informação; Projetar/reprojetar e detalhar uma parte da empresa, contemplando aspectos funcionais, comportamentais, informacionais, organizacionais ou estruturais; Analisar diferentes aspectos da empresa (análise econômica, organizacional etc.); Possibilitar a realização de simulações;

5 Tomar melhores decisões em relação à organização e às operações empresariais; Controlar, coordenar ou monitorar os processos empresariais. Segundo Rashid M. Khan, em seu artigo What Standards Really Matter For BPM, a modelagem e notação de processos podem trazer alguns benefícios para a organização, como por exemplo: Promover o padrão de terminologias e definições dos processos de negócio. Isso acelera o entendimento dos processos, maximizando a sua compreensão e a capacidade de resposta rápida às necessidades dos clientes; A utilização de uma linguagem padrão e amplamente utilizada pelo mercado permite às empresas desenvolver, manter e atualizar seus processos de forma mais simples e rápida; Capacidade de integração entre processos de negócios que estejam modelados na mesma linguagem. Caso haja processos que estejam modelados em notações diferentes, a interação entre eles pode ser prejudicada; Outro grande benefício da padronização de uma linguagem é a facilidade que as empresas têm de migrar de uma notação baseada em BPM para a outra. Se há uma insatisfação com algum tipo de linguagem específica, a organização pode adequar-se a outra que segue o mesmo padrão em BPM. Ao facilitar a compreensão e auxiliar a navegação entre sistemas em BPM, este padrão irá reduzir os custos de realização dos processos e, assim, trazer vantagens para o consumidor final; Algumas linguagens em BPM têm uma forte base matemática envolvida em sua estrutura. Assim, notações baseadas em cálculos, como o BPEL estruturado sobre o Pi Calculus, minimiza as chances de erros se comparado a linguagens que não apresentam esse embasamento.

6 Revisão Teórica sobre Modelagem de Processos Abaixo seguem algumas opiniões de principais autores sobre modelagem de processos. 2.1.) ABPMP BPM CBOK e a Visão de Modelagem de Processos O objetivo da modelagem de processos é criar uma representação de um processo, descrito de maneira precisa, das atividades que estão sendo executadas na organização. No entanto, um modelo nem sempre será uma representação integral e completa do processo real, mas freqüentemente focará na representação das principais atividades. Portanto, deve-se ter atenção em até que ponto um simples diagrama será suficiente para representar um determinado processo. Modelos de processos têm muitas vantagens na gestão de operações empresariais, tais como a melhoria da comunicação através da criação de uma representação visível e o estabelecimento de uma perspectiva comum e compartilhada, facilitando a compreensão do leitor. Na gestão de processo de negócios, os modelos são os meios pelos quais as organizações gerenciam seus processos, analisando a sua performance e definindo mudanças. Eles expressam o foco do negocio da organização e especificam os recursos que permitem a efetiva operação do negócio: pessoas, informações, equipamentos, automação, finanças, energia etc. Alguns dos motivos mais comuns para a criação de modelos de processo são os seguintes: Documentar claramente um processo existente; Ajudar nos treinamentos através das atribuições de cada ator presentes nos processos; Usar como uma avaliação das normas e cumprimento das obrigações;

7 Compreender o comportamento do processo sob a ação de diferentes cargas ou sob alguma mudança antecipada; Servir de base para análise na identificação de oportunidades para melhoria; Suportar o design de um novo processo ou uma nova abordagem para um processo já existente; Fornecer uma base para a comunicação e discussão organizacional; Descrever requisitos para uma nova operação da empresa. 2.2) Paul Harmon e a Visão de Modelagem de Processos O objetivo da modelagem de processos é simplificar, destacar, clarificar e comunicar. O autor não destaca uma notação específica para a modelagem de um processo, justificando que se deve escolher um determinado padrão de notação que deixe as idéias mais claras possíveis para o leitor, ressaltando que qualquer notação de difícil compreensão e muito complexa é contraproducente.ao mesmo tempo, é importante permitir que qualquer pessoa da organização consiga compreender os diagramas de processos de forma clara e, para tal, faz-se necessário focar num mesmo conjunto de convenções. Acredita-se que a essência central dos elementos que a notação BPMN disponibiliza hoje é o que há de melhor. Por outro lado, quando é encontrada alguma situação que não é facilmente expressada pelo BPMN, às vezes as pessoas se sentem livres para ampliar informalmente o BPMN para ter certeza de que um determinado ponto de vista foi expresso da forma mais clara possível. 2.3) ROSEMANN e PIDD e o Principio de Modelagem Muitos autores têm discutido sobre a visão dos princípios de modelagem. Neste âmbito, alguns confirmam que os princípios de modelagem são essenciais para a criação de modelos robustos.

8 Há uma grande dificuldade na modelagem de processos de negócios e isto se dá pelo fato das pessoas terem percepções diferentes para o mesmo problema. Para minimizar essas divergências, busca-se modelar processos simples, que não incluem a complexidade da realidade. Abaixo segue a visão de dois autores sobre o principio de modelagem. Visão de ROSEMANN 1. Aderência: norteia quanto à proximidade que se está da realidade modelada. Técnicas de levantamento e validação de modelos de processos são aplicadas para aumentar a aderência e compatibilizar as diferentes percepções acerca de como o processo realmente é. 2. Relevância ou suficiência: todo objeto representado em um modelo deve ter um propósito, ou seja, um modelo só deve conter informações relevantes. Por isso, a definição do que é ou não relevante deve ser cautelosa. 3. Custo/benefício: este princípio visa analisar a quantidade necessária para criar o Modelo versus Utilidade do modelo versus Tempo de uso do modelo. 4. Clareza: este princípio é um dos mais importantes, pois se relaciona à capacidade de ser entendido e usado pelos usuários. 5. Comparabilidade: para que os processos sejam comparáveis é preciso aplicar os mesmos métodos a todos, corrigindo e uniformizando a nomenclatura e os níveis de detalhamento para que fiquem homogêneos. 6. Estruturação sistemática: este princípio está ligado à capacidade de integrar modelos representando diversos aspectos da realidade e, nesse sentido, à capacidade desses modelos de se conectarem metodologicamente.

9 Visão de PIDD 1. Modele simples, pense complicado; 2. Seja parcimonioso, comece pequeno e vá adicionando; 3. Divida e conquiste, evite megamodelos; 4. Use metáforas, analogias e similaridades; 5. Não se apaixone por dados; 6. A construção do modelo deve ser esclarecedora.

10 Notações de modelagem: BPMN 4.1 Apresentação O Business Process Modeling Notation (BPMN) é uma representação gráfica especificada para processos de negócio de workflow. Elaborado pela Business Process Management Initiative (BMPI.org), teve a sua primeira versão publicada em novembro de Desde 2005 esta notação de modelagem é atualizada pela Object Management Group (OMG ),, após a fusão desta com a BPMI. Em seguida foi lançada a versão 1.1 sobre a notação, mas, dada a necessidade de atualização e algumas pequenas alterações, foi publicada a versão 1.2. Atualmente está sendo produzida a versão 2.0, que vai apresentar grandes mudanças em seu escopo original, objetivando uma maior coerência para essa notação. Após a sua publicação, o BPMN emergiu como o principal padrão de modelagem utilizado pelos especialistas no tema. Além disso, pesquisas feitas revelam que as organizações apresentam um interesse especial sobre esse padrão de modelagem. Utilizado para comunicar uma variedade de informações para uma ampla variedade de telespectadores, o BPMN é projetado para cobrir vários tipos de modelagem, permitindo a criação de processos de ponta à ponta da cadeia. A sua estrutura de elementos permite ao leitor a fácil distinção entre as seções de um diagrama BPMN. O BPMN apóia os conceitos de modelagem que são aplicáveis aos processos de negócio. Isto significa que outros tipos de modelagens feitas por organizações sem o foco em negócio fogem ao escopo de atuação desta representação. Abaixo seguem alguns exemplos de modelos que não estão no escopo de atuação do BPMN:

11 Estruturas organizacionais e recursos; Modelos de funções de departamentos; Modelos de dados e informações; Modelos de estratégia empresarial; Modelos regras de negócios. 4.2 Visão geral de BPMN Hoje existem três modelos básicos para a modelagem no padrão BPMN: 1. Processos privados de negócios (interno); 2. Processos abstratos (público); 3. Processos colaborativos (global). Abaixo os modelos básicos para modelagem BPMN são detalhados. Processos Privados de Negócios (interno) Os processos privados de negócios referem-se a uma organização específica e são do tipo de processos que têm sido chamados de workflow ou processos BPM. Ao modelar esse tipo de processos, serão utilizadas raias de executores ou suporte e nelas é representado um determinado fluxo de atividades. O fluxo de atividades está contido em apenas uma única raia, mas quando se trata de fluxo de informação, passa-se a permitir a travessia entre raias, de forma a demonstrar as iterações existentes entre processos privados de negócio distintos. Figura 2 Exemplo de Processos privados de negócio

12 Processos Abstratos (público) Os processos abstratos representam a interação entre os processos internos da organização e um processo ou participante externo a essa organização. Somente as atividades que são utilizadas na comunicação com o exterior do processo do negocio estão inclusos nesse tipo de modelo básico.todos os outros processos internos não são mostrados nos processos abstratos. Assim, os processos abstratos mostram para o mundo exterior a seqüência de mensagens que são necessárias na interação com outro processo ou participante externo. Além disso, eles podem ser representados dentro de uma raia de executores ou suporte e modelados dentro de um único diagrama BPMN para mostrar o fluxo de mensagem com outras entidades. Caso o processo abstrato esteja dentro de um processo privado de negocio eles podem ser representados em um mesmo diagrama. Figura 3 Exemplo de Processos Abstratos Processos Colaborativos (global) O processo de colaboração se refere à interação entre duas ou mais entidades de negocio. Essa interação é definida como uma seqüência de atividades que representa as trocas de mensagem entre os envolvidos. Um único processo de colaboração pode ser mapeado em várias linguagens, como ebxml, BPSS, RosettaNet. Esse modelo pode ser realizado em um ou mais processos, indicando os locais onde há comunicação entre eles. No caso de ser em um único modelo, cada raia

13 de executor ou suporte representa cada um dos participantes. Assim sendo, se estivermos tratando de um processo privado e que esteja sendo modelado no mesmo diagrama BPMN, devem-se associar as atividades que são comuns a ambos os processos. Figura 4 Exemplo de Processos Colaborativos Tipos de Diagramas de BPMN Dentro e entre cada um desses modelos de processos de BPMN, muitos outros tipos de diagramas podem estar sendo criados. A seguir estão os tipos de processos de negócio que pode ser modelado com BPMN (aqueles com asterisco não podem ser mapeados para uma linguagem executável). Processo privado de atividade de alto nível (repartição nãofuncional) * Processo de negócio privado detalhado o AS-IS ou processo de negócio antigo * o TO-BE ou processos de negócios novos Detalhamento dos processos de negócios privados com interações com um ou mais entidades externas (ou processos "caixa preta")

14 Duas ou mais interações de processos de negócio privados detalhados Detalhamento do relacionamento de processos de negócios privados com processos abstratos Detalhamento do relacionamento de processo de negócios privados com processos colaborativos Dois ou mais processos abstratos * Relacionamento de processos abstratos com processos colaborativos* Processo colaborativo apenas (por exemplo, ebxml BPSS ou RosettaNet)* Abaixo segue um modelo de processo com a notação BPMN: Figura 5 Exemplo de Modelagem em BMPN

15 Principais objetos da notação BPMN: Tabela 2 Principais objetos da notação BPMN (FONTE: Stephen A. White) Elemento Descrição Notação Evento Um evento é o que acontece durante a execução do processo. Esses eventos afetam o fluxo do processo e geralmente tem uma causa (gatilho) ou um impacto (resultado). Existem três tipos de eventos, baseados quando eles afetam o fluxo. São eles: início, intermediário e finalístico. Atividade A atividade é um termo genérico que representa o trabalho que a empresa executa. Os tipos de atividades que são parte do modelo de processos são: processos, sub-processos, e tarefas. Tarefas e sub-processos tem a forma de retângulos com as pontas arredondadas. Os processos são modelados dentro de raias. Gateway O Gateway é usado para controlar as divergências e convergências da seqüência do fluxo. Desse modo, esse elemento determina a ramificação no processo, fusão, e a junção de trilhos diferentes do fluxo. Seqüência do fluxo A seqüência do fluxo é usada para demonstrar a ordem de como as atividades serão executadas no fluxo do processo. Mensagem do fluxo A mensagem do fluxo é usada para mostrar o fluxo de mensagens presentes entre dois participantes do processo que a envia e a recebe. Em BPMN, duas raias distintas representam participantes diferentes do processo. Associação Uma associação é usada para associar informações aos objetos do fluxo. Textos e diagramas podem ser associados a tais objetos.

16 Raias Uma raia representa um participante do processo, podendo ser representado por uma raia de piscina através de uma representação gráfica que contém um conjunto de atividades que podem apresentar relação com outras raias, geralmente em um contexto de B2B. Lane A Lane é uma subpartição pertencente a uma determinada raia do fluxo e se estende por todo o comprimento da raia, tanto verticalmente quanto horizontalmente. Lanes são usadas para organizar e categorizar atividades. Objeto de dados Os objetos de dados são considerados artefatos já que não apresentam nenhum efeito direto sobre a seqüência ou sobre as mensagens do fluxo, mas ele prove algumas informações de como as atividades são executadas. Grupo (caixa em volta de um conjunto de objetos em uma mesma categoria) É um grupo de atividades que pertence a uma mesma categoria. Esse agrupamento não afeta a seqüência do fluxo ou as suas atividades. O nome da categoria aparece no diagrama como o rótulo do grupo. Categorias podem ser utilizadas para a documentação ou análise de efeitos. Grupos são formados com o objetivo de destacar visualmente categorias de objetos no fluxo Anotações em texto Anotações em texto é um mecanismo utilizado pelo modelador com o objetivo de prover informações adicionais ao leitor do diagrama em BPMN. 4.3 Considerações finais O grande sucesso do BPMN está calcado em três pilares. O primeiro é o fato de ser uma linguagem de fácil compreensão a todos os envolvidos com processos. Assim, tanto usuário de negócios quanto profissionais de TI conseguem facilmente ler um processo em BPMN. Assim, o BPMN se torna uma linguagem comum entre a maioria dos departamentos da empresa, aumentando a integração entre as mesmas.

17 O segundo está no fato do BPMN apresentar uma serie de recursos que torna possível a modelagem de processos simples até os mais complexos. Esses recursos são opcionais, mas, se utilizados, permitem a modelagem em um nível bastante refinado, agregando várias informações técnicas e permitindo o mapeamento automático para padrões de execução de processos, como o BPEL. Por fim, o terceiro pilar do sucesso desta notação de modelagem está calcado em uma sólida fundamentação matemática. Construído baseado no conceito do Pi-Calculus, uma derivação do Cálculo de Processos para a representação de processos dinâmicos e móveis, o que permitiu uma grande solidez em seu conceito e aceitação no mercado. Outra questão relevante é o fato do BPMN ter a capacidade de detalhar diversos modelos em seqüência. No entanto, deve-se ter cuidado, pois, quanto mais subprocessos combinados, como, por exemplo, três ou mais subprocessos trocando informações entre si, mais se dificulta a leitura do seu diagrama e, por conseqüência, a sua compreensão. Recomenda-se que se tenha bastante cuidado a fim de facilitar a leitura do processo.

18 IDEF As informações abaixo estão fortemente baseadas no site e o artigo Integration Definition For Function Modeling (IDEFØ), do National Institute of Standards and Technology. 5.1 Apresentação O IDEF (Integration DEFinition) é um padrão de modelagem para softwares. Ele tem uma abrangência de utilização para a modelagem de simulação, informações, análise à orientação ao objeto e design e aquisição de conhecimento. Teve a sua criação iniciada na década de 70, e foi finalizado durante os anos 80. O IDEF surgiu a partir do padrão de modelagem ICAM (Integrated Computer-Aided Manufacturing), criado pelas forças armadas norte americanas. Apresenta uma estratégia abrangente que permite a representação empresarial e organizacional de forma integrada e, por isso, tem se transformado em um dos principais padrões. Ele é dividido em alguns métodos de modelagem, conforme a Figura 6.

19 Figura 6 Métodos IDEF (FONTE: Mayer, 1995 Apud Paim, 2002) Abaixo está à descrição de alguns desses métodos: IDEFØ Modelagem funcional; IDEF1 Modelagem de informações; IDEF2 Modelagem para simulação; IDEF3 Modelagem para a descrição e captura de processos; IDEF4 Modelagem orientada por objetos; IDEF5 Modelagem para a descrição de ontologia; IDEF6 Modelagem para a racionalização de descrições; IDEF7 Modelagem para a auditoria de sistemas de informação; IDEF8 Modelagem de projetos de sistemas com interação humana; IDEF9 Modelagem para identificação de restrições nos processos; IDEF10 Modelagem de artefatos de informação; IDEF12 Modelagem para projeto organizacional;

20 Conforme analisado acima, o IDEF apresenta algumas notações voltadas para a modelagem de processos. As descrições abaixo serão focadas no IDEFØ e IDEF IDEFØ Modelagem funcional Criado a partir de uma linguagem gráfica bem estabelecida, o Structured Analysis and Design Technique (SADT), o IDEFØ é um método concebido para a modelagem de decisões, ações e atividades de uma organização ou sistema. Essa notação foi encomendada pelas Forças Aéreas dos Estados Unidos para exercer a função de desenvolver um método de modelagem e de comunicação das funcionalidades de um sistema. Efetivamente os modelos IDEFØ ajudam a organizar as análises dos consumidores. Esse padrão de modelagem é útil para estabelecer o escopo de análise, especialmente em análises funcionais. Como uma ferramenta de comunicação, o IDEFØ auxilia o modelador a identificar quais as funções são realizadas, o que é necessário para as realizações de algumas funções, o que um sistema atual faz de correto e o que o sistema faz de errado. Assim, os modelos IDEFØ são freqüentemente criados como uma das primeiras tarefas do desenvolvimento de um sistema. O método IDEFØ tem um conceito básico que endereça cada necessidade discutida anteriormente. O Conceito básico do IDEFØ são os seguintes, conforme abaixo. Célula de Modelagem de Representação Gráfica A representação gráfica da "caixa e seta" de um diagrama do IDEFØ funciona como uma caixa e as suas interfaces ou de suas funções como setas entrando ou saindo da caixa. Para expressar as funções, caixas operam simultaneamente com outras caixas, como interfaces, através de setas indicando quando e como as operações são desencadeadas e

21 controladas. A base de sintaxe para o modelo IDEFØ é mostrada na figura abaixo. Figura 7 Esquema do modelo IDEFØ Objetivos e Aplicação Os principais objetivos desse padrão de modelagem são: a. Prover recursos para uma completa e consistente modelagem de funções (atividades, ações, processos, operações) requeridas por um sistema ou empresa, e as funções de relacionamento e dados (informação ou objetos) que suportam a integração entre estas funções. b. Prover uma técnica de modelagem que seja independente dos métodos ou ferramentas do Computer-Aided Software Engineering (CASE), mas que possa ser usado em conjunto com essas ferramentas e métodos; c. Prover a técnica de modelagem que tenham as seguintes características:

22 a. Genérica (para análise de sistemas com diferentes propósitos, escopo e complexidade); b. Precisa e rigorosa (para produzir corretamente modelos utilizáveis); c. Concisa (para facilitar a compreensão, comunicação, consenso e validação) d. Conceitual (para a representação dos requerimentos das funções físicas ou de implementações organizacionais); e. Flexível (para suportar as várias fases do ciclo de vida de um projeto). A utilização desse padrão de modelagem é fortemente recomendada em projetos que: a. Requerem técnicas de modelagem para a análise, desenvolvimento, re-engenharia, integração ou aquisição de informações de sistemas; b. Incorporam sistemas ou técnicas de modelagem empresarial para análises de processos de negócio ou metodologia de software de engenharia. As especificações desse padrão de modelagem são aplicáveis quando sistemas ou técnicas de modelagem empresarial são aplicados seguintes itens: aos a. Projetos que necessitem o IDEFØ como técnica de modelagem; b. Desenvolvimento de ferramentas para softwares automatizados para a implementação da técnica de modelagem IDEFØ. As especificações desse padrão não são aplicáveis aos projetos que necessitam de técnicas de modelagem funcionais.

23 Pontos fortes e fracos do IDEFØ A principal força do IDEFØ baseia-se no fato de ter sido comprovada a sua eficiência no detalhamento das atividades de um sistema. As atividades podem ser descritas por suas entradas, saídas, controles e mecanismos. Além disso, as descrições das atividades de um sistema podem ser facilmente refinadas em maior detalhe até o quanto for necessária para a tomada de decisão. Com isso, um dos problemas observados nessa notação é o fato de ser, às vezes, tão conciso que apenas o desenvolvedor ou alguém que participou da modelagem tenha a completa compreensão do modelo. A natureza hierárquica do IDEFØ favorece a construção de modelos (AS- IS) que tenham uma representação e interpretação top-down, mas que se baseiam na análise de processo bottom-up. De forma geral, o modelador deve agrupar atividades intimamente relacionadas ou até com funcionalidades similares. Através desse processo de agrupamento, a hierarquia surge. Caso se esteja tratando de uma organização que está começando a construir a sua hierarquia, geralmente chamada de modelagem TO-BE, a construção top-down é mais indicada. Assim, constrói-se a idéia mais macro e depois se passa aos níveis mais detalhados. Quando se fala de uma organização que já apresenta uma arquitetura consolidada, geralmente chamada de modelagem AS-IS, observa-se que as atividades podem ser descritas para, em seguida, serem combinadas em um nível mais agregado. Este processo continua até que se chegue ao nível mais desejável de agregação. Um problema com IDEFØ é a tendência de esses modelos serem interpretados como uma representação de atividades em seqüência. Apesar do IDEFØ não ser utilizado para a modelagem de atividades em seqüência, é fácil fazê-la. As atividades podem ser colocadas em uma seqüência da esquerda para a direita dentro de uma ordem e conectada com os fluxos. É natural ordenar as atividades da esquerda para a direita,

24 pois o output de uma determinada atividade também é utilizado como o input para outra, deixando as conexões entre as atividades um conceito bem claro. Assim, mesmo sem intenção, o raciocínio de seqüenciamento de atividade pode ser embutido no modelo IDEFØ. Nos casos em que o seqüenciamento de atividades não é incluído no modelo, os leitores tendem a acrescentar esse tipo de interpretação. Esta situação anômala poderia ser considerada um ponto fraco da IDEFØ. No entanto, para corrigi-la iria resultar na corrupção dos princípios básicos sobre os quais se assenta IDEFØ e, conseqüentemente, perderia a eficácia comprovada do método. Abaixo segue uma estrutura do diagrama do IDEFØ: Figura 8 Estrutura do diagrama do IDEFØ (FONTE: Integration Definition For Function Modeling (IDEFØ))

25 5.3 IDEF3 Modelagem para a descrição e captura de processos O IDEF3, Método de Captura de Descrição de Processo, provê um mecanismo para o armazenamento e documentação de processos. O IDEF3 captura a relação dos precedentes e das casualidades entre as situações e eventos em uma forma natural ao domínio dos especialistas, provendo um método estruturado para expressar o conhecimento de um sistema, processo, ou trabalhos de uma organização. O IDEF3 pemite: Registrar dados crus resultantes de fatos encontrados em entrevistas em atividades de análise de sistemas. Determinar o impacto nos recursos de informações de uma organização baseados nos principais cenários de operação de uma empresa. Documentar os procedimentos para decisões que afetam o estado e o ciclo de vida de um dado crítico e compartilhado, particularmente manufatura, engenharia, e definição da manutenção de dados de produtos. Gerenciar a configuração de dados e mudança das definições de políticas de controle. Produzir a concepção de sistema e o design de análise de trade-offs. Prover a geração de modelos de simulação. O IDEF3 tem a capacidade de compreender os aspectos comportamentais de um sistema existente ou sugerido e captura todas as informações temporais, incluindo processos empresariais. Os resultados das descrições do IDEF3 provêem a estruturação da base do conhecimento para construir modelos analíticos e de design. Infelizmente, linguagens de simulação (por exemplo: SIMAN, SLAM, GPSS, WITNESS) constroem modelos matemáticos, enquanto o IDEF3 constrói descrições estruturadas. Essas descrições capturam as informações do que um sistema de fato realiza ou vai realizar e ainda provê à organização uma série de visões dos diferentes usuários do sistema.

26 Existem dois modos para descrição do IDEF3:o fluxo de processo e a transição da rede do estado do objeto. A descrição do fluxo de processo captura o conhecimento de como as coisas funcionam em uma organização, por exemplo, a descrição de que acontece com uma parte, e como é o fluxo dela na seqüência do processo de manufatura. A segunda dimensão permite a transição completa de um objeto para um determinado processo. Ambas as dimensões contêm unidade de informações que compõem a descrição do sistema. As entidades dos modelos, como eles são chamados, formam a base das unidades de descrição do IDEF3. Os diagramas resultantes e textos compreendem o que é denominado descrição, em oposição ao foco do que é produzido pelos outros modelos IDEF, cujos produtos são um modelo. No IDEF3, o processo de descrição do fluxo de processos capta a descrição de um processo e a rede de relações que existe entre os processos dentro do contexto de um cenário em que eles estão contidos. O intuito desta descrição é mostrar como as coisas funcionam em uma determinada organização quando vistas como sendo parte de um problema particular, resolvendo ou demonstrando uma situação recorrente. O desenvolvimento de um processo deste tipo consiste em expressar fatos, coletados a partir do domínio de especialistas, em termos descritivos da construção de cinco blocos básicos. O exemplo a seguir ilustra como os blocos de construção do método IDEF3 podem descrever o cenário tipicamente encontrado em indústria de manufatura. A situação a ser descrita está baseada em um processo de pintura e de inspeção, relacionados com a aplicação de uma tinta em um módulo que se tornará um elemento de um pesado equipamento de construção. A figura abaixo é a representação gráfica do exemplo, que está baseado na entrevista de um supervisor de pintura de uma fábrica. Abaixo segue exemplo de um diagrama do IDEF3:

27 Figura 9 Exemplo de diagrama IDEF3 As caixas maiores são chamadas de Unit Of Behavior (UOB). As linhas são as conexões entre as UOBs e é isso que define o fluxo lógico do diagrama. As pequenas caixas no canto inferior esquerdo definem os mecanismos que introduzem o fluxo lógico do diagrama. 5.4 Considerações finais De forma geral, a proposta dos modelos e descrições é ajudar a tomar decisões. Cada tipo de modelo ou descrição foca em um relativo conjunto estreito de relacionamentos e características de sistemas, compreendendo um ponto de vista particular ou uma perspectiva global do sistema. Modelos de análises, por exemplo, são utilizados para determinar requerimentos existentes ou antecipar a sua concepção. Design de modelos servem para facilitar a otimização de recursos desejáveis de design para um conjunto de requerimentos de sistemas. Modelos de simulação provem um perspectiva de várias medidas e estatísticas associadas ao desempenho do sistema que podem ser geradas para examinar uma característica especifica de desempenho sobre um conjunto restrito de condições operacionais. Cada modelo e as decisões geradas através da sua construção têm uma relativa ponderação em direção ao nível global das decisões do sistema, criando uma competição de decisões dentro e entre tipos de modelos que eventualmente emergem, necessitando análises de trade-offs.

28 Como resultado, os modelos e as descrições nunca pretendem representar todas as possibilidades ou comportamentos de um sistema. Estes focam em um conjunto restrito de características de sistemas e acabam ignorando os aspectos que não são pertinentes na tomada de decisão. A família de métodos do IDEF busca um balanceamento favorável entre métodos especiais de aplicações efetivas limitadas a tipos de problemas específicos, e super modelos que incluem tudo que possa ser necessário. Este balanceamento é mantido com a família de métodos do IDEF provendo mecanismos explícitos para integração de resultados de aplicações de métodos individuais.

29 Notação de modelagem: ARIS AS informações abaixo estão fortemente baseadas em Paim (2002) e Chaloub (2004). 6.1 Apresentação A ferramenta ARIS Toolset é utilizada para suportar a metodologia ARIS de Modelagem de Processos de Negócios e está fundamentada na utilização de diversos modelos e objetos, através dos quais os processos de negocio de uma data organização podem ser representados e analisados. Essa metodologia foi desenvolvida objetivando a integração dos processos de negócios de uma organização. O primeiro passo para o desenvolvimento desta arquitetura foi a criação de um modelo que contivesse as principais características para se descrever um processo de negócio. O resultado foi um modelo complexo, sendo necessária, assim, a divisão em partes para interpretar o todo. Desta forma, criou-se uma divisão em vistas. Estas vistas são inter-relacionadas de forma que os modelos possam ser analisados holisticamente e sem redundância. Os modelos podem ser agrupados em cinco vistas: Organização, Função, Dados, Saída e Controle.

30 Figura 10 Aris House (FONTE: Organização dos Modelos, Scheer, 1998, p. 1) Nesta metodologia os principais modelos são: Cadeia de Valor Agregado - VAC; Diagrama de Objetivos - DO; Árvore de Funções - FT; Organograma - ORG; Diagrama de Entidades e Relacionamento - ERM; Estrutura de Conhecimento - KSD; Diagrama de Função - FAD; e Cadeia de Processos Orientada por Eventos - EPC, sendo este bastante importante para a visão de processos. Cada um destes modelos tem objetivos próprios, mas são utilizados de forma inter-relacionada, na lógica da metodologia. 6.2 Diagrama de Objetivos Em muitos casos, os projetos de modelagem estão ligados a discussões estratégicas que orientam processos. Baseado nisso, antes de realizar qualquer atividade de modelagem de processos, como analisá-los e redesenhá-los, é necessário conhecer os objetivos estratégicos da empresa.

31 Assim, esse diagrama permite que os objetivos organizacionais sejam definidos e hierarquizados. Além disso, podem ser identificados no modelo os fatores críticos para que sejam alcançados esses objetivos, e também as atividades ou processos relacionados a esse objetivo. Abaixo está a representação dos principais objetos utilizados nesse modelo. Figura 11 Objetos de modelagem do Diagrama de Objetivos (FONTE: Chalhoub) De acordo com a situação em que o objeto está envolvido, ele pode assumir diferentes significados. Nesse diagrama, o objeto função é utilizado para representar atividades ou processos que estejam relacionados aos objetivos mapeados. Além disso, a ligação presente entre os objetos desse diagrama também pode ter significados diferentes, de acordo com a sua disposição. Assim sendo, deve-se ter atenção não apenas nos objetos que compõe o diagrama, mas também nas ligações existentes entre eles. A seguir seguem alguns exemplos de diagramas de objetos modelados no ARIS.

32 Figura 12 Exemplo de hierarquização no diagrama de objetivos (FONTE: Chalhoub) Figura 13 Exemplo de relacionamento entre atividades, objetivos e fatores críticos (FONTE: Chalhoub) 6.3 Organograma - ORG Este modelo tem como função representar a estrutura organizacional. Apresenta como propriedade a visualização das relações existentes entre as diversas áreas de uma organização, além das suas estruturas internas. Os objetos comuns utilizados nesse modelo e um exemplo seguem abaixo.

33 Figura 14 Objetos de modelagem do Organograma (FONTE: Chalhoub) Figura 15 Exemplo de Objetos de organograma (FONTE: Chalhoub)

34 6.4 Cadeia de Valor VAC Este modelo facilita à macro visão dos processos mapeados da organização, mostrando como eles se conectam, além de representar o fluxo de materiais e informações na empresa. De uma forma geral, esse modelo apresenta como é agregado valor durante a realização das atividades e processos na organização. No VAC, os principais objetos são: função, unidade organizacional e cluster. Os objetos de unidade organizacional e de função já foram apresentados anteriormente, mas o último ainda apresenta uma pequena diferença daquele apresentado, sendo demonstrado no exemplo abaixo. Já o cluster é entendido por um conjunto de dados e informações. Abaixo segue a ilustração dos objetos utilizados no VAC. Figura 16 Objetos de modelagem de VAC (FONTE: Chalhoub) O objetivo do VAC é representar o fluxo de processos, sendo desenhado como estes processos organizacionais estão inter-relacionados através da ligação existente entre eles. As ligações tracejadas entre os objetos representam uma lógica temporal entre eles, um predecessor do outro, enquanto a linha continua representa hierarquização, relação de superioridade. A figura abaixo é um exemplo de representação do VAC no ARIS.

35 Figura 17 Exemplo de VAC Cadeia de Suprimentos de Petróleo (FONTE: Chalhoub) Uma das vantagens do VAC é permitir a navegação logicamente estruturada entre os processos mais detalhados da organização, denominados EPC (Event Driven Process Chain). A interligação entre o VAC e o EPC, que será mais bem detalhado no próximo item, garante a consistência de interligação dos processos entre as diversas áreas organizacionais. Portanto, o VAC disponibiliza uma visão agregada dos processos que permeiam toda a estrutura organizacional, permitindo que os EPCs sejam acessados a partir de um macro processo. 6.5 Cadeia de Processos Orientada por Eventos EPC Este modelo representa a integração das diversas visões do ARIS: função, dados, organização e saídas na vista de controle. Sua principal finalidade é a modelagem detalhada dos processos da organização. São encadeadas seqüencialmente as atividades realizadas em um dado processo, bem como os eventos que as motivam, associando-se a cada atividade os recursos por elas consumidos e/ou gerados (relatórios, informações, sistemas, meios de comunicação, conhecimentos etc.), além dos indivíduos e/ou unidades organizacionais responsáveis pela sua realização, utilizando operadores lógicos para descrever a lógica de encadeamento das atividades. Abaixo seguem os objetos do EPC utilizados com maior freqüência.

36 Figura 18 Objetos de modelagem de EPC (FONTE: Chalhoub) Abaixo um exemplo de EPC.

37 Figura 19 Exemplo de EPC (FONTE: Chalhoub) Através desse modelo é possível visualizar todos os insumos que participam do processo, sejam eles clientes, fornecedores ou atores, bem como os produtos por eles gerados.

38 6.6 Diagrama de Função FAD Esse modelo é utilizado quando se deseja mapear os insumos necessários para a execução de uma atividade e os resultados por ela gerados. Uma das diretrizes para a modelagem nesse diagrama é evitar carregá-lo com muita informação, já que tornará o modelo de difícil leitura e compreensão. Opta-se, nesse caso, por desmembrar os modelos em outros menores, reduzindo a sua complexidade. Os objetos utilizados no FAD são os mesmos do EPC e, por isto, não necessita de uma descrição mais detalhada. Abaixo segue uma figura exemplificando o uso do FAD. Figura 20 Exemplo de FAD (FONTE: Chalhoub) O desmembramento de um processo em FADs não é um recurso especifico para esse diagrama, sendo utilizado também na modelagem de EPCs, por exemplo. A figura abaixo exemplifica o link entre EPCs, VACs e FADs na modelagem de processos.

39 Figura 21 VAC desdobrado em EPC e FAD (FONTE: Chalhoub) 6.7Considerações finais

40 Notação de modelagem: UML 2.0 As informações abaixo estão fortemente baseadas em UML 2 for Dummies, de Michael Jesse. 7.1 Apresentação A primeira informação que devemos saber é porque o UML existe. O UML (Unified Modeling Language) é um padrão de modelagem que permite a integração de um conjunto de diagramas, que foi desenvolvido para auxiliar os desenvolvedores de softwares e sistemas a realizar algumas tarefas, tais como especificação, documentação, simulação e teste e visualização. O UML foi originalmente desenvolvido com a intenção de promover a comunicação e produtividade para os desenvolvedores de sistemas orientados a objetos. Entretanto, o poder do UML permitiu a sua utilização em qualquer tipo de sistema e de desenvolvimento de software. Assim, esse padrão de modelagem também tem sido utilizado na modelagem de negócios. Além disso, o UML tem a propriedade de ser de fácil compreensão, permitindo ao modelador focalizar no que realmente é importante, evitando que a distração com detalhes de menor importância e que podem ser suprimidos em outro momento. Após ter construído um modelo, essa notação permite que se faça alguns testes para verificar a qualidade do mesmo, sem que seja necessário o desenvolvimento do sistema propriamente dito, ou seja, sem aumento de custos. A modelagem UML também suporta a visão de um sistema sob múltiplas vistas. Assim como se pode ter um mapa político, um mapa de relevo ou um roteiro, é possível ter um mesmo mapa que apresente diagramas com distintas finalidades e com diferentes tipos de diagramas, enfatizando

41 diferentes visões do sistema que esteja modelando, de acordo com o tipo de diagrama UML a ser utilizado. Hoje existem diversos diagramas em UML. Oficialmente existem, no mínimo, 13 diagramas e alguns outros semi-oficiais. Dado isso, algumas confusões podem surgir, já que o UML permite que o modelador troque alguns elementos entre modelos. 7.2 Visão geral de UML Uma das propriedades do UML, como já foi mencionada, é o fato de apresentar diversos diagramas, entretanto, não é necessário saber todos. A Figura 22 é um bom esquema que exemplifica os diagramas em UML. Figura 22 Esquema de diagrama em UML (FONTE: Wikipedia) A figura está baseada em setas que apontam para um diagrama mais geral, em um nível maior de abstração. Quanto mais abaixo da figura, mais especifico é o diagrama. As setas tracejadas indicam uma interdependência entre alguns diagramas no que tange a reutilização das características de outros diagramas.

42 Embora não pareça tão claro, há diferentes modos de organizar os diagramas em UML e, assim, ajudar na compreensão de qual é a melhor maneira de utilizá-los. Ainda segundo a Figura 22, ela utiliza a técnica de organização baseada em generalizações (movendo para baixo através de níveis de abstração) e especializações (movendo para baixo através de uma mesma hierarquia na direção de um detalhe mais concreto). Os diagramas em UML ainda podem ser divididos em três categorias: Diagramas de estrutura: utiliza-se esse tipo de diagrama para representar os blocos de construção de recursos de sistemas que não mudam com o tempo. Este diagrama responde a seguinte pergunta: o que está lá? Diagramas comportamentais: utiliza-se esse tipo de diagrama para mostrar como o sistema responde a alterações ou como evolui ao longo do tempo. Diagramas de interação: é utilizado para descrever as trocas de mensagens dentro de uma colaboração (um grupo de objetos colaborando entre si) para atingir uma determinada meta. Esses diagramas, na realidade, são um tipo de diagramas comportamentais. Tabela 3 Categorias e diagramas UML Categoria Tipo de diagrama Descrição Diagramas de estrutura Diagrama de classe Utilizado para mostrar as entidades do mundo real, elementos de analise e concepção, classes de implementação e seus relacionamentos.

43 Diagramas de estrutura Diagrama de objetos Utilizado para mostrar um exemplo especifico ou ilustração de objetos e suas ligações. Pode ser utilizado para indicar condições para eventos, como um teste ou operação de chamada. Diagramas de estrutura Diagrama de estrutura composta Utilizado para mostrar como alguma coisa é feita. Especialmente utilizado para estruturas complexas. Diagramas de estrutura Diagrama de implantação Utilizado para mostrar o tempo de execução de um sistema, plataforma de hardware, softwares e seus ambientes (como sistemas operacionais e máquinas virtuais) Diagramas de estrutura Diagrama de componentes Utilizado para mostrar a organização e seus relacionamentos no que tange seus sistemas Diagramas de estrutura Diagrama de pacotes Utilizado para organizar os elementos de modelos e mostrar a dependência entre eles Diagrama de comportamento Diagrama de atividades Utilizado para demonstrar o fluxo de dados e/ ou o controle de trabalho de comportamento Diagrama de Diagrama de casos de uso Utilizado para mostrar os

44 comportamento serviços que os atores podem solicitar de um sistema Diagrama de comportamento Diagrama de máquina / protocolo do diagrama de máquina Utilizado para mostrar o ciclo de vida de um determinado objeto, ou a seqüência de objetos, ou a sua interface de suporte. Diagrama de interação Diagrama overview Utilizado para demonstrar vários cenários de interações (seqüência de comportamento) para um conjunto de elementos trabalhando em conjunto para realizar uma meta (colaboração) Diagrama de interação Diagrama de seqüência Utilizado em concentrar nas trocas de mensagens entre um grupo de objetos e a ordem de mensagens Diagrama de interação Diagrama de comunicação Utilizado em concentrar nas mensagens entre grupo de objetos e as relações entre objetos Diagrama de interação Diagrama de tempo Utilizado para mostrar as mudanças em tempo real ou sistemas de trabalho. Pelo fato do UML ser bastante dinâmico, existem outras maneiras de categorizar os seus diagramas. Abaixo seguem as três categorias: Diagramas estáticos: Semelhante à dos diagramas estruturais, estes diagramas mostram a estática do sistema.

45 Diagramas dinâmicos: Esses diagramas mostram como um determinado sistema evolui ao longo do tempo. Esta categoria abrange os diagramas de máquina e os diagramas de tempo. Diagramas funcionais: Estes mostram os detalhes do comportamento e algoritmos de como um determinado sistema se comporta. Esta categoria abrange os diagramas de casos de uso, interação e atividades. 7.3 Diagrama de Classes e Diagrama de objetos O UML tem dois principais diagramas estáticos: diagrama de classes e diagramas de objetos. O diagrama de classes mostra as classes e as associações, agregações e generalizações. Já o diagrama de objetos puro mostra apenas os casos de classes e seus links com outras instancias. Obviamente, podem ser mostrados classes e objetos no mesmo esquema, mas isso raramente é feito. Esses diferentes diagramas são utilizados com fins específicos. Quando se usa uma ferramenta de modelagem UML, deve-se ter bastante atenção sobre os diferentes tipos de diagramas que ele suporta. Caso não se tenha atenção a esse detalhe e não se tenha suporte para o diagrama de objetos, então a ferramenta de modelagem provavelmente deve permitir que se coloque objetos no diagrama de classes. A maior parte do tempo se utiliza o diagrama de classes, que fornecem a mais ampla forma de mostrar aquilo que estamos modelando. Eles também são os mais úteis diagramas que se pode produzir porque o código gerado pela ferramenta UML é baseado no diagrama de classes. Os diagramas de objetos puros mostram simplesmente os casos e links de objetos e as conexões entre eles. No caso de modelos muito complexos, geralmente aparecem muitos casos e links em um único diagrama. Mas, o diagrama de classes seria muito simples. A figura abaixo exemplifica isto.

46 Figura 23 Diagrama de classes Uma instância da classe Supplier chamado ace1 faz link com duas instâncias da classe Invoice, A1 e A2. Ambas as instâncias A1 e A2 são contas que foram enviadas no passado, porque eles desempenham o papel de pastbill. Estes dois Invoices foram pagos a partir de uma instância da classe SupplierAccount chamada aceacc. Outra instância da classe Supplier, generalairf, está ligada a um conjunto diferente de invoices. A partir do diagrama visto, percebe-se que a instância b4 da classe invoice desempenha o papel do currentbill. A figura acima ilustra dois casos diferentes de Suppliers e seus Invoices. Em um caso o Supplier ace1 não tem uma currentbill. No outro caso, generalairf tem um current Bill. Os diagramas de objetos são bons para mostrar um exemplo simples do que se entende por um diagrama de classe. Por vezes, existem um ou dois diagramas de classes para um projeto de software: eles são bons para mostrar aos gerentes o que está acontecendo. Ainda pode-se construir um diagrama de objetos/classes híbrido. Alguns acham isso mais útil quando se quer mostrar as classes e também mostrar um exemplo ou dois casos de uso de algumas dessas classes.

47 Tabela 4 Tipos de Diagrama UML (FONTE: ELO Group) Tipo de Diagrama Descrição Diagrama de classes Apresenta classes, associações, agregações e generalizações Organizar as classes de geração de códigos em ferramentas UML Mostra um exemplo especifico de gestão Diagrama de objetos Considera quais instâncias se tem em execução (também utilizado no diagrama de comunicação) Descreve o comportamento antes e depois de executado Mostrar a configuração para a rodada de teste Diagrama de objetos/classes híbrido Mostra exemplos de uma classe especifica que são de difícil compreensão. 7.4 Diagrama de casos de uso Os diagramas UML aproveitam a potência da teoria de orientação por objeto e das técnicas de análise e desenho, enquanto outros centralizam no detalhamento de projeto e construção. Em ambos os casos, estes diagramas ajudam a realizar uma tarefa ou se comunicar com funcionários na organização. No entanto, o desenvolvimento prático não é apenas uma atividade interna, sobretudo no atual clima de competição e de pressão para diminuir os orçamentos. Se o objetivo é permanecer no negócio, é preciso captar e entender as exigências de seus clientes e suas necessidades, e fazer um produto ou sistema que eles querem. Casos de uso e diagramas

48 de casos de uso são as funcionalidades do UML que apóiam o recolhimento e a análise centrados nos requisitos dos usuários iniciado nos objetivos e metas de seus clientes. Casos de uso podem manter-se focados em seus usuários e objetivos práticos sobre sistemas de produção que entregam valor aos seus clientes, sejam eles clientes internos ou externos. O Caso de uso tem um fim específico em que o usuário pode realmente utilizar o sistema. O Caso de uso atinge seu grande poder principalmente por simplificar e organizar: quando se identifica e organiza o uso de casos, é possível pintar uma imagem clara do que o sistema tem de fazer. Essa imagem clara pode ser mostrada aos clientes, usuários, gestores e demais interessados, que podem ajudar a compreender os defeitos e acertos do sistema, favorecendo o processo de desenvolvimento. Identificando o público Para se obter uma imagem fiel do propósito que o sistema quer atingir, é necessário identificar para quem o sistema é (seu cliente) e quem utiliza o sistema (os usuários). Lembrando que os usuários e os clientes geralmente não são o mesmo grupo de pessoas. Mesmo quando eles são as mesmas pessoas, esta distinção é benéfica para pensar a diferença de papéis entre os usuários e os clientes Clientes: São pessoas ou organizações que, em última instância, pertencem a sua equipe. Eles devem ser satisfeitos para que se possa receber um pagamento. Seu time pode ter uma relação contratual com eles (clientes externos), ou podem ser uma parte da sua própria estrutura de gestão (clientes internos). Quando estamos desenvolvendo uma organização, considere a organização como seus pais o seu cliente.

49 Os clientes dos seus clientes: Quando se fala sobre clientes (por oposição aos seus clientes), geralmente se refere aos clientes do seu cliente. Estas são as pessoas ou organizações que compram coisas a partir do seu cliente. Se o seu sistema não torná-los felizes, o seu cliente está insatisfeito. Usuários: Ao se referir aos usuários de um sistema, eles podem ser os clientes do seu cliente, ou eles podem ser os trabalhadores da organização de seu cliente que se relaciona de alguma forma com o sistema. Muitos sistemas têm usuários de todos os tipos: os seus clientes, clientes dos seus clientes, e as pessoas que trabalham desenvolvendo o sistema. Usuários chegam a se sentir mais próximo dos sistemas e acabam obtendo impressões mais fortes. As tarefas dos usuários são especificar o que o sistema deve automatizar, as necessidades dos usuários são o que o sistema tem de realizar. Assim sendo, os atores de um sistema, considerando que os atores não são uma pessoa especifica, mas o papel que uma determinada pessoa exerce e que não devemos usar nomes individuais. Dentro do UML a notação de um ator é tradicionalmente uma figura bastão ou pode também ser utilizada uma caixa com o rótulo escrito «Actor», conforme pode ser visto na figura abaixo: Figura 24 Exemplo da representação de atores em UML

50 Recomenda-se que seja utilizada a figura com a forma humana para todos os atores humanos e a classe de caixa para atores não-humanos (outros sistemas, bases de dados e dispositivos). Esta pequena convenção visual irá ajudá-lo a distingui-las rapidamente. 7.5 Considerações finais Pode-se empregar os diagramas em UML para mostrar informações diferentes, em tempos diferentes e com finalidades diferentes. Existem diversos frameworks, como Zachman ou DODAF (Department of Defenses Architecture Framework), que auxiliam os desenvolvedores de sistemas a organizar e comunicar diferentes aspectos de seus sistemas. Um simples framework para organizar as idéias pode ser bastante útil através das respostas de simples questões sobre os sistemas que se deseja modelar: 1. Quem utiliza o sistema? Mostre os atores (aqueles que vão utilizar o sistema) nos diagramas de casos de uso (mostrando os efeitos do sistema). 2. Do que o sistema é feito? Desenhe o diagrama de classes para mostrar a estrutura lógica e o diagrama de componentes para mostrar a estrutura física do sistema. 3. Onde estão localizados os componentes do sistema? Indique os seus planos sobre para onde seu sistema vai estar e evoluir no diagrama de implantação. 4. Quando é que acontecem eventos importantes no sistema? Mostre o que provoca a reação dos objetos e o trabalho através dos diagramas de estado e interação. 5. Porque é que este sistema está fazendo as coisas que ele faz? Identifique os objetivos dos usuários do sistema e capture-os em casos reais. O UML foi desenvolvido justamente para esse fim.

51 6. Como esse sistema vai trabalha? Mostre as partes do diagrama de estrutura e utiliza o diagrama de comunicação para mostrar as interações em um nível suficiente para detalhar a concepção e implementação.

52 Referencias Instituições e Conferências Livros e Artigos Bussiness Process Change, Paul Harmon UML 2 for Dummies, Michael Jesse Afonso, Fernanda Chalhoub, Avaliação do Supply-Chain Operations Reference-Model (SCOR) como um Modelo de Referência de Processos voltado para o Gerenciamento de

BPMN (Business Process. George Valença gavs@cin.ufpe.br

BPMN (Business Process. George Valença gavs@cin.ufpe.br BPMN (Business Process Modeling Notation) George Valença gavs@cin.ufpe.br 31/10/2012 Introdução Modelagem de processos No ciclo de vida BPM, a etapa de modelagem de processos consiste em um conjunto de

Leia mais

BPMN. Business Process Modeling Notation. Leandro C. López Agosto - 2015

BPMN. Business Process Modeling Notation. Leandro C. López Agosto - 2015 BPMN Business Process Modeling Notation Leandro C. López Agosto - 2015 Objetivos Conceitos Boas práticas de modelagem Elementos do BPMN Tipos de processos Apresentar os conceitos e elementos da notação

Leia mais

1 UML (UNIFIED MODELING LANGUAGE)

1 UML (UNIFIED MODELING LANGUAGE) 1 UML (UNIFIED MODELING LANGUAGE) Segundo Tonsig (2003), para conseguir desenvolver um software capaz de satisfazer as necessidades de seus usuários, com qualidade, por intermédio de uma arquitetura sólida

Leia mais

Maratona CBOK Brasília, 23 de outubro de 2012

Maratona CBOK Brasília, 23 de outubro de 2012 Maratona CBOK Brasília, 23 de outubro de 2012 BPM CBOK Guia para o Gerenciamento de Processos de Negócios Corpo Comum de Conhecimento Modelagem de Processos de Negócios Modelagem de processos Análise de

Leia mais

Adm. Vinicius Braga admviniciusbraga@gmail.com. Prof. Msc. Wilane Carlos da Silva Massarani wilane@cercomp.ufg.br

Adm. Vinicius Braga admviniciusbraga@gmail.com. Prof. Msc. Wilane Carlos da Silva Massarani wilane@cercomp.ufg.br Adm. Vinicius Braga admviniciusbraga@gmail.com Prof. Msc. Wilane Carlos da Silva Massarani wilane@cercomp.ufg.br Objetivos Contextualização Conceitos Boas práticas de modelagem Elementos do BPMN Tipos

Leia mais

BPMN - Business Process Modeling and Notation

BPMN - Business Process Modeling and Notation BPMN - Business Process Modeling and Notation AGENDA Notação Conceito Visão Geral da Notação BPMN Notação BPMN no Escritório de Processos NOTAÇÃO - CONCEITO Segundo o dicionário: Ação de indicar, de representar

Leia mais

MODELAGEM DE PROCESSOS

MODELAGEM DE PROCESSOS MODELAGEM DE PROCESSOS a a a PRODUZIDO POR CARLOS PORTELA csp3@cin.ufpe.br AGENDA Definição Objetivos e Vantagens Linguagens de Modelagem BPMN SPEM Ferramentas Considerações Finais Referências 2 DEFINIÇÃO:

Leia mais

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade;

do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; 1 ARQUITETURA E DESIGN DE SOFTWARE O que é Arquitetura? do grego: arkhé (chefe ou mestre) + tékton (trabalhador ou construtor); tekhne arte ou habilidade; do dicionário: Arte de projetar e construir prédios,

Leia mais

Engenharia de Software I

Engenharia de Software I Engenharia de Software I Rogério Eduardo Garcia (rogerio@fct.unesp.br) Bacharelado em Ciência da Computação Aula 05 Material preparado por Fernanda Madeiral Delfim Tópicos Aula 5 Contextualização UML Astah

Leia mais

Renata Alves Campos (CoInfo) Sandra Maria Peron de Lima (DP) Março/2012

Renata Alves Campos (CoInfo) Sandra Maria Peron de Lima (DP) Março/2012 Renata Alves Campos (CoInfo) Sandra Maria Peron de Lima (DP) Março/2012 O que é um processo? Um processo é um grupo de atividades realizadas numa seqüência lógica com o objetivo de produzir um bem ou um

Leia mais

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br

ENGENHARIA DE SOFTWARE Prof. Ricardo Rodrigues Barcelar http://www.ricardobarcelar.com.br - MÓDULO 3 - MODELAGEM DE SISTEMAS ORIENTADA A OBJETOS COM UML 1. INTRODUÇÃO A partir de 1980, diversos métodos de desenvolvimento de sistemas surgiram para apoiar o paradigma orientado a objetos com uma

Leia mais

Conceitos de Processos & BPM

Conceitos de Processos & BPM http://rogerioaraujo.wordpress.com Série Rações Semanais Conceitos de Processos & BPM Parte I Rogério Araújo http://rogerioaraujo.wordpress.com Série Rações Semanais Conceitos de Processos & BPM Parte

Leia mais

Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br BPMN

Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br BPMN Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br BPMN Benefícios da modelagem Em uma organização orientada a processos, modelos de processos são o principal meio para medir o desempenho

Leia mais

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação

UNIVERSIDADE FEDERAL DO PARANÁ UFPR Bacharelado em Ciência da Computação SOFT DISCIPLINA: Engenharia de software AULA NÚMERO: 08 DATA: / / PROFESSOR: Andrey APRESENTAÇÃO O objetivo desta aula é apresentar e discutir conceitos relacionados a modelos e especificações. Nesta aula

Leia mais

Disciplina: GESTÃO DE PROCESSOS E QUALIDADE Prof. Afonso Celso M. Madeira

Disciplina: GESTÃO DE PROCESSOS E QUALIDADE Prof. Afonso Celso M. Madeira Disciplina: GESTÃO DE PROCESSOS E QUALIDADE Prof. Afonso Celso M. Madeira 3º semestre CONCEITOS CONCEITOS Atividade Ação executada que tem por finalidade dar suporte aos objetivos da organização. Correspondem

Leia mais

INTRODUÇÃO A MODELAGEM DE PROCESSOS UTILIZANDO BPMN 1 FÁBIO RODRIGUES CRUZ 2 2.1 CONCEITO DE MODELAGEM DE PROCESSOS UTILIZANDO BPMN

INTRODUÇÃO A MODELAGEM DE PROCESSOS UTILIZANDO BPMN 1 FÁBIO RODRIGUES CRUZ 2 2.1 CONCEITO DE MODELAGEM DE PROCESSOS UTILIZANDO BPMN INTRODUÇÃO A MODELAGEM DE PROCESSOS UTILIZANDO BPMN 1 FÁBIO RODRIGUES CRUZ 2 1 INTRODUÇÃO A Business Process Modeling Notation (BPMN), ou Notação de Modelagem de Processos de Negócio, é um conjunto de

Leia mais

UML - Unified Modeling Language

UML - Unified Modeling Language UML - Unified Modeling Language Casos de Uso Marcio E. F. Maia Disciplina: Engenharia de Software Professora: Rossana M. C. Andrade Curso: Ciências da Computação Universidade Federal do Ceará 24 de abril

Leia mais

Título do Slide Máximo de 2 linhas. Aprimorando o Gerenciamento de Projetos com Mapeamento de Processos

Título do Slide Máximo de 2 linhas. Aprimorando o Gerenciamento de Projetos com Mapeamento de Processos Título do Slide Aprimorando o Gerenciamento de Projetos com Mapeamento de Processos Título Palestrante do Slide Renato Borges de Souza Diretor de Comunicação PMI AM, Chefe da Divisão de Produtos e Negócios

Leia mais

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE

LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE LEVANTAMENTO DE REQUISITOS SEGUNDO O MÉTODO VOLERE RESUMO Fazer um bom levantamento e especificação de requisitos é algo primordial para quem trabalha com desenvolvimento de sistemas. Esse levantamento

Leia mais

Fase 1: Engenharia de Produto

Fase 1: Engenharia de Produto Fase 1: Engenharia de Produto Disciplina: Análise de Requisitos DURAÇÃO: 44 h O objetivo principal da disciplina é realizar uma análise das necessidades e produzir um escopo do produto. Representará os

Leia mais

Introdução ao BPM e CBOK. Decanato de Planejamento e Orçamento DPO Diretoria de Processos Organizacionais - DPR

Introdução ao BPM e CBOK. Decanato de Planejamento e Orçamento DPO Diretoria de Processos Organizacionais - DPR Introdução ao BPM e CBOK Decanato de Planejamento e Orçamento DPO Diretoria de Processos Organizacionais - DPR BPM CBOK O Guia para o Gerenciamento de Processos de Negócio - Corpo Comum de Conhecimento

Leia mais

Tutorial de BPMN. Visão Geral. Escopo. Elementos

Tutorial de BPMN. Visão Geral. Escopo. Elementos Tutorial de BPMN Visão Geral É um padrão para modelagem de processos de negócio que fornece uma notação gráfica para especificação de processos de negócio em um DPN (Diagrama de Processo de Negócios).

Leia mais

BEM-VINDO!!! Apresentação Inicial. Por favor, descreva o seu atual conhecimento sobre Mapeamento de Processos

BEM-VINDO!!! Apresentação Inicial. Por favor, descreva o seu atual conhecimento sobre Mapeamento de Processos Apresentação Inicial BEM-VINDO!!! Por favor, descreva o seu atual conhecimento sobre Mapeamento de Processos 1 Mapeamento de Processos Mapeamento de Processos e Negócios com BPM 2 Ementa Introdução Definição

Leia mais

Unidade: Pró-Reitoria de Desenvolvimento Institucional - PRDI Nº: MANUAL DE PROCEDIMENTOS. TÍTULO: Modelar Processos 1/17

Unidade: Pró-Reitoria de Desenvolvimento Institucional - PRDI Nº: MANUAL DE PROCEDIMENTOS. TÍTULO: Modelar Processos 1/17 1/17 ESTA FOLHA ÍNDICE INDICA EM QUE REVISÃO ESTÁ CADA FOLHA NA EMISSÃO CITADA R. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 R. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 FL. FL. 01 X 26 02 X 27 03 X 28 04 X 29 05 X 30 06 X

Leia mais

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO

UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO UNIVERSIDADE FEDERAL DE SANTA MARIA CENTRO DE TECNOLOGIA AULA 10 PROFª BRUNO CALEGARO Santa Maria, 10 de Outubro de 2013. Revisão aula anterior Documento de Requisitos Estrutura Padrões Template Descoberta

Leia mais

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 01

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 01 PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 01 LEVANTAMENTO, MODELAGEM

Leia mais

Unified Modeling Language UML - Notações

Unified Modeling Language UML - Notações Unified Modeling Language UML - Notações Prof. Ms. Elvio Gilberto da Silva elvio@fmr.edu.br UML Ponto de Vista É gerada com propósito geral de uma linguagem de modelagem visual usada para especificar,

Leia mais

Modelagem de Processos e a Metodologia IDEF0

Modelagem de Processos e a Metodologia IDEF0 Modelagem de Processos e a Metodologia IDEF0 Prof. Ricardo J. Rabelo UFSC Universidade Federal de Santa Catarina DAS Departamento de Automação e Sistemas Sumário Introdução a Processos Modelagem de Processos

Leia mais

Ciclo BPM: da Estratégia à Medição

Ciclo BPM: da Estratégia à Medição Treinamentos em Gestão por Processos Ciclo BPM: da Estratégia à Medição Da modelagem e análise ao monitoramento da execução de processos automatizados: tudo o que você precisa saber para fazer a Gestão

Leia mais

DISSEMINAÇÃO DE CONHECIMENTO FERRAMENTA BIZAGI

DISSEMINAÇÃO DE CONHECIMENTO FERRAMENTA BIZAGI DISSEMINAÇÃO DE CONHECIMENTO FERRAMENTA BIZAGI Harley Caixeta Seixas Márcia Lúcia Borges de Melo Gomes Roberta A. de Mello Bezerra Silvana Dias Soares FERRAMENTA BIZAGI BPMN Business Process Modeling Notation

Leia mais

Wilson Moraes Góes. Novatec

Wilson Moraes Góes. Novatec Wilson Moraes Góes Novatec Copyright 2014 Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta obra, mesmo parcial, por qualquer processo,

Leia mais

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza

Modelagem OO com UML. Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Modelagem OO com UML Vítor E. Silva Souza (vitorsouza@inf.ufes.br) http://www.inf.ufes.br/ ~ vitorsouza Departamento de Informática Centro Tecnológico Universidade Federal do Espírito Santo Modelos Maneira

Leia mais

PROPOSTA PARA AUTOMAÇÃO DO PROCESSO DE ELABORAÇÃO DE HORÁRIOS DO CENTRO UNIVERSITÁRIO UNIVATES

PROPOSTA PARA AUTOMAÇÃO DO PROCESSO DE ELABORAÇÃO DE HORÁRIOS DO CENTRO UNIVERSITÁRIO UNIVATES XIV COLÓQUIO INTERNACIONAL DE GESTÃO UNIVERSITÁRIA CIGU A Gestão do Conhecimento e os Novos Modelos de Universidade Florianópolis Santa Catarina Brasil 3, 4 e 5 de dezembro de 2014. ISBN: 978-85-68618-00-4

Leia mais

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil

PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL. Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil PROJETO DE COOPERAÇÃO TÉCNICA INTERNACIONAL Diretrizes e Estratégias para Ciência, Tecnologia e Inovação no Brasil Projeto 914 BRA5065 - PRODOC-MTC/UNESCO DOCUMENTO TÉCNICO Nº 01 ASPECTOS DE MUDANÇA CULTURAL

Leia mais

PADRÃO DE MODELAGEM DE PROCESSOS

PADRÃO DE MODELAGEM DE PROCESSOS PADRÃO DE MODELAGEM DE PROCESSOS - 1 - Sumário 1. INTRODUÇÃO 6 2. BASE CONCEITUAL 7 3. DIAGRAMAS PARA GESTÃO DE PROCESSOS NO INSTITUTO DO PATRIMÔNIO HISTÓRICO E ARTÍSTICO NACIONAL 9 3.1. Cadeia de Valor

Leia mais

Algumas propriedades dos objetos:

Algumas propriedades dos objetos: Orientação a Objetos Vivemos num mundo de objetos. Esses objetos existem na natureza, nas entidades feitas pelo homem, nos negócios e nos produtos que usamos. Eles podem ser categorizados, descritos, organizados,

Leia mais

Treinamento BPM e BPMN Apresentação Executiva

Treinamento BPM e BPMN Apresentação Executiva Apresentação Executiva 1 O treinamento de BPM e BPMN tem como premissa capacitar o aluno a captar as atividades relativas a determinado processo da empresa, organizá-las, gerando um fluxograma de atividades/processos,

Leia mais

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem?

A linguagem UML. UML e Diagramas de Casos de Uso e Classes. Por que usar UML? O que é modelagem? UML e Diagramas de Casos de Uso e Classes Prof. Ms. Luiz Alberto Contato: lasf.bel@gmail.com A linguagem UML UML (Unified Modeling Language) Linguagem de Modelagem Unificada É uma linguagem de modelagem

Leia mais

Projetos (PMO) : Oportunidades de Sinergia

Projetos (PMO) : Oportunidades de Sinergia Escritórios de Processos (BPM Office) e de Projetos (PMO) : Oportunidades de Sinergia Introdução...2 Uniformizando o entendimento dos conceitos... 4 Entendendo as principais similaridades... 5 Entendendo

Leia mais

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS

PDS - DATASUS. Processo de Desenvolvimento de Software do DATASUS PDS - DATASUS Processo de Desenvolvimento de Software do DATASUS Coordenação Geral de Arquitetura e Engenharia Tecnológica Coordenação de Padronização e Qualidade de Software Gerência de Padrões e Software

Leia mais

BPM Definições e Contexto Prática Aula 1

BPM Definições e Contexto Prática Aula 1 BPM Definições e Contexto Prática Aula 1 BP Business Process Algumas definições sobre o que é Processos de Negócio (BP) Um processo é um fluxo coordenado e padronizado de atividades executadas por pessoas

Leia mais

MAPEAMENTO DE PROCESSOS: TEORIA E CASO ILUSTRATIVO

MAPEAMENTO DE PROCESSOS: TEORIA E CASO ILUSTRATIVO MAPEAMENTO DE PROCESSOS: TEORIA E CASO ILUSTRATIVO Aluna: Ana Luisa Alves Teixeira Orientador: Luiz Felipe R. R. Scavarda do Carmo Departamento de Engenharia Industrial Palavras Chaves: Processos, SIPOC,

Leia mais

COMO MODELAR PROCESSOS DE NEGÓCIOS UTILIZANDO DIAGRAMA DE ATIVIDADES DA UNIFIED MODELING LANGUAGE (UML)

COMO MODELAR PROCESSOS DE NEGÓCIOS UTILIZANDO DIAGRAMA DE ATIVIDADES DA UNIFIED MODELING LANGUAGE (UML) COMO MODELAR PROCESSOS DE NEGÓCIOS UTILIZANDO DIAGRAMA DE ATIVIDADES DA UNIFIED MODELING LANGUAGE (UML) Ursulino Pereira Dias 1, Celso Luis. Z. Faria 2 RESUMO: Todo trabalho realizado nas empresas faz

Leia mais

Gestão de Processos de Negócios

Gestão de Processos de Negócios Gestão Operacional da TI Gestão de Processos de Negócios Business Process Management (BPM) Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Professor NOME: RÔMULO CÉSAR DIAS DE ANDRADE

Leia mais

Gerenciamento de Processos de Negócio

Gerenciamento de Processos de Negócio Gestão por Processos By Alan Lopes +55 22-99202-0433 alopes.campos@mail.com http://prof-alan-lopes.weebly.com Gerenciamento de Processos de Negócio - Conceitos e fundamentos - Modelagem de processo - Análise

Leia mais

! Introdução. " Motivação para Processos de Software. ! Processo Unificado (USDP) " Definições " RUP x USDP " Características do Processo Unificado

! Introdução.  Motivação para Processos de Software. ! Processo Unificado (USDP)  Definições  RUP x USDP  Características do Processo Unificado Agenda! Introdução " Motivação para Processos de Software! (USDP) " Definições " RUP x USDP " Características do! Descrição detalhada do! Processos Derivados! Templates simplificados! Conclusões 2 Processo

Leia mais

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2

UML 2. Guia Prático. Gilleanes T.A. Guedes. Novatec. Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 UML 2 Guia Prático Gilleanes T.A. Guedes Obra revisada e ampliada a partir do título Guia de Consulta Rápida UML 2 Novatec capítulo 1 Introdução à UML A UML (Unified Modeling Language ou Linguagem de Modelagem

Leia mais

2. Modelagem de Processo de Negócio

2. Modelagem de Processo de Negócio 18 2. Modelagem de Processo de Negócio Este capítulo apresenta um estudo sobre modelagem de processo de negócio. Este estudo exibirá a definição de modelagem de processo de negócio e seus propósitos, bem

Leia mais

Introdução ao OpenUP (Open Unified Process)

Introdução ao OpenUP (Open Unified Process) Introdução ao OpenUP (Open Unified Process) Diferentes projetos têm diferentes necessidades de processos. Fatores típicos ditam as necessidades de um processo mais formal ou ágil, como o tamanho da equipe

Leia mais

A Linguagem de Modelagem Unificada (UML)

A Linguagem de Modelagem Unificada (UML) Aécio Costa A Linguagem de Modelagem Unificada (UML) Percebeu-se a necessidade de um padrão para a modelagem de sistemas, que fosse aceito e utilizado amplamente. Surge a UML (Unified Modeling Language)

Leia mais

3 OOHDM e SHDM 3.1. OOHDM

3 OOHDM e SHDM 3.1. OOHDM 32 3 OOHDM e SHDM Com a disseminação em massa, desde a década de 80, de ambientes hipertexto e hipermídia, principalmente a Web, foi identificada a necessidade de elaborar métodos que estruturassem de

Leia mais

Programa do Módulo 2. Processo Unificado: Visão Geral

Programa do Módulo 2. Processo Unificado: Visão Geral 9.1 Programa do Módulo 2 Orientação a Objetos Conceitos Básicos Análise Orientada a Objetos (UML) O Processo Unificado (RUP) Processo Unificado: Visão Geral 9.2 Encaixa-se na definição geral de processo:

Leia mais

Material para nivelamento de informações sobre Mapeamento de Processos

Material para nivelamento de informações sobre Mapeamento de Processos Material para nivelamento de informações sobre Mapeamento de Processos 1 Objetivo Nivelar informações e conceitos sobre mapeamento de processos na UFABC. O que é um processo?? É um conjunto de atividades

Leia mais

Guia de utilização da notação BPMN

Guia de utilização da notação BPMN 1 Guia de utilização da notação BPMN Agosto 2011 2 Sumário de Informações do Documento Documento: Guia_de_utilização_da_notação_BPMN.odt Número de páginas: 31 Versão Data Mudanças Autor 1.0 15/09/11 Criação

Leia mais

Automação do Processo de Instalação de Softwares

Automação do Processo de Instalação de Softwares Automação do Processo de Instalação de Softwares Aislan Nogueira Diogo Avelino João Rafael Azevedo Milene Moreira Companhia Siderúrgica Nacional - CSN RESUMO Este artigo tem como finalidade apresentar

Leia mais

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI

UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI UTILIZANDO ICONIX NO DESENVOLVIMENTO DE APLICAÇÕES DELPHI Dr. George SILVA; Dr. Gilbert SILVA; Gabriel GUIMARÃES; Rodrigo MEDEIROS; Tiago ROSSINI; Centro Federal de Educação Tecnológica do Rio Grande do

Leia mais

Administração de Sistemas de Informação Gerenciais

Administração de Sistemas de Informação Gerenciais Administração de Sistemas de Informação Gerenciais UNIDADE VI: Como desenvolver Sistemas de Informação e Gerenciar Projetos. Novos sistemas de informação são construídos como soluções para os problemas

Leia mais

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

BPMN Business Process Modeling Notation

BPMN Business Process Modeling Notation BPMN Business Process Modeling Notation Business Process Modeling Notation Página 1 Objetivo O objetivo deste curso é apresentar os elementos da notação de modelagem de processos de negócio BPMN 1.1 (Business

Leia mais

Introduçãoa Engenhariade. Prof. Anderson Cavalcanti UFRN-CT-DCA

Introduçãoa Engenhariade. Prof. Anderson Cavalcanti UFRN-CT-DCA Introduçãoa Engenhariade Software Prof. Anderson Cavalcanti UFRN-CT-DCA O que é Software? O que é software? São programas de computadores, em suas diversas formas, e a documentação associada. Um programa

Leia mais

Documentação de um Produto de Software

Documentação de um Produto de Software Documentação de um Produto de Software Versão 3.0 Autora: Profª Ana Paula Gonçalves Serra Revisor: Prof. Fernando Giorno 2005 ÍNDICE DETALHADO PREFÁCIO... 4 1. INTRODUÇÃO AO DOCUMENTO... 6 1.1. TEMA...

Leia mais

2 Processos de Negócios e Indicadores de Desempenho

2 Processos de Negócios e Indicadores de Desempenho 2 Processos de Negócios e Indicadores de Desempenho Esse capítulo apresenta os principais conceitos afetos a processos de negócio e indicadores de desempenho considerados relevantes para o entendimento

Leia mais

Características do Software

Características do Software Questionamentos Por que tanta demora para entregar? Por que os prazos se atrasam? Por que os custos são altos? Por que não achar todos os erros antes de entregar? Por que dificuldade em medir o progresso

Leia mais

Concepção e Elaboração

Concepção e Elaboração UNIVERSIDADE ESTADUAL PAULISTA INSTITUTO DE BIOCIÊNCIAS, LETRAS E CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIAS DE COMPUTAÇÃO E ESTATÍSTICA Análise e Projeto Orientado a Objetos Concepção e Elaboração Estudo

Leia mais

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial

Histórico da Revisão. Versão Descrição Autor. 1.0 Versão Inicial 1 of 14 27/01/2014 17:33 Sistema de Paginação de Esportes Universitários Documento de Arquitetura de Software Versão 1.0 Histórico da Revisão Data 30 de novembro de 1999 Versão Descrição Autor 1.0 Versão

Leia mais

Engenharia de Software

Engenharia de Software CENTRO UNIVERSITÁRIO NOVE DE JULHO Profº. Edson T. França edson.franca@uninove.br Software Sistemas Conjunto de elementos, entre os quais haja alguma relação Disposição das partes ou dos elementos de um

Leia mais

Unidade II MODELAGEM DE PROCESSOS

Unidade II MODELAGEM DE PROCESSOS Unidade II 3 MODELAGEM DE SISTEMAS 1 20 A fase de desenvolvimento de um novo sistema de informação (Quadro 2) é um momento complexo que exige um significativo esforço no sentido de agregar recursos que

Leia mais

3 Arquitetura de Integração

3 Arquitetura de Integração 65 3 Arquitetura de Integração O objetivo da integração é permitir a modelagem de objetivos e a modelagem de processos em um mesmo diagrama de forma a explicitar o porque e o como ao mesmo tempo, evidenciando

Leia mais

Eduardo Bezerra. Editora Campus/Elsevier

Eduardo Bezerra. Editora Campus/Elsevier Princípios de Análise e Projeto de Sistemas com UML 2ª edição Eduardo Bezerra Editora Campus/Elsevier Capítulo 11 Arquitetura do sistema Nada que é visto, é visto de uma vez e por completo. --EUCLIDES

Leia mais

1. Introdução 2. Desenvolvimento de Softwares orientado a objetos 3. UML A unificação dos métodos para a criação de um novo padrão 4. Uso da UML 5.

1. Introdução 2. Desenvolvimento de Softwares orientado a objetos 3. UML A unificação dos métodos para a criação de um novo padrão 4. Uso da UML 5. 1. Introdução 2. Desenvolvimento de Softwares orientado a objetos 3. UML A unificação dos métodos para a criação de um novo padrão 4. Uso da UML 5. Fases do Desenvolvimento de um Sistema em UML 1. Análise

Leia mais

MC302A Modelagem de Sistemas com UML. Prof. Fernando Vanini vanini@ic.unicamp.br

MC302A Modelagem de Sistemas com UML. Prof. Fernando Vanini vanini@ic.unicamp.br MC302A Modelagem de Sistemas com UML Prof. Fernando Vanini vanini@ic.unicamp.br Modelamento de Sistemas e Orientação a Objetos O paradigma de Orientação a Objetos oferece um conjunto de características

Leia mais

Planejamento da disciplina: Modelagem de processos de negócio

Planejamento da disciplina: Modelagem de processos de negócio UNIVERSIDADE FEDERAL DE MINAS GERAIS / INSTITUTO DE CIÊNCIAS EXATAS DEPARTAMENTO DE CIÊNCIA DA COMPUTAÇÃO Planejamento da disciplina: Modelagem de processos de negócio Professor: Clarindo Isaías Pereira

Leia mais

Os casos de uso dão conta da maioria dos requisitos de um sistema computacional.

Os casos de uso dão conta da maioria dos requisitos de um sistema computacional. Unidade 3: Modelagem de requisitos e de soluções (Parte a) 1 Casos de uso 1.1 Conceitos básicos e parâmetros de descrição Os casos de uso dão conta da maioria dos requisitos de um sistema computacional.

Leia mais

guia prático 2a Edição Gilleanes T.A. Guedes Novatec

guia prático 2a Edição Gilleanes T.A. Guedes Novatec guia prático 2a Edição Gilleanes T.A. Guedes Novatec Copyright 2007, 2014 da Novatec Editora Ltda. Todos os direitos reservados e protegidos pela Lei 9.610 de 19/02/1998. É proibida a reprodução desta

Leia mais

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I BPMN I Ricardo de Sousa Britto rbritto@ufpi.edu.br 1 + Processo de Negócio 2 n Coleção de atividades relacionadas e estruturadas que produzem um serviço ou produto específico.

Leia mais

O que é a UML? Introdução a UML. Objetivos da Modelagem. Modelos. A UML não é. Princípios da Modelagem. O que é um modelo?

O que é a UML? Introdução a UML. Objetivos da Modelagem. Modelos. A UML não é. Princípios da Modelagem. O que é um modelo? O que é a UML? Introdução a UML Linguagem Gráfica de Modelagem para: Visualizar Especificar Construir Documentar Comunicar Artefatos de sistemas complexos Linguagem: vocabulário + regras de combinação

Leia mais

Módulo 6. Todos os direitos de cópia reservados. Não é permitida a distribuição física ou eletrônica deste material sem a permissão expressa do autor.

Módulo 6. Todos os direitos de cópia reservados. Não é permitida a distribuição física ou eletrônica deste material sem a permissão expressa do autor. Módulo 6 Módulo 6 Desenvolvimento do projeto com foco no negócio BPM, Análise e desenvolvimento, Benefícios, Detalhamento da metodologia de modelagem do fluxo de trabalho EPMA. Todos os direitos de cópia

Leia mais

Qualidade de Processo de Software Normas ISO 12207 e 15504

Qualidade de Processo de Software Normas ISO 12207 e 15504 Especialização em Gerência de Projetos de Software Qualidade de Processo de Software Normas ISO 12207 e 15504 Prof. Dr. Sandro Ronaldo Bezerra Oliveira srbo@ufpa.br Qualidade de Software 2009 Instituto

Leia mais

ERP: Pacote Pronto versus Solução in house

ERP: Pacote Pronto versus Solução in house ERP: Pacote Pronto versus Solução in house Introdução Com a disseminação da utilidade e dos ganhos em se informatizar e integrar os diversos departamentos de uma empresa com o uso de um ERP, algumas empresas

Leia mais

Definição de Processos

Definição de Processos Definição de Processos Introdução Prof Ms Vinícius Costa de Souza www.inf.unisinos.br/~vinicius viniciuscs@unisinos.br Agenda Processos Definição Componentes Documentação Características Aplicações Nomenclaturas

Leia mais

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1

Engenharia de Software Introdução. Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Engenharia de Software Introdução Ricardo Argenton Ramos UNIVASF Engenharia de Software I - Aula 1 Tópicos Apresentação da Disciplina A importância do Software Software Aplicações de Software Paradigmas

Leia mais

RESUMO DA SOLUÇÃO CA ERwin Modeling. Como eu posso gerenciar a complexidade dos dados e aumentar a agilidade dos negócios?

RESUMO DA SOLUÇÃO CA ERwin Modeling. Como eu posso gerenciar a complexidade dos dados e aumentar a agilidade dos negócios? RESUMO DA SOLUÇÃO CA ERwin Modeling Como eu posso gerenciar a complexidade dos dados e aumentar a agilidade dos negócios? O CA ERwin Modeling fornece uma visão centralizada das principais definições de

Leia mais

Engenharia de Software

Engenharia de Software Engenharia de Software Requisitos de Software Prof. MSc. Edilberto Silva prof.edilberto.silva@gmail.com http://www.edilms.eti.br Requisito O que é um REQUISITO? Em software: É a CARACTERIZAÇÃO do que o

Leia mais

ADMINISTRAÇÃO GERAL GESTÃO DE PROCESSOS

ADMINISTRAÇÃO GERAL GESTÃO DE PROCESSOS ADMINISTRAÇÃO GERAL GESTÃO DE PROCESSOS Atualizado em 21/12/2015 GESTÃO DE PROCESSOS Um processo é um conjunto ou sequência de atividades interligadas, com começo, meio e fim. Por meio de processos, a

Leia mais

MACROPROCESSOS É um conjunto de processos que correspondem a uma função da organização.

MACROPROCESSOS É um conjunto de processos que correspondem a uma função da organização. GESTÃO POR PROCESSOS Prof. WAGNER RABELLO JR PROCESSO Conjunto de recursos e atividades interrelacionadas que transforma insumos (entradas) em serviços ou produtos (saídas); GESTÃO DE PROCESSO OU GESTÃO

Leia mais

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas.

Palavras-Chaves: estoque, modelagem, requisitos, UML, vendas. UTILIZAÇÃO DA UML NO DESENVOLVIMENTO DE SISTEMA DE CONTROLE DE VENDAS E ESTOQUE GILBERTO FRANCISCO PACHECO DOS SANTOS Discente da AEMS Faculdades Integradas de Três Lagoas JACKSON LUIZ ARROSTI Discente

Leia mais

Nos artigos anteriores apresentamos. Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio

Nos artigos anteriores apresentamos. Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio Desenvolvimento de Software Dirigido por Caso de Uso Parte III: Caso de Uso de Negócio Vinicius Lourenço de Sousa vinicius.lourenco.sousa@gmail.com Atua no ramo de desenvolvimento de software há mais de

Leia mais

Modelagem do Processo de Negócio

Modelagem do Processo de Negócio Análise e Projeto 1 Modelagem do Processo de Negócio Modelos de processos de negócios descrevem as diferentes atividades que, quando combinados, oferecem suporte a um processo de negócio. Processos de

Leia mais

UFG - Instituto de Informática

UFG - Instituto de Informática UFG - Instituto de Informática Curso: Sistemas de Informação Arquitetura de Software Prof.: Fabrízzio A A M N Soares professor.fabrizzio@gmail.com Aula 3 Introdução à Arquitetura de Software (continuação)

Leia mais

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER

Unisant Anna Gestão Empresarial com ERP 2014 Modelagem de Sistemas - UML e MER Objetivo dessa aula é descrever as características e a simbologia dos diagramas UML e MER na modelagem de sistemas de informação de uma forma a permitir a comunicação entre técnicos e gestores. Modelagem

Leia mais

BPMN: Identificando vantagens e desvantagens do uso desta ferramenta para modelagem de processos.

BPMN: Identificando vantagens e desvantagens do uso desta ferramenta para modelagem de processos. BPMN: Identificando vantagens e desvantagens do uso desta ferramenta para modelagem de processos. Franciele da Costa Canello 1 RESUMO As organizações estão cada vez mais necessitando de sistemas que aliem

Leia mais

Secretaria de Estado de Gestão e Planejamento Superintendência de Modernização Institucional Gerência de Escritório de Processos

Secretaria de Estado de Gestão e Planejamento Superintendência de Modernização Institucional Gerência de Escritório de Processos SUMÁRIO PADRONIZAÇÃO DO DESENHO DE PROCESSOS NO BIZAGI... 2 1. CONFIGURANDO A FERRAMENTA... 2 2. GLOSSÁRIO... 2 3. OBJETIVO... 3 4. NOTAÇÃO... 3 5. REGRAS DE DESENHO... 3 5.1. Macroprocesso... 3 5.2. Sub-processo......

Leia mais

INFRAESTRUTURA PARA INOVAÇÃO BPM e SOA

INFRAESTRUTURA PARA INOVAÇÃO BPM e SOA INFRAESTRUTURA PARA INOVAÇÃO BPM e SOA Palestrante: Eduardo José Ribeiro de Castro, MSc. eduardo@quaddract.com.br 25/08/2009 1 Objetivo Geral APL Brasília Capital Digital Desenvolver entre as empresas

Leia mais

Gestão por Processos

Gestão por Processos Gestão por Processos Ponta Grossa SC Setembro de 2011 Simone de Andrade Klober. Graduado em Psicologia - ACE/SC, Mestre em Gestão Estratégica ESAG/UDESC, Especialista em dinâmica dos Grupos SBDG, Formação

Leia mais

Instituto de Computação, Universidade Federal do Amazonas (UFAM) Manaus-AM, Brasil

Instituto de Computação, Universidade Federal do Amazonas (UFAM) Manaus-AM, Brasil Elicitação de Requisitos a partir de Modelos de Processos de Negócio e Modelos Organizacionais: Uma pesquisa para definição de técnicas baseadas em heurísticas Marcos A. B. de Oliveira 1, Sérgio R. C.

Leia mais

Dominando o Mapeamento de Processos com BPMN 2.0

Dominando o Mapeamento de Processos com BPMN 2.0 Treinamentos em Gestão por Processos Dominando o Mapeamento de Processos com BPMN 2.0 Representando processos de negócio com a notação mais poderosa do Mercado. BPMN (Business Process Model and Notation)

Leia mais

Levantamento de Requisitos.

Levantamento de Requisitos. FACULDADES INTEGRADAS MATO-GROSSENSES DE CIÊNCIAS SOCIAIS E HUMANAS RESUMO Levantamento de Requisitos. Leandro Cícero da Silva Mello. Prof. Jeanine Ferrazza Meyer Metodologia e Técnica de Pesquisa- Levantamento

Leia mais

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1.

Modelos de Sistema. 2007 by Pearson Education. Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1. Modelos de Sistema Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 8 Slide 1 Objetivos Explicar por que o contexto de um sistema deve ser modelado como parte do processo de RE Descrever

Leia mais

Guia de Modelagem de Casos de Uso

Guia de Modelagem de Casos de Uso Guia de Modelagem de Casos de Uso Sistema de e-commerce de Ações Versão 1.1 1 Histórico da Revisão. Data Versão Descrição Autor 13 de Setembro de 2008 1.0 Criação do documento Antonio Marques 28 de Setembro

Leia mais

A história de UML e seus diagramas

A história de UML e seus diagramas A história de UML e seus diagramas Thânia Clair de Souza Vargas Departamento de Informática e Estatística Universidade Federal de Santa Catarina (UFSC) Florianópolis, SC Brazil thania@inf.ufsc.br Abstract.

Leia mais