News

Evaluation blanche du 18 juin 2019 - 10h07

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

Evaluation blanche du 05 juin 2019 - 23h26

Added by Marc CHEVALDONNE about 3 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 : 36/120

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

Documents : 4/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).
    => 3,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.
    => 0/8
  • Note : chaque diagramme doit être accompagné de notes et d’une description écrite.

Programmation : 7,5/20

  • bases (classes, structures, instances, …) [sur 2 points]
    Bien dans l'ensemble.
    Evitez de passer des List par référence dans les méthodes.
    Préférez les chaînes verbatim pour les string sur plusieurs lignes.
    Attention aux magic numbers.
    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.
    Attention : pas d'affichage Console dans les classes (Stub).
    => 1,5/2
  • abstraction (héritage, interfaces, polymorphisme) [sur 3 points]
    Il y en a avec la persistance, mais peu exploitée pour le moment.
    L'injection semble partiellement comprise : comment fait-on pour injecter vos deux persistances en même temps ?

    Bien compris pour le code de réduction. L'héritage n'est pas encore très utile.
    => 2,5/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.
    => 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é.
    => 0,5/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.
    Plutôt que de faire les tests dans les constructeurs, intégrez-les dans les setters de vos propriétés.
    Les collections sont mal encapsulées.
    => 1/5
  • tests (fonctionnels et/ou unitaires) [sur 4 points]
    Un début de test de fonctionnel à avancer. 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]

IHM : Interface Homme-Machine (XAML, WPF)

Documents : 8/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]
    pas trouvé 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.
    - il manque la description (-2,5)
    => 1/5
  • considérations ergonomiques [sur 2 points]
  • prise en compte de l’accessibilité [sur 1 point]

Programmation : 6/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]
      quelques éléments inutiles (Grid, WrapPanel), en particulier dans page_info.xaml
      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]
      Vous gagneriez à les utiliser pour vos TextBlock et vos Button (au moins...).
      Trop peu pour l'instant.
      => 0,5/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.
      => 1/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
      => 0,5/2
    • DataBinding (sur le Detail) [sur 2 points]
      j'attends que le premier binding fonctionne.
      => 0/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 : 2/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).
    => 1,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 : 8,5/20

  • persistance (XML, JSON, BDD, WebService…) [sur 3 points]
    Un début avec le stub. L'injection de dépendance est à perfectionner.
    OK pour le Stub, il faut maintenant s'occuper aussi de la persistance.
    => 1/3
  • autre ajout personnel [sur 3 points]
  • qualité
    • documentation du code [sur 2 points]
      Utilisez la notation standard avec ///
      => 1,5/2
    • utilisation du repository subversion ou git [sur 2 points]
      des fichiers inutiles. OK
      => 2/2
  • fonctionnement de l’application
    • compilation [sur 3 points]
      ne compile plus une petite erreur, sinon, ça compile.
      => 2/3
    • exécution [sur 5 points]
      ne peut donc plus s'exécuter le test et le début de la vue fonctionnent
      => 2/5
    • déploiement [sur 2 points]

Evaluation blanche du 20 mai 2019 - 18h25

Added by Marc CHEVALDONNE about 3 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 : 21,5/120

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

Documents : 4/20

  • diagramme de paquetage [sur 2 points]
    pas trouvé
    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]
    Des erreurs dans l'écriture de l'UML (par exemple, l'héritage et l'implémentation d'interfaces, la multiplicité...).
    Très bien pour l'écriture de l'UML. Il manque juste quelques noms de membres sur les associations, mais tout est clair.
    Il manque la description (4).
    -Bien pour le reste.

    => 3,5/8
  • 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]
    Il est temps d'essayer de décrire votre architecture.
    => 0/8
  • Note : chaque diagramme doit être accompagné de notes et d’une description écrite.

Programmation : 6/20

  • bases (classes, structures, instances, …) [sur 2 points]
    Bien dans l'ensemble.
    Evitez de passer des List par référence dans les méthodes.
    Faites s'appeler les constructeurs d'une même classe.
    Utilisez StringBuilder pour les concaténations de chaînes de caractères.
    Préférez les chaînes verbatim pour les string sur plusieurs lignes.
    Attention aux magic numbers.
    => 1/2
  • abstraction (héritage, interfaces, polymorphisme) [sur 3 points]
    ok mais pas très utile pour le moment avec Administrateur.
    Il y en a avec la persistance, mais peu exploitée pour le moment.
    L'injection semble partiellement comprise : comment fait-on pour injecter vos deux persistances en même temps ?
    => 1/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.
    => 1/2
  • collections avancées (dictionnaires) [sur 2 points]
    OK, mais des maladresses dans l'utilisation du dictionnaire.
    Il manque les protocoles d'égalité.
    => 0,5/2
  • encapsulation [sur 5 points]
    bien pour l'utilisation des propriétés mais tous les setters sont publiques.
    Plutôt que de faire les tests dans les constructeurs, intégrez-les dans les setters de vos propriétés.
    Les collections sont mal encapsulées.
    => 1/5
  • tests (fonctionnels et/ou unitaires) [sur 4 points]
    Un début de test de fonctionnel à avancer.
    => 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]

