Semainier GL 2018

Planning

Le planning est susceptible de changer au cours du semestre.

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 : 09/11/2018 à 14:28:15

Rendus de GL

• Dates des rendus 2018-2019
• Contenu des rendus
• Patrons pour le document de rendu
  • Premier rendu
  • Deuxième rendu
  • Troisième rendu
• Documents à produire
  • Document de suivi de projet
  • Document d'analyse et de conception
• Travail collaboratif
• Contenu de la maquette

Dates des rendus 2018-2019

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

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

• patrons pour le document de rendu
• voir aussi documents

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 logicielle

  • Quelle est l'architecture qui sera utilisée pour l'application (en couche, client/serveur ...)
    • Faire apparaitre (dans un diagramme de classes) les principaux paquetages participants à l'architecture logicielle.

• Hiérarchie des CUs

  • Classement des CUs en fonction des risques
  • 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).

Documents GL

• cours
• syllabus
• sujets
  • html
  • pdf
• Etude de cas :
  • Etude de cas v2
  • maquette
• td-tp
• patrons pour le document de rendu
• exemple de document de suivi de projet
  • SuiviProjectGl.html
  • SuiviProjectGl.ods
  • SuiviProjectGl.pdf
  • SuiviProjectGl.xlsx
• Papyrus
  • Papyrus est installé au M5
• Tutorial Papyrus