Vous êtes sur la page 1sur 35

PROJETS TUTEURES

UIDE ENSEIGNANT
TABLE DES MATIERES

DESCRIPTION ET PLANIFICATION DES PROJETS TUTEURES ........................................................ 4


A CHAQUE ACTEUR SES OBJECTIFS.......................................................................................... 4
Pour les étudiants ....................................................................................................................... 4
Pour les professionnels............................................................................................................... 4
Pour l’équipe enseignante .......................................................................................................... 4
LE ROLE DE CHAQUE ACTEUR ................................................................................................. 5
Le responsable du projet (vous) ................................................................................................. 5
L'étudiant .................................................................................................................................... 5
ADOPTER UNE ATTITUDE PROFESSIONNELLE........................................................................... 6
Prendre des décisions ................................................................................................................. 6
Gérer des conflits........................................................................................................................ 6
LE CARNET DE BORD DU GROUPE D’ETUDIANTS ...................................................................... 6
MODE DE FONCTIONNEMENT ENTRE LES ETUDIANTS ET TUTEURS ........................................... 7
METHODOLOGIE DE REDACTION : RAPPORT DE PROJET TUTEURE ............................................ 8
Structure du rapport de stage/projet tuteuré............................................................................ 8
Eléments de rédaction................................................................................................................ 8
EVALUATION DU RAPPORT ET DE LA SOUTENANCE ................................................................. 9
Les critères du rapport écrit ....................................................................................................... 9
Les critères de la soutenance orale .......................................................................................... 10
SCRUM : UNE DEMARCHE AGILE POUR GERER VOS PROJETS........................................................ 11
OBJECTIF DU TP 2 ................................................................................................................ 11
PENNY GAME FEEDBACK ...................................................................................................... 11
CONCEPTION ET ARCHITECTURE LOGICIEL DES PROJETS .............................................................. 12
OBJECTIF DU TP 3 ................................................................................................................ 12
PROJET 1 : NEWSTUDY : CAHIER DES CHARGES ..................................................................... 12
Diagramme des cas d’utilisation général.................................................................................. 12
Diagramme des classes Métier ................................................................................................. 13
Conception des U.I Web ........................................................................................................... 13
Conception des U.I Web ........................................................................................................... 16
PROJET 2 : CONTROLE D’ACCES............................................................................................ 19
Diagramme des cas d’utilisation général.................................................................................. 19
Diagramme de Classe ............................................................................................................... 19
Mise en œuvre de la solution ................................................................................................... 20
PROJET 3 : CONCEPTION ET REALISATION D’UN SYSTEME D’INFORMATION DES ETUDIANTS DU
DEPARTEMENT INFORMATIQUE ........................................................................................... 21
Vue statique du système : Diagramme de classe ..................................................................... 22
Vue dynamique du système ..................................................................................................... 23
DEROULEMENT DE LA REALISATION ................................................................................. 24
Les rôles .................................................................................................................................... 24
La durée .................................................................................................................................... 24
Planning Scrum ......................................................................................................................... 24
DEVELOPPEMENT AVEC SCRUM .................................................................................................. 26
OBJECTIF DES TPs 5,6,7 ........................................................................................................ 26
VALIDATION DU RELEASE : SCRUM MEETING REVIEW. ........................................................... 26
PLANIFICATION DU PROCHAIN SPRINT : SPRINT PLANNING MEETING. .................................... 27
COACHING DES EQUIPES ...................................................................................................... 28
SPECIFICITES POUR LE DERNIER ATELIER ............................................................................... 28
PRESENTATION TECHNIQUE ET COMMERCIAL DU PRODUIT ......................................................... 29
OBJECTIF DU TP 8 ................................................................................................................ 29
TRAVAIL A PREPARER PAR LES ETUDIANTS ............................................................................ 29
DEROULEMENT DE L’ATELIER ............................................................................................... 29
ASPECTS ORGANISATIONNELS, POUR LE JOUR DE L’EVALUATION : ......................................... 30
BIBLIOGRAPHIE ET WEBOGRAPHIE.............................................................................................. 31
1

Le projet de fin d’études (PFE) est un moment essentiel de la formation en licence appliquée
dans le réseau ISET. Mené en équipe de 3 à 4 étudiants entre Septembre et Décembre, il
offre aux étudiants l’opportunité d’ancrer activement les enseignements aux situations
professionnelles. Le projet est également un moment important pour saisir l’imbrication des
différentes dimensions abordées au cours de la formation. Il est à la fois un temps de
réflexion, d’approfondissement et de « mise à l’épreuve » sur le terrain de certaines notions
et connaissances acquises, un temps aussi de découverte d’une situation opérationnelle
associée à la formulation et la gestion d’un projet aussi bien que l’acquisition de nouvelles
compétences. Il s’agit bien d’une logique d’apprentissage. À ce titre, le projet doit, certes,
constituer une contribution réelle et originale pour la formation mais aussi pour l’organisme
demandeur. Mais cela passe aussi par la reformulation de la proposition, par l’exploration de
pistes qui peuvent s’avérer infructueuses, par un recul critique sur les problématiques
traitées.

