Prodageo : première synthèse

Voilà que notre expérimentation de mini-projet Prodagéo touche déjà à sa fin et pour l’instant, je n’ai pas beaucoup écrit à ce sujet. Je vais donc essayer de me rattraper aujourd’hui en faisant un compte rendu des observations et premières conclusions que nous pouvons faire à la fin de ces quinze jours.

1 – le transfert du cahier des charges de Safi vers Dijon
Le transfert d’information en lui-même s’est plutôt bien passé, l’erreur était plus au niveau des étudiants marocains qui n’ont pas bien assimilé le découpage du projet. En effet, il était précisé dans les cahiers des charges que les techniciens faisaient leur mesure et transmettaient le résultat sur la ligne série, tandis que les ingénieurs remplissaient leur base de données à partir d’un fichier texte (cela n’est pas très judicieux mais il faut se débrouiller pour trouver une solution d’interface entre des techniciens qui ne connaissent pas encore les fichiers et des ingénieurs qui n’ont pas entendu parler de la ligne série : nous fournissions un petit exécutable qui lit la ligne série et remplit le ficher texte). Nulle part il n’y a de précision sur ce qui se passe entre les deux et c’est une imprécision du cahier des charges que j’assume. Cependant, il est du rôle du chef de projet de comprendre le fonctionnement global du système et de questionner le client pour éclaircir tous les points obscurs. Je doute fort qu’un chef de projet rencontre une fois dans sa carrière un cahier des charges exhaustif et complet … Les étudiants marocains ont fait un raccourci tranquillisant en disant, tout ce qu’on a pas à faire, c’est aux techniciens de le faire. Il en est ressorti que le résultat du transfert de cahier des charges est un échec.
Quelles conclusions en tirer ? D’abord chercher à avoir des documents pour les étudiants plus précis et complet (c’est toujours possible), ensuite, inciter les chefs de projet à analyser l’ensemble du projet avec toutes les contraintes et précisant toutes les interfaces (composée de quelques schémas UML par exemple).
Force est de constater que l’éloignement et l’impossibilité de se rencontrer en face à face ne simplifie pas les échanges mais cela fait partie de l’exercice. C’est une situation qui peut se rencontrer régulièrement dans la vie professionnelle. Il est, me semble-t-il, important de sensibiliser et former les étudiants à la reformulation pour qu’ils puissent s’assurer d’avoir bien compris les consignes ou informations.
Pour palier le problème de transmission de cahier des charges et ne pas embrigader les étudiants dans une mauvaise piste, nous, enseignants, sommes intervenu pour recadrer le projet en fournissant le ‘vrai’ cahier des charges. nous aurions dû aussi informer les étudiants marocains de ce recadrage afin qu’ils puissent repartir sur les bonnes bases.

2 – la gestion du temps
On retrouve en condensé tous les travers des projets que vivent les étudiants en 2ème année :
– Difficulté à appréhender le problème et à rentrer dans le projet
– A la fin de la période d’analyse du problème et de découverte des outils et logiciels, les étudiants sont déjà en retard par rapport au planning.
– Le travail de réalisation (développement, mise en oeuvre du matériel) est intense et correspond à peu près à ce qui est planifié. Mais cela ne suffit pas à rattraper le temps perdu au début.
C’est une très bonne sensibilisation à la gestion du temps dans un projet et cela servira de base sur laquelle on pourra s’appuyer pour dynamiser les étudiants lors des prochains projets en insistant sur les risques à ne pas respecter les délais intermédiaires.

3 – le travail en équipe
Sur un petit projet de quinze jours, il est difficile de découper le travail à réaliser pour responsabiliser chaque étudiant sur une tâche spécifique. Les groupes ont dans l’ensemble fonctionné de manière fusionnelle : « on fait tout tous ensemble ». Cela ne correspond pas au fonctionnement normal d’un projet et c’est une limite de notre exercice. Il est apparu un étudiant qui ne s’est pas intégré dans son groupe et qui s’est donc mis en marge par rapport à l’équipe. C’était un des deux groupes de 4 étudiants : c’est trop ! Il apparaît que pour cet exercice, un groupe ne doit pas contenir plus de 3 étudiants.

