Des sensibilit´es de gestion de LdP

a-d. correspondant `a de la gestion de configuration. Alors que la plupart des syst`emes de gestion de configuration (software configuration management - SCM ) [Bab86], par ex. [FB03, Loe09, Pil04], cible plus particuli`erement les documents textuels tels que le code source, les fichiers binaires, des syst`emes de gestion de configuration sp´ecifiques ont vu le jour pour les mod`eles de l’IDM. Aizenbud-Reshef et al. [ARNRSG06a] discutent de l’´etat de l’art de la tra¸cabilit´e dans les d´eveloppements de mod`eles et des moyens de ges-tion de configurages-tion. Ducasse et al. [DGF05] donnent la d´efinition suivante : une version est un clich´e d’une entit´e `a un moment particulier. L’´evolution est le processus qui m`ene d’une version `a une autre. L’historique est la r´eification du concept d’encapsulation de la connaissance sur l’´evolution et la version.

❼ Une variabilit´e `a r´esoudre dans le temps, c.-`a-d. li´ee `a la d´erivation de produits dans un contexte de ligne de produits. Cette notion a ´et´e abord´ee dans le chapitre3.

4.4.3 Des sensibilit´es de gestion de LdP

L’adoption d’une ligne de produits est abord´ee dans plusieurs travaux [CN01, WL99, Bos00,

Bos02, SV02], ´evoquant les degr´es de maturit´e de l’organisation pour la mise en œuvre de la structure de ligne de produits. L’adoption est relative `a l’´el´evation syst´ematique d’une organisa-tion d’un ´etat de foncorganisa-tionnement en projets ou affaires `a un ´etat de sophistication plus avanc´e. Cette phase d’institution est un cas particulier de changement de technologie de par son impact fort sur l’organisation des ´equipes (raffinement du CONOPS4 - concept of operations, remise en cause du savoir-faire). L’adoption se doit d’ˆetre planifi´ee et de prendre en consid´eration les actifs logiciels existants (legacy). Les coˆuts, risques, et ressources forment classiquement une barri`ere prohibitive `a l’adoption de la ligne de produits [Kru02]. Le lancement peut ˆetre de type ´evolu-tionnaire (sur la base de l’existant) ou r´evolu´evolu-tionnaire (en faisant table rase de l’existant) selon Simon et Eisenbarth [SE02]. Clements et Krueger [CK02] classent les lignes de produits existantes en trois cat´egories : extractive, r´eactive ou proactive.

La figure 4.3 issue de [SV02] pr´esente deux graphiques d’investissements, la partie (a) fait r´ef´erence `a l’approche proactive, ´egalement nomm´ee “big bang” et la partie (b) fait apparaˆıtre l’approche incr´ementale r´eactive.

Proactive

Dans le mod`ele proactif, une organisation r´ealise un investissement d’entr´ee ´elev´e pour d´eve-lopper des ´el´ements r´eutilisables (architecture, Core Assets) et par la suite, sur la base de ces

4description haut niveau de la structure organisationnelle et description de la conduite des affaires (processus m´etier).

4.4. ´Evolution d’une ligne de produits

Figure4.3: Graphiques d’investissement - adoption d’une LdP [SV02] : (a) approche proactive, incluant des risques ; (b) proactive vs. r´eactive.

