Académique Documents
Professionnel Documents
Culture Documents
Guide Perfectionnement
Guide Perfectionnement
REPUBLIQUE TUNISIENNE ***** MINISTERE DE L'ENSEIGNEMENT SUPERIEUR, DE LA RECHERCHE SCIENTIFIQUE ET DE LA TECHNOLOGIE ***** DIRECTION GENERALE DES ETUDES TECHNOLOGIQUES ***** INSTITUT SUPERIEUR DES ETUDES TECHNOLOGIQUES DE CHARGUIA *****
RAPPORT DE
STAGE DE PERFECTIONNEMENT
Sujet :
Socit daccueil : .
Remerciements
Cette page est personnelle et est consacre, gnralement, remercier lencadreur de la socit ainsi que les personnes (membres de la socit, enseignants, personnel technique ou administratif et non pas les membres du jury) qui auraient aid ltudiant mener terme son stage de perfectionnement en le conseillant ou en lui fournissant de la documentation. Ces remerciements sont exprims en une dizaine de lignes au maximum, de la faon la plus simple possible, sans platitude ni exagration. La mise en forme de cette page est au gr de ltudiant.
Sommaire
[La table des matires (sommaire) permet, grce la pagination, de retrouver lendroit o se trouve un lment recherch par le lecteur. La table des matires doit tre gnre dune faon automatique. Elle ne doit pas prsenter plus que trois niveaux de sous-titres.] Introduction gnrale ...........................................................................................................1 Chapitre 1 : Prsentation du cadre du stage .......................................................................2 I. II. Prsentation de la socit ............................................................................................2 Etude de lexistant ......................................................................................................2
II.1. Description de lexistant..........................................................................................2 II.2. Critique de lexistant ...............................................................................................2 II.3. Solution propose....................................................................................................2 Chapitre 2 : Notions thoriques ...........................................................................................4 Chapitre 3 : Spcification des besoins..................................................................................5 I. II. Besoins fonctionnels ...................................................................................................5 Besoins non fonctionnels ............................................................................................5
III. Diagrammes de cas dutilisation..................................................................................5 III.1. Prsentation des acteurs..........................................................................................5 III.2. Description des cas dutilisation .............................................................................5 Chapitre 4 : Conception .......................................................................................................7 I. Conception de la base de donnes ...............................................................................7
I.1. Conception de la base de donnes en se basant sur la mthode MERISE...................7 II.2. Conception de la base de donnes en se basant sur le langage UML ........................8 II. Conception des traitements .........................................................................................9 Chapitre 5: Ralisation.......................................................................................................10 I. Environnement de dveloppement.............................................................................10
I.1. Environnement matriel..........................................................................................10 I.2. Environnement logiciel...........................................................................................10 II. Principales interfaces graphiques ..............................................................................10 Conclusion gnrale............................................................................................................11 Bibliographie et Ntographie .............................................................................................12 ANNEXES ............................................................................................................................13 ANNEXE A : Que placer en annexes ? .............................................................................14 ANNEXE B : Proposition de mise en forme .....................................................................15 ANNEXE C : Diverses recommandations.........................................................................17
[Cette rubrique nest pas obligatoire si le nombre de figures est infrieur cinq (05). Elle doit tre gnre automatiquement.] Notez que le titre de la figure doit tre plac en dessous de la figure.
[Cette rubrique nest pas obligatoire si le nombre de tableaux est infrieur cinq (05). Elle doit tre gnre automatiquement.] Notez que le titre du tableau doit tre plac au dessus du tableau.
Introduction gnrale
Introduction gnrale
Lintroduction gnrale comporte, globalement, deux parties. La premire partie prsente le sujet travers des renseignements prcis et pose le problme rsoudre avec clart sans vocation de rsultats. [Il faut viter imprativement les introductions passe partout ] La seconde partie nonce le plan du rapport en voquant, brivement, le contenu de chaque chapitre. La suite de ce guide illustre un exemple type de structure de rapport pouvant tre adopte par un tudiant du dpartement Technologies de linformatique dont le stage a pour objectif de dvelopper une application.
I.
Prsentation de la socit
Cette partie comprend une brve description de la socit daccueil : son domaine dactivit, un bref historique (si a apporte une plus-value au travail), son organisation. Il faudrait, surtout, insister sur laspect informatique : ses activits dans ce domaine ; la prsentation de son parc informatique est, particulirement, apprcie. Il est, galement, important dindiquer le dpartement au sein duquel le stage sest effectu en prcisant sa vocation (dveloppement, maintenance,) Attention !! La prsentation de la socit nest pas une publicit pour celle-ci ; il ne sagit pas de vanter ses mrites ou les services quelle offre.
II.
Etude de lexistant
II.1. Description de lexistant
Il est question dexpliquer comment le travail seffectue, actuellement, au sein de la socit (en rapport avec lapplication qui va tre dveloppe par ltudiant).
Chapitre 1 : Prsentation du cadre du stage Chaque chapitre doit comporter une brve introduction et conclusion. La mention des termes Introduction et Conclusion nest pas indispensable.
I.
Besoins fonctionnels
Ce sont les besoins indispensables auxquels doit rpondre lapplication. Par mesure de clart, il est recommand de prsenter les besoins sous forme WBS (Work Breakdown Structure) ; en dautres termes, indiquer les besoins globaux puis les dtailler. Pour cela, il est possible dutiliser les puces ou les numrotations comme suit : 1. Besoin global 1 1.1. Sous-besoin1 1.2. Sous-besoin 2 2. Besoin global 2 2.1. Sous-besoin1 2.2. Sous-besoin 2
Chapitre 3 : Spcification des besoins compltement indpendantes, cest la premire solution qui est adopte. Si en revanche, une fonctionnalit du systme fait intervenir plusieurs acteurs, cest la deuxime possibilit qui est adopte. Les cas dutilisation prsentant certaines ambiguts doivent tre complts par une description textuelle (prsente au choix sous forme dun paragraphe cohrent ou non). Celleci comprend, essentiellement, les points suivants : Objectif : cest le but du cas dutilisation. Pr-condition(s) : Condition(s) devant tre remplie(s) pour excuter le cas dutilisation. Enchanement nominal : Cest le scnario indiquant les tapes pour raliser le cas dutilisation (il ne comprend pas dalternatives) : il peut tre, galement, remplac par un diagramme de squence. Post-condition(s) : Condition(s) ncessaire(s) pour que le cas dutilisation soit considr comme achev. Il est, galement, possible de spcifier dautres informations telles que les acteurs primaires et secondaires ; tout dpend de la particularit du cas.
Chapitre 4 : Conception
Chapitre 4 : Conception
Ce chapitre a pour objectif de prsenter la solution conceptuelle propose par ltudiant. En dautres termes, ce chapitre devrait rpondre la question COMMENT FAIRE. La conception est dcrite par un ensemble de diagrammes relevant soit de la mthode MERISE soit du langage de modlisation UML. Notons que pour les sujets de configuration, de paramtrage ou d'intgration, ce chapitre peut tre compltement omis. La structure de ce chapitre dpend de la nature du sujet ; il est, vivement, recommand de sadresser au corps enseignant pour tout conseil ventuel. Nous illustrons, dans la suite, une structuration de ce chapitre dans le cas dun stage ayant pour objectif de dvelopper une application qui gre une base de donnes.
I.
La description de la conception de la base de donnes seffectue en plusieurs tapes. Ltudiant adopte la structuration approprie pour ce chapitre, selon son choix pour la mthode MERISE ou le langage UML. Pour chacun de ces choix, nous proposons une structuration possible de cette section.
Chapitre 4 : Conception Il est impratif que le MCD ainsi que tous les diagrammes de conception soient tracs laide dun outil de conception appropri tels que POWER AMC ou AMC Designer. Si le diagramme est trs imposant, il est possible de le dcomposer en plusieurs parties. Il est, galement, possible de se limiter la partie du modle juge la plus importante et placer le reste des entits en annexes. Si le nombre dattributs dune entit est considrable, il est, galement, possible de se limiter aux plus importants dentre eux vu que les attributs ont dj t dfinis au niveau du dictionnaire de donnes.
Chapitre 4 : Conception Notons que les rgles de passage du diagramme de classes au modle relationnel sont analogues celles du passage du MCD au MLD. Dans le cas dun diagramme de classes imposant, il suffit de montrer 3 ou 4 relations et de placer la suite en annexes.
II.
Un intrt particulier est port aux traitements effectus par lapplication. Si ltudiant a opt pour la mthode MERISE, il modlise les traitements travers le Modle Conceptuel de Traitements (MCT). Dans le cas o ltudiant a opt pour une modlisation avec UML, les traitements peuvent tre illustrs par des diagrammes de squence dtaills ou des diagrammes dactivits. Le choix dun ou de plusieurs diagrammes de conception dpend du sujet. Attention !! Il faut slectionner les traitements jugs les plus importants ; la qualit de la conception nest pas value en fonction du nombre de diagrammes reprsents ! Notons que chaque diagramme doit, imprativement, tre suivi dune explication textuelle en quelques phrases. Selon, la spcificit du sujet, la conception peut diffrer. Il est recommand ltudiant de sadresser au corps enseignant pour lui porter conseil.
Chapitre 5 : Ralisation
Chapitre 5: Ralisation
Ce chapitre a pour objectif majeur de prsenter le produit fini , c'est--dire ce que ltudiant a dvelopp. Pour cela, ce chapitre est, gnralement, compos de deux parties. La premire partie dtaille lenvironnement de dveloppement. La seconde partie concerne la mise en uvre de la solution propose par ltudiant en prsentant les principales interfaces graphiques. Pour les sujets de stage de configuration ou dintgration, le dploiement et limplmentation peuvent tre dtaills.
I.
Environnement de dveloppement
I.1. Environnement matriel
Cest lenvironnement sous lequel ltudiant a dvelopp son application : les caractristiques de lordinateur telles que la frquence du processeur, la taille de la mmoire centrale ou sil sagit dune application rseau, les routeurs ou hubs, serveurs,
II.
Au niveau de cette rubrique, il faut placer les principales interfaces graphiques dveloppes qui devraient tre toutes commentes par un paragraphe de 2 3 lignes expliquant son contenu. A noter quil ne faut pas placer toutes les interfaces de lapplication, mais uniquement les plus importantes et celles qui seraient diffrentes. Les autres interfaces sont places en annexes.
10
Conclusion gnrale
Conclusion gnrale
La conclusion du rapport doit comprendre, imprativement, un rappel de lobjectif du stage de perfectionnement et une rcapitulation du travail fait en prsentant les rsultats (en dautres termes, les rponses aux problmes poss au dbut). Il est, galement, recommand de porter un il critique sur le travail fait en soulevant certaines insuffisances ou amliorations possibles. Remarque : La conclusion devrait tre rdige en une page sous forme dun paragraphe et non pas de tirets.
11
Bibliographie et Ntographie
Bibliographie et Ntographie
Cette partie comprend les diffrents livres, articles, revues et sites internet qui ont servi la documentation. Bibliographie [Obligatoire] Lordre de ces rfrences peut se faire soit par ordre alphabtique du nom de lauteur soit par ordre dapparition dans le rapport. [i] NOM_AUTEUR, Prnom. Titre de louvrage , lieu de publication, nom de lditeur, anne de publication, nombre de tomes, nombre de pages. Sil sagit dun rapport de PFE, par exemple, on peut ajouter le numro dordre (rfrence) associ. (i= 1, 2, ,n). Exemple : [1] REEVES, Hubert. Bases de donnes relationnelles , Paris, Editions du seuil, 1988, 288p. Ntographie Sites Web visits lors de llaboration du projet, avec une brve description du thme consult (une ou deux lignes au maximum). Exemple : [2] http://www.asp.net/ : Fondements du langage ASP.NET. A ne pas mentionner : Les moteurs de recherche tels que www.google.fr ou www.yahoo.fr
Les cours tudis au niveau de lISET ; ils sont considrs comme faisant partie des connaissances acquises et assimiles par les tudiants. Il est impratif de rfrencer la bibliographie et ntographie au niveau du rapport !!
12
ANNEXES
ANNEXE A : Que placer en annexes ?
14
I. Titres et sous-titres
Il est recommand de prcder le titre du chapitre par son numro (Chapitre 1 : ), Les titres et sous-titres doivent tre sur le mme niveau vertical, On peut distinguer les niveaux de titres et sous-titres par la taille de police, A ne pas utiliser : la fin dun titre ou dun sous-titre, Les titres et sous titres ne sont ni souligns ni crits en italique, Un titre ou sous-titre ne doit jamais figurer en fin de page.
Remarque : Le titre dun chapitre peut tre plac sur une page indpendante ; dans ce cas, la page en question devrait tre comptabilise mais non numrote et ne devrait comporter ni entte ni pied de page. La page daprs (contenant le corps du chapitre) ne doit porter aucun titre. En dautres termes, le titre dun chapitre doit tre mentionn une seule fois.
III. Puces
Il faut adopter le mme type de puces pour tout le rapport et conserver le mme retrait, Chaque puce finit par une virgule , lexception de la dernire qui finit par un point . .
15
Annexe B : Proposition de mise en forme 2.3. Une ligne le sparant du texte de la page Remarque : Il nest pas apprci de mentionner le nom de ltudiant ou de la socit en entte ou pied de page dans la mesure o elle ne prsente aucune plus-value.
V. Marges
2.5 cm (haut, bas, droite, gauche)
VI. Couleurs
A viter sauf en cas de besoin (Interfaces de lapplication, )
16
17