mgl804 projet session vr 007 - publications...
TRANSCRIPT
ÉCOLE DE TECHNOLOGIE SUPÉRIEURE
UNIVERSITÉ DU QUÉBEC
RAPPORT TECHNIQUE PRÉSENTÉ À L’ÉCOLE DE TECHNOLOGIE SUPÉRIEURE
DANS LE CADRE DU PROJET DE FIN DE SESSION DU COURS MGL804
TEST DU MODULE « EMBEDDED DATA LOGGER » DU LOGICIEL NI-VERISTAND DE NATIONAL INSTRUMENTS
PAR VINCENT RUAULT
MONTRÉAL, LE 18 JUIN 2016
VINCENT RUAULT, 2016
TEST DU MODULE « EMBEDDED DATA LOGGER » DU LOGICIEL NI-VERISTAND DE NATIONAL INSTRUMENTS
RUAULT, Vincent
RÉSUMÉ
Ce rapport technique est réalisé dans le cadre du travail de fin de session pour le cours MGL804 (Réalisation et maintenance de logiciels) à l’ETS (École de technologie supérieure). Le sujet de session retenu est le numéro 36 (Abran & April, 2016) : « Utilisez un des outils de tests offerts au mainteneur sur un logiciel de votre organisation. Expliquez l’apport réel de l’outil par rapport à son coût et à l’effort de l’adapter et de le maîtriser ». National Instruments est, entre autres, un éditeur de logiciels pour l’industrie. Le logiciel NI-VeriStand permet de faire tourner des modèles de simulation sur des cibles d’exécution temps-réel. Ce logiciel a de nombreuses fonctionnalités d’enregistrement local sur la cible temps-réel ou déporté. Le module « Embedded Data Logger » est une des possibilités en local. Une tâche récente qui m’a été confiée par le département de Recherche et Développement est de venir résoudre des défauts de ce module et créer une série automatisée de tests pour démontrer l’efficacité des changements et pouvoir effectuer des tests de non-régression. Le but est d’intégrer le module modifié à la prochaine version du logiciel NI-VeriStand qui sortira dans quelques mois. Ce rapport vient expliquer les raisons d’affaires à l’origine de la demande ainsi que les contraintes imposées par le département de Recherches et Développement. Une présentation du produit à tester ainsi que les logiciels LabVIEW et NI-TestStand de National Instruments (utilisés pour créer et exécuter l’outil de test) est traitée dans le rapport. Enfin, la critique sur la mise en place des outils de tests et l’application termine le rapport. Il s’agissait de ma première expérience de maintenance logicielle et une opportunité certaine de découvrir ce que pouvait représenter en termes de coût et bénéfice la mise en place de ce genre d’outils.
Mots-Clés : MGL804, maintenance, logiciel
IV
TABLE DES MATIÈRES
INTRODUCTION .....................................................................................................................9
CHAPITRE 1 PRÉSENTATION DU LOGICIEL NI-VERISTAND .....................................111.1 Introduction ..................................................................................................................111.2 Configuration matérielle typique .................................................................................131.3 Embedded Data Logger (EDL) Custom Device (CD) .................................................14
CHAPITRE 2 PRÉSENTATION DE L’OUTIL DE TEST : NI-TESTSTAND ET LABVIEW .....................................................................................................15
2.1 NI TestStand (TS) ........................................................................................................152.2 LabVIEW (LV) ............................................................................................................162.3 Paramètres des tests .....................................................................................................182.4 Utilisation pour notre projet .........................................................................................19
CHAPITRE 3 APPROCHE DES TESTS - RÉSULTATS ......................................................213.1 Approche ......................................................................................................................213.2 Rapports de test ............................................................................................................223.3 Base de données ...........................................................................................................23
CHAPITRE 4 CRITIQUE SUR L’OUTIL DE TEST .............................................................254.1 Apport réel ...................................................................................................................254.2 Coût ..............................................................................................................................264.3 Effort ............................................................................................................................264.4 Prochaine étape ............................................................................................................27
CONCLUSION ........................................................................................................................29
LISTE DE RÉFÉRENCES BIBLIOGRAPHIQUES ..............................................................31
LISTE DES FIGURES
Page
Figure 1-1 Fenêtre de System-Explorer ...................................................................................12
Figure 1-2 Exemple de Workspace ..........................................................................................13
Figure 1-3 Lien entre le matériel et le logiciel. ........................................................................14
Figure 2-1 Séquence de tests dans « Sequence Editor » ..........................................................16
Figure 2-2 Face-Avant de VI ...................................................................................................17
Figure 2-3 Bloc-diagramme du VI. ..........................................................................................18
Figure 2-4 Exemple de fichier de paramètres de test ...............................................................19
Figure 3-1 Rapport - Résultat de plusieurs "steps" ..................................................................22
LISTE DES ABRÉVIATIONS, SIGLES ET ACRONYMES ADO ActiveX Data Objects
ATML Automatic Test Markup Language
CAR Corrective Action Request
CD Custom Device
EDL Embedded Data Logger
ETS École de Technologie Supérieure
IDE Integrated Development Environment
FPGA Field Programmable Gate Array
HTML HyperText Markup Language
MGL Maîtrise en Génie Logiciel
NI National Instruments
PC Personal Computer
R&D Recherches et Développement
RT Real Time
RTT Real Time Testing
TS TestStand
VI Virtual Instrument
VS VeriStand
XML Extensible Markup Language
INTRODUCTION
Un client local de National Instruments (NI), dans l’industrie aérospatiale, possède 30
licences du logiciel NI-VeriStand (NI-VS). Ce client est confronté à deux défauts logiciels
sur un module du logiciel NI-VS appelé Embedded Data Logger (EDL). Ces deux défauts
sont répertoriés depuis l’année 2012 et font l’objet de CAR (Corrective Action Request)
respectif. Ils n’ont jamais été résolus parce que considérés non prioritaires par le département
Recherche & Développement (R&D) de NI, au cours des nouvelles versions. Du point de vue
technique du client local, il s’agit de deux problèmes importants, très pénalisants. Du point
de vue commercial, cela remet en cause le renouvellement des licences ce qui pose un
problème à l’équipe locale de ventes de NI.
Au cours de l’année 2016, une nouvelle version de NI-VS sera disponible et dans le cycle
de vie, le produit est sur le point d’entrer en phase « Alpha ». Il n’y a pas de possibilité qu’un
ingénieur de R&D puisse travailler là-dessus, la cédule ne le permet pas. En prenant en
considération ces différentes données, la R&D a proposé que je me charge localement
(Montréal) de la résolution des défauts de l’EDL à condition que je fournisse un outil de test
prouvant la non-régression et la résolution de ces deux problèmes. Cet outil de test devrait
être entièrement automatique, ne pas nécessiter d’achats de licences supplémentaires et être
disponible avant la fin du mois de mai 2016. À la suite de cela, le code devait être soumis à la
R&D pour une revue des tests et du code pour intégration à la version beta de NI-VS.
Le premier chapitre du rapport présente le produit NI-VS. Le second chapitre introduit les
outils logiciels utilisés pour créer l’outil de test. Le troisième chapitre expose l’approche et
les résultats des tests. Enfin, le dernier chapitre dresse une critique sur l’outil de test.
CHAPITRE 1
PRÉSENTATION DU LOGICIEL NI-VERISTAND
1.1 Introduction
Le terme « Real Time Testing » (RTT) est généralement utilisé pour regrouper toutes les
applications qui partagent deux caractéristiques : fiabilité et déterminisme. Fiabilité parce que
ce sont des applications qui doivent s’exécuter pendant de longues périodes (souvent
plusieurs mois) et que les éléments sous contrôles (moteurs, pompes, actuateurs divers) sont
souvent des éléments coûteux et fragiles. Déterminisme parce que ces applications exécutent
des modèles de simulations qui, pour être fiables, doivent s’exécuter systématiquement avec
un pas fixe.
NI-VeriStand (National Instruments, 2016) est l’environnement logiciel de National
Instruments « prêt à l’emploi » qui permet de configurer et exécuter des applications de RTT.
Sans avoir à programmer, NI-VS permet aux utilisateurs de configurer une simulation sur un
moteur d’exécution multi-cœurs pour remplir des tâches telles que : génération de signaux de
stimuli, acquisition de données haute-vitesse, exécutions de voies calculées, application de
mise à l’échelle personnalisée, utilisation de bus de communications, enregistrements, etc.
NI-VS peut aussi importer des algorithmes de contrôle de différents environnements de
modélisation/simulation tels que Matlab/Simulink (The MathWorks), NI-LabVIEW, du C
ANSI…
NI-VS vient avec un outil graphique appelé « System-Explorer » (SE) qui permet de
configurer tous les éléments de la simulation. La Figure 1-1 représente une capture d’écran
d’une des fenêtres de configuration de SE.
12
Figure 1-1 Fenêtre de System-Explorer
L’utilisateur a à sa disposition une interface graphique appelée « Workspace » qui lui permet
de configurer l’application, et aussi de visualiser et contrôler l’application pendant la
simulation. La Figure 1-2 illustre la « Workspace » d’un projet d’exemple.
13
Figure 1-2 Exemple de Workspace
1.2 Configuration matérielle typique
Une configuration typique de NI-VS contient au minimum deux machines. Un PC (Personal
Computer) appelé machine « hôte », sous OS (Operating System) Windows qui permet de
faire tourner toutes les interfaces utilisateur (configuration de la simulation, contrôle de la
simulation, visualisation,…). La seconde machine est appelée : cible RT (Real Time). C’est
sur cette cible que la simulation, les entrées/sorties physiques, les bus de communication,
l’enregistrement sur disque… s’exécutent. Cette cible tourne avec un OS temps-réel pour
assurer le déterminisme. Les deux machines (PC et cible RT) sont reliées via Ethernet. Ce
qui est décrit plus haut est la configuration la plus simple, mais les applications peuvent
utiliser des cibles RT multiples dans la même configuration. La Figure 1-3 décrit de manière
succincte (et non exhaustive) la répartition des tâches logicielles sur chacune des deux cibles.
14
Figure 1-3 Lien entre le matériel et le logiciel.
1.3 Embedded Data Logger (EDL) Custom Device (CD)
Ce composant fait partie de ce qui s’exécute sur la cible temps-réel. Cette fonctionnalité
permet d’effectuer de l’enregistrement sur disque. Les fichiers produits sont ensuite
accessibles par réseau Ethernet (FTP/WebDAV). Cette fonctionnalité a deux défauts qui font
l’objet de la tâche qui m’a été confiée pour les corriger et, surtout, de créer un outil de test
automatique qui permet de montrer que les corrections sont efficaces. Les utilisateurs de NI-
VS font appel à cette fonctionnalité pour récolter des données exploitées ensuite en post-
traitement. L’utilisateur a la possibilité de définir des groupes de voies, un groupe de voies
partageant la même vitesse de stockage. Un exemple typique est une simulation qui est
configurée pour s’exécuter à 2 kHz (temps de boucle de 500 us). L’utilisateur peut définir un
premier groupe avec un taux de décimation de 1 (aucune décimation) avec un certain nombre
de voies à l’intérieur. Cela définit que toutes les voies seront stockées à 2 kHz. Un second
groupe de voies à une vitesse de décimation de 3 définit que ses voies seront stockées à 2
kHz/3 soit 666 Hz.
CHAPITRE 2
PRÉSENTATION DE L’OUTIL DE TEST : NI-TESTSTAND ET LABVIEW
NI-TestStand (NI-TS) et LabVIEW (LV) sont les deux outils logiciels imposés par la R&D et
ils doivent être utilisés pour créer les tests automatisés. Les deux paragraphes qui suivent
sont une introduction rapide de chacun d’eux.
2.1 NI TestStand (TS)
De TestStand (National Instruments, 2016) : « TestStand est un logiciel de gestion de test
standard qui permet aux ingénieurs de test et validation de développer et de déployer des
systèmes de test automatique plus rapidement. TestStand inclut un moteur de séquencement
de test prêt à l’emploi qui supporte de nombreux langages de code de test, une génération de
rapports de résultats flexibles et des tests parallèles/multithread. ».
Il est important de noter que lorsque l’on parle de tests, ici, c’est en référence à des outils de
tests pour la production (souvent électronique). Ces tests sont donc rarement liés à du test en
génie logiciel. En revanche, certaines fonctionnalités sont utiles dans les deux cas et c’est
pour cette raison que l’on m’a demandé d’utiliser cet outil. De plus, étant un outil « maison »,
cela ne requiert aucun achat de licence supplémentaire.
Pour mon projet, NI TS est utilisé pour appeler et séquencer les différents « pas de tests » qui
vont être écrits en LabVIEW (Cf. 2.2). NI TS prend en charge des opérations typiquement
requises comme le chargement des paramètres de tests, l’enregistrement des résultats dans
des fichiers, base de données ou encore la génération de rapport. Ce sont ces fonctionnalités
que j’ai mises en œuvre dans mon projet. La Figure 2-1 est une capture de la séquence de test
principal de mon projet ouvert dans l’éditeur de séquences qui vient avec NI TS.
16
Figure 2-1 Séquence de tests dans « Sequence Editor »
Les séquences sont structurées, on peut évidemment modulariser les pas de tests en sous-
séquences, les appeler à plusieurs endroits…
2.2 LabVIEW (LV)
LabVIEW (National Instruments, 2016) est un environnement complet de programmation
graphique disponible depuis des années. Les programmes écrits en LV sont appelés VI pour
« Virtual Instruments » parce que l’apparence ressemblait beaucoup, à l’origine à des faces-
avant d’instruments comme des oscilloscopes, des multimètres,...
17
Lorsque l’utilisateur crée un nouveau VI, il obtient par défaut deux fenêtres respectivement
appelées : face-avant et bloc-diagramme. La fenêtre de face-avant est l’interface utilisateur
du VI. La Figure 2-2 illustre une face-avant de VI très simple.
Figure 2-2 Face-Avant de VI
Une fois la face-avant crée, l’utilisateur ajoute du code à son application en utilisant des
représentations graphiques des fonctions pour contrôler les objets de la face-avant du VI. La
fenêtre de bloc-diagramme contient le code de l’application à exécuter. La Figure 2-3 est une
capture de la fenêtre bloc-diagramme du VI introduit précédemment.
18
Figure 2-3 Bloc-diagramme du VI.
LV vient avec une diversité de boîtes à outils servant différents types d’application comme :
analyse vibratoire, traitement d’image, outils de diagnostiques pour l’automobile,… LV peut
être utilisé sur différentes plates-formes : Windows, Linux, MAC, Temps-Réel, mais aussi
FPGA (Field Programmable Gate Array). LV propose tous les outils d’une IDE (Integrated
Development Environment) classique pour la mise-au-point, la compilation, la
caractérisation de la performance du code. Dans mon cas, ce que j’ai utilisé en particulier est
la capacité d’appeler des fonctions d’Assemblies .NET, la lecture de fichiers, l’analyse de
données…
Les pas de tests appelés par NI-TS sont, dans mon cas, des pas de tests écrits en LV.
2.3 Paramètres des tests
L’outil de test doit être suffisamment flexible pour pouvoir ajouter de nouveaux tests sans
avoir à changer les séquences de tests dans NI TS ou encore le code source des pas de tests
dans LV. Aussi, la spécification des tests à exécuter se fait via un fichier texte formaté
(ASCII). L’approche est vraiment très simple. Ci-dessous, sur la Figure 2-4, on peut voir une
19
capture d’une partie d’un fichier de paramètres pour les tests, on ne voit que les premières
colonnes.
Figure 2-4 Exemple de fichier de paramètres de test
Chaque ligne est un test individuel. Pour chaque test, on vient spécifier le nom de la cible
d’exécution, le type d’OS, son adresse IP, la vitesse de boucle,…toute une série de
paramètres.
2.4 Utilisation pour notre projet
La portée de mon projet se limite à la résolution de deux défauts assez majeurs, mais il est
aussi primordial de s’assurer que l’on ne dégrade aucune performance et que l’on ne voit pas
d’effet de bord immédiat en effectuant un minimum de tests de non-régression. Pour moi,
cela implique de devoir tester le code modifié sur chacune des plateformes d’exécution qui
utilisent le composant EDL. Cela ne représente pas moins de cinq plateformes différentes. De
plus, un des défauts ne se manifeste qu’après deux exécutions d’un scénario bien précis.
L’outil NI TS permet facilement d’exécuter les tests de manière répétée (aussi avec un
système de pré et post conditions sur chacun des pas de tests) ce qui est fort utile dans notre
cas.
CHAPITRE 3
APPROCHE DES TESTS - RÉSULTATS
3.1 Approche
Dans le cadre du projet de session, par rapport à l’approche des tests, nous sommes dans un
contexte restreint au sens où le nombre d’embranchements à tester était très limité. Pour cette
raison, le choix des cas de tests ne posait pas de défi particulier. J’étais ici dans une situation
de débogage. Les critères ou objectifs de test étaient connus avant l’exécution des tests. Par
contre, lors du travail de débogage, cela m’a permis de découvrir un autre défaut qui est lui-
même devenu l’objet d’un ticket et d’un objectif de test supplémentaire. En termes de
catégorisation des défauts, tous étaient liés directement à la programmation.
Pour l’approche des tests, les critères imposés les plus importants étaient la répétabilité, la
possibilité de réutilisation et l’automatisation complète.
La stratégie de conception de tests retenue a été la boîte noire. Je me suis complètement
concentré sur les fonctionnalités. Ce sont des tests dynamiques. Pour la conception des cas de
tests, je me suis basé sur des tests exploratoires menés directement par le client (utilisateur
final). À partir de ses tests, je les ai complétés par d’autres tests exploratoires étant moi-
même un utilisateur fréquent de NI TS. La tâche était facilitée par le fait qu’il y a une API
.NET qui permet d’invoquer la plupart des fonctionnalités de NI TS. Cela était déterminant
pour pouvoir automatiser les tests.
En termes de critères de réussite des tests, tous les tests devaient être réussis pour que la
tâche soit considérée comme terminée. C’était le seul critère imposé. Cela se comprend étant
donné le contexte : le projet a été initié pour résoudre des défauts et la création de l’outil de
tests et des tests en a découlé.
En faisant les tests exploratoires, il a été établi que l’apparition de défauts était aussi
conditionnée par le nombre d’itérations. Aussi, les tests tiennent compte de cette
caractéristique et sont exécutés plusieurs fois.
22
3.2 Rapports de test
NI TS permet de générer automatiquement un rapport de test. Différents formats sont
disponibles initialement : Automatic Test Markup Language (ATML), XML (Extensible
Markup Language), HTML (HyperText Markup Language), ou ASCII. Dans mon cas, j’ai
utilisé un rapport XML qui est généré automatiquement. Pour chaque pas de test dans NI TS,
il est possible de spécifier si l’on souhaite voir figurer des informations sur le test (le status,
la mesure,…) ou aucune information. À titre d’illustration, on peut voir une capture d’écran,
Figure 3-1, d’une section du rapport XML généré par NI TS et ouvert dans un browser WEB.
Figure 3-1 Rapport - Résultat de plusieurs "steps"
La colonne de gauche « Step » donne le nom des pas de tests. On peut y reconnaître une
partie de la Figure 2-1. Le test « WebDAV » files from Target a un Status « Skipped » parce
que pour la cible d’exécution, la technique de transfert de fichiers utilisée est FTP. Ce pas de
test a une « pré-condition » qui porte sur l’OS de la cible d’exécution. Le pas suivant « F
TP Files from Target » s’est exécuté et a un Status « Done ». C’est une simple action, pas de
mesure associée. Le dernier pas de test « Measurements on TDMS File » est le pas de test qui
analyse automatiquement les fichiers de données générées par le composant EDL de NI VS.
On voit qu’il a un Status « Failed ». Comme c’est un pas de type « Numeric Limit Test », les
mesures sont ajoutées au rapport, ainsi que les limités utilisées et la forme de comparaison. Je
ne peux pas rentrer dans les détails, ce qui intéresse, dans un premier temps, c’est le résultat
global de tous les tests. Si ce résultat est « Failed », c’est à ce moment que l’on rentre dans le
23
détail individuel des tests. Pour donner un aperçu, l’exécution de 16 tests sur les 5
plateformes supportées prend plus de 1120 secondes.
3.3 Base de données
Tous les résultats de tests sont enregistrés, par défaut, dans une base de données locale à la
machine sur laquelle tourne NI TS. De manière très semblable à la partie génération de
rapports, NI TS donne la possibilité à l’utilisateur de consigner les résultats de chaque step
dans une base de données. NI TS utilise Microsoft ActiveX Data Objects (ADO) comme
client de base de données. Dans notre cas, c’est plus un ‘extra’ qui peut être utilisé « au cas
où » l’on voudrait revenir à des tests antérieurs, mais comme c’est disponible sans aucun
effort supplémentaire d’intégration. Malgré tout, c’était aussi demandé pour d’éventuelles
comparaisons pendant la phase de revue de code avec la R&D.
CHAPITRE 4
CRITIQUE SUR L’OUTIL DE TEST
4.1 Apport réel
Le fait que cet outil soit complètement automatisé est un apport réel. On doit modérer cela en
considérant que, pour ce composant en particulier, les tests étaient presque inexistants
auparavant. Aussi, la comparaison n’est peut-être pas totalement juste.
Pour les ingénieurs de R&D, cet outil de test basé sur NI TS est nouveau et a demandé un
peu de prise en main, mais leur intervention se limite à l’exécution de l’outil et l’ajout de
tests. La prise en main a été assez rapide (1 heure).
Les outils de test existants couvrent beaucoup de fonctionnalités de NI TS, mais sont assez
peu automatisés au sens où ils demandent souvent une intervention du testeur à un moment
ou à l’autre. Cet outil vient donc compléter l’existant en exigeant assez peu d’efforts pour les
utilisateurs. Même si l’outil est focalisé uniquement sur le composant EDL de NI VS pour le
moment, il sera aisé d’ajouter d’autres tests couvrant d’autres fonctionnalités de NI VS.
D’un point de vue de la qualité du logiciel, c’est certain que cet outil de test vient augmenter
la qualité du composant EDL de NI VS à court terme (version « n ») et on peut dire la qualité
globale de NI VS à moyen terme (version « n+1 »).
Au-delà de ce premier projet, on peut envisager une réutilisation future pour d’autres projets
du fait de la flexibilité.
26
4.2 Coût
Le coût humain du projet est celui d’une semaine (5 jours ouvrés) de mon temps, et une
journée d’un ingénieur de la R&D de l’équipe de NI VS, c'est-à-dire une demi-journée de
travail pour deux ingénieurs de R&D (niveau sénior).
En considérant le temps cumulé, par tâche, nous avons les valeurs respectives pour moi :
• 0,5 jour de développement pour réparer les défauts dans le code,
• 4 jours pour développer l’outil de test et les tests eux-mêmes,
• 0,5 jour pour faire la revue de code et l’intégration du code à la branche principale de
développement.
En termes d’achat, ce projet n’a pas nécessité l’acquisition de nouveaux moyens logiciels. La
première raison est que j’ai utilisé des logiciels « maison » pour la création des outils de
tests. La seconde raison est que je me suis appuyé sur des outils externes déjà utilisés par la
R&D pour le système de tickets et aussi pour la gestion de code source. Il n’y a pas à
proprement parler d’équipe de maintenance logicielle dans la compagnie. Cependant, des
développeurs sont affectés ponctuellement à cette tâche dans le cycle de vies des versions.
Ce projet utilise plusieurs matériels pour pouvoir exécuter les tests (cibles d’exécution temps
réel). Tout ce qui a été employé était déjà disponible dans un « pool » de matériels et aucun
achat spécifique n’a été réalisé. Si cela avait dû être le cas, on parle d’un budget d’achat de
matériels de plus de 30 000 $ CAD (prix public).
4.3 Effort
Une particularité est que l’outil de test pour ce composant n’existait pas alors j’ai pu le
concevoir pour répondre exactement au besoin du projet. Je connaissais le séquenceur de
tests NI-TestStand donc je n’ai pas eu de difficultés à le maîtriser et à l’adapter à mon besoin
pour obtenir l’outil de test pour l’EDL.
27
En prenant du recul, c’est très surprenant le temps consacré aux modifications du code source
par rapport à la partie consacrée à l’outil de tests et à la création des tests eux-mêmes. C’est
certain que si une nouvelle activité de maintenance devait avoir lieu, l’outil de test ne serait
pas à développer, mais il n’en reste pas moins que la partie élaboration des tests est très
chronophage.
Pour être totalement juste, il faudrait aussi prendre en compte l’effort pour compléter les tests
exploratoires du client, l’interface avec les différentes parties prenantes… Au final, on peut
parler de plus de deux semaines si on veut tout englober.
Enfin, je n’ai pas du tout tenu compte de l’aspect « politique interne » et tout le temps passé
pour discuter, convaincre et décider si on faisait quelque chose et quoi précisément. Le fait
de ne pas avoir d’équipe dédiée à la maintenance, mais seulement des développeurs qui de
façon ponctuelle sont affectés à la maintenance crée une sorte de fossé. À partir du moment
où l’équipe de développeurs est en mode « développement » et ne peut plus passer du tout en
mode « maintenance », cela crée des blocages. La cédule ne pouvant pas être modifiée, la
maintenance passe au second plan, avec une priorité basse, ce qui impacte le client. Au final,
ce projet a pu aller de l’avant uniquement parce que j’étais une ressource externe et que ce
projet ne modifierait pas la cédule de la R&D établie des mois à l’avance.
4.4 Prochaine étape
L’acceptation du contenu de ce qui a été fait dans cette activité de maintenance est en cours,
dont 50 % a été déjà complété. Pour l’acceptation, outre l’exécution des tests, il y a aussi une
revue du code modifié. Une fois cela terminé, le code modifié du composant EDL sera
intégré à la branche principale du code source de NI-VS. La version « beta » de NI-VS 2016
comportera alors les modifications que j’ai effectuées au cours de ce projet.
28
À la suite de cette première partie, il est déjà prévu de venir enrichir la liste des tests créés
pour ce projet afin d’augmenter la couverture des tests et certainement la qualité de ce
logiciel.
CONCLUSION
Je dois avouer avoir été très agréablement surpris par plusieurs choses lors de cette première
activité de maintenance réalisée dans le cadre de mon activité professionnelle. Ce même
projet a fait aussi l’objet de mon travail de session pour ce cours. Cette activité de
maintenance a été un grand défi pour moi du fait du niveau avancé de compréhension requis
de l’architecture du logiciel. Il a fallu aussi trouver des solutions créatives aux défauts à
traiter. Cela contraste aussi avec le cadre d’intervention du mainteneur : on n’est pas du tout
dans un cadre libre, mais vraiment dans un cadre existant et il faut s’adapter. La création de
l’outil de test et des tests eux-mêmes était un processus de création qui s’est aussi avéré très
plaisant.
Lors de cette activité de maintenance, j’ai pu aussi m’apercevoir du problème engendré par le
fait qu’il n’y a pas de ressources dédiées à la maintenance en permanence mais uniquement
périodiquement sur ce produit. La qualité du service rendue au client est grandement
impactée.
L’effectif de l’équipe de développement d’environ 30 personnes ne justifierait pas d’avoir
une équipe de maintenance dédiée mais il serait mieux d’avoir des développeurs qui, tout au
long du cycle d’une version aurait du temps dédié à l’activité de maintenance.
LISTE DE RÉFÉRENCES BIBLIOGRAPHIQUES
Abran, A. & April, A., 2016. Améliorer la maintenance du logiciel. s.l.:Loze-Dion.
National Instruments, 2016. LabVIEW. [En ligne]
Available at: http://www.ni.com/labview/
[Accès le September 2015].
National Instruments, 2016. NI-VeriStand. [En ligne]
Available at: http://www.ni.com/veristand
[Accès le 15 September 2015].
National, I., 2016. NI-TestStand. [En ligne]
Available at: http://www.ni.com/teststand/f/
[Accès le 05 May 2016].