> Réunion 19 janv 2023 > > Présents : EM, ML, DS, CL ## ODJ 1. 20' concernant l'organisation générale de l'UE 2. 40' concernant les sujets ## CR > rédigé a posteriori, recense ce qui a été exprimé + fait des propositions en fonction ### Organisation générale de l'UE > présentation de l'UE à l'aide du diaporama Diapos_présentation_CNUM.pptx > discussions * points importants concernant CNUM présentés * doit former et évaluer l'acquisition de la compétence 'concevoir' * mène à la réalisation d'un produit fini * activités centrées autour des étudiants * rôle important du commanditaire * 4 RDV * RDV1 : exprime la demande * RDV2 : valide le cahier des charges réalisé par les étu, que les étu ont bien compris la demande, ce qu'ils se proposent de réaliser y répond bien (ajuste si besoin) * RDV3 : valide le prototype (ajuste si besoin) * TDV4 : évalue le produit fini, en lien avec le cahier des charges * besoin d'un soutien technique (programmation) * khalid en 2023 * quel temps allouer aux TA? Quel temps allouer à l'assistance technique ? * TA/TD étu * pour assurer le soutien nécessaire * pour laisser les étudiants développer en autonomie * heures enseignant * pour utiliser le volume horaire proposé par la diretu * pour dimensionner correctement cette année avec peu d'étu et les années prochaines pour lesquelles les effectifs seront plus conséquents => dimensionner le temps d'assistance en fonction du nombre de projets => proposition de **durée d'assistance à 3h par projet, pool commun**, à ajuster son utilisation en fonction des groupes, des sujets => permet de rétribuer par projet en fonction de qui réalise l'assistance tech => 15h si 5 projets en 2023 ### Sujets > discussions autour des qualités d'un sujet plutôt que ce qui était prévu au départ, à savoir améliorer en détail les sujets existants * ouvrir la possibilité de proposer un sujet à des personnes qui ne sont pas de SIN * autres enseignants * services * scolarité etc => ouverture possible à présent, certaine en 2024 * il y a de nombreuses idées de sujets, entre ce qui a été proposé avant la réunion et ce qui a été exprimé pendant puis en off après => rajouter une ligne dans le tableau partagé pour indiquer les embryons de sujets, en indiquant qu'il n'est pas prêt à être proposé. Ces sujets pourront évoluer dans un second temps :) * qui évalue la faisabilité, le bon dimensionnement du sujet ? le responsable d'UE n'a pas tout le savoir-faire ? les ens de SIN sont surbookés     => cf propostion + loin concernant la distinction commanditaire/tuteur * évalue-t-on le produit fini ou la progression des étu ?     => définir un objectif visé qui forme à la conception, au dela du visé qui est un plus * être vigilant à ne pas former sur l'utilisation d'une bibliothèque spécifique mais bien à la conception => le projet ne doit pas reposer sur l'utilisation de la bibliothèque spécifique (n'est qu'une partie du développement; ou bien reléguer l'utilisation spécifique à l'au dela du visé) * si le commanditaire est de SIN, il doit être en mesure de réaliser le produit fini (il doit donc connaitre le langage de prog associé au sujet) s'il fallait le faire (mais il ne va pas le faire :), de manière à pouvoir * dimensionner correctement le projet * identifier les obstacles, guider vers des ressources externes si besoin (ouvrage, package, doc, site web etc) * valider la démarche que les étu vont proposer * **on définit un nouveau rôle, le <u>tuteur</u>, qui est un membre de SIN, qui est associé à chaque sujet, qui est différent de celui du <u>commanditaire</u>, même si cela peut être la même personne** * le commanditaire * peut donc ne pas être un ens de SIN * fait une demande réelle * sera présent lors des 4 RDV * pour décrire le produit qu'il souhaiterait (RDV1) * faire un retour sur le cahier des charges si ce qui est envisagé par les étu correspond à ce qui est attendu (RDV2) * si le prototype correspond à ce qui est attendu (RDV3) * si le produit fini correspond à ce qui est attendu (RDV4) * n'est <u>pas</u> rémunéré en heure éqTD (il recevra le produit fini :) * le tuteur * est un ens de SIN * peut être aussi commanditaire, sinon est en relation avec lui * s'assure que le projet est bien dimensionné, échange avec le commanditaire en amont (est en accord avec lui-même s'il est aussi commanditaire :) pour se mettre d'accord sur un produit * maitrise le langage associé au projet (cf plus haut) * n'apporte pas d'assistance technique (sauf s'il joue officiellemet le rôle d'expert technique; cf plus bas) * sera présent lors des 4 RDV, mais avec un rôle différent du commanditaire * RDV1 : s'assure que la demande correspond bien à ce qui était prévu et correspond bien aux critères de qualité des sujets * RDV2 : valide la démarche proposée par les étu * RDV3 : accompagne les étu pour confronter le prototype au cahier des charges * RDV4 : accompagne les étu pour confronter le produit fini au cahier des charges * guide les étu vers les ressources adéquates associées à la réalisation (ouvrage, package, doc, site web etc) * décrit le projet en remplissant le tableau xls partagé * <u>est</u> rémunéré 2heqTD * Rq : la demande de la part du commanditaire doit être réelle * attente forte et réelle sur le produit fini, motivante pour les étu * rq : ce qui exclue de reproposer exactement un même sujet une année sur l'autre, si la réalisation une année est satisfaisante. Il faudra imaginer des extensions pour rendre la demande réelle * **on définit toujours un rôle d'assistant technique maintenant nommé <u>expert technique</u>** (pour que ce soit plus valorisant :) * il est expert du langage associé au projet * il assure 100% de l'assistance technique * il est rémunéré le temps indiqué plus haut (**3h eqTD**/groupe pour 2023) * proposer des sujets pour 2023 * 8 sujets pour 5 groupes, pour offrir une marge de manoeuvre dans le choix des étu, même si les étu n'en prendront que 5 au final * les sujets doivent être détaillés dans le doc en ligne :) * les sujets valident les critères :) * l'aspect **interactif** du produit * positif * à l'avantage de pouvoir rendre le produit testable lors du forum, afin d'éviter aux groupe de simplement montrer de façon transmissive leur produit * la contrainte de l'interactivité est une opportunité pour avoir des idées complémentaires sur un sujet existant * négatif * exclut des sujets potentiellement formatifs ? * biaise les productions vers des appli web, des appli Rshiny, etc ? * à voir... * proposer pour chaque sujet un objectif visé et un **au dela du visé** - le visé est faisable, permet de valider la compétence conception - le au dela du visé claque, est ce qui est réellement attendu par le commanditaire, est interactif, est faisable mais demande un engagement + fort de la part des étu => renseigner ces 2 aspects sur le doc partagé * un sujet peut permettre aux étu * de mobiliser des connaissances techniques (programmation) déjà vues dans les UE SIN, de manière à les remobiliser les acquérir * ou d'acquérir de nouveaux éléments * ex utiliser un package spécifique, langage proche des langages connus (ex ggplot), ... * un sujet peut permettre aux étu * de remobiliser des savoirs thématiques/conceptuels déjà vus dans des UE SIN ou non SIN * d'acquérir de nouveaux éléments * expression des sujets * remplir le [doc en ligne](https://but.univ-toulouse.fr/sw?type=onlyoffice&state=14&d=15581194&doc=81643916_b38bd8d88d76fb006c04b74411db373a) * indiquer pour chaque sujet le commanditaire, le tuteur, l'expert tech * décrire le sujet (visé, au dela du visé etc) * indiquer si les critères de qualité sont ok * si tout est ok, indiquer si le sujet est prêt pour être proposé :) * si tout n'est pas ok, quelle modification du sujet permettrait de valider ? * ces critères sont la pour aider à identifier des éventuels points faibles du sujet qui pourraient poser problème dans la réalisation par ex. Un sujet qui ne valide pas tous les points peut être proposé néanmoins, le tuteur décide :) * la liste actuelle des critères de qualité * La demande du commanditaire est-elle réelle ? * Les obstacles et les ressources externes associées (documents, tuto, etc) sont-ils bien identifiées ? * Le projet est-il a priori correctement dimensionné en terme de temps de travail (ni pas assez, ni trop) ? * Le projet bénéficie-t-il d'un expert technique clairement identifié ? * L'objectif "visé" forme-t-il à la conception (concevoir une solution en adaptant les méthodologies à l'objectif) ? * L'objectif "au-delà du visé" est-il atteignable sous condition d'un engagement plus fort des étudiants ? * Le projet nécessite-t-il dans sa réalisation de passer par une séance de créativité (brainstorming) ? S'éloigne-t-il bien d'une simple exécution * Le projet est-il suffisamment complexe pour devoir se décomposer en sous-tâches et nécessiter une organisation adaptée ? c'est à dire une réalisation en mode projet * Le projet permet-il aux étudiants d'améliorer leur savoir-faire en conception logicielle ? Si oui quoi ? * Le projet permet-il aux étudiants d'approfondir leur connaissances hors conception logicielle ? Si oui quoi ? * Le produit fini est-il interactif ? Dans le sens ou il pourra être mis à l'épreuve par des pairs de façon dynamique ? * L'aspect numérique du produit apporte-t-il une pluvalue significative par rapport à ce qui pourrait exister sans l'aspect numérique ? Dans le but de montrer aux étu l'intérêt de la démarche numérique * pas eu le temps de voir tous ensemble les sujets en détail et les enrichir collectivement * se refaire une réunion exprès : pas le temps * ajouter des commentaires sur le doc partagé : pas le temps => se contenter des sujets porposés par chacun, ce sera dejà très bien