Universit de Nantes Dpartement Informatique

UFR Sciences et Techniques Alain VAILLY

propos de notation -------------------Alain VAILLY Dpartement Informatique - UFR de Sciences et Techniques Universit de Nantes

I) Pourquoi une notation!? Proposer une notation est toujours dlicat. Outre le fait quelle doit tre la plus objective possible, une notation, quelle quelle soit, traduit une perception de ce que doit tre le travail rendre Qui dit perception dit le plus souvent subjectivit!! Nous savons bien que ces projets de conception doivent tre corrigs par chaque tuteur, chacun ayant sa propre formation, son propre vcu par rapport la discipline. Pourquoi alors se risquer proposer un barme!? Deux raisons justifient cette tentative!: la premire est quelle permet une certaine quit de traitement entre tous les apprenants, lvaluation se faisant sur les mmes bases, que le correcteur soit en Mtropole, au Maghreb, au VietNam ou ailleurs. La seconde est quelle fournit aux tudiants des indications sur ce qui est attendu, sur les priorits mises sur les diffrents critres par celui qui va mesurer. Ils ont donc un cadre de travail. En ce sens-l, nous plaidons pour que chaque projet, quelque niveau que ce soit, soit accompagn systmatiquement du barme qui lui sera appliqu. La mise sur la table dun barme ne rduit pas, pour autant, le risque de subjectivit nant. Quand nous indiquons, par exemple, attribuer deux points (sur vingt) la clart des explications, nous ne disons pas comment mesurer ce critre. Ce document est donc largement amliorable et nous y travaillons. II) Quoi prendre en compte!? Le travail demand, dans ce module, consiste rdiger un document dans lequel larchitecture du logiciel va tre explique, prsente, commente, justifie Cette architecture va tre exprime en termes dune structure de donnes, dun ensemble de fonctions offertes aux utilisateurs et dune structure de contrle de lusage fait de ces fonctions. Chacune de ces trois parties est aussi importante que les deux autres. Il est donc vident que le dossier fourni contient (au moins) trois chapitres, une par partie. Ltude de cette architecture se fait en respectant un processus, tape aprs tape. Aprs chacune, des rsultats, des diagrammes sont produits. Il est donc naturel de penser que ces diagrammes vont constituer la base du dossier. Leur valuation doit bien entendu tre faite sparment et globalement. Les diagrammes, pris de faon isole, doivent tre corrects. Ils doivent aussi tre cohrents les uns par rapport aux autres. Ce dossier est destin tre lu par deux catgories bien distinctes de personnes, des !politiques! et des techniciens. Pour les premiers et pour les seconds, il faut soigner la forme, en noubliant pas de paginer le document, en rdigeant une introduction, une conclusion Celle-ci est, de notre point de vue, aussi importante que lune quelconque des autres lments. Nous allons construire notre barme autour des points suivants!: Document de travail rdig le 24/07/07 14:55 Page 1 / 6

Universit de Nantes Dpartement Informatique - le dossier (sa forme), - le recul des tudiants (sur leur propre pratique), - la mise en vidence des hypothses, - la largeur de ltude, - la profondeur de cette tude, - la pertinence des diagrammes, pris sparment, - la cohrence des diagrammes entre eux.
Dossier Recul Hypothses Largeur Profondeur Pertinence Cohrence 4 points 1 point 1 point 2 points 2 points 6 points 4 points

UFR Sciences et Techniques Alain VAILLY

III) Quels critres faut-il valuer!? Maintenant que nous connaissons les diffrents critres prendre en compte et le nombre de points affects chacun deux, nous pouvons aborder les lments qui vont, sils sont runis, permettre dattribuer la note maximum. Nous les avons regroups en trois catgories. Une premire correspond tout ce qui a trait au dossier en lui-mme, sa forme. Une deuxime va rassembler les critres se rapportant la pratique (au travail) des tudiants, quil sagisse du recul mis dans leur tude, de la mise en vidence des hypothses de travail, de la largeur ou de la profondeur de lanalyse. La troisime partie pourrait sappeler le !fond!. On y retrouve deux critres, celui portant sur la pertinence et celui portant sur la cohrence. III.1) lments de notation du dossier en lui-mme Voici, en vrac, quelques critres que nous avons lhabitude de prendre en compte pour noter cette partie!: - plan dtaill, complet, bien fait!; - prsence dune introduction et dune conclusion claires, qui soient une vraie introduction (au problme, au contenu du dossier, la dmarche suivie) et une vraie conclusion (au problme, aux solutions envisages, aux enseignements tirs de cette exprience, aux amliorations possibles)!; - pagination complte (numro de page / nombre total de pages du document) sur tout le document, annexes comprises!; - justification des textes!; - absence de fautes dorthographe, de lourdeurs de style!; - respect du droit dauteurs, en cas demprunts de schmas, de textes sur Internet ou dans des livres!; - clart des explications fournies dans le document, y compris et surtout!??? dans les parties techniques. Rappelons que le dossier doit pouvoir tre lu par un non spcialiste. Il doit donc tre rdig dans un franaise intelligible et agrable lire.

