Les projets finaux sont évalués majoritairement selon les trois axes suivants:
- La description de l'architecture finale;
- Le recul sur l'évolution de votre implémentation et votre capacité à la discuter;
- la description de l'impact de l'ajout de la couche de persistance dans votre projet, ainsi que la prise en compte de toute la grille tarifaire.
Cette note compte a égalité avec celle de la démonstration faite en séance (25% en tout, donc 12,5% chacune).
Les notes sont dans HyperPlanning. La moyenne des projets est de 11,80, avec cependant une forte disparité entre les groupes (13 dans les groupes 1 et 2, 7 dans le groupe 3).
sur la forme: Attention a l'orthographe / la grammaire / la mise en page. Je suis loin d'être un modèle, mais si je vois vos fautes, c'est qu'elles sont vraiment énormes. Ne vous sentez pas obligés de mettre tous les composants sur le même diagramme, vous avez le droit de décomposer, ou de proposer plusieurs points de vues sur le même problème.
sur l'architecture: Vous êtes trop factuel et superficiels dans vos descriptions. On se fiche du comment, il suffit d'aller lire votre code pour le voir. Expliquez votre valeur ajoutée, le pourquoi vous avez fait les choses ainsi.
sur la persistance : vous n'êtes pas clair sur le coût de l'introduction de la persistence dans vos architectures. si vous avez été obligés de tout changer, est-ce de la faute du framework, ou de votre modèle initial ? Si au contraire cela n'a pas posé de problème, quelles propriétés possédaient votre architecture pour qu'il en soit ainsi. Ne vous contentez pas d'écrire en langue naturelle votre code, exprimez votre intention et donnez de l'analyse / du recul à votre travail. Passez de la 2D à la 3D, mettez les différents aspects de votre travail en perspectives les uns par rapport aux autres,
- Très bonne description de l'architecture;
- Recul discutable et trop factuel sur les ≠ avec le plan initial. Votre justification est "on savait pas". On s'en fiche un peu ... par contre, les avantages qu'apportent vos nouveaux choix seraient intéressant a expliciter.
- Votre analyse de l'impact de la persistance est trop factuel là encore. Qu;auriez vous pu (ou du?) faire pour que le changement de technologie au niveau donnée impacte au minimum votre architecture ?
- Dommage de devoir ajouter une nouvelle classe pour ajouter un nouveau forfait ...
- le rapport est succint et mériterait plus de profondeur. Il semble presque baclé.
- travail sur les rôles interessant
- "Pour nous aider dans cette tache, les tests unitaires nous nous sommes appuyés sur des test" ... ???
- Le travail de synthèse et de description n'est pas a la hauteur du travail fourni dans le projet.
- Architecture au bon niveau.
- Bonne prise de recul sur les décision architecturale et sur l'évolution entre ce qui était prévu et ce qui a été livré
- Bonne vision pour la suite, dommage que les forfaits soit aussi limités actuellement.
- Bon boulot :).
- Rapport brouillon, pas clair a la lecture seule du rapport de ce qui est présent dans le projet et de ce qui le sera plus tard.
- le point bloquant était la vente de forfait sans compte utilsiateur. En rajoutant un user dans la base à chaque fois que vous vendez un forfait de manière anonyme, vous vous endettez terriblement ! C'est un ugly hack, qui n'est pas perenne sur le long terme.
- que veut dire "assurer les avantages du polymorphisme" ?
- votre vision du support de la grille tarifaire n'est pas consciente de ses limites. Vous avez une implémentation "en dur", du code métier centralisé, ... et vous défendez qu'elle peut tout faire. Certes, ça fonctionne a court terme. Mais l'archi derrière n'est pas au niveau.
- le diagramme de composant est inutile as is, il n'est pas lisible
- Beaucoup de banalité dans la justification du diagramme de composants
- La prise en compte des points bloquant est superficielle. Vous ne discutez pas réelement l'impact de l'ajout d'au autre partenaire externe a votre système
- Bonne vision des modifs a faire (et a ne pas faire) pour supporter la grille tarifaire complète
- ORTH / Grammaire ! "les composants son bien resté dans le diagramme final", "on c'est rendu compte", "il n'est pas référencer", impacte de la couche de persistance... c'est pas raisonnable.
- Beaucoup de composants dans le système final. La justification que vous donnez est cohérente avec une prolifération d'interface (et a du sens avec votre justif), mais certains composants pourraient être moins fins et regrouper l'implémentation de ≠ interfaces, par corps de métier.
- Ok pour la justification de la DAL.
- Très bon travail au niveau du code et de l'archi. Dommage que le rapport donne l'impression d'une synthèse baclée.
- Bonne description de l'architecture, et bonne solution mise en place dans le code
- Attention, le diagramme de composants est illisible une fois imprimé
- Votre discours sur l'impact de la persistance dans votre projet est très bien construit, et l'analyse des ≠ solutions est bonne.
- Vous êtes moins clair sur les évolutions a apporter au système pour être compatible avec la grille tarifaire. A la lecture du code, je suis moins confiant que vous.
- Le rapport est très "vide", vous restez superficiel.
- vous n'allez pas assez loin dans la justification de la nouvelle architecture
- passer le singleton stateless ne garanti pas la résolution de votre problème, bien au contraire. Ça pourrait toujours marcher "par chance".
- Vous ne semblez pas connaitre les limites de votre code actuel, c'est très dommage.
- wahou
- wahou
- La discussion sur les objets métiers est intéressante, mais je ne suis pas sur d'en comprendre la conclusion.
- L'architecture mise en place est interessante, et bien décrite dans le rapport.
- Vous ne discutez pas des différence entre votre architecture initiale (dans le 1er rapport) et la finale (dans l'implèm). Vous avez la figure d'une "diagramme de composant initial tel qu'il est dans notre implémentation", pas bien sur de comprendre ce que cela veut dire. Dommage de perdre des points en ne répondant pas aux questions qui sont évaluées (cf https://piazza.com/class/ik0w6n52sfgr7?cid=51)
- Partie JSF très avancée, et justifiée dans le rapport. Ok pour la rustine d'init de la base, mais vous auriez plus leur plus loin sur la différence prod/test en exploitant mieux les tests
- Pas très clair sur les limites de votre implèm actuel dans l'évolution a apporter pour supporter toute la grille tarifaire
- Le diagramme de composant décrit peu d'interfaces, c'est bizarre vis a vis du code de l'implèm.
- Dans votre rapport, vous semblez défendre la définition de composants isolés plus que faiblement couplé. Il y a une vraie différence entre les deux, il faut faire attention.
- votre vision de l'architecture semble plus claire que lors de la démo, et alignée avec votre code.
- ok pour la description de la persistance
- votre vision de l'évolution a apporter dans votre implèm pour supporter la grille tarifaire complète semble un peu idéalisée au vu du code.
- 2 rapports dans le rapport, en lien avec les 2 projets dans le projet qui n'ont pas été intégré. Ce n'est pas raisonnable.
- utiliser la définition d'
equalscomme exemple de code "dur" est un peu abusé dans votre contexte. - Le point bloquant que nous vous avions demandé de traiter était l'intégration des 2 sous projets. A part coté météo où vous en discutez un peu dans le rapport, cela semble être passé complètement à la trappe.
- C'est dommage parce qu'il y a un certain travail dans le code, mais ce n'est globalement pas ce qui est demandé, et pas au niveau attendu.
- Ce n'est pas une notion vue en ISA, mais je ne peux pas laisser passer l'horreur: le rôle d'un PO n'est pas de diriger l'équipe ni de maitriser la technique, bien au contraire. Le PO est le garant de la vision du client dans l'équipe, il écrit les specs (stories) et négocie avec l'équipe. C'est l'équipe qui s'auto-organise sur la base de sa connaissance technique.
- Personne ne vous a forcé a introduire des intercepteurs dans votre projet.
- Architecture OK, bonne visibilité sur comment faire évoluer le projet pour supporter la grille tarifaire
- Vous auriez pu rester moins superficiel sur l'introduction de la persistence, vous n'allez pas au fond des choses dans l'analyse.
- Modélisation Objet d'une station de ski ? vous vouliez dire Composants non ?
- Votre diagramme de composant n'en est pas un
- C'est trop light, sur le rapport comme sur l'implèm.
- bonne idée d'avoir découpé le diagramme en 2 parties, une pour le métier et une pour l'exposition JSF.
- Il n'y a ni votre numéro d'équipe ni vos noms sur le rapport...
- Il aurait été possible de regrouper certains composants en un seul (une même classe implémentant plusieurs interfaces)
- très factuel dans la description des interfaces, peu de recul sur le reste. Allez plus a l'essentiel, ne vous noyez pas dans des détails techniques peu intéressants.
- par exemple, une des ≠ majeures est l'utilisation de finders. Quel impact cela a eu sur votre système ? quelles bonnes propriétés cela apporte a l'assemblage final ?
- Votre solution au point bloquant est très factuelle là encore. Qu'apporte le CheckEntity d'un point de vue global ? comment garantir son unicité ?
- Beaucoup de perspectives, que vous envisagez sans pour autant décrire comment elles modifieraient votre système.
- Il faut aller plus en profondeur dans la justification de vos choix et ne pas vous arrêter au comment ... expliquez pourquoi.
- architecture OK. Vous auriez pu vous passer de recopier les interfaces (vu qu'on va aussi lire le code), et plutôt donner une vision globale de l'architecture
- Cela vous aurait permis de passer plus de temps sur la partie II, qui est expédiée trop rapidement.
- Il y a un très bon travail au niveau du code, mais le rapport n'est vraiment pas à la hauteur du travail réalisé. c'est trop faible, superficiel et succinct.
- Vous défendez la suppression des composants d'accès aux données initialement prévus par l'introduction d'une couche de persistance. Or, cela a pour effet de coupler le métier a la couche donnée, et du coup pose des problèmes au niveau de l'arche d'un point de vue maintenance / isolation / couplage. C'est peu cohérent avec votre implèm et votre rapport
- Je ne comprend absolument pas la partie sur la persistance. en quoi la nature "transactionnelle" des tests est elle un problème vis a vis des objets persistants a tester ? Pour accéder à la base il faut une transaction, ou la transaction est initiée par le conteneur (composant métier), ou elle l'est dans le test.
- Pas très partisan de la solution classe par classe pour supporter toute la grille tarifaire.
- Intéressant d'avoir discuté des capacité des lecteurs sur les portiques pour argumenter votre choix de stockage, pour une fois c'est une bonne raison de descendre à ce niveau et d'en exprimer une conclusion architecturale.
- Quel intérêt d'avoir des interfaces de services si elles exposent as is celles des composants métiers. Juste pour l'interopérabilité ? C'est limité quand même ...
- "Ce problème est du à un manque de connaissance sur les technologies nouvelles que nous ne maitrisons pas étant données qu'elles sont nouvelles" ... ok, soit. du coup on fait comment ? Quelles leçons tirés vous de ce qui s'est passé avec la pile J2E ?
- Vous avez du tout changer dans votre code pour intégrer de la persistance. Quel leçons tiré vous de votre code initial et de sa modélisation ?
- C'est pas au niveau.