Visão de Processos de Negócio

Documentos relacionados
Visão de Processos de Negócio

Visão de Comportamento do Negócio

Visão de Comportamento do Negócio

Visão de Estrutura do negócio

Introdução. Introdução. Introdução. Planejamento da disciplina. Modelagem de Processos de Negócio. Prof.: Clarindo Isaías Pereira da Silva e Pádua

MODELAGEM DE SISTEMAS. Introdução a Computação e Engenharia de Software. Profa. Cynthia Pinheiro

UML: Introdução. História Visão geral Modelo conceitual da UML. Bibliografia. UML: introdução

Modelagem Usando Orientação à Objetos (Programação Orientada a Objetos) Prof. Responsáveis Wagner Santos C. de Jesus

Modelagem. Bibliografia. Modelo. Prof.: Clarindo Isaías Pereira da Silva e Pádua. Modelo segundo Aurélio. Gestus

Introdução Diagrama de Classes Diagrama de Seqüência Diagrama de Atividades. Diagramas UML. Classe, Seqüência e Atividades. Marcio E. F.

INSTITUTO FEDERAL DE EDUCAÇÃO, CIÊNCIA E TECNOLOGIA DO RIO GRANDE DO NORTE CAMPUS JOÃO CÂMARA UML UNIFIED MODELING LANGUAGE

Modelagem da Arquitetura do Negócio

Notas de Aula 03: Introdução a Orientação a Objetos e a UML

Introdução. à UML. Histórico (cont.) Histórico Definição Benefícios Notação Diagrama de Classes Diagramas de Interação Conclusões Revisão

UML (Unified Modelling Language)

Engenharia de Software 2012/3 Aula 5 Modelagem de Sistemas

Capítulo 5 Modelação do Sistema 1

Análise e projeto de sistemas

Sistematização do levantamento de requisitos em processos de desenvolvimento de software a partir de uma arquitetura de modelagem de negócios

A modelagem de Negócio com UML

Engenharia de Software. UML Unified Modeling Language

Introdução aos sistemas de informação

02/10/2012. Referências. Processo visando a Usabilidade. Introdução. Engenharia de Usabilidade. Prof.: Clarindo Isaías Pereira da Silva e Pádua

Análise de Sistemas. Aula 5

Introdução a UML (Unified Modeling Language)

O Fluxo de Requisitos

Programa Analítico de Disciplina INF323 Engenharia de Software II

Objetivo. Diagramas de Caso de Uso. História. Diagramas de Caso de Uso. Atores. Atores

Rational Unified Process (RUP)

APLICAÇÃO DA ENGENHARIA DE REQUISITOS E ESPECIFICAÇÃO DE REQUISITOS NA IDENTIFICAÇÃO DE ESCOPO DE SISTEMA

Modelagem de dados usando o modelo Entidade- Relacionamento (ER)

UML (Linguagem Modelagem Unificada) João Paulo Q. dos Santos

IDENTIFICAÇÃO DO ESCOPO DE SOFTWARE A PARTIR DA ANÁLISE DE REQUISITOS UTILIZANDO A UML

Requisitos de Software e UML Básico. Janaína Horácio

Modelos em Sistemas de Informação. Aula 2

DIAGRAMAS DE CLASSE UML

1.1. Declaração do Problema e Limitações dos Trabalhos Relacionados Um Framework Conceitual para SMAs

UML Diagramas Estruturais Diagrama de Componentes

Fases do OOHDM. OOHDM Um modelo para autoria de HT

Analista de Sistemas S. J. Rio Preto

Análise de Sistemas 3º Bimestre (material 2)

Diagrama de Estados. Curso de Especialização DEINF - UFMA Desenvolvimento Orientado a Objetos Prof. Geraldo Braz Junior

UML e seus diagramas

Capítulo 5 Gerenciamento do Escopo do projeto. Introdução. Antes de iniciarmos vamos pensar um pouco.

FUNDAÇÃO UNIVERSIDADE ESTADUAL DE MARINGÁ

