Guide de Rédaction du Rapport du Stage de Perfectionnement
Institut Supérieur des Études Technologiques de CharguiaInstitut Supérieur des Études Technologiques de Charguia
1/22
100%
Rendu du PDF...
Guide de Rédaction du Rapport du Stage de Perfectionnement
Institut Supérieur des Études Technologiques de Charguia · Computer Science - Internship Documentation · course
Voir tous les documents en langues et communication
Fiche de révisionFiche de cours
Rédigée à partir de ce document, puis vérifiée avant publication.
Ce guide s’adresse aux étudiants du département Technologies de l’Informatique qui doivent rédiger un rapport de stage de perfectionnement. Il présente une structure type et des recommandations précises pour chaque partie du rapport, depuis l’introduction jusqu’aux annexes, en insistant sur la clarté, la rigueur et la présentation professionnelle.
Ce chapitre comprend deux parties principales : la présentation de la société d’accueil et l’étude de l’existant.
Il s’agit de décrire brièvement la société où le stage s’est déroulé, en précisant son domaine d’activité, son organisation, et surtout son aspect informatique (activités liées à l’informatique, parc informatique). Il faut également indiquer le département où s’est effectué le stage en précisant sa vocation (développement, maintenance, etc.).
Attention : cette présentation ne doit pas être une publicité pour la société, mais une description objective.
Cette partie se divise en trois sous-parties :
Remarque : l’étude de l’existant peut constituer un chapitre indépendant.
Ce chapitre est facultatif et ne s’intègre que si le sujet du stage nécessite des notions peu communes ou non encore étudiées, mais indispensables à la compréhension du projet.
Ce chapitre détaille ce que l’application doit faire, en précisant clairement les fonctionnalités attendues.
Ce sont les besoins indispensables auxquels l’application doit répondre. Il est conseillé de les présenter sous forme de WBS (Work Breakdown Structure), c’est-à-dire en listant les besoins globaux puis leurs sous-besoins. Par exemple :
1. Besoin global 1 1.1. Sous-besoin 1 1.2. Sous-besoin 2 2. Besoin global 2 2.1. Sous-besoin 1 2.2. Sous-besoin 2
Ces besoins améliorent la qualité de service de l’application, comme la convivialité, l’ergonomie, ou le temps de réponse. Ils peuvent être présentés sous forme de listes à puces.
Cette section présente brièvement les différents acteurs qui interagissent avec l’application.
Les cas d’utilisation peuvent être présentés par acteur ou par fonctionnalité, selon que les fonctions sont indépendantes ou partagées entre plusieurs acteurs.
Chaque cas d’utilisation ambigu doit être complété par une description textuelle comprenant :
Il est possible d’ajouter des informations sur les acteurs primaires et secondaires selon le cas.
Ce chapitre décrit la solution conceptuelle proposée, répondant à la question « COMMENT FAIRE ». La conception est illustrée par des diagrammes issus soit de la méthode MERISE, soit du langage UML.
La conception comprend plusieurs étapes :
Inventaire des attributs de la base de données, précisant leur désignation, type et signification, classés par entités.
Le diagramme du MCD est placé ici. Il doit être réalisé avec un outil de conception (ex. POWER AMC). En cas de diagramme volumineux, il peut être décomposé ou limité à la partie principale, le reste étant en annexes.
Liste des relations déduites du MCD, avec les clés primaires et étrangères mises en évidence. En cas de modèle imposant, seules 3 ou 4 relations sont présentées, le reste en annexes.
Présentation et description brève des différentes classes, ou des principales si elles sont nombreuses.
Le diagramme est placé ici, éventuellement accompagné de la description des classes. Les mêmes remarques que pour le MCD s’appliquent en cas de diagramme volumineux.
Traduction du diagramme de classes en modèle relationnel, montrant la transformation des classes et associations en tables. Seules quelques relations sont présentées si le modèle est volumineux.
Les traitements effectués par l’application sont modélisés selon la méthode choisie :
Il faut sélectionner les traitements les plus importants. Chaque diagramme doit être accompagné d’une explication textuelle concise.
Ce chapitre présente le produit fini développé par l’étudiant, généralement en deux parties :
Description des caractéristiques matérielles utilisées pour le développement (processeur, mémoire, équipements réseau, serveurs, etc.).
Liste des outils logiciels utilisés pour le développement, la modélisation, la gestion de base de données, etc.
Présentation des interfaces graphiques principales développées, accompagnée d’un court paragraphe explicatif (2 à 3 lignes). Seules les interfaces les plus importantes ou différentes sont présentées ici, les autres étant en annexes.
La conclusion rappelle l’objectif du stage et récapitule le travail réalisé en présentant les résultats obtenus, c’est-à-dire les réponses aux problèmes posés. Elle doit aussi comporter un regard critique sur le travail, en soulignant les insuffisances ou pistes d’amélioration.
La conclusion est rédigée en un paragraphe d’une page environ, sans liste à puces.
Cette partie regroupe les références documentaires utilisées :
Liste des ouvrages, articles, revues consultés, classés soit par ordre alphabétique d’auteur, soit par ordre d’apparition dans le rapport. Exemple de référence :
[1] REEVES, Hubert. « Bases de données relationnelles », Paris, Editions du seuil, 1988, 288p.
Liste des sites web consultés, avec une brève description du contenu (1 ou 2 lignes). Exemple :
[2] http://www.asp.net/ : Fondements du langage ASP.NET.
Ne doivent pas être mentionnés les moteurs de recherche ni les cours étudiés à l’ISET.
Il est impératif de référencer ces sources dans le rapport.
Les annexes sont facultatives et contiennent des documents complémentaires non indispensables à la compréhension, mais utiles :