Examen de génie logiciel avancé : 1. BPM et BPMN

1. Réponse a : son trait épais
La norme ne définit ni couleur ni position. Seul le trait distingue les trois familles : fin pour le début, double pour l'intermédiaire, épais pour la fin. Un diagramme en noir et blanc reste parfaitement lisible.

2. Réponse b : deux éléments de pools différents
Le flux de message matérialise ce qui circule entre participants distincts. À l'intérieur d'un pool, y compris entre deux couloirs, on emploie des flux de séquence.

3. Réponse b : repart dès qu'une branche entrante arrive
Le XOR ne synchronise pas. Il laisse passer chaque jeton qui se présente. C'est le AND qui attend tout le monde, et le OR qui attend les branches effectivement activées.

4. Réponse b : ne sont pas évaluées : toutes les branches partent
Le AND ne lit aucune condition : il active toutes ses sorties. Écrire une condition sur une passerelle parallèle est un contresens, et c'est une faute classique.

5. Réponse b : deux pools distincts
Deux entités autonomes, qui peuvent refuser de coopérer, sont deux pools. Les couloirs servent à découper les rôles d'une même organisation.

6. Réponse b : un verbe à l'infinitif suivi d'un objet, par exemple « Émettre la facture »
Une tâche est une action. « Facture » ne dit pas ce qu'on en fait, et une question appartient à une passerelle, pas à une tâche.

7. Réponse b : par l'OMG en janvier 2011
BPMN 2.0 est une spécification de l'Object Management Group, publiée en janvier 2011. C'est elle qui a introduit le format d'échange XML rendant les diagrammes exécutables.

8. Réponse b : attend uniquement les branches qui ont été activées en amont
C'est la difficulté du OR : il doit savoir lesquelles de ses branches ont été activées à la division pour n'attendre que celles-là.

9. Réponse b : d'échanger un modèle entre outils, et de le faire exécuter par un moteur
Le XML rend le modèle portable d'un outil à l'autre et exploitable par un moteur d'exécution. Il ne génère pas d'application : il décrit l'enchaînement, pas le métier.

10. Réponse b : plusieurs terminaisons du processus pour une seule instance
Chaque branche poursuit son chemin jusqu'à un événement de fin. Sur un moteur, l'instance se termine autant de fois qu'il y a de branches : deux factures, deux notifications. La plupart des outils ne le refusent pas : ils l'exécutent.

1. Fautif. Une tâche se nomme par un verbe à l'infinitif suivi d'un objet. « Demande de congé » est un nom : on ne sait pas qui fait quoi.

Correction : « Déposer la demande de congé », ou « Enregistrer la demande » selon l'acteur.

2. Fautif. Une passerelle parallèle n'évalue aucune condition : elle active toutes ses sorties. Porter une condition dessus est un contresens.

Correction : remplacer par une passerelle exclusive, avec les conditions « solde suffisant » et « solde insuffisant » sur les deux sorties.

3. Fautif. Un flux de séquence ne franchit jamais la frontière d'un pool. L'entreprise ne commande pas l'activité du salarié, et réciproquement.

Correction : un flux de message, en pointillés.

4. Fautif. Tout chemin doit se terminer par un événement de fin. Sans lui, on ignore si l'instance se termine ou si elle reste pendante.

Correction : ajouter un événement de fin « demande refusée » après la tâche de notification.

Barème : 1 point par point, dont 0,5 pour l'identification et 0,5 pour la correction.

1. Les deux temps.

Temps de traitement : 20 + 15 + 10 + 5 = 50 minutes.

Attentes : 2 h + 6 h + 30 min = 8 h 30, soit 510 minutes.

Temps de cycle = 50 + 510 = 560 minutes, soit 9 h 20.

2. Efficacité.

50 / 560 = 0,0892857… ≈ 8,9 %

Autrement dit, sur une demande qui met plus de neuf heures à traverser l'entreprise, moins de neuf pour cent du temps est consacré à un travail réel. Le reste, c'est de l'attente.

3. L'effet de la proposition.

Le temps de cycle passe de 560 à 552 minutes : un gain de 8 minutes, soit 1,4 % du total.

Le gisement n'est pas dans le traitement, il est dans les attentes.

