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

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

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

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

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

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

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

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

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

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 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

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

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

Processo de Software

Processo de Software Processo de Software Uma importante contribuição da área de pesquisa de processo de software tem sido a conscientização de que o desenvolvimento de software é um processo complexo. Pesquisadores e profissionais

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Engenharia de Software

Engenharia de Software Engenharia de Software Introdução à Melhoria de Processos de Software baseado no MPS.BR Prof. Maxwell Anderson www.maxwellanderson.com.br Agenda Introdução MPS.BR MR-MPS Detalhando o MPS.BR nível G Introdução

Leia mais

fagury.com.br. PMBoK 2004

fagury.com.br. PMBoK 2004 Este material é distribuído por Thiago Fagury através de uma licença Creative Commons 2.5. É permitido o uso e atribuição para fim nãocomercial. É vedada a criação de obras derivadas sem comunicação prévia

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

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

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI)

ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) ALESSANDRO PEREIRA DOS REIS PAULO CESAR CASTRO DE ALMEIDA ENGENHARIA DE SOFTWARE - CAPABILITY MATURITY MODEL INTEGRATION (CMMI) APARECIDA DE GOIÂNIA 2014 LISTA DE TABELAS Tabela 1 Áreas de processo por

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

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

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

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

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

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

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

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

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

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

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

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE

Prof. Dr. Ivanir Costa. Unidade III QUALIDADE DE SOFTWARE Prof. Dr. Ivanir Costa Unidade III QUALIDADE DE SOFTWARE Normas de qualidade de software - introdução Encontra-se no site da ABNT (Associação Brasileira de Normas Técnicas) as seguintes definições: Normalização

Leia mais

GESTÃO E OTIMIZAÇÃO DE PROCESSOS. Vanice Ferreira

GESTÃO E OTIMIZAÇÃO DE PROCESSOS. Vanice Ferreira GESTÃO E OTIMIZAÇÃO DE PROCESSOS Vanice Ferreira 12 de junho de 2012 GESTÃO E OTIMIZAÇÃO DE PROCESSOS: conceitos iniciais DE QUE PROCESSOS ESTAMOS FALANDO? GESTÃO E OTIMIZAÇÃO DE PROCESSOS: conceitos iniciais

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

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

Processo de Desenvolvimento Unificado

Processo de Desenvolvimento Unificado Processo de Desenvolvimento Unificado Processo de Desenvolvimento de Software? Conjunto de atividades bem definidas; com responsáveis; com artefatos de entrada e saída; com dependências entre as mesmas

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

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

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA

ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA ALESSANDRO RODRIGO FRANCO FERNANDO MARTINS RAFAEL ALMEIDA DE OLIVEIRA INTRODUÇÃO O projeto de um banco de dados é realizado sob um processo sistemático denominado metodologia de projeto. O processo do

Leia mais

GERENCIAMENTO DE PROCESSOS DE NEGÓCIO. Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br

GERENCIAMENTO DE PROCESSOS DE NEGÓCIO. Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br GERENCIAMENTO DE PROCESSOS DE NEGÓCIO Professor: Rômulo César romulodandrade@gmail.com www.romulocesar.com.br Guia de Estudo Vamos utilizar para a nossa disciplina de Modelagem de Processos com BPM o guia

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

Análise e Projeto Orientados por Objetos

Análise e Projeto Orientados por Objetos Análise e Projeto Orientados por Objetos Aula 02 Análise e Projeto OO Edirlei Soares de Lima Análise A análise modela o problema e consiste das atividades necessárias para entender

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

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante

Engenharia de Software Questionário sobre Engenharia de Requisitos Resolvido Prof. MSc Wagner Siqueira Cavalcante 1 - Q193183 ( Prova: FCC - 2011 - TRT - 19ª Região (AL) - Analista Judiciário - Tecnologia da Informação / Engenharia de Software / Análise de Requisitos; Engenharia de Requisitos; ) De acordo com Sommerville,

Leia mais

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619

Tópicos em Engenharia de Software (Optativa III) AULA 2. Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Tópicos em Engenharia de Software (Optativa III) AULA 2 Prof. Andrêza Leite andreza.lba@gmail.com (81 )9801-6619 Engenharia de Software Objetivo da aula Depois desta aula você terá uma revisão sobre o

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

Requisitos de Software

Requisitos de Software Requisitos de Software Ian Sommerville 2006 Engenharia de Software, 8ª. edição. Capítulo 6 Slide 1 Objetivos Apresentar os conceitos de requisitos de usuário e de sistema Descrever requisitos funcionais

Leia mais

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009)