Objectif général

L’objectif majeur de ce manuel « Projet tuteuré » est de transformer l’espace


d’enseignement des étudiants en un espace professionnel. L’étudiant se voit alors émergé
dans un environnement professionnel semblable à celui des boites de développement
informatique. Le laboratoire informatique est transformé en un espace d’entrainement
pédagogique où les mêmes exigences et procédures de travail aussi bien que les
méthodologies de conduite de projets informatiques sont appliquées. Il offre ainsi aux
étudiants l’opportunité d’ancrer activement les enseignements aux situations
professionnelles.

Le projet est également un moment important pour saisir l’imbrication des différentes
dimensions abordées au cours de la formation. Il est à la fois un temps de
réflexion, d’approfondissement et de « mise à l’épreuve » sur le terrain de certaines notions
et connaissances acquises, un temps aussi de découverte d’une situation opérationnelle
associée à la formulation et la gestion d’un projet et, in fine, d’acquisition de nouvelles
compétences. Il s’agit bien d’une logique d’apprentissage.

Objectifs Spécifiques

A la fin de ce module l’étudiant sera capable de :

 Mettre en pratique les savoirs acquis au cours de la formation

 Répondre à une demande réelle en analysant une situation et en proposant une


solution adaptée

 Travailler au sein d’une équipe sous contrainte de temps et de moyens

 Appliquer une approche de développement (Agile)


2

 Partager et diffuser des informations entre les différents membres d’un même
groupe

 Gérer et partager son code à travers un outil de gestion de versionning

 Appliquer les bonnes pratiques de développement

 Développer un composant spécifique de l’application et assurer son intégration


continue tout au long du processus du développement

 Rapporter l’état d’avancement de son projet.

 démontrer ses capacités d’initiative, d’autonomie et de responsabilité,

L’apport des professionnels est fondamental dans le développement du contenu de ce


module. La définition d’un cahier des charges, la solution proposée, la conception,
l’architecture de l’application, la composition de l’équipe, l’organisation des tâches, les outils
de gestion de versionning, de reporting et d’intégration, la conduite du projet sont des
éléments indispensables pour la réalisation de ce support pédagogique.

Prérequis
Pour pouvoir suivre ces ateliers, vous devriez maîtriser les notions suivantes :

 POO et POOA
 BD et SGBD
 Architecture des logiciels
 Génie logiciel
 Méthodologie de conception

Méthodes d’Évaluation

Les éléments pris en compte pour l’évaluation sont les éléments suivants :

Utilisation d’un outil de travail collaboratif : l’utilisation d’un outil de travail collaboratif
(échanges, rendus, saisies du temps de travail, compte rendu de réunions, …) sera prise en
compte.

Soutenance : qualité du support (forme et fond), qualité du discours et respect du temps.

DT : qualité du support (forme et font) et respect des contraintes de mise en page.

Documents généraux : qualité du support (forme et font) et respect des contraintes de mise
en page.

Une attention particulière sera apportée par les évaluateurs au respect


3

De la propriété intellectuelle : toute forme de plagiat (même minime) sera sanctionnée par
un 0 à la note globale du projet tuteuré.

Des dates de rendu : tout retard sera lourdement sanctionné. La sanction s’appliquera à la
note globale du projet.

Du temps de travail : chaque étudiant doit travailler 80h sans quoi sa note sera réduite en
conséquence.

Du respect des consignes : le non-respect de l’ensemble des consignes indiquées dans ce


document ou transmises ultérieurement par le responsable des projets tuteurés sera
lourdement sanctionné. La sanction s’appliquera à la note globale du projet.

Equipe pédagogique

L’équipe pédagogique de la réalisation de ce manuel est formée de trois enseignants :

 Mohamed HAMMOUDA
 Sofien BEJI
 Iness Ben TARBOUT
 Nabil AOUADI

Volume Horaire

• Les séances d’ateliers auront lieu chaque semaine à raison de 3h par semaine par groupe
durant 14 semaines, soit 42h/semestre

Répartition des séances

Atelier Intitulé
Atelier 1 DESCRIPTION ET PLANIFICATION DES PROJETS TUTEURES