4 – l’utilisation des outils proposés
pour cette première expérience, on s’était centré sur 3 outils :
– Moodle pour régler les délais et synchroniser les tâches
– Subversion pour gérer des versions d’un document
– TestLink pour rédiger des plans et campagnes de tests
L’utilisation de Moodle n’a pas posé de problèmes à Dijon puisque les étudiants sont habitués à rendre leur travaux sur un serveur FTP, Les marocains ont eu plus de réticences à l’utiliser.
TestLink est un logiciel sûrement puissant mais qui n’est pas aisé de prise en main et nécessite un apprentissage. Aucun enseignant disponible à ce moment ne maîtrisait l’outil, il a été abandonné lors du travail préparatoire d’analyse des marocains. Leur plan de tests s’est réduit à un tableau.
Enfin, je ne sais pas comment Subversion a été utilisé à Safi mais à Dijon, il n’a pas servi ou presque. Les étudiants ne sont pas sensibles au problème de versions et de restauration …
En conclusion, il faut que les étudiants soient formés aux outils de gestion de projet utilisés avant un mini-projet Prodagéo.

5 – les tests
Nos techniciens ne savent pas tester !!! Ils nous font des beaux plans de tests, mais au moment du test, si on prend le temps de le faire, on modifie les paramètres, on adapte, on biaise les tests …
Un exemple significatif est le test d’émission d’une trame toutes les heures. Les étudiants nous disent : « à quoi ça sert de faire le test pendant la nuit puisqu’on a vu que ça fonctionne quand on demande une émission toutes les 10 minutes ? « . On a bataillé pour que le test se fasse quand même en respectant le protocole défini. Le lendemain matin, oh ! surprise ! au bout de 2 trames, plus rien : les PCs s’étaient mis en veille !!!

6 – la position des enseignants
Nous avions prévu que nous serions support technique. Il s’est avéré dès le résultat de la transmission du cahier des charges que nous devions aussi superviser l’avancement du projet et nous donner la liberté de recadrer les étudiants après chaque jalon d’avancement du projet. Il faut alors envisager le projet comme une course à la boussole par étape. On joue le rôle de la voiture balais pour tous les candidats qui se sont trompés sur la position de l’arrivée d’une étape : on les amène sur la ligne de départ de l’étape suivante.

7 – correction à prévoir dans le planning
Afin de mieux responsabiliser les ingénieurs dans leur rôle de chef de projet, il faudra la prochaine fois leur demander de réagir à l’analyse faite par les techniciens pour préparer leur travail. Les techniciens devront en avoir le retour avant le début du codage afin de pouvoir le prendre en compte.

8 – intégration des différents éléments du projet

Deux groupes ayant finalisé leur travail 4 heures avant la fin du temps imparti, nous leur avons proposé de travailler sur l’intégration générale de tous les composants (acquisition, interface, portail). Ils ont ainsi pu sentir la difficulté de reprendre le travail d’un autre et l’utilité de tous les documents demandés (manuel d’installation, d’utilisation, analyse, commentaires dans le code, …). Espérons que cela leur sera profitable et qu’ils s’en souviendront lors de la rédaction de leurs prochains documents. L’intégration n’a pour l’instant pas abouti.

9 – intégration du projet dans la progression pédagogique à Dijon
Nous avons pu pendant cette quinzaine faire une synthèse de tout le premier semestre : analyse, intégration de matériel, acquisition, … Cela nous a permi aussi de sensibiliser à la vie d’un projet, ses étapes, ses documents, son rythme. Deux points spécifiquement disciplinaires sont à soulever :
– cela a été l’occasion d’avoir une vraie mise en situation pour valider des tâches de l’habilitation électrique (et ça, je trouve que c’est un petit exploit)
– nous avons pu faire travailler nos étudiants avec du matériel de mesure : GBF et oscilloscope afin de valider le comptage d’événement et de visualiser les trames échangées entre le SHT71 et le PC (ou DK41)

La quinzaine a donc été bien riche, je ne pense pas qu’on ait fait le tour complet de son analyse mais c’est déjà bien riche. Je ne peux pas vous quitter sans préciser que tous les groupes sont arrivés à acquérir les informations demandées. Le calibrage du travail demandé était donc correct, ce n’était pas forcément gagné d’avance.

C’était passionnant de monter tout cela et de le partager pendant deux semaines avec nos élèves. C’est à faire et à refaire.
Nous sommes ouvert pour fournir toutes les informations nécessaires à qui voudrait tenter l’aventure …

Publicités

Prodagéo Dijon – Safi, c’est parti !!!

