RS&DE – Qu’est-ce que du travail expérimental en TI ? C’est ici que se termine la saga sur la rédaction d’un bon projet RS&DE, alors que je présente sa conclusion se rapportant aux travaux expérimentaux. Encore une fois, on sait tous que l’objectif premier de tout bon informaticien consiste à définir, développer, intégrer et améliorer. Par contre, le défi lorsque l’on rédige une démarche expérimentale demeure dans la vérification que ce programmeur ait abordé cette contrainte selon une approche systématique et dans le but d’atteindre un avancement ou un progrès technologique. Partant de ce fait, j’ai composé trois exemples afin de vous illustrer des situations pouvant survenir. Exemple 1 : On désire archiver le nombre d’œufs qui sont pondus par les poules d’un élevage. Or, lors de la collecte, il ne faut pas que deux personnes ne puissent accéder à la base de données au même moment.Hypothèse : Le développement d’une structure de données permettrait de stocker en BD tout en évitant que deux entités n’écrasent leurs données.Travaux : Une structure de données a été développée ainsi qu’un prototype d’interface. Résultat : Un test avec les valeurs fournies par 10 poules a démontré que ce qui a été conçu fonctionnait selon l’objectif visé.(Même si cette démarche comporte les étapes d’une investigation systématique, celle-ci ne demeure pas moins inadmissible, car la contrainte qui y est abordée en est une d’affaires). Exemple 2 : On tente de lire un code-barres à l’aide d’un iPhone 4, mais le manque de précision de la DLL nuit à la reconnaissance. Hypothèse : N’existerait-il pas une DLL qui permettrait de résoudre cette problématique? Travaux : Différentes librairies sont testées. Résultat : Parmi les librairies testées, l’une d’entre elles répond à nos exigences.(Cet exemple compose aussi une démarche systématique, mais aucun travail de développement de technologie n’a été effectué. La contrainte a tout simplement été contournée en utilisant une technologie connue ). Exemple 3 : Pour que l’hypothèse précédente ait été valable, il aurait fallu qu’elle prenne cette tournure : Hypothèse : L’altération de la DLL open source Barcode.dll permettrait d’améliorer sa précision. Travaux : L’algorithme de reconnaissance de la librairie semblait déficient. Il a alors été remplacé par un mécanisme de détection de code-barres développé à partir d’un algorithme propriétaire. Résultat : Le mécanisme créé a amélioré la qualité de l’image acquise, ce qui a accru la flexibilité de la solution. Cette dernière s’adapte maintenant automatiquement à n’importe quel modèle d’iPhone en s’ajustant à la résolution spécifique de chacun.(Cette fois-ci, la contrainte n’a pas uniquement été abordée, mais elle a aussi été résolue par un travail de développement de la technologie).Ainsi, même si un programmeur opère selon une démarche structurée, cela ne signifie pas qu’il effectue des travaux de RS&DE, car normalement, tout bon programmeur doit suivre une investigation systématique lorsqu’il travaille. Par conséquent, pour qu’elle soit considérée admissible, la démarche systématique doit aborder à la fois la contrainte et l’objectif technologique. La RS&DE peut se révéler complexe lorsqu’on ne sait pas par quel bout la prendre, mais une fois que vous l’aurez démystifiée, elle n’aura plus de secret pour vous. En souhaitant que cette série vous a plu et vous a permis d’en apprendre plus sur une bonne méthodologie d’identification des travaux RS&DE.
d'Astous Groupe Conseil inc.