Atelier 2 SCRUM : UNE DEMARCHE AGILE POUR GERER VOS PROJETS

Atelier 3 CONCEPTION ET ARCHITECTURE LOGICIELLE DES PROJETS

Atelier 4 TRAVAIL EN EQUIPE- GESTION DES VERSIONS ET PLANIFICATION DES


PROJETS

Atelier 5-7 DEVELOPPEMENT DES PROJETS AVEC SCRUM

Atelier 8 PRESENTATION TECHNIQUE ET COMMERCIALE DU PRODUIT

Atelier 9 EVALUATION
4

Atelier 1

DESCRIPTION ET PLANIFICATION DES PROJETS


TUTEURES
A CHAQUE ACTEUR SES OBJECTIFS

Pour les étudiants

 Mettre en œuvre de façon globale, sur une étude donnée, les connaissances acquises
lors de la formation en licence qui permettent de mettre en corrélation
enseignements et projet.
 Développer ses « savoir-faire » par une mise en situation propice à l’observation et à
l’échange au sein du groupe et dans l’organisme impliqué dans le projet.
 Apprendre à travailler dans un groupe-projet de façon efficace et enrichissante dans
une double perspective de développement de son autonomie et de capacité à
travailler et à s’organiser en équipe.
 Prendre conscience de l’importance de développer une réflexion critique,
constructive, pertinente et apprendre à la communiquer à son « commanditaire ».
 Apprendre à chercher et synthétiser l’information.

Pour les professionnels

 Contribuer activement à la professionnalisation de futurs maîtres d’ouvrage en


participant activement à la formation en licence DSI et en s’inscrivant dans les
réseaux de professionnels et d’universitaires qui œuvrent dans le sens de cette
professionnalisation.
 S’exposer aux regards neufs et naïfs d’un groupe d’étudiants, donc modifier et
enrichir sa connaissance de son entreprise (ou organisme) à travers un point de vue
extérieur et novice. Faire connaître son secteur et son entreprise, voire susciter
l’intérêt des étudiants, dans une perspective éventuelle de proposition de stages plus
opérationnels (stage de fin d’étude) ou d’embauche ultérieure.
 Disposer d’un produit fini en fin de projet.

Pour l’équipe enseignante

 Tester la pertinence des enseignements par le suivi des étudiants mis en situation.
Développer et enrichir les enseignements par une meilleure connaissance du milieu
professionnel.
5

 Maintenir et consolider ses exigences de professionnalisation par l’ancrage de la


formation dans un réseau de professionnels. Faire connaître les masters de l’UFR
STGI et favoriser son rayonnement en développant ce réseau de façon active.
 Utiliser certains de ces projets comme base de rédaction d’études de cas ou d’outils
méthodologiques.
 Permettre à l’équipe enseignante de mesurer les attentes des entreprises du
domaine à l’instant « t ».

LE ROLE DE CHAQUE ACTEUR

Le responsable du projet (vous)

Ses principales tâches sont :

 animer l’équipe des tuteurs des différents projets ;


 concevoir le dispositif ;
 informer sur les règles de fonctionnement et fournir les outils ;
 constituer la liste des sujets de projet ;
 organiser les soutenances et le débriefing avec les tuteurs.
 valider dès le début la proposition de projet du groupe d’étudiants, notamment sa
faisabilité;
 orienter les étudiants vers des ressources ;
 donner des conseils en termes d’organisation ;
 valider la répartition et la planification des tâches au sein du groupe ;
 évaluer les rapports intermédiaires et les rendus finaux.

L'étudiant

Ses principales tâches sont :

 s’investir dans un projet dans une équipe de travail ;


 participer activement aux réunions de travail et à la réalisation des tâches ;
 se donner les moyens d’optimiser l’acquisition de savoir-faire et de savoir être.
 reformuler le cahier des charges et s’assurer de la validation par l’industriel.
Le commanditaire (éventuel)

Ce sont des entreprises, des associations, ou des institutions qui proposent un sujet. leurs
principales tâches sont :

 définir le cahier de charge des projets



 participer à l’évaluation finale du projet.
6

ADOPTER UNE ATTITUDE PROFESSIONNELLE

Pour mener à bien un projet, et instaurer des relations constructives, le groupe doit se
montrer :

 Mobilisé :
 Tous les étudiants du groupe doivent être présents et ponctuels aux réunions
sauf cas de force majeure.
 Les membres du groupe doivent s’organiser pour disposer du carnet de bord
