Discussion :

[Yveke]

Bonjour,

Je suis nouveau sur ce forum alors d'abord bonjour à tous !!
J'aimerais obtenir plus de précisions sur le business use case model (ou plus généralement le business modeling) définit par le RUP.
J'ai rédigé la modélisation basé uniquement sur les processus d'une entreprise (use case, activity diag, seq, class, ...), peut on considérer cela comme du business modeling (particulièrement au niveau use case ?). Et j'ai une autre itération basée uniquement sur les "requirements" qui enrichit ce premier modèle.
Donc es ce que ma première itération est un business model ou es ce encore autre chose de plus global.
Merci d'éclairer ma lanterne !

Yves.

[ego]

Ce que tu as fait n'est pas à proprement parlé du BPM.
Le BPM vise avant tout à modéliser les processus métier. Dans RUP, on identifie un processus métier avec un Business Use Case. Ce BUC est donc déclenché par des business actors et est exécuté au sein de l'entreprise par des business workers.
Lorsque tu décris un BUC, via un diag d'activité par exemple, chaque activité est une activité "métier", par exemple : rentrer en contact avec le client, définir les clauses du contrat, obtenir l'accord du service juridique, obtenir l'accord du client,...
Parmis ces activités, l'entreprise peut décider d'en informatiser certaines.
C'est à ce moment que les informaticiens interviennent et vont, vis-à-vis de l'application à réaliser, identifier des use cases. Ces UC seront déduit, voir identiques aux activités informatisées et décrites dans les BUC. La différence sera que dans la description du UC, même s'il est "identique" à une activité déjà décrite, on parlera d'interaction entre l'acteur et l'application. Les détails seront sûrement plus fins que ceux donnés au niveau BPM. Ces détails pourront même être un peu différent car le fait d'informatiser l'activité donne de nouvelles perspectives.

[Yveke]

Tout d'abord un grand merci à toi ego pour tes commentaires et tes conseils !

Donc si j'ai bien compris le 'business use case diagram' est plus (+) centré sur une interaction de l'entité modélisée avec le 'monde extérieur' comme avec les clients ou les fournisseurs que sur le processus de production en tant que tel. Puis le monde de l'informatique procède à une phase de sélection des use case pertinents pour l'informatique et de 'raffinage' de ceux-ci. On a donc en quelque sorte une double itération à ce niveau !?

De plus quel serait, selon toi, le statut d'un use case diagram basé uniquement sur le processus de production et de celui basé uniquement sur les intéractions homme - système informatique que j'ai (peut être abusivement) nommé use case basé sur les requirements.

Tu connais une étude de cas (livre, net, ...) où l'on développe un business use case diagram, etc.

Encore un tout grand merci d'avance.

Yves.

[ego]

Les Business Use Cases sont dans un premier temps exprimés, comme le sont les use cases, en terme de relation avec l'utilisateur du système. Sauf qu'à ce niveau le système c'est ton entreprise.
Ensuite, comme avec les UC, les BUC sont décrits en termes d'activités. Je ne sais pas si ce n'est finalement pas ce que tu entends par "production" !? Si c'est bien cela, quand on décrit un BUC, comme tu le ferais en analyse et conception avec un UC, on va décrire la "production" du BUC par l'entreprise; en termes d'activités métier. Ensuite, on attachera des business workers à ces activités. Certaines activités seront désignées comme devant être automatisables par les gens du métier et non par les gens de l'informatique. On pourra aussi décider d'informatiser certains business workers et ainsi remplacer des gens par des "robots".

Quand on ne fait pas de BPM, donc pas de BUC, on part directement sur les UC. En fait, ces UCs sont des activités métiers que tu décris mais qui auraient dû être déjà décrite par une modélisation des processus métier, tout au moins de manière macro.
Probablement aussi que tes UC s'enchainent dans le contexte d'un BUC non décrit ! C'est d'ailleurs une erreur classique que de modéliser des enchainements de UCs dans un diagramme de UC. Vis-à-vis d'une application, les UCs ne s'enchainent pas. Si tu éprouve le besoin de décrire l'enchainement de UCs c'est parce que tu as besoin d'expliquer à tes utilisateurs comment ils travaillent !!! = tu essayes de faire un BUC.

[Yveke]

Ok, j'ai compris, en fait mon premier use case correspond d'après moi à un BUC ! Je te remercie une nouvelle fois pour toutes les infos.

Encore une petite question : peut on mélanger des use case stéréotypés business et des use case tradinionnels dans un même diagramme ?
Merci.

Yves.

[ego]

Uniquement pour y identifier des liens de dépendance de type <<trace>> (dépendance stéréotypée "trace") depuis le UC vers le BUC

[Yveke]

Merci pour toutes les infos ego !

Yves.