Comment tracer les tests, la recette et les décisions d'architecture d'un projet ?
D’après Gestion de projets avec DYNAMAP SI
Les preuves de test et les décisions d'architecture permettent de comprendre ce qui a été vérifié et pourquoi certains choix ont été retenus. Elles doivent rester reliées aux livrables, aux critères d'acceptation et aux éventuelles réserves.
Tests, recette et preuves (Quality / Stakeholder)
La recette ne doit pas être un événement final, elle doit être une mécanique d’acceptation progressive.
Vous organisez :
- Tests unitaires et intégration
- Tests de non-régression
- Tests de performance / sécurité si requis
- Recettes métier par scénarios
- Gestion des anomalies (tri, correction, acceptation de dette)
Livrable : dossier de preuves (résultats de tests, PV de recette intermédiaires), et liste de non-conformités résiduelles arbitrées.
Décisions d’architecture tracées (Intégration / Scope / Risk)
La mise en œuvre génère des décisions : choix de pattern d’intégration, modèle de données, stratégie de migration, exigences non fonctionnelles, compromis sur la dette.
Ces décisions doivent être tracées, sinon elles ressurgissent en incident ou en désaccord lors de la bascule.
Pratique recommandée : un journal d’Architecture Decision Records (ADR) : décision, contexte, options, justification, impacts, date, propriétaire.
Ceci crée un socle de gouvernance technique cohérent avec le portefeuille.