d´eveloppements, les produits peuvent ˆetre r´ealis´es. Ce type d’approche est effectif pour des lignes de produits dans des domaines matures et stables, o`u les features peuvent ˆetre pr´edits. Elle se pr´esente comme l’approche en cascade des d´eveloppements logiciels conventionnels, `a savoir que toutes les variations des produits `a un horizon d´efini sont analys´ees, incluses dans l’architecture, con¸cues et impl´ement´ees avant toute r´ealisation de produit. Le mod`ele proactif peut engendrer des impr´ecisions dans la variabilit´e fournie, les features pr´edits pour les futurs produits n’´etant pas adapt´es et finalement d´esir´es. Le coˆut d’entr´ee est cons´equent, il est inutile de rappeler que toute r´ealisation pour la r´eutilisation voit son coˆut augmenter (en moyenne 30% de plus pour des composants r´eutilisables que pour un d´eveloppement unique [Pou96].

Une LdP configurable (“configurable software product family” [CN01]) correspond `a une ap-proche proactive totale, o`u le besoin de d´eveloppement sp´ecifique pour la r´ealisation d’un produit est minime voir nul. Les exigences de r´ealisation du produit sont dans ce cas couvertes en totalit´e (ou quasi-totalit´e) par la ligne de produit.

R´eactive

Dans le mod`ele r´eactif, les ´el´ements r´eutilisables sont d´evelopp´es au fil du temps quand les opportunit´es de r´eutilisations ´emergent. Cette approche est plus pragmatique et adapt´ee aux domaines o`u les features ne peuvent ˆetre pr´edits par avance. Bien que cette approche ne n´ecessite pas d’investissement trop cons´equent, le coˆut de r´e-ing´enierie et restructuration peut ˆetre ´elev´e sans une base architecturale adapt´ee. L’approche r´eactive, pour certains aspects, se rapproche d’une approche de d´eveloppement en spirale ou d’extreme programming.

Extractive

Une derni`ere approche propos´ee dans [Kru06], appel´ee mod`ele extractif, oscille entre le proactif et le r´eactif. L’approche extractive r´eutilise un ou plusieurs produits existants pour construire le cadre initial de la Ligne de Produits. Cette approche peut ˆetre effective pour une organisation ayant accumul´e des exp´eriences et artefacts de d´eveloppement dans un domaine, et voulant rapidement r´ealiser une transition des d´eveloppements conventionnels aux lignes de produits. Concernant le retour sur investissement, Krueger va plus loin et d´efend que l’adoption de la ligne de produits logicielle peut ˆetre b´en´eficiaire depuis la premi`ere application r´ealis´ee, si l’approche est introduite incr´ementalement.

L’´evolution qui en d´ecoule

Bien que la variabilit´e de la ligne de produits et de ses core assets anticipe certains changements dans l’espace (diff´erents produits) et dans le temps (diff´erentes versions de produits), tous ne peuvent ˆetre pr´edits et inclus dans la ligne de produits.

Les lignes de produits adopt´ees sur un mod`ele proactif tendent `a conserver ce mode et `a ´evoluer de mani`ere proactive ´egalement (aucune r`egle n’impose cet ´etat de fait, et la logique de la premi`ere loi de Lehman [Leh80] qui dicte que l’´evolution est in´evitable, mais difficilement pr´edictible, sugg`ere plutˆot une approche r´eactive). Dans la pratique, les approches proactives reposent sur un processus rigoureux de planification de l’´evolution [MSG96,VDG08,VDJ10,BPD+10].

Les approches r´eactives sont principalement abord´ees, soit sous l’angle processus et par l’agi-lit´e [HF08,GAM10,ZSP+11], soit par des approches d’impl´ementation (Clegg et al. [CKM02] se reposent sur la fabrique abstraite pour g´erer l’incr´ementalit´e). De mˆeme, Mende et al. [MBKM08] pr´esentent un support outill´e `a l’approche “grow-and-prune”5 de [FV03] (identification et refac-toring de code cr´ee par actions de copier/coller, qui r´ealise donc une remont´ee du niveau produit au niveau LdP). Ce type d’approche minimise les risques de d´eveloppement mais maximise son entropie.

Dans [DSB09], Deelstra et al. introduisent une phase d’´evaluation de la variabilit´e pour r´e-pondre `a l’´evolution de celle-ci. Une analyse comparative de la variabilit´e pr´esente et requise est r´ealis´ee dans l’environnement COVAMOF. La remont´e d’information depuis l’ing´enierie de l’application vers le domaine se trouve ´egalement au centre des travaux de Heider [HR10].

