Mapeando processos de negócios com Zackman Framework e SBVR

746 visualizações

Publicada em

Trabalho da disciplina de Engenharia de Requisitos de Software - Dr. Paulo Sérgio Muniz, Mapeando processos de negócios com Zackman Framework e SBVR

Publicada em: Tecnologia
0 comentários
1 gostou
Estatísticas
Notas
  • Seja o primeiro a comentar

Sem downloads
Visualizações
Visualizações totais
746
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
22
Comentários
0
Gostaram
1
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Mapeando processos de negócios com Zackman Framework e SBVR

  1. 1. Apresentação Equipe #3André Rocha Agostinho, 40.820Herez Moise Kattan, 40.800Nery Signorini Neto, 35.681 09 de abril de 2013
  2. 2. Temas Abordados na Apresentação1) Quadros de referência para a Engenharia de Software• Fornecer modelos apropriados para as colunas 1 (O quê?), 2 (Como?) e 3 (Onde?)das linhas 2 e 3 do Arcabouço de Zackman;• Fornecer e justificar uma proposta de mapeamento dos elementos das células das colunas data funções da linha 2 para as células correspondentes da linha 3;• Propor uma sugestão de como migrar RN da linha 2 para a linha 3.
  3. 3. Temas Abordados na Apresentação2) Regras de negócio e requisitos de software.• De acordo com o artigo discutido na aula 9, apresentar um conjunto de Regras de Negócio para o exemplo da disciplina assumindo premissas razoáveis.• Definir parte dos conceitos do domínio do problema segundo o vocabulário SBVR e suplementar alguns deles, quando necessário, com regras de negócio estruturais.• Definir algumas regras de processos de negócio segundo o SBVR.• Definir algumas restrições.• Dar exemplos de como as regras de negócio definidas acima podem afetar o modelo da coluna “dados” e linha 3 da primeira parte.
  4. 4. Exemplo da DisciplinaObjeto do Trabalho:Sistema de Monitoração de Acúmulo deÁguas Pluviais nas Estradas (Sigla: SMAAPE)
  5. 5. Domínio do Problema
  6. 6. Domínio do Problema• Quando e onde haverá possibilidade de haver acúmulo de água decorrente das chuvas?• Qual é o nível pluviométrico que represente perigo para a circulação de veículos?• As equipes de recuperação e sinalização devem ser acionadas quando o nível pluviométrico ultrapassar o considerado “perigoso”;• O que é considerado perigoso?• Quais outros valores qualitativos e quantitativos existem?• O produto de software deverá melhorar a assertividade das previsões futuras de chuvas e de alagamentos;
  7. 7. Domínio do Problema – Cont.• Auxiliar no gerenciamento das equipes e frota de manutenção e sinalização nas bases operacionais instaladas nos pontos estratégicos;• Objetivo é tornar as estradas “mais seguras”;• O que é ser “mais seguro?”;• Conexão (troca de dados) permanente com o Centro de Pesquisas Meteorológicos de Sãp Paulo (CMSP);• Coleta das condições meteorológicas e do nível pluviométrico nas estradas em tempo real;• Dispositivos/sensores instalados ao longo das estradas;• Central de Gestão e Monitoração das estradas, evitar acidentes, aumentar proatividade das equipes.
  8. 8. Stakeholders IdentificadosNome Representa Papel#1 Secretário do Governo do Estado, É responsável pelo editalTransporte representado pela e pelo conteúdo da secretaria de transporte licitação Patrocina o projeto É sponsor do projeto, possui decisão final para aprovação do fornecedor#2 Diretor DER Depto Estradas e É responsável em analisar Rodagem, responsável o conteúdo da proposta pelas estradas do estado técnica para o produto de software
  9. 9. Stakeholders Identificados – Cont.Nome Representa Papel#3 Diretoria Comercial Centro Meteorológico de Definirá os métodos deCMSP (Centro de São Paulo, responsável acesso aos dadosMeteorologia de SP) pelas previsões meteorológicas do Disponibilizarão estado informações sobre previsão do tempo para o sistema#4 Superintendente Secretaria responsável É responsável pelaregional para pela conservação das administração doconservação das estradas contrato de monitoraçãoestadas das estradas do vencedor da licitação
  10. 10. Stakeholders Identificados – Cont.Nome Representa Papel#5 Diretor Centro de Responsável pelos Definirá requisitos para oManutenção (Base centros de manutenção gerenciamento eCentral – Gestão e espalhados agendamento dasCoordenação) estrategicamente pela equipes de manutenção rodovia e sinalização Faz a gestão da frota e das equipes#6 Coordenador Centro Responsável pelo centro Receberá osde Manutenção (Bases de manutenção acionamentos e osInstaladas – específico boletins do centro deOperacionais) monitoração e enviará equipes aos locais determinados
  11. 11. Usuários IdentificadosNome Descrição StakeholderAnalista da Qualidade DER – Responsável por Representa o governodas Estradas definir premissas e como contratante e restrições da licitação principal sponsor. Representa #1 e #2Meteorologista CMSP Identificará os critérios para que os sistemas Responsável em sejam integrados disponibilizar informações meteorológicas e Representa #3 previsão pluviométrica para o sistema
  12. 12. Usuários Identificados – Cont.Nome Descrição StakeholderUsuário do sistema de Responsável pela Faz parte do ganhadormonitoração (Gestão) utilização do sistema e da licitação realiza acionamento às equipes de manutenção Representa #5 e sinalização Central de monitoração e acionamentoUnidade de atendimento Realiza os serviços de Executas as ações após(Execução) reparo, sinalização e acionamento pela ações preventivas. central Representa #6
  13. 13. Estrutura do Sistema
  14. 14. IDEF0 do Sistema Nível 0
  15. 15. IDEF0 do Sistema Nível 1
  16. 16. Arcabouço de Zachman
  17. 17. Arcabouço de Zachman
  18. 18. What - Linha 2 – Coluna 1Semantic Model
  19. 19. What - Linha 2 – Coluna 2Business Process Model
  20. 20. What - Linha 2 – Coluna 3Business Logistic System Alertas Boletins Met. Acionamentos
  21. 21. Arcabouço de Zachman
  22. 22. What - Linha 3 – Coluna 1 Logical Data Model UnidadeGestao-UnidadeApoioRodovia-trecho Trecho-sensor
  23. 23. What - Linha 3 – Coluna 2Application Architecture
  24. 24. What - Linha 3 – Coluna 3Distributed System Architecture STG
  25. 25. Mapeando Linhas 2 e 3
  26. 26. Mapeamento Proposto Para classificação de risco de alagamentoRisco Descrição Condições de transiçãoAlto Trechos que devem ser (NP >= 30mm ) ou (PC == Alta e OA > 0) notificados as unidades de gestãoMédio Trechos que devem ser (NP >= 10mm e NP < 30mm) ou (PC == Alta supervisionados e necessitam e OA > 0) atençãoBaixo Trechos que não necessitam de (NP < 10mm) ou (PC != Alta„ e OA == 0) atençãoNeutro Trechos secos Otherwise NP: Nível pluviométrico OA: Ocorrências anteriores, acidentes PC: Previsão de chuva
  27. 27. Mapeamento Proposto: Dados Linha 2 Coluna 1 para Linha 3 Coluna 1Ator Caso de uso Atividades de negócioSensor Coletar dados do - Coletar Informações do Sensor trecho - Verificar sinal com o centro de metrologia - Coletar dados meteorológicos - Armazenar dados coletadosSistema de Analisar dados do - Analisar informações coletadas trecho - Classificar risco do trechomonitoramentoOperador Notificar trecho com - Notificar trechos com risco risco - Registrar trechos com risco de alagamentoGestor Notificar unidades de - Acionar unidades próximas apoio - Registrar trechos com risco de alagamentoAtividades de negócios no diagrama BPMN levam a casos de uso.
  28. 28. Mapeamento Proposto Funções Linha 2 Coluna 2 para Linha 3 Coluna 2ID Association Name DescriptionR1 Rodovia-trecho É necessário que uma rodovia tenha ao menos um trechoR2 Trecho-sensor É necessário que um trecho tenha ao menos um sensorR3 UnidadeGestao- É necessário que uma unidade de gestão e UnidadeApoio conservação tenha ao menos uma unidade de apoio1 Substantivos são transformados em objetos de negócios como classes;2. Tipos de valor (como números) são transformados em tipos básicos (boolean,número, texto, etc.);3. Relações de posse “Tem” são transformados em associações de composiçãoe agregação;4. Relações de definição “É” são transformadas em herança;5. Relações como “Envia”, “Mantém” e “Monitora” são transformadas emassociações entre classes;6. A cardinalidade das associações seguem o vocabulário SBVR.
  29. 29. SVBR - Semantics Of BusinessVocabulary And Rules
  30. 30. Semantics Of Business Vocabulary And Rules (SBVR)Definição:É uma especificação da OMG(www.omg.org/spec/SBVR/1.0) Usada na definição de regras de negócio (RN) a partirda perspectiva de negócio. A base para se definir RNsão as próprias regras do negócio.
  31. 31. Semantics Of Business Vocabulary And Rules (SBVR)Significado:• Ontologia terminológica (terminologia formal,vocabulário SBVR):um conjunto de conceitos interconectados para escrever regras denegocio;• Guia comportamental (políticas, regras, etc.): dirigem as açõesdos sujeitos da ontologia terminológica;• Fornece um meio para possibilitar o processamento dasemântica do negócio.
  32. 32. SBVR – Coletar Dados MeteorológicosRegras de Negócio:• Os dados metereológicos devem ser coletados do Centro de Metereologia do Estado;• Os dados sobre condições das estradas são coletados de dispositivos situados ao longo das estradas, sobretudo nos trechos em que historicamente ocorrem mais alagamentos;• Os dispositivos informam, em tempo real, as condições atmosféricas locais, incluindo a temperatura e a umidade.
  33. 33. SBVR – Coletar Dados Meteorológicos O sistema de monitoração deve coletar do Centro de Metereologia do Estado em tempo real as condições atmosféricas locais, incluindo a temperatura e a umidade.sistema de monitoraçãoDescription: Sistema de software SMAAPECentro de Metereologia do EstadoConcept Type: implicitly-understood conceptCondições atmosféricas locaisConcept Type: implicitly-understood conceptTemperaturaConcept Type: implicitly-understood conceptDefinition: Medido em Grau CelciusUmidadeConcept Type: implicitly-understood concept
  34. 34. SVBR - Coletar Dados das Condições Meteorológicas das Estradas O sistema de monitoração deve coletar dos dispositivos situados em trechos da estrada em tempo real as condições atmosféricas locais, incluindo a temperatura e a umidade.Sistema de monitoraçãoDescription: Sistema de software SMAAPEDispositivosSynonym: sensorTrechos da estradaConcept Type: implicitly-understood conceptCondições atmosféricas locaisConcept Type: implicitly-understood conceptTemperaturaConcept Type: implicitly-understood conceptDefinition: Medido em Grau CelciusUmidade Concept Type: implicitly-understood concept
  35. 35. Coletar Dados das Condições Meteorológicas das EstradasRegras de Negócio:• Os dispositivos informam, em tempo real, as condições atmosféricas locais, incluindo a temperatura e a umidade;• Acionar a central de monitoração;• Emitir alertas no sistema.
  36. 36. SVBR - Trecho Potencialmente Perigoso Premissa O sistema de monitoração necessita que um trecho da estrada tenha ao menos um dispositivo monitor.Sistema de monitoraçãoDescription: Sistema de software SMAAPEDispositivo monitorSynonym: sensorTrechos da estradaConcept Type: implicitly-understood concept
  37. 37. SVBR - Trecho Potencialmente Perigoso Premissa O sistema de monitoração deve considerar um trecho da estrada como potencialmente perigoso se nível pluviométrico maior ou igual a 30 milimetros ou neste trecho da estrada há histórico de alagamento e há previsão de chuva.Sistema de monitoraçãoDescription: Sistema de software SMAAPECondições atmosféricas locaisConcept Type: implicitly-understood conceptpotencialmente perigosoSynonym: alto riscoDescription: (NP >= 30mm ) ou (PC == Alta e OA > 0)Note: NP = nível pluviométricoPC = previsão de chuvaOA = ocorrências anteriores
  38. 38. SVBR – Trecho necessita atenção Premissa O sistema de monitoração deve considerar um trecho da estrada como necessita atenção se nível pluviométrico entre 10 e 30 milimetros ou se neste trecho da estrada há histórico de alagamento e há previsão de chuva.Sistema de monitoraçãoDescription: Sistema de software SMAAPECondições atmosféricas locaisConcept Type: implicitly-understood conceptnecessita atençãoSynonym: alto riscoDescription: (NP >= 10mm e NP< 30mm) ou (PC == Alta e OA > 0)Note: NP = nível pluviométricoPC = previsão de chuvaOA = ocorrências anteriores
  39. 39. SVBR -Alertar Centro de Monitoramento Restrição O sistema de monitoração deve avisar o coordenador do centro de monitoramento se há trechos da estrada potencialmente perigosos ou se há trechos da estrada que necessitam de atenção.Coordenador do centro de monitoramentoConcept Type: implicitly-understood concept-stakeholdertrecho da estrada potencialmente perigosoSynonym: alto riscoDescription: (NP >= 30mm ) ou (PC == Alta e OA > 0)Note: NP = nível pluviométricoPC = previsão de chuvaOA = ocorrências anteriorestrecho da estrada necessita atençãoDescription: (NP >= 10mm e NP< 30mm) ou (PC == Alta e OA > 0)Note: NP = nível pluviométricoPC = previsão de chuvaOA = ocorrências anteriores
  40. 40. SVBR – Alertar sobre Falhas Restrição O sistema de monitoração deve avisar o coordenador do centro de monitoramento se há falhas.Sistema de monitoraçãoDescription: Sistema de software SMAAPECoordenador do centro de monitoramentoConcept Type: implicitly-understood concept-stakeholderFalhasSynonym:irregularidade, insucesso, imperfeição, erroDefinition: qualquer, toda falha tanto de software quanto dehardwareDescription: SMAAPE deve ser capaz de detectar falhas desoftware e hardwareNote: SMAAPE deve ter uma interface humano computador quepermita ao usuário do SMAAPE identificar falhas no sistema
  41. 41. SVBR Extensãoimplicitly-understood concept Definition: concept that has a designation that is implicitly understood Description: O significado compreendido é o mesmo da linguagem corrente do termo que representa.implicitly-understood concept -stakeholder• Definition: concept that has a definition at PMBOK(2008):• Description: São pessoas e organizações, como clientes, patrocinadores, organizações executoras e o público, que estejam ativamente envolvidas no projeto ou cujos interesses possam ser afetados de forma positiva ou negativa pela execução ou término do projeto. Elas podem também exercer influência sobre o projeto e suas entregas.
  42. 42. Movendo da linha 2 para a linha3 do Arcabouço de Zachman
  43. 43. Proposta: Movendo da linha 2 para a linha 3 Regra de Negócio – perspectiva de Negócio • Segundo BRG1, é um guia que possui uma obrigação a respeito da conduta, execução, práticas ou procedimentos de uma particular atividade ou esfera (processo específico) [2]. O objetivo principal é determinar processos desempenhados por humanos e automatizados por sistemas. • Pela perspectiva do Negócio, as RN possuem a motivação e podem ser foco no processo de automação por TI.1 Business Rule Group
  44. 44. Proposta: Movendo da linha 2 para a linha 3 Regra de Negócio – perspectiva de Negócio • Podem ser RN Estruturuais (Structural Bus. Rules - verdadeiras em si) e; • RN Operacionais (Operative Bus. Rules – definição ou restrições).1 Business Rule Group
  45. 45. Proposta: Movendo da linha 2 para a linha 3 Regra de Negócio – perspectiva de TI • Segundo BRG1, RN Persp. TI é uma declaração que limita, que restringe aspectos do negócio. • Podem ser regras Derivadas (Derivation Rules) definem como a informação será utilizada (ie. Desconto); • Processos (Process Rules) regras que afetam o processo, gatilhos (ie. Mal pagador) e; • Restrições (Constrains) regras, restrições – premissas (ie. Respeitar limite de crédito);1 Business Rule Group
  46. 46. Proposta: Movendo da linha 2 para a linha 3Heurística abaixo pode ser aplicada para facilitar oprocesso de identificação [2]:• Regras de negócio Estruturais (Business), serão transformadas em regras Derivadas (TI);• Regras de negócio Operacionais (Bususiness), serão transformadas em regras Processos (TI) ou Restrições (TI)
  47. 47. Proposta: Movendo da linha 2 para a linha 3Exemplo de RN:RN Estruturais:1) Os sensores instalados coletam dados em realtime;2) Bases operacionais estão conectadas online com a central de monitoração;RN Operacionais:1) Mapa de riscos é resultado da estatística + histórico de acidentes no Km, acúmulo de água + previsão meteorológicas daquela região;2) Alertas do sistema são analisados pela central, que publica boletins, alertas e acionamentos.
  48. 48. Proposta: Movendo da linha 2 para a linha 3RN Estruturais:1) Os sensores instalados coletam dados em realtime;• O sistema possui threshold de Nms para garantir que os dados dos sensores estejam sendo coletados, alarme em caso de falha (envio de equipe no local, manutenções);• Nms é configurado pelo Adm do Sistema.2) Bases operacionais (clientes) estão conectados online com a central de monitoração;• O sistema possui controle dos links de comunicação entre as bases e a central, onde é identificado quais bases estão offline, para contingências operacionais (telefone, rádio),
  49. 49. Proposta: Movendo da linha 2 para a linha 3RN Operacionais:1) Mapa de riscos é resultado da estatística acidentes histórico, acúmulo de água + previsão meteor.;• Deriva em Processo: O cálculo para estabelecer riscos é oriundo da análise de 3 fatores (% histórico de acidentes no Km; % Vol. Água, Histórico de Alagamentos e Previsão (análise barométrica, volume estiamdo, probabilidade, impacto);2) Alertas do sistema são analisados pela central, que publica boletins, alertas e acionamentos;• Deriva em restrição: Após calculado o risco, o sistema emite um alerta e recomendações, Este, para ser válido deverá ser aprovado pelo Coordenador em serviço obrigatoriamente;
  50. 50. Proposta: Movendo da linha 2 para a linha 3Associação:Estrutural: Os sensores instaladoscoletam dados em realtime Funções primárias, automatizadas eEstrutural: Bases operacionais (clientes) monitoradasestão conectados online com acentral de monitoraçãoOperacional: Mapa de riscos éresultado da estatística acidenteshistórico, acúmulo de água + previsão Procedimentos/processosmeteor. traduzidos em funções no sistema;Operacional: Alertas do sistema sãoanalisados pela central, que publica Operação automatizada;boletins, alertas e acionamentos;
  51. 51. Proposta: Movendo da linha 2 para a linha 3 Aplicando so ConceitosPassos para Aplicação1) Classificar os RN Negócio (Business Owner Row 2) em: Estruturais ou Operacionais:2) Aplicar a Heurística Sugerida pelo artigo;3) As RN Estruturais, são transferidos como funções, programas específicos, ou equipamento que desempenham determinadas funções (de subsistência do sistema) que permite o negócio operar com segurança e integridade;4) Se faz a relação entre Requisito e Especificação (base para implementação).
  52. 52. Proposta: Movendo da linha 2 para a linha 3 Aplicando so ConceitosPassos para Aplicação5) Respeitar especificações dos componentes (sensores) utilizados na solução (são restrições de operação e uso);6) RN Operacionais; são transferidas com base em processos operacionais descritos, comportamentos adotados pelos operadores, cálculos, estatísticas que serão automatizados para auxiliar na tomada de decisão pelos operadores;7) Buscar processos operacionais, regras, códigos de conduta e outras “diretrizes”.
  53. 53. Proposta: Movendo da linha 2 para a linha 3 Aplicando so ConceitosRN Definidas Afetam o Modelo Dados – Col. 31. Regras Estruturais podem adicionar o modelo de dados com restrições e premissas de operação;2. Criação de funções específicas para subsistência do sistema;3. Regras Operacional, direcionam a implementação dos processos que se complementam com as ações da operação diária (a primeira reflete a segunda);4. O modelo de dados é acrescido de mecanismos para suportar ambas as regras;5. Atenção especial à rastreabilidade dos RN e RS.
  54. 54. Bibliografia[1] Evaluation of Current Architecture Frameworks, Susanne Leist, Gregor Zellner;[2] Moving from Zachman Row 2 to Zachman Row 3, Markus Schacher; [2]http://www.omg.org/mda/mda_files/SanJose.pdfThe Zachman Framework and the OMG‟s Model Driven Architecture;http://www.omg.org/mda/mda_files/09-03-WP_Mapping_MDA_to_Zachman_Framework1.pdfhttp://www.ibm.com/developerworks/rational/library/nov06/temnenco/http://www.hfgilbert.com/rc/Whitepapers/UMLRUPandZachmanBetterTogether.temnenko.pdfhttp://heaveniscupcake.blogspot.com.br/2006/10/practical-use-of-zachman-framework-for.html
  55. 55. Dúvidas? Obrigado! André, Herez e Nery

×