accueil FIL | Licence 1 | Licence Info | Master Informatique | Master Miage | Alternance | Médiation |
| M1S1 | M1S2 | M2 e-Services | M2 IAGL | M2 IVI | M2 MOCAD | M2 TIIR | Recherche et Innovation |
| ACT | AEO | ANG | ASE | GL | PJE | PJE1 | PJE2 | PJE3 | PJE4 | PJE5 | PPP |
Vous êtes ici : FIL > Portail > Master Informatique > M1S1 > GL


GL - Génie Logiciel

Responsable

Les intervenants

Volume horaire

Chaque semaine :
Cours (1h30)
TD (1h30) + TP (2h) + travail personnel
TD lecture obligatoire (1h30)

Credits

5 ECTS 
Cedric Dumoulin
dernière modification : 10/09/2018 à 13:00:04


Objectifs

Ce cours a pour objectif de concevoir des applications orientés objets de façon systématique et reproductible. Dans ce cours, l'étudiant(e) apprendra à rechercher et établir les fonctionnalités d'une application, et à les modéliser sous forme de cas d'utilisation (C.U.) et de scénarios. IL ou elle apprendra à rechercher les classes et les acteurs nécessaires à la conception de l'application. L'étudiant(e) apprendra aussi des bonnes pratiques de conception, comme l'utilisation de patron de conception (design pattern), le découpage en couches de l'architecture , la structuration en paquetages et le maquettage. Voir aussi le syllabus : syllabus

Contenu

Voir le syllabus : syllabus

Bibliographie

Voir le syllabus : syllabus 
Cedric Dumoulin
dernière modification : 11/09/2017 à 12:46:42

Gpe Nature Horaire Salle Enseignant e-mail
Cours Lundi 13h30-15h C. Dumoulin
1 TD mardi 08h30- 10h00 Michaël Launay
1 TP mardi 10h15 - 12h15 Michaël Launay
2 TD lundi 10h15-11h45 Cedric Dumoulin
2 TP lundi 15h15-17h15 Cedric Dumoulin
3 TD mercredi 13h30- 15h00 Xavier Le Pallec
3 TP mercredi 15h20 - 17h50 Xavier Le Pallec
4 TD mercredi 8h30- 10h Vincent Aranega
4 TP mercredi 10h15 - 12h15 Vincent Aranega
5 TD mardi 8h30- 10h Xavier Le Pallec
5 TP mardi 10h15 - 12h15 Xavier Le Pallec

Cedric Dumoulin
dernière modification : 10/09/2018 à 15:42:29

Semainier GL 2018

Planning

Le planning est susceptible de changer au cours du semestre.

Seance semaine tp td
S 1 10/09 TD1 : Constitution des équipes - Ecriture des scénarios concrets
S 2 17/09 TD2 : Recherche CU, classes et acteurs (TinCar)
S 3 24/09 TD3 : CUs : relation extends et include
S 4 01/10 rendu TD4 : Diagramme de classes (TinCar)
------ :-------: ---------- ------------------------------------------------------
S 5 08/10 correction TD5 : Description textuelle de CUs
S 15/10 Abs.
S 6 22/10 TD6 : Diagramme de séquences
int p. 29/10 -- Interruption pedagogique
S 7 05/11 rendu TD7 : Pattern MVC (diagramme de classe complet + dss)
------ :-------: ---------- ------------------------------------------------------
S 8 12/11 correction TD8 : (suite TD 7) + Hierarchisation
S 9 19/11 TD9 : Diagramme classe ++ (enumeration)
S 10 26/11 TD10 : (Recherche écran ?)
S 11 03/12 Rendu en fin de semaine Uniquement TP
------ :-------: ---------- ------------------------------------------------------
s 12 10/12 soutenances
------ :-------: ---------- ------------------------------------------------------

Contenu des séances