De mani`ere g´en´erale, l’´evolution dans les lignes de produits est trait´ee : (i) par la mise en œuvre de cadres techniques (par ex. [DNGR08b,DNGR08a] bas´ee sur des m´etamod`eles et [DGRN10] autour des diff´erents espaces de mod´elisations), (ii) en se basant sur de la tra¸cabilit´e (par ex. : [RP01] permet une gestion des changements, du refactoring et de la reconfiguration ; [AK08] propose des m´ecanismes couvrant quatre strat´egies, l’identification du changement, d´ecouverte de l’impact du changement, de la propagation du changement et de la validation de celui-ci), (iii) par des travaux sur la surveillance et la visualisation des changements [TAS07, HRDG09], (iv) par la gestion de version [TM11], (v) par l’analyse de l’´evolution plus particuli`ere des mod`eles de variabilit´e [DSB09, BPD+10, Liv11], (vi) par le traitement de l’´evolution par l’architecture (par ex. [Mac02, DLS05]) et l’´evaluation de l’architecture pour appr´ecier sa modifiabilit´e (par ex. HoPLAA [OM07] ou EATAM [KKKL08]), (vii) enfin par l’analyse de retours d’exp´erience [Bos99,Mac02,EDL10].

Pour conclure, il est `a souligner que l’´evolution incr´ementale des core assets et de la ligne de produits introduit des possibilit´es d’incoh´erence devant ˆetre g´er´ees convenablement [LHET+10]. Cette v´erification peut faire appel `a une analyse des impacts li´es au changement, qui est d´efinie comme l’identification de cons´equences potentielles `a un changement, ou `a l’estimation de ce qui doit ˆetre modifi´e pour accomplir ce changement [BA96,Boh02].

4.5 Discussion et synth`ese

La ligne de produits se d´emarque des d´eveloppements par projet par une commonalisation d’acti-vit´es et d’artefacts. Sur le plan du processus, la dualit´e des ing´enieries (Domaine et Application) est caract´erisante. Les approches de la litt´erature font la part belle `a l’ing´enierie du Domaine, `a l’analyse et la mod´elisation de la variabilit´e, ainsi qu’`a la conception du domaine, en d´elaissant quelque peu la phase de d´erivation des produits. Au del`a du processus, des sp´ecificit´es r´esident

5selon Faust et Verhoef [FV03], la LdP oscille entre (i) une phase de croissance (“grow”) libre, qui entraˆıne un ph´enom`ene de mitose logicielle de part l’abondance de clones et de variants, et (ii)) d’´elagage (“prune”), qui supprime les branches inutiles.

4.5. Discussion et synth`ese

´egalement dans la gestion de l’architecture des lignes de produits. N´eanmoins, similairement aux d´eveloppement d’applications monolithiques, la ligne de produits est soumise `a des variations externes, l’amenant irr´em´ediablement (premi`ere loi de Lehman [Leh80]) `a ´evoluer : changement d’exigences utilisateurs, d’environnement d’ex´ecution, etc..

Au vu de la grande long´evit´e des syst`emes cibl´es, une prise en compte de ces changements ´emergents est primordiale. Dans la confrontation avec ce probl`eme, deux strat´egies semblent viables :

❼ chercher `a minimiser la quantit´e de changements n´ecessaire pour supporter l’´evolution, cette perspective r´eside dans l’absorption de ceux-ci par l’architecture du syst`eme ; ❼ ´etudier les possibilit´es pour minorer la complexit´e additionnelle requise pour soutenir cette

´evolution, cette autre voie reposant sur la compr´ehension et l’explicitation des artefacts manipul´es, et sur une gestion de l’´evolution, de mani`ere proactive et planifi´ee, ou r´eactive. B 4. L’´evolution des lignes de produits requiert une compr´ehension et donc une explicitation des artefacts manipul´es dans le processus, leur positionnement, interactions et d´ependances.

La ligne de produits doit traiter l’´evolution comme une normalit´e et non une anomalie [DNGR08b]. L’´evolution est in´evitable, mais difficilement pr´edictible, donc assurer un proces-sus de modification favorisant la r´eactivit´e est pr´ef´erable.

Ce chapitre r´epond `a QR2 et `a QR3, et se faisant couvre la sous interrogation : qu’est ce que l’architecture d’une ligne de produits ?