CMMI. B) descrições das atividades consideradas importantes para o atendimento de suas respectivas metas específicas. Governo do ES (CESPE 2009) CMMI Governo do ES (CESPE 2009) Na versão 1.2 do CMMI, 111 os níveis de capacidade são definidos na abordagem de estágios. 112 os níveis de maturidade são definidos na abordagem contínua. 113 existem seis

Leia mais

Módulo 4. Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios

Módulo 4. Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios Módulo 4 Visão geral dos controles do COBIT aplicáveis para implantação da Sarbanes, o papel de TI, a importância dos softwares e exercícios Estruturas e Metodologias de controle adotadas na Sarbanes COBIT

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

TRIBUNAL DE JUSTIÇA DO ESTADO DE MATO GROSSO

TRIBUNAL DE JUSTIÇA DO ESTADO DE MATO GROSSO DO ESTADO DE MATO GROSSO INSTRUÇÃO NORMATIVA STI Nº 01/2011 Versão: 01 Publicação: DJE nº de / /2011 Unidade Responsável: Coordenadoria de Tecnologia da Informação - CTI I FINALIDADE Instituir a Metodologia

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

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

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

Diferença entre a visão departamental e visão por processos.

Diferença entre a visão departamental e visão por processos. GESTÃO POR PROCESSOS Diferença entre a visão departamental e visão por processos. A visão por processos é conhecida desde a época medieval com a atuação dos artesãos responsáveis por todas as etapas do

Leia mais

Sistemas de Informação I

Sistemas de Informação I + Sistemas de Informação I Dimensões de análise dos SI Ricardo de Sousa Britto rbritto@ufpi.edu.br + Introdução n Os sistemas de informação são combinações das formas de trabalho, informações, pessoas

Leia mais

Modelagem de Processos. Prof.: Fernando Ascani

Modelagem de Processos. Prof.: Fernando Ascani Modelagem de Processos Prof.: Fernando Ascani Bibliografia UML Guia de consulta rápida Douglas Marcos da Silva Editora: Novatec UML Guia do usuário Grady Booch James Rumbaugh Ivair Jacobson Editora: Campus

Leia mais

PROCESSOS PODEROSOS DE NEGÓCIO. ideiaconsultoria.com.br 43 3322 2110 comercial@ideiaconsultoria.com.br

PROCESSOS PODEROSOS DE NEGÓCIO. ideiaconsultoria.com.br 43 3322 2110 comercial@ideiaconsultoria.com.br PROCESSOS PODEROSOS DE NEGÓCIO ideiaconsultoria.com.br 43 3322 2110 comercial@ideiaconsultoria.com.br POR QUE ESCREVEMOS ESTE E-BOOK? Nosso objetivo com este e-book é mostrar como a Gestão de Processos

Leia mais

Material de Apoio. Sistema de Informação Gerencial (SIG)

Material de Apoio. Sistema de Informação Gerencial (SIG) Sistema de Informação Gerencial (SIG) Material de Apoio Os Sistemas de Informação Gerencial (SIG) são sistemas ou processos que fornecem as informações necessárias para gerenciar com eficácia as organizações.

Leia mais

SAP RECURSOS HUMANOS O curso completo abrange quatro módulos:

SAP RECURSOS HUMANOS O curso completo abrange quatro módulos: SAP RECURSOS HUMANOS O curso completo abrange quatro módulos: - SAP FOUNDATIONS (40 horas EAD) - HR Recursos humanos (40 horas presenciais), tendo como pré requisito o módulo SAP FOUNDATIONS * - BPM Business

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

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

Redes Dinâmicas de Cooperação Organizacional, Modelo Dinâmico Descritivo de Negócios e Interoperabilidade

Redes Dinâmicas de Cooperação Organizacional, Modelo Dinâmico Descritivo de Negócios e Interoperabilidade Redes Dinâmicas de Cooperação Organizacional, Modelo Dinâmico Descritivo de Negócios e Interoperabilidade Bruno Carvalho Palvarini bruno.palvarini@caixa.gov.br CAIXA ECONÔMICA FEDERAL 1 Desenvolvimento

Leia mais

Modelo de dados do Data Warehouse

Modelo de dados do Data Warehouse Modelo de dados do Data Warehouse Ricardo Andreatto O modelo de dados tem um papel fundamental para o desenvolvimento interativo do data warehouse. Quando os esforços de desenvolvimentos são baseados em

Leia mais

FINANÇAS EM PROJETOS DE TI

FINANÇAS EM PROJETOS DE TI FINANÇAS EM PROJETOS DE TI 2012 Material 1 Prof. Luiz Carlos Valeretto Jr. 1 E-mail valeretto@yahoo.com.br Objetivo Objetivos desta disciplina são: reconhecer as bases da administração financeira das empresas,

