Document d'Architecture et de Justification Technique de la Solution Logicielle

Je souhaite vous faire part du le seul document que je souhaiterais trouver systématiquement quand j'aborde la reprise d'un logiciel existant. Un seul document en dehors du code pour comprendre la genèse de la solution logicielle face à laquelle je me trouve.

Et pourtant ce document n'existe que très rarement, il est souvent en morceaux dans d'autres documents de la Qualité Logicielle, je veux vous parler du Document de Justification Technique (DJT).

Wikipédia - Architecture Logicielle

La qualité logicielle, suivant la méthodologie que vous utilisez, préconise un tas de documents suivant le référentiel mais il y a un document que je ne trouve jamais qui me parait pourtant le seul utile à un nouvel arrivant sur un projet logiciel, c'est le Document d'Architecture et de Justification Technique.

On vous parlera du DAT - Document d’Architecture Technique qui est le document réalisé par l'architecte technique au démarrage du projet dans lequel il décrit les briques de base et leurs imbrications dans la réalisation de la solution.

A l'instant donné du démarrage d'un projet, je peux concevoir que l'architecte ne se soit pas posé trop de questions sur la maintenance et les évolutions dans le temps de la solution qu'il met en place mais quelques années après, lorsque j'arrive pour reprendre ou continuer la solution, ce document ne me suffit pas. 

Le DAT est l'image du projet à son démarrage et je souhaiterais absolument savoir pourquoi le choix de ces briques de base ont été faits au début du projet.

Au démarrage du projet l'architecte a fait ses choix de briques car il les connait, les maîtrise, sait comment les mettre en oeuvre, son DAT porte ainsi sa vision de la solution mais avec de l'expérience et du recul, vous savez qu'il en existe d'autres, peut être mieux adaptées, plus facile à maintenir, à mettre en oeuvre. 

C'est là que la partie "justification technique" de ce document est très importante.

Ajout de la Justification Technique au DAT

Par exemple l'architecte de la solution peut très bien écrire, je préconise d'utiliser la brique untel car c'est la seule qui existe pour résoudre cette problématique. Il peut également écrire, nous avions à notre disposition la brique 1 et 2 ou 3 pour telle raison, j'ai choisie la 1.

Quand vous arrivez quelques années après, vous savez alors pourquoi le choix de telle brique a été fait à l'époque. 

Depuis d'autres briques sont apparues sont peut être mieux adaptées mais vous savez alors pourquoi elles n'ont pas été utilisées dans cette solution soit parce qu'elles n'existaient pas soit parce que l'Architecte ne les connaissait pas mais vous connaissez la justification technique du choix qui a été fait.

Donc le Document d'Architecture Technique ne suffit pas, il faut y ajouter les briques envisagées au démarrage du projet, et justifier les choix de telle ou telle brique logicielle, plutôt que telle autre pour que la solution logicielle soit maintenable, reprenable et pérenne.

J'ajoute que même si aujourd'hui dans les plans de DAT on trouve maintenant parfois :

"Vous définissez votre choix et expliquer les raisons qui vont ont poussé à le faire, en citant quelques alternatives possibles."

Vous verrez que dans la pratique sur les différents DAT que vous aurez l'occasion de lire, vous ne trouverez pas cette notion de justification de la solution technique.