HEMO-MIXER - Automate de prélèvement

Présentation au sujet: "HEMO-MIXER - Automate de prélèvement"— Transcription de la présentation:

1 HEMO-MIXER - Automate de prélèvement
Ingénierie système - Sysml Exemple HEMO-MIXER Automate de prélèvement Séminaire académique L’HEMO-MIXER a été utilisé par l’équipe national chargé de travailler sur IS et Sysml.

2 Ingénierie système - Boite noire – Boite blanche
Quel processus ? 1-Processus de définition des besoins PPS 2-Processus d’analyse des exigences 3-Processus de conception de l’architecture Qui intervient ? maître d'ouvrage (MOA) maître d'œuvre (MOE) Suivant quel point de vue? Nous avons En IS nous avons 3 processus, 2 intervenants et 2 points de vue ? Se pose l’interrogation de qui fait quoi et à quel moment ? Nous allons nous poser le problème en IS pour chaque processus de qui intervient et suivant quel point de vu ?

3 Représentant des utilisateurs du système
Ingénierie systèmes - Boite noire – Boite blanche 1-Processus de définition des besoins PPS Maître d’Ouvrage Représentant des utilisateurs du système C’est au maître d’ouvrage qu’incombe la responsabilité de définir les besoins. Position du système dans son environnement 2-Processus d’analyse des exigences 3-Processus de conception de l’architecture Le premier processus est confié au maitre d’ouvrage par le client. Il a une vision boite noire : place du système dans son environnement.

4 Représentant des utilisateurs du système
Ingénierie systèmes - Boite noir – Boite blanche 1-Processus de définition des besoins PPS 2-Processus d’analyse des exigences 3-Processus de conception de l’architecture Maitre Ouvrage Représentant des utilisateurs du système Au maitre d’ouvrage incombe la responsabilité de définir les besoins. Position du système dans son environnement Maitre d’œuvre Représentant des réalisateurs du système Au maître d’œuvre incombe la responsabilité de concevoir la solution répondant aux besoins du système. Les deux processus suivants sont confiés au maître d’œuvre par le maître d’ouvrage. Il a une vision boite blanche : définir l’architecture interne.

5 Ingénierie systèmes - Boite noir – Boite blanche
1-Processus de définition des besoins PPS 2-Processus d’analyse des exigences 3-Processus de conception de l’architecture Maitre Ouvrage Représentant des utilisateurs du système Au maitre d’ouvrage incombe la responsabilité de définir les besoins. Position du système dans son environnement Maitre d’œuvre Représentant des réalisateurs du système Au maitre d’œuvre incombe la responsabilité de concevoir la solution répondant aux besoins du système. Maitre d’ouvrage et maître d’œuvre doivent s’en tenir chacun à leur rôle. Par exemple : la confusion des rôles entraine des risques de besoin induit par la solution. Il est fondamentale que le maitre d’ouvrage et le maitre d’œuvre s’en tiennent chacun à leur rôle. La confusion des rôles entraine des risques de besoin induit par la solution. On imagine un projet pour lequel le besoin est sans cesse redéfini et pour lequel la solution n’arrive jamais.

6 HEMO-MIXER - Automate de prélèvement
L’HEMO-MIXER est un Automate de prélèvement sanguin. Il est utilisé par les établissements nationaux responsables de la collecte et de la préparation des produits sanguins. Par exemple de l’Etablissement Français du Sang (EFS). L’entreprise Hemopharm est un équipementier médical spécialisée dans le matériel destiné à la collecte de sang. (ne pas dire : Hemopharm liquidation judiciaire 23 septembre 2014) Elle distribue l’Hemo-mixer.

7 Processus de définition des besoins des Parties Prenantes
HEMO-MIXER - Automate de prélèvement Processus de définition des besoins des PPS DBPP1 Définir la mission principale du système Processus de définition des besoins des Parties Prenantes Cycle de vie d’un système Ingénierie système Nous revenons à l’ingénierie Système. L’ingénierie système apparait au début du cycle de vie du système. Pour concevoir le produit, il faut tenir compte de la mission principale du produit : « prélever du sang », mais aussi de l’ensemble du cycle de vie : - Contexte de retrait, contexte de mobilité…

8 Processus de définition des besoins des Parties Prenantes
HEMO-MIXER - Automate de prélèvement Processus de définition des besoins des PPS DBPP1 Définir la mission principale du système Processus de définition des besoins des Parties Prenantes Parties prenantes Toutes les personnes (physiques ou morales) concernées directement ou indirectement par le système dans toutes ses situations de vie … Tout au long de sa vie le système est concerné directement ou indirectement par des personnes physiques ou morales. Ces personnes physiques ou morales sont appelées les partie prenantes. MOA Organisme de norme MOE Organisme collecteur