Semaine 1

  • TD 1 : User stories (scénarios concrets)
    • Présentation des sujets
    • constitution des équipes (4 à 5 personnes max)
    • choix d'un sujet par chaque équipes
    • Ecriture des premier scénarios concrets par les équipes
    • Un scénario concret raconte comment plusieurs personnes utilisent le futur logiciel. Il peut décrire les écrans du logiciel et les interactions des personnes avec le logiciel.
    • un scénario concret ne décrit pas le fonctionnement interne de l'application (pas de technologies).
    • Le logiciel est décrit par plusieurs scénario concrets.
    • les scénario concrets doivent être complémentaires : ils doivent décrire différentes utilisations du logiciel.
    • Un scénario concret doit avoir plusieurs personnages (acteurs).
  • TP 1 :
    • Ecriture collaborative des scénarios concrets.
    • Utilisation des outils collaboratifs : git, markdown,
    • outils possible :
      • langage : markdown
      • editeur : atom
      • git

Semaine 2

  • TD 2 : recherche des CUs, classes et acteurs
    • recherche des CUs, classes et acteurs (TinCar)
    • (ancien TD1)
    • Glossaire métier
  • TP 2 :
    • Papyrus
    • prise en main
    • Construire les premiers diagrammes de CUs, classes et acteurs avec Papyrus

Semaine 3

  • TD 3 : relation extends et include
    • relation extends et include sur les CU trouvé lors du TD 2
  • TP
    • travaille sur le projet ## Semaine 4
  • TD 4 : Diagramme de classe
    • Diagramme de classe (TinCar)
    • diagrammes
    • paquetages
  • TP
    • travaille sur le projet

Semaine 5

  • TD 5 : Description textuelle des scénarios
    • Description textuelle des scénarios
    • Hierarchie des CUs
  • TP
    • travaille sur le projet
    
    Cedric Dumoulin
    dernière modification : 05/09/2018 à 23:59:55
rendus

Rendus de GL

▶︎
all
running...

Dates des rendus 2018-2019

La date de rendu est la suivante, sauf spécification contraire de votre intervenant.

Rendu Dates
Rendu 1 vendredi 5/10 20h
Rendu 2 vendredi 9/11 20h
Rendu 3 vendredi 7/12 20h
Soutenances semaine du 10/12

Contenu des rendus

Pour le projet de GL, On vous demande de rendre un document à des dates précises.

Il y a 3 rendus. Les rendus 2 et 3 sont la suite du rendu précédent.

Les documents sont à rendre impérativement sur l’intranet du FIL avant les dates et heures précisées suivant des modalités qui vous seront indiquées en TD (interface PROF).

Patrons pour le document de rendu