du projet et des documents nécessaires à chaque réunion.
 Toutes les tâches doivent être réalisées dans les délais.
 Organisé
 Respecter les horaires.
 Planifier un ordre du jour incluant un point sur l’état d’avancement du projet.
 Rédiger un compte rendu pour chaque réunion.
 Mettre à jour le planning du suivi des projets.
 Assurer un suivi de projet.
 Responsable
 Faire valider par votre enseignant tuteur tous les documents (lettres, mails,
etc.) qui feront l’objet d’une communication externe au groupe.
 Faire état des difficultés rencontrées et des solutions envisagées.

Prendre des décisions

Travailler en groupe c’est prendre en commun un certain nombre de décisions. L’unanimité


n’est pas toujours de mise ! Pour prendre de bonnes décisions, il faut que chacun exprime
son point de vue et ses arguments, et qu’il soit écouté. Enfin, travailler en groupe, c’est
respecter mais aussi se faire respecter. Il faut prendre sa place dans l’équipe, il est en
particulier de votre responsabilité d’exprimer votre point de vue si vous voulez qu’il soit pris
en considération.

Gérer des conflits

Une répartition des tâches équitable, validée par tous, et respectée, permet d’installer des
conditions favorables. Si un conflit émerge, il faut le rendre explicite, avant qu’il ne prenne
pas des proportions difficiles à gérer. Le conflit se nourrit souvent du flou, du non-dit.

LE CARNET DE BORD DU GROUPE D’ETUDIANTS

Le carnet de bord du groupe est un outil pour les étudiants et pour les enseignants. Il permet
de suivre le projet sur la durée et d’en conserver une mémoire écrite. Il constitue un support
central pour le projet.
7

Le carnet de bord peut contenir :

 les objectifs pédagogiques du projet (fournis par l’enseignant) : ils sont de nature à
motiver et à guider les apprentissages ;
 les modalités : elles constituent un élément central du contrat pédagogique et
doivent être décrites en détail ;
 l’échéancier et le format des rendus ;
 les comptes rendus des réunions.

La vie d’un projet passe par une série d’étapes, notamment des réunions, dont il faut garder
la trace. La rédaction de comptes rendus constitue un élément indispensable dans de
nombreuses activités professionnelles ; il est donc utile de s’initier.

MODE DE FONCTIONNEMENT ENTRE LES ETUDIANTS ET TUTEURS

Règles du jeu

Indépendamment des séances programmées dans le calendrier, tuteur(s) et groupe doivent


se rencontrer un certain nombre de fois selon des modalités qui seront définies au début du
projet. Pour préparer chaque réunion, le groupe établira un rapport intitulé. Il s’agit
notamment de pointer :

 ce qui est fait, ce qui reste à faire ;


 les contacts manquants ;
8

 les problèmes et questions à poser au(x) tuteur(s).


 Ce document préparatoire sera envoyé par Email au(x) tuteur(s) avant la rencontre.

METHODOLOGIE DE REDACTION : RAPPORT DE PROJET TUTEURE

Structure du rapport de stage/projet tuteuré

Le rapport de 20 à 30 pages (sans les annexes), doit respecter l'ordre suivant :

 une page de couverture et une page de garde identiques comprenant : le titre du


mémoire, le nom de l'Université, l'intitulé de la formation, les noms et des tuteurs
(entreprise et UFR), l'année universitaire.
 des remerciements: surtout vis-à-vis des professionnels.
 Un résumé d’une page en français et en anglais.
 un sommaire : paginé (uniquement pour le développement). L’introduction et la
conclusion ne sont pas paginées. Le titre des parties et sous-parties doit être explicite
et reflète le contenu. Le plan doit comporter 2 ou 3 grandes parties (une quatrième
partie reste exceptionnelle et doit être justifiée). Le détail du plan ne doit pas
excéder 3 niveaux de sous-sections.
 le développement.
 le glossaire : définition des termes techniques et des abréviations utilisées.
 une bibliographie : elle est obligatoire et non factice. Elle met en évidence les articles
de revues, les ouvrages et les sites internet de référence. Le texte doit y faire
référence systématiquement. Elle peut être organisée par ordre d'apparition dans le
texte et donc numérotée [] ou par ordre alphabétique du nom des auteurs.
 les annexes : titrées et numérotées. Elles doivent être absolument commentées dans
le texte. Elles ne doivent pas excéder ¼ de l’ensemble du rapport.

Eléments de rédaction