Bibliografia. UML: visão geral. Prof.: Clarindo Isaías Pereira da Silva e Pádua. UML: visão geral

ENGENHARIA DE SOFTWARE. Aula 03 Processos de Software

Diagrama de Sequência Notação Objetos. Diagrama de Sequência Notação Mensagens. Diagrama de Sequência Notação Mensagens. Tipos de Mensagens

Especificação de Sistemas de Software e a UML

Diagrama de Atividades. Professor: André Gustavo Bastos Lima

Modelagem de Sistemas. Análise de Requisitos. Modelagem

Introdução a UML e seus diagramas

Processo. Processo unificado. Principais Características do UP. Principais Características do UP RUP. Unified Process (Processo Unificado)

Visões Arquiteturais. Visões Arquiteturais

Padrão para Especificação de Requisitos de Produto de Multimídia

Engenharia de Software e Gerência de Projetos Prof. Esp. André Luís Belini Bacharel em Sistemas de Informações MBA em Gestão Estratégica de Negócios

Introdução. Diagramas de Interação. Introdução. Introdução. Introdução. Introdução. Os modelos de análise não respondem a algumas perguntas:

Desenvolvimento de Sistemas Orientados a Objetos com UML UP/RUP: Projeto

Diagrama de Atividades

PMBOK Processo Planejamento

POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos. POO Paradigma Orientado a Objetos

Requisitos de Sistemas

Engenharia de Software. Projeto de Arquitetura

Agenda da Aula. Arquitetura de Software e Padrões Arquiteturais. Elementos de um Padrão. Arquitetura de Software. Arquitetura de Software

Diagramas. Abordaremos agora cada um destes tipos de diagrama: 1. Diagrama Use-Case. 2. Diagrama de Colaboração. 3. Diagrama de Sequência

ENGENHARIA DE SOFTWARE. Aula 07 UML - Diagrama de Casos de Uso

as fases contemplam todas as etapas do ciclo de desenvolvimento (requisitos, análise, projeto, implementação, teste e validação);

Especificação de Sistemas e SysML

Interações entre objetos

UML UNIFIED MODELING LANGUAGE LINGUAGEM DE MODELAGEM UNIFICADA

Engenharia de Software II

Tópicos da Aula. A Linguagem UML. A Linguagem UML. De onde surgiu? Fundadores da UML. Introdução à UML e Diagrama de Casos de Uso.

MANUAL PARA DESENVOLVIMENTO DE SOFTWARE TRABALHO DE CONCLUSAO DE CURSO EM SISTEMAS DE INFORMAÇÃO

Apresentação do Capítulo 4 MDA (Model-Driven Archtecture) ALUNO: DOMENICO SCHETTINI FILHO NÚMERO USP:

Engenharia de Requisitos

Visão Geral da UML. SSC Engenharia de Software I Profa. Dra. Elisa Yumi Nakagawa 2 o semestre de 2012

15/04/2013. Pensar Orientado a Objetos. Projeto Orientado a Objetos. Características de Objetos. Classe de Objetos. Comunicação entre Objetos

Análise e Projeto de Software Parte II. Marcos Dósea

Ferramenta MVCASE - Estágio Atual: Especificação, Projeto e Construção de Componentes

Análise de Requisitos. Tema 4. Análise de Requisitos Profa. Susana M. Iglesias

Áreas de Conhecimento, Técnicas de Análise de Negócio e Conceitos-Chave

Modelagem de Sistemas

CSE Métodos e Processos na Área Espacial

Bibliografia. Quais são os problemas? capacidade de construção. acompanha a demanda por novos programas. ameaçada por projetos ruins.

15/04/2013. Outro Diagrama de Classes. Primeiro Diagrama de Classes. Diagrama de Classes. Atributos. Eduardo Figueiredo

INF1013 MODELAGEM DE SOFTWARE

Use Cases e Fluxo de Eventos. Use Case e Ator. Objetivos. Algumas Definições. Algumas Definições

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

Linguagem de Modelagem Unificada UML

