Ci-dessous un plan “idéal” d’un rapport de “stage” sur une mission de développement (mi-technique, pas guide utilisateur à part dans les illustrations éventuelles de la réalisation).
Dans le rapport technique (i.e. davantage le cas pour les rapports de “projet”), il y a surtout les sections 1, 5, 6 et 7.1.
1. Introduction (contexte, problématique, contribution, plan du rapport)
2. Présentation de l'environnement de travail : l'entreprise (activités ; informations légale, juridique, financière; organisation), département/équipe dans lequel tu t'insères (sa raison d'être, ton positionnement dans l'équipe, les métiers des personnes avec qui tu travailles, la nature des interactions que tu entretiens avec elles)
3. Gestion de projet
3.1. Planification (gantt explicité produit a posteriori accepté)
3.2. Méthodologie de travail (agile...)
3.3. Outils (collaboratifs/individuels) de travail
4. Etude de l'existant
4.1. Solution actuellement en place : Description et limites
4.2. Etat de l'art : présentation des (pistes de) solutions alternatives possibles
5. Conception : Expliquer verbeusement et à l'aide de diagrammes opportuns ce que vous avez conçu.
* Les diagrammes principaux sont ceux de cas d'utilisation, d'interactions, d'activités, de séquences, d'états et de classes.
* Si une application était déjà en place, fournissez ce qui est nécessaire pour que l'on comprenne votre contribution (précisez ce qui était existant et ce qui correspond à votre production).
6. Réalisation
6.1. Choix technologique motivé
6.2. Présentation de ce qui a été développé (potentiellement sur plusieurs sections) : idéalement autour de quelques cas canoniques avec des captures écrans et extraits de code ou algo choisis pour illustrer des aspects pertinents
7. Conclusion
7.1. Bilan et perspectives sur l'application réalisée (l'état de votre avancement dans le projet au prorata de votre explication sur votre activité et difficulté rencontré : ce qui a été conçu, réalisé, ce qui pourrait être poursuivi, pistes éventuelles sur la manière de concevoir/réaliser la suite)
7.2. Bilan personnel sur l'expérience humaine, méthodologique et technique
[1] est une bonne référence pour la description des diagrammes UML.[1] https://laurent-audibert.developpez.com/Cours-UML/
Suivant votre façon de présenter certaines informations peuvent passer dans la partie “5. Conception” ou dans la partie “6. Réalisation”.
Vous n’êtes pas non plus obligés d’être exhaustifs. Vous pouvez dans l’analyse avoir une description des fonctionnalités les plus importantes et renvoyer le reste en annexe si vous les aviez produits pour votre cahier des charges.
Sont aussi bienvenus les diagrammes de navigation dans les écrans (en expliquant les IHM), la présentation de l’arborescence des fichiers, schéma de base de données… A vous de voir si vous les placez en annexe ou ailleurs (un schéma bd peut être redondant avec un diagramme de classe, on peut donc l’omettre ou le mettre en annexe, mais si on n’a pas de diagramme de classes alors il vaut mieux le faire apparaître dans le rapport, l’arborescence de fichiers expliqué devrait se trouver dans le README).