Un projet informatique est développé conjointement par deux équipes : la maîtrise d’ouvrage et la maîtrise d’oeuvre.
La maîtrise d’ouvrage (MOA) est le client ou le représentant des utilisateurs. Si nous faisons un parallèle avec une maison, ce serait la personne qui passe commande. « Je veux une maison jaune avec un toit rouge et un lutin qui hoche la tête béatement ».
La maîtrise d’œuvre (MOE) sera l’équipe chargée de réaliser la vision de la maîtrise d’ouvrage. Face à la demande précédente, elle répondra certainement « Nous utiliserons de la brique et une dalle en béton. La peinture sera sans ammoniaque. Quant au lutin… Ce n’est pas vraiment de notre domaine, désolé ».
Il arrive parfois que le client ne soit pas formé en gestion de projet et qu’il fasse appel à des prestataires dont c’est le métier. Nous parlons alors d’assistance à maîtrise d’ouvrage (AMOA).
Bien. Nous savons un peu mieux qui intervient sur le projet. Voyons maintenant les différentes phases et les documents produits.
Etape 1 : définition du projet
La maîtrise d’ouvrage écrit les spécifications fonctionnelles (“requirements” en anglais). Il s’agit d’un (long) document détaillant point par point tous les comportements de l’application. Nous pouvons le voir comme la Bible du projet : développeurs, chefs de projet, rédacteurs, bref, tout le monde y aura recours en cas de doute. Il faut le peaufiner !
Nous les verrons en détail un peu plus tard dans la partie suivante.
Etape 2 : conception de l’architecture
Une fois que les spécifications fonctionnelles sont écrites, la maîtrise d’oeuvre écrit les spécifications techniques et conçoit l’architecture globale de l’application.
À la différence des spécifications fonctionnelles, qui se concentrent sur l’utilisation de l’application, les spécifications techniques ont pour objectif de définir le cadre technique du projet. Plus ou moins poussées, elles seront une base de travail solide pour les développeurs.
En parallèle, le chef de projet technique conçoit l’architecture en s’aidant de diagrammes UML. Une validation est réalisée par le client et le chef de projet fonctionnel.
Etape 3 : écriture du code
C’est au tour des développeurs d’entrer sur la scène ! Ils se basent sur les spécifications et sur le diagramme pour produire le code demandé.
Etape 4 : recette
La dernière phase a pour objectif de vérifier que l’application fonctionne comme il se doit. Des tests manuels peuvent être effectués mais, en règle générale, nous préférons utiliser les pouvoirs de l’informatique pour automatiser au maximum ces vérifications. Nous utilisons notamment des tests unitaires.
Qu'est-ce qu'un test unitaire ?
Chaque test unitaire a pour but de vérifier qu’une partie de l’application produit bien le résultat attendu quand un certain événement a lieu. Nous pouvons vérifier, par exemple, que le formulaire n’est pas envoyé si l’utilisateur n’a pas renseigné son prénom. Automatiser les tests fait gagner beaucoup de temps !
Puis le maître d’ouvrage réalise des tests de recette, c’est-à-dire qu’il va tester manuellement que l’application correspond à ce qui a été demandé.
Une méthodologie de projet séquentielle permet de réaliser ces phases les unes après les autres dans un ordre chronologique. L’objectif de chaque phase est avant tout un document à remettre, plus que des fonctionnalités. Le logiciel n’est testé qu’à la fin et le client commence à voir les résultats du travail de préparation parfois plusieurs mois après le démarrage du projet.
Qu’est-ce qu’une fonctionnalité ?
Il s’agit d’une petite partie d’un programme qui répond au besoin de l’utilisateur. Voici quelques exemples de fonctionnalités :
- Paiement par Paypal
- Compte utilisateur
- Carte affichant les maisons qui ont un toit orange
- ...
Suivre cette approche séquentielle à la lettre signifie avoir :
100% des spécifications fonctionnelles avant de commencer la conception,
100% des spécifications techniques avant de commencer le code,
100% du code avant de commencer les tests.
Pas évident, dans ce cas, de modifier des éléments en cours de route ! C’est un modèle idéal mais irréaliste. Dans la réalité, on revient souvent aux phases précédentes, notamment pendant la phase de test qui implique de réécrire du code pour corriger des défauts, donc de retravailler la conception et par conséquent de modifier les spécifications fonctionnelles.
De plus, les contrôles tout au long du projet sont difficiles à faire car ils portent sur une multitude de documents qui peuvent devenir très vite assommants. Les développeurs peuvent manquer de motivation, la déprime s’installe. Bref, tout va mal ma bonne dame.
Que faire, mais que faire ? Est-on condamné à cette approche ?
Non, bien entendu, mais vous le saviez déjà ! Les méthodologies de projet agiles sont justement apparues pour résoudre ces problèmes.
--------
Crédits illustrations :
Carte : Lloyd Humphreys
Diapo : Icon Fair
Ordi : Nopixel
Developpeurs·ses : Oksana Latysheva
Bug : Chris Homan
Ampoule : Arved Bünning
Gracieusement fournises par The Noun Project.