9 DBPP1 Définir la mission principale du système
HEMO-MIXER - Automate de prélèvement Processus de définition des besoins des PPS DBPP1 Définir la mission principale du système Les collectes peuvent être : Fixes. Mobiles : véhicule spécifique ou au sein d’un lieu public (école, salle des fêtes…) ou privé Une collecte est constituée d’une succession de processus. Le processus principal est celui de prélèvement du sang. Le personnel doit veiller au bon déroulement du prélèvement. Le personnel arrête le don quand le volume de sang maximum à prélever est atteint. Les collectes peuvent être fixes ou mobiles. Une collecte fixe est réalisée dans des centres spécifiques. En revanche, il existe deux méthodes pour effectuer une collecte mobile de dons du sang : utiliser un véhicule spécifique – un camion de collecte – qui se rend sur le lieu de prélèvement, ou mettre en place au sein d’un lieu public (école, salle des fêtes…) ou privé, une structure de collecte pour une journée ou une demi-journée. La collecte du sang est constituée d’une succession de processus dont l’un des principaux est le processus de prélèvement. Dans ce processus, le personnel doit veiller au bon déroulement du prélèvement, c’est-à-dire à la bonne santé du donneur et à la viabilité du sang (risque de coagulation). Enfin le personnel stoppe le prélèvement lorsque le volume de sang maximum à prélever est atteint (ce volume dépendant de la physiologie du donneur).

10 DBPP1 Définir la mission principale du système
HEMO-MIXER - Automate de prélèvement Processus de définition des besoins des PPS DBPP1 Définir la mission principale du système Différents problèmes ont été identifiés dans le processus de collecte risques d’erreurs : trop grande proportion de tâches réalisées par le personnel. temps pour faire un don du sang : trop important. quantité de personnels mobilisés par prélèvement : trop importante. L’HEMO-MIXER doit être repensé pour faciliter le travail du personnel en automatisant la phase de prélèvement pour les tâches réalisées sur la poche de sang prélevé Certains problèmes sont rencontrés au niveau du processus de prélèvement : risques d’erreurs : le personnel doit s’assurer que le prélèvement se déroule bien (bon état du donneur, bon état du sang prélevé, quantité de sang prélevé ne dépassant pas la limite maximum) ; Il a trop de taches. le temps pour faire un don du sang est trop important (immobilisation du donneur pouvant freiner les vocations) ; la quantité de personnel mobilisé par prélèvement est trop importante. L’HEMO-MIXER doit être repensé pour faciliter le travail du personnel en automatisant la phase de prélèvement pour les tâches réalisées sur la poche de sang prélevé

11 DBPP1 Définir la mission principale du système
HEMO-MIXER - Automate de prélèvement Processus de définition des besoins des PPS Expression du besoin initial Système de prélèvement : compact, facile et rapide à mettre en œuvre et autonome en énergie Personnel : Préparer le donneur, mettre en œuvre le système de prélèvement puis de lancer le prélèvement. Surveiller la bonne santé du patient et contrôler la quantité de sang actuellement prélevée. La fin du prélèvement proprement dit s’effectue par le clampage du cathéter. Incident ou fin de prélèvement : le système prévient le personnel qui peut alors entamer la procédure de clôture du prélèvement. Le système de prélèvement devra être compact, facile et rapide à mettre en œuvre et autonome en énergie (absence de câbles d’alimentation au sol). Il devra pouvoir s’adapter à toute poche de sang. Le personnel aura en charge de préparer le donneur, de mettre en œuvre le système de prélèvement puis de lancer le prélèvement. Il surveillera la bonne santé du patient et pourra aussi contrôler la quantité de sang actuellement prélevée. La fin du prélèvement proprement dit s’effectue par le clampage du cathéter. Définition ne pas lire : Clamper, déclamper, autrement dit fermer le circuit, ouvrir le circuit.  Lorsqu’un incident survient ou que le prélèvement est terminé, le système prévient le personnel qui peut alors entamer la procédure de clôture du prélèvement.

12 Mission principale du système
DBPP1 Définir la mission principale du système HEMO-MIXER - Automate de prélèvement Processus de définition des besoins des PPS Mission principale du système Finalité Problèmes La mission provient d’une finalité. Nous pouvons décrire la mission principale du système. La finalité permet de justifier le besoin de réaliser, améliorer le système. Le problème est issu directement des constats précédents. La mission : le système rend un ensemble de service, ici complémentaire du service principal. Le système doit satisfaire la mission. « Satisfy » est une relation de traçabilité. Mission Système Le système doit satisfaire la mission. Diagramme des besoins (RD)

