News

Big todo: Evaluation blanche du 05/05/2020 - 19h03

Added by Marc CHEVALDONNE over 1 year ago

Rappel :
  • ne rendez qu’un seul document (pdf de préférence), contenant l’intégralité des schémas, diagrammes, descriptions pour les 3 modules,
  • ne rendez qu’une seule solution faites de plusieurs projets et ressources pour vos programmes
  • il y a 2 notes par module :
    • une partie écrite (appelée « documents »)
    • une partie développement (appelée « programmation »)
  • une évaluation blanche n'est qu'indicative : elle ne comptera pas dans la moyenne. Le soin apporté aux corrections n'est pas le même que pour l'évaluation finale et les notes blanches ne sont qu'un aperçu de votre travail à un instant t.
  • Critères d’évaluation pour chaque note :
    (Note : le barème n’est pas définitif et très susceptible d’évoluer ; il n’est donné qu’à titre indicatif)

Bilan
Au total : 13/120

Objets 2 : Conception et Programmation Orientées Objets (C#, .NET)

Documents : /20

  • diagramme de paquetage [sur 2 points]
  • diagramme de classes [sur 8 points]
  • diagramme de séquence (sur quelques cas particuliers) [sur 2 points]
  • description écrite de l’architecture (dont patrons de conception, dépendances…) [sur 8 points]
  • Note : chaque diagramme doit être accompagné de notes et d’une description écrite.

Programmation : /20

  • bases (classes, structures, instances, …) [sur 2 points]
  • abstraction (héritage, interfaces, polymorphisme) [sur 3 points]
  • collections simples (tableaux, listes…) [sur 2 points]
  • collections avancées (dictionnaires) [sur 2 points]
  • encapsulation [sur 5 points]
  • tests (fonctionnels et/ou unitaires) [sur 4 points]
  • LINQ [sur 1 point]
  • évènements (cf. module IHM) [sur 1 point]

IHM : Interface Homme-Machine (XAML, WPF)

Documents : 12/20

  • description du contexte [sur 4 points]
    Les bémols sont :
    - la position dans le document (pourquoi ne commence-t-on pas avec le contexte ?)
    - la mise en page,
    - quelques fautes restantes
    Bon travail sinon.
    => 3/4
  • sketchs [sur 4 points]
    C'est propre, mais vos sketchs manquent de cohérence et de fausses données qui aideraient à les interpréter.
    Vous parlez souvent d'oeuvre (films, séries, livres, mais aussi jeux vidéo) mais dans un sketch il y a "les courses du confinement". Je ne sais vraiment plus où j'en suis. Ce sont des to-do listes personnalisées ou partagées ???
    "Les courses du confinement" c'est une oeuvre ??
    Je n'ai pas compris le coup de la croix pour supprimer de la liste à côté du bouton ToDo.
    Pour le reste, c'est propre.
    => 2/4
  • storyboards [sur 4 points]
    Très bien. Le storyboard lève toutes les ambiguïtés. Il n'y a que la mise en page qui est décevante et des fautes d'orthographe.
    => 3/4
  • diagramme de cas d’utilisation [sur 5 points]
    C'est très bien compris, aussi bien pour la forme du diagramme que la forme de la description.
    Quelques critiques :
    - certaines description pourraient être améliorées : par exemple l'ajout d'un élément à la done list doit éventuellement enlever cet élément de la todo list.
    - quelques cas pourraient être davantage détaillés.
    - quelques fautes.
    => 4/5
  • considérations ergonomiques [sur 2 points]
  • prise en compte de l’accessibilité [sur 1 point]

Programmation : 0/20

*_Il faut ajouter le projet et les solutions.
Il faut avancer sur le code.

Vous semblez avancer, mais il n'y a toujours pas le projet. Je ne corrige pas dans ces conditions._*

  • XAML :
    • répartition dans l’espace (layout des vues et usercontrols) [sur 2 points]
      Il n'y a aucune répartition dans l'espace.
      => 0/2
    • utilisation des controls (vues et usercontrols) [sur 1 point]
      boutons et ellipses seulement.
      => 0/1
    • ressources, styles [sur 2 points]
      pas de ressources, pas de styles.
      => 0/2
    • DataTemplate (locaux et globaux) [sur 2 points]
  • boucle Model <-> View
    • gestion d’évènements sur la vue [sur 2 points]
    • gestion d’évènements depuis le métier (notifications) [sur 2 points]
    • DataBinding (sur le Master) [sur 2 points]
    • DataBinding (sur le Detail) [sur 2 points]
    • DataBinding sur les UserControl + Dependency Property [sur 2 points]
  • gestion du Master-Detail [sur 3 points]

Projet Tuteuré S2

Documents : /20

  • diagramme de paquetage mettant en avant la partie persistance [sur 2 points]
  • diagramme de classes mettant en avant la partie persistance [sur 4 points]
  • diagramme de classes sur votre (vos) partie(s) ajoutée(s) [sur 4 points]
  • vidéo de 1 à 3 minute(s) du projet [sur 10 points]

Programmation : 0/20

  • persistance (XML, JSON, BDD, WebService…) [sur 3 points]
  • autre ajout personnel [sur 3 points]
  • qualité
    • documentation du code [sur 2 points]
    • utilisation du repository subversion ou git [sur 2 points]
      Il faut laisser un message à chaque soumission
      Il manque des fichiers. Il y en a d'autres inutiles.

      => 0/2_*
  • fonctionnement de l’application
    • compilation [sur 3 points]
      sans projet, il n'y a rien à compiler.
      => 0/3
    • exécution [sur 5 points]
    • déploiement [sur 2 points]

Big todo: Evaluation blanche du 21/04/2020 - 16h30

Added by Marc CHEVALDONNE over 1 year ago

Rappel :
  • ne rendez qu’un seul document (pdf de préférence), contenant l’intégralité des schémas, diagrammes, descriptions pour les 3 modules,
  • ne rendez qu’une seule solution faites de plusieurs projets et ressources pour vos programmes
  • il y a 2 notes par module :
    • une partie écrite (appelée « documents »)
    • une partie développement (appelée « programmation »)
  • une évaluation blanche n'est qu'indicative : elle ne comptera pas dans la moyenne. Le soin apporté aux corrections n'est pas le même que pour l'évaluation finale et les notes blanches ne sont qu'un aperçu de votre travail à un instant t.
  • Critères d’évaluation pour chaque note :
    (Note : le barème n’est pas définitif et très susceptible d’évoluer ; il n’est donné qu’à titre indicatif)

Bilan
Au total : 13/120

Objets 2 : Conception et Programmation Orientées Objets (C#, .NET)

Documents : /20

  • diagramme de paquetage [sur 2 points]
  • diagramme de classes [sur 8 points]
  • diagramme de séquence (sur quelques cas particuliers) [sur 2 points]
  • description écrite de l’architecture (dont patrons de conception, dépendances…) [sur 8 points]
  • Note : chaque diagramme doit être accompagné de notes et d’une description écrite.

Programmation : /20

  • bases (classes, structures, instances, …) [sur 2 points]
  • abstraction (héritage, interfaces, polymorphisme) [sur 3 points]
  • collections simples (tableaux, listes…) [sur 2 points]
  • collections avancées (dictionnaires) [sur 2 points]
  • encapsulation [sur 5 points]
  • tests (fonctionnels et/ou unitaires) [sur 4 points]
  • LINQ [sur 1 point]
  • évènements (cf. module IHM) [sur 1 point]

IHM : Interface Homme-Machine (XAML, WPF)

Documents : 12/20

  • description du contexte [sur 4 points]
    Les bémols sont :
    - la position dans le document (pourquoi ne commence-t-on pas avec le contexte ?)
    - la mise en page,
    - quelques fautes restantes
    Bon travail sinon.
    => 3/4
  • sketchs [sur 4 points]
    C'est propre, mais vos sketchs manquent de cohérence et de fausses données qui aideraient à les interpréter.
    Vous parlez souvent d'oeuvre (films, séries, livres, mais aussi jeux vidéo) mais dans un sketch il y a "les courses du confinement". Je ne sais vraiment plus où j'en suis. Ce sont des to-do listes personnalisées ou partagées ???
    "Les courses du confinement" c'est une oeuvre ??
    Je n'ai pas compris le coup de la croix pour supprimer de la liste à côté du bouton ToDo.
    Pour le reste, c'est propre.
    => 2/4
  • storyboards [sur 4 points]
    Très bien. Le storyboard lève toutes les ambiguïtés. Il n'y a que la mise en page qui est décevante et des fautes d'orthographe.
    => 3/4
  • diagramme de cas d’utilisation [sur 5 points]
    C'est très bien compris, aussi bien pour la forme du diagramme que la forme de la description.
    Quelques critiques :
    - certaines description pourraient être améliorées : par exemple l'ajout d'un élément à la done list doit éventuellement enlever cet élément de la todo list.
    - quelques cas pourraient être davantage détaillés.
    - quelques fautes.
    => 4/5
  • considérations ergonomiques [sur 2 points]
  • prise en compte de l’accessibilité [sur 1 point]

Programmation : 0/20

Il faut ajouter le projet et les solutions.
Il faut avancer sur le code.

  • XAML :
    • répartition dans l’espace (layout des vues et usercontrols) [sur 2 points]
      Il n'y a aucune répartition dans l'espace.
      => 0/2
    • utilisation des controls (vues et usercontrols) [sur 1 point]
      boutons et ellipses seulement.
      => 0/1
    • ressources, styles [sur 2 points]
      pas de ressources, pas de styles.
      => 0/2
    • DataTemplate (locaux et globaux) [sur 2 points]
  • boucle Model <-> View
    • gestion d’évènements sur la vue [sur 2 points]
    • gestion d’évènements depuis le métier (notifications) [sur 2 points]
    • DataBinding (sur le Master) [sur 2 points]
    • DataBinding (sur le Detail) [sur 2 points]
    • DataBinding sur les UserControl + Dependency Property [sur 2 points]
  • gestion du Master-Detail [sur 3 points]

Projet Tuteuré S2

Documents : /20

  • diagramme de paquetage mettant en avant la partie persistance [sur 2 points]
  • diagramme de classes mettant en avant la partie persistance [sur 4 points]
  • diagramme de classes sur votre (vos) partie(s) ajoutée(s) [sur 4 points]
  • vidéo de 1 à 3 minute(s) du projet [sur 10 points]

Programmation : 1/20

  • persistance (XML, JSON, BDD, WebService…) [sur 3 points]
  • autre ajout personnel [sur 3 points]
  • qualité
    • documentation du code [sur 2 points]
    • utilisation du repository subversion ou git [sur 2 points]
      Il faut laisser un message à chaque soumission
      => 1/2
  • fonctionnement de l’application
    • compilation [sur 3 points]
      sans projet, il n'y a rien à compiler.
      => 0/3
    • exécution [sur 5 points]
    • déploiement [sur 2 points]

Big todo: Evaluation blanche du 14/04/2020 - 16h33

Added by Marc CHEVALDONNE over 1 year ago

Rappel :
  • ne rendez qu’un seul document (pdf de préférence), contenant l’intégralité des schémas, diagrammes, descriptions pour les 3 modules,
  • ne rendez qu’une seule solution faites de plusieurs projets et ressources pour vos programmes
  • il y a 2 notes par module :
    • une partie écrite (appelée « documents »)
    • une partie développement (appelée « programmation »)
  • une évaluation blanche n'est qu'indicative : elle ne comptera pas dans la moyenne. Le soin apporté aux corrections n'est pas le même que pour l'évaluation finale et les notes blanches ne sont qu'un aperçu de votre travail à un instant t.
  • Critères d’évaluation pour chaque note :
    (Note : le barème n’est pas définitif et très susceptible d’évoluer ; il n’est donné qu’à titre indicatif)

Bilan
Au total : 7,5/120

Objets 2 : Conception et Programmation Orientées Objets (C#, .NET)

Documents : /20

  • diagramme de paquetage [sur 2 points]
  • diagramme de classes [sur 8 points]
  • diagramme de séquence (sur quelques cas particuliers) [sur 2 points]
  • description écrite de l’architecture (dont patrons de conception, dépendances…) [sur 8 points]
  • Note : chaque diagramme doit être accompagné de notes et d’une description écrite.

Programmation : /20

  • bases (classes, structures, instances, …) [sur 2 points]
  • abstraction (héritage, interfaces, polymorphisme) [sur 3 points]
  • collections simples (tableaux, listes…) [sur 2 points]
  • collections avancées (dictionnaires) [sur 2 points]
  • encapsulation [sur 5 points]
  • tests (fonctionnels et/ou unitaires) [sur 4 points]
  • LINQ [sur 1 point]
  • évènements (cf. module IHM) [sur 1 point]

IHM : Interface Homme-Machine (XAML, WPF)

Documents : 5/20

  • description du contexte [sur 4 points]
    Je n'ai pas trouvé de mise en contexte.
    Les personas sont bien. La user storie est dans le bon ton, mais ne donne pas trop d'indications sur l'utilisation de l'application par Arsene.
    Je veux dire l'utilisation quotidienne, ou hebdomadaire ou mensuelle. Pas vraiment où Arsene va cliquer.
    L'histoire d'Arsene doit nous permettre de comprendre à quoi sert cette applicatiton, quelles utilisations peuvent en être faites, pour en déduire le meilleur design possible.
    Il y aussi trop de fautes d'orthographe.

    C'est plutôt très bien. Mais il y a quelques détails qui me chiffonnent :
    - à la fin de la lecture du contexte, je me suis dit qu'il était court mais très clair. Mais après avoir fini la lecture des user stories, je me suis rendu compte que tout n'était pas clair. A la fin du contexte, j'avais l'impression que l'utilisateur se faisait ses propres todolists, mais je m'aperçois en lisant les user stories, qu'elles sont en fait accessibles quelque part, modifiables, et que chacun peut dire où il en est.
    En conséquence, je pense que le contexte (quoique très bien écrit) devrait être étoffé pour qu'on comprenne mieux l'objectif de Big Todo.
    Il faudra aussi faire la mise en page.
    Les personas et les user stories sont très bien.
    Beaucoup moins de fautes.
    => 3/4
  • sketchs [sur 4 points]
    Il manque une vue d'ensemble. J'ai l'impression de n'avoir que des bouts de fenêtre, sans savoir comment ils vont s'assembler.
    Les photos ne sont pas toujours très lisibles (c'est un peu moche quand même comme sketchs...).
    Je me souviens très bien avoir dit qu'on ne tenait pas compte des facteurs d'échelle dans les sketchs, mais là, on arrive pas du tout à savoir si la fenêtre sera une popup ou un plein écran.
    La 2ème image est particulièrement peu lisible.
    Parfois, on dirait un storyboard (dernière image).
    La description est dans le bon format, mais parfois courte. Elle pourrait être accompagnée de flèches, de pastilles numérotées, de cadres de couleur pour faire le lien avec les sketchs.
    => 1/4
  • storyboards [sur 4 points]
    pas trouvé ?
  • diagramme de cas d’utilisation [sur 5 points]
    Certains cas n'ont pas de verbes à l'infinitif (Barre de menu, To-do/Done...).
    Vous mettez des relations entre cas en cherchant une suite logique. Ce n'est pas l'objectif du diagramme de cas. Il dit ce qu'on peut faire. Dans la description, on pourra être plus précis.
    Par exemple, "Choisir une catégorie" inclut "Autres" étendu par "Ajouter à une liste". Personnellement, j'aurais choisi directement : "Ajouter un élément à une liste" (éventuellement généralisé en "ajouter à la to-do list" et "ajouter à la done list" mais même ça, je crois que je ne l'aurais pas mis), et j'aurais ajouté inclut "sélectionner un élément d'une liste".
    Le diagramme de cas ne doit pas avoir de lien avec une quelconque description de la vue (barre de menu par exemple...).
    D'après DiagrammeAjout, si on rentre des informations, on est obligé de sauvegarder et de choisir une image. C'est bien le cas ? "Revenir à la catégorie" relève de l'utilisation de l'interface, et pour moi, n'est pas un cas d'utilisation. Je pense même que ce schéma n'a pas forcément lieu d'être. "Ajouter/Modifier un élément" dans le diagramme de cas général aurait sûrement été suffisant.
    Concernant la description, les noms de cas ne correspondent pas à ceux qu'il y dans le diagramme !
    Vos descriptions parlent quasiment uniquement de l'utilisation de la vue (où faut-il cliquer, regarder, etc.). Comme dit précédemment et dans la vidéo, ce n'est pas l'objectif du diagramme de cas et de sa description.
    On peut éventuellement rajouter une note dessus pour le mentionner, mais le but est avant tout d'expliquer ce que peut faire l'utilisateur, pas comment il peut le faire.
    Beaucoup de travail néanmoins, je suis sûr que ça va finir par payer. Courage !
    => 1/5
  • considérations ergonomiques [sur 2 points]
  • prise en compte de l’accessibilité [sur 1 point]

Programmation : /20

Il faut vraiment commencer le code maintenant !

  • XAML :
    • répartition dans l’espace (layout des vues et usercontrols) [sur 2 points]
    • utilisation des controls (vues et usercontrols) [sur 1 point]
    • ressources, styles [sur 2 points]
    • DataTemplate (locaux et globaux) [sur 2 points]
  • boucle Model <-> View
    • gestion d’évènements sur la vue [sur 2 points]
    • gestion d’évènements depuis le métier (notifications) [sur 2 points]
    • DataBinding (sur le Master) [sur 2 points]
    • DataBinding (sur le Detail) [sur 2 points]
    • DataBinding sur les UserControl + Dependency Property [sur 2 points]
  • gestion du Master-Detail [sur 3 points]

Projet Tuteuré S2

Documents : /20

  • diagramme de paquetage mettant en avant la partie persistance [sur 2 points]
  • diagramme de classes mettant en avant la partie persistance [sur 4 points]
  • diagramme de classes sur votre (vos) partie(s) ajoutée(s) [sur 4 points]
  • vidéo de 1 à 3 minute(s) du projet [sur 10 points]

Programmation : 2,5/20

  • persistance (XML, JSON, BDD, WebService…) [sur 3 points]
  • autre ajout personnel [sur 3 points]
  • qualité
    • documentation du code [sur 2 points]
    • utilisation du repository subversion ou git [sur 2 points]
      ok, mais n'oubliez pas de mettre des messages à chaque fois que vous soumettez sur le repository
      Très bien
      => 2/2
  • fonctionnement de l’application
    • compilation [sur 3 points]
    • exécution [sur 5 points]
    • déploiement [sur 2 points]

Big todo: Evaluation blanche du 06/04/2020 - 11h59

Added by Marc CHEVALDONNE over 1 year ago

Rappel :
  • ne rendez qu’un seul document (pdf de préférence), contenant l’intégralité des schémas, diagrammes, descriptions pour les 3 modules,
  • ne rendez qu’une seule solution faites de plusieurs projets et ressources pour vos programmes
  • il y a 2 notes par module :
    • une partie écrite (appelée « documents »)
    • une partie développement (appelée « programmation »)
  • une évaluation blanche n'est qu'indicative : elle ne comptera pas dans la moyenne. Le soin apporté aux corrections n'est pas le même que pour l'évaluation finale et les notes blanches ne sont qu'un aperçu de votre travail à un instant t.
  • Critères d’évaluation pour chaque note :
    (Note : le barème n’est pas définitif et très susceptible d’évoluer ; il n’est donné qu’à titre indicatif)

Bilan
Au total : /120

Objets 2 : Conception et Programmation Orientées Objets (C#, .NET)

Documents : /20

  • diagramme de paquetage [sur 2 points]
  • diagramme de classes [sur 8 points]
  • diagramme de séquence (sur quelques cas particuliers) [sur 2 points]
  • description écrite de l’architecture (dont patrons de conception, dépendances…) [sur 8 points]
  • Note : chaque diagramme doit être accompagné de notes et d’une description écrite.

Programmation : /20

  • bases (classes, structures, instances, …) [sur 2 points]
  • abstraction (héritage, interfaces, polymorphisme) [sur 3 points]
  • collections simples (tableaux, listes…) [sur 2 points]
  • collections avancées (dictionnaires) [sur 2 points]
  • encapsulation [sur 5 points]
  • tests (fonctionnels et/ou unitaires) [sur 4 points]
  • LINQ [sur 1 point]
  • évènements (cf. module IHM) [sur 1 point]

IHM : Interface Homme-Machine (XAML, WPF)

Documents : 1/20

  • description du contexte [sur 4 points]
    Je n'ai pas trouvé de mise en contexte.
    Les personas sont bien. La user storie est dans le bon ton, mais ne donne pas trop d'indications sur l'utilisation de l'application par Arsene.
    Je veux dire l'utilisation quotidienne, ou hebdomadaire ou mensuelle. Pas vraiment où Arsene va cliquer.
    L'histoire d'Arsene doit nous permettre de comprendre à quoi sert cette applicatiton, quelles utilisations peuvent en être faites, pour en déduire le meilleur design possible.
    Il y aussi trop de fautes d'orthographe.
    => 1/4
  • sketchs [sur 4 points]
  • storyboards [sur 4 points]
  • diagramme de cas d’utilisation [sur 5 points]
  • considérations ergonomiques [sur 2 points]
  • prise en compte de l’accessibilité [sur 1 point]

Programmation : /20

  • XAML :
    • répartition dans l’espace (layout des vues et usercontrols) [sur 2 points]
    • utilisation des controls (vues et usercontrols) [sur 1 point]
    • ressources, styles [sur 2 points]
    • DataTemplate (locaux et globaux) [sur 2 points]
  • boucle Model <-> View
    • gestion d’évènements sur la vue [sur 2 points]
    • gestion d’évènements depuis le métier (notifications) [sur 2 points]
    • DataBinding (sur le Master) [sur 2 points]
    • DataBinding (sur le Detail) [sur 2 points]
    • DataBinding sur les UserControl + Dependency Property [sur 2 points]
  • gestion du Master-Detail [sur 3 points]

Projet Tuteuré S2

Documents : /20

  • diagramme de paquetage mettant en avant la partie persistance [sur 2 points]
  • diagramme de classes mettant en avant la partie persistance [sur 4 points]
  • diagramme de classes sur votre (vos) partie(s) ajoutée(s) [sur 4 points]
  • vidéo de 1 à 3 minute(s) du projet [sur 10 points]

Programmation : 1,5/20

  • persistance (XML, JSON, BDD, WebService…) [sur 3 points]
  • autre ajout personnel [sur 3 points]
  • qualité
    • documentation du code [sur 2 points]
    • utilisation du repository subversion ou git [sur 2 points]
      ok, mais n'oubliez pas de mettre des messages à chaque fois que vous soumettez sur le repository
      => 1,5/2
  • fonctionnement de l’application
    • compilation [sur 3 points]
    • exécution [sur 5 points]
    • déploiement [sur 2 points]

Projets 2020: Continuité Pédagogique

Added by Jacques LAFFONT over 1 year ago

Les projets continuent malgré le confinement.

  • Essayez d'avancer au mieux les parties théoriques et organisationnelles.
  • Tenir à jour le Gantt modifié sur la forge,
  • Définition des tâches de sous-traitances,
  • Mise en place de la structure du SVN,
  • Rédaction du rapport -> EEO,
  • Ébauche et structuration du Wiki.

Les cours de gestion de projet et les revues d'appel d'offres sont maintenues.

Lors des séances de projets à l’emploi du temps, les enseignants sont disponibles pour répondre à vos questions.
  • Utilisez les demandes pour les questions importantes.

libszdist: v0.11.0 is out

Added by David PICARD over 1 year ago

Change the build system from qmake to CMake, and produce a Windows installer for easy setup and use.

- Rename utility szdist to szinv.
- Windows binaries are now distributed as an installer that creates a start menu entry to open a preconfigured Bash shell, provided Git is installed.

Projets 2020: Documents projets

Added by Jacques LAFFONT almost 2 years ago

Les documents suivants contiennent :
  • le détail sur le fonctionnement de la forge,
  • Le fonctionnement des projets ainsi que les séances de micromanagement,
  • La fiche d'emprunt de matériel.

Lien : http://forge.clermont-universite.fr/projects/polytechprojetsge/documents

projet04_javafx_2019: Modèle évaluation

Added by Cedric BOUHOURS almost 2 years ago

Rappel :
  • Le contenu de votre branche master : un dossier documents, un dossier projet et un jar exécutable.
  • Pour la partie documentation, rendez un seul document au format pdf, contenant l’intégralité des schémas, diagrammes, descriptions.

DOCUMENTATION : 0/20

  • Je sais concevoir un diagramme UML intégrant des notions de qualité et correspondant exactement à l’application que j’ai à développer. [sur 7 points]
    PREUVE :
    Pas encore
    => 0/7
  • Je sais décrire un diagramme UML en mettant en valeur et en justifiant les éléments essentiels. [sur 5 points]
    PREUVE :
    Pas encore
    => 0/5
  • Je sais documenter mon code et en générer la documentation. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais décrire le contexte de mon application, pour que n’importe qui soit capable de comprendre à quoi elle sert. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais faire un diagramme de cas d’utilisation pour mettre en avant les différentes fonctionnalités de mon application. [sur 4 points]
    PREUVE :
    Pas encore
    => 0/4

Programmation : 0/40

  • Je maîtrise la notion d’immuabilité de la classe String. [sur 0.5 point]
    PREUVE :
    Pas encore
    => 0/0.5
  • Je maîtrise les règles de nommage Java. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais binder bidirectionnellement deux propriétés JavaFX. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais binder unidirectionnellement deux propriétés JavaFX. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais coder une classe Java en respectant des contraintes de qualité de lecture de code. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais contraindre les éléments de ma vue, avec du binding FXML. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais définir une CellFactory fabriquant des cellules qui se mettent à jour au changement du modèle. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais développer une application graphique en JavaFX en utilisant FXML. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais éviter la duplication de code. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais hiérarchiser mes classes pour spécialiser leur comportement. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais intercepter des évènements en provenance de la fenêtre JavaFX. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais maintenir une encapsulation adéquate dans mes classes. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais maintenir, dans un projet, une responsabilité unique pour chacune de mes classes. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais gérer la persistance de mon modèle. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais surveiller l’élément sélectionné dans un composant affichant un ensemble de données. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais utiliser à mon avantage le polymorphisme. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais utiliser certains composants simples que me propose JavaFX. [sur 0.5 point]
    PREUVE :
    Pas encore
    => 0/0.5
  • Je sais utiliser certains layout que me propose JavaFX. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais utiliser GIT pour travailler avec mon binôme sur le projet. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais utiliser le type statique adéquat pour mes attributs ou variables. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais utiliser les collections. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais utiliser les différents composants complexes (listes, combo…) que me propose JavaFX. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais utiliser les lambda-expression. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais utiliser les listes observables de JavaFX. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais utiliser les packages à bon escient dans un projet. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais utiliser un convertisseur lors d’un bind entre deux propriétés JavaFX. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais utiliser un fichier CSS pour styler mon application JavaFX. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais utiliser un formateur lors d’un bind entre deux propriétés JavaFX. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1

La dure l'oie des Oscars: Modèle évaluation

Added by Cedric BOUHOURS almost 2 years ago

Rappel :
  • Le contenu de votre branche master : un dossier documents, un dossier projet et un jar exécutable.
  • Pour la partie documentation, rendez un seul document au format pdf, contenant l’intégralité des schémas, diagrammes, descriptions.

DOCUMENTATION : 0/20

  • Je sais concevoir un diagramme UML intégrant des notions de qualité et correspondant exactement à l’application que j’ai à développer. [sur 7 points]
    PREUVE :
    Pas encore
    => 0/7
  • Je sais décrire un diagramme UML en mettant en valeur et en justifiant les éléments essentiels. [sur 5 points]
    PREUVE :
    Pas encore
    => 0/5
  • Je sais documenter mon code et en générer la documentation. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais décrire le contexte de mon application, pour que n’importe qui soit capable de comprendre à quoi elle sert. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais faire un diagramme de cas d’utilisation pour mettre en avant les différentes fonctionnalités de mon application. [sur 4 points]
    PREUVE :
    Pas encore
    => 0/4

Programmation : 0/40

  • Je maîtrise la notion d’immuabilité de la classe String. [sur 0.5 point]
    PREUVE :
    Pas encore
    => 0/0.5
  • Je maîtrise les règles de nommage Java. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais binder bidirectionnellement deux propriétés JavaFX. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais binder unidirectionnellement deux propriétés JavaFX. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais coder une classe Java en respectant des contraintes de qualité de lecture de code. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais contraindre les éléments de ma vue, avec du binding FXML. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais définir une CellFactory fabriquant des cellules qui se mettent à jour au changement du modèle. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais développer une application graphique en JavaFX en utilisant FXML. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais éviter la duplication de code. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais hiérarchiser mes classes pour spécialiser leur comportement. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais intercepter des évènements en provenance de la fenêtre JavaFX. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais maintenir une encapsulation adéquate dans mes classes. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais maintenir, dans un projet, une responsabilité unique pour chacune de mes classes. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais gérer la persistance de mon modèle. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais surveiller l’élément sélectionné dans un composant affichant un ensemble de données. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais utiliser à mon avantage le polymorphisme. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais utiliser certains composants simples que me propose JavaFX. [sur 0.5 point]
    PREUVE :
    Pas encore
    => 0/0.5
  • Je sais utiliser certains layout que me propose JavaFX. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais utiliser GIT pour travailler avec mon binôme sur le projet. [sur 2 points]
    PREUVE :
    Pas encore
    => 0/2
  • Je sais utiliser le type statique adéquat pour mes attributs ou variables. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais utiliser les collections. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais utiliser les différents composants complexes (listes, combo…) que me propose JavaFX. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais utiliser les lambda-expression. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais utiliser les listes observables de JavaFX. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais utiliser les packages à bon escient dans un projet. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais utiliser un convertisseur lors d’un bind entre deux propriétés JavaFX. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais utiliser un fichier CSS pour styler mon application JavaFX. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1
  • Je sais utiliser un formateur lors d’un bind entre deux propriétés JavaFX. [sur 1 point]
    PREUVE :
    Pas encore
    => 0/1

H3G3: Evaluation blanche du 18 juin 2019 - 10h07

Added by Marc CHEVALDONNE over 2 years ago

Rappel :
  • ne rendez qu’un seul document (pdf de préférence), contenant l’intégralité des schémas, diagrammes, descriptions pour les 3 modules,
  • ne rendez qu’une seule solution faites de plusieurs projets et ressources pour vos programmes
  • il y a 2 notes par module :
    • une partie écrite (appelée « documents »)
    • une partie développement (appelée « programmation »)
  • une évaluation blanche n'est qu'indicative : elle ne comptera pas dans la moyenne. Le soin apporté aux corrections n'est pas le même que pour l'évaluation finale et les notes blanches ne sont qu'un aperçu de votre travail à un instant t.
  • Critères d’évaluation pour chaque note :
    (Note : le barème n’est pas définitif et très susceptible d’évoluer ; il n’est donné qu’à titre indicatif)

Bilan
Au total : 43/120

Objets 2 : Conception et Programmation Orientées Objets (C#, .NET)

Documents : 8/20

  • diagramme de paquetage [sur 2 points]
    C'est un début. Il manque la description (-1). Il manque les dépendances entre assemblages.
    A poursuivre.
    => 0,5/2
  • diagramme de classes [sur 8 points]
    Très bien pour l'écriture de l'UML. Il manque juste quelques noms de membres sur les associations, mais tout est clair.
    Certaines multiplicités ne sont pas bonnes.

    Il manque la description ( -4). Je trouve que la description peut-être pratique dans le diagramme, mais il faudrait jouer sur les couleurs pour permettre de la différencier plus rapidement des classes.
    Néanmoins, je trouve qu'elle ne permet pas de remplacer une description plus "classique" dans du texte. En d'autres termes, vous pouvez la laisser, mais rajoutez quand même une vraie description, beaucoup plus détaillée, en particulier sur l'architecture.
    Corrigez les fautes d'orthographe également.
    => 5,5/8
  • diagramme de séquence (sur quelques cas particuliers) [sur 2 points]
    => 0/2
  • description écrite de l’architecture (dont patrons de conception, dépendances…) [sur 8 points]
    Il est temps d'essayer de décrire votre architecture.
    A travers vos "mini-descriptions", vous parlez de Façade et de Stratégie, mais c'est trop court. Vous n'expliquez pas le fonctionnement de ces patrons, et ne passez pas assez de temps sur les avantages qu'ils vous procurent.
    => 2/8
  • Note : chaque diagramme doit être accompagné de notes et d’une description écrite.

Programmation : 9/20

  • bases (classes, structures, instances, …) [sur 2 points]
    Bien dans l'ensemble.
    De bonnes choses. Pour votre constructeur avec ou sans code de réduc, choisissez une instance par défaut qui ne fait rien.
    Idem pour le constructeur de Manager par défaut.

    Trop de magic strings.
    Décomposez Manager.ModifierPlaneteAvantConversionDeLaNouvelleValeur en plusieurs sous-méthodes privées pour améliorer la lisibilité.
    Attention : pas d'affichage Console dans les classes (Stub).
    => 1,5/2
  • abstraction (héritage, interfaces, polymorphisme) [sur 3 points]
    Bien compris pour le code de réduction. L'héritage n'est pas encore très utile.
    Bien
    => 3/3
  • collections simples (tableaux, listes…) [sur 2 points]
    Il manque les protocoles d'égalité des classes utilisées dans les collections.
    Initialisez vos collections via les initialiseurs.
    Utilisez les types de plus haut niveau en paramètres et retour de méthodes (IEnumerable<T>).
    => 0,5/2
  • collections avancées (dictionnaires) [sur 2 points]
    OK, mais des maladresses dans l'utilisation du dictionnaire (notamment la recherche d'éléments).
    Il manque les protocoles d'égalité.
    => 1/2
  • encapsulation [sur 5 points]
    bien pour l'utilisation des propriétés mais tous les setters sont publiques => un peu mieux le 05/06, mais il y en a encore pas mal.
    Les collections sont mal encapsulées.
    => 1/5
  • tests (fonctionnels et/ou unitaires) [sur 4 points]
    Ok mais il en faut plus.
    => 1/4
  • LINQ [sur 1 point]
    A utiliser (par exemple pour calculer le prix du voyage).
    Un petit Where.
    => 0,5/1
  • évènements (cf. module IHM) [sur 1 point]
    un tout petit PropertyChanged qui traine...
    => 0,5/1

IHM : Interface Homme-Machine (XAML, WPF)

Documents : 9/20

  • description du contexte [sur 4 points]
    Le contexte est bien écrit. Les deux personas n'apportent pas grand chose de différent : vous axez leur utilisation à tous les deux vers la simplicité et la rapidité.
    Vous auriez pu aussi faire référence à l'accès aux informations, la préparation d'un voyage, la gestion de favoris...
    Le descriptif est plus lourd à lire dans un contexte et pourrait plutôt accompagner les sketchs ou les introduire.
    J'inverserais donc les deux.

    => 3,5/4
  • sketchs [sur 4 points]
    Les sketchs sont propres.
    Il manque la description (2) -et par endroits, des fausses données pour aider à la lecture.
    => 2/4
  • storyboards [sur 4 points]
    pas trouvé Très bien. Peut-être un peu chargé quand même... On pourrait en faire plusieurs pour montrer différents scenarii.
    Il manque la description (-2)
    => 1,5/4
  • diagramme de cas d’utilisation [sur 5 points]
    OK pour la forme, mais :
    laissez les acteurs sur la gauche,
    les flèches en pointillés sont-elles des inclusions ou des extensions ?
    il manque certainement des inclusions/extensions.
    - la flèche d'extension ne me semble pas bonne, ou au moins, n'est pas dans le bon sens,
    - il manque la description (-2,5) : suite à ma réponse à la question de Lucie, ici, pour un diagramme de cas d'utilisation, la description n'est pas convenable. Il faut, pour chaque cas, un petit bloc de texte donnant le titre du cas, l'état de l'application avant le cas, le scénario d'utilisation, l'état de l'application après le cas.
    => 2/5
  • considérations ergonomiques [sur 2 points]
  • prise en compte de l’accessibilité [sur 1 point]

Programmation : 9/20

Ajoutez ce projet au reste de la solution.

J'ai corrigé VueSecours. J'aurais bien aimé qu'on fasse fonctionner votre première idée. Si vous le souhaitez, nous pouvons nous en occuper une fois que le gros (et le stress) sera fait.

  • XAML :
    • répartition dans l’espace (layout des vues et usercontrols) [sur 2 points]
      Bien (très classique mais compris).
      => 2/2
    • utilisation des controls (vues et usercontrols) [sur 1 point]
      ok
      => 1/1
    • ressources, styles [sur 2 points]
      Trop peu pour l'instant.
      => 1/2
    • DataTemplate (locaux et globaux) [sur 2 points]
      ok pour les DataTemplate locaux, simples.
      => 1/2
  • boucle Model <-> View
    • gestion d’évènements sur la vue [sur 2 points]
      ok pour la gestion des clicks sur les boutons.
      => 2/2
    • gestion d’évènements depuis le métier (notifications) [sur 2 points]
    • DataBinding (sur le Master) [sur 2 points]
      ok pour le binding sur les valeurs d'enum Compris. Peut-on modifier la source du Master, ajouter des planètes ?
      => 1/2
    • DataBinding (sur le Detail) [sur 2 points]
      j'attends que le premier binding fonctionne. ok, mais peut-on modifier également ?
      => 1/2
    • DataBinding sur les UserControl + Dependency Property [sur 2 points]
      pas de usercontrols
      => 0/2
  • gestion du Master-Detail [sur 3 points]

Projet Tuteuré S2

Documents : 3/20

  • diagramme de paquetage mettant en avant la partie persistance [sur 2 points]
    Le Stub apparait, mais il manque les dépendances entre assemblages et la description
    => 0,5/2
  • diagramme de classes mettant en avant la partie persistance [sur 4 points]
    Très bien. Il manque quelques précisions sur le type de persistance, et l'injection de dépendance.
    Il manque aussi la description ( -2). Il manque une vraie description détaillée.
    => 2,5/4
  • diagramme de classes sur votre (vos) partie(s) ajoutée(s) [sur 4 points]
  • vidéo de 1 à 3 minute(s) du projet [sur 10 points]

Programmation : 5/20

  • persistance (XML, JSON, BDD, WebService…) [sur 3 points]
    OK pour le Stub, il faut maintenant s'occuper aussi de la persistance.
    Utilisez les DataContract, c'est plus simple.
    => 1/3
  • autre ajout personnel [sur 3 points]
  • qualité
    • documentation du code [sur 2 points]
      Utilisez la notation standard avec /// effort à poursuivre
      => 2/2
    • utilisation du repository subversion ou git [sur 2 points]
      OK
      => 2/2
  • fonctionnement de l’application
    • compilation [sur 3 points]
      une petite erreur, sinon, ça compile. ne compile pas
      => 0/3
    • exécution [sur 5 points]
      le test et le début de la vue fonctionnent rien ne s'exécute.
      => 0/5
    • déploiement [sur 2 points]

1 2 3 4 ... 16 (11-20/158)

Also available in: Atom