- Interventions de l'équipe projet -

En fonction de l'importance de la modification ou de la correction à réaliser, le cycle de développement peut reprendre à différents niveaux.

S'il s'agit d'une demande de modification qui met en cause certaines fonctions, on reprendra le cycle au départ c'est-à-dire dès la phase de définition.

S'il s'agit d'une anomalie importante, on pourra reprendre la phase de conception pour modifier une classe, une méthode ou la logique de l'IHM.

Dans la plupart des cas, il s'agira d'erreurs minimes de programmation qui pourront être directement corrigées au niveau du codage.

Le diagramme d'activités ci-dessous montre quels sont les différents cas rencontrés lors de la phase de tests-utilisateurs. Dans tous les cas, la phase d'intégration doit être suivie d'une opération de tests de non-régression qui permettent de vérifier que les modifications apportées n'ont pas introduit de nouvelles anomalies.

Dans le cas où il est nécessaire de reprendre la phase de définition, le Dossier de Définition Prototype (DDP) devra être mis à jour. Il en est de même pour le Dossier de Réalisation Prototype (RDP) dans le cas où la phase de conception doit être reprise.

Livraison des nouvelles versions

Afin d'éviter des aller-retour incessants entre les valideurs et l'équipe projet on cherchera à regrouper plusieurs corrections et modifications dans une même livraison qui constituera une "version" du prototype. Ce principe ne s'applique pas dans les cas de correction d'anomalies bloquantes qui nécessitent un retour rapide vers les valideurs afin qu'ils puissent poursuivre leurs tests.

C'est l'équipe projet qui décidera à quel moment ils livreront une nouvelle version en fonction du nombre et de la nature des interventions à réaliser. Il faudra simplement veiller à ce qu'un délai trop important ne sépare deux livraisons afin que les valideurs aient suffisamment de temps pour vérifier les corrections ou les modifications apportées. Chaque livraison concernera tous les valideurs qui doivent installer la nouvelle version.

L'ensemble des éléments livrés constitue un lot comportant :

• les fichiers à installer,
• une procédure d'installation,
• une nouvelle version éventuelle du MUP ou du GIP,
• éventuellement un ou plusieurs programmes de récupération des données (moulinette),
• un document descriptif du lot.

En ce qui concerne les fichiers livrés, on peut alors envisager deux philosophies. La première consiste à livrer dans chaque lot la totalité des fichiers afin d'éviter d'avoir à développer une procédure spéciale d'installation. En effet, dans ce cas la procédure d'installation initiale peut être chaque fois appliquée de façon identique. La deuxième philosophie consiste à ne livrer que les fichiers modifiés pour limiter le volume de données expédié. Ce cas ne se justifie que si les fichiers sont envoyés par le réseau en fichiers attachés dans un mail, ou par FTP. On peut par exemple utiliser la première philosophie pour livrer une version touchant un nombre important de fichiers, et la seconde dans l'autre cas ou pour livrer rapidement la correction d'une anomalie bloquante.

Si une nouvelle version entraîne un changement de formats de certaines données persistantes (fichiers ou base de données), on pourra être amené à joindre au lot une moulinette de récupération des données existantes afin d'éviter que les valideurs n'aient à re-saisir une quantité importante de données. Cet aspect sera d'autant plus sensible que l'on avancera dans les versions et surtout dans les prototypes.

Le document descriptif de lot est l'équivalent d'un bon de livraison qui détaille le contenu du lot : fichiers livrés, modifications ou corrections prises en compte dans le lot faisant référence à la FAP ou la FMP correspondante, nouveaux formats des données persistantes, etc.