Read this post in: de_DEen_USes_EShi_INid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

Relier les processus métiers aux exigences logicielles : une étude de cas Visual Paradigm sur la transition de BPMN vers les cas d’utilisation

Introduction

Dans le paysage numérique en constante évolution d’aujourd’hui, les organisations font face à un défi persistant : garantir que les efforts de développement logiciel restent étroitement alignés sur les opérations métiers réelles. Trop souvent, l’élaboration des exigences se déroule en isolation par rapport à la modélisation des processus métiers, ce qui conduit à des systèmes incapables de répondre aux flux de travail du monde réel ou de fournir la valeur attendue aux utilisateurs finaux. Cette étude de cas explore une méthodologie éprouvée pour combler cet écart en effectuant une transition des diagrammes Business Process Model and Notation (BPMN) vers des modèles de cas d’utilisation UML, grâce à l’environnement intégré de modélisation de Visual Paradigm.

À travers un exemple concret impliquant une entreprise de livraison d’eau distillée, nous montrons comment les analystes métiers et les concepteurs de systèmes peuvent collaborer pour extraire directement des exigences logicielles pertinentes à partir de processus métiers validés. Cette approche utilise la fonctionnalité Model Transitor de Visual Paradigm pour établir des liens de traçabilité entre les tâches métiers et les cas d’utilisation du système, garantissant que chaque fonction logicielle sert un objectif métier documenté. Que vous soyez un analyste métier cherchant à communiquer plus efficacement les exigences ou un architecte système visant à concevoir des solutions véritablement adaptées aux besoins opérationnels, cette étude de cas fournit des pistes concrètes pour aligner la modélisation des processus métiers avec l’ingénierie des exigences logicielles.

Bridging Business Processes to Software Requirements: BPMN-to-Use Case Transition

Comprendre les fondations : les diagrammes BPMN et les diagrammes de cas d’utilisation

Qu’est-ce que le BPMN et le BPD ?

BPMNfournit aux analystes métiers un ensemble de notations graphiques pour modéliser les processus métiers. Il a été initialement développé par leInitiative de gestion des processus métiers (BPMI) et est actuellement entretenu par leGroupe de gestion des objets (OMG). L’une des motivations du développement du BPMN est de fournir un langage graphique commun aux personnes occupant des rôles différents, provenant de pays différents et/ou parlant des langues différentes, afin qu’elles puissent comprendre le même processus métier sans barrières.

BPD, abréviation deDiagramme de processus métier, est le diagramme dans lequel un processus métier est modélisé à l’aide du BPMN. Il s’agit d’un diagramme ressemblant à un organigramme qui représente le flux du processus, les participants impliqués et les échanges de messages entre eux. Les analystes métiers dessinent des BPD pour modéliser la manière dont différents participants collaborent afin d’atteindre un objectif métier. Une fois le modèle métier terminé et validé auprès des utilisateurs finaux, un analyste système peut alors commencer à planifier le système.

Le diagramme suivant est un BPD simple du processus d’inscription pour une organisation. Il couvre la plupart des notations de modélisation typiques que vous verrez. Examinons-le.

BPD sample

Notation Description
BPMN pool Pool – Représente un participant au sein d’un processus. Dans le BPMN, les pools et les lignes sont utilisés pour représenter des participants. Une ligne est contenue dans un pool afin de modéliser une sous-partition du pool parent.
BPMN start event Événement de départ – Le début d’un processus. Des déclencheurs peuvent être définis pour indiquer aux lecteurs dans quelles situations le processus sera déclenché. Par exemple, lorsqu’un e-mail est reçu, lorsqu’il est lundi matin, ou lorsqu’une erreur s’est produite.
BPMN task Tâche – Une activité atomique que des participants désignés (modélisés par pool/ligne) peuvent effectuer. Les tâches et d’autres objets de flux sont reliés pour former un flux de travail métier complet.
BPMN end event Événement de fin – La fin d’un processus. Un résultat peut être défini pour indiquer aux lecteurs ce qui se produira lorsque le processus se terminera. Par exemple, émettre un signal ou produire une erreur.

Qu’est-ce qu’un diagramme de cas d’utilisation ?

La modélisation des cas d’utilisation fait référence à la technique de capture des exigences utilisateur de haut niveau à l’aide d’undiagramme de cas d’utilisation UML. Un modèle de cas d’utilisation est conçu pour les concepteurs logiciels ou système, et non pour les professionnels métiers.