Le texte doit être tapé en Tahoma, taille de caractères, interlignes 1,2. L'utilisation de
couleurs pour les caractères est déconseillée (exceptée pour les titres des parties et sous
parties (bleu).

L'introduction générale doit comporter trois paragraphes principaux :

 généralités sur le secteur d'activité, l'entreprise, le thème d'étude...


 la problématique : quel intérêt pour les professionnels,
 annonce du plan du rapport (seulement les grandes parties).

Chaque partie doit comporter une sous introduction et une sous conclusion (conclusion
partielle): l'une pour annoncer le contenu détaillé, l'autre pour faire une synthèse
intermédiaire (peut être réalisée sous forme de schéma ou tableau).
9

La conclusion générale doit comporter trois paragraphes principaux :

 synthèse des apports.


 limites : comment compléter votre analyse ?

Les tableaux et figures doivent être numérotés, titrés et commentés (citer les sources en bas
de page). Les citations sont mentionnées entre guillemets. Tout passage emprunté à une
revue, un article, un site internet doit être mentionné avec une note de bas de page
(Références – Insérer une note de bas de page). Sans cette note de bas de page, le passage
copié est considéré comme du plagiat et aura un impact sur l’évaluation.

La présentation de l'entreprise d'accueil ne doit pas faire l'objet d'une partie entière. Elle ne
doit pas être descriptive : l’étudiant doit livrer un état de la structure (organisationnel,
commercial, financier, humain...) avec un jugement critique (forces/faiblesses).

Pour la forme :

 attention à l'orthographe, et la grammaire (faire relire systématiquement votre


document par plusieurs personnes)
 aérer le texte
 justifier le texte – alignement à droite et à gauche
 paginer le document

EVALUATION DU RAPPORT ET DE LA SOUTENANCE

Les critères du rapport écrit

Sur la forme

 Respect des directives de forme (sommaire, remerciements, annexes,


bibliographie…)
 Qualité de l’expression, du style
 Orthographe, Grammaire

Sur le fond

 Introduction/Conclusion
 Présentation de la problématique
 Cohérence de la méthodologie : cheminement, transition, synthèse…
 Description des moyens mis en œuvre
 Richesse et exploitation des informations collectées
 Diversité et densité des actions menées
 Analyse des résultats obtenus
 Analyse critique, identification des limites et ouverture
10

 Enseignements tirés aux plans personnel et professionnel


 Capacité à travailler en équipe

Les critères de la soutenance orale

Sur la forme

 Présentation personnelle, aisance, mobilité, gestuelle…


 Qualité de l’expression : vocabulaire, rythme, clarté des propos…
 Qualité et utilisation des documents d’accompagnement
 Maîtrise du temps

Sur le fond

 Le problème est correctement posé


 Les méthodes utilisées présentées et pertinentes
 Les résultats sont clairement restitués et satisfaisants
 L’exposé est structuré et synthétique et s’appuie sur des supports appropriés et
attrayants
 Les réponses aux questions démontrent la maîtrise du sujet et de son contexte
 Le groupe a su exposer ses difficultés de façon positive et a su modifier le jury pour
les résoudre
 Le groupe s’est montré ouvert à la discussion et aux suggestions du jury
11

Atelier 2

SCRUM : UNE DEMARCHE AGILE POUR GERER


VOS PROJETS
OBJECTIF DU TP 2

L'objectif de ce TP est de permettre aux étudiants d’acquérir de solides bases sur Scrum et
ses principes fondamentaux en explorant sa mécanique et les raisons de son efficacité. Il
permet entre autre, et à travers un jeu éducatif, de mettre en évidence un certain nombre
du manifeste agile décrit exhaustivement au début de l’atelier.

PENNY GAME FEEDBACK

Voici les leçons que l'équipe doit apprendre en observant le déroulement de chaque tour.

Round1 : Certaines personnes ne travaillent pas, pendant que d’autres travaillent. Le temps
inactivité de chaque membre de l’équipe de développement est remarquable. En plus le
client reçoit ça première release à la fin du temps consacré pour le jeu.

Round2 : Des lots plus petits signifient que plus de valeurs sont livrées et que les membres
de l’équipe de développement (travailleur) peuvent passer plus de temps à travailler car ils
travaillent simultanément. La première valeur est également livrée plutôt au client.

Round3 : Des lots encore plus petits signifient que plus de valeurs sont livrées et que la
première valeur est rapidement livrée au client.

Round4 : Supprimer les obstacles signifie que plus de valeur est livrée sans que l'équipe ne
travaille plus. Ils sont juste plus efficaces.

Round5 : Sélectionner un travail de haute valeur améliore la valeur délivrée même si


l'équipe travaille pendant le même laps de temps. À ce stade, j'ai demandé aux gestionnaires
s'ils pensaient qu'il était important de savoir combien de temps les employés travaillaient.

s'agissait d'un point de pouvoir.


12

Atelier 3 DESCRIPTION DES PROJETS PROPOSES

CONCEPTION ET ARCHITECTURE LOGICIEL DES


PROJETS
OBJECTIF DU TP 3