Leia mais

Aquecimento para o 3º Seminário Internacional de BPM

Aquecimento para o 3º Seminário Internacional de BPM Aquecimento para o 3º Seminário Internacional de BPM É COM GRANDE PRAZER QUE GOSTARÍAMOS DE OFICIALIZAR A PARTICIPAÇÃO DE PAUL HARMON NO 3º SEMINÁRIO INTERNACIONAL DE BPM!! No ano passado discutimos Gestão

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

SAP PLANEJAMENTO DE PRODUÇÃO O curso completo abrange quatro módulos:

SAP PLANEJAMENTO DE PRODUÇÃO O curso completo abrange quatro módulos: SAP PLANEJAMENTO DE PRODUÇÃO O curso completo abrange quatro módulos: - SAP FOUNDATIONS (40 horas EAD) - PP Planejamento de Produção (40 horas presenciais), tendo como pré requisito o módulo SAP FOUNDATIONS

Leia mais

Uma Abordagem usando PU

Uma Abordagem usando PU Uma Abordagem usando PU Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior Referências: Baseada em: Rational Software Corpotation G. Booch, Ivar Jacobson,

Leia mais

2 Diagrama de Caso de Uso

2 Diagrama de Caso de Uso Unified Modeling Language (UML) Universidade Federal do Maranhão UFMA Pós Graduação de Engenharia de Eletricidade Grupo de Computação Assunto: Diagrama de Caso de Uso (Use Case) Autoria:Aristófanes Corrêa

Leia mais

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves

MSF- MICROSOFT SOLUTIONS FRAMEWORK. Cesar Eduardo Freitas Italo Alves MSF- MICROSOFT SOLUTIONS FRAMEWORK Cesar Eduardo Freitas Italo Alves A ORIGEM DO MSF (MICROSOFT SOLUTIONS FRAMEWORK) Baseado na experiência da empresa na construção de softwares como Office e Windows e

Leia mais

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS

PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS PEDRO HENRIQUE DE OLIVEIRA E SILVA MESTRE EM MODELAGEM MATEMÁTICA E COMPUTACIONAL E-MAIL: PEDROHOLI@GMAIL.COM CMMI E METODOLOGIAS Á G EIS CMMI E METODOLOGIAS ÁGEIS Os métodos de desenvolvimento Ágeis e

Leia mais

SAM GERENCIAMENTO DE ATIVOS DE SOFTWARE

SAM GERENCIAMENTO DE ATIVOS DE SOFTWARE SAM GERENCIAMENTO DE ATIVOS DE SOFTWARE Modelo de Otimização de SAM Controle, otimize, cresça Em um mercado internacional em constante mudança, as empresas buscam oportunidades de ganhar vantagem competitiva

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

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

silviaheld@usp.br Italiano, Isabel Cristina. Profa. Dra. - Têxtil e Moda - Escola de Artes, Ciências e RESUMO ABSTRACT

silviaheld@usp.br Italiano, Isabel Cristina. Profa. Dra. - Têxtil e Moda - Escola de Artes, Ciências e RESUMO ABSTRACT MAPEAMENTO DE PROCESSOS DE CONFECÇÃO PARA IDENTIFICAÇÃO DE PONTOS CRÍTICOS DA PRODUÇÃO Espinosa, Caroline Stagi - Bacharel em Têxtil e Moda - Escola de Artes, Ciências e Humanidades - Universidade de São

Leia mais

DECLARAÇÃO DE POSICIONAMENTO DO IIA: O PAPEL DA AUDITORIA INTERNA

DECLARAÇÃO DE POSICIONAMENTO DO IIA: O PAPEL DA AUDITORIA INTERNA Permissão obtida junto ao proprietário dos direitos autorais, The Institute of Internal Auditors, 247 Maitland Avenue, Altamonte Springs, Florida 32701-4201, USA, para publicar esta tradução, a qual reflete

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

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

Versão 6.04.00 Setembro/2013. Manual de Processos. Módulo Protocolo

Versão 6.04.00 Setembro/2013. Manual de Processos. Módulo Protocolo Versão 6.04.00 Setembro/2013 Manual de Processos Módulo Protocolo 1 1 2 2 Sumário Sumário... 3 Introdução ao Manual de Processos... 4 Conceituado os Processos de Negócio... 5 Estrutura do Manual de Processos...

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

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

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas

UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas UNIDADE 4. Introdução à Metodologia de Desenvolvimento de Sistemas 4.1 Motivação Sistemas de Informação são usados em diversos níveis dentro de uma organização, apoiando a tomada de decisão; Precisam estar

Leia mais