MASTER 2 INFORMATIQUE RAPPORT DE STAGE...
39
RAPPORT DE STAGE MASTER 2 INFORMATIQUE – UNIVERSITE DE FRANCHE-COMTE Développement de plug-ins Eclipse en contexte agile 2012 / 2013 BENOIT BERNARDIN Responsable enseignant : Fabien Peureux Responsable entreprise : Christophe Grandpierre Membre du jury : Fabrice Bouquet
Transcript of MASTER 2 INFORMATIQUE RAPPORT DE STAGE...
RAPPORT DE STAGE
MASTER 2 INFORMATIQUE – UNIVERSITE DE FRANCHE-COMTE
Développement de plug-ins Eclipse
en contexte agile
2012 / 2013
BENOIT BERNARDIN
Responsable enseignant : Fabien Peureux
Responsable entreprise : Christophe Grandpierre
Membre du jury : Fabrice Bouquet
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
2
Remerciements
Pour commencer, je tiens à remercier Laurent Py et Stéphane Werba pour m’avoir
accueilli au sein de leur société et de m’avoir fait participer à des réunions stratégiques sur
l’entreprise. Merci à Bruno Legeard et Fabien Peureux pour leur suivi et leurs conseils tout au
long du stage. Je remercie aussi l’ensemble de l’équipe R&D de Smartesting pour leur accueil,
leur soutien et leur bonne humeur de travail. Merci à notre manager Séverine Darlot, pour la
confiance accordée durant ces six mois de stage et pour l’écoute dont elle a fait preuve afin que
je réalise un stage dans les meilleures conditions qu’il soit.
Des remerciements particuliers et sincères à :
Christophe Grandpierre, tuteur durant toute cette période, et où, à ses cotés, j’ai pu acquérir
de nombreuses et précieuses connaissances dans le domaine du développement logiciel.
Merci pour l’aide et les connaissances que tu m’as apprises, pour la confiance que tu m’as
apportée ainsi que pour la disponibilité dont tu as fais preuve.
Arnaud Bouzy et Dooley Nsewolo Lukula, respectivement product-manager et consultant,
qui étaient à mes cotés et avec qui j’ai pu collaborer et échanger de nombreuses idées sur les
fonctionnalités développées. Merci pour vos précieux conseils et pour votre confiance.
Julien Botella et Romain Sibre, consultants travaillant aussi dans notre environnement de
travail et avec qui j’ai échangé : aussi bien avec Julien qui m’a permis de comprendre le
fonctionnement de la solution Smartesting CertifyIt™, que Romain avec qui j’ai binômé. Merci
à vous pour votre bonne humeur qui a fait de ce stage, un réel plaisir d’apprendre au
quotidien.
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
3
Table des matières
Introduction .......................................................................................................................................... 5
I. Contexte et objectifs du stage ................................................................................................... 7
A. La société Smartesting ................................................................................................................. 7
B. La solution Smartesting CertifyIt™ .............................................................................................. 8
C. L’équipe R&D ............................................................................................................................. 10
D. Missions et objectifs du stage ................................................................................................... 12
II. Méthodes agiles et outils de travail ....................................................................................... 13
A. L’agilité ...................................................................................................................................... 13
B. Les pratiques Smartesting ......................................................................................................... 14
III. Développements réalisés...................................................................................................... 22
A. Regroupement d’éditeurs .......................................................................................................... 23
B. Smartesting Viewer ................................................................................................................... 27
Bilans et conclusion ........................................................................................................................... 34
A. Difficultés rencontrées ............................................................................................................... 34
B. Bilan technique .......................................................................................................................... 35
C. Bilan humain .............................................................................................................................. 36
D. Conclusion générale................................................................................................................... 36
Bibliographie ....................................................................................................................................... 37
Sitographie .......................................................................................................................................... 38
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
4
Table des illustrations
Figure 1 : Vision multidimensionnelle de l'activité de test .................................................................... 7
Figure 2 : La solution Smartesting CertifyIt™ ......................................................................................... 9
Figure 3 : Logo UML ............................................................................................................................. 10
Figure 4 : Organisation de l'équipe CertifyIt™ ..................................................................................... 11
Figure 5 : Cycle en « V » ....................................................................................................................... 13
Figure 6 : Outil de gestion de backlog Kanbanpad .............................................................................. 15
Figure 7 : Logos Jenkins - Subversion .................................................................................................. 16
Figure 8 : Processus de développement d'une tâche .......................................................................... 17
Figure 9 : Exemple de collection immutable ....................................................................................... 19
Figure 10 : Exemple d'utilisation des Google Collections .................................................................... 20
Figure 11 : Phases de développement ................................................................................................ 22
Figure 12 : Anciens éditeurs OCL ......................................................................................................... 23
Figure 13 : Aperçu des idées de conception graphique des nouveaux éditeurs ................................. 24
Figure 14 : Nouvel éditeur OCL développé .......................................................................................... 25
Figure 15 : Release 5.3.2 de la solution Smartesting CertifyIt™ .......................................................... 26
Figure 16 : Architecture de l’outil Smartesting Viewer ....................................................................... 28
Figure 17 : Construction du noyau « Viewer » ................................................................................... 30
Figure 18 : Résultat de l'exécution du noyau Eclipse .......................................................................... 30
Figure 19 : Architecture Eclipse - Représentation du workbench ....................................................... 31
Figure 20 : Aperçu du « shell Viewer » ................................................................................................ 33
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
5
Introduction
Dans le cadre du Master 2 Informatique à l’Université de Franche-Comté, un stage doit
être réalisé afin d’appliquer l’ensemble des connaissances acquises tout au long de notre cursus.
Ce stage, d’une période minimale de quatre mois, est l’occasion pour chaque étudiant de
confronter ses aptitudes au monde professionnel et de lui permettre d’assimiler de nouvelles
notions afin d’obtenir une base solide pour son entrée dans le monde du travail.
Pour cette dernière ligne droite, je souhaite réaliser un stage différent des trois derniers
réalisés au cours de ma formation initiale. En effet, jusqu’à présent, mes stages se présentaient
sous la forme d’un objectif précis, à atteindre en plusieurs mois de travail et à concevoir de « A à
Z ». Par conséquent, je passais, plus ou moins rapidement, par toutes les étapes logiques du
développement d’applications : étude du sujet, analyse et conception, développement,
validation jusqu’à la mise en production. Cette année, je désire faire de ce stage une réelle
expérience professionnelle à la fois représentative du parcours effectué, en mettant en pratique
les connaissances étudiées à l’Université, et en même temps novatrice.
Parmi les différentes phases de développement citées précédemment, la validation
logicielle notamment par le développement de tests, ne m’était pas familière. Effectivement, ce
vaste domaine a été abordé, pour la première fois, au cours du Master et sa seule mise en
œuvre a été faite durant un projet universitaire. Développer une application est plutôt aisé mais
construire une application testée dans laquelle nous avons confiance est une chose beaucoup
plus difficile. Cela est l’une des raisons de mon choix pour ce stage que j’ai effectué au sein de la
société Smartesting, éditrice de solutions informatiques de tests.
A cela s’ajoutent aussi de nombreux autres critères. On peut notamment citer le
développement JAVA sur lequel j’ai envie d’évoluer et de poursuivre mon implication. Ainsi que
le développement en contexte agile qui est l’une des nouveautés, introduites durant cette
seconde année de Master, que j’ai tout de suite trouvé motivante. Enfin, un de mes derniers
critères était l’idée de ne pas avoir un sujet précis, de ne pas avoir une application à réaliser de
bout-en-bout mais plutôt d’être intégré directement dans une équipe qui travaille à maintenir et
faire évoluer une solution existante.
Par conséquent, mon objectif personnel est d’apprendre un maximum : autant sur le
plan technique avec l’acquisition et le perfectionnement de concepts et de bonnes pratiques que
sur le plan humain en travaillant en équipe et en partageant les différentes idées de chacun. Bien
entendu, nous reviendrons sur toutes ces spécificités tout au long de ce document.
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
6
Nous allons, dans un premier temps, présenter l’entreprise Smartesting et décrire le
contexte dans lequel le stage va se dérouler, à savoir l’équipe R&D chargée de maintenir et
développer la solution Smartesting CertifyIt™. Toujours dans la même partie, nous décrirons les
différents objectifs et la mission du stage. Dans un second temps, nous poursuivrons sur une
brève description des méthodes agiles et nous nous attarderons davantage sur leur application
au sein de la société. Dans une troisième partie, nous nous pencherons sur le travail réalisé à
savoir les diverses améliorations apportées à la solution Smartesting CertifyIt™. Nous en
profiterons pour détailler, en particulier, deux fonctionnalités. Enfin, nous terminerons par un
bilan autant technique qu’humain afin de récapituler les développements réalisés et de conclure
sur l’ensemble des compétences acquises.
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
7
I. Contexte et objectifs du stage
L’Informatique a, aujourd’hui, pris une place prépondérante dans notre vie de tous les
jours en automatisant des tâches quotidiennes, bien souvent répétitives, mais en participant
aussi à notre sécurité grâce, par exemple, aux nombreux systèmes d’aide à la conduite. Dans ce
processus d’automatisation, les logiciels jouent un rôle indispensable.
Si le dysfonctionnement d’un appareil photo peut être désagréable, l’arrêt de l’ABS
(« antiblockiersystem » ou système antiblocage des roues) ou même du contrôle dynamique de
trajectoire d’un véhicule peut avoir des conséquences dramatiques. Le développement de
logiciels se trouve face à de nouveaux enjeux où il ne suffit pas tant d’innover que d’assurer la
qualité des logiciels produits. En effet, la fiabilité des résultats obtenus résulte de la fiabilité
même du logiciel utilisé. C'est là tout l'intérêt du test logiciel et c’est précisément là où se
positionne la société Smartesting en proposant une solution d’automatisation de la conception
de tests sur laquelle nous reviendrons dans la partie I.B : La solution Smartesting CertifyIt™.
A. La société Smartesting
Créée, en 2003, par Bruno LEGEARD et Laurent PY, Smartesting est une entreprise
française d'édition de logiciels. Implantée à Besançon et à Paris, elle tend aujourd'hui à se
développer à l’international grâce à des agences situées à Bangalore en Inde et à Boston aux
États-Unis. L'entreprise est, aujourd'hui, dirigée par Laurent PY - Président Directeur Général et
Stéphane WERBA - Directeur opérationnel.
L’activité de test est multidimensionnelle comme le montre ci-après la Figure 1 : Vision
multidimensionnelle de l'activité de test, proposée par Jan Tretmans (Université Nijmegen, Pays-
Bas). Smartesting propose une solution de génération de tests fonctionnels.
Figure 1 : Vision multidimensionnelle de l'activité de test
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
8
Les tests, dits fonctionnels, peuvent intervenir à tout moment dans le cycle de vie d’un
logiciel. Leur rôle est de simuler des actions dans un contexte réel d’utilisation afin d’identifier
d’éventuels problèmes : aussi bien des erreurs que des problèmes freinant l’utilisateur. Ils visent
à démontrer qu’un logiciel effectue ce pourquoi il est fait, en recherchant d’éventuelles
défaillances, en le sollicitant avec des valeurs d’entrée et en examinant le résultat donné. Le test
fonctionnel vérifie que l’objectif du code est atteint sans en connaitre ses détails.
Néanmoins, ce type de test présente certains inconvénients s’il doit être réalisé
manuellement : mobilisation de ressources, temps de réalisation important, vue subjective du
testeur et non réutilisable la plupart du temps. La solution CertifyIt™ de Smartesting propose de
remédier à ces défaillances en permettant de produire et de maîtriser des tests fonctionnels à
partir d’exigences métier.
Smartesting compte plus d’une trentaine de salariés dont une dizaine compose l’équipe
R&D (Recherche et Développement), basée au siège social à Besançon. Le reste est constitué de
consultants et de commerciaux présents notamment sur Paris et sur les agences internationales.
Tous, travaillent à faire évoluer et à promouvoir la solution Smartesting CertifyIt™.
Après avoir couvert de nombreux secteurs durant quelques années, la société se
positionne aujourd’hui sur le secteur IT (« Information Technology » ou technologies de
l’information) où elle recense majoritairement des grands comptes parmi ses clients : Accenture,
BNP Paribas, CAP Gemini, DGA (Direction Générale de l’Armement), Dassault Systems, Gemalto,
Steria…
B. La solution Smartesting CertifyIt™
Smartesting CertifyIt™ est un logiciel permettant la génération de cas de tests
fonctionnels à partir d’une modélisation UML1 des exigences. Cette activité, aussi appelée MBT
pour « Model-Based Testing », présente de nombreux avantages : modélisation abstraite et
partielle des comportements attendus d’un logiciel ce qui ne nécessite pas forcément d’être
développeur, maintenance facilitée des tests puisque la génération est automatisée et que, par
conséquent, seul le modèle doit être modifié pour mettre à jour les suites de tests, réduction des
risques d’erreurs liés à l’implémentation même du test avec un gain sur les coûts de processus et
bien d’autres que nous listerons pas ici.
1 UML pour « Unified Modeling Language » ou langage de modélisation unifié est un langage de modélisation graphique à
base de diagrammes couramment utilisé en génie logiciel dans le cadre de la conception orientée objet.
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
9
La solution se compose d’un logiciel permettant la génération automatique et d’un
« plug-in2 » intégré à un environnement de modélisation UML avec des contraintes écrites en
OCL3. L’ensemble produit des cas de tests et ce, en plusieurs étapes détaillées en Figure 2 : La
solution Smartesting CertifyIt™.
2 Plug-in (plugiciel en français) est un module d’extension qui complète un logiciel pour lui apporter de nouvelles
fonctionnalités. 3 OCL pour « Object Constraint Language » est un langage formel d’expression de contraintes utilisé par UML.
IBM - Rational Software Architect®
Conception du modèle
SMARTESTING CERTIFYIT™
Publication
Exportation du fichier
Fichier « .smtmodel »
Génération
PLUG-IN SMARTESTING
Spécifications
et exigences
Check
Export
Figure 2 : La solution Smartesting CertifyIt™
2
3
1
4
5
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
10
Au départ, un modèle comportemental est réalisé à partir des spécifications clientes.
Ce dernier se compose de trois diagrammes issus de la notation UML :
- Le diagramme de classes qui contient l’ensemble des concepts
et variables d’états du système sous test, appelé SUT
(« System Under Test »),
- Le diagramme d’états/transitions qui contient les
comportements du système et qui décrit les évolutions des
variables d’états (définies dans le diagramme précédent),
- Et le diagramme d’objets qui est utilisé pour définir l’état initial et les données de test.
Ces diagrammes sont réalisés grâce à l’environnement de modélisation Rational Software
Architect® d’IBM. Ce logiciel est basé sur la plateforme Eclipse, ce qui permet justement à
Smartesting d’y intégrer son « plug-in » permettant, dans une seconde partie, la vérification et
l’exportation du modèle créé. Le résultat de cette dernière opération est un fichier
spécifique (de type « smtmodel »). C’est ce fichier qui constitue le point d’entrée du logiciel
Smartesting CertifyIt™. Il suffit alors de le charger et de lancer la génération des tests.
Si la procédure se passe sans défaut c’est-à-dire que l’ensemble des tests passent, la
troisième et dernière étape vise à publier les tests sous différentes formes (HTML, JUnit) et
pour différents environnements de gestion de tests : TestLink (projet open-source), Quality
Center® d’HP ou Rational Quality Manager® d’IBM. A noter, tout de même, que ces deux
dernières solutions couvrent 95% du marché à elles seules et permettent de manager, gérer et
« versionner » les tests.
C. L’équipe R&D
Depuis peu, l’équipe R&D, composée d’une dizaine de personnes, est scindée en deux
équipes : la première est dédiée au maintien et à l’évolution des solutions commercialisées
(Smartesting CertifyIt™) tandis que la seconde équipe se charge de la définition et du
développement de solutions nouvelles. C’est dans la première équipe que le stage s’est déroulé :
c’est pourquoi nous nous y attacherons dans la suite du document.
L’équipe « CertifyIt™ » est composée de trois personnes dont un développeur à temps
plein, Monsieur Christophe Grandpierre (responsable de stage) et de deux personnes, Monsieur
Dooley Nsewolo Lukula, développeur/consultant et Monsieur Arnaud Bouzy travaillant pour
moitié en tant que développeur/product-manager.
Figure 3 : Logo UML (Unified Modeling Language)
2
3
4
5
1
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
11
Le schéma suivant (Figure 4 : Organisation de l'équipe CertifyIt™) détaille l’organisation
et les interactions de l’équipe.
Dans cette organisation, chacun joue son rôle. L’équipe R&D participe à l’estimation des
coûts de développement, rend compte du point de vue technique et assure le développement
du produit. Le product-manager, ou client XP, centralise l’ensemble des fonctionnalités à
développer ce qui lui permet de déterminer les fonctionnalités du logiciel, de gérer les priorités,
de valider les développements réalisés d’un point de vue fonctionnel et enfin de gérer le projet
dans sa globalité. La partie « consulting » a pour rôle de mettre en œuvre la solution chez
l’utilisateur final. Directement lié à ce dernier, les consultants peuvent ainsi remonter certaines
améliorations possibles (bugs, nouvelles fonctionnalités…) afin d’adapter la solution. Ainsi, ils
jouent les intermédiaires entre R&D/product-manager et le client.
Le product-manager, régulièrement au contact de l’utilisateur final, centralise et filtre les
retours-clients pour les prioriser, en collaboration avec les développeurs, afin de constituer une
roadmap4 », appelée ici feuille de route. Celle-ci se présente sous la forme d’un tableau de
tâches (« backlog ») qu’on détaillera plus tard dans ce document.
4 Roadmap est un mot anglais signifiant littéralement calendrier de lancement. En génie logiciel, on parle de feuille de route
pour désigner la direction de développement à suivre.
CLIENT FINAL - UTILISATEUR
EQUIPE R&D
CONSULTANTS
PRODUCT-MANAGER
DIRECTION
Figure 4 : Organisation de l'équipe CertifyIt™
Collaboration pour définir si une évolution est
réalisable et estimer son estimation en temps
afin de mettre à jour la feuille de route
Feuille de route Réalisation des tâches
Suivi et
échange sur
l’avancement
général
Echange sur de nouvelles fonctionnalités
Echange sur de nouvelles fonctionnalités
Liens externes (avec les clients)
Liens internes à l’entreprise Relations permanentes
Communications ponctuelles
Equipe dans laquelle ce stage s’est déroulé
roadmap
backlog
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
12
Les développeurs se chargent, ensuite, de développer les tâches définies dans la feuille
de route en respectant une qualité satisfaisante qui est définie au départ et qui est obtenue, en
autres, grâce aux méthodes de travail mises en place (voir la partie II : Méthodes agiles et outils
de travail).
Bien entendu, ce schéma indique le fonctionnement général en soulignant les relations
entre chaque acteur car il faut garder à l’esprit que la communication au sein de l’entreprise est
un facteur majeur de réussite et cela grâce aux méthodes de gestion pratiquées.
D. Missions et objectifs du stage
Intégré au sein de l’équipe « CertifyIt™ », mon rôle sera de maîtriser la solution
Smartesting CertifyIt™ pour ensuite développer des améliorations sur celle-ci et notamment sur
le « plug-in » Eclipse qu’elle intègre. A noter que ce dernier regroupe lui-même plusieurs « plug-
ins », c’est pourquoi ma mission est le :
Par conséquent, nous allons reprendre les termes de cet objectif pour définir la suite de
ce document. Nous commencerons par définir le contexte agile dans lequel j’ai évolué durant
ces mois de stage puis nous poursuivrons par l’étude des développements réalisés et, en
particulier, deux fonctionnalités : le regroupement d’éditeurs et l’outil Smartesting Viewer.
DEVELOPPEMENT DE PLUG-INS ECLIPSE
EN CONTEXTE AGILE
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
13
Figure 5 : Cycle en « V »
II. Méthodes agiles et outils de travail
Les méthodes agiles sont des méthodes de développement utilisées notamment pour les
projets en Informatique. Apparues au début des années 2000, elles sont aujourd’hui de plus en
plus utilisées dans le monde logiciel de par leur pragmatisme face aux méthodes traditionnelles
comme le célèbre « cycle en V » dont le schéma est présenté Figure 5 : Cycle en « V ».
Le modèle du « cycle en V » est une
gestion de projets particulière permettant de
limiter un retour aux étapes précédentes. Elle tire
son nom du fait de descendre d’une réalisation
générale à une réalisation détaillée puis de
remonter en testant à différents niveaux.
Néanmoins, ce modèle présente certains
inconvénients : attentes, retards, problèmes de
transmission d’informations, processus inutiles,
multitâches, travail partiellement fait, présence de
défauts… L’apparition des méthodes dites
« agiles » permet de résoudre ces inconvénients.
A. L’agilité
L’agilité est une notion qui regroupe un certain nombre de pratiques avec la promesse
d'une qualité de production et une réactivité élevée face aux nouvelles demandes. Plusieurs
méthodes existent aujourd’hui comme « eXtreme programming » (appelée XP) ou bien
« Scrum » et reposent sur une structure (cycle de développement) commune (itérative,
incrémentale ou adaptative) et quatre valeurs communes déclinées en douze principes
fondamentaux.
Nous ne listerons pas ici ces douze principes mais nous nous attacherons aux quatre
valeurs représentatives afin de montrer l’objectif visé de l’agilité.
Les quatre valeurs communes (extraites du Manifeste agile5) :
- L’équipe : « Les individus et leurs interactions, plus que les processus et les outils »
- L’application : « Des logiciels opérationnels, plus qu'une documentation exhaustive »
- La collaboration : « La collaboration avec les clients, plus que la négociation contractuelle »
- L’acceptation du changement : « L'adaptation au changement, plus que le suivi d'un plan »
5 Le Manifeste agile est un texte rédigé par des experts du développement d’applications informatiques sous la forme de
plusieurs méthodes dites agiles en détermine leurs points communs. Datant de 2001, il est aujourd’hui défendu par l’Agile Alliance.
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
14
L’approche agile adoptée par Smartesting se base sur les principes de l'« eXtrem
Programming ». Effectivement, la méthode XP regroupe treize pratiques : règles de codage,
restructuration du code, conception simple, tests unitaires, intégration continue, responsabilité
collective du code, travail en binôme, langage commun, rythme régulier, client sur site, tests de
recette, planification itérative et enfin livraisons fréquentes.
Il faut noter que ces pratiques ne sont pas figées et elles évoluent selon le contexte dans
lequel elles s’appliquent. L’équipe CertifyIt™ compte peu de membres (trois en l’occurrence) :
c’est l’une des raisons qui explique que l’ensemble des pratiques prônées par la méthode XP
n’est pas appliqué et adapté, en général, à des équipes de dix à quinze personnes. On peut citer,
par exemple, le travail en binôme qui est pratiqué aussi souvent que possible mais difficilement
dû au nombre de développeurs pour constituer les binômes.
B. Les pratiques Smartesting
A présent, nous allons nous focaliser sur les diverses méthodes de travail de l’équipe
R&D en faisant le parallèle avec les différents pratiques prônées par l’eXtreme Programming.
1. Planification itérative et déroulement des itérations
Afin d’être un maximum réactif et de pouvoir s’adapter rapidement à la demande du
client, les équipes fractionnent généralement le développement en courtes itérations de
quelques semaines (une à deux le plus souvent), validées au fur-et-à-mesure de leur
avancement. Durant cette courte période, le product-manager tient à jour un tableau de tâches,
considéré comme la « roadmap » précédemment (Figure 4 : Organisation de l'équipe CertifyIt™).
Charge, ensuite, à chaque développeur de choisir une tâche et de la développer.
Dans le cas du développement de la solution Smartesting CertifyIt™, nous sommes sur
une phase de maintenance et d’évolution du produit. Par conséquent, les itérations ne
correspondent plus à un nombre déterminé de semaines mais s’accordent par rapport aux
« releases6 » du produit. Le tableau de tâches (« backlog »), quant à lui, est géré grâce à
l’utilisation d’une application Web appelée « Kanbanpad ». Cette plateforme permet de gérer
des projets, et notamment des tâches, et de les affecter à des développeurs en charge de leur
réalisation. L’illustration (Figure 6 : Outil de gestion de backlog Kanbanpad) en montre un
aperçu. L’équipe l’utilise pour avoir, à tout moment, une vision globale de l’avancement des
fiches et donc des tâches de développement.
6 Release est un mot anglais signifiant sortie. En Informatique, on parle de versions d’un logiciel.
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
15
Les bugs détectés et les nouvelles fonctionnalités demandées par le client final sont
considérés comme des améliorations à la solution. Chacune d’entre elles fait l’objet de la
création d’une fiche (une tâche) qui est étudiée par le product-manager et les développeurs afin
de déterminer sa faisabilité et estimer son coût de développement. Cette opération est appelée
le « planning game7 ».
Charge, ensuite, à chaque développeur de choisir une tâche du « backlog » et de mettre
à jour son avancement : de sa planification (« planning » sur la Figure 6 : Outil de gestion de
backlog Kanbanpad) à son développement en passant par une phase de conception (« design »),
si nécessaire. Bien entendu, l’ensemble de l’équipe communique en permanence pour connaitre
les choix de chacun et l’environnement de travail en « open space8 » facilite cette procédure. On
rappelle ici que l’outil décrit ne sert qu’à obtenir une vision instantanée du travail réalisé. En
aucun cas, la communication de l’équipe ne se substitue à cet outil.
7 Planning game (appelé aussi « planning poker ») pour jeu du planning est une façon efficace de produire des estimations
sur la complexité des fonctionnalités à produire. Cette pratique est surtout utilisée par les méthodes agiles et a été introduite pour la première fois en 2002 par James Grenning. 8 Open space : anglicisme qui désigne une façon d’organiser un espace de travail à plusieurs.
Cycle de vie des tâches
Figure 6 : Outil de gestion de backlog Kanbanpad
Projet sélectionné
Catégories (feature, bug, technic,
doc…) représentées par un
système de couleurs et pouvant
correspondre à une priorité.
Equipe de développeurs
Exemple de tâche
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
16
Le développement d’une tâche consiste à écrire les tests unitaires, dans un premier
temps, puis de développer la fonctionnalité le plus simplement possible pour que les tests
réussissent. On parle alors d’approche TDD (« Test Driven Development » ou développement
piloté par les tests) permettant ainsi de développer une tâche sous couvert de tests.
Une fois dans la colonne « Testing » de la Figure 6 : Outil de gestion de backlog
Kanbanpad, une tâche est dite développée et testée unitairement. Elle doit encore passer une
phase de validation avant d’être mise en « release ». L’idée est qu’une personne, autre que le
développeur, valide cette tâche. Généralement, cette validation fonctionnelle se fait avec une
technique de « boite noire » c’est-à-dire sans connaitre l’implémentation réelle de la tâche.
Néanmoins, chacun peut juger bon de regarder le code suivant l’importance de la modification
et des modules touchés par cette dernière. Dès lors, une revue de code ou un « refactoring9 »
est effectué afin de détecter d’éventuelles erreurs de programmation ou de trouver des
vulnérabilités potentielles.
Si cette dernière étape de validation se révèle sans défaut, la tâche est mise en
« release » et pourra donc être intégrée à la prochaine version de la solution. Dans le cas
contraire, la tâche est repassée au stade de développement avec les commentaires justifiant ce
retour et le développeur en est averti. La correction se fait alors par un binôme constitué du
développeur et d’un tiers (voir partie II.B.3 : Travail en binôme).
J’ai pu appliquer cette méthodologie tout au long de mon stage à chaque développement
de tâches. Elle permet d’avoir une réelle organisation avec la gestion des priorités et permet
d’obtenir une vision globale à chaque instant. On notera qu’on utilise ici un outil (de gestion de
tâches) plutôt que de privilégier la communication et les interactions entre tous avec l’utilisation
d’un tableau de fiches papier. Ce choix a été fait car le product-manager, régulièrement en
déplacement, peut ainsi visualiser le « backlog » à tout moment.
2. Intégration continue et phase de tests
En parallèle, le développement se fait sur un mode
d’intégration continue. Cette notion, prônée par les
méthodes agiles, est un ensemble de pratiques utilisées pour
vérifier à chaque modification du code source que le résultat
de ce changement ne produit pas de régression dans
l’application. La modification se doit d’être une amélioration
et non une altération du produit final. Cela permet d’avoir, à
tout moment, une solution fonctionnelle et potentiellement
livrable.
9 Le refactoring est un terme anglais qui désigne le fait de retravailler le code source sans lui ajouter de fonctionnalité ni
même de corriger des bugs mais en améliorant sa lisibilité pour simplifier sa maintenance.
Figure 7 : Logos Jenkins - Subversion
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
17
Un serveur d’intégration continue (Jenkins) est mis en place avec un dépôt unique du
code source « versionné » grâce à l’utilisation du logiciel de gestion de version Subversion
(abrégé SVN).
Ainsi, lorsqu’une tâche est testée unitairement et développée, les modifications sont
immédiatement intégrées dans le produit final. Quand tous les tests passent (unitaires et
d’intégration), l’intégration est terminée. La tâche reste encore à être validée par un tiers.
Néanmoins, cette procédure permet d’éviter la surcharge de travail liée à l’intégration de
plusieurs éléments en même temps.
Le schéma, présenté en Figure 8 : Processus de développement d'une tâche, détaille le
processus complet d’intégration continue en faisant le parallèle avec le cycle de vie d’une fiche.
Création et planification d’une tâche
Figure 8 : Processus de développement d'une tâche
Choix d’une tâche
Analyse et conception
Product-manager
Développeur
Tests unitaires
Mise en « release »
Serveur
d’intégration /
dépôt
KO
Développement
Validation (« testing »)
Tierce personne
KO
OK
OK
* Commit : action utilisée par les logiciels de gestion de versions (ici SVN) pour désigner la validation d’une
transaction permettant de transférer son code source local sur le dépôt commun pour le rendre accessible à tous.
Commit
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
18
Dans cette course à la qualité, les outils ne suffisent pas. Comme l’évoque la première
valeur des méthodes agiles : « Les individus et leurs interactions, plus que les processus et les
outils ». C’est pourquoi, d’autres pratiques, se basant sur l’interaction des personnes, sont aussi
mises en place avec pour objectif la qualité, la communication et la simplicité…
Nous rappelons ici que la qualité avec le slogan « zéro défaut » n’existe pas mais l’objectif
est de produire et maintenir un logiciel dans lequel nous avons suffisamment confiance. En
outre, certaines phases de qualité peuvent être omises car leur mise en œuvre peut s’avérer
trop coûteuse par rapport au bénéfice estimé.
3. Travail en binôme
L’idée est de travailler en binôme sur une tâche souhaitée. Ce procédé permet ainsi une
meilleure qualité du travail accompli en privilégiant la communication entre les membres de
l’équipe qui interagissent avec leur propre vision des choses. Concrètement, le binôme travaille
sur le même poste et partage les périphériques d’entrée (clavier et souris) et chacun partage
ainsi son point de vue.
Durant le stage, cette pratique a été régulièrement utilisée avec mon tuteur notamment
sur des problèmes où la solution n’était pas toute trouvée. Ainsi, nous recherchions diverses
solutions en confrontant nos idées afin de trouver la mieux adaptée au problème qui se posait.
Cette pratique m’a permis d’acquérir des notions et des concepts beaucoup plus
rapidement. Côté logiciel, elle permet une harmonisation du code source et une détection des
erreurs plus tôt, à l’écriture du code. En effet, lorsqu’un développeur écrit, son binôme peut
ainsi le corriger directement. Sur le plan humain, cette méthode de binôme permet une certaine
interactivité entre les membres, l’échange d’idées et le partage de connaissances.
4. Conception simple, remaniement de code et règles de codage
A noter que le « binômage » a été aussi appliqué avec Romain Sibre, stagiaire consultant
chez Smartesting durant la même période. Nous avons eu l’occasion de travailler ensemble sur le
projet financé RASEN afin de réaliser une revue de code et du « refactoring ». La première notion
permet d’examiner le code source afin de détecter d’éventuelles erreurs de conception et
d’améliorer la qualité et la sécurité du logiciel. La seconde, quant à elle, consiste à retravailler le
code source sans lui ajouter de fonctionnalité ni corriger de bugs mais juste en amélioration sa
lisibilité.
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
19
Ce binôme était différent de celui réalisé avec mon tuteur dans le sens où je jouais
davantage le rôle du correcteur. Ainsi, j’ai pu corriger objectivement des erreurs qu’il m’arrive de
faire aussi. Cette opération m’a été très utile car j’ai pris conscience de la difficulté à reprendre
du code que nous n’avons pas écrit nous-mêmes et dont la compréhension s’avère parfois assez
complexe. Je comprends, à présent, l’utilité d’un code clair et concis découpé en courtes
méthodes avec chacune un rôle précis. Cela facilite aussi l’écriture des tests unitaires.
D’ailleurs, nous avons pu compléter les tests unitaires écrits jusqu’à ce que nous ayons
réellement confiance dans le code. Là aussi, j’ai pu comprendre la difficulté d’écrire des tests
lorsque le code, au départ, n’est pas sûr. Ainsi, lorsque les tests ne passent pas, il est difficile de
savoir si cela vient du code ou des tests eux-mêmes. L’approche « tests-first » et ses variantes
permettent de remédier à ce genre de problèmes.
Un binôme qui a très bien fonctionné et qui nous a permis de partager des visions et des
idées différentes à certains moments. Nous nous sommes rendu compte au final que le code
était harmonisé, beaucoup plus simple à appréhender, et surtout qu’il donnait davantage
confiance.
D’autres méthodes de travail ont été utilisées et citées implicitement précédemment.
Nous pouvons citer le travail en équipe ou l’appropriation collective du code car l’équipe est
collectivement responsable de l’application. Chaque développeur peut modifier des portions de
code qu’il n’a pas forcément écrites. Les tests se chargeront de révéler ensuite d’éventuelles
erreurs.
Une autre pratique qui permet une certaine qualité du code concerne les conventions
puisque tous les développeurs interviennent sur le code source et il est indispensable de
respecter certaines normes. Plusieurs exemples peuvent être cités : convention de nommage,
utilisation du mot-clé « final » pour des questions d’optimisation et afin d’obtenir des objets
immuables, tout comme l’usage de listes non modifiables en retour de méthodes comme le
montre la Figure 9 : Exemple de collection immutable. Le respect de ces normes est un ensemble
de bonnes pratiques de développement Java [CR11].
Figure 9 : Exemple de collection immutable
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
20
Enfin une dernière pratique est liée directement à l’une des valeurs des méthodes agiles :
« Des logiciels opérationnels, plus qu'une documentation exhaustive ». Ainsi, nous avons un code
source sans aucun commentaire car l’idée est que l’usage de ces derniers est une conséquence
d’un code complexe et difficile à appréhender. Hors, l’objectif est d’obtenir un code clair et
concis.
Un exemple concret est l’utilisation du « framework 10» Google Collections issu du projet
Guava11 et qui m’était inconnue jusqu’alors. Cette bibliothèque permet de manipuler assez
simplement des collections Java et, par conséquent, améliore la lisibilité du code. Elle permet, en
autres, de rechercher des éléments et de filtrer, de transformer ou de composer des collections.
Au lieu d’avoir des boucles dont les conditions et les incréments sont difficiles à visualiser
de prime-abord, elle permet une certaine visibilité sur l’objectif d’une méthode ou d’une partie
précise du code. La Figure 10 : Exemple d'utilisation des Google Collections présente un exemple
de code où l’on cherche à r etourner, parmi une collection, tous les films de l’année 2000. Deux
méthodes sont écrites : la première est l’écriture « naïve » du problème posé tandis que la
seconde est la solution utilisant les Google Collections.
10
Framework (littéralement cadre de travail) est un mot anglais qui désigne un kit de composants logiciels qui servent à
créer les fondations et les grandes lignes de tout ou partie d’un logiciel (son architecture). 11
Le projet Guava regroupe dans sa majorité les Google Collections qui est un « framework » s’intéressant aux
problématiques de bas-niveau et apportant un support fiable aux développeurs sur le sujet des collections Java.
Figure 10 : Exemple d'utilisation des Google Collections
A
V
E
C
S
A
N
S
Une ligne de code suffit
Compréhensible mais plus
difficile à appréhender
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
21
La première méthode n’est peut-être pas la plus efficace pour réaliser un filtre sur une
collection mais c’est la solution « naïve » que j’aurais écris avant de connaitre le framework
Google Collections.
Nous constatons, dans la seconde méthode, que l’utilisation de ce framework permet
d’avoir un code source simple, clair et concis tandis que dans la première, des informations
supplémentaires faussent la compréhension comme les conditions. A noter aussi que la
première méthode devra sûrement être testée afin de se rassurer sur le résultat retourné
contrairement à la seconde puisqu’on réutilise une méthode existante (filter) qui nous permet
de ne pas gérer la structure complexe (la boucle et sa conditionnelle).
Qualité, simplicité, interaction et communication sont donc des valeurs prônées par les
méthodes agiles et appliquées au sein de l’équipe chargée du maintien de la solution
Smartesting CertifyIt™. Maintenant que nous avons défini l’environnement de travail dans sa
globalité, nous rentrons dans le vif du sujet en étudiant le travail réalisé au cours de ces mois de
stage.
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
22
III. Développements réalisés
L’axe majeur de mon travail tout au long de ce stage a été le développement JAVA lié à la
solution Smartesting CertifyIt™ et plus particulièrement à la plateforme Eclipse/Eclipse RCP sur
laquelle elle repose. Pour rappel, RCP est un outil permettant la conception d’applications
autonomes en développant des « plug-ins » adaptés à la plateforme Eclipse.
Mon stage s’est déroulé en plusieurs phases comme l’illustre la Figure 11 : Phases de
développement. La première s’est faite durant les premières semaines et m’a permis de
découvrir l’ensemble des outils et des méthodes utilisés. De plus, elle m’a permis de me
familiariser à la notion de « plug-ins » et de connaitre certains éléments de l’architecture Eclipse
comme la zone d’éditeurs. La seconde, quant à elle, constitue une phase de développement
d’améliorations (bugs, fonctionnalités…) qui s’est déroulée aussi sur plusieurs semaines. Ces
deux premières phases m’ont ainsi permis de participer à la sortie de la release 5.3.2 de la
solution Smartesting CertifyIt™. Enfin la dernière phase constitue le début d’un projet avec la
création d’un « shell viewer ».
A présent, nous allons nous concentrer sur deux fonctionnalités précises à savoir le
regroupement d’éditeurs (phase 1) et le projet Smartesting Viewer (phase 3). La phase 2 a permis de
poursuivre l’amélioration de la solution, débutée au début de stage, en continuant notamment à
faciliter son utilisation et en résolvant des bugs. Nous pouvons citer, entre autres, quelques exemples
comme la gestion du double-clic sur les arbres afin d’ouvrir plus rapidement les éditeurs, la gestion
d’une complétion sur la documentation ou encore la création d’une option de recherche globale sur
l’ensemble des projets ouverts.
temps
Figure 11 : Phases de développement
6 semaines
Début de stage
1 mois 2 mois 6 semaines
Fin réelle de stage Présentation de stage
PHASE 1
Regroupement
d’éditeurs
PHASE 2
Améliorations
diverses
PHASE 3
Projet « Smartesting Viewer »
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
23
A. Regroupement d’éditeurs
Le premier objectif à mon arrivée au sein de Smartesting était de prendre connaissance
du code et de maîtriser la solution Smartesting CertifyIt™ en prenant des exemples et en
appliquant de bout-en-bout le processus décrit précédemment (voir la Figure 2 : La solution
Smartesting CertifyIt™). En parallèle, l’objectif était de proposer des améliorations possibles sur
la solution.
Après quelques semaines d’utilisation, j’ai proposé une amélioration sur le
regroupement d’éditeurs. En effet, lors de la conception du modèle UML, une phase d’édition
des « pré » et « post » conditions est requise sur les opérations, les états et les transitions du
diagramme d’états/transitions afin de déterminer le comportement du système sous test. Cette
édition est réalisable grâce au « plug-in » Smartesting via des entrées dans le menu.
Le problème, illustré à la Erreur ! Source du renvoi introuvable., est la répétition des
actions pour arriver à éditer les différents comportements. En effet, si l’on veut éditer les actions
d’une seule opération du modèle, il faut afficher le menu en cliquant sur l’opération,
sélectionner tout d’abord « edit precondition » puis renouveler la manipulation deux fois en
sélectionnant « edit postcondition » et « edit documentation ». Le résultat étant l’ouverture de
trois éditeurs distincts.
L’amélioration proposée était une question d’ergonomie et de facilité d’utilisation. Ainsi,
pourquoi ne pas avoir une seule entrée dans le menu qui ouvrirait une seule page regroupant
plusieurs éditeurs ?
On remarque la présence de
trois éditeurs indépendants
avec en plus, pour la « post-
condition », la présence d’un
éditeur de texte et d’un tableur.
Figure 12 : Anciens éditeurs OCL
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
24
Une fois l’amélioration proposée, nous l’avons soumis aux consultants et au product-
manager pour connaitre leur opinion et éventuellement obtenir des idées de réalisation. Leur
avis était indispensable pour savoir si la fonctionnalité pouvait répondre à un besoin. Après
échange, nous avons convenu que la fonctionnalité devait être implémentée. Plusieurs idées ont
été suggérées comme par exemple :
- Une seule entrée dans le menu avec l’ouverture simultanée de plusieurs éditeurs
- Une seule entrée et une seule page avec une décomposition des éditeurs en sections
- Une seule entrée et une seule page avec une décomposition des éditeurs en onglets
Une analyse de l’existant a été faite pour comprendre le fonctionnement de la
plateforme Eclipse et notamment de ses éditeurs puisqu’on le rappelle, nous travaillons ici sur le
« plug-in » (Eclipse) de la solution Smartesting CertifyIt™.
Celle-ci a permis aussi d’écarter certaines idées non réalisables, par rapport à
l’architecture Eclipse, ou tout simplement non satisfaisantes comme la décomposition d’éditeurs
sous forme de sections au sein même d’une seule et même page car ne laissant que trop peu de
places à l’édition.
En réalité, la fonctionnalité s’est avérée plus difficile à développer qu’elle n’y paraissait.
En effet, il ne suffisait pas de créer une nouvelle entrée dans le menu et d’ouvrir une seule page.
L’architecture Eclipse est plus complexe à appréhender et chaque éditeur est associé à des
modèles et des stockages spécifiques. Par conséquent, la combinaison de trois éditeurs en un
seul nous a obligés à revoir la conception depuis le début. A la fin de l’étude, le choix s’est porté
sur une entrée menu donnant accès à une page regroupant des éditeurs via des onglets comme
le montre la Figure 14 : Nouvel éditeur OCL développé.
Figure 13 : Aperçu des idées de conception graphique des nouveaux éditeurs
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
25
Le résultat en est une facilité d’utilisation notamment pour un modèle comportant un
nombre sensible d’opérations. A noter aussi que l’on prend pour exemple ici les opérations mais
il faut avoir à l’idée que les états et transitions du diagramme d’états/transitions peuvent faire
l’objet d’une édition OCL.
A présent, un seul clic suffit dans le menu pour voir apparaitre toutes les informations.
On ne s’attardera pas ici à détailler l’implémentation de la fonctionnalité mais celle-ci fût
développée sur une période de quatre semaines pour arriver à un résultat validé par les
consultants et le product-manager avec lesquelles j’ai été en collaboration tout au long du
développement. A présent, cette amélioration fait partie intégrante de la « release » 5.3.2 de la
solution CertifyIt™ de Smartesting.
Son développement m’a permis d’appréhender le code existant en apprenant, en même
temps, de nouveaux concepts et de nouvelles méthodes de programmation. Aussi, j’ai pu
commencer à développer avec Eclipse RCP en abordant les « plug-ins » par le biais de fichiers
XML (pour les entrées menu) et en me familiarisant avec son architecture. Ayant repris la
conception depuis le départ, j’ai eu l’occasion d’améliorer mes compétences en JAVA et
notamment sur le plan graphique avec l’utilisation de SWT12 et JFace13.
12
SWT (Standard Widget Toolkit) est une bibliothèque graphique libre pour Java sur laquelle se repose, en autre, la
plateforme Eclipse. Elle permet notamment l’implémentation native spécifique à chaque système d’exploitation. 13
JFace est une bibliothèque graphique qui se repose sur SWT pour fournir des composants de plus haut niveau.
Figure 14 : Nouvel éditeur OCL développé
Ouverture d’une seule page comportant
tous les éditeurs regroupés en onglets
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
26
Après cette réalisation et comme cité précédemment (voir la Figure 11 : Phases de
développement), ma mission était de poursuivre l’amélioration de la solution Smartesting
CertifyIt™ en continuant à faciliter son utilisation et en résolvant des bugs. De nombreuses
fonctionnalités qui m’ont permis sans cesse d’apprendre sur le langage JAVA et qui ont été
intégré directement sur la « release » 5.3.2 de la solution comme le montre la Figure 15 : Release
5.3.2 de la solution Smartesting CertifyIt™.
Figure 15 : Release 5.3.2 de la solution Smartesting CertifyIt™
Fonctionnalités développées
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
27
Au bout de quelques mois et après plusieurs remontées clients, une nouvelle
fonctionnalité sur la solution Smartesting CertifyIt™ était envisagée. En effet, certains
utilisateurs, notamment des chefs de projet et des experts métier utilisent la solution mais
seulement à titre consultatif. Aujourd’hui, cette utilisation particulière leur pose certains
problèmes (achat de licence, difficultés d’installation…) et la société doit, par conséquent,
adapter sa solution aux diverses utilisations qui lui en sont faites.
Afin de répondre à ce besoin, l’idée est de créer une application basée sur la plateforme
Eclipse et permettant exclusivement de consulter certains projets (de la même façon que
Rational Software Architect® d’IBM). La seule différence résidera dans la facilité d’utilisation et
l’impossibilité de modifier les projets puisque seule la consultation sera fonctionnelle : un mode
« read-only » en quelque sorte.
B. Smartesting Viewer
Cette application, appelée « viewer » en référence à la visualisation, doit être vue comme
une nouvelle fonctionnalité puisqu’ elle sera intégrée à la solution Smartesting CertifyIt™. A titre
de comparaison, nous pourrions prendre la suite Adobe pour la gestion des fichiers PDF. Il existe,
aujourd’hui, un logiciel payant d’édition de fichiers PDF appelé Adobe CreatePDF et un logiciel
gratuit de consultation Adobe Reader. Au final, la solution Smartesting CertifyIt™ comprendra
aussi deux fonctionnalités : un outil d’édition et un outil de visualisation (le « viewer »).
Ce « viewer » se devra de résoudre les problèmes rencontrés actuellement par les chefs
de projet et les experts métier. Tout d’abord, une question d’ordre financier en n’obligeant pas
l’utilisateur final à acheter une licence globale relativement élevée aujourd’hui pour de la
consultation. Ensuite, des difficultés d’installation et de prise en main pour des utilisateurs ne
maîtrisant pas le modeleur RSA (Rational Software Architect®) d’IBM. En effet, cet outil complet,
sur lequel se base la solution Smartesting CertifyIt™, possède de nombreuses configurations et
sa prise en main est assez difficile. C’est ce point précis qui nous intéressera par la suite tout
comme le dernier problème : le filtrage des informations selon le profil utilisateur.
Ainsi, on peut penser qu’un chef de projet appréciera une vue de statistiques et
d’indicateurs d’avancement tandis qu’un expert métier se concentrera davantage sur la
validation des aspects fonctionnels en consultant les tables ou les énumérés.
L’idée est donc de créer une application basée sur la plateforme Eclipse et relativement
facile à utiliser. Pour cela, nous devons partir d’un noyau épuré d’Eclipse. Le « viewer » sera ainsi
principalement constitué de « plug-ins » adaptés à ce noyau.
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
28
L’objectif, dans un premier temps, est de réfléchir sur la construction de ce noyau pour
disposer d’un exécutable prêt à l’emploi. L’objectif suivant et qui restera mon objectif jusqu’à la
présentation de ce stage est l’ajout de « plug-ins » à ce noyau Eclipse afin de constituer un
« shell » minimal sur lequel le « viewer » final se reposera comme le montre la Figure 16 :
Architecture de l’outil Smartesting Viewer.
Le « shell viewer » se repose sur le noyau Eclipse pour faciliter l’intégration d’autres
« plug-ins » déjà existants. Après étude avec les consultants et le product-manager, ce « shell »
doit comporter plusieurs composants dont un menu de base et un explorateur de projets pour
les principaux. Il constituera une application minimale : notre propre noyau en quelque sorte.
Néanmoins, avant de le développer, l’objectif est de réfléchir sur sa construction afin de
faciliter l’intégration de nouveaux « plug-ins » au fur-et-à-mesure de son développement et
d’avoir un exécutable à tout moment.
Plug-ins ou modules à développer Plug-ins existants
SHELL VIEWER « Shell » minimal
Noyau
Eclipse
Menu
Plug-in Smartesting
« core »
Editeurs
Autres…
Explorateur
de projets
Plug-in Smartesting
« publisher »
Plug-in Smartesting
« licence »
… / …
Smartesting Viewer
Figure 16 : Architecture de l’outil Smartesting Viewer
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
29
Construction du « shell Viewer »
Un « product » est un exécutable Eclipse résultant d’une construction des sources. Sa
création est relativement aisée par le biais du PDE (Plug-in Developement Environment)14 Eclipse
car gérée via une interface graphique. Il suffit d’y indiquer les paramètres de construction et
c’est l’IDE qui se charge de concevoir l’exécutable. Néanmoins, cette opération n’est pas
détaillée et, même après plusieurs recherches, il est difficile de connaitre le mode opératoire.
Au départ, nous sommes parti sur une construction automatique de l’exécutable. Par
conséquent, à chaque modification du code, un « build15 » aurait permis de construire
automatiquement un « product ». Cette idée a fait l’objet d’une étude afin de déterminer les
solutions possibles. Deux possibilités se dégagent de cette analyse :
- La construction avec ANT : historique, cette solution annexe est apparemment difficile à
mettre en œuvre dû à des scripts complexes, tout comme son utilisation dans un outil
d’intégration comme Jenkins.
- La construction avec Maven et Tycho : Maven est un outil comparable à ANT sauf qu’il est
plus facile de le prendre en main et de comprendre son fonctionnement. Seul, il ne peut être
utilisé pour construire des exécutables Eclipse car tout deux présentent une incompatibilité
(architecture OSGi sur laquelle se base Eclipse et que Maven ne reconnait pas). C’est
pourquoi Tycho est requis. Ce dernier est un « plug-in » Maven qui permet de construire des
binaires de « plug-ins » Eclipse.
La première construction a tout de suite été écartée car elle semblait beaucoup trop
complexe et difficile à appréhender. Ce choix a été fait afin de ne pas perdre trop de temps à
trouver la meilleure solution au problème de construction du « shell Viewer ». La combinaison
de Maven et Tycho a été retenue et utilisée pour savoir si elle était conforme à notre objectif.
Nous arrivions bien au résultat escompté à savoir un exécutable Eclipse mais des difficultés ont
été rencontrées lorsqu’il a fallu intégrer ce processus dans l’outil d’intégration continue Jenkins.
Avec consultation du product-manager, nous nous sommes alors tournés vers une
troisième solution qui est la plus appropriée à notre cas : la construction manuelle d’un
« product » de noyau Eclipse (via l’IDE Eclipse) et y intégrer automatiquement des « plug-ins »
qui constitueront notre « shell ». Ce choix a été fait après avoir analysé justement l’intégration
de « plug-ins » au sein d’un exécutable Eclipse : celle-ci est relativement aisée. La Figure 17 :
Construction du noyau « Viewer » présente le fonctionnement de cette solution de construction.
14
PDE (« Plug-in Development Environment ») pour environnement de développement de « plug-ins » est un assistant de
création de « plug-in » qui permet, en autre, d’éditer les fichiers de configuration. 15
Un build est, comme son nom le suggère, une construction d’une version exécutable de tout ou partie d’un logiciel.
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
30
Par conséquent, nous avons construit une et une seule fois le noyau Eclipse pour avoir en
résultat un répertoire avec notamment l’exécutable et un sous-répertoire « plugins ». A ce
stade, si nous lançons l’exécutable, une fenêtre s’affiche avec seulement les contrôles de
redimensionnement et de fermeture (Figure 18 : Résultat de l'exécution du noyau Eclipse). Afin
de constituer notre « shell Viewer », il suffira donc d’intégrer, manuellement ou
automatiquement, des extensions dans le sous-répertoire « plugins » sous la forme de fichiers
JAR16.
16
JAR (Java Archive) est un format de fichier utilisé pour distribuer un ensemble de classes Java. Cette archive stocke les
définitions des classes, des métadonnées et l’ensemble d’un programme.
Figure 17 : Construction du noyau « Viewer »
Noyau
Eclipse
Plug-in Menu Résultat de la
construction Construction
manuelle via
l’IDE Eclipse Plug-in Console
« SHELL VIEWER »
Plug-in Editeurs
Plug-in Explorateur
…
Figure 18 : Résultat de l'exécution du noyau Eclipse
Exécutable
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
31
Développement du « shell Viewer »
Le développement de cette application minimale est principalement d’ordre graphique.
Comme cité précédemment, le « shell » se devra de proposer un menu avec des options
basiques et relatives à de la consultation. On aura donc des entrées comme « open file »,
« export » et non « sauvegarder sous » qui résulte d’une modification. De plus, un explorateur
de projet permettra des actions sur les différents fichiers comme l’ouverture dans une zone
d’éditeurs. Mais avant tout, intéressons-nous à l’architecture Eclipse via un aperçu d’écran.
Menu
Barre d’outils (toolbar)
Une vue
Ici, l’explorateur
de projets
Là, d’autres vues…
La zone d’éditeurs
La barre de statuts Une page composant une perspective
Figure 19 : Architecture Eclipse - Représentation du workbench
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
32
La Figure 19 : Architecture Eclipse - Représentation du workbench détaille l’ensemble des
composants de l’architecture Eclipse. Dans notre cas, nous avons besoin du menu et d’une page
composée d’une vue « explorateur de projets » et d’une zone d’éditeurs. C’est ces éléments qui
constitueront notre « shell ».
Le menu est construit via le PDE Eclipse. En réalité, c’est un fichier XML qui est écrit au fur-et-
à-mesure et qui regroupe toutes les informations nécessaires à la création d’un menu (items,
sous-items, raccourcis clavier…). Le « shell » propose un menu des plus basiques avec des
items « file » (gestion de l’application et des fichiers), « edit » (recherche ou sélection de
termes), « window » (gestion de la zone d’éditeurs), « project » (gestion des projets) et enfin
« help » (aide, préférences). Celui-ci constitue, pour l’instant, une base et il sera sûrement
amené à changer au fur-et-à-mesure selon les besoins.
La page principale, développée aussi avec le PDE Eclipse, regroupe deux zones :
- Une zone d’éditeurs permettant d’ouvrir des fichiers. La particularité ici est le mode
« read-only » (lecture seulement) de ces éditeurs afin d’interdire leur modification.
- Un explorateur de projets qui est le module le plus important du « shell » et qui constitue
la base du « viewer ». Cette vue associée à un « workspace17 » permet de gérer des
projets.
Cette page est associée à une perspective. On ne s’attardera pas ici sur ce dernier terme puisque
le « shell » ne propose qu’une seule perspective afin de faciliter l’utilisation de l’application. En
effet, afin de répondre au besoin de filtrage des informations selon le profil utilisateur, nous
avons réfléchi (développeurs, consultants et product-manager) sur les diverses solutions
possibles à l’implémentation de cette fonctionnalité. Plusieurs possibilités se dégageaient de
cette réflexion :
- Développer plusieurs versions de « viewers » adaptés à certains utilisateurs.
- Avoir un seul « viewer » avec plusieurs perspectives.
- Une seule application avec une seule perspective mais plusieurs vues.
C’est cette dernière idée que nous avons retenu afin de proposer une application des plus
simples possibles. L’utilisateur final n’aura qu’à gérer un ensemble de vues selon ses besoins et
la compréhension en est facilitée. Ainsi, il n’y a pas plusieurs versions de « viewers », ni plusieurs
perspectives à gérer.
Après une longue phase d’analyse et de tests de l’architecture Eclipse, j’ai développé
l’ensemble du « shell » par l’intermédiaire du PDE Eclipse : du menu à l’explorateur de projets en
passant par toute la configuration des pop-up menus. La plateforme Eclipse RCP propose, en
effet, de nombreuses configurations qui nous permettent d’avoir une application minimale sans
écrire aucune ligne de code. Un aperçu du résultat est visible en Figure 20 : Aperçu du « shell
Viewer ».
17
Workspace pour espace de travail est un répertoire créé à l’ouverture de l’application et regroupant l’ensemble des
projets gérés via l’application.
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
33
Ce « shell » minimal est une base solide à l’ajout de « plug-ins » existants afin de
constituer le « viewer » qui sera intégré à la solution Smartesting CertifyIt™. Cette application de
base représente une petite partie du projet global de « viewer » que je suis entrain de
développer au moment où j’écris ces lignes.
En effet, maintenant que nous avons notre noyau, deux nouveaux objectifs sont fixés. Le
premier se concentre sur l’explorateur de projets en permettant l’ouverture de fichiers
spécifiques comme les suites (fichiers avec l’extension « .smartsuite » propres à Smartesting) ou
les fichiers « emx » propres à RSA® d’IBM. Le second est l’ajout de premiers « plug-ins » déjà
existants au sein de la solution Smartesting CertifyIt™ comme le « tag browser » qui est une vue
listant les différents tags présents dans les suites. Le développement de ces objectifs est en
cours de réalisation et sera terminé pour la fin réelle de stage à savoir fin Juillet.
Pour conclure, nous allons réaliser un bilan technique en listant quelques difficultés
majeures rencontrées puis en récapitulant toutes les notions et concepts appréhendés tout au
long de ce stage. Nous terminerons par un bilan humain et une conclusion plus générale.
Figure 20 : Aperçu du « shell Viewer »
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
34
Bilans et conclusion
Cette dernière partie est la conclusion de tout le travail réalisé au sein de l’équipe R&D
Smartesting. C’est aussi, en quelque sorte, la conclusion de ma formation initiale après cinq
années d’études supérieures dont la majorité au sein de l’Université de Franche-Comté.
A. Difficultés rencontrées
De nombreuses difficultés, plus ou moins bloquantes, ont été rencontrées tout au long
de ce stage. Certaines étaient mineures comme la prise en main de l’IDE IntelliJ Idea que je ne
connaissais pas jusque là. En effet, j’ai déjà eu l’occasion de travailler avec Eclipse et NetBeans
mais pas du tout avec cet environnement de développement. Au fur-et-à-mesure du stage et à
force de connaitre la configuration de cet outil, je me suis rendu compte du temps gagné sur le
développement de tâches grâce aux raccourcis clavier entre autre.
A ces difficultés mineures se sont ajoutés de sérieux problèmes, parfois même bloquants.
Le premier que je peux citer est la prise en main de la solution Smartesting CertifyIt™. Non pas
en terme d’utilisation mais plutôt au niveau du code source avec ses conventions de nommage,
ses règles et surtout ses dizaines de milliers de lignes de code à « apprivoiser ». Par conséquent,
il m’a fallu quelques semaines pour appréhender certaines parties. Ceci m’a permis de me
familiariser avec les concepts de codage comme l’utilisation de certains design-patterns ou
encore du framework Google Collections. La seconde difficulté majeure, qui a été régulièrement
bloquante, a été la maitrise de l’architecture Eclipse et notamment son workbench (partie
graphique de l’architecture).
Tout au long du stage, j’ai pu surmonter toutes ces contraintes grâce à l’aide reçue des
membres de l’équipe R&D et tout particulièrement de mon tuteur. En parallèle, j’ai tout de
même fais preuve d’autonomie en recherchant constamment les solutions à mes problèmes sur
Internet (documentations, blogs, tutoriaux…) et dans des ouvrages mis à disposition au sein de la
société.
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
35
B. Bilan technique
Comme évoqué au début de ce document, mon objectif était de réaliser un stage
récapitulant l’ensemble des compétences acquises tout au long de mon parcours et, en même
temps, en assimilant de nouveaux concepts et de nouvelles notions.
Ainsi, j’ai eu l’occasion de me perfectionner sur le langage JAVA (dans lequel j’ai envie de
poursuivre mon implication) et, de manière plus générale, en programmation en m’appropriant
notamment de bonnes pratiques de développement. J’ai pu aborder de nombreuses
bibliothèques et notions du monde JAVA : plateforme Eclipse, Eclipse RCP, SWT… Ce qui me
permet, à présent, d’avoir de plus fortes compétences dans ce langage.
Le domaine des tests, qui était plutôt flou au départ pour moi, est beaucoup plus clair
aujourd’hui et ce, grâce à une plongée au sein même de cette activité. Ce fut d’ailleurs l’un de
mes critères de choix pour venir au sein de l’équipe Smartesting, que je ne regrette aucunement.
Je me suis rendu compte que cette activité jouait une part très importante dans la livraison
d’une application de qualité.
A cela s’ajoute, l’appropriation des techniques issues des méthodes agiles comme le
fonctionnement d’intégration continue sur lequel nous avions pu travailler à l’Université mais
seulement sur un projet. Par conséquent, ce processus était assez vague mais je comprends
beaucoup mieux aujourd’hui son objectif et ses avantages.
Enfin, j’ai pu assimiler de nouvelles connaissances sur des sujets variés comme, par
exemple, les « builds » avec ANT mais surtout Maven. On peut citer la prise en main de
l’environnement IntelliJ Idea ou encore mon perfectionnement sur l’utilisation de Subversion.
Je ne détaillerai pas la liste de tout ce que j’ai appris car il y a de nombreuses choses à
évoquer mais je pense posséder aujourd’hui un sérieux bagage avec de solides compétences
pour entrer dans le monde professionnel. J’ai pris conscience qu’il faut sans cesse progresser
mais je pense, aujourd’hui, avoir déjà des atouts confortables qui me permettront ainsi
d’évoluer aussi bien techniquement qu’humainement.
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
36
C. Bilan humain
La première valeur qui me vient à l’esprit en cette fin de stage est le travail en équipe :
aussi bien au sein même de l’équipe CertifyIt™ avec la mise en place de binômes par exemple,
qu’avec la collaboration avec d’autres groupes comme les consultants et le product-manager.
Les méthodes agiles y jouent un grand rôle en intégrant une dimension humaine très
forte et en accordant beaucoup d’importance à l’individu. Je peux le constater aujourd’hui en
comparant mes différents stages avec cette expérience chez Smartesting. Leur application
pousse naturellement à la communication et à l’entraide entre les différents membres de
l’équipe, ce qui m’a permis d’obtenir des connaissances beaucoup plus rapidement. Nous
sommes dans un cercle de qualité où le dialogue a une importance capitale et participe à la
solidarité de l’équipe qui, elle-même, participe à la prise d’initiatives (donc de dialogue, d’écoute
et de compréhension). L’exemple le plus concret est l’ensemble des améliorations que j’ai eu
l’occasion de proposer et qui ont été prises en compte pour faire évoluer la solution.
Dès mon arrivée, j’ai tout de suite été intégré et l’équipe m’a accordé beaucoup de confiance si
bien que j’ai fais preuve d’initiatives et force de proposition. Si ce stage a été enrichissant sur le
plan technique, il ne l’a donc pas moins été sur le plan relationnel.
D. Conclusion générale
Je termine ce stage par un bilan plus que positif : aussi bien personnel avec l’ensemble
des compétences mises en pratique que sur l’ensemble des développements réalisés. En effet,
j’ai pu développer plusieurs fonctionnalités innovantes en termes de facilité d’utilisation et
d’ergonomie de la solution Smartesting CertifyIt™. Intégrées depuis la « release » 5.3.2 de la
solution, ces fonctions répondent aujourd’hui à un réel besoin. A cela s’ajoute, le projet
Smartesting Viewer que j’ai débuté en permettant d’avoir une solide base à la construction du
« viewer » final qui, pour rappel, sera distribué avec la solution pour des chefs de projet et des
experts métiers.
Ce stage a donc été très instructif puisqu’il m’a permis de participer à toutes les étapes
de développement d’un logiciel, notamment en codant sous couverts des tests, et j’ai pu
approfondir une méthodologie de travail grâce à certaines pratiques de la méthode XP. J’en
ressors grandi aussi bien sur l’ensemble de mes compétences que sur le plan humain.
De solides bagages que j’espère pouvoir continuer à appliquer…
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
37
Bibliographie
Développement JAVA
[BJ08] Bougeault, J. (2008). Java - La maîtrise - 2e édition : Java 5 et 6. Paris: Edition Eyrolles.
[CR11] Chevallier, R. (2011). Java 7. Paris: Edition Campus Press / Pearson.
Construction avec Apache Maven
[HND11] Héritier, N. D. (2011). Apache Maven version 2 et 3. Paris: Edition Pearson.
Domaine des tests
[PJF09] Printz, J.-F. P.-P. (2009). Pratique des tests logiciels : concevoir et mettre en œuvre une
stratégie de tests et préparation à la certification ISTQB. Belgique: Dunod.
Environnement Eclipse - Eclipse RCP
[REC09] Rubel, E. C. (2009). Eclipse Plug-ins - Third Edition. Boston: Addison-Wesley.
Méthodes agiles
[WJS08] Warden, J. S. (2008). The Art of Agile Development. United States Of America: O'reilly.
Intégration au sein de l’équipe R&D Smartesting BERNARDIN Benoît
38
Sitographie
Développement JAVA
Documentation officielle sur Java fournie par Oracle : http://docs.oracle.com/javase/6/docs/api/
Communauté francophone sur Java : http://java.developpez.com/
Forum référent pour les problèmes rencontrés en Java : http://stackoverflow.com/
Environnement Eclipse - Eclipse RCP
Documentation officielle « The Eclipse Rich Client Platform » publié par IBM (Mark Rogalski) le 20-01-
2005 : http://www.eclipse.org/ercp/RCP-TechPaper.pdf
Documentation sur la plateforme Eclipse : http://help.eclipse.org/juno/index.jsp
Wiki associé à la communauté d’Eclipse : http://wiki.eclipse.org/
Site francophone consacré au projet Eclipse : http://www.eclipsetotale.com
- Présentation d’Eclipse RCP - Publié le 31-03-2006
http://www.eclipsetotale.com/articles/Eclipse_RCP.html
- Développement d’applications Eclipse RCP - Publié le 15-12-2007
http://www.eclipsetotale.com/articles/Developpement_applications_Eclipse_RCP_partie1.html
- Et de nombreuses informations diverses présentes sur le site
Communauté francophone sur Eclipse : http://eclipse.developpez.com/
Site référent de tutoriels sur Eclipse écrits par Lars Vogel : http://www.vogella.com/eclipse.html
Maven et construction de plug-ins avec Tycho
Documentation officielle sur Maven écrite et publié par Sonatype en 2009 : http://maven-guide-
fr.erwan-alliaume.com/maven-reference-fr/site/reference/public-book.html
Le site officiel sur Maven développé et publié par la fondation Apache : http://maven.apache.org/plugins/
Articles sur la construction de plug-ins Eclipse RCP avec Maven 3 et Tycho
- Article écrit et publié par Pascalle Clercq le 14-02-2012 :
http://pascalleclercq.wordpress.com/2010/02/14/construire-ses-plugins-eclipse-rcp-avec-maven-
c%E2%80%99est-plus-facile-maintenant-avec-maven-3-et-tycho/
- Article « Building with Tycho » écrit par Mattias Holmqvist et publié le 11-02-2010 :
http://mattiasholmqvist.se/2010/02/building-with-tycho-part-1-osgi-bundles/
- « Maitriser Tycho de A à Z » par Paul-Emmanuel Faidherbe, le 02-09-2010 :
http://developpef.blogspot.fr/2010/09/maitriser-tycho-de-a-z.html
- « Introduction à Tycho » par Mickael Baron, publié le 28-10-2011 et mis à jour le 25-01-
2013 : http://mbaron.developpez.com/eclipse/introtycho/
Résumé Le Master Informatique de l’Université de Franche-Comté se termine par un stage en entreprise d’une période d’environ six mois qui s’est effectué au sein de la société Smartesting et notamment dans son équipe R&D associée à la solution Smartesting CertifyIt™. Cette expérience est l’occasion de mettre en pratique les compétences acquises tout au long de notre formation initiale tout en abordant de nouvelles notions et concepts. Pour cela, l’axe de travail de ce stage est le développement de « plug-ins » Eclipse afin de maintenir et faire évoluer le produit de la société et ce, en contexte agile. Mots-clés : JAVA, Eclipse, RCP, plug-ins, SWT, JFace, Smartesting CertifyIt™, tests fonctionnels et unitaires, IBM Rational Software Architect® (RSA), UML, OCL, eXtreme Programming (XP), Maven
Abstract The master of Computer at the University of Franche-Comté ends with an internship for a period of approximately six months that was carried out within the company Smartesting, and particularly in its R&D team associated with the Smartesting Certifylt™ solution. This experience is an opportunity to put into practice the skills acquired throughout our initial training while learning new ideas and concepts. For this, the line of work of this internship is the development of Eclipse plug-ins to maintain and develop the company's product in agile context. Keywords : JAVA, Eclipse, RCP, plug-ins, SWT, JFace, Smartesting CertifyIt™, functional and unit testing, IBM Rational Software Architect® (RSA), UML, OCL, eXtreme Programming (XP), Maven
