Wiki Campus 3

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
==== Management des Systèmes d'Information ====

Le système d'information (S.I.) (ensemble des informations et règles de gestion de ces informations) est l'instrument de la coordination entre les acteurs d'une organisation. Il assure 3 fonctions : le traitement, la mémorisation et la circulation de l'information.

Il évolue au cours du temps par\\
 - l'introduction de nouvelles applications qui couvrent des besoins nouveaux ou pas encore automatisés\\
 - l'ajout de fonctionnalités aux applications existantes,\\
 ...

=== Management ou gestion ? ===

Le management dit quoi faire tandis que la gestion dit comment faire. (//Management is to do the right things and administration is to do right the things.//)
En matière de S.I., le management décide des projets d'informatisation, d'évolution... sur la base de différents critères au nombre desquels on trouve le coût.

Pour déterminer le coût d'un projet (de développement), on peut utiliser des modèles de coût.

===== Modèles de coût =====

Il s'agit de déterminer le coût d'un projet avant de l'avoir réalisé.

Deux approches sont possibles :\\
 - par décomposition du projet en tâches élémentaires dont on estime la durée et l'effectif requis pour les mener à bien, c'est l'approche analytique. Les charges des différentes tâches sont ajoutées les unes aux autres pour donner la charge du projet tout entier.\\
 - par une approche globale qui consiste à estimer la charge d'un projet en se basant sur l'expérience, à partir d'éléments objectifs, tangibles, propres au projet.

==== Approche analytique et modèle de la valeur acquise ====

L'{{:departement_info:personnels:pb:R3.10:analyse_methodique.pdf|analyse méthodique}} procède par décomposition en un plan détaillé et addition des charges du plan. Elle permet d'estimer le coût total d'un projet ainsi que l'évolution du coût au cours du temps (plus on avance dans le projet, plus le coût - cumul des dépenses - augmente).

Ce coût peut être compatible avec le budget disponible ou pas et détermine ainsi la décision de départ (//Go / No Go//).

En effectuant un suivi régulier au cours du projet, on peut apprécier si la réalisation est conforme aux prévisions en termes de délai et de coût et décider ainsi de l'arrêt du projet (retard et/ou surcoût trop important) ou de sa poursuite (//Stop or Go//). Le {{:departement_info:personnels:pb:R3.10:valeur_acquise.pdf|modèle de la valeur acquise}} fournit les informations utiles à cette décision (//stop or go//) et des indicateurs de performance du projet...

{{:departement_info:personnels:pb:R3.10:exercice_valeur_acquise.pdf|Exercice sur la valeur acquise}}

Cet exercice illustre le besoin de quantifier l'avancement des tâches, ce qui est relativement facile quand le produit du projet est concret, physique. Qu'en est-il pour le développement d'un logiciel ? Quelle pourrait être la mesure de l'avancement ?

Les indices de performance peuvent constituer les coordonnées des points d'un graphe qui illustre l'évolution du projet au cours du temps en termes de délai (efficacité en abscisse) et de coût (efficience en ordonnée), le {{:departement_info:personnels:pb:R3.10:tendance_cout_delai.pdf|graphe de tendance coût-délai}}.

Cette approche méthodique suppose :\\
 - de n'oublier aucune tâche dans le découpage du projet;\\
 - d'estimer correctement la charge de chaque tâche;

Plus l'ampleur du projet est grande, plus ces conditions sont difficiles à satisfaire. Cette approche conduit alors à sous-estimer la durée et l'effectif... et le projet semble être toujours en retard, toujours en dépassement du budget, ce qui conduit les équipes à faire vite et mal pour y arriver ! Il faut donc une autre approche qui découpe le projet en grandes phases de travail, sans entrer dans le détail de toutes les tâches à mener à bien (ce dont on n'est pas capable).

{{:departement_info:personnels:pb:R3.10:exercice_grandes_phases.pdf|Exercice basé sur les grandes phases d'un projet}}\\
Pour plus d'informations sur le projet de cet exercice, on pourra lire les articles parus sur [[https://www.le-ticket.fr/dans-les-coulisses-produit-de-sncf-connect-lappli-qui-a-deraille-au-depart/4203/|le-ticket.fr]] et sur [[https://www.igen.fr/app-store/2022/09/sncf-connect-les-coulisses-dun-developpement-ambitieux-pour-une-app-tres-critiquee-132227|igen.fr]].

==== Modèles de coût empiriques ====

Les modèles de coût empiriques sont basés sur l'expérience et proposent de calculer la charge (et la durée) à partir d'unités d'œuvre propres au projet, sur quelques grandes phases du projet.

La méthode {{:departement_info:personnels:pb:R3.10:racines.pdf|RACINES}} (RAtionalisation des Choix INformatiquES) a été conçue en 1976 par le ministère français de l'industrie et formalisée dans un guide publié en 1988. A partir d'unités d'œuvre de MERISE, RACINES permet de calculer les charges de travail de 3 phases d'un projet d'informatisation :\\
 - l'analyse fonctionnelle\\
 - la réalisation\\
 - l'intégration.

{{:departement_info:personnels:pb:R3.10:exercice_racines.pdf|Exercice RACINES}}

{{:departement_info:personnels:pb:R3.10:cocomo.pdf|CoCoMo}} a été conçue en 1981 par Barry Boehm. C'est une méthode statistique basée sur 63 projets de développement de logiciels de 2 000 à 1 000 000 lignes de code. Elle permet de calculer l'effort et la durée d'un projet de développement de logiciel à partir de sa taille et de sa complexité. Des 
{{:departement_info:personnels:pb:R3.10:repartitions_cocomo.pdf|tableaux}} fournissent les coefficients pour répartir l'effort et la durée sur les 4 phases du projet :\\
 - spécification et planification\\
 - conception générale\\
 - programmation\\
 - intégration et tests.

{{:departement_info:personnels:pb:R3.10:exercice_cocomo.pdf|Exercice CoCoMo}} pour lequel les calculs pourront être faits avec cette {{:departement_info:personnels:pb:R3.10:application_cocomo.xlsx|application au tableur}}

Dans les années 1970, de nombreux experts du développement ont constaté une corrélation entre la taille du logiciel et l'effort et la durée du développement. Pour cette raison, Barry Boehm a conçu son modèle sur la base de cette unité d'œuvre. Mais estimer la taille suppose de l'expérience... et tout peut être remis en question si on change de langage !

Dans le cas de réécriture d'une application (passage d'application de bureau à application web par exemple, à condition que les langages utilisés aient des pouvoirs d'expression comparables - java et PHP par objets, C et PHP sans objets) ou lorsqu'il faut réécrire une partie du code d'une application (changement d'algorithme pour de meilleurs temps de réponse), on peut faire l'hypothèse que la taille est à peu la même que celle de départ.

Ces modèles sont-ils encore applicables en l'état de nos jours, compte tenu de l'évolution des méthodes (modélisation en UML plutôt qu'en MERISE), des langages de programmation et des outils (Environnement de développement intégré - //Integrated Development Environnement//; //framework// et intelligence artificielle générative) ? Quelles unités d'œuvre retenir ?

Toujours est-il que ces modèles de coût correspondent aux approches classiques de gestion de projet. Mais qu'en est-il des approches agiles ?

==== Modèle de coût agile ====

Les approches agiles diffèrent des approches classiques par leur {{:departement_info:personnels:pb:R3.10:cycles_de_vie.pdf|cycle de vie}} qui répète des périodes de travail courtes avec livraison partielle au client plutôt qu'une seule longue période de projet avec livraison complète à la fin du travail.

C'est le cas de l'approche {{:departement_info:personnels:pb:R3.10:scrum.pdf|Scrum}} dont les itérations, appelées sprints, suivent toutes le même schéma :\\
 - {{:departement_info:personnels:pb:R3.10:planification_iteration.pdf|planification}}\\
 - production\\
 - {{:departement_info:personnels:pb:R3.10:revue.pdf|revue d'itération}}\\
 - {{:departement_info:personnels:pb:R3.10:retrospective.pdf|rétrospective d'itération}}\\
ponctué de réunions quotidiennes, les {{:departement_info:personnels:pb:R3.10:melee.pdf|mêlées}} (daily scrum).

Le cahier des charges agile prend la forme d'un {{:departement_info:personnels:pb:R3.10:backlog.pdf|carnet de commande}} (//product backlog//) constitué de différentes attentes formulées en petits scénarios d'utilisation, les {{:departement_info:personnels:pb:R3.10:us.pdf|récits utilisateur}} (//user stories//).

La planification dans les approches agiles est basée sur un modèle de coût spécifique, qui s'appuie sur :\\
 - l'effort estimé en {{:departement_info:personnels:pb:R3.10:points.pdf|points de difficulté}},\\
 - la valeur des attentes, fournie par le client ou le porteur du produit (//product owner//).

L'estimation de la difficulté se fait au cours d'une réunion de planification, le {{:departement_info:personnels:pb:R3.10:poker.pdf|poker d'estimation}} ou //planning poker//.

La valorisation de la difficulté des attentes du carnet de commande permet la planification agile qui consiste à établir un {{:departement_info:personnels:pb:R3.10:plan_livraison.pdf|plan de livraison}}. A celui-ci correspondent ...\\
 - une baisse au cours du temps de la charge de travail restante\\
 - une augmentation de la valeur du produit livré au client\\
illustrées par des {{:departement_info:personnels:pb:R3.10:taf_valeur.pdf|graphiques prévisionnels du TAF et de la valeur}}.

La valeur du produit livré (éventuellement ramenée au budget du projet) peut être comparée à la valeur acquise des approches classiques de gestion de projet.
L'observation des courbes de la valeur du produit (approche agile) et de la valeur acquise (approche classique) montre un accroissement rapide de la valeur dans les approches agiles (qui diminue ensuite) quand les approches classiques se caractérisent par un accroissent lent la valeur acquise (qui augmente ensuite). La décision d'arrêt du projet en cas de retard est plus facile à prendre dans les approches agiles puisqu'un produit répondant partiellement au besoin est utilisable et que ce qui lui manque a peu de valeur pour le client qui peut donc y renoncer.

{{:departement_info:personnels:pb:R3.10:exercice_planification_agile.pdf|Exercice de planification agile}}

Au cours de chaque itération, un outil est utilisé pour coordonner et suivre le travail des membres de l'équipe : le tableau d'itération ou {{:departement_info:personnels:pb:R3.10:tableau_des_taches.pdf|tableau des tâches}}.

A la fin de la revue d'itération les {{:departement_info:personnels:pb:R3.10:suivi_taf_valeur.pdf|graphiques de suivi du TAF et de la valeur}} peuvent être mis à jour pour illustrer le retard, la conformité ou l'avance par rapport aux prévisions.

{{:departement_info:personnels:pb:R3.10:exercice_suivi_agile.pdf|Exercice de suivi agile}}
  
En cas de retard, les tâches encore "à faire" ou "en cours" à la fin d'une itération sont reportées "à faire" ou "en cours" pour l'itération suivante et les attentes qu'on avait prévu de traiter au cours de la prochaine itération ne sont pas toutes portées "à faire" dans cette itération. Si au contraire l'équipe a pris de l'avance, on inclut dans le travail "à faire" des éléments initialement prévus ultérieurement. Le plan de livraison est donc revu à la fin de la rétrospective pour tenir compte de la vélocité réelle de l'équipe.

{{:departement_info:personnels:pb:R3.10:exercice_revision_agile.pdf|Exercice de révision du plan de livraison}}

----

La valorisation par le client des attentes du carnet de commande et l'estimation par l'équipe de leur difficulté en points de récit permettent d'établir le plan de livraison. Cependant la mesure de la difficulté en points de récit est {{:departement_info:personnels:pb:R3.10:remise en question.pdf|remise en question}}.\\
Qu'importe pour les nombreuses équipes agiles à ne pas faire de poker d'estimation. A la place, elles préfèrent une réunion pour bien comprendre les récits utilisateur, les reformuler si nécessaire, les décomposer en plusieurs récits... On appelle cette réunion //backlog refinement//. Elle conduit alors à un carnet de commande dans lequel toutes les attentes ont une difficulté à peu près équivalente et il devient inutile de les estimer. Le nombre d'attentes prises en charge à chaque itération est alors à peu près le même.

Cependant, que l'on fasse une réunion d'estimation ou une réunion d'affinage du carnet de commande, comment fixer le nombre de personnes de l'équipe agile, ainsi que le nombre et la durée des itérations. C'est la question de la charge de travail qui reste posée. Certains proposent d'utiliser les {{:departement_info:personnels:pb:R3.10:points de fonction COSMIC.pdf|points de fonction COSMIC}} pour estimer l'effort requis pour mener à bien le projet (voir [[https://assemi.fr/cosmic-la-methode-de-mesure-logicielle/|COSMIC]]). 

----
==== Triplet coût-délai-qualité ====

La gestion de projet vise à respecter le budget tout en tenant les délais. Mais il ne faut pas oublier la qualité et la sacrifier au profit du délai et/ou du budget. Remettre à plus tard une réécriture revient à emprunter du temps qu'il faudra rembourser par de la maintenance corrective par exemple. Malheureusement, le temps que cela prend quand on ne le fait pas tout de suite est plus long, un peu comme si on devait rembourser des intérêts en plus du capital. C'est pourquoi on appelle les défauts du code de la {{:departement_info:personnels:pb:R3.10:dette.pdf|dette technique}}. [[https://dantotsupm.com/2011/05/12/gartner-cast-whitepaper-monetisez-la-dette-technique/|Le coût de cette dette]] est énorme.

On pourra lire à ce sujet deux articles de juin 2022 : [[https://www.lemondeinformatique.fr/actualites/lire-la-dette-technique-reste-mal-comprise-86974.html|article paru dans "Le monde informatique"]] et [[https://www.linkedin.com/pulse/questce-que-la-dette-technique-comment-ma%C3%AEtriser-falco-schmutz?trk=public_profile_article_view|article publié sur LinkedIn]].

Il faut donc toujours avoir en tête la qualité et ne rien livrer qui ne soit terminé. Par leur processus itératif avec validation à chaque revue d'itération, {{:departement_info:personnels:pb:R3.10:qualigilité.pdf|les approches agiles encouragent et permettent la qualité}}. Mais cela suppose une {{:departement_info:personnels:pb:R3.10:DoD.pdf|définition stricte de fini}} (DoD pour Definition of Done) et la connaissance des critères d'acceptation du client.

====== Management des S.I. et processus ======

Décider de développer une nouvelle application, de faire évoluer une application existante, de remplacer une application par une autre, en bref de réaliser la transformation numérique de l’entreprise suppose d’en connaître les processus. Le coût intervient dans la décision, mais ce n'est pas le seul critère ! Une activité ne peut être automatisée que si elle est bien comprise.

A cet effet, un outil, la cartographie des processus, permet :\\
 - d'analyser finement le fonctionnement de l'entreprise ;\\
 - de localiser les processus clés ;\\
 - d'aider à comprendre les interactions entre eux.

Pour cartographier les processus, on peut démarrer la représentation par les intrants (//inputs//) principaux (commande client, réclamation, …) et associer le(s) processus participant à l'atteinte des objectifs et la production des principaux extrants (//outputs//). Cela renvoie aux fonctions du S.I. (traitement, circulation et mémorisation de l'information) et à la représentation des flux d'information.

===== Modèles des flux d'information =====

Un flux d'information est un ensemble de données qui circulent en même temps (une commande, une facture, un bulletin de paie...) entre deux acteurs : l'émetteur et le destinataire.

MERISE propose de représenter les flux d'information entre le S.I. et les acteurs externes au moyen d'un {{:departement_info:personnels:pb:R3.10:flux-contexte.pdf|modèle de contexte}} ou diagramme brut des flux. En s'intéressant à l'activité, la représentation ou {{:departement_info:personnels:pb:R3.10:MCF.pdf|modèle conceptuel des flux}}, fait apparaître les processus au sein de l'organisation, processus que l'on peut détailler en activités entre lesquelles des informations sont échangées. On peut aussi s'intéresser aux acteurs internes entre lesquels des informations sont échangées. Le {{:departement_info:personnels:pb:R3.10:flux-acteurs.pdf|graphe des flux et des acteurs}} en rend compte.

La circulation de l'information et les traitements étant liés, il existe des modèles qui mixtent les fonctions circulation et traitement. C'est le cas du {{:departement_info:personnels:pb:R3.10:dfd.pdf|diagramme de flux de données}} de l'analyse structurée (SA) et du {{:departement_info:personnels:pb:R3.10:schema-circulation-documents.pdf|schéma de circulation des documents}} de MERISE.

===== Modèles des processus =====

Alors que la cartographie a pour objectif de représenter graphiquement les principaux processus et les interactions entre eux, la modélisation va plus loin, en explicitant le fonctionnement du système.

La modélisation des processus fournit un support pour se donner les moyens de\\
 - formaliser la manière de fonctionner du système\\
 - la comprendre\\
 - l’analyser\\
 - l’optimiser\\
 - la faire évoluer.


==== Modèles de MERISE ====

MERISE propose {{:departement_info:personnels:pb:R3.10:modeles-traitements-merise.pdf|trois modèles des traitements}} correspondant à ses trois niveaux de description du système d'information.

Le {{:departement_info:personnels:pb:R3.10:mct.pdf|modèle conceptuel des traitements}} décompose le processus en opérations et le décrit indépendamment des choix d'organisation.

{{:departement_info:personnels:pb:R3.10:exemple mct.pdf|Exemple de modèle conceptuel des traitements}}

{{:departement_info:personnels:pb:R3.10:choix-organisation.pdf|Les choix d'organisation}} (niveau d'automatisation, affectation à un poste de travail) sont pris en compte dans le {{:departement_info:personnels:pb:R3.10:morgt.pdf|modèle organisationnel des traitements}} qui décrit la procédure (et ses différentes phases constitutives) correspondant à une opération du modèle conceptuel.

{{:departement_info:personnels:pb:R3.10:exemple mot.pdf|Exemple de modèle organisationnel des traitements}}

Le {{:departement_info:personnels:pb:R3.10:mopt.pdf|modèle opérationnel des traitements}} décrit les phases automatisées du modèle organisationnel et précise les accès aux données et l'interface utilisateur au moyen de dessins d'écran.

==== Modèles d'UML ====

UML propose {{:departement_info:personnels:pb:R3.10:diagrammes-uml.pdf|différents points de vue}} sur le système d'information

Parmi les diagrammes de comportement, le diagramme de cas d'utilisation recense les opérations sans les décrire tandis que le diagramme états-transitions illustre les différents états que peut prendre un objet en fonction des traitements réalisés. Le diagramme de séquence explicite le déroulement des choses tout comme le {{:departement_info:personnels:pb:R3.10:diagramme-activité.pdf|diagramme d'activité}}, qui sert à expliciter un cas d'utilisation, une méthode ou un processus.

{{:departement_info:personnels:pb:R3.10:exercices-diagramme-activité.pdf|Exercices sur le diagramme d'activité}}

Les différents acteurs impliqués dans un processus peuvent être représentés par des couloirs verticaux (des colonnes) mentionnant leur nom en entête et permettant de distribuer les noeuds du diagramme d'activité pour préciser qui fait quoi. De plus, l'avancement du processus peut être explicité en reliant les opérations à des objets (instances de classes) avec mention de leur état noté comme une condition (entre crochets). {{:departement_info:personnels:pb:R3.10:diag. activité avec couloirs et objets.pdf|diagramme d'activité avec couloirs et objets dans différents états}}

Même si UML permet de modéliser les processus, les concepts utilisés (classes, objets, cas d'utilisation, méthodes...) sont trop techniques pour des experts métier (non développeurs). La norme BPMN (Business Process Modeling Notation) a été conçue spécialement pour eux en répondant à leurs besoins.

==== BPMN ====

UML et BPMN sont deux normes de l'[[https://www.omg.org/|Object Management Group]]. Le standard BPMN 2.0 de janvier 2011 spécifie les éléments graphiques des modèles, leur sémantique et leur exécution, ce qui permet de convertir les diagrammes en modèles de processus et de les exécuter avec un moteur BPMN.

Appelé aussi processus d’affaires ou processus d’entreprise ou processus opérationnel, un processus métier (//business process//) est un ensemble d’activités corrélées ou en interaction qui contribuent aux finalités des affaires d’une organisation. Il est représenté par un graphe dont les {{:departement_info:personnels:pb:R3.10:éléments de BPMN.pdf|éléments}} sont répartis dans des groupes éventuellement compartimentés en phases.

{{:departement_info:personnels:pb:R3.10:exercice 1 BPMN.pdf|Exercice 1 de BPMN}}

La notation précise {{:departement_info:personnels:pb:R3.10:événements BPMN.pdf|la temporalité et la nature des événements}} et propose {{:departement_info:personnels:pb:R3.10:branchements BPMN.pdf|différents types de branchements}} ainsi que {{:departement_info:personnels:pb:R3.10:types et marqueurs d'activités.pdf|différents types de tâches et marqueurs d'activité}}.

{{:departement_info:personnels:pb:R3.10:exemple escalade et sous-processus.pdf|exemple d'escalade et de sous-processus}}

{{:departement_info:personnels:pb:R3.10:exercice 2 BPMN.pdf|Exercice 2 de BPMN}}

{{:departement_info:personnels:pb:R3.10:poster sur BPMN2.pdf|Tout BPMN 2 en un poster !}}


===== Ethique du numérique =====

La décision de développer une application ou un service ne se prend pas que sur la base du coût du projet ou de la connaissance du processus à automatiser.\\
Il s'agit de rendre le Système d'information plus performant en offrant aux utilisateurs des applications utiles, pour le bien de l'organisation, des utilisateurs et des clients. Il ne faudrait pas que l'utilisation d'une application puisse être détournée de sa vocation initiale ou que l'on trompe l'utilisateur pour le faire agir contre son intérêt ([[https://www.atipik.ch/fr/blog/definition-dark-patterns-design-ux
|interactions trompeuses]]).\\
Par ailleurs, l'informatique utilise des données, parfois personnelles et nominatives, voire des {{:departement_info:personnels:pb:R3.10:donnees_sensibles.pdf|données sensibles}} qui pourraient être obtenues par des personnes non autorisées, voire altérées ou utilisées à d'autres fins que ce que nécessitent les traitements automatisés. Il faut veiller à sécuriser les applications pour se prémunir de ces agissements et respecter les obligations réglementaires en vigueur.

L'{{:departement_info:personnels:pb:R3.10:ethique.pdf|éthique}} doit intervenir dans la décision du management (gouvernance des S.I.). En effet, l'éthique questionne trop souvent //a posteriori// alors qu'avec l'informatique, un problème éthique sera très difficile à régler dans la réactivité. Il faut être proactif et prendre en compte les considérations éthiques...\\
- à la décision de\\
- pendant\\
la transformation numérique de l'organisation.

« La technologie n’est ni bonne, ni mauvaise. Elle n’est pas neutre non plus. » ([[https://en.wikipedia.org/wiki/Melvin_Kranzberg|Melvin Kranzberg]]) car elle peut aussi avoir un impact positif ou négatif sur nous, sur nos sociétés, indépendamment de nos usages. Le numérique devient une norme, qui se heurte parfois à d'autres normes ou référentiels. Pour rééquilibrer les aspects normatifs négatifs du numérique, il faut inventer d'autres normes ({{:departement_info:personnels:pb:R3.10:normatif et ethique.pdf|normatif et éthique}}).

Des {{:departement_info:personnels:pb:R3.10:regles.pdf|lois, codes et chartes}} encadrent en partie les choses. Il faut y ajouter les multiples chartes propres à certaines organisations et que doivent signer les employés et éventuellement les usagers. Ils et elles rappellent des règles de bon sens, des principes éthiques ou de loi mais couvrent (partiellement) le sujet de l'éthique en ne traitant pas toutes ses {{:departement_info:personnels:pb:R3.10:dimensions.pdf|dimensions}}.

Il faut donc parvenir à [[https://www.cairn.info/revue-sciences-du-design-2019-2-page-61.htm(...)|une éthique par dessein]] (//by design//), qui considère les questions éthiques le plus tôt possible et dans le suivi des innovations techniques.



----

===== Le contrôle des connaissances =====

Cette partie de "Management des systèmes d'information" est évaluée par :\\
 - un examen écrit ;\\
 - un mini-projet.\\
La partie de Monsieur Jean-Luc Lambert est évaluée séparément.


==== l'examen (semaine du 4 novembre 2024) ====

C'est une épreuve écrite surveillée d'une durée d'au plus 1 heure avec document manuscrit A4 recto-verso autorisé.\\
Elle porte sur les modèles de coût (classique et/ou agile). 

Voici le {{:departement_info:personnels:pb:r3.10:sujet.pdf|sujet}} et le {{:departement_info:personnels:pb:r3.10:corrigé.pdf|corrigé}} de l'année 2021-2022.

==== le projet (18 décembre 2024) ====

C'est un travail de modélisation à réaliser en groupe de 2 et à rendre pour le 19 décembre 2024 sur [[https://ecampus.unicaen.fr/mod/assign/view.php?id=892411|le dépôt prévu à cet effet sur eCampus]].

{{:departement_info:personnels:pb:r3.10:sujet exercice de modélisation en BPMN.pdf|sujet}}

[[https://camunda.com/download/modeler/|site de téléchargement du logiciel Camunda Modeler]]