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 leur imbrication 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 mais quelques années après lorsque j'arrive pour reprendre ou continuer la solution, ce document ne me suffit pas car il est l'image du projet à son démarrage et je souhaiterais absolument savoir pourquoi ces choix de briques de base ont été faits.

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.

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. Quand vous arrivez quelques années après vous savez pourquoi ce choix a été fait à l'époque et depuis d'autres briques sont apparues sont peut être mieux adaptées mais vous savez pourquoi elles ne sont pas utilisées dans cette solution.

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.