Document de travail rdig le 24/07/07 14:55

Page 2 / 6

Universit de Nantes Dpartement Informatique III.2) lments de notation de ltude ralise

UFR Sciences et Techniques Alain VAILLY

Pour apporter une rponse notre demande, les tudiants disposent dun laps de temps limit. Nous avons valu le temps de travail ncessaire pour !finir! chaque projet une vingtaine dheures. Il est vident quen moins dune journe non-stop ou, plus raisonnablement, en trois jours de sept heures, il est humainement impossible de produire un plan exhaustif, prcis, cohrent, qui satisfait les exigences de lutilisateur final. On ne conoit pas un logiciel de gestion dun aroclub, dune bibliothque en aussi peu de temps (ou alors les socits de services informatiques ont des commerciaux hors pair!!). Les tudiants dans ce module sont donc condamns au superficiel ou du moins des choix. Ils ne peuvent pas tout faire.

Pour autant, le peu quils font doit nous permettre dvaluer la justesse de la solution quils proposent et dduire du dossier quils remettent leur degr de matrise dune technique. Nous prenons en compte quatre paramtres!: - prise de recul!: le but dun projet tudiant est de reproduire, dune certaine faon et dans certaines conditions, une situation professionnelle. Nous attendons, je crois, de ceux-ci quils gardent la tte froide et quils ne se laissent pas dborder. Cest la raison pour laquelle nous valuons leur capacit prendre du recul par rapport au travail demand et analyser lintrt de tel ou tel diagramme, critiquer leurs propres pratiques Cette prise de recul sera note 0 (aucun recul), 0.5 (recul moyen, !normal!) ou 1 (prise de recul importante). Aucun recul Recul moyen Recul important 0 point 0.5 point 1 point

- mise en vidence des hypothses!: durant la phase dtude dun problme, il est improbable de compter sur la prsence permanente des utilisateurs. Celui qui conoit le logiciel ne peut pas se permettre de stopper son tude au moindre problme, la moindre hsitation. Il doit, pour tre efficace, mettre des hypothses et dvelopper sa solution en fonction de celles-ci. Il vrifiera donc, rgulirement, la vracit de celles-ci auprs des utilisateurs. Ceci ne pourra se faire que sil a pris la peine de les noter!! La mise en vidence des hypothses sera note 0 (aucune hypothse note), 0.5 (quelques hypothses mentionnes) ou 1 (nombreuses hypothses signales). Aucune hypothse Quelques hypothses Nombreuses hypothses 0 point 0.5 point 1 point

- largeur de ltude!: nous mesurons cette largeur en comptant (simplement) le nombre de types de diagrammes prsents dans le dossier. Cette largeur sera value 0 (un ou deux types Document de travail rdig le 24/07/07 14:55 Page 3 / 6

Universit de Nantes Dpartement Informatique

UFR Sciences et Techniques Alain VAILLY

de diagrammes), 1 (trois ou quatre types diffrents) ou 2 (plus de quatre types de diagrammes). 1 ou 2 types de diagrammes 3 ou 4 types diffrents Plus de 4 types diffrents 0 point 1 point 2 points

NB!: le nombre de diagrammes pris en compte dans chaque tranche peut, bien entendu, tre adapt aux exigences des tuteurs, aux cas traits

- profondeur de ltude!: nous voulons ici apprcier si les tudiants ont approfondi le problme, en traitant ou non des cas particuliers. Cette profondeur sera note 0 (tude superficielle), 1 (tude !normale!, aucun cas particulier) ou 2 (nombreux cas particuliers traits). Etude superficielle Etude !normale!, sans cas particulier Nombreux cas particuliers traits 0 point 1 point 2 points

III.3) lments de notation de la partie concernant la solution dveloppe On trouvera ci-aprs quelques lments prendre en compte pour valuer cette partie. Auparavant, rappelons fermement quun dessin ne se suffit pas lui mme. Commencer cette partie par un diagramme de cas dutilisation ou un diagramme de classes mtier est une absurdit. Le lecteur na mme pas eu le temps de se remmorer le contexte quil reoit en pleine figure un schma, souvent complexe, auquel il ne comprend rien.