06-use-case-diagram-sample

Il existe trois éléments principaux dans un diagramme de cas d’utilisation.

Notation Description
UML use case Cas d’utilisation – Chaque cas d’utilisation représente un objectif utilisateur, c’est-à-dire un objectif que l’utilisateur du système souhaite atteindre. Notez que les cas d’utilisation ne peuvent être utilisés que pour montrer ce que l’utilisateur souhaite faire, et non ce que le développeur doit développer, bien qu’ils puissent être identiques dans certains cas. Si vous souhaitez documenter ou modéliser les fonctions impliquées dans un cas d’utilisation, vous pouvez utiliser l’outil de flux d’événements, ou élaborer un cas d’utilisation avec undiagramme de séquence / diagramme d’activité. Gardez à l’esprit que la modélisation des cas d’utilisation vise à modéliser ce que l’utilisateur souhaite accomplir.
UML actor Acteur – Un utilisateur du système. Le mot « utilisateur » ici n’est pas limité aux êtres humains. Il peut s’agir d’un système qui interagit avec notre système afin de remplir un objectif commercial spécifique.
UML communication link Lien de communication/Association – Connecte un acteur à un cas d’utilisation pour indiquer l’accès au système par l’acteur. Chaque lien de communication implique une séquence de transactions entre l’acteur et le système.

Passer du processus métier aux exigences du système

Le lien stratégique

Bien que les diagrammes de processus métier (BPD) et les diagrammes de cas d’utilisation ne devraient pas nécessairement s’appuyer l’un sur l’autre, ils peuvent être liés de manière complémentaire. En général, nous développons des logiciels pour automatiser ou optimiser certains flux de processus métiers. Grâce à un BPD, vous pouvez comprendre comment les participants collaborent et qui est responsable de quoi, ce qui nous aide à identifier les fonctions dont ils ont besoin que le système soutienne. Les fonctions système (flux de travail ou processus métier) que l’utilisateur souhaite peuvent être modélisées à l’aide de cas d’utilisation, puis développées par l’équipe. En conséquence, on peut dire qu’un BPD vous aide à identifier les cas d’utilisation pour un système en cours de développement.

Visual Paradigm est un outil de modélisation visuelle qui permet de passer de la modélisation du processus métier à la modélisation des cas d’utilisation (des exigences métiers aux exigences d’application) en établissant des liens de traçabilité entre les deux modèles grâce à sa fonctionnalité de transiteur de modèle. Nous avons besoin de cette traçabilité pour les raisons suivantes :

  • Nous pouvons garantir que le système s’inscrit dans une utilisation du monde réel en étudiant la partie du flux de processus impliquée par un cas d’utilisation.

  • Pour répondre à des questions telles que « Pourquoi avons-nous besoin de cette fonction (du système) ? » en remontant la partie du processus d’où provient un cas d’utilisation.

  • Pour répondre à des questions telles que « Une opération spécifique a-t-elle déjà été mise en œuvre ? » en remontant du BPD au diagramme de cas d’utilisation.

Distinctions clés : BPD vs. Diagramme de cas d’utilisation

Certaines personnes peuvent penser qu’un diagramme de cas d’utilisation ressemble à un BPD, mais ils diffèrent considérablement en termes de notations et de buts. Souvenez-vous que BPMN est conçu pour les professionnels métiers, tandis qu’un diagramme de cas d’utilisation est destiné aux analystes système ou aux développeurs système. Ils ont des objectifs différents et perçoivent une entreprise sous deux angles distincts. C’est pourquoi, dans la section précédente, j’ai résumé la relation entre un BPD et un diagramme de cas d’utilisation en disant « un BPD vous aide à identifier les cas d’utilisation ». Un BPD ne peut vous donner que des indices lors de l’identification des cas d’utilisation. Il n’existe aucune règle stipulant que chaque tâche présente dans un BPD est équivalente à un cas d’utilisation. Toutefois, nous pouvons approfondir un processus métier en utilisant un cas d’utilisation pour automatiser une fonction par le système cible.

Étude de cas : La société True Aqua eau distillée

Contexte métier et description du processus

La société True Aqua eau distillée est un jeune fournisseur d’eau distillée dans la ville. Elle vend de l’eau distillée pour une utilisation commerciale et domestique. La description suivante est textuelle du processus de livraison d’eau.

Pour commander de l’eau distillée, les clients appellent soit le numéro d’assistance pour les commandes, soit nous envoient un courriel. Actuellement, 90 % des commandes proviennent d’appels téléphoniques, tandis que 10 % sont passées par courriel. L’assistant du service client qui reçoit la commande vérifie si le client est déjà existant ou s’il s’agit d’un nouveau client. Si le client n’a jamais commandé auparavant, l’assistant du service client créera un compte client pour lui avant de procéder à la livraison de l’eau.
La livraison de l’eau distillée a lieu une fois par semaine, tous les mercredis. Ainsi, chaque mercredi matin, l’assistant du service client transmettra les commandes au Département Logistique pour la livraison. Dès que le responsable du Département Logistique a reçu les commandes, il organisera la livraison en attribuant des travailleurs à différentes commandes, en imprimant et en affichant l’horaire. Les travailleurs reçoivent les appels et livrent l’eau aux clients en conséquence.

Un modèle de processus métier a été créé sur la base de la description. Maintenant, vous êtes chargé de développer un système informatique afin d’optimiser l’ensemble du processus. La première chose que vous devez faire est de développer un modèle de cas d’utilisation. Avec l’aide du BPD, essayez de développer un diagramme de cas d’utilisation.

Processus de transition étape par étape

  1. TéléchargerDistilled Water Delivery.vpp. Vous pouvez également trouver ce fichier en bas de ce tutoriel.

  2. Ouvrez le fichier .vpp téléchargé dans Visual Paradigm. Pour ouvrir un projet, sélectionnezProjet > Ouvrirdans la barre d’outils de l’application.

  3. Ouvrez le BPDProcessus de commande d’eau distillée. Étudiez attentivement le flux du processus.

    BPD sample

  4. Le processus commence lorsque le client passe une commande. Ici, nous pouvons envisager un cas d’utilisation – Passer une commande. Ce cas d’utilisation aidera à automatiser le processus en fournissant une interface pour que le client passe une commande sans l’aide d’un assistant du service client, aidera à vérifier l’identité du client et à créer un compte si le client n’existe pas. Cliquez avec le bouton droit surPasser une commande et sélectionnez Éléments associés > Transférer vers un nouveau cas d’utilisation… dans le menu contextuel.

    Create use case from task

  5. Cela affiche la fenêtre Transférer l’élément du modèle où vous pouvez sélectionner le modèle dans lequel placer le cas d’utilisation et l’acteur, et les renommer. Dans ce cas, nous sommes satisfaits des noms du cas d’utilisation et de l’acteur. Maintenons-les inchangés. Cliquez sur OK.

    Transit model element
    Cela crée un nouveau diagramme de cas d’utilisation dans UeXceler.
    Use case diagram formed

  6. Retournez au BPD.

  7. Examinons la tâche Créer un compte client. Dans le processus métier, l’assistant service client doit créer un compte pour chaque nouveau client. Dans le nouveau système, cela peut être une partie du cas d’utilisation Passer une commande ou un cas d’utilisation distinct déclenché manuellement par l’assistant service client. Dans une situation réelle, vous devez clarifier ce type de doute avec le donneur d’ordre, car un modèle de cas d’utilisation incorrect entraînera le développement de fonctions qui ne correspondent pas aux attentes des utilisateurs. Dans cet exemple, supposons que l’utilisateur souhaite que la tâche Créer un compte client soit une tâche effectuée par l’assistant service client. Créons un cas d’utilisation à partir de cette tâche. Cliquez avec le bouton droit sur Créer un compte client et sélectionnez Éléments associés > Transférer vers un nouveau cas d’utilisation… dans le menu contextuel.

    Create use case from task

  8. Encore une fois, nous sommes satisfaits du nom du cas d’utilisation et de l’acteur. Laissez tout tel quel dans la fenêtre Transférer l’élément du modèle inchangé. Cliquez sur OK. Le diagramme de cas d’utilisation est mis à jour avec un nouveau cas d’utilisation et un nouvel acteur. Examinons-le.

    New use cases created

  9. Retournez au BPD. Passons au sous-processus Organiser la livraison. Le responsable du département Logistique peut utiliser le système pour planifier les livraisons et informer les ouvriers de livrer l’eau. Par conséquent, il s’agit également d’un cas d’utilisation du système. Cliquez avec le bouton droit sur le sous-processus Organiser la livraisonet sélectionnerÉléments associés > Transférer vers un nouveau cas d’utilisation… depuis le menu contextuel.

  10. Cochez l’acteur « Gérant » dans leÉlément de transit du modèle fenêtre. Si nous conservons le nom de l’acteur commeGérant, cela est ambigu dans le modèle de cas d’utilisation car il peut y avoir de nombreux départements avec de nombreux gérants différents dans l’entreprise. Par conséquent, renommez l’acteur enGérant du département logistique.

    24-rename-actor

  11. Cliquez surOK. Le diagramme de cas d’utilisation est mis à jour.

    Use case diagram updated

  12. Retournez au BPD. La tâche finaleLivrer de l’eau est une tâche qui ne peut être effectuée que par un humain et n’a rien à voir avec l’interaction du système. Par conséquent, nous n’avons pas besoin d’en créer un cas d’utilisation.

  13. Supposons que le directeur régional souhaite que le système prenne en charge une nouvelle fonction permettant de générer un rapport affichant les statistiques sur les commandes. Cette fonction peut l’aider à revue et affiner la stratégie marketing. Bien que cette fonction n’ait pas été modélisée dans le modèle de processus métier, nous pouvons la dessiner directement dans le diagramme de cas d’utilisation. Ouvrez le diagramme de cas d’utilisation. Dessinez un acteurDirecteur régional. Créez un cas d’utilisationGénérer un rapport statistique à partir de celui-ci avec une association entre les deux.

    Use case diagram updated

  14. Disons que le client souhaite autoriser le client à visualiser les relevés de facturation et à annuler les commandes. En outre, le client souhaite autoriser le gérant du département logistique à imprimer un rapport logistique. Dessinez les cas d’utilisation respectivement.

    Use case diagram updated

  15. Mettons en ordre le diagramme.

    Complete use case diagram

  16. La relation de transition vous permet de retracer le modèle de processus métier à partir du modèle de cas d’utilisation (et inversement). Essayons. Placez le pointeur de la souris sur le cas d’utilisationPasser une commande cas d’utilisation.

    Mouse over use case

  17. Cliquez sur leRessource de transit du modèle située dans le coin inférieur droit de la forme. SélectionnezTransition à partir de > Processus de commande d’eau distillée <.Passer une commandedu menu contextuel.

    Open task from use case
    Cela ouvre le BPD avec la tâche Passer une commandesélectionnée.
    Task selected

Conclusion

Cette étude de cas démontre que passer des modèles de processus métier BPMN aux diagrammes de cas d’utilisation UML n’est pas simplement une opération technique : c’est une approche stratégique pour garantir que les solutions logicielles apportent une véritable valeur métier. En utilisant la fonctionnalité Model Transitor de Visual Paradigm, les équipes peuvent établir une traçabilité claire entre les activités métiers et les exigences système, créant ainsi une compréhension partagée entre les parties prenantes métier et les équipes de développement.

L’exemple de la société True Aqua d’eau distillée illustre plusieurs principes essentiels : toutes les tâches métiers n’ont pas besoin d’un cas d’utilisation correspondant ; la clarification des parties prenantes est indispensable lors de la cartographie des processus vers les fonctions système ; et de nouvelles exigences peuvent être ajoutées directement aux modèles de cas d’utilisation, même si elles ne sont pas présentes dans le processus métier initial. Plus important encore, la traçabilité bidirectionnelle offerte par l’outil permet aux équipes de répondre à des questions fondamentales sur la justification des exigences et l’état d’implémentation tout au long du cycle de vie du projet.

Les organisations adoptant cette méthodologie peuvent s’attendre à une réduction de l’ambiguïté des exigences, à une meilleure alignement des parties prenantes, et à des systèmes logiciels qui reflètent plus fidèlement les réalités opérationnelles. Alors que les processus métiers évoluent continuellement, le maintien de cette traçabilité garantit que les améliorations du système restent ancrées dans des besoins métier validés, plutôt que dans des demandes de fonctionnalités spéculatives. L’intégration de fonctionnalités alimentées par l’IA dans les outils de modélisation modernes accélère davantage cette transition, permettant aux équipes de se concentrer sur l’analyse stratégique plutôt que sur les tâches manuelles de création de diagrammes.


Références

  1. Comment l’IA et le traitement du langage naturel révolutionnent la génération de BPMN à partir de texte pour la modélisation des processus d’entreprise: Explore comment le traitement du langage naturel transforme les descriptions textuelles métier en modèles BPMN conformes pour la documentation des flux de travail d’entreprise.
  2. Maîtrise de la modélisation des processus métiers BPMN 2.0 avec les outils d’IA de Visual Paradigm: Revue complète des capacités de modélisation BPMN améliorées par l’IA pour créer des spécifications exécutables de processus métiers.
  3. Fonctionnalité de transformation du cas d’utilisation en diagramme d’activité: Détaille le flux automatisé pour transformer des cas d’utilisation de haut niveau en diagrammes d’activité détaillés, destinés à la planification de mise en œuvre.
  4. Mise à jour du générateur de diagrammes de processus métier BPMN avec IA: Notes de version couvrant les fonctionnalités améliorées de l’IA pour convertir des descriptions narratives de processus en diagrammes BPMN structurés.
  5. Fonctionnalité des diagrammes BPMN et outils: Documentation officielle des outils de modélisation BPMN 2.0, du support de notations et des fonctionnalités de collaboration au sein de Visual Paradigm.
  6. Démonstration de restructuration de processus conversationnelle: Démonstration vidéo de l’utilisation de commandes d’assistant conversationnel IA pour modifier dynamiquement des diagrammes BPMN à l’aide d’instructions en langage naturel.
  7. Sortie de l’outil d’amélioration des processus métiers avec IA: Annonce des fonctionnalités d’analyse intelligente des flux de travail qui suggèrent des opportunités d’optimisation basées sur des indicateurs de performance du processus.
  8. Fonctionnalité des diagrammes BPMN et outils: Guide de référence pour les fonctionnalités avancées de BPMN, y compris la décomposition des sous-processus et la génération de modèles exécutables.
  9. Outil d’amélioration des diagrammes de cas d’utilisation avec IA: Outil web basé sur l’IA pour améliorer automatiquement les modèles de cas d’utilisation de base avec des relations d’inclusion/extension appropriées et une gestion des exceptions.
  10. Guide complet de la modélisation des cas d’utilisation avec l’écosystème d’IA de Visual Paradigm: Analyse indépendante des techniques assistées par l’IA pour l’élaboration des exigences et la spécification des cas d’utilisation.
  11. Du processus métier aux cas d’utilisation : tutoriel (PDF): Guide étape par étape téléchargeable pour passer des modèles BPMN aux diagrammes de cas d’utilisation UML avec traçabilité.
  12. Démonstration de génération automatique des limites: Tutoriel vidéo montrant la création pilotée par l’IA des limites du système, des acteurs et des cas d’utilisation principaux à partir des énoncés de portée du projet.
  13. Démonstration de raffinement intelligent des relations: Démonstration de l’analyse par IA qui identifie et suggère des relations include/extend appropriées entre les cas d’utilisation.
  14. Fonctionnalité de l’outil de raffinement des diagrammes de cas d’utilisation par IA: Page produit détaillant les capacités d’analyse et de raffinement automatiques des relations entre les cas d’utilisation.
  15. Démonstration de génération de flux de travail en aval: Vidéo montrant la génération automatique des diagrammes d’activité et de séquence à partir de spécifications de cas d’utilisation validées.
  16. Visual Paradigm sur TheirStack: Profil technologique et aperçu de l’adoption des outils de modélisation Visual Paradigm dans les environnements d’entreprise.
  17. Fonctionnalité du générateur de rapports de diagrammes de cas d’utilisation par IA: Outil de conversion des scripts PlantUML et des modèles de cas d’utilisation en documents professionnels pour les parties prenantes.
  18. Documentation du point d’extension du flux d’événements: Référence technique pour la documentation de scénarios de cas d’utilisation détaillés avec préconditions, postconditions et flux alternatifs.
  19. Publication de l’atelier de modélisation de cas d’utilisation piloté par l’IA: Annonce de publication des capacités intégrées d’IA dans la modélisation des cas d’utilisation, y compris l’analyse de requêtes en langage naturel.