Ca y’est, le projet est lancé ! Le planning de la quinzaine va être bien chargé, vous avez ici le scénario prévu avec les documents que doivent fournir les différents groupes…
Vous pouvez aussi consulter les configurations matérielles utilisées par les différents groupes ainsi que le cahier des charges que nous avions fourni aux étudiants marocains.
Où en est-on ce soir ?
Les 6 groupes ‘chefs de projets’ ont transmis leur Cahier des charges aux techniciens de Dijon. Globalement ça s’est bien passé techniquement, et socialement. Pour ce qui est du contenu transmis, j’ai demandé à mes étudiants de Dijon de rédiger un court rapport de ce qu’ils ont compris de leur cahier des charges. Voici le bilan :
1 équipe n’a rien rendu (aïe, aïe aïe …)
les 5 autres équipes ont des imprécisions non négligeables sur le fonctionnement général du système et les limites de leur travail.
Aucune équipe n’a fait état d’un cahier de recette ni de tests, peut-être n’ont-ils pas jugé nécessaire d’en parler, ce sera à éclaircir demain.

Il faut donc recadrer cela afin de retourner dans le cadre du projet. Nous pensons demain commencer en donnant à nos étudiants les documents que nous avons fournis aux étudiants marocains afin qu’ils comparent avec ce qu’ils ont compris. Cela devrait leur permettre de retrouver le bon chemin.

L’impression générale de la journée est très bonne, tout le monde s’est pris au jeu, aussi bien les élèves que les profs …. C’est bon de se faire plaisir au boulot !

Prodageo Dijon-Safi : ça va se faire

Après bien des incertitudes, un travail collaboratif va bien avoir lieu entre des étudiants ingénieurs de Safi (Maroc) et des étudiants techniciens de Dijon (France). L’objectif est de monter un portail web de supervision d’une mini-serre automatisée pour des élèves de primaire. Les ingénieurs vont être chef de projet et s’occuper de la partie Web + base de données, les techniciens vont eux s’occuper de l’acquisition des différentes mesures (humidité, température et ouverture du volet de la serre). Les ingénieurs travaillent actuellement sur la maquette du portail et le dossier de tests de l’acquisition. Le 25 février, ils transmettront par tchat l’ensemble des documents nécessaires au techniciens pour qu’ils puissent travailler dessus pendant deux semaines.
C’est une bonne nouvelle !!!!

Présentation de l’avenir : un projet géodistribué

Début janvier, les élèves techniciens de Dijon et ingénieurs de Safi vont travailler ensemble sur l’acquisition des mesures nécessaires à notre mini-serre. Un bon dessin valant mieux qu’un mauvais discours, je profite de cette occasion pour présenter un outil bien pratique : le concept mapping. L’image ci-dessous est un exemple de réalisation de Concept Map appliqué à notre projet. Cette carte a été réalisée avec l’outil en ligne ctools, mais bien d’autres solutions existent, c’était juste pour moi l’occasion de l’utiliser et le tester …
Concept-Map-Prodag--o-copie-1.jpg

une mini-serre USB

Si vous trouvez que notre projet est trop ambitieux ou trop compliqué, vous pouvez toujours vous rabattre sur une solution  ‘clé en main’. Elle intègre une lampe et est alimentée par l’USB de votre PC …
Elle est pas belle la vie …
En vente chez geeks.com à 19,99$

Travaux partiques sur la mini-serre

Nos élèves de BTS IRIS ont travaillé sur le projet mini-serre en programmant la régulation de température d’une mini-serre simulée. Cette régulation a été réalisée en C++ sous Windows 2000 pro avec comme outil de développement Visual Studio 2005. La mini-serre simulée communique via des sockets. Le programme des élèves se connecte à la mini-serre, puis récupère les températures de 3 capteurs et réalise la régulation en agissant sur un chauffage, un ventilateur et l’ouverture d’une fenêtre.
Ci-joint la photo de la mini-serre simulée.

miniserre.jpg

un peu de météo

Voici un petit outil pour afficher la météo de n’importe quel aéroport du monde. En effet, il se base sur les données METAR fournies par les aéroports et disponibles sur le site adds.aviationweather.gov/ qui regroupe toutes les données au niveau mondial. Un petit script écrit en PHP génère l’image .png finale. Pour l’insérer dans votre blog ou votre site, il suffit d’aller sur cette page mdmj.dubois.club.fr/villes/data/aff_graphique.php?code=LFSD et de choisir le code ICAO de votre ville. Si vous souhaitez voir apparaître le nom de votre ville plutôt que le code, n’hésitez pas à envoyer un message. Un bug subsiste car certaines trames METAR disent « rien n’a changé, c’est comme avant », comme tout n’est pas enregistré, cela génère une erreur ….

Bonne météo

%d blogueurs aiment cette page :