Maj du git depuis la derniere fois
This commit is contained in:
BIN
TP_valarcher/Yolou_4.tar
Normal file
BIN
TP_valarcher/Yolou_4.tar
Normal file
Binary file not shown.
146
TP_valarcher/Yolou_4/Prompt_reponse.txt
Normal file
146
TP_valarcher/Yolou_4/Prompt_reponse.txt
Normal file
@@ -0,0 +1,146 @@
|
||||
(Prompt et reéponses fait sur Chat GPT - modele 5.1)
|
||||
|
||||
|
||||
|
||||
Q1 Frontière EF/ENF dépendante du contexte
|
||||
|
||||
Je voulais que Chat GPT m'aide a comprendre avec des exemple de contexte car j'en avais pas vraiment, j'ai donc poser la question au chat l'aide du prompt : "Peux-tu me donner un exemple pour la question 1 en utilisant une fonctionnalité différente de celle déjà utilisée ? J’aimerais voir un autre exemple afin de comprendre comment réaliser l’exercice étape par étape. (Ne réalise pas toutes les questions)"
|
||||
|
||||
Il m'a tout d'abord généré sa reponse :
|
||||
"Nouvelle fonctionnalité choisie (INVENTÉE) :
|
||||
« Le système envoie un email quand un utilisateur modifie son adresse. »
|
||||
Maintenant je te montre comment répondre à Q1-a, Q1-b et Q1-c avec CETTE fonctionnalité de manière partielle, pour que tu comprennes comment faire pour n’importe quel cas.
|
||||
|
||||
Q1-a – ANALYSE DU CONTEXTE (exemple inventé)
|
||||
|
||||
Contexte 1 : Application de livraison (ex : Uber Eats)
|
||||
|
||||
Dans ce type d’application, l’adresse du client est critique pour réussir une livraison.
|
||||
Si l’utilisateur change son adresse, prévenir immédiatement est une action essentielle pour éviter des erreurs logistiques.
|
||||
Donc dans ce contexte, envoyer un email = EF (fonction métier).
|
||||
|
||||
Pourquoi ?
|
||||
|
||||
Parce que si l’adresse change et que personne n’est informé, la livraison peut échouer.
|
||||
|
||||
Contexte 2 : Réseau social (ex : Instagram)
|
||||
|
||||
Dans un réseau social, changer son adresse n’a aucun impact métier important.
|
||||
L’envoi d’un email sert juste à améliorer la sécurité du compte.
|
||||
Donc ici, c’est une ENF (sécurité).
|
||||
|
||||
Pourquoi ?
|
||||
|
||||
Parce que ce n’est pas une vraie fonctionnalité métier.
|
||||
L’utilisateur est venu pour socialiser, pas pour gérer son adresse.
|
||||
|
||||
Q1-b – Rédaction DES EXIGENCES pour chaque contexte
|
||||
Tu dois réécrire une exigence adaptée au contexte.
|
||||
Une pour le contexte 1, une pour le contexte 2.
|
||||
|
||||
Exigence pour le contexte 1 (livraison → EF)
|
||||
« Lorsqu’un utilisateur modifie son adresse principale, le système doit immédiatement envoyer un email au client et au livreur associé contenant la nouvelle adresse, l’ancienne adresse et la date de modification. »
|
||||
Ça décrit bien une action métier → EF.
|
||||
|
||||
Q1-c – Impact sur le BACKLOG selon EF ou ENF
|
||||
Tu expliques comment EF/ENF affecte l’organisation du travail.
|
||||
|
||||
Si EF → devient une User Story prioritaire
|
||||
Dans le contexte de livraison :
|
||||
L’envoi de mail devient une vraie User Story :
|
||||
|
||||
“En tant que livreur, je veux être informé quand l’utilisateur change d’adresse pour éviter une erreur de livraison.”
|
||||
|
||||
|
||||
Elle sera priorisée car elle empêche les erreurs du métier.
|
||||
Elle peut être découpée en sous-stories : format du mail, contenu, timing…
|
||||
|
||||
Plus de stories → backlog plus granularisé.
|
||||
Si ENF → devient un critère d’acceptation
|
||||
Dans le contexte du réseau social :
|
||||
Pas une User Story.
|
||||
|
||||
|
||||
C’est un critère d’acceptation de la story : “Gérer son compte”.
|
||||
C’est moins prioritaire.
|
||||
|
||||
|
||||
On peut le mettre dans un sprint plus tard.
|
||||
Moins de stories → backlog plus simple.
|
||||
|
||||
"
|
||||
|
||||
-------
|
||||
|
||||
Q2 – Refonte d’un backlog non INVEST
|
||||
|
||||
PARTIE 1 – Prompt que j’ai utilisé
|
||||
« Peux-tu me donner un exemple de la manière de refaire un backlog non conforme à INVEST ? J’aimerais voir comment identifier les problèmes d’une User Story, puis comment construire un nouveau backlog conforme à INVEST. Ne fais pas l’exercice complet, juste un exemple pour m’aider à comprendre. »
|
||||
|
||||
PARTIE 2 – Réponse donnée par ChatGPT
|
||||
|
||||
Exemple :
|
||||
Ancienne User Story : « En tant qu’utilisateur, je veux une interface moderne pour que ce soit joli. »
|
||||
|
||||
Problèmes INVEST :
|
||||
|
||||
– I : dépend d’autres stories (refonte complète)
|
||||
– N : contenu flou, non négociable
|
||||
– V : valeur métier faible
|
||||
– E : impossible à estimer (« moderne » est subjectif)
|
||||
– S : trop grande
|
||||
– T : non testable
|
||||
|
||||
Backlog corrigé :
|
||||
|
||||
US1 : En tant qu’utilisateur, je veux activer le mode sombre afin d’améliorer le confort visuel.
|
||||
US2 : En tant qu’utilisateur, je veux modifier la taille du texte afin d’adapter l’affichage à mes besoins.
|
||||
US3 : En tant qu’utilisateur, je veux changer la langue de l’interface afin de personnaliser mon expérience.
|
||||
|
||||
-------
|
||||
|
||||
Q3 – Gestion des ruptures de stock dans une boutique en ligne
|
||||
|
||||
PARTIE 1 – Prompt que j'ai utilisé
|
||||
« Peux-tu m’expliquer comment rédiger un processus métier clair en plusieurs étapes, comment compléter un diagramme de classes du domaine avec de nouvelles classes et attributs, et comment écrire un scénario Given/When/Then pour tester une exigence ? Donne-moi juste un exemple pour comprendre la méthode. »
|
||||
|
||||
PARTIE 2 – Exemple de réponse donnée par ChatGPT
|
||||
|
||||
Exemple de processus métier :
|
||||
|
||||
L’utilisateur consulte la fiche d’un produit.
|
||||
Le système affiche le stock disponible.
|
||||
Si le produit est en rupture, le système bloque l’ajout au panier.
|
||||
Le système propose une alerte de remise en stock.
|
||||
Si l’utilisateur accepte, il est inscrit sur la liste d’attente.
|
||||
Lors du réapprovisionnement, le système notifie les utilisateurs inscrits.
|
||||
|
||||
|
||||
Exemple de compléments au DCD :
|
||||
– Classe : AlerteStock, attributs : dateInscription, canalNotification.
|
||||
– Classe : CommandeFournisseur, attributs : dateCommande, quantite, statut.
|
||||
Exemple Given/When/Then :
|
||||
Given un produit en rupture,
|
||||
When l’utilisateur active l’alerte,
|
||||
Then il reçoit une notification lorsque le produit revient en stock.
|
||||
|
||||
-------
|
||||
|
||||
Q4 – Complémentarité entre User Stories et Cas d’utilisation
|
||||
|
||||
PARTIE 1 – Exemple de prompt que j’aurais pu utiliser
|
||||
|
||||
« Peux-tu m’expliquer comment une User Story peut être déclinée en plusieurs cas d’utilisation, et comment expliquer les risques d’un projet qui n’utilise que des User Stories ou seulement des Cas d’utilisation ? Donne-moi juste un exemple pour comprendre la logique générale, sans faire l’exercice complet. »
|
||||
|
||||
PARTIE 2 – Exemple de réponse donnée par ChatGPT
|
||||
|
||||
Exemple :
|
||||
|
||||
User Story : « En tant que client, je veux payer ma commande en ligne afin de la finaliser. »
|
||||
Cas d’utilisation possibles :
|
||||
– Saisir ses informations de paiement
|
||||
– Confirmer le paiement
|
||||
– Obtenir une confirmation de commande
|
||||
Risques si on utilise seulement des User Stories : manque de précision sur les enchaînements et les erreurs.
|
||||
Risques si on utilise seulement des Cas d’utilisation : perte de la notion de valeur métier, backlog impossible à prioriser.
|
||||
|
||||
203
TP_valarcher/Yolou_4/Yolou_4.txt
Normal file
203
TP_valarcher/Yolou_4/Yolou_4.txt
Normal file
@@ -0,0 +1,203 @@
|
||||
Q1 Frontière EF/ENF dépendante du contexte
|
||||
|
||||
Ainsi en voyant cette exemple donné par (Chat GPT - modele 5.1) j'avais un début de piste pour réaliser la question:
|
||||
|
||||
Q1-a :
|
||||
|
||||
Contexte 1 : Application éducative plateforme d’apprentissage (Duolingo) ENF
|
||||
Changer son mot de passe ne fait pas partie du parcours pédagogique.
|
||||
C’est une exigence de sécurité, donc ENF.
|
||||
|
||||
Contexte 2: Plateforme d’investissements / trading (Boursorama / Trading Republic)
|
||||
Dans ce type d’application, une compromission de compte peut faire perdre de l’argent.
|
||||
La notification immédiate fait partie de la protection métier du capital de l’utilisateur.
|
||||
|
||||
Q1-b et Q1-c
|
||||
|
||||
Contexte 1 : Application éducative (type Duolingo)
|
||||
Classification : ENF (exigence non-fonctionnelle)
|
||||
|
||||
Q1-b – Exigence adaptée au contexte éducatif
|
||||
« Lorsqu’un utilisateur modifie son mot de passe, le système doit envoyer une notification push informative dans un délai inférieur à 10 secondes, afin de garantir un niveau de sécurité minimal pour la gestion du compte. La notification doit indiquer la date et l’heure de la modification. »
|
||||
Ici, l’envoi de notification n’est pas lié au cœur du métier (apprendre une langue). C’est uniquement une règle de sécurité.
|
||||
|
||||
Q1-c – Impact sur le backlog (application éducative)
|
||||
Étant une exigence non-fonctionnelle, cette notification n’apparaît pas comme une User Story autonome dans le backlog. Elle sera intégrée comme critère d’acceptation dans une User Story plus large de type « Gérer son compte ». Cette exigence n’a pas de valeur métier directe pour l’utilisateur, ce qui la place à une priorité moindre dans le backlog. Elle ne génère pas de sous-stories, car il s’agit d’une simple contrainte technique ou de sécurité.
|
||||
|
||||
Contexte 2 : Plateforme d’investissement / trading
|
||||
Classification : EF (exigence fonctionnelle)
|
||||
|
||||
Q1-b – Exigence adaptée au contexte investissement/trading
|
||||
« Lorsqu’un utilisateur modifie son mot de passe, le système doit envoyer immédiatement une notification push d’alerte contenant la date, l’heure, l’adresse IP d’origine et un lien permettant de bloquer rapidement le compte en cas d’activité suspecte. Le délai d’envoi de la notification ne doit pas dépasser 5 secondes. »
|
||||
Dans ce contexte, informer l’utilisateur est une fonction métier essentielle, car elle permet de protéger ses actifs.
|
||||
|
||||
Q1-c – Impact sur le backlog (plateforme d’investissement)
|
||||
Cette exigence est une exigence fonctionnelle et devient une User Story à part entière dans le backlog, car elle contribue directement à la protection des capitaux de l’utilisateur. Elle est prioritaire et doit être développée en début de projet. De plus, elle entraîne un découpage en plusieurs User Stories ou sous-tâches (définition du contenu de l’alerte, action de blocage, gestion des logs, délai d’envoi), ce qui augmente la granularité du backlog.
|
||||
|
||||
--------------------------
|
||||
|
||||
Q2 – Refonte d’un backlog non INVEST
|
||||
|
||||
Début de réponse que j’ai écrit que j'ai commencé à rédiger :
|
||||
|
||||
Q2-a – Début de réponse
|
||||
Pour la question 2-a, j’ai commencé par relire les trois User Stories données. J’ai remarqué qu’elles sont toutes formulées de manière assez large, et on voit déjà que certaines expressions comme “tableau de bord complet” ou “interface moderne” semblent poser problème. Je pense que ces US ne respectent pas vraiment les critères INVEST, mais je dois encore préciser exactement lesquels et pourquoi.
|
||||
|
||||
Q2-b – Début de réponse
|
||||
Pour la partie 2-b, j’ai essayé de réfléchir à plusieurs User Stories plus simples et plus précises. Mon idée est de partir des mêmes besoins mais en les divisant en fonctionnalités plus petites. J’ai déjà quelques pistes, par exemple sur l’affichage des tâches ou la gestion des comptes, mais il faut que je les reformule correctement au format US.
|
||||
|
||||
Q2-c – Début de réponse
|
||||
Pour la partie 2-c, je commence à réfléchir aux critères d’acceptation possibles pour certaines des nouvelles User Stories. Pour l’instant, je me dis qu’il faudrait au moins deux critères clairs et testables, mais je dois choisir les US les plus adaptées avant de définir ces critères.
|
||||
|
||||
En utilisant ce modèle, j’ai commencé à analyser les User Stories du sujet.
|
||||
|
||||
Réponse finale complète de mes questions à la Q2 grâce à l'aide de l'IA (Chat GPT - modele 5.1):
|
||||
|
||||
Q2-a – Identification des problèmes dans les User Stories
|
||||
|
||||
US1 : « En tant qu’utilisateur, je veux un tableau de bord complet avec une vue globale de toutes mes activités. »
|
||||
|
||||
Problèmes INVEST :
|
||||
|
||||
– I : dépend d’autres fonctionnalités
|
||||
– S : trop large (« complet », « global »)
|
||||
– T : non testable sans préciser les informations attendues
|
||||
– E : non estimable, périmètre flou
|
||||
– V : valeur métier non explicite
|
||||
|
||||
US2 : « En tant qu’utilisateur, je veux une interface moderne afin d’améliorer mon expérience. »
|
||||
|
||||
Problèmes INVEST :
|
||||
|
||||
– V : valeur métier non définie
|
||||
– E : non estimable (« moderne » est subjectif)
|
||||
– T : non testable
|
||||
– S : trop large (design, navigation, composants)
|
||||
|
||||
US3 : « En tant qu’administrateur, je veux gérer tout le système efficacement. »
|
||||
|
||||
Problèmes INVEST :
|
||||
|
||||
– S : trop grande (« tout le système »)
|
||||
– I : dépend de multiples fonctionnalités (utilisateurs, contenus…)
|
||||
– T : impossible à tester
|
||||
– E : impossible à estimer, périmètre trop vaste
|
||||
|
||||
Q2-b – Nouveau backlog contenant au moins 6 User Stories INVEST
|
||||
|
||||
US-A : En tant qu’utilisateur, je veux consulter la liste de mes tâches du jour afin de commencer rapidement mon travail.
|
||||
US-B : En tant qu’utilisateur, je veux filtrer mes tâches par projet afin de visualiser uniquement celles qui me concernent.
|
||||
US-C : En tant qu’utilisateur, je veux afficher mes tâches en retard afin d’identifier mes priorités.
|
||||
US-D : En tant qu’utilisateur, je veux activer un mode clair ou sombre afin d’ajuster le confort visuel.
|
||||
US-E : En tant qu’administrateur, je veux créer un compte utilisateur afin d’ajouter un nouveau collaborateur à la plateforme.
|
||||
US-F : En tant qu’administrateur, je veux désactiver un compte utilisateur afin de retirer l’accès à un collaborateur quittant l’entreprise.
|
||||
|
||||
Q2-c – Critères d’acceptation (pour deux User Stories du backlog corrigé)
|
||||
|
||||
Story X – US-A : « Consulter la liste de mes tâches du jour »
|
||||
|
||||
Critère 1 : La section « Aujourd’hui » affiche uniquement les tâches avec une date d’échéance correspondant à la date du jour.
|
||||
Critère 2 : Si aucune tâche n’est prévue pour aujourd’hui, l’application affiche le message « Aucune tâche pour aujourd’hui ».
|
||||
|
||||
Story Y – US-F : « Désactiver un compte utilisateur »
|
||||
|
||||
Critère 1 : Lorsqu’un administrateur désactive un compte, l’utilisateur concerné ne peut plus se connecter et le message « Compte désactivé » apparaît.
|
||||
Critère 2 : Les tâches précédemment assignées à cet utilisateur restent visibles dans l’historique, mais le compte apparaît comme « désactivé ».
|
||||
|
||||
Q3 – Gestion des ruptures de stock dans une boutique en ligne
|
||||
|
||||
Début de réponse que j’ai écrit que j'ai commencé à rédiger :
|
||||
|
||||
Q3-a – Début de réponse
|
||||
|
||||
Pour le début de la question 3-a, j’ai essayé de reconstituer le processus métier lié à la rupture de stock. Je vois qu’il faut décrire les étapes dans l’ordre logique, en partant du moment où le client consulte le produit jusqu’à la remise en stock. J’ai quelques premières idées mais il faut encore organiser les étapes de façon plus précise.
|
||||
|
||||
Q3-b – Début de réponse
|
||||
|
||||
Pour la partie 3-b, j’ai regardé le diagramme du domaine fourni. Je pense qu’il manque certaines classes importantes, surtout pour gérer les alertes et les commandes fournisseurs. Je dois encore déterminer exactement quelles classes et quels attributs ajouter.
|
||||
|
||||
Q3-c – Début de réponse
|
||||
|
||||
Pour le Given/When/Then, je comprends qu’il faut prendre un scénario précis autour de la remise en stock. J’ai déjà imaginé un cas où un produit est en rupture et où un utilisateur est inscrit à l’alerte, mais je dois formaliser ça correctement dans le format attendu.
|
||||
|
||||
|
||||
Réponse finale complète de mes questions à la Q3 grâce à l'aide de l'IA (Chat GPT - modele 5.1):
|
||||
|
||||
Q3-a – Rédaction du processus métier (au moins 8 étapes)
|
||||
|
||||
Le client consulte la page d’un produit dans la boutique en ligne.
|
||||
Le système vérifie le niveau de stock du produit.
|
||||
Si le stock est positif, le système permet l’ajout normal au panier.
|
||||
Si le produit est en rupture, le système empêche l’ajout au panier et affiche un message d’indisponibilité.
|
||||
Le système propose alors au client de s’inscrire à une alerte de remise en stock.
|
||||
Si le client accepte, le système enregistre une demande d’alerte associée au client et au produit.
|
||||
En parallèle, lorsque le stock atteint le seuil de rupture, le système génère automatiquement une commande fournisseur et l’associe au service logistique pour suivi.
|
||||
Lorsque l’employé logistique enregistre la réception de la commande fournisseur, le système augmente le stock du produit.
|
||||
Dès que le produit redevient disponible, le système déclenche une notification (email ou push) pour tous les clients inscrits à l’alerte.
|
||||
|
||||
|
||||
Q3-b – Modifications à apporter au Diagramme de Classes du Domaine
|
||||
|
||||
Nouvelles classes :
|
||||
|
||||
– AlerteRuptureStock
|
||||
– CommandeFournisseur
|
||||
|
||||
Nouveaux attributs pertinents :
|
||||
|
||||
– Produit : stockDisponible, stockSeuilRupture, etatDisponibilite
|
||||
– AlerteRuptureStock : dateInscription, canalNotification
|
||||
– CommandeFournisseur : dateCommande, quantiteCommande, statutCommande
|
||||
|
||||
Ces ajouts permettent de représenter les processus de rupture, de réapprovisionnement et de notification.
|
||||
|
||||
Q3-c – Scénario de test d’acceptation (Given / When / Then)
|
||||
|
||||
Given un produit dont le stockDisponible est égal à 0 et un client inscrit à l’alerte de remise en stock,
|
||||
When l’employé logistique enregistre la réception d’une commande fournisseur augmentant le stock du produit,
|
||||
Then le système met à jour l’état du produit à “disponible” et envoie une notification au client inscrit pour l’informer de la remise en stock.
|
||||
|
||||
Q4 – Complémentarité entre User Stories et Cas d’utilisation
|
||||
|
||||
Début de réponse que j’ai écrit que j'ai commencé à rédiger :
|
||||
|
||||
Q4-a – Début de réponse
|
||||
|
||||
Pour la question 4-a, j’ai commencé par choisir une User Story autour de la commande en ligne. Je vois comment cette US peut être déclinée en plusieurs cas d’utilisation, mais je dois encore faire la liste complète des actions qui en découlent.
|
||||
|
||||
Q4-b – Début de réponse
|
||||
|
||||
Pour la partie 4-b, j’ai essayé d’identifier les problèmes d’un projet basé uniquement sur les User Stories. Je vois déjà que cela peut créer des zones floues, mais il faut que je développe mieux ces idées.
|
||||
|
||||
Q4-c – Début de réponse
|
||||
|
||||
Pour la dernière sous-question, j’ai réfléchi aux risques inverses, c’est-à-dire un projet basé seulement sur des cas d’utilisation. Je pense que cela pose des problèmes de priorisation et de valeur métier, mais je dois encore formuler tout ça plus clairement
|
||||
|
||||
Réponse finale complète de mes questions à la Q3 grâce à l'aide de l'IA (Chat GPT - modele 5.1) :
|
||||
|
||||
Q4-a – Exemple de User Story et cas d’utilisation dérivés
|
||||
|
||||
User Story choisie :
|
||||
|
||||
« En tant que client, je veux passer une commande en ligne afin de recevoir mes produits à domicile. »
|
||||
Cas d’utilisation dérivés :
|
||||
– Consulter un produit et l’ajouter au panier
|
||||
– Modifier le contenu du panier
|
||||
– Saisir une adresse de livraison
|
||||
– Choisir un mode de livraison
|
||||
– Sélectionner un moyen de paiement
|
||||
– Valider la commande
|
||||
– Recevoir un récapitulatif de commande
|
||||
|
||||
Q4-b – Risques d’un projet qui ne repose que sur des User Stories
|
||||
|
||||
Un projet qui se limite uniquement aux User Stories risque de ne pas décrire précisément les enchaînements d’actions et les scénarios alternatifs, ce qui peut provoquer des ambiguïtés lors du développement. Les comportements attendus en cas d’erreur ou d’exception ne sont pas explicités, ce qui entraîne des implémentations différentes selon les développeurs. L’absence de scénarios détaillés complexifie également les tests, car il devient difficile de valider le comportement complet du système.
|
||||
|
||||
Q4-c – Risques d’un projet qui n’utilise que des Cas d’utilisation
|
||||
|
||||
Se baser seulement sur des Cas d’utilisation peut conduire à ignorer la notion de valeur métier et de priorisation. Tous les cas apparaissent alors sur le même niveau d’importance, ce qui rend le backlog difficile à organiser pour un développement itératif. L’équipe risque de se concentrer sur la complétude documentaire plutôt que sur la livraison de fonctionnalités ayant un impact direct pour l’utilisateur. Cela augmente le risque de retard et d’alignement insuffisant avec les besoins réels du métier.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
146
TP_valarcher/controle_tp_191125/Prompt_reponse.txt
Normal file
146
TP_valarcher/controle_tp_191125/Prompt_reponse.txt
Normal file
@@ -0,0 +1,146 @@
|
||||
(Prompt et reéponses fait sur Chat GPT - modele 5.1)
|
||||
|
||||
|
||||
|
||||
Q1 Frontière EF/ENF dépendante du contexte
|
||||
|
||||
Je voulais que Chat GPT m'aide a comprendre avec des exemple de contexte car j'en avais pas vraiment, j'ai donc poser la question au chat l'aide du prompt : "Peux-tu me donner un exemple pour la question 1 en utilisant une fonctionnalité différente de celle déjà utilisée ? J’aimerais voir un autre exemple afin de comprendre comment réaliser l’exercice étape par étape. (Ne réalise pas toutes les questions)"
|
||||
|
||||
Il m'a tout d'abord généré sa reponse :
|
||||
"Nouvelle fonctionnalité choisie (INVENTÉE) :
|
||||
« Le système envoie un email quand un utilisateur modifie son adresse. »
|
||||
Maintenant je te montre comment répondre à Q1-a, Q1-b et Q1-c avec CETTE fonctionnalité de manière partielle, pour que tu comprennes comment faire pour n’importe quel cas.
|
||||
|
||||
Q1-a – ANALYSE DU CONTEXTE (exemple inventé)
|
||||
|
||||
Contexte 1 : Application de livraison (ex : Uber Eats)
|
||||
|
||||
Dans ce type d’application, l’adresse du client est critique pour réussir une livraison.
|
||||
Si l’utilisateur change son adresse, prévenir immédiatement est une action essentielle pour éviter des erreurs logistiques.
|
||||
Donc dans ce contexte, envoyer un email = EF (fonction métier).
|
||||
|
||||
Pourquoi ?
|
||||
|
||||
Parce que si l’adresse change et que personne n’est informé, la livraison peut échouer.
|
||||
|
||||
Contexte 2 : Réseau social (ex : Instagram)
|
||||
|
||||
Dans un réseau social, changer son adresse n’a aucun impact métier important.
|
||||
L’envoi d’un email sert juste à améliorer la sécurité du compte.
|
||||
Donc ici, c’est une ENF (sécurité).
|
||||
|
||||
Pourquoi ?
|
||||
|
||||
Parce que ce n’est pas une vraie fonctionnalité métier.
|
||||
L’utilisateur est venu pour socialiser, pas pour gérer son adresse.
|
||||
|
||||
Q1-b – Rédaction DES EXIGENCES pour chaque contexte
|
||||
Tu dois réécrire une exigence adaptée au contexte.
|
||||
Une pour le contexte 1, une pour le contexte 2.
|
||||
|
||||
Exigence pour le contexte 1 (livraison → EF)
|
||||
« Lorsqu’un utilisateur modifie son adresse principale, le système doit immédiatement envoyer un email au client et au livreur associé contenant la nouvelle adresse, l’ancienne adresse et la date de modification. »
|
||||
Ça décrit bien une action métier → EF.
|
||||
|
||||
Q1-c – Impact sur le BACKLOG selon EF ou ENF
|
||||
Tu expliques comment EF/ENF affecte l’organisation du travail.
|
||||
|
||||
Si EF → devient une User Story prioritaire
|
||||
Dans le contexte de livraison :
|
||||
L’envoi de mail devient une vraie User Story :
|
||||
|
||||
“En tant que livreur, je veux être informé quand l’utilisateur change d’adresse pour éviter une erreur de livraison.”
|
||||
|
||||
|
||||
Elle sera priorisée car elle empêche les erreurs du métier.
|
||||
Elle peut être découpée en sous-stories : format du mail, contenu, timing…
|
||||
|
||||
Plus de stories → backlog plus granularisé.
|
||||
Si ENF → devient un critère d’acceptation
|
||||
Dans le contexte du réseau social :
|
||||
Pas une User Story.
|
||||
|
||||
|
||||
C’est un critère d’acceptation de la story : “Gérer son compte”.
|
||||
C’est moins prioritaire.
|
||||
|
||||
|
||||
On peut le mettre dans un sprint plus tard.
|
||||
Moins de stories → backlog plus simple.
|
||||
|
||||
"
|
||||
|
||||
-------
|
||||
|
||||
Q2 – Refonte d’un backlog non INVEST
|
||||
|
||||
PARTIE 1 – Prompt que j’ai utilisé
|
||||
« Peux-tu me donner un exemple de la manière de refaire un backlog non conforme à INVEST ? J’aimerais voir comment identifier les problèmes d’une User Story, puis comment construire un nouveau backlog conforme à INVEST. Ne fais pas l’exercice complet, juste un exemple pour m’aider à comprendre. »
|
||||
|
||||
PARTIE 2 – Réponse donnée par ChatGPT
|
||||
|
||||
Exemple :
|
||||
Ancienne User Story : « En tant qu’utilisateur, je veux une interface moderne pour que ce soit joli. »
|
||||
|
||||
Problèmes INVEST :
|
||||
|
||||
– I : dépend d’autres stories (refonte complète)
|
||||
– N : contenu flou, non négociable
|
||||
– V : valeur métier faible
|
||||
– E : impossible à estimer (« moderne » est subjectif)
|
||||
– S : trop grande
|
||||
– T : non testable
|
||||
|
||||
Backlog corrigé :
|
||||
|
||||
US1 : En tant qu’utilisateur, je veux activer le mode sombre afin d’améliorer le confort visuel.
|
||||
US2 : En tant qu’utilisateur, je veux modifier la taille du texte afin d’adapter l’affichage à mes besoins.
|
||||
US3 : En tant qu’utilisateur, je veux changer la langue de l’interface afin de personnaliser mon expérience.
|
||||
|
||||
-------
|
||||
|
||||
Q3 – Gestion des ruptures de stock dans une boutique en ligne
|
||||
|
||||
PARTIE 1 – Prompt que j'ai utilisé
|
||||
« Peux-tu m’expliquer comment rédiger un processus métier clair en plusieurs étapes, comment compléter un diagramme de classes du domaine avec de nouvelles classes et attributs, et comment écrire un scénario Given/When/Then pour tester une exigence ? Donne-moi juste un exemple pour comprendre la méthode. »
|
||||
|
||||
PARTIE 2 – Exemple de réponse donnée par ChatGPT
|
||||
|
||||
Exemple de processus métier :
|
||||
|
||||
L’utilisateur consulte la fiche d’un produit.
|
||||
Le système affiche le stock disponible.
|
||||
Si le produit est en rupture, le système bloque l’ajout au panier.
|
||||
Le système propose une alerte de remise en stock.
|
||||
Si l’utilisateur accepte, il est inscrit sur la liste d’attente.
|
||||
Lors du réapprovisionnement, le système notifie les utilisateurs inscrits.
|
||||
|
||||
|
||||
Exemple de compléments au DCD :
|
||||
– Classe : AlerteStock, attributs : dateInscription, canalNotification.
|
||||
– Classe : CommandeFournisseur, attributs : dateCommande, quantite, statut.
|
||||
Exemple Given/When/Then :
|
||||
Given un produit en rupture,
|
||||
When l’utilisateur active l’alerte,
|
||||
Then il reçoit une notification lorsque le produit revient en stock.
|
||||
|
||||
-------
|
||||
|
||||
Q4 – Complémentarité entre User Stories et Cas d’utilisation
|
||||
|
||||
PARTIE 1 – Exemple de prompt que j’aurais pu utiliser
|
||||
|
||||
« Peux-tu m’expliquer comment une User Story peut être déclinée en plusieurs cas d’utilisation, et comment expliquer les risques d’un projet qui n’utilise que des User Stories ou seulement des Cas d’utilisation ? Donne-moi juste un exemple pour comprendre la logique générale, sans faire l’exercice complet. »
|
||||
|
||||
PARTIE 2 – Exemple de réponse donnée par ChatGPT
|
||||
|
||||
Exemple :
|
||||
|
||||
User Story : « En tant que client, je veux payer ma commande en ligne afin de la finaliser. »
|
||||
Cas d’utilisation possibles :
|
||||
– Saisir ses informations de paiement
|
||||
– Confirmer le paiement
|
||||
– Obtenir une confirmation de commande
|
||||
Risques si on utilise seulement des User Stories : manque de précision sur les enchaînements et les erreurs.
|
||||
Risques si on utilise seulement des Cas d’utilisation : perte de la notion de valeur métier, backlog impossible à prioriser.
|
||||
|
||||
BIN
TP_valarcher/controle_tp_191125/Yolou_4.tar
Normal file
BIN
TP_valarcher/controle_tp_191125/Yolou_4.tar
Normal file
Binary file not shown.
203
TP_valarcher/controle_tp_191125/Yolou_4.txt
Normal file
203
TP_valarcher/controle_tp_191125/Yolou_4.txt
Normal file
@@ -0,0 +1,203 @@
|
||||
Q1 Frontière EF/ENF dépendante du contexte
|
||||
|
||||
Ainsi en voyant cette exemple donné par (Chat GPT - modele 5.1) j'avais un début de piste pour réaliser la question:
|
||||
|
||||
Q1-a :
|
||||
|
||||
Contexte 1 : Application éducative plateforme d’apprentissage (Duolingo) ENF
|
||||
Changer son mot de passe ne fait pas partie du parcours pédagogique.
|
||||
C’est une exigence de sécurité, donc ENF.
|
||||
|
||||
Contexte 2: Plateforme d’investissements / trading (Boursorama / Trading Republic)
|
||||
Dans ce type d’application, une compromission de compte peut faire perdre de l’argent.
|
||||
La notification immédiate fait partie de la protection métier du capital de l’utilisateur.
|
||||
|
||||
Q1-b et Q1-c
|
||||
|
||||
Contexte 1 : Application éducative (type Duolingo)
|
||||
Classification : ENF (exigence non-fonctionnelle)
|
||||
|
||||
Q1-b – Exigence adaptée au contexte éducatif
|
||||
« Lorsqu’un utilisateur modifie son mot de passe, le système doit envoyer une notification push informative dans un délai inférieur à 10 secondes, afin de garantir un niveau de sécurité minimal pour la gestion du compte. La notification doit indiquer la date et l’heure de la modification. »
|
||||
Ici, l’envoi de notification n’est pas lié au cœur du métier (apprendre une langue). C’est uniquement une règle de sécurité.
|
||||
|
||||
Q1-c – Impact sur le backlog (application éducative)
|
||||
Étant une exigence non-fonctionnelle, cette notification n’apparaît pas comme une User Story autonome dans le backlog. Elle sera intégrée comme critère d’acceptation dans une User Story plus large de type « Gérer son compte ». Cette exigence n’a pas de valeur métier directe pour l’utilisateur, ce qui la place à une priorité moindre dans le backlog. Elle ne génère pas de sous-stories, car il s’agit d’une simple contrainte technique ou de sécurité.
|
||||
|
||||
Contexte 2 : Plateforme d’investissement / trading
|
||||
Classification : EF (exigence fonctionnelle)
|
||||
|
||||
Q1-b – Exigence adaptée au contexte investissement/trading
|
||||
« Lorsqu’un utilisateur modifie son mot de passe, le système doit envoyer immédiatement une notification push d’alerte contenant la date, l’heure, l’adresse IP d’origine et un lien permettant de bloquer rapidement le compte en cas d’activité suspecte. Le délai d’envoi de la notification ne doit pas dépasser 5 secondes. »
|
||||
Dans ce contexte, informer l’utilisateur est une fonction métier essentielle, car elle permet de protéger ses actifs.
|
||||
|
||||
Q1-c – Impact sur le backlog (plateforme d’investissement)
|
||||
Cette exigence est une exigence fonctionnelle et devient une User Story à part entière dans le backlog, car elle contribue directement à la protection des capitaux de l’utilisateur. Elle est prioritaire et doit être développée en début de projet. De plus, elle entraîne un découpage en plusieurs User Stories ou sous-tâches (définition du contenu de l’alerte, action de blocage, gestion des logs, délai d’envoi), ce qui augmente la granularité du backlog.
|
||||
|
||||
--------------------------
|
||||
|
||||
Q2 – Refonte d’un backlog non INVEST
|
||||
|
||||
Début de réponse que j’ai écrit que j'ai commencé à rédiger :
|
||||
|
||||
Q2-a – Début de réponse
|
||||
Pour la question 2-a, j’ai commencé par relire les trois User Stories données. J’ai remarqué qu’elles sont toutes formulées de manière assez large, et on voit déjà que certaines expressions comme “tableau de bord complet” ou “interface moderne” semblent poser problème. Je pense que ces US ne respectent pas vraiment les critères INVEST, mais je dois encore préciser exactement lesquels et pourquoi.
|
||||
|
||||
Q2-b – Début de réponse
|
||||
Pour la partie 2-b, j’ai essayé de réfléchir à plusieurs User Stories plus simples et plus précises. Mon idée est de partir des mêmes besoins mais en les divisant en fonctionnalités plus petites. J’ai déjà quelques pistes, par exemple sur l’affichage des tâches ou la gestion des comptes, mais il faut que je les reformule correctement au format US.
|
||||
|
||||
Q2-c – Début de réponse
|
||||
Pour la partie 2-c, je commence à réfléchir aux critères d’acceptation possibles pour certaines des nouvelles User Stories. Pour l’instant, je me dis qu’il faudrait au moins deux critères clairs et testables, mais je dois choisir les US les plus adaptées avant de définir ces critères.
|
||||
|
||||
En utilisant ce modèle, j’ai commencé à analyser les User Stories du sujet.
|
||||
|
||||
Réponse finale complète de mes questions à la Q2 grâce à l'aide de l'IA (Chat GPT - modele 5.1):
|
||||
|
||||
Q2-a – Identification des problèmes dans les User Stories
|
||||
|
||||
US1 : « En tant qu’utilisateur, je veux un tableau de bord complet avec une vue globale de toutes mes activités. »
|
||||
|
||||
Problèmes INVEST :
|
||||
|
||||
– I : dépend d’autres fonctionnalités
|
||||
– S : trop large (« complet », « global »)
|
||||
– T : non testable sans préciser les informations attendues
|
||||
– E : non estimable, périmètre flou
|
||||
– V : valeur métier non explicite
|
||||
|
||||
US2 : « En tant qu’utilisateur, je veux une interface moderne afin d’améliorer mon expérience. »
|
||||
|
||||
Problèmes INVEST :
|
||||
|
||||
– V : valeur métier non définie
|
||||
– E : non estimable (« moderne » est subjectif)
|
||||
– T : non testable
|
||||
– S : trop large (design, navigation, composants)
|
||||
|
||||
US3 : « En tant qu’administrateur, je veux gérer tout le système efficacement. »
|
||||
|
||||
Problèmes INVEST :
|
||||
|
||||
– S : trop grande (« tout le système »)
|
||||
– I : dépend de multiples fonctionnalités (utilisateurs, contenus…)
|
||||
– T : impossible à tester
|
||||
– E : impossible à estimer, périmètre trop vaste
|
||||
|
||||
Q2-b – Nouveau backlog contenant au moins 6 User Stories INVEST
|
||||
|
||||
US-A : En tant qu’utilisateur, je veux consulter la liste de mes tâches du jour afin de commencer rapidement mon travail.
|
||||
US-B : En tant qu’utilisateur, je veux filtrer mes tâches par projet afin de visualiser uniquement celles qui me concernent.
|
||||
US-C : En tant qu’utilisateur, je veux afficher mes tâches en retard afin d’identifier mes priorités.
|
||||
US-D : En tant qu’utilisateur, je veux activer un mode clair ou sombre afin d’ajuster le confort visuel.
|
||||
US-E : En tant qu’administrateur, je veux créer un compte utilisateur afin d’ajouter un nouveau collaborateur à la plateforme.
|
||||
US-F : En tant qu’administrateur, je veux désactiver un compte utilisateur afin de retirer l’accès à un collaborateur quittant l’entreprise.
|
||||
|
||||
Q2-c – Critères d’acceptation (pour deux User Stories du backlog corrigé)
|
||||
|
||||
Story X – US-A : « Consulter la liste de mes tâches du jour »
|
||||
|
||||
Critère 1 : La section « Aujourd’hui » affiche uniquement les tâches avec une date d’échéance correspondant à la date du jour.
|
||||
Critère 2 : Si aucune tâche n’est prévue pour aujourd’hui, l’application affiche le message « Aucune tâche pour aujourd’hui ».
|
||||
|
||||
Story Y – US-F : « Désactiver un compte utilisateur »
|
||||
|
||||
Critère 1 : Lorsqu’un administrateur désactive un compte, l’utilisateur concerné ne peut plus se connecter et le message « Compte désactivé » apparaît.
|
||||
Critère 2 : Les tâches précédemment assignées à cet utilisateur restent visibles dans l’historique, mais le compte apparaît comme « désactivé ».
|
||||
|
||||
Q3 – Gestion des ruptures de stock dans une boutique en ligne
|
||||
|
||||
Début de réponse que j’ai écrit que j'ai commencé à rédiger :
|
||||
|
||||
Q3-a – Début de réponse
|
||||
|
||||
Pour le début de la question 3-a, j’ai essayé de reconstituer le processus métier lié à la rupture de stock. Je vois qu’il faut décrire les étapes dans l’ordre logique, en partant du moment où le client consulte le produit jusqu’à la remise en stock. J’ai quelques premières idées mais il faut encore organiser les étapes de façon plus précise.
|
||||
|
||||
Q3-b – Début de réponse
|
||||
|
||||
Pour la partie 3-b, j’ai regardé le diagramme du domaine fourni. Je pense qu’il manque certaines classes importantes, surtout pour gérer les alertes et les commandes fournisseurs. Je dois encore déterminer exactement quelles classes et quels attributs ajouter.
|
||||
|
||||
Q3-c – Début de réponse
|
||||
|
||||
Pour le Given/When/Then, je comprends qu’il faut prendre un scénario précis autour de la remise en stock. J’ai déjà imaginé un cas où un produit est en rupture et où un utilisateur est inscrit à l’alerte, mais je dois formaliser ça correctement dans le format attendu.
|
||||
|
||||
|
||||
Réponse finale complète de mes questions à la Q3 grâce à l'aide de l'IA (Chat GPT - modele 5.1):
|
||||
|
||||
Q3-a – Rédaction du processus métier (au moins 8 étapes)
|
||||
|
||||
Le client consulte la page d’un produit dans la boutique en ligne.
|
||||
Le système vérifie le niveau de stock du produit.
|
||||
Si le stock est positif, le système permet l’ajout normal au panier.
|
||||
Si le produit est en rupture, le système empêche l’ajout au panier et affiche un message d’indisponibilité.
|
||||
Le système propose alors au client de s’inscrire à une alerte de remise en stock.
|
||||
Si le client accepte, le système enregistre une demande d’alerte associée au client et au produit.
|
||||
En parallèle, lorsque le stock atteint le seuil de rupture, le système génère automatiquement une commande fournisseur et l’associe au service logistique pour suivi.
|
||||
Lorsque l’employé logistique enregistre la réception de la commande fournisseur, le système augmente le stock du produit.
|
||||
Dès que le produit redevient disponible, le système déclenche une notification (email ou push) pour tous les clients inscrits à l’alerte.
|
||||
|
||||
|
||||
Q3-b – Modifications à apporter au Diagramme de Classes du Domaine
|
||||
|
||||
Nouvelles classes :
|
||||
|
||||
– AlerteRuptureStock
|
||||
– CommandeFournisseur
|
||||
|
||||
Nouveaux attributs pertinents :
|
||||
|
||||
– Produit : stockDisponible, stockSeuilRupture, etatDisponibilite
|
||||
– AlerteRuptureStock : dateInscription, canalNotification
|
||||
– CommandeFournisseur : dateCommande, quantiteCommande, statutCommande
|
||||
|
||||
Ces ajouts permettent de représenter les processus de rupture, de réapprovisionnement et de notification.
|
||||
|
||||
Q3-c – Scénario de test d’acceptation (Given / When / Then)
|
||||
|
||||
Given un produit dont le stockDisponible est égal à 0 et un client inscrit à l’alerte de remise en stock,
|
||||
When l’employé logistique enregistre la réception d’une commande fournisseur augmentant le stock du produit,
|
||||
Then le système met à jour l’état du produit à “disponible” et envoie une notification au client inscrit pour l’informer de la remise en stock.
|
||||
|
||||
Q4 – Complémentarité entre User Stories et Cas d’utilisation
|
||||
|
||||
Début de réponse que j’ai écrit que j'ai commencé à rédiger :
|
||||
|
||||
Q4-a – Début de réponse
|
||||
|
||||
Pour la question 4-a, j’ai commencé par choisir une User Story autour de la commande en ligne. Je vois comment cette US peut être déclinée en plusieurs cas d’utilisation, mais je dois encore faire la liste complète des actions qui en découlent.
|
||||
|
||||
Q4-b – Début de réponse
|
||||
|
||||
Pour la partie 4-b, j’ai essayé d’identifier les problèmes d’un projet basé uniquement sur les User Stories. Je vois déjà que cela peut créer des zones floues, mais il faut que je développe mieux ces idées.
|
||||
|
||||
Q4-c – Début de réponse
|
||||
|
||||
Pour la dernière sous-question, j’ai réfléchi aux risques inverses, c’est-à-dire un projet basé seulement sur des cas d’utilisation. Je pense que cela pose des problèmes de priorisation et de valeur métier, mais je dois encore formuler tout ça plus clairement
|
||||
|
||||
Réponse finale complète de mes questions à la Q3 grâce à l'aide de l'IA (Chat GPT - modele 5.1) :
|
||||
|
||||
Q4-a – Exemple de User Story et cas d’utilisation dérivés
|
||||
|
||||
User Story choisie :
|
||||
|
||||
« En tant que client, je veux passer une commande en ligne afin de recevoir mes produits à domicile. »
|
||||
Cas d’utilisation dérivés :
|
||||
– Consulter un produit et l’ajouter au panier
|
||||
– Modifier le contenu du panier
|
||||
– Saisir une adresse de livraison
|
||||
– Choisir un mode de livraison
|
||||
– Sélectionner un moyen de paiement
|
||||
– Valider la commande
|
||||
– Recevoir un récapitulatif de commande
|
||||
|
||||
Q4-b – Risques d’un projet qui ne repose que sur des User Stories
|
||||
|
||||
Un projet qui se limite uniquement aux User Stories risque de ne pas décrire précisément les enchaînements d’actions et les scénarios alternatifs, ce qui peut provoquer des ambiguïtés lors du développement. Les comportements attendus en cas d’erreur ou d’exception ne sont pas explicités, ce qui entraîne des implémentations différentes selon les développeurs. L’absence de scénarios détaillés complexifie également les tests, car il devient difficile de valider le comportement complet du système.
|
||||
|
||||
Q4-c – Risques d’un projet qui n’utilise que des Cas d’utilisation
|
||||
|
||||
Se baser seulement sur des Cas d’utilisation peut conduire à ignorer la notion de valeur métier et de priorisation. Tous les cas apparaissent alors sur le même niveau d’importance, ce qui rend le backlog difficile à organiser pour un développement itératif. L’équipe risque de se concentrer sur la complétude documentaire plutôt que sur la livraison de fonctionnalités ayant un impact direct pour l’utilisateur. Cela augmente le risque de retard et d’alignement insuffisant avec les besoins réels du métier.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
146
TP_valarcher/controle_tp_191125/Yolou_4/Prompt_reponse.txt
Normal file
146
TP_valarcher/controle_tp_191125/Yolou_4/Prompt_reponse.txt
Normal file
@@ -0,0 +1,146 @@
|
||||
(Prompt et reéponses fait sur Chat GPT - modele 5.1)
|
||||
|
||||
|
||||
|
||||
Q1 Frontière EF/ENF dépendante du contexte
|
||||
|
||||
Je voulais que Chat GPT m'aide a comprendre avec des exemple de contexte car j'en avais pas vraiment, j'ai donc poser la question au chat l'aide du prompt : "Peux-tu me donner un exemple pour la question 1 en utilisant une fonctionnalité différente de celle déjà utilisée ? J’aimerais voir un autre exemple afin de comprendre comment réaliser l’exercice étape par étape. (Ne réalise pas toutes les questions)"
|
||||
|
||||
Il m'a tout d'abord généré sa reponse :
|
||||
"Nouvelle fonctionnalité choisie (INVENTÉE) :
|
||||
« Le système envoie un email quand un utilisateur modifie son adresse. »
|
||||
Maintenant je te montre comment répondre à Q1-a, Q1-b et Q1-c avec CETTE fonctionnalité de manière partielle, pour que tu comprennes comment faire pour n’importe quel cas.
|
||||
|
||||
Q1-a – ANALYSE DU CONTEXTE (exemple inventé)
|
||||
|
||||
Contexte 1 : Application de livraison (ex : Uber Eats)
|
||||
|
||||
Dans ce type d’application, l’adresse du client est critique pour réussir une livraison.
|
||||
Si l’utilisateur change son adresse, prévenir immédiatement est une action essentielle pour éviter des erreurs logistiques.
|
||||
Donc dans ce contexte, envoyer un email = EF (fonction métier).
|
||||
|
||||
Pourquoi ?
|
||||
|
||||
Parce que si l’adresse change et que personne n’est informé, la livraison peut échouer.
|
||||
|
||||
Contexte 2 : Réseau social (ex : Instagram)
|
||||
|
||||
Dans un réseau social, changer son adresse n’a aucun impact métier important.
|
||||
L’envoi d’un email sert juste à améliorer la sécurité du compte.
|
||||
Donc ici, c’est une ENF (sécurité).
|
||||
|
||||
Pourquoi ?
|
||||
|
||||
Parce que ce n’est pas une vraie fonctionnalité métier.
|
||||
L’utilisateur est venu pour socialiser, pas pour gérer son adresse.
|
||||
|
||||
Q1-b – Rédaction DES EXIGENCES pour chaque contexte
|
||||
Tu dois réécrire une exigence adaptée au contexte.
|
||||
Une pour le contexte 1, une pour le contexte 2.
|
||||
|
||||
Exigence pour le contexte 1 (livraison → EF)
|
||||
« Lorsqu’un utilisateur modifie son adresse principale, le système doit immédiatement envoyer un email au client et au livreur associé contenant la nouvelle adresse, l’ancienne adresse et la date de modification. »
|
||||
Ça décrit bien une action métier → EF.
|
||||
|
||||
Q1-c – Impact sur le BACKLOG selon EF ou ENF
|
||||
Tu expliques comment EF/ENF affecte l’organisation du travail.
|
||||
|
||||
Si EF → devient une User Story prioritaire
|
||||
Dans le contexte de livraison :
|
||||
L’envoi de mail devient une vraie User Story :
|
||||
|
||||
“En tant que livreur, je veux être informé quand l’utilisateur change d’adresse pour éviter une erreur de livraison.”
|
||||
|
||||
|
||||
Elle sera priorisée car elle empêche les erreurs du métier.
|
||||
Elle peut être découpée en sous-stories : format du mail, contenu, timing…
|
||||
|
||||
Plus de stories → backlog plus granularisé.
|
||||
Si ENF → devient un critère d’acceptation
|
||||
Dans le contexte du réseau social :
|
||||
Pas une User Story.
|
||||
|
||||
|
||||
C’est un critère d’acceptation de la story : “Gérer son compte”.
|
||||
C’est moins prioritaire.
|
||||
|
||||
|
||||
On peut le mettre dans un sprint plus tard.
|
||||
Moins de stories → backlog plus simple.
|
||||
|
||||
"
|
||||
|
||||
-------
|
||||
|
||||
Q2 – Refonte d’un backlog non INVEST
|
||||
|
||||
PARTIE 1 – Prompt que j’ai utilisé
|
||||
« Peux-tu me donner un exemple de la manière de refaire un backlog non conforme à INVEST ? J’aimerais voir comment identifier les problèmes d’une User Story, puis comment construire un nouveau backlog conforme à INVEST. Ne fais pas l’exercice complet, juste un exemple pour m’aider à comprendre. »
|
||||
|
||||
PARTIE 2 – Réponse donnée par ChatGPT
|
||||
|
||||
Exemple :
|
||||
Ancienne User Story : « En tant qu’utilisateur, je veux une interface moderne pour que ce soit joli. »
|
||||
|
||||
Problèmes INVEST :
|
||||
|
||||
– I : dépend d’autres stories (refonte complète)
|
||||
– N : contenu flou, non négociable
|
||||
– V : valeur métier faible
|
||||
– E : impossible à estimer (« moderne » est subjectif)
|
||||
– S : trop grande
|
||||
– T : non testable
|
||||
|
||||
Backlog corrigé :
|
||||
|
||||
US1 : En tant qu’utilisateur, je veux activer le mode sombre afin d’améliorer le confort visuel.
|
||||
US2 : En tant qu’utilisateur, je veux modifier la taille du texte afin d’adapter l’affichage à mes besoins.
|
||||
US3 : En tant qu’utilisateur, je veux changer la langue de l’interface afin de personnaliser mon expérience.
|
||||
|
||||
-------
|
||||
|
||||
Q3 – Gestion des ruptures de stock dans une boutique en ligne
|
||||
|
||||
PARTIE 1 – Prompt que j'ai utilisé
|
||||
« Peux-tu m’expliquer comment rédiger un processus métier clair en plusieurs étapes, comment compléter un diagramme de classes du domaine avec de nouvelles classes et attributs, et comment écrire un scénario Given/When/Then pour tester une exigence ? Donne-moi juste un exemple pour comprendre la méthode. »
|
||||
|
||||
PARTIE 2 – Exemple de réponse donnée par ChatGPT
|
||||
|
||||
Exemple de processus métier :
|
||||
|
||||
L’utilisateur consulte la fiche d’un produit.
|
||||
Le système affiche le stock disponible.
|
||||
Si le produit est en rupture, le système bloque l’ajout au panier.
|
||||
Le système propose une alerte de remise en stock.
|
||||
Si l’utilisateur accepte, il est inscrit sur la liste d’attente.
|
||||
Lors du réapprovisionnement, le système notifie les utilisateurs inscrits.
|
||||
|
||||
|
||||
Exemple de compléments au DCD :
|
||||
– Classe : AlerteStock, attributs : dateInscription, canalNotification.
|
||||
– Classe : CommandeFournisseur, attributs : dateCommande, quantite, statut.
|
||||
Exemple Given/When/Then :
|
||||
Given un produit en rupture,
|
||||
When l’utilisateur active l’alerte,
|
||||
Then il reçoit une notification lorsque le produit revient en stock.
|
||||
|
||||
-------
|
||||
|
||||
Q4 – Complémentarité entre User Stories et Cas d’utilisation
|
||||
|
||||
PARTIE 1 – Exemple de prompt que j’aurais pu utiliser
|
||||
|
||||
« Peux-tu m’expliquer comment une User Story peut être déclinée en plusieurs cas d’utilisation, et comment expliquer les risques d’un projet qui n’utilise que des User Stories ou seulement des Cas d’utilisation ? Donne-moi juste un exemple pour comprendre la logique générale, sans faire l’exercice complet. »
|
||||
|
||||
PARTIE 2 – Exemple de réponse donnée par ChatGPT
|
||||
|
||||
Exemple :
|
||||
|
||||
User Story : « En tant que client, je veux payer ma commande en ligne afin de la finaliser. »
|
||||
Cas d’utilisation possibles :
|
||||
– Saisir ses informations de paiement
|
||||
– Confirmer le paiement
|
||||
– Obtenir une confirmation de commande
|
||||
Risques si on utilise seulement des User Stories : manque de précision sur les enchaînements et les erreurs.
|
||||
Risques si on utilise seulement des Cas d’utilisation : perte de la notion de valeur métier, backlog impossible à prioriser.
|
||||
|
||||
203
TP_valarcher/controle_tp_191125/Yolou_4/Yolou_4.txt
Normal file
203
TP_valarcher/controle_tp_191125/Yolou_4/Yolou_4.txt
Normal file
@@ -0,0 +1,203 @@
|
||||
Q1 Frontière EF/ENF dépendante du contexte
|
||||
|
||||
Ainsi en voyant cette exemple donné par (Chat GPT - modele 5.1) j'avais un début de piste pour réaliser la question:
|
||||
|
||||
Q1-a :
|
||||
|
||||
Contexte 1 : Application éducative plateforme d’apprentissage (Duolingo) ENF
|
||||
Changer son mot de passe ne fait pas partie du parcours pédagogique.
|
||||
C’est une exigence de sécurité, donc ENF.
|
||||
|
||||
Contexte 2: Plateforme d’investissements / trading (Boursorama / Trading Republic)
|
||||
Dans ce type d’application, une compromission de compte peut faire perdre de l’argent.
|
||||
La notification immédiate fait partie de la protection métier du capital de l’utilisateur.
|
||||
|
||||
Q1-b et Q1-c
|
||||
|
||||
Contexte 1 : Application éducative (type Duolingo)
|
||||
Classification : ENF (exigence non-fonctionnelle)
|
||||
|
||||
Q1-b – Exigence adaptée au contexte éducatif
|
||||
« Lorsqu’un utilisateur modifie son mot de passe, le système doit envoyer une notification push informative dans un délai inférieur à 10 secondes, afin de garantir un niveau de sécurité minimal pour la gestion du compte. La notification doit indiquer la date et l’heure de la modification. »
|
||||
Ici, l’envoi de notification n’est pas lié au cœur du métier (apprendre une langue). C’est uniquement une règle de sécurité.
|
||||
|
||||
Q1-c – Impact sur le backlog (application éducative)
|
||||
Étant une exigence non-fonctionnelle, cette notification n’apparaît pas comme une User Story autonome dans le backlog. Elle sera intégrée comme critère d’acceptation dans une User Story plus large de type « Gérer son compte ». Cette exigence n’a pas de valeur métier directe pour l’utilisateur, ce qui la place à une priorité moindre dans le backlog. Elle ne génère pas de sous-stories, car il s’agit d’une simple contrainte technique ou de sécurité.
|
||||
|
||||
Contexte 2 : Plateforme d’investissement / trading
|
||||
Classification : EF (exigence fonctionnelle)
|
||||
|
||||
Q1-b – Exigence adaptée au contexte investissement/trading
|
||||
« Lorsqu’un utilisateur modifie son mot de passe, le système doit envoyer immédiatement une notification push d’alerte contenant la date, l’heure, l’adresse IP d’origine et un lien permettant de bloquer rapidement le compte en cas d’activité suspecte. Le délai d’envoi de la notification ne doit pas dépasser 5 secondes. »
|
||||
Dans ce contexte, informer l’utilisateur est une fonction métier essentielle, car elle permet de protéger ses actifs.
|
||||
|
||||
Q1-c – Impact sur le backlog (plateforme d’investissement)
|
||||
Cette exigence est une exigence fonctionnelle et devient une User Story à part entière dans le backlog, car elle contribue directement à la protection des capitaux de l’utilisateur. Elle est prioritaire et doit être développée en début de projet. De plus, elle entraîne un découpage en plusieurs User Stories ou sous-tâches (définition du contenu de l’alerte, action de blocage, gestion des logs, délai d’envoi), ce qui augmente la granularité du backlog.
|
||||
|
||||
--------------------------
|
||||
|
||||
Q2 – Refonte d’un backlog non INVEST
|
||||
|
||||
Début de réponse que j’ai écrit que j'ai commencé à rédiger :
|
||||
|
||||
Q2-a – Début de réponse
|
||||
Pour la question 2-a, j’ai commencé par relire les trois User Stories données. J’ai remarqué qu’elles sont toutes formulées de manière assez large, et on voit déjà que certaines expressions comme “tableau de bord complet” ou “interface moderne” semblent poser problème. Je pense que ces US ne respectent pas vraiment les critères INVEST, mais je dois encore préciser exactement lesquels et pourquoi.
|
||||
|
||||
Q2-b – Début de réponse
|
||||
Pour la partie 2-b, j’ai essayé de réfléchir à plusieurs User Stories plus simples et plus précises. Mon idée est de partir des mêmes besoins mais en les divisant en fonctionnalités plus petites. J’ai déjà quelques pistes, par exemple sur l’affichage des tâches ou la gestion des comptes, mais il faut que je les reformule correctement au format US.
|
||||
|
||||
Q2-c – Début de réponse
|
||||
Pour la partie 2-c, je commence à réfléchir aux critères d’acceptation possibles pour certaines des nouvelles User Stories. Pour l’instant, je me dis qu’il faudrait au moins deux critères clairs et testables, mais je dois choisir les US les plus adaptées avant de définir ces critères.
|
||||
|
||||
En utilisant ce modèle, j’ai commencé à analyser les User Stories du sujet.
|
||||
|
||||
Réponse finale complète de mes questions à la Q2 grâce à l'aide de l'IA (Chat GPT - modele 5.1):
|
||||
|
||||
Q2-a – Identification des problèmes dans les User Stories
|
||||
|
||||
US1 : « En tant qu’utilisateur, je veux un tableau de bord complet avec une vue globale de toutes mes activités. »
|
||||
|
||||
Problèmes INVEST :
|
||||
|
||||
– I : dépend d’autres fonctionnalités
|
||||
– S : trop large (« complet », « global »)
|
||||
– T : non testable sans préciser les informations attendues
|
||||
– E : non estimable, périmètre flou
|
||||
– V : valeur métier non explicite
|
||||
|
||||
US2 : « En tant qu’utilisateur, je veux une interface moderne afin d’améliorer mon expérience. »
|
||||
|
||||
Problèmes INVEST :
|
||||
|
||||
– V : valeur métier non définie
|
||||
– E : non estimable (« moderne » est subjectif)
|
||||
– T : non testable
|
||||
– S : trop large (design, navigation, composants)
|
||||
|
||||
US3 : « En tant qu’administrateur, je veux gérer tout le système efficacement. »
|
||||
|
||||
Problèmes INVEST :
|
||||
|
||||
– S : trop grande (« tout le système »)
|
||||
– I : dépend de multiples fonctionnalités (utilisateurs, contenus…)
|
||||
– T : impossible à tester
|
||||
– E : impossible à estimer, périmètre trop vaste
|
||||
|
||||
Q2-b – Nouveau backlog contenant au moins 6 User Stories INVEST
|
||||
|
||||
US-A : En tant qu’utilisateur, je veux consulter la liste de mes tâches du jour afin de commencer rapidement mon travail.
|
||||
US-B : En tant qu’utilisateur, je veux filtrer mes tâches par projet afin de visualiser uniquement celles qui me concernent.
|
||||
US-C : En tant qu’utilisateur, je veux afficher mes tâches en retard afin d’identifier mes priorités.
|
||||
US-D : En tant qu’utilisateur, je veux activer un mode clair ou sombre afin d’ajuster le confort visuel.
|
||||
US-E : En tant qu’administrateur, je veux créer un compte utilisateur afin d’ajouter un nouveau collaborateur à la plateforme.
|
||||
US-F : En tant qu’administrateur, je veux désactiver un compte utilisateur afin de retirer l’accès à un collaborateur quittant l’entreprise.
|
||||
|
||||
Q2-c – Critères d’acceptation (pour deux User Stories du backlog corrigé)
|
||||
|
||||
Story X – US-A : « Consulter la liste de mes tâches du jour »
|
||||
|
||||
Critère 1 : La section « Aujourd’hui » affiche uniquement les tâches avec une date d’échéance correspondant à la date du jour.
|
||||
Critère 2 : Si aucune tâche n’est prévue pour aujourd’hui, l’application affiche le message « Aucune tâche pour aujourd’hui ».
|
||||
|
||||
Story Y – US-F : « Désactiver un compte utilisateur »
|
||||
|
||||
Critère 1 : Lorsqu’un administrateur désactive un compte, l’utilisateur concerné ne peut plus se connecter et le message « Compte désactivé » apparaît.
|
||||
Critère 2 : Les tâches précédemment assignées à cet utilisateur restent visibles dans l’historique, mais le compte apparaît comme « désactivé ».
|
||||
|
||||
Q3 – Gestion des ruptures de stock dans une boutique en ligne
|
||||
|
||||
Début de réponse que j’ai écrit que j'ai commencé à rédiger :
|
||||
|
||||
Q3-a – Début de réponse
|
||||
|
||||
Pour le début de la question 3-a, j’ai essayé de reconstituer le processus métier lié à la rupture de stock. Je vois qu’il faut décrire les étapes dans l’ordre logique, en partant du moment où le client consulte le produit jusqu’à la remise en stock. J’ai quelques premières idées mais il faut encore organiser les étapes de façon plus précise.
|
||||
|
||||
Q3-b – Début de réponse
|
||||
|
||||
Pour la partie 3-b, j’ai regardé le diagramme du domaine fourni. Je pense qu’il manque certaines classes importantes, surtout pour gérer les alertes et les commandes fournisseurs. Je dois encore déterminer exactement quelles classes et quels attributs ajouter.
|
||||
|
||||
Q3-c – Début de réponse
|
||||
|
||||
Pour le Given/When/Then, je comprends qu’il faut prendre un scénario précis autour de la remise en stock. J’ai déjà imaginé un cas où un produit est en rupture et où un utilisateur est inscrit à l’alerte, mais je dois formaliser ça correctement dans le format attendu.
|
||||
|
||||
|
||||
Réponse finale complète de mes questions à la Q3 grâce à l'aide de l'IA (Chat GPT - modele 5.1):
|
||||
|
||||
Q3-a – Rédaction du processus métier (au moins 8 étapes)
|
||||
|
||||
Le client consulte la page d’un produit dans la boutique en ligne.
|
||||
Le système vérifie le niveau de stock du produit.
|
||||
Si le stock est positif, le système permet l’ajout normal au panier.
|
||||
Si le produit est en rupture, le système empêche l’ajout au panier et affiche un message d’indisponibilité.
|
||||
Le système propose alors au client de s’inscrire à une alerte de remise en stock.
|
||||
Si le client accepte, le système enregistre une demande d’alerte associée au client et au produit.
|
||||
En parallèle, lorsque le stock atteint le seuil de rupture, le système génère automatiquement une commande fournisseur et l’associe au service logistique pour suivi.
|
||||
Lorsque l’employé logistique enregistre la réception de la commande fournisseur, le système augmente le stock du produit.
|
||||
Dès que le produit redevient disponible, le système déclenche une notification (email ou push) pour tous les clients inscrits à l’alerte.
|
||||
|
||||
|
||||
Q3-b – Modifications à apporter au Diagramme de Classes du Domaine
|
||||
|
||||
Nouvelles classes :
|
||||
|
||||
– AlerteRuptureStock
|
||||
– CommandeFournisseur
|
||||
|
||||
Nouveaux attributs pertinents :
|
||||
|
||||
– Produit : stockDisponible, stockSeuilRupture, etatDisponibilite
|
||||
– AlerteRuptureStock : dateInscription, canalNotification
|
||||
– CommandeFournisseur : dateCommande, quantiteCommande, statutCommande
|
||||
|
||||
Ces ajouts permettent de représenter les processus de rupture, de réapprovisionnement et de notification.
|
||||
|
||||
Q3-c – Scénario de test d’acceptation (Given / When / Then)
|
||||
|
||||
Given un produit dont le stockDisponible est égal à 0 et un client inscrit à l’alerte de remise en stock,
|
||||
When l’employé logistique enregistre la réception d’une commande fournisseur augmentant le stock du produit,
|
||||
Then le système met à jour l’état du produit à “disponible” et envoie une notification au client inscrit pour l’informer de la remise en stock.
|
||||
|
||||
Q4 – Complémentarité entre User Stories et Cas d’utilisation
|
||||
|
||||
Début de réponse que j’ai écrit que j'ai commencé à rédiger :
|
||||
|
||||
Q4-a – Début de réponse
|
||||
|
||||
Pour la question 4-a, j’ai commencé par choisir une User Story autour de la commande en ligne. Je vois comment cette US peut être déclinée en plusieurs cas d’utilisation, mais je dois encore faire la liste complète des actions qui en découlent.
|
||||
|
||||
Q4-b – Début de réponse
|
||||
|
||||
Pour la partie 4-b, j’ai essayé d’identifier les problèmes d’un projet basé uniquement sur les User Stories. Je vois déjà que cela peut créer des zones floues, mais il faut que je développe mieux ces idées.
|
||||
|
||||
Q4-c – Début de réponse
|
||||
|
||||
Pour la dernière sous-question, j’ai réfléchi aux risques inverses, c’est-à-dire un projet basé seulement sur des cas d’utilisation. Je pense que cela pose des problèmes de priorisation et de valeur métier, mais je dois encore formuler tout ça plus clairement
|
||||
|
||||
Réponse finale complète de mes questions à la Q3 grâce à l'aide de l'IA (Chat GPT - modele 5.1) :
|
||||
|
||||
Q4-a – Exemple de User Story et cas d’utilisation dérivés
|
||||
|
||||
User Story choisie :
|
||||
|
||||
« En tant que client, je veux passer une commande en ligne afin de recevoir mes produits à domicile. »
|
||||
Cas d’utilisation dérivés :
|
||||
– Consulter un produit et l’ajouter au panier
|
||||
– Modifier le contenu du panier
|
||||
– Saisir une adresse de livraison
|
||||
– Choisir un mode de livraison
|
||||
– Sélectionner un moyen de paiement
|
||||
– Valider la commande
|
||||
– Recevoir un récapitulatif de commande
|
||||
|
||||
Q4-b – Risques d’un projet qui ne repose que sur des User Stories
|
||||
|
||||
Un projet qui se limite uniquement aux User Stories risque de ne pas décrire précisément les enchaînements d’actions et les scénarios alternatifs, ce qui peut provoquer des ambiguïtés lors du développement. Les comportements attendus en cas d’erreur ou d’exception ne sont pas explicités, ce qui entraîne des implémentations différentes selon les développeurs. L’absence de scénarios détaillés complexifie également les tests, car il devient difficile de valider le comportement complet du système.
|
||||
|
||||
Q4-c – Risques d’un projet qui n’utilise que des Cas d’utilisation
|
||||
|
||||
Se baser seulement sur des Cas d’utilisation peut conduire à ignorer la notion de valeur métier et de priorisation. Tous les cas apparaissent alors sur le même niveau d’importance, ce qui rend le backlog difficile à organiser pour un développement itératif. L’équipe risque de se concentrer sur la complétude documentaire plutôt que sur la livraison de fonctionnalités ayant un impact direct pour l’utilisateur. Cela augmente le risque de retard et d’alignement insuffisant avec les besoins réels du métier.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Reference in New Issue
Block a user