feat: add project introduction course

content/conduite_projet/1_intro/index.md

@@ -0,0 +1,104 @@
+---
+title: "Conduite de projet: introduction"
+date: 2024-09-10
+tags: [""]
+categories: ["Conduite de projet", "Cours"]
+mathjax: true
+---
+
+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 mise en production** pour assurer la production (exploitation).
+
+ Mener à bien ces différents projets est un long chemin, il est facile de se
+ perde surtout *si les contours sont flous*. Et pour ça nous allons avoir
+ besoin d'un peut de **formalisme**.
+
+## Projet de développement
+
+ 1. Tout part **d'un utilisateur** qui a un besoin, il peut ne pas en être 
+    conscient ou l'exprimer.
+ 2. Le **propriétaire** (ou le *producteur*) exprime ce besoin dans un *cahier
+    des charges*.
+ 3. Le **développeur** va spécifier le besoin dans *la réponse au cahier des
+    charges*
+ 4. Le **propriétaire** accepte la réponse.
+ 5. Le **développeur** réalise le développement et le livre.
+ 6. Le **propriétaire** mets à disposition le logiciel à *l'utilisateur*
+
+Nous utilisons les termes de *MOA* pour *Maître d'ouvrage* (le propriétaire) et
+*MOE* pour *Maître d'œuvre* (le développeur).
+
+Le cycle de développement se décompose en 3 phases:
+
+ 1. **l'analyse**: le *MOE* spécifie ce qu'il peut réaliser, mais aussi ce qu'il
+    ne peut pas;
+ 2. **la conception**: le *MOE* organise son développement;
+ 3. **le développement**: le *MOE* développe les différents composants.
+
+## L'analyse
+
+Le cahier des charge représente un peu *la lettre au père noël* du *MOA* au
+*MOE*. Ce dernier doit alors spécifier ce qu'il est capable de réaliser mais
+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.
+
+## La conception
+
+C'est l'écriture du code des différents composants de l'application, il y a
+alors plusieurs points de vies:
+
+ * application **monolithique**;
+ * composition en **modules**, ils permettent aussi de découper en tâche. Il
+   faut aussi définir les différentes interactions entre les modules.
+
+Il faut aussi choisir **une architecture** (3 tiers, en couche, par service).
+
+## Les besoins
+
+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)
+
+