SERVIÇO PÚBLICO FEDERAL UNIVERSIDADE FEDERAL DE SANTA CATARINA CENTRO DE CIÊNCIAS DA SAÚDE PROGRAMA DE MESTRADO PROFISSIONAL EM INFORMÁTICA EM SAÚDE

Engenharia de Software.

Introdução à Análise e Projeto de Sistemas

Campus Capivari Análise e Desenvolvimento de Sistemas (ADS) Prof. André Luís Belini /

Modelagem de Processos de Negócio Aula 4 Projeto de Modelagem Andréa Magalhães Magdaleno

Modelagem de Processos. Prof a. Silvia Inês Dallavalle de Pádua

LEVANTAMENTO DE REQUISITOS E ANÁLISE PARA UM SISTEMA DE CONTROLE DE ACADEMIA

MODELAGEM DE PROCESSOS MÓDULO 9

RUP Unified Process. Profª Jocelma Rios

Transcrição:

Visão de Processos de Negócio Bibliografia Eriksson, H-E; Penker, M. Business Modeling with UML: Business Patterns at work, John Wiley, 2000 Prof.: Clarindo Isaías Pereira da Silva e Pádua Gestus Departamento de Ciência da Computação - UFMG Booch G. et al, "The Unified Modeling Language User Guide", Addison Wesley, 1999. Rumbaugh J. et al, "The Unified Modeling Language Reference Manual", Addison Wesley, 1999. 1 2 Conteúdo Introdução. Especificação dos processos de negócio. Modelagem de processos de negócio. Diagrama de linha de Montagem. Introdução Está no centro da modelagem de negócio. O processo mostra: Atividades que precisam ser realizadas para atingir metas explícitas E os relacionamentos com os recursos que participam no processo Recursos: Incluem pessoas, materiais, energia, informação e tecnologia. São consumidos, refinados, criados ou usados (ex. atuam como catalisadores) durante o processo 3 4 1

Introdução Introdução O resultado é a criação de diagramas de processos que descrevem pelo menos os processos centrais da organização. Os processos centrais: normalmente são orientados aos clientes; são críticos para entrega de mercadorias e serviços oferecidos pela organização; são horizontais na organização (englobando vários departamentos na organização). Uma descrição de processo deve ser geral, descrevendo todas as alternativas de execução (incluindo situações de erro e excessões) mas Uma instância de um processo executa um caminho específico no Uma instância é como um exemplo de uma execução. 5 6 Introdução Introdução Existe relação entre: um processo e seus recursos; metas podem ser associadas a processos; diferentes processos que interagem. Os processos têm Propósito Meta específica Todos os processos coletivamente buscam atender às metas globais do negócio. As metas da organização que se encontram no modelo de visão do negócio são a base para o modelo de processos. As definições de processo são usadas para: entender o negócio; identificar ameaças ou oportunidades; melhorar ou inovar; atuar como base para outros modelos Como os modelos de sistemas de informação 7 8 2

Introdução Introdução Os processos de negócio são modelados usando: entrevistas; discussões com pessoas do negócio; resultados de sessões de brainstorming compostas por grupos selecionados cuidadosamente; estudos práticos de como o negócio opera; descrições de processos existentes servem como base. Mas esses precisam ser revisados com olhos críticos. Ao executar as atividades de levantamento de processos, o modelador deve: buscar entender o negócio; capturar como o negócio opera; capturar como os recursos na empresa são manuseados. Os arquitetos de negócio criam o modelo de processos de negócio Com o apoio da equipe de modeladores do 9 10 Especificação dos processos de negócio Quais atividades são requeridas? Estas são especificadas como processos ou atividades num diagrama de processos. Quando as atividades são executadas e em qual ordem? Introdução É especificado pelo fluxo de controle no diagrama. Introdução > Especificação dos processos de negócio Porque as atividades são executadas; quais são as metas dos processos? Especificado por meio de objetos da classe meta associadas a processos; ou por Diagramas de metas que mostram relações entre metas. Como as atividades são executadas? Isso é especificado no diagrama de processos, freqüentemente pela quebra de processos em sub-processos que definem as atividades em maior detalhe. 11 12 3

