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 Takaiotakai@gmail.com

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.

Pós-GraduaçãoEngenharia de Software

Prof. Osvaldo Kotaro Takaiotakai@gmail.com

Obrigado!