IHM : Interface Homme-Machine (XAML, WPF)

Documents : 5/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/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é
    => 0/4
  • diagramme de cas d’utilisation [sur 5 points]
    pas trouvé
    => 0/5
  • considérations ergonomiques [sur 2 points]
  • prise en compte de l’accessibilité [sur 1 point]

Programmation : 2/20

Ajoutez ce projet au reste de la solution.

  • XAML :
    • répartition dans l’espace (layout des vues et usercontrols) [sur 2 points]
      ok quelques éléments inutiles (Grid, WrapPanel), en particulier dans page_info.xaml
      => 1/2
    • utilisation des controls (vues et usercontrols) [sur 1 point]
      ok
      => 1/1
    • ressources, styles [sur 2 points]
      Vous gagneriez à les utiliser pour vos TextBlock et vos Button (au moins...).
      => 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 : 2/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]
    Un début avec l'apparition du Stub. 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).
    => 1,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 : 2,5/20

  • persistance (XML, JSON, BDD, WebService…) [sur 3 points]
    Un début avec le stub. L'injection de dépendance est à perfectionner.
    => 0,5/3
  • autre ajout personnel [sur 3 points]
  • qualité
    • documentation du code [sur 2 points]
      par endroits mais peu. Utilisez la notation standard avec ///
      => 1/2
    • utilisation du repository subversion ou git [sur 2 points]
      des fichiers inutiles.
      => 1/2
  • fonctionnement de l’application
    • compilation [sur 3 points]
      ok ne compile plus
      => 0/3
    • exécution [sur 5 points]
      ok, mais il n'y a pas grand chose à exécuter pour l'instant. ne peut donc plus s'exécuter
      => 0/5
    • déploiement [sur 2 points]

Evaluation blanche du 13 mai 2019 - 21h28

Added by Marc CHEVALDONNE over 3 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 : 22/120

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

Documents : 2/20

  • diagramme de paquetage [sur 2 points]
    pas trouvé
    => 0/2
  • diagramme de classes [sur 8 points]
    Des erreurs dans l'écriture de l'UML (par exemple, l'héritage et l'implémentation d'interfaces, la multiplicité...).
    Il manque la description (-4).
    Bien pour le reste.
    => 2/8
  • 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 : 4,5/20

  • bases (classes, structures, instances, …) [sur 2 points]
    Bien dans l'ensemble.
    Evitez de passer des List par référence dans les méthodes.
    Faites s'appeler les constructeurs d'une même classe.
    Utilisez StringBuilder pour les concaténations de chaînes de caractères.
    => 1/2
  • abstraction (héritage, interfaces, polymorphisme) [sur 3 points]
    ok mais pas très utile pour le moment avec Administrateur.
    => 0,5/3
  • collections simples (tableaux, listes…) [sur 2 points]
    Il manque les protocoles d'égalité des classes utilisées dans les collections.
    => 1/2
  • collections avancées (dictionnaires) [sur 2 points]
  • encapsulation [sur 5 points]
    bien pour l'utilisation des propriétés mais tous les setters sont publiques.
    Plutôt que de faire les tests dans les constructeurs, intégrez-les dans les setters de vos propriétés.
    Les collections sont mal encapsulées.
    => 1/5
  • tests (fonctionnels et/ou unitaires) [sur 4 points]
    Un début de test de fonctionnel à avancer.
    => 1/4
  • LINQ [sur 1 point]
    A utiliser (par exemple pour calculer le prix du voyage).
  • évènements (cf. module IHM) [sur 1 point]

IHM : Interface Homme-Machine (XAML, WPF)

Documents : 5/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/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é
    => 0/4
  • diagramme de cas d’utilisation [sur 5 points]
    pas trouvé
    => 0/5
  • considérations ergonomiques [sur 2 points]
  • prise en compte de l’accessibilité [sur 1 point]

Programmation : 3/20

  • XAML :
    • répartition dans l’espace (layout des vues et usercontrols) [sur 2 points]
      ok
      => 2/2
    • utilisation des controls (vues et usercontrols) [sur 1 point]
      ok
      => 1/1
    • ressources, styles [sur 2 points]
      Vous gagneriez à les utiliser pour vos TextBlock et vos Button (au moins...).
      => 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 : 0,5/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]
    Un début avec l'apparition du Stub.
    => 0,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 : 6,5/20

  • persistance (XML, JSON, BDD, WebService…) [sur 3 points]
  • autre ajout personnel [sur 3 points]
  • qualité
    • documentation du code [sur 2 points]
      par endroits mais peu. Utilisez la notation standard avec ///
      => 0,5/2
    • utilisation du repository subversion ou git [sur 2 points]
      des fichiers inutiles.
      => 1/2
  • fonctionnement de l’application
    • compilation [sur 3 points]
      ok
      => 3/3
    • exécution [sur 5 points]
      ok, mais il n'y a pas grand chose à exécuter pour l'instant.
      => 2/5
    • déploiement [sur 2 points]

(1-4/4)

Also available in: Atom