13 DBPP2 Définir le contexte du système
HEMO-MIXER - Automate de prélèvement Processus de définition des besoins des PPS DEFINITION DU CONTEXTE DU SYSTEME Différentes phase de vie du système : Exploitation ou don du sang. Conception et réalisation. Transport et stockage. Maintien en condition opérationnelle. Retrait. Un diagramme de contexte par phase de vie. Nous limitons la présentation à un seule phase : exploitation du don du sang. Nous avons vu que le développement du produit demande une prise en compte de chaque phase du cycle de vie. Le contexte et les parties prenantes sont définis pour chaque phase de vie du système. Ici nous avons 5 phases. Exploitation ou don du sang : mission principale. Conception et réalisation ; Transport et stockage : issu du mode d’utilisation de l’hémo-mixer. Maintien en condition opérationnelle : maintenance curative, préventive, réglementation … Retrait. Nous limitons la présentation du contexte en phase de vie Exploitation ou don du sang.

14 Contexte et parties prenantes en phase exploitation ou don du sang.
DBPP2 Définir le contexte du système HEMO-MIXER - Automate de prélèvement Processus de définition des besoins des PPS Contexte et parties prenantes en phase exploitation ou don du sang. Les problèmes ont mis en évidence le besoin d’un système « automate de prélèvement ». Il est représenté en phase exploitation du don du sang. Il s’agit d’un diagramme des blocs. L’automate apparait au centre du diagramme de contexte. Des images permettent d’illustrer le diagramme. Nous voyons apparaitre - les parties prenantes : Personne physique : personnel soignant, le donneur… Personne morale : organisme collecteur, organisme ce certification CE… - Les entités externes : poche de sang, PC Collect... Diagramme de définition de bloc (BDD)

15 Diagramme de contexte en phase conception
DBPP2 Définir le contexte du système HEMO-MIXER - Automate de prélèvement Processus de définition des besoins des PPS Diagramme de contexte en phase conception Un diagramme de contexte doit être réalisé par phase du cycle de vie. Par curiosité voici le diagramme de contexte en phase conception. On met en relation les éléments, qui interviennent pendant la conception de l’automate de prélèvement. Diagramme de contexte (BDD)

16 Cas d’utilisation en phase don du sang
DBPP3 Définir les utilisations du système HEMO-MIXER - Automate de prélèvement Processus de définition des besoins des PPS Cas d’utilisation en phase don du sang Chaque contexte donc chaque phase de cycle de vie possède un diagramme de cas d’utilisation. Chaque cas d’utilisation décrit un service principal de l’HEMO-MIXER. Nous trouvons autour du système les acteurs (les parties prenantes dans un rôle dans un cycle de vie) et les systèmes. Rem : les acteurs et les systèmes externes sont obligatoirement dans les diagrammes de contexte. Il faut par diagramme limiter le nombre de missions sinon on risque de décrire les fonctions plutôt que les missions. Nous avons ici un sous service : configurer … Et un cas d’utilisation qui est apparu après : fournir les informations... Remarque : Peut-être illustré par des images réalistes des acteurs et des systèmes Diagramme de cas d’utilisation (UCD)

17 Cas d’utilisation en phase don du sang
DBPP4 Décrire les scénarios d’utilisation HEMO-MIXER - Automate de prélèvement Processus de définition des besoins des PPS Cas d’utilisation en phase don du sang Il s’agit ici pour chacun des cas d’utilisation de décrire les scénarios d'utilisation. Cela peut être fait sous forme textuel dans ce diagramme ou encore en utilisant des diagrammes de séquence, d’activité ou d’état. Ici sont précisés : · Le contexte (opérationnel) ; · Les actions et interactions ; · Leurs enchainements et conditions éventuelles ; · Les acteurs qui font l’action ; · Les données en entrée et en sortie ; · Les options éventuelles. Diagramme de cas d’utilisation (UCD)

18 DBPP5 Définir les besoins de parties prenantes
HEMO-MIXER - Automate de prélèvement Processus de définition des besoins des PPS Dans un premier temps nous complétons le diagramme des exigences avec les besoins apparus au niveau du diagramme des cas d’utilisation : il s’agit ici de besoins – services attendus. On indique la Trace, qui permet de définir d’où vient le besoin Trace : provient d’une mission ou d’un service. Diagramme des besoins (RD)

