From 7ca4460a8d699312be4242766d2a7e98bb966379 Mon Sep 17 00:00:00 2001 From: Yorick Barbanneau Date: Tue, 24 Sep 2024 22:31:36 +0200 Subject: [PATCH] refactor: move needs part from intro to its own part --- content/conduite_projet/1_intro/index.md | 50 +++------------------- content/conduite_projet/2_besoins/index.md | 49 +++++++++++++++++++++ 2 files changed, 55 insertions(+), 44 deletions(-) create mode 100644 content/conduite_projet/2_besoins/index.md diff --git a/content/conduite_projet/1_intro/index.md b/content/conduite_projet/1_intro/index.md index 61072e5..72d527f 100644 --- a/content/conduite_projet/1_intro/index.md +++ b/content/conduite_projet/1_intro/index.md @@ -1,7 +1,7 @@ --- title: "Conduite de projet: introduction" -date: 2024-09-10 -tags: [""] +date: 2024-09-16 +tags: ["besoins", "conception"] categories: ["Conduite de projet", "Cours"] mathjax: true --- @@ -10,7 +10,7 @@ Les projets informatiques peuvent prendre plusieurs formes: * **Projet de développement logiciel** pour livrer la première version utilisable du logiciel. - * **Projet de tierce maintenance applicatice** pour en assurer la maintenance. + * **Projet de tierce maintenance applicative** pour en assurer la maintenance. * **Projet de mise en production** pour assurer la production (exploitation). Mener à bien ces différents projets est un long chemin, il est facile de se @@ -47,7 +47,8 @@ aussi **le chiffrer**. Le *MOE* peut refuser de aire telle ou telle spécification du budget et de ses capacités. Au niveau du chiffrage, on évalue en **jour/homme**, c'est une tâche qui demande -de l'expérience car semée de pièges. +de l'expérience car semée de pièges. Par exemple, il est souvent pas possible de +factoriser, en effet 2 jours/homme ne signifie pas 2 fois 1 jour/homme. ## La conception @@ -60,45 +61,6 @@ alors plusieurs points de vies: Il faut aussi choisir **une architecture** (3 tiers, en couche, par service). -## Les besoins - -Nous pouvons utiliser la méthode sur **6 artefacts**: +Nous pouvons utiliser la méthode sur **6 artefacts**: ![Schéma: les six artefacts](./imgs/6_artefacts.svg) - -L'expression des besoin contient elle aussi des pièges: - - * les besoins fantômes; - * les besoins mal exprimés. - -Un besoin se caractérise par deux stades: - - 1. en cours de rédaction; - 2. rédigé et en attente de qualification. - -6 bonnes pratiques: - - * un besoin doit être identifié par un numéro de besoin - * un besoin doit être précis - * un besoin doit être qualifié (type, difficulté, priorisé) - * un besoin doit être planifié (échéance, unité de temps) - * un besoin doit être clos (à un moment donné) - * les besoins doivent être homogénéisés - -Nos besoins contiennent dont un *identifiant*, une *description*, un *objectif* -et un *contrôle*. Il faut absolument **tuer tout espace laissé au flou et à -l'interprétation**. Nous avons besoin de précision. - -**Homogénéiser**: chacun des besoins doivent avoir le même point de vue, exprimé -de la même façon avec la même granularité. - -Un besoin doit être **priorisé** selon 3 critères: `élevé`, `normal`, `bas` - -### 4 types de besoins - - * Nouvelle fonctionnalité. - * Bugfix / amélioration - * Amélioration de performances - * Refactoring (visibilité du code) - - diff --git a/content/conduite_projet/2_besoins/index.md b/content/conduite_projet/2_besoins/index.md new file mode 100644 index 0000000..462815a --- /dev/null +++ b/content/conduite_projet/2_besoins/index.md @@ -0,0 +1,49 @@ +--- +title: "Conduite de projet: les besoins" +date: 2024-09-16 +tags: ["besoins", "conception"] +categories: ["Conduite de projet", "Cours"] +mathjax: true +--- +Une fois le cahier des charge et les spécifications effectué, nous pouvons +passer aux besoins. + +Mais attention, l'expression des besoin contient des pièges: + + * les besoins fantômes; + * les besoins mal exprimés. + +Un besoin se caractérise par deux stades: + + 1. en cours de rédaction; + 2. rédigé et en attente de qualification. + +6 bonnes pratiques: + + * un besoin doit être identifié par un numéro de besoin + * un besoin doit être précis + * un besoin doit être qualifié (type, difficulté, priorisé) + * un besoin doit être planifié (échéance, unité de temps) + * un besoin doit être clos (à un moment donné) + * les besoins doivent être homogénéisés + +Nos besoins contiennent dont un *identifiant*, une *description*, un *objectif* +et un *contrôle*. Il faut absolument **tuer tout espace laissé au flou et à +l'interprétation**. Nous avons besoin de précision. + +Ils doivent être auto-contenus. + +**Homogénéité**: chacun des besoins doivent avoir le même point de vue, exprimé +de la même façon avec la même granularité. Il ne faut **laisser aucune place au +flou et à l'interprétation**. + +Un besoin doit être **priorisé** selon 3 critères: `élevé`, `normal`, `bas` + +### 4 types de besoins + + * Nouvelle fonctionnalité. + * Bugfix / amélioration + * Amélioration de performances + * Refactoring (visibilité du code) + +Une fois les besoins définis, nous passer aux tâches.