Les problèmes rencontrés au cours du stage

Un chercheur n'est pas un dévellopeur

Il a été décrit dans la section 4.1, paragraphe gestion de projet l'état dans lequel nous avons trouvé ce projet et dans les paragraphes suivants, nous avons montré les erreurs que nous avions trouvés dans ce projet.

Il est difficile d'évaluer combien de temps nous avons passé à:

• Nettoyer du code (nb: le mettre à norme, faire en sorte qu'il soit lisible en fait).
• Corriger des erreurs de programmations.
• Modifier des portions de code inadmissibles (pour tout développeur qui se respecte).
• Refaire les Makefiles.
• Refondre les entrées sorties.
• Modulariser les programmes.
• Comprendre des sources non documentées.
• Documenter les sources.
• Créer une véritable hiérarchie de projet.

C'est-à-dire à ne rien faire car tout cela aurait du être fait par nos prédécesseurs. On peut affirmer que la moitié du stage au minimum a été perdu de cette manière. Perdu, car tout ce temps n'a pu être utilisé pour des apports au projet tel qu'un format de données compressé, la reconstruction avec deux séquences d'objets, la fusion des programmes de calibration en un seul ou encore l'exportation des applications sous windows 9x et NT.

Nous ne nous attendions pas, en nous intégrant dans un projet de cette importance (ACOHIR), à ce que la gestion de projet soit inexistante et les programmes dans cet état.

Le bon coté de tout cela, c'est que nous avons pris conscience de l'importance de ceci et pendant ce stage, nous avons toujours documenté et programmé suivant une norme, dont nous avons découvert l'importance car quand on ne voit que du code normé, on ne réalise pas combien la norme est primordiale, on se contente de l'appliquer, souvent à contre-coeur.

De plus, si quelqu'un venait à reprendre les programmes qui composent ce projet, aujourd'hui, il ne lui faudrait pas longtemps pour en comprendre le fonctionnement.

Cette critique ne concerne pas uniquement ce projet, c'est un problème qui se retrouve dans tout le département, et doit être fréquent dans la recherche (sauf la recherche en informatique bien sur). Nous avons croisés des thésards qui devaient s'appuyer sur des programmes parfois buggés, sans documentation.

Le réseau de l'ENST et du département TSI

Le département TSI fait beaucoup de traitement d'image. Paradoxalement, c'est certainement le département où les moyens informatiques sont les plus limités.

• La puissance de calcul se limite au serveur principal, picabia, qui est une Sun Ultra 2, avec 512 Mo de mémoire vive, ce qui trop limité pour notre projet, sans compter que tout le monde travaille dessus.
• Tout le monde travaille dessus car c'est certainement un des derniers endroits ou l'on achète encore des terminaux NCD, choix critiquable dans la mesure ou avec ce matériel, tous les applications, même basiques comme les serveurs X, tourne sur le serveur, qui est présenté ci-dessus, ce qui n'arrange rien. Pour le même prix si ce n'est moins, des PC aurait permis de libérer les ressources du serveur et donc de travailler dans de meilleures conditions.

Nous avons constamment été génés par le manque de ressources du réseau tout le long de notre stage, nous avons du lancer des traitements importants pendant la nuit, pendant les week-end, et nous avons ainsi perdu du temps.

De plus, il n'y a pas d'utilitaires comme top, qui permet de voir quels sont les processus qui tournent, comme par exemple dans le cas d'un processus zombie monopolisant la moitié des ressources du système, car top n'est pas une application ``officielle''. C'est ainsi que des processus zombies peuvent tourner pendant plusieurs jours, réduisant encore plus nos possibilitées. Nous avons pu nous apercevoir de cela car nous avions un script qui permettait de faire à peu près la même chose que top.

Les logiciels installés sur le réseau sont souvent vieux, ce qui peut provoquer des problèmes de compatibilités, et surtout beaucoup de logiciels ne sont pas présent car les administrateurs refusent d'en installer de nouveaux. Rien que pour obtenir un window manager décent et qui se montrera indispensable pour pouvoir faire les calibrations des images 3040x2008, grâce aux écrans virtuels, nous avons du faire des installations en local sur nos comptes, ce qui impliques une perte d'espace mémoire due aux programmes dupliqué. Il en est de même pour certaines bibliothèques, très souvent utilisées, que nous sommes aller chercher dans des comptes personnels.

Un manque de connaissance

Ce projet aborde des domaines ou nous n'avions aucune connaissance, comme l'optique, qui tient une place importante dans ce projet, ou la colorimétrie:

• Lors de la première scéance d'acquisition, il n'y avait personne qui ne savait faire la calibration couleur de la caméra, qui nous aurait permis de ramener des images de bonne qualité.
• Toute la calibration de la caméra porte sur des connaissances en optiques; si nous avions eu la théorie, nous aurions pu comprendre beaucoup plus rapidement ces étapes de calibration, ce qui nous aurait permis peut-être de reprendre les programmes qui n'étaient absolument pas documentés. Au lieu de cela, nous avons été obligé de faire confiance à ces programmes, dont les résultats n'ont jamais été mis en cause, mais qui aurait pu être améliorés, notamment au niveau des techniques de programmation.
• Pour la reconstruction et surtout la double reconstruction, le projet s'est heurté à un problème lié à la calibration, qui n'aura pas été corrigé par manque de temps avant la fin du stage, mais que nous aurions pu mieux analyser, afin d'implémenter une solution, qui viendra peut-être aprés.