1. O documento discute a importância da modelagem dos processos de negócio antes da definição de requisitos de sistemas de software. 2. Apesar da evidência de que entender os processos de negócio é essencial, a maioria das empresas de desenvolvimento de software negligencia esta etapa. 3. O palestrante irá apresentar sua opinião sobre o estado atual desta área e expectativas futuras.

1. Pós-Graduação
Engenharia de Software
Modelagem dos Processos de Negócio para a
Definição de Requisitos de Sistemas Software
Prof. MSc. Osvaldo Kotaro Takai
otakai@gmail.com

2. 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. 3
Problema do Desenvolvimento
de Software

4. 4
As Grandes Promessas

5. 5
As Grandes Promessas
Matam até lobisomem!

6. 6
As Grandes Decepções

7. 7
As Grandes Decepções

8. 8
Imaturidade, Insanidade ou
Loucura?
Desenvolvemos
softwares que devem
apoiar processos de
negócio, mas sem ao
menos conhecê-los!

9. 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.
P
S

10. 10
Princípios do Manifesto Ágil
1. 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. 11
Paradoxo de Cobb

12. 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. 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. 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. 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. 16
A Bola da Vez
 BPMS
 BPMN
 SOA
 WebServices
 Zachman Framework
 The Open Group Architecture
Framework (TOGAF)
 DoDAF

17. 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. 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. 19
Eventos
ANÁLISE DOS EVENTOS Externo Temporal
Nº Evento Esperado
Não-
Esperado
Relativo 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. 20
Eventos X Processos
ANÁLISE DOS EVENTOS Externo Temporal
Nº Evento Esperado
Não-
Esperado
Relativo 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. 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. 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ável
Criada
Aprovada
Não-Aprovada
Em-Atendimento
Atendida
Cancelada

23. 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. 24
Business Use-Case
uc Business Process Mo...
Cliente
Anotar Encomenda
act Activity
Funcionário
Receber Encomenda
:Cliente
:Cliente
:Encomenda
:Livro
encomenda confirmação
uc Business Use-Case ...
(from Business Use-Case)
Anotar Encomenda
Anotar Encomenda

25. 25
BPMN
BPMN 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
Registrar
Pagamento
Livraria envia
livros
Cliente efetua
pagamento
Enviar Livros
Cliente
recebe
livros
Fechar Pedido
Cliente
cancela
pedido
Trater
Cancelamento do
Pedido pelo Cliente
Cliente
reclama não
recebimento
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 de
entrega
Livraria
solicita
posição
Livraria envia
situação do
pedido
Corrigir Falha na
Entrega de Livros
Livraria
informa
cancelamento
da venda
BPMN Receber Pedido
Recepcionista
Cadastrar Cliente
Registrar Pedido
Recepcionar Pedido
Pedido
Cliente
Pedido
Cliente não
cadastrado

26. 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. 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 Web
1. 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.

28. Pós-Graduação
Engenharia de Software
Prof. Osvaldo Kotaro Takai
otakai@gmail.com
Obrigado!