cours/content/conduite_projet/1_intro/index.md

title	date	tags	categories	mathjax
Conduite de projet: introduction	2024-09-10		Conduite de projet Cours	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)