L'objectif de ce TP est d’appliquer les concepts théoriques de la conception et de


l’architecture des logicielle afin de présenter une conception détaillée des différents projets
présentés dans l’atelier 2 aussi bien qu’une architecture logiciel pour chaque projet.

PROPOSOTION DES SOLUTIONS POUR CHAQUE CAS

PROJET 1 : NEWSTUDY : CAHIER DES CHARGES

Diagramme des cas d’utilisation général


13

Diagramme des classes Métier

Conception des U.I Web

Gestion des administrateurs


14

Gestion des clubs

Statistiques des actualités


15
16

Conception des U.I Web

This figure represents the user interface sign in This figure represents the user interface
which will be display only at the first launching of list news.
the application.

Figure 1: UI Sign up Figure 2: UI list news


17

This figure represents the user interface list This figure represents the user interface
clubs. institute description.

Figure 3: UI list clubs Figure 4: UI institute section

The figure bellow shows the user interface The figure bellow shows the user
details news with an advertisement. interface settings of the notifications
and profile

Figure 5: UI detail news Figure 6: UI settings


18

This figure shows the user interface notification This figure shows the user interface
settings where the mobile user can choose a profile settings where the mobile user
notification alarm or enable/disable the can update his profile by enable/disable
notification vibrates. the notification vibrates.

Figure 7: UI notification settings Figure 8: UI update profile


19

PROJET 2 : CONTROLE D’ACCES

Diagramme des cas d’utilisation général

Configurer Centrale

Installateurs

Gérer le Reporting

<<include>>
Utilisateur de l'Application
Gérer les Utilisateurs de l'Application

Utilisateur du Système

Gérer les Sites

Superviseur
<<extend>>

Gérer les Portes Commander Centrales

<<extend>>

Gérer les Groupes de Portes


Administrateur <<include>>

Gérer les Plages Horaires


<<include>>

Automatiser les Contrôles

Gérer les Utilisateurs Système

Diagramme de Classe

Le diagramme de classe suivant permet de mettre en évidence les classes qui peuvent
intervenir dans la réalisation de plusieurs cas d'utilisation.
20

Mise en œuvre de la solution

Trois applications de base (A1, A2, et A3) peuvent être développées assurant chacune une
fonctionnalité principale au niveau de notre solution globale.

Une première application A1 assure la communication « bas niveau » avec les centrales,
basée sur une communication par Socket. Les commandes envoyées à la centrale à travers
l’application A1 sont transformées en trames d’octets selon le protocole de communication
de la centrale. Les commandes sont répertoriées en deux catégories :

 Des commandes de type GET paramétrées: Permettant d’interroger les centrales et


récupérer des informations sous forme d’une trame d’octet.

 Des commandes de type SET paramétrées: Permettant de configurer les centrales et


récupérer un acquittement de réception.
21

Ces fonctionnalités, empaquetées dans deux DLL


(Protocol.dll et Command.dll), garantissent la
communication avec les centrales, et interagissent
directement avec l’application A2.

A2 quant à elle assure les fonctionnalités du


système décrites dans la section précédente et
interagit directement avec l’application A3
(Model.dll) qui assure la communication avec la
base de données. La figure (Fig.3) décrit l’aspect
architectural de la solution RITEGE.

PROJET 3 : CONCEPTION ET REALISATION D’UN SYSTEME D’INFORMATION


DES ETUDIANTS DU DEPARTEMENT INFORMATIQUE
22

Vue statique du système : Diagramme de classe


23

Vue dynamique du système

Cas "Ajouter cours "

Cas "S’inscrire dans un PFE "


24

DEROULEMENT DE LA REALISATION

Afin de développer des compétences en gestion de projet, nous recommandons l’utilisation


d’un processus de développement Agile tel que Scrum, ci-dessous un aperçu de quelques
événemnts types selon Scrum.

Les rôles

Rôle Assuré par


Scrum Master : L’enseignant
Suivi du déroulement des réunions
Product owner : L’enseignant
Responsabilité métier
Development Team : Les étudiants
Responsabilité de la réalisation

La durée

Durée de Sprint : 1 à 4 semaines, 2 semaines sera adéquat dans le cas d’un semestre, ce qui
donnera lieu à 4 sprints de développement.

Planning Scrum
Sprint Scrum
Semaine 1 Semaine 2
1 2 3 4 5 6 7 8 9 10 11 12

Sprint Product Sprint


planning Backlog review
meeting Refinment
4H 2H 2H

Durant les séances de tutorat, il est recommandé de faire :

 Sprint planning meeting : à réaliser avant d’entamer le sprint, ceci consiste