Introdução > Especificação dos processos de negócio Introdução > Especificação dos processos de negócio Quem ou o que é envolvido na execução das atividades? Definido pelos recursos que participam no O que está sendo consumido ou produzido? Definido pelos recursos que são consumidos ou produzidos no Como as atividades precisam ser executadas? Definido por meio do: fluxo de controle no diagrama de processos, ou por regras de negócio. Quem controla o processo? Quem executa o processo ou é responsável pelo seu sucesso. Como o processo está relacionado à organização do negócio? Pode ser mostrado por meio de raias no diagrama de processos. 13 14 Como o processo está relacionado a outros processos? Introdução > Especificação dos processos de negócio Mostrado por meio de diagramas de interação, discutida na Visão de Comportamento. Com o melhor entendimento do negócio as respostas para todas essas perguntas tornamse aparentes, facilitando a modelagem acurada dos processos no negócio. Modelagem de processo A visão de processos de negócio é descrita com diagramas de atividade da UML. A extensão de negócio Eriksson-Penker estabelece um conjunto de estereótipos que definem um processo e os vários recursos. Propõe também uma variante, o diagrama de Linha de Montagem (adiante). 15 16 4

Modelagem de processos Modelagem de processos > Motivação Motivação A modelagem de processos pode ser usada para: Criação de uma documentação acurada do modo com que o trabalho é executado. Importante para o desenvolvimento de sistemas de informação. Melhorar ou inovar os processos Para fazer o negócio funcionar mais eficientemente. Criar e projetar novos processos que tiram vantagens dos recursos e conhecimento presente na organização. Identificar oportunidades no negócio. É importante esclarecer o propósito da modelagem de negócio antes de começar a modelar. Faz focar no que é mais importante no modelo Pode-se determinar se a modelagem está no caminho certo Provê uma meta a ser perseguida. Torna mais fácil decidir o que é importante. 17 18 Modelagem de processos Modelagem de processos > Técnicas Técnicas Existem várias técnicas usadas para modelar o negócio. Em geral: são orientadas ao cliente; requerem a avaliação dos produtos ou serviços produzidos no negócio. Pela análise das interfaces com os clientes da organização é possível: identificar os eventos do negócio que são gerados e analisá-los para indicar a ação apropriada que o negócio precisa tomar para cada evento. Por um trabalho inverso, a partir das definições de produtos e serviços é possível descobrir as atividades requeridas para produzi-los. O fluxo de ambos controle e objetos (ex. recursos) são capturados e descritos no modelo de processos. Cada passo no processo adiciona valor aos recursos criados ou refinados no 19 20 5

Modelagem de processos > Técnicas Modelagem de processos > Técnicas Os processos são modelados: primeiramente modelando e concentrandose nos processos centrais do negócio por completo; em seguida os processos de suporte. Um negócio usualmente não tem mais de cinco a dez processos centrais, mas pode ter muito mais processos de suporte. Idealmente, todos os processos são modelados e integrados uns aos outros. Se não for prático, a abordagem poderia ser: concentrar-se nos processos centrais. É também importante determinar se um processo de suporte indireto restringe, de algum modo, um processo central. O que deve ser evitado. 21 22 Gerência dos processos A gerência dos processos também está no escopo da modelagem de processos. Os processos muitas vezes não são diretamente alocados a somente uma unidade organizacional. Deve existir um responsável por um processo específico dentro da organização. O responsável tem autoridade sobre aquele processo perante toda a organização. Modelagem de processos A gerência é importante para garantir que os resultados do processo sejam distribuídos de maneira justa na organização. Evitando, por exemplo, que uma unidade organizacional ganhe com um processo enquanto outra unidade tenha uma perda pelo mesmo Modelagem de processos > Gerência dos processos Idealmente, o modo vertical de construção de unidades de resultados é eliminado e substituído por uma organização de processo completa. 23 24 6

