104 lines
3.6 KiB
Markdown
104 lines
3.6 KiB
Markdown
---
|
|
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**:
|
|
|
|
|
|
|
|
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)
|
|
|
|
|