Evaluation blanche du 14/04/2020 - 16h33

Added by Marc CHEVALDONNE about 1 month 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]

Comments