palestra sobre modelagem de processos de negócio
DESCRIPTION
Modelagem de Processos de NegócioTRANSCRIPT
Pós-GraduaçãoEngenharia de Software
Modelagem dos Processos de Negócio para a Definição de Requisitos de Sistemas Software
Prof. MSc. Osvaldo Kotaro [email protected]
2
Resumo Pergunte para algum analista de sistemas: Vocês realizaram a
modelagem dos processos de negócio antes de definir a especificação do sistema que sua equipe está desenvolvendo? Por incrível que pareça, a resposta será: "Veja bem, ..."; ou seja, são apresentadas várias desculpas plausíveis de não terem realizado esta atividade (e ainda por cima nos chamam de cegos!). Apesar da razão indicar que conhecimento dos processos de negócio é condição sine qua non para o desenvolvimento de sistemas que automatizem esses processos, a maioria das empresas de desenvolvimento de software insiste em desprezar esse conhecimento.
O objetivo da apresentação é discutir estas e outras questões associadas à Modelagem dos Processos de Negócio, bem como apresentar a opinião do palestrante sobre o estado atual desta área de atuação e suas expectativas para os próximos anos.
3
Problema do Desenvolvimento de Software
Por que?a. Não conseguimos entregar softwares nos
prazos e custos combinados com o cliente?
b. Não conseguimos entregar softwares que verdadeiramente atendam às necessidades dos clientes?
4
As Grandes Promessas
Scrum
Spring
DDD
PMBOK
UML
GWT
.NetXP
FDDTDD
Prince2
Javabeans
CMMI
BPMN
EJB
Ruby & Rails
MPS.br
SOARUP
TOGAF
Zachman
5
As Grandes Promessas
Matam até lobisomem!
Scrum
Spring
DDD
PMBOK
UML
GWT
.NetXP
FDDTDD
Prince2
Javabeans
CMMI
BPMN
EJB
Ruby & Rails
MPS.br
SOARUP
TOGAF
Zachman
6
As Grandes Decepções
7
As Grandes Decepções
8
Imaturidade, Insanidade ou Loucura?
Desenvolvemos softwares que devem apoiar processos de negócio, mas sem ao menos conhecê-los!
9
UP
HEUMANN , J. Introduction to business modeling using the Unified Modeling Language (UML), IBM, 2003 in: http://www.ibm.com/developerworks/rational/library/360.html.
NC
R
P
S
10
Princípios do Manifesto Ágil1. Garantir a satisfação do consumidor entregando rapidamente e continuamente
softwares funcionais;
2. Softwares funcionais são entregues frequentemente (semanas, ao invés de meses);
3. Softwares funcionais são a principal medida de progresso do projeto;
4. Até mesmo mudanças tardias de escopo no projeto são bem-vindas.
5. Cooperação constante entre pessoas que entendem do 'negócio' e desenvolvedores;
6. Projetos surgem através de indivíduos motivados, e que deve existir uma relação de confiança.
7. Design do software deve prezar pela excelência técnica;
8. Simplicidade;
9. Rápida adaptação às mudanças;
10. Indivíduos e interações mais do que processos e ferramentas;
11. Software funcional mais do que documentação extensa;
12. Colaboração com clientes mais do que negociação de contratos;
13. Responder a mudanças mais do que seguir um plano
11
Paradoxo de Cobb
12
Ou seja, por que não modelamos os processos de negócio?
Algumas desculpas (Veja bem ...):• Nunca precisamos modelá-los• Clientes não nos pagam para isso• Não está no contrato• Não dá! Já estamos atrasados!• Fazer o certo é muito acadêmico e muito
demorado
Talvez, no fundo, a verdadeira resposta seja:• Não sabemos como fazer isso
13
Modelagem dos Processos de Negócio Não basta apenas reunir desenvolvedores e clientes
para que a mágica aconteça (Manifesto Ágil) Não basta apenas utilizar uma notação padrão
(BPMN / Extensões do RUP) É preciso SABER ajudar os clientes a formalizarem
o seu conhecimento
Puxa! Nunca tinha pensado nisso!
Eu não sabia que o meu negócio era tão rico sim!
Agora eu vejo claramente o que é o meu negócio!
Podemos mudar isto?
14
Cuidado!!!
Muitos dizem que sabem modelar negócios; e acreditam piamente nisso!
Mas quando dois deles modelam o mesmo negócio, os resultados apresentados são diferentes, mesmo que adotem uma mesma abordagem!
Por que? Porque a maioria possui um
conhecimento informal ou semi-informal ...
15
Modalidades de Modelagem de Negócio Informal:
– Muito descritivo– Pouca consciência de uma abordagem metodológica
Semi-formal:– Baseado em notações de mercado– Pouca consciência de uma abordagem metodológica
Pragmático:– Baseado em notações de mercado– Conscientes de seus objetivos e de uma abordagem metodológica
Formal:– Baseado em notações e linguagens formais– Pesquisadores
16
A Bola da Vez
BPMS BPMN SOA WebServices Zachman Framework The Open Group Architecture
Framework (TOGAF) DoDAF
17
Abordagem Pragmática
Mais importante do que a notação e frameworks, é:– saber identificar os processos de negócio
( premissa da partição por eventos )– Saber detalhá-los sem a interferência
tecnológica ( premissa da neutralidade tecnológica )
– saber detalhá-los considerando os dados consumidos ou gerados ( premissa da partição por objetos )
18
Outro Primata
Mestre em Computação pelo ICMC-USP-São Carlos.
Professor da Faculdade Impacta de Tecnologia.
Especialista em Engenharia de Requisitos na Fundação Atech – Tecnologias Críticas.
Assuntos de interesse: Desenvolvimento Pragmático de Sistemas, Modelagem de Negócio, Metodologias de Levantamento e Especificação de Sistemas de Software.
19
Eventos
ANÁLISE DOS EVENTOS Externo Temporal
Nº Evento EsperadoNão-
EsperadoRelativo Absoluto
Não-Evento
1 Cliente Encomenda Livros ✔
2 Cliente Cancela Encomenda de Livros ✔(1)
3 Cliente Efetua Pagamento ✔(1)
4 Sexta-feira: Compra de Livros na Distribuidora ✔
5 Distribuidora Entrega Livros ✔(4)
6 Distribuidora Cancela Venda de Livros ✔
7 Entrega de Livros ao Cliente ✔ (5)
8 Cliente Devolve Livros ✔ (7)
9 Cliente Não Efetua Pagamento ✔ (3)
10 Distribuidora Não Entrega Livros ✔ (5)
20
Eventos X Processos
ANÁLISE DOS EVENTOS Externo Temporal
Nº Evento EsperadoNão-
EsperadoRelativo Absoluto
Não-Evento
1 Cliente Encomenda Livros ✔
2 Cliente Cancela Encomenda de Livros ✔(1)
3 Cliente Efetua Pagamento ✔(1)
4 Sexta-feira: Compra de Livros na Distribuidora ✔
5 Distribuidora Entrega Livros ✔(4)
6 Distribuidora Cancela Venda de Livros ✔
7 Entrega de Livros ao Cliente ✔ (5)
8 Cliente Devolve Livros ✔ (7)
9 Cliente Não Efetua Pagamento ✔ (3)
10 Distribuidora Não Entrega Livros ✔ (5)
Cliente
Anotar Enco-menda
encomenda
Cliente Livro
confirmação
Encomenda
Processo de Negócio
Depósito de Dados
Fluxo de Dados Identificado
Fluxo de Dados Não Identificado
Entidade Externa
Cliente Encomenda
Livros
21
Eventos X Processos X Conceitos X Estados
Cliente
Anotar Enco-menda
encomenda
Cliente Livro
confirmação
Encomenda
Processo de Negócio
Depósito de Dados
Fluxo de Dados Identificado
Fluxo de Dados Não Identificado
Entidade Externa
Cliente Encomenda
Livros
A B C
22
Eventos X Processos X Conceitos X Estados
Cliente
Anotar Enco-menda
encomenda
Cliente Livro
confirmação
Encomenda
Processo de Negócio
Depósito de Dados
Fluxo de Dados Identificado
Fluxo de Dados Não Identificado
Entidade Externa
Cliente Encomenda
Livros
A
B
C
stm Ciclo de Vida
Canceláv el
Criada
Aprov ada
Não-Aprov ada
Em-Atendimento
Atendida
Cancelada
23
A
B
C
Três diferentes visões (as nuvens) de um mesmo objeto em estudo (o sol no centro).
Perspectivas
Um objeto em estudo pode ser visualizado por meio de várias perspectivas
24
Business Use-Caseuc Business Process Mo...
Cliente
Anotar Encomenda
act Activ ity
Fu
nc
ion
ári
o
Receber Encomenda
:Cliente
:Cliente
:Encomenda
:Liv ro
encomenda confirmação
uc Business Use-Case ...
(from Business Use-Case)
Anotar Encomenda
Anotar Encomenda
25
BPMNBPMN BPMN-2
Cliente faz pedido de livros
Receber Pedido
Livraria confirma recebimento
Livraria valida pedido
Validar Pedido
Livraria informa não aceitação do pedido
RegistrarPagamento
Livraria envialivros
Cliente efetua pagamento
Enviar Livros
Cliente recebe livros
Fechar Pedido
Cliente cancela pedido
TraterCancelamento do
Pedido pelo Cliente
Cliente reclama nãorecebimento
Invertigar Situação
Livraria envia boleto
Cliente não efetuou o pagamento
Livraria cancela venda de livros
Solicitar Posição do Cliente
Livraria não enviou livros
Cliente devolve livros
A
A
Extornar Pagamento Desfazer registro deentrega
Livrariasolicita posição
Livraria enviasituação do pedido
Corrigir Falha naEntrega de Livros
Livraria informa cancelamentoda venda
BPMN Receber Pedido
Recepcionista
Cadastrar Cliente
Registrar Pedido
Recepcionar Pedido
Pedido
Cliente
Pedido
Cliente não cadastrado
26
Obtendo Requisitos Funcionais Para cada atividade do Atividade responda:
– O que o sistema deve fazer pelo worker para executar a atividade?
Descreva a resposta no seguinte formato:– O sistema deve permitir que o worker faça ….
27
Bibliografia Referências Bibliográficas
1. LEFFINGWELL, DEAN; WIDRIG, DON. Managing Software Requirements: A Unified Approach – Addison-Wesley object technology series, Addison Wesley, 2000. ISBN: 0-201-61593-2.
2. McMENAMIN, Stephen M.; Lars Gustav Erik Unonius. [Trad.]. Analise essencial de sistemas. Traduzido do original: ESSENTIAL SYSTEMS ANALYSIS. São Paulo: Makron Books, 1991. 567p.
Referências Web1. Software no plural: http://198.106.73.59/01/01_soft.htm 2. HEUMANN , J. Introduction to business modeling using the
Unified Modeling Language (UML), IBM, 2003 in: http://www.ibm.com/developerworks/rational/library/360.html.