19 DBPP5 Définir les besoins de parties prenantes
HEMO-MIXER - Automate de prélèvement Processus de définition des besoins des PPS Nous allons compléter les besoins avec différents besoins de 5 types : service, performance, opérationnel, performance et contrainte. Par exemple ici sont issus des éléments du besoin initial et des scénarios associés aux cas d’utilisation Diagramme des besoins (RD)

20 Vérification au fil de l’eau et avant la présentation au client
DBPP6 Vérifier les besoins des parties prenantes HEMO-MIXER - Automate de prélèvement Processus de définition des besoins des PPS Vérification au fil de l’eau et avant la présentation au client Diagrammes de cas d’utilisation (UCD) Diagramme des besoins (RD) Bien sur la vérification a été faite au fil de l’eau et il faut maintenant effectuer une vérification complète avant de présenter le résultat au client. On vérifie la cohérence des 3 diagrammes : besoin, contexte, mission. Diagrammes de contexte (BDD)

21 par le(s) client(s) des besoins des parties prenantes
DBPP7 Valider les besoins des parties prenantes HEMO-MIXER - Automate de prélèvement Processus de définition des besoins des PPS Validation par le(s) client(s) des besoins des parties prenantes Les besoins des parties prenantes sont définis. Le ou les clients peuvent les valider. Il ne reste qu’à établir le dossier de définition des besoins des parties prenantes.

22 Client(s) MOA MOE Analyse des exigences
HEMO-MIXER - Automate de prélèvement Dossier de définition des besoins des parties prenantes Référentiel des besoins en SysML Client(s) Besoins Le maître d’ouvrage va confier au maître d’œuvre le dossier de définition des besoins des parties prenantes de l’HEMO-MIXER. La vision boite noire est terminée, nous allons pouvoir passer à la vision boite blanche. MOA MOE Dossier de définition des exigences système Concepts opérationnels et/ou d’architecture

23 HEMO-MIXER - Automate de prélèvement Processus d’analyse des exigences
AE1 Analyser le contexte du système HEMO-MIXER - Automate de prélèvement Processus d’analyse des exigences Le maitre d’oeuvre prend en main le besoin des parties prenantes.

24 HEMO-MIXER - Automate de prélèvement Processus d’analyse des exigences
AE2 Définir les concepts du système HEMO-MIXER - Automate de prélèvement Processus d’analyse des exigences Pour l’automate de prélèvement les concepts sont énoncés. On voit par exemple que le concept utilisé pour empêcher la coagulation du sang est l’agitation de la poche. Ce concept est justifié par le commentaire. Il est possible d’avoir pour une même exigence plusieurs concepts. Dans ce cas plusieurs direction de conception seront prises et découleront vers un choix. Diagramme de définition de bloc (BDD)

25 Diagramme de cas d’utilisation (UC)
AE3 Décrire les missions du système HEMO-MIXER - Automate de prélèvement Processus d’analyse des exigences Diagramme de cas d’utilisation (UC) Un diagramme d’état nous permet de décrire les missions de l’HEMO-MIXER. Les cas d’utilisation permettent de produire ce diagramme. La mission « Prélever le sang du donneur » est décrite par un diagramme d’état. On remarque le sous service « configurer la quantité de sang ». Diagramme d’état (SMD)

26 Diagramme de cas d’utilisation (UC)
AE3 Décrire les missions du système HEMO-MIXER - Automate de prélèvement Processus d’analyse des exigences (MOE) Diagramme de cas d’utilisation (UC) Une autre possibilité consiste à utiliser un diagramme des séquences. Diagrammes de séquence (SD)

27 HEMO-MIXER - Automate de prélèvement Processus d’analyse des exigences
AE4 Décrire les exigences système HEMO-MIXER - Automate de prélèvement Processus d’analyse des exigences Les exigences système sont issues directement des exigences des parties prenantes. Nous allons avoir à ajouter les exigences à partir de l’étude précédente…

28 Exigences Système Fonctionnelles. Ex. Clamper le cathéter
AE4 Décrire les exigences système HEMO-MIXER - Automate de prélèvement Processus d’analyse des exigences Exigences Système Fonctionnelles. Ex. Clamper le cathéter Elles sont de 5 types : ex les Exigences Système Fonctionnelles. Ex. Clamper le cathéter