essentiellement dans la planification du sprint, il permet de développer la
compétence de décomposition des besoins en tâches et d’évaluation des réalisations
du projet.

 Sprint review : il s’agit d’une démonstration du release à la fin du sprint et de la


validation des besoins qui ont été totalement achevés. L’enseignat en tant que
Product Owner confirmera ou annulera les items achevés durant le Sprint, les
étudiants doivent procéder à une démonstration du produit.
25

 Product Backlog refinement : il s’agit de réarranger les items du product backlog et


de détailler les user story du prochain sprint afin de garder les priorités en haut de la
pile.
26

Atelier 5,6 et 7

DEVELOPPEMENT AVEC SCRUM

OBJECTIF DES TPs 5,6,7

L'objectif de ces TPs est, d’une part mettre en pratique les compétences en développement à
savoir l’utilisation des IDE, le codage, le test, l’intégration etc, et d’autre part adopter une approche
Agile se basant sur le formalisme Scrum. Dans ce qui suit, le déroulement d’une séance type.

La séance de tutorat pourra faire l’objet des activités suivantes :

 Validation du release : Scrum meeting review.


 Planification du prochain sprint : Sprint planning meeting.
 Coaching des équipes.

VALIDATION DU RELEASE : SCRUM MEETING REVIEW.

Participant à la réunion Jouant le Rôle de


Enseignant Product owner
Etudiants Dev Team

Durant cette réunion l’enseignant jouant le rôle de Product Owner procèdera à une
validation du produit logiciel réalisé par le groupe.

L’enseignant testera réellement la solution et en se référant au Sprint Backlog, il aura à


valider ou pas les user story planifiés pour le Sprint courant.

Exemple : Soit les 3 user story : 2.1, 2.2 et 2.3 planifiées par exemple pour le 2ème sprint.

User story 2.1 User story 2.2 User story 2.3

As A « Administrateur » As A « Administrateur » As A « Utilisateur»

I want to « Créer des profiles I want to « Visualiser le log des I want to «Accéder au Labo»
utilisateurs » accès au Labo»
So That «Utiliser les ressources
So That « Personnaliser les accès So That « Identifier l’origine disponibles»
selon mes besoins» causes de vols de matériel»

L’enseignant jouant le rôle du P.O aura à tester chaque User story et exprimer sa validation
sur ce dernier: on peut imaginer par exemple que User story 2.1 et User story 2.3 sont
validés mais User story 2.2 n’est pas totalement achevé, dans ce cas User story 2.2 sera
remis dans le Product Backlog et sera re-planifiée dans la prochaine réunion.

Si un membre de la Dev team a des suggestions par rapport au release, il peut les exprimer.
27

Tout nouveau besoin identifié sera ajouté au Product Backlog en tant que P.B.I : product
Backlog Item.

Un Product Backlog contient des P.B.I, un PBI peut être une user story ou bien un
autre besoin comme par exemple un besoin technique tel que migrer vers un autre
serveur d’hébergement.

PLANIFICATION DU PROCHAIN SPRINT : SPRINT PLANNING MEETING.

Participant à la réunion Jouant le Rôle de


Enseignant Product owner
Etudiants Dev Team

Durant cette réunion, le P.O va définir (dans la mesure du possible) l’objectif du prochain
Sprint et procédera avec la Dev Team à la sélection des User story à inclure dans le prochain
Sprint.Une fois les user story sélectionnées, la Dev Team procédera à l’estimation de ces
dernières en utilisant la technique du planning poker.

Après estimation, il faut passer à la 2ème partie de la réunion qui consiste à identifier les
tâches pour réaliser les P.B.I

Nous obtiendrons ainsi le Sprint Backlog, qui inclure les informations suivantes :

P.B.I Estimation Tâche Durée Affectée


estimée A

As A « S, M, L, XL, XXL ou Créer modèle de données 2H Mehdi


Administrateur »
utiliser des valeurs Créer les classes 2H Mehdi
I want to « numériques (0, 1,
Visualiser le log des 2, 3, 5, 8, 13, 20, 40 Générer la couche dao 2H Mehdi
accès au Labo» et 100)
Créer les images nécessaires 4H Sami
So That « Identifier
l’origine causes de Intégrer l’interface 4H Sami
vols de matériel»
Se Documenter sur Google 8H Karim
Messaging

Coder le contrôleur
8H Karim
Tester
30 min Sami
Déboguer après test
2H Mehdi
Créer les comptes sur GitHub
30 min Sami
Préparer une démo GitHub & Eclipse
4H Sami

Plusieurs modèles de Sprint Backlog (sous la forme de Tableur) existent sur le web. Une fois
le Sprint Backlog réalisé, les User Story seront verrouillées, chaque nouveau besoin identifié
durant le Sprint doit être ajouté dans le Product Backlog.
28