Premier rendu

  • Plusieurs scénarios concrets (au moins un par membre de l'équipe). Il faut choisir des scenarios représentatifs de l'utilisation de l'application.

    • un scénario peut être décrit sous forme textuelle (histoire), bande dessinée, vidéo ...
    • Il faut se focaliser sur l'interaction avec l'application.

  • Les diagrammes de cas d'utilisation (CU) correspondants aux scénarios

    • un scénario doit produire plusieurs CUs
    • Des CUS peuvent être communs à plusieurs scénarios
    • Pour chaque CU :
      • description courte du CU
      • diagrammes de CU
      • regrouper les CUs par affinités si possible

  • liste des acteurs

    • factorisation des acteurs (si possible)

  • Diagrammes de classes (Classes du domaine)

    • Il faut identifier les premières classe du domaine de l'application
    • Regroupement des classes en paquetage (premier essai)

  • Glossaire métier

    • Définition des termes métier utilisés dans les CUs

Deuxième rendu

Le deuxième rendu consiste à enrichir le premier rendu. C'est le même document, avec plus de contenu.
C'est une nouvelle itération du document.

  • Ajouts de nouveaux scénarios (au moins un par membre de l'équipe).

    • CUs correspondants
    • Classes correspondantes
    • Nouveaux paquetage

  • description de l'architecture

    • Quelle est l'architecture qui sera utilisée pour l'application (en couche, client/serveur ...)

  • Hiérarchie des CUs

    • Classement des CUs en fonction des riques
    • La liste des CUs retenus

  • Scénarios abstraits

    • Description textuelle des scénario abstraits
      • Chaque CU doit être décrit par son scénario abstrait correspondant.
      • Une description par membre de l'équipe
      • Ne pas décrire le CU 'authentification'
    • Diagramme de Séquence Système (DSS) pour chaque CU
    • Diagramme de séquence détaillé pour chaque DSS

  • Description des premiers écrans de l'application

    • description par l'exemple (snapshot, maquette ...)
    • Cela peut être un raffinement des écrans déjà proposés dans les scénarios concrets.
      • Il ne faut pas hésiter à remettre en cause les écrans proposés dans les scénarios concrets

  • Glossaire de l'ingénierie des besoins

    • Explication des termes utilisés dans la description de la solution proposé :
      • explication des classes, paquetages, CU ...

Troisième rendu

Le troisième rendu consiste à enrichir le précèdent rendu. C'est le même document, avec plus de contenu.
C'est une nouvelle itération du document.

  • Le contenu du rendu 2 plus ce qui suit
  • CUs supplémentaires, Description textuelle, Diagramme de Sequence Système et Détaillé pour les nouveaux CU
  • Raffinement final des diagrammes de Classes
  • raffinement des paquetages
  • Maquette interactive (coté client)

Documents à produire

Vous devez produire deux documents:

  • un document de suivi de projet (voir paragraphe concerné)
  • un document d'analyse et de conception

Document de suivi de projet

Pour suivre votre projet, vous devez maintenir un document de suivi de projet. Ce document est partagé entre tous les membres du groupe en lecture et écriture. Le partage ce fait dans GIT.

Chaque semaine:

  • vous définissez les tâches à faire, et vous les indiquez dans le document (nom, résumé, temps estimé, affectation, remarques)
  • vous répartissez les tâches entre les membre du groupe
  • vous faites le points sur les tâches qui étaient à faire (finis, temps effectif, ...)

Ce document sert à planifier votre travail, à répartir le travail, et aussi à vérifier le bon fonctionnement du groupe. Il permet à votre enseignant de détecter des disfonctionnements au sein d'un groupe. Mais si vous constatez vous même des dysfonctionnements, il vous est conseillé de les rapporter le plus vite possible à votre intervenant. (Par exemple: absence répété d'un membre, travail non fait, ...)

Document d'analyse et de conception

C'est le document principal de votre projet. Il doit suivre le template proposé dans le livre support du cours.

Dans votre documents on doit trouver:

  • Le nom de tous les membres du groupe.
  • La date de rédaction et le nom du (es) rédacteur(s)
  • Les pages sont numérotées.
  • Si un document doit être rendu plusieurs fois parce qu’il a évolué, il doit posséder un numéro de version et un historique.
  • Vous devez suivre le template proposé dans le livre.

Travail collaboratif

Votre projet est un travail collaboratif entre les membres de votre équipe.

De plus, il doit être possible de suivre l'évolution de votre projet, et de savoir qui a écrit quoi dans les documents. Pour cela, il faut utiliser GIT, et des documents de type texte. Afin de permettre la mise en page de votre document, vous devez utiliser un langage d'édition comme markdown, et un éditeur adéquat comme atom.

Vous devez utiliser des outils facilitant la collaboration :

  • git
    • pour partager les documents
    • vous pouvez créer un compte git au FIL (voir les pages du FIL)
  • fichier texte pour le document d'analyse
    • atom comme éditeur
    • markdown comme langage d'édition.

Vous ne pouvez pas utiliser google doc car celui-ci ne permet pas le suivi de projet.

Contenu de la maquette

  • Sauf indication contraire, la maquette doit contenir tout les écrans de l'application, y compris les écrans d'erreurs et de validation. Cela reste une maquette: l'application n'est pas opérationnelle. L'enchainement des pages est factice (lien hypertexte, pas de vérification de données ni de calcul).


Evaluation

L'évaluation s'effectue suivant une procédure de contrôle continu. Il y a 3 rapports a rendre dont un finale.
Il n'y a pas d'examen final, la soutenance finale tient lieu d'examen.
Il y a un examen de rattrapage.

Un sujet de projet est donné en début de semestre. Le projet consiste a analyser et concevoir une application d'après le sujet. Chaque rapport correspond à une itération de cette analyse et conception.

L'unité acquise apporte 5 ECTS.


Cedric Dumoulin
dernière modification : 22/09/2017 à 16:22:15
documents

Documents GL


Cedric Dumoulin
dernière modification : 01/10/2018 à 12:57:39