Ceci tant rappel, revenons aux critres. Nous prenons en considration la pertinence des diagrammes et la cohrence de ceux-ci les uns par rapport aux autres. a) pertinence des diagrammes!: chaque schma, plus exactement chaque type de diagramme, est valu et est not 0 (il y a de nombreuses erreurs dans des lments de ce type), 0.5 (peu de schmas faux) ou 1 (cette !classe! de diagramme est correctement instancie). Entrent dans lvaluation les lments suivants!: - prsence dexplications progressives et correctes!; - utilisation dun vocabulaire simple. Les termes !occurrences dassociation!, de !collection!, de !cardinalits!, de !classes!, d!!hritage!, d!!agrgation! doivent tre, autant que possible, bannis. - justesse de la solution propose (proprits ncessaires toutes prsentes, pas de proprit superflue, associations significatives, cardinalits adquates, non redondance)!; Document de travail rdig le 24/07/07 14:55 Page 4 / 6

Universit de Nantes Dpartement Informatique

UFR Sciences et Techniques Alain VAILLY

- perception exacte de la vie des donnes pendant un cycle de vie suffisament long (avec plusieurs exercices au sens comptable du terme, plusieurs utilisateurs)!; - prsence de contraintes bloquant lintroduction de donnes anormales!; - prsence de fonctions de mise jour de toutes les classes et les associations (sans mettre en jeu des fonctions ayant une porte plus large)!; - respect du temps dans le droulement des oprations, non obligation faite au logiciel de se mettre en attente dune rponse de lutilisateur!; - prise en compte de toutes les plages horaires (y compris celles de la nuit)!; - prsence doprations rserves ladministrateur de la base de donnes!; - prise en compte, par des oprations spcifiques, de cas particuliers!; - respect du contexte et des demandes de lutilisateur. Les diagrammes suivants sont, au minimum, pris en compte!: Cas dutilisation Scnarios Squences Diagramme de classes Diagrammes de collaboration Diagrammes tats-transitions 1 point 1 point 1 point 1 point 1 point 1 point

b) cohrence des diagrammes!: il ne suffit pas danalyser problme et solution sous diffrentes facettes (donnes, fonctions) et dassocier chacune un ou plusieurs diagrammes. Il faut aussi que lensemble fasse un tout cohrent. Lorsque, par exemple, dans un diagramme de squences, une classe X envoie un message m1 une classe Y, il est naturel de prvoir dans la classe rceptrice une opration permettant de traiter m1. Un diagramme tats-transitions (D.E.T.), autre exemple, est troitement li une classe prcise. Les vnements provoquant des transitions dans les tats de cette classe correspondent naturellement des rceptions de messages. Il y a donc un lien indniable entre vnements et oprations Nous prenons en compte plusieurs !couples! de diagrammes et les notons 0 (aucune cohrence), 0.5 (cohrence normale, quelques dfauts et/ou omissions) ou 1 (cohrence forte). Les !couples! suivants sont considrs!: Squences / Classes Collaborations / Classes D.E.T. / Classes Scnarios / Squences 1 point 1 point 1 point 1 point

Loutil que nous construisons doit vritablement amliorer la qualit du travail de lutilisateur et non pas linverse. IV) Que retenir de ce qui prcde!? La notation que nous proposons dans ce document est utilise par nous depuis plusieurs annes. Elle a donc fait ses preuves. En donnant une place significative au dossier, elle remet les choses en perspective. Les documents produits sont destins des informaticiens (il doit donc y avoir des donnes techniques) et des non-spcialistes (il doit donc y avoir des donnes textuelles).

Document de travail rdig le 24/07/07 14:55

Page 5 / 6

Universit de Nantes Dpartement Informatique

UFR Sciences et Techniques Alain VAILLY

Nous partons dun constat simple!: un excellent dossier technique est inutilisable sil nest pas lisible ou si la moiti du temps le lecteur doit r-inventer le contexte dans lequel le travail a t ralis. Larchitecte logiciel se situe la frontire entre lHomme et la Machine. Il puise les informations dont il a besoin chez lHomme, les met en forme pour quune Machine puisse les assimiler et les restitue, dans un langage clair et auto-suffisant, aux Hommes qui vont utiliser le logiciel (mme sil sagit dinformaticiens, gens a priori au fait des langages de la Machine).

-------------------------------------------------

Document de travail rdig le 24/07/07 14:55

Page 6 / 6