Diagrama de processos É um diagrama de atividades. Possui um conjunto de estereótipos que descrevem : as atividades executadas dentro de um processo; como as atividades interagem; os recursos de entrada e de saída; os recursos de fornecimento ou de controle dos processos; as metas do Modelagem de processos processos Um processo é uma atividade estereotipada por <<processo>>. Um processo pode conter outros processos, ou sub-processos que descrevem os passos internos tomados dentro de todo o 25 26 processos processos O símbolo de atividade na UML é usado para mostrar que um processo não pode ser quebrado em sub-processos ou que fazer isso ad Diagram de processo genérico «Pessoa» objeto Pessoa «Meta» Meta do Processo : Meta Quantitativa pode não ser significante. Neste caso, a atividade ou processo é considerada atômica. «Objeto de Informação» objeto de entrada A «Controla» Processo «Atinge» «Físico» objeto de saída Supõe-se que a descrição da atividade seja suficiente para o entendimento do processo «Físico» objeto de entrada B atômico. «Supre» «Supre» «Físico» objeto Físico objeto de Informação 27 28 7

Objetos de meta: representa uma meta do diagrama meta/problema que tenha sido alocada a um É desenhado na parte superior no diagrama do processo processos Objetos do diagrama Há um relacionamento de dependência, estereotipada por <<atinge>> do processo para o objeto meta (mostra que o processo busca atingir a meta). Objetos de entrada: recursos que são consumidos ou refinados no processo Têm relacionamento de <<object flow>> com o processos > Objetos do diagrama Este é um estereótipo de relacionamento de dependência usado para conectar objetos a atividades em um diagrama de atividades (ou de estados) São normalmente colocados a esquerda do O refinamento de um recurso pode mudar sua localização, aparência, conteúdo, ou informação. 29 30 processos > Objetos do diagrama processos > Objetos do diagrama Objetos de saída: recursos que são produzidos pelo processo ou são o resultado do refinamento de um ou mais objetos de entrada. São conectados ao processo também por um relacionamento <<object flow>>. São normalmente colocados a direita do Objetos fornecidos: são recursos que participam do processo mas não são consumidos nem produzidos por ele. São conectados ao processo também por um relacionamento de dependência, estereotipados <<fornece>> ou <<supre>>. São desenhados abaixo do 31 32 8

processos > Objetos do diagrama processos > Objetos do diagrama Objetos de controle: são recursos que controlam ou executam o São conectados ao processo também por um relacionamento de dependência, estereotipado <<controla>>. São normalmente desenhados acima do O processo é uma operação contínua que consome objetos de entrada e produz objetos de saída. Se o número de objetos de saída é requerido, poderia ser especificado como uma meta para o processo (ex. o número de produtos por dia ou por mês) Não por meio de multiplicidade como usado em relacionamentos na UML. 33 34 processos > Objetos do diagrama processos > Objetos do diagrama Pode ser difícil separar um objeto de entrada de um objeto fornecido. Objeto fornecido também pode mudar seu estado durante o Um objeto de entrada é um recurso chave que é refinado ou consumido para produzir um objeto de saída. Um objeto fornecido é um recurso que o processo requer (participa no processo) para consumir ou refinar outros recursos. Por exemplo, em processos manufaturados: um objeto de entrada poderia ser uma matéria prima; um objeto fornecido poderia ser uma máquina usada no Em muitos casos, o objeto de saída é do mesmo tipo que um objeto de entrada, mas com valor adicional resultante do Pode-se usar outros estereótipos para relacionamentos de transição ou de dependência. Por exemplo, um fluxo de objeto com o estereótipo nãocausal: indica que o objeto pode ou não ser o resultado de uma atividade ou 35 36 9