Les six heures d'attente avant la validation du chef d'agence pèsent quarante-cinq fois plus lourd que les huit minutes gagnées sur la saisie. S'attaquer à cette file, par une délégation sur les petits montants, ou une validation groupée à heure fixe, rapporterait sans commune mesure.

C'est l'apport central du BPM : on optimise ce que la mesure désigne, pas ce que l'intuition suggère.

Barème : 1,5 pour la question 1, 1 pour la question 2, 1,5 pour la question 3 dont 1 pour le commentaire.

1. L'erreur.

La passerelle parallèle qui divise n'est refermée par aucune passerelle parallèle.

Les deux branches, « Commander au fournisseur » et « Informer le client », rejoignent directement la tâche « Installer la pièce ». La règle violée est celle de l'appariement : ce qui divise doit refermer, avec une passerelle du même type.

Ce qu'un moteur en ferait : le AND crée deux jetons. Chacun poursuit son chemin et déclenche « Installer la pièce ». L'installation serait donc lancée deux fois, et l'événement de fin atteint deux fois pour une seule demande. En pratique : deux ordres d'intervention, deux lignes de facturation, un technicien qui se déplace pour rien.

Plus grave encore, la première branche à arriver déclenche l'installation immédiatement : le technicien partirait poser une pièce qui n'est pas encore livrée, puisque « Informer le client » prend 10 minutes quand la commande en prend trois jours.

2. Le diagramme corrigé.

Deux points de rigueur attendus : le AND de fermeture, qui attend réellement les deux branches ; et le XOR de convergence, qui ne doit surtout pas être un AND, sinon le processus attendrait la branche « non » alors qu'elle n'a jamais été activée, et resterait bloqué.

3. Le délai moyen.

Deux chemins, de probabilités connues.

Sur la branche parallèle, la durée est celle de la branche la plus longue, puisque le AND attend les deux : 3 jours = 4 320 minutes contre 10 minutes. C'est le point que le barème sanctionne : additionner 4 320 et 10 serait une faute de lecture du AND.

0,60 × 50 + 0,40 × 4 370 = 30 + 1 748 = 1 778 minutes

Soit environ 29 h 38 min, ou 1,24 jour.

4. Descendre sous 24 heures.

L'objectif de 24 h vaut 1 440 minutes. Il faut donc gagner au moins 338 minutes sur la moyenne.

Première piste : constituer un stock des pièces les plus demandées. Si la part des pièces en stock passe de 60 % à 75 % :

0,75 × 50 + 0,25 × 4 370 = 37,5 + 1 092,5 = 1 130 minutes, soit 18 h 50

L'objectif est atteint. Coût : de la trésorerie immobilisée et un risque d'obsolescence sur les pièces qui ne tournent pas.

Seconde piste : réduire le délai fournisseur de 3 jours à 1 jour, par un accord de livraison express :

0,60 × 50 + 0,40 × (5 + 1 440 + 45) = 30 + 596 = 626 minutes, soit 10 h 26

Le gain est bien plus important. Coût : un surcoût par commande, à négocier.

La seconde piste est la plus efficace : elle s'attaque à la durée qui domine la moyenne.

Le raisonnement à tenir : les 4 320 minutes de commande pèsent 97 % du chemin le plus long. Agir sur la fréquence des commandes (première piste) ne change pas leur durée ; agir sur leur durée (seconde piste) améliore tous les cas concernés. On retiendrait donc la négociation fournisseur, en réservant le stock aux quelques références qui tournent le plus.

Une réponse qui combine les deux, chiffres à l'appui, vaut la note maximale.

5. L'indicateur.

Le délai moyen entre l'événement « pièce manquante » et l'événement « pièce posée », mesuré sur toutes les instances closes du mois, suivi mois par mois.

Deux précautions valent des points. Il faut suivre aussi la médiane ou un percentile, car une poignée de commandes très longues suffit à déformer la moyenne. Et il faut relever la proportion de pièces trouvées en stock, sans quoi on ne saura pas distinguer l'effet de la négociation fournisseur de celui d'une variation saisonnière des demandes.

Barème : 1,5 pour la question 1, 1,5 pour la question 2, 1,5 pour la question 3, 2 pour la question 4, 0,5 pour la question 5.