1°/ Objectif
Le but de ce rapport est de faire un bilan technique de l'application qui a été développée, afin de servir de référence pour une reprise et/ou extension future. Il doit donc contenir tous les éléments techniques qui permettent à un développeur de reproduire l'architecture logicielle et matérielle de l'application, mais également des explications sur comment ont été codées les fonctionnalités principales.
Comme tout rapport technique, le style doit être impersonnel et intemporel. Des expressions telles que "nous avons fait ci ou ça, il a fallu, ..." sont donc à proscrire totalement. De plus, il doit être centré sur l'application et non pas le fait que cette application a été produite dans le cadre d'une SAÉ. De fait, il ne doit pas y avoir de mention de la SAÉ et de ses objectifs (à savoir reprendre un prototype), juste ce qui concerne votre application.
2°/ Contenu
2.1°/ Introduction
L'introduction doit présenter les objectifs de l'application, avec les contextes principaux d'utilisation. Pour ce faire, vous pouvez repartir du premier rapport du S5, en précisant/changeant les points qui ont évolué. Même si vous ne devez pas faire une description fonctionnelle précise façon cahier des charges, cette introduction doit déjà donner des éléments sur les différentes parties de l'application, lesquelles vont être reliées, lesquelles vont être utilisées par des acteurs, et dans quel but. En revanche, la descriptions détaillées de ces éléments est faite dans les sections suivantes.
2.2°/ Structure logicielle et matérielle globale
Cette partie décrit quelles sont les parties principales de l'application et quelles sont leurs interactions, par exemple à l'aide d'un schéma commenté du type de celui de l'application prototype. Il n'y a pas besoin de donner des détails fonctionnels sur chaque partie, il suffit de préciser leur nature (par ex, serveur Java, BdD Mongo, ...) et si il y a lieu, de préciser comment elles sont liées : qui envoie à qui, pour demander quoi (= nature des données) et comment (= quel protocole).
2.3°/ Contexte logiciel et matériel
Cette partie décrit en détail les éléments matériels et logiciels qui sont nécessaire à l'application. Le lecteur doit retrouver dans cette partie les informations précises lui permettant de recréer le contexte logiciel et matériel pour travailler sur l'application et continuer son développement. Il faut donc décrire, entre autres :
- les différents logiciels, plugins, modules, etc. utilisés pour le développement de l'application, avec :
- à quoi ils servent,
- leur version,
- où les trouver,
- la procédure d'installation et configuration.
- les sources de l'application, avec :
- à quoi ils servent dans l'application (= quelle(s) partie(s) )
- les liens/façons de les télécharger,
- la procédure d'installation et configuration.
- si besoin, comment créer et configurer les projets associés aux différentes parties de l'application dans des outlis d'aide au développement
- les différents logiciels, plugins, modules, etc. utilisés pour le déploiement et l'exécution de l'application, avec :
- à quoi ils servent,
- leur version,
- où les trouver,
- la procédure d'installation et configuration.
- les procédures de compilation, conteneuristation, déploiement et d'exécution des différentes parties de l'application.
- ...
2.4°/ Descriptif technique
Cette partie doit présenter, pour chaque partie de l'application, les éléments techniques informatique qui sont les plus importants, en supposant que le lecteur a une connaissance basique, mais pas nulle, des langages/bibliothèques utilisés pour coder chaque partie. Par exemple, on suppose que le lecteur sait comment écrire un sketch arduino, coder en Java/python/node, connaît les principes des bases mongodb, des API en node+express etc. En revanche, on suppose que le lecteur n'est pas forcément formé sur des points bien plus précis et moins communs, tels que : interagir entre java et mongodb, utiliser http en java, faire de l'analyse de média, etc. De même, le lecteur n'est pas censé connaître ce qui est propre à l'application. Par exemple, même s'il sait comment développer une API node+express, il ne peut pas connaître à l'avance les routes de l'application, ni si la structuration des fichiers suit la même logique que celle qu'il connaît.
C'est pourquoi, dans chaque sous-section traitant d'une partie de l'application, il faut décrire, entre autre :
- les répertoires principaux,
- quels types de fichiers ils contiennent,
- pour quelles fonctionnalités/objectifs servent ces fichiers.
Pour le dernier point, inutile d'être trop précis. Il suffit que le lecteur puisse comprendre sur quels fichiers il doit intervenir s'il veut modifier/étendre l'application. Exemple sur le serveur de centralisation de données : "l'interface DataDriver déclare les méthodes permettant de faire une requête pour obtenir/stocker des données. Pour ajouter de nouvelles requêtes, il suffit de déclarer d'autres méthodes dans cette classe et de les implémenter dans HttpDataDriver et MongoDataDriver qui sont les deux classes permettant de lancer ces requêtes respectivement auprès d'une API ou directement sur le serveur mongo. Il est également possible de créer d'autres classes implémentant DataDriver, par exemple afin d'interroger d'autres types de serveur"
Cependant dans certains cas, il convient de descendre au niveau des fonctions et de décrire leur objectif/fonctionnement, notamment quand il y a des interactions complexes entre elles alors qu'elles ont un rôle central dans une partie de l'application. Par exemple, si l'analyse de média fait appel à plein de fonctions se trouvant dans différent fichiers, il est pertinent de faire un diagramme/organigramme pour expliquer les relations entre ces fonctions et expliquer le pourquoi et le comment de l'analyse. Idem pour le µC.
Certaines parties doivent également contenir des descriptifs spécifiques :
- la partie API doit décrire les routes, avec au moins le type de requête, le chemin, quel type d'information est demandé à la BdD et renvoyé au client. La structure des données reçues/renvoyées peut être mis en annexe, bien qu'il soit préférable qu'elle soit documentée au travers d'un outil tel que swagger.
- la partie BdD doit décrire les modèles de document,
- la partie micro-contrôleur doit décrire le côté "électronique", avec notamment :
- la présentation du µC,
- les modules utilisés, à quoi il servent, et si pertinent comment ils communiquent avec le µC,
- le schéma électrique (avec les pins connectées)
A tout cela, vous devez ajouter tout ce qui est spécifique à votre application et que vous estimez nécessaire pour qu'un "novice" puisse la reprendre.
2.5°/ Annexes, liens
Le rapport se termine avec des listes de liens, des annexes, des figures, etc.