DĂ©finition
Traces pour prouver des savoirs et savoir-faire en informatique
Quels savoirs et savoir-faire ont été acquis ?
Eviter à tout pris le mot "compétence"
Choix pertinent des traces dans le portfolio
Il faut choisir des traces pour prouver la possession d’un savoir ou d’un savoir-faire particulier. Les traces sont à sélectionner dans les tâches effectuées lors du stage.
Deux difficultés :
- Choisir des traces pertinentes ;
- bien les analyser.
Raisons pour lesquelles des traces ne peuvent pas convenir :
- trace mal choisie, car ne prouvant rien, ni seule, ni commentée ;
- trace qui pourrait convenir en étant plus précise — exemple : schéma ;
- trace qui pourrait convenir en étant accompagnée d’une autre trace ;
- Trace qui pourrait convenir en étant (bien) commentée.
Avis sur les figures de schémas
Figure 1
Cette figure est inutile pour démontrer quelconque savoir-faire.
Figure 2
Elle est utile, mais peut être perfectible. Avec les commentaires, cela démontre que l’étudiant a compris l’importance de la documentation.
Figure 3
Elle a deux défauts :
- Problèmes de lisibilité
- Pas de légende
- Flèches sans signification.
Figure 4
Similaire à la précédente, mais le schéma est nettement plus lisible.
Le commentaire est toutefois “light”
Figure 5
Le schéma ne démontre rien, il explique l’architecture web de base, ce qui n’est pas demandé, car censé être acquis.
Figure 6
Cette fois, l’étudiant a ajouté des informations liées au projet, qui le rende utile par rapport à la mission de stage.
Figure 7
Ce n’est pas utile pour un rapport de type “portfolio”. Toutefois, c’est intéressant pour un rapport technique.
Figure 8
Un MCD n’est pas utile dans un portfolio, sauf si le commentaire décrit le raisonnement qui a amené au MCD. À éviter sans bons commentaires ou si le MCD n’est pas bon/médiocre.
"Ne pas tenter le diable" - Stephane Domas
Figure 9
Figures illisibles, fenêtre avec champs de saisies (pas utile). C’est une démonstration utilisateur. Ce type de figures seraient utiles dans un manuel utilisateur.
Figure 10
La légende est nécessaire et on ne sais pas avec qui il a travaillé.
Figure 11
Très bien.
Avis sur les figures de captures d’écrans
Figure 1
Cela pourrait paraitre basique, elle représente le type d’application qui est enseignée en cours. Avec des bons commentaires, c’est utile pour montrer son savoir-faire.
Elle peut être utilisée en tant que support, car elle représente un savoir-faire. Il faut toutefois éviter “la VRAIE interface”, car il faudra montrer la “fausse” interface
Figure 2
Cette figure n’est pas utile sans de bons commentaires. Sinon, on ne peut pas comprendre l’intérêt de cette figure.
Il faudrait aussi montrer l’ancienne interface.
Figure 3
La journalisation des choses faites et à faire est utile et montre un savoir-faire (gestion projet, communication…,)
Cependant, le code SQL est inutile.
Figure 4
“Démontrer” et “jeu” ne vont pas ensemble. Ça peut être une belle illustration, mais pas une démonstration. Cela démontre néanmoins “je sais faire une interface texte dans un terminal pour afficher des caractères en couleur”.
Figure 5
Une fenêtre de login ne prouve aucun savoir-faire. Il est néanmoins possible d’expliquer sur texte qu’il y a un procédé d’authentification et rapidement l’expliquer, mais sans figures.
Figure 6
Il faut ajouter les noms, ou le décrire textuellement.
Avis sur les figures de codes
Figure 1
Degré 0 de programmation, car il n’y a aucune complexité derrière.
Figure 2
Aucune différence par rapport à la figure 1.
Si le script Docker était plus complexe, ça mériterait d’être précisé, mais pas un code basique.
Figure 3
C’est le seul code qui prouve un savoir-faire : Il faut développer l’application en prenant en compte les bugs et failles possibles. La vérification des paramètres d’entrées du code permettent de confirmer qu’on valide les données en entrée (compétence 4).
Figure 4
Illisible
Figure 5
Inutile, car c’est juste un exemple de point de DB. Il y a seulement des champs et des valeurs JSON. Toutefois, si le code JSON était plus complexe, et avec les bons commentaires, cela serait possible.
Figure 6
Pareil, le schéma peut être gardé, mais le code JSON est inutile.
Conclusion
Différents domaines concernés :
- Réalisation d’un développement d’application
- Optimiser des applications
- Administrer des systèmes informatiques communicants complexes
- gestion des données de l’information
- conduite de projet
- collaboration au sein d’une équipe informatique
Il faut valider AU MOINS deux compétences
Analyse
Analyses pertinentes dans le portfolio
Ce sont des commentaires prouvant la possession de savoirs et de savoir-faire qui sont particuliers et fondamentaux en fin de S4.
Il faut illustrer au moins une ou deux compétences parmi les six compétences.
On devra s’appuyer sur le travail effectué lors du stage, il s’agit de choisir parmi le travail effectué, non d’évoquer tout le stage.
Choisir parmi les apprentissages fondamentaux en informatique ET prouvant un niveau satisfaisant en fin de S4.
Raisons pour lesquelles des analyses peuvent ne pas convenir :
- Commentaires d’un savoir ou savoir-faire basique, car trop simple (boucle, “if”, …)
- Commentaires ne se référant pas correctement à la trace qui l’illustre
- Commentaire ne décrivant même pas la trace qui l’accompagne
- Commentaire sans analyse, décrivant juste une trace
- Commentaire n’indiquant ni savoir ni savoir-faire
- Commentaire comportant une analyse peu approfondie et ne prouvant donc pas la possession d’un savoir ou d’un savoir-faire.
- Commentaire dont la formulation est problématique., etc.
Analyse satisfaisante, mais sans traces
Analyse : remarques élémentaires
- ”… appliqué les principes basiques de sécurisation logicielle d’une application…” : Prouve qu’il a un savoir-faire (figure 2)
- Il y a une légende en dessous de l’image. (figure 2) (obligatoire)
- Ne prouve pas de savoir-faire (sécurisation, figure 1)
- Problèmes de formulation : langage trop propre (f2) et trop vulgaire (f1) (figure 2)