processos processos Raias podem ser usadas para: descrever onde as atividades são executadas em termos da organização do negócio (ex. em qual divisão ou departamento da empresa); mostrar quais objetos são responsáveis por uma atividade ou processo específico. Esses objetos podem ser uma máquina ou um papel de pessoa, por exemplo. ad Exemplo de processos com raias Exemplo de processo de negócio Vendas Produção Distribuição Venda de propaganda «Abstrato» Ordem de anúncio «Pessoa» Representante do cliente «fornece» «Objeto de informação» Perfil da empresa cliente «Pessoa» Webmaster «fornece» «controla» Web design «fornece» «Pessoa» Redator «Abstrato» Anúncio em banner «Abstrato» Plano de propaganda «Abstrato» Sítio Web Construção do sítio «Pessoa» Webmaster «controla» «abstrato» Sítio Web 37 38 Visão de processos de negócio Modelagem de eventos Exemplo de polimorfismo de eventos Modelagem de eventos Eventos de negócio podem ser usados ad Eventos de negócio «abstrato» para modelar respostas a ocorrências Conserto «não-causal» Ordem de execução do serviço importantes nos processos. Selecionado conserto Pode-se usar polimorfismo de eventos Call center Serviço selecionado Selecionado informação Informação sobre tarifas para modelar diferentes alternativas de transição. Selecionado contratação de serviços Contratação de serv iço contrato de serv iço 39 40 10

Modelagem de eventos > Exemplo de polimorfismo de eventos Visão de processos de negócio cd Ev ento polimórfico Diagrama linha de montagem «Evento de negócio» Serv iço selecionado É uma variante de um diagrama de processos, proposto na extensão Eriksson & Penker: Usado para descrever mais claramente como o processo interage com os recursos durante a execução. Os recursos são freqüentemente recursos de informação «Evento de negócio» Selecionado conserto «Evento de negócio» Selecionado informação «Evento de negócio» Selecionado contratação de serv iços (ex. objetos informação) em um sistema de informação. Mas podem ser usados para a modelagem de outros tipos de sistemas também, como logística ou recursos humanos. 41 42 Diagrama linha de montagem Diagrama linha de montagem O topo do diagrama contém um diagrama de processos ad Linha de montagem Processo X Processo Y Na parte inferior, aparecem pacotes estereotipados <<linha de montagem>>, cada um representando um conjunto de objetos. Os pacotes são desenhados de forma esticada, dando «Linha de Montagem» A uma aparência de linha de montagem. O propósito do diagrama é mostrar como os processos «Linha de Montagem» B na parte superior fazem referência às linhas de montagem. 43 44 11

Diagrama linha de montagem Diagrama linha de montagem Referências entre os processos e os pacotes de linha de montagem representam as atividades ou funções principais mostradas no diagrama. São modeladas por relacionamentos de <<object flow>>. São usados para representar operações de transferência de objetos entre os processos e as linhas de montagem. Os nomes desses relacionamentos podem ser usados para dar nomes às operações. Os pacotes de linha de montagem provêm atividade de suporte para que as atividades principais possam ser realizadas. Um recurso pode ser lido ou atualizado por um processo e lido por outro processo mais adiante. Os objetos dos pacotes em geral são objetos de informação de sistemas de informação. O diagrama mostra como essa informação é acessada através do sistema e como ela é usada ou modificada no Mas os objetos podem ser outros tipos de recursos. 45 46 Diagrama linha de montagem Diagrama linha de montagem As linhas de montagem podem representar um sistema de informação, um sub-sistema ou um pacote de classes (por exemplo, classes de entidade) ou um tipo específico de recurso. A documentação de cada pacote deve conter uma Exemplo de diagrama de linha de montagem descrição do que ele representa. 47 48 12

cd Exemplo de linha de montagem Gestão de estoque Diagrama linha de montagem Venda Dar baixa em estoque Consulta dados de mercadoria «linha de montagem» Cadastro de mercadoris Avaliação de estoque [estoque Controle de estoque abaixo do mínimo] Compra Consulta dados de mercadoriaatualização de Registra pedido de compra para informação de estoque fornecedor Consulta pedido de compras Obtém informação de estoque Cadastra orçamento Mapeamento negócio/sistemas de informação. Diagramas de linha de montagem são importantes na abordagem Eriksson & Penker pois permitem um mapeamento entre o negócio e sistemas de informação. «linha de montagem» Informações de estoque «linha de montagem» Apoio a compras Permitem o mapeamento entre modelos de processos e casos de uso. Casos de uso descrevem aspectos funcionais de sistemas de informação. 49 50 Casos de uso podem ser derivados de diagramas de linha de montagem. As referências de processos a linhas de montagem mostram o fluxo de informação entre processos e sistemas de informação. Mostram as interfaces entre os processos de negócio e sistemas de informação. Casos de uso, na engenharia de software, são utilizados para modelar essas interfaces em termos da interação usuário/sistema. Diagrama linha de montagem > Mapeamento negócio / sistemas de informação Os atores que interagem com os casos de uso podem ser identificados a partir dos papéis representados pelos processos que utilizam as linhas de montagem. O diagrama de processos de negócio pode auxiliar na definição de casos de uso. Um conjunto de referências a linhas de montagem pode originar um caso de uso. Diagrama linha de montagem > Mapeamento negócio / sistemas de informação Definição de casos de uso Atores (recursos) devem ser identificados nos processos de negócio. 51 52 13

A análise pode ser realizada em diferentes níveis de abstração, em um abordagem top-down, começando com processos de mais alto nível e pacotes de linhas de montagem no nível de sistemas ou sub-sistemas de informação. O modelo é refinado. Diagrama linha de montagem > Mapeamento negócio / sistemas de informação > Definição de casos e uso O refinamento se dá na estrutura de processos e subprocessos e pacotes e sub-pacotes. Os processos e pacotes de linha de montagem são detalhados. No refinamento, também as referências de processos a linhas de montagem são detalhadas. Uma referência pode originar um conjunto de referências. Em cada nível de abstração, realizam-se as seguintes atividades: Identificação das referências dos processos às linhas de montagem, Modelagem conceitual (de classes) associada aos sistemas de informação. Uma ou mais referências são selecionadas para gerar um caso de uso. Diagrama linha de montagem > Mapeamento negócio / sistemas de informação > Definição de casos e uso Isso quando se está trabalhando em nível de detalhamento de um sistema de informação. 53 54 A escolha das referências deve ser feita criteriosamente. Deve existir uma coesão semântica entre elas. Um caso de uso deve ter um iniciação clara, representa um comunicação entre ator e sistema e deve ter um término bem definido que traga valor para o cliente. A engenharia de software e de usabilidade propõem técnicas e critérios para a identificação de casos de uso. Diagrama linha de montagem > Mapeamento negócio / sistemas de informação > Definição de casos e uso A caracterização de atores e das tarefas que eles realizam provêm valiosos subsídios para a definição de casos de uso. Requistos não funcionais são aqueles ligados à qualidade do produto. A norma ISO 9126 define um modelo para a qualidade de um produto de software. Diagrama linha de montagem > Mapeamento negócio / sistemas de informação Requisitos não funcionais Este modelo (ISO 9126) define características de qualidade como, por exemplo, eficiência, manutenibilidade, usabilidade, portabilidade, etc. 55 56 14

Diagrama linha de montagem > Mapeamento negócio / sistemas de informação > Requisitos não funcionais Características dos processos podem afetar requisitos não-funcionais. O tempo de execução de um processo pode afetar sistemas de suporte. Perguntas como quão confiável, quão rápido, quão portável, quão usável, etc, podem ser respondidas considerando as características dos processos. Por características dos processos entende-se características de seus elementos como atividades, recursos (incluindo pessoas), metas, etc. Uma análise cotejando as características dos processos de negócio com as características dos sistemas pode também ser usada para validar e verificar os sistemas de informação. Validar está relacionado com fazer as coisas certas. Verificar está relacionado com fazer certo as coisas. As metas de negócio são especialmente importantes na validação e verificação dos requisitos dos sistemas. validação: os requisitos do sistema levam à conquista das metas? verificação: os requisitos, como definidos, levam realmente à conquista das metas? Diagrama linha de montagem > Mapeamento negócio / sistemas de informação 57 58 15