COACHING DES EQUIPES

Cette activité est menée par l’enseignant, elle consiste à assister les étudiants dans les choix
à faire ou éventuellement dans les aspects techniques et ce dans la mesure du possible.

L’enseignant pourra dans cette activité valider le Sprint planning en vérifiant la forme et
l’affectation des tâches entre les membres.

Spécificités pour le dernier Sprint (Atelier)

Selon le formalisme de Scrum, une réunion d’évaluation du processus devrait être faite à
chaque fin de Sprint : la sprint retrospective meeting. Pour des besoins d’optimisation de
temps et afin d’éviter la confusion chez l’apprenant, on laissera cette réunion uniquement
pour le dernier Sprint.

L’objectif de la sprint retrospective meeting est simple ; évaluer l’approche de travail


adoptée en identifiant les choses qui ont bien marché et celles qui ne le sont pas. Plusieurs
techniques peuvent être utilisées comme par exemple la méthode classique qui consiste à
dresser 2 colonnes avec les éléments à retenir et ceux à améliorer ou éliminer.

SPECIFICITES POUR LE DERNIER ATELIER

Selon le formalisme de Scrum, une réunion d’évaluation du processus devrait être faite à
chaque fin de Sprint : la sprint retrospective meeting. Pour des besoins d’optimisation de
temps et afin d’éviter la confusion chez l’apprenant, on laissera cette réunion uniquement
pour le dernier Sprint.

L’objectif de la sprint retrospective meeting


est simple ; évaluer l’approche de travail
adoptée en identifiant les choses qui ont bien
marché et celles qui ne le sont pas. Plusieurs
techniques peuvent être utilisées comme par
exemple la méthode classique qui consiste à
dresser 2 colonnes avec les éléments à retenir
et ceux à améliorer ou éliminer. Après ceci,
l’équipe dressera un bilan critique avec les
actions à entreprendre prochainement pour
améliorer le processus Scrum.
29

Atelier 8

PRESENTATION TECHNIQUE ET COMMERCIAL DU


PRODUIT
OBJECTIF DU TP 8

L’objectif de cet atelier est de développer les Soft-Skills des étudiants en leur permettant de
présenter leurs projets sous la forme d’un produit logiciel prêt à la commercialisation.
Idéalement, cet atelier se déroulera dans les conditions d’une exposition de projets où
chaque groupe d’étudiants aura un stand pour présenter sa réalisation.

TRAVAIL A PREPARER PAR LES ETUDIANTS

 Un pitch de 1 minute résumant les principales fonctionnalités du produit réalisé.


 Une présentation résumant :
 Les besoins
 La démarche de résolution
 Les outils
 La solution finale
 Une maquette ou une affiche représentant le produit.
 Tout autre élément pouvant attirer le public cible.

DEROULEMENT DE L’ATELIER

L’enseignant établit un planning des présentations.

Chaque groupe procédera à une présentation de 15 à 20 minutes suivie d’une session de


questions-réponses de 5 à 10 minutes.

L’évaluation sera faite selon une grille de critères, ci-dessous quelques suggestions :

 Qualité de la réalisation
 Technologies et outils utilisés
 Degrés d’achèvement
 Complexité du sujet et volume du travail
 Maîtrise de la réalisation
 Qualité de la présentation
 Réactivité aux questions
 Qualité du stand, poster, etc
30

ASPECTS ORGANISATIONNELS, POUR LE JOUR DE L’EVALUATION :

 Accès à la salle 1 heure avant le


début des évaluations.
 Regroupement des enseignants
assurant ce module et
évaluation des différents
groupes le même jour.
 Invitation d’autres enseignants
ou personnel administratif.
 Réarrangement de la salle, à la
manière d’une salle d’exposition
avec un « stand » pour chaque
groupe.
 Annonce à la fin de la journée
du groupe vainqueur.
31

BIBLIOGRAPHIE ET WEBOGRAPHIE

[SCRUM- Le guide pratique de la méthode agile la plus populaire] : Claude Aubry, 4ème édition.
Octobre 2015

[Git par la pratique] : Davide Demaree, 1ère édition. Février 2017

[La Gestion de Produit Agile expliquée en 15 minutes : http://www.agiliste.fr/lagilite-metier-


en-2-mots/]

[http://www.agiliste.fr/guide-de-demarrage-scrum/#D-marrage]

[https://openclassrooms.com/courses/gerez-vos-codes-source-avec-git]

[https://git-scm.com/docs/gittutorial]

[http://www.leanagiletraining.com/better-agile/agile-penny-game-rules/]
32