29 Ex. Disposer d’une interface intuitive
AE4 Décrire les exigences système HEMO-MIXER - Automate de prélèvement Processus d’analyse des exigences Exigences d'interface Ex. Disposer d’une interface intuitive Exigences de performance Ex. Installer le système en moins d’1mn Exigences d'interface Ex. Disposer d’une interface intuitive Exigences de performance Ex. Installer le système en moins d’1mn

30 Exigences de contraintes. Ex. utiliser tout type de poches
AE4 Décrire les exigences système HEMO-MIXER - Automate de prélèvement Processus d’analyse des exigences Et enfin Exigences de contraintes. Ex. utiliser tous types de poches Exigences de contraintes. Ex. utiliser tout type de poches

31 Exigences de validation. Ex. réaliser 200 prélèvements en 70h
AE5 Définir les exigences de validation HEMO-MIXER - Automate de prélèvement Processus d’analyse des exigences Nous allons terminer avec les Exigences de validation. Ex. réaliser 200 prélèvements en 70h. Cette étape est fondamentale, elle permet de définir les exigences à vérifier lors de la recette du produit. Exigences de validation. Ex. réaliser 200 prélèvements en 70h Diagramme d’exigences (RD)

32 Traçabilité des exigences systèmes
AE6 Assurer la traçabilité des exigences système HEMO-MIXER - Automate de prélèvement Processus d’analyse des exigences Traçabilité des exigences systèmes Matrice de traçabilité Exigences / Besoins Il faut vérifier que les besoins des parties prenantes se retrouvent tracées ou exprimées dans les exigences systèmes. Ceci peut être fait avec un tableau qui représente suivant les lignes les besoins de parties prenantes. Suivant les colonnes les exigences systèmes.

33 HEMO-MIXER - Automate de prélèvement Processus d’analyse des exigences
AE7 Vérifier les exigences système HEMO-MIXER - Automate de prélèvement Processus d’analyse des exigences Les outils informatiques nous aide à effectuer cette activité.

34 Validation par le(s) client(s) des exigences système
AE8 Valider les exigences système HEMO-MIXER - Automate de prélèvement Processus d’analyse des exigences Nous pouvons présenter les exigences systèmes au client et valider le dossier. Les diagrammes produits donnent le dossier de conception. Validation par le(s) client(s) des exigences système

35 Client(s) MOA MOE MOE Réalisation Concevoir l’architecture
HEMO-MIXER - Automate de prélèvement Processus de conception de l’architecture Dossier de définition des exigences système validé Client(s) Besoins Les exigences systèmes sont décrites et validées avec le client, il est possible de passer à la réalisation. Il est possible de parler de maître d’œuvre de réalisation. MOA MOE MOE Réalisation Dossier de conception

36 CA1 Identifier les opérations du système
HEMO-MIXER - Automate de prélèvement Processus de conception de l’architecture CA2 Définir la vue logique du système Diagramme de séquence (SD) Pour établir le diagramme des bloc nous partons du bloc système que nous allons décomposer. Ici nous avons le bloc système de l’automate de prélèvement. Nous allons pouvoir définir ses opérations a partir des messages du diagramme des séquences. Lorsque le bloc système va se décomposer en blocs, il va falloir distribuer les opérations. Diagramme de définition de bloc (BDD)

37 CA3 Associer les opérations aux états
HEMO-MIXER - Automate de prélèvement Processus de conception de l’architecture Diagramme d’état (STMD) Diagramme de définition de bloc (BDD) Le bloc système est décomposé en blocs sous système de façon logique. Plusieurs solutions peuvent être envisagées et comparées pour effectuer un choix. Au niveau du diagramme des blocs apparait uniquement une décomposition logique et non pas de flux d’information. Un diagramme d’état permet aussi de définir les opérations du système. Les opérations sont attribuées à partir du diagramme d’état.

38 CA6 Allouer les opérations aux sous-systèmes
HEMO-MIXER - Automate de prélèvement Processus de conception de l’architecture CA7 Définir les échanges avec les sous- systèmes CA8 Définir la vue interne du système Le diagramme des bloc interne est déduit. Les ports sont produits à partir des messages du diagramme de séquences. Les flux d’informations d’énergie, de matière … sont ajoutés. Diagrammes de bloc interne (IBD)

39 CA9 Vérifier l’architecture physique
HEMO-MIXER - Automate de prélèvement Processus de conception de l’architecture Exigences induites Diagramme d’exigence (RD) Les blocs sont ajoutés au diagramme d’exigence afin de vérifier à l’aide d’une matrice que le lien fonction/solution est établi. Nous voyons ici que l’exigence système ‘échanger via un port usb’ est réalisée par le bloc « PC-solution 1 ». Dans une matrice