Le document traite de la réutilisation des exigences à travers l'ingénierie des lignes de produits logiciels, présentée lors de la conférence AOSD 2010. Il met en lumière différents cas de réutilisation des exigences, allant de la duplication à des méthodes plus avancées comme l'ingénierie des lignes de produits logiciels (SPL) et le développement orienté aspects (AOSD). À travers cette approche, l'accent est mis sur l'agilité et la flexibilité nécessaires dans le développement de logiciels complexes.

1. http://www.meito.com/
http://www.irisa.fr/
http://www.aosd.net/2010/
Réutiliser les exigences par l'ingénierie des lignes de
produits logiciel - une étape vers l'AOSD ?
Atelier Meito / IRISA 'Modularité avancée pour l'agilité des systèmes informatiques',
Dans le cadre de la conférence AOSD 2010 à Rennes et Saint Malo
Daniel Lucas-Hirtz
daniel@exibri.com
www.exibri.com
16/03/2010
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel

2. exibri
exibri est un cabinet d'ingénierie
des exigences du logiciel
Fondé en novembre 2009 par Norbert
Khalil et Daniel Lucas-Hirtz, ex
responsables de la définition des
produits chez Mitsubishi puis Motorola
(téléphonie mobile).
Notre expertise:
●
les systèmes complexes avec logiciel,
matériel et mécanique;
●
la gestion de lignes de produits à base de
logiciel (héritage du logiciel, gestion des
changements, gouvernance, etc.).
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 2

3. Contexte
Cœur de métier:
●
informatique industrielle,
●
logiciel embarqué,
●
produits grand public,
●
multimédia et télécom.
Complexité d'un produit:
●
2000 à 10000 tests “système”
●
Nombre similaire d'exigences
“système”
●
Familles de produits (héritage,
évolutions)
Ingénierie d'un produit:
●
20 à 400 personnes,
●
6 mois à 2 ans.
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 3

4. Nos références
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 4

5. Ingénierie des exigences et agilité ?
A "spec" is close to useless. I have _never_ seen a spec that was both
big enough to be useful _and_ accurate.
And I have seen _lots_ of total crap work that was based on specs. It's
_the_ single worst way to write software, because it by definition
means that the software was written to match theory, not reality.
Linus Torvalds,
creator of Linux ( from: Linux: Linus On Specifications)
Forget about locked-in specs. They force you to make big, key
decisions too early in the process. Bypass the spec phase and
you’ll keep change cheap and stay flexible.
37Signals, in "Getting Real",
http://gettingreal.37signals.com/toc.php
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 5

6. L'ingénierie des exigences: c'est quoi ?
Une exigence est l'expression documentée d'un besoin que le
système devra satisfaire.
L'ingénierie des exigences est une discipline de l'ingénierie des
systèmes dont l'objet est d'établir et de maintenir un accord
entre les parties prenantes (équipes d'ingénierie, client, ..) sur
les besoins que le système doit satisfaire.
Ce que le Ce que le Ce que Ce que le Ce que le Ce dont le
client a chef de l'architecte développeur commercial client avait
décrit projet a a conçu a a vendu vraiment
compris programmé besoin
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 6

7. Les stratégies de ré-utilisation du logiciel
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 7

8. L'enquête ExiO
sur l'ingénierie uest 2009
d
disponible sur es exigences
www.exibri.co
m
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 8

9. Les stratégies de ré-utilisation du logiciel
Ré-utilisation du logiciel = agilité du logiciel
“composants agiles” versus “processus agiles”
Les organisations d'ingénierie adoptent différentes stratégies de
réutilisation du logiciel au sein d'une famille de produits:
●
Cas 1: Duplication (des exigences, du code, des tests ..)
●
Cas 2: Delta (on référence un produit “base” et on définit ce
qui change)
●
Cas 3: Plate-forme structurée en “features” ré-utilisables
●
Cas 4: Ingénierie des lignes de produit logiciel “SPLE”: la
variabilité est modélisée explicitement et indépendament des
artefacts de l'ingénierie (exigences, tests, composants, ..).
●
Mais encore: Domain Specific Language (DSL); Model Driven
Engineering (MDE, MDD); Aspect Oriented Software
Development (AOSD) ...
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 9

10. Les stratégies de ré-utilisation du logiciel
●
Cas 1: Duplication (des exigences, du code, des tests ..)
●
Cas 2: Delta (on référence un produit “base” et on définit ce
qui change)
●
Cas 3: Ré-utilisation planifiée de “features”
●
Cas 4: Ingénierie des lignes de produit logiciel “SPLE”: la
variabilité est modélisée explicitement et indépendament des
artefacts de l'ingénierie (exigences, tests, composants, ..).
●
Cas 5: Domain Specific Language (DSL)
●
Cas 6: Aspect Oriented Software Development (AOSD)
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 10

11. Produit unique
Third parties / partners
customer
end user marketing corporate etc.
factory Standards / legal Program /
regulations cust. operation
Exigences d'entrée
Produit
Exigences systèmes Tests systèmes
SysReq SysReq SysReq
SysReq SysReq SysReq Test Test Test Test Test Test
Cardinalité ~= 1000 Cardinalité ~= 1000
Traçabilité “satisfait”
Cardinalité: ~1000
Traçabilité “verifie”
Cardinalité: ~1000
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 9

12. Cas 1: duplication
Third parties / partners
customer
end user marketing corporate etc.
factory Standards / legal Program / Cas 1: Duplic
a
Recopie des a tion :
regulations cust. operation
rtefacts du
projet = ré-ut
ilisation non
planifiée
Exigences d'entrée
Produit
Exigences systèmes Tests systèmes
SysReq SysReq SysReq
SysReq SysReq SysReq Test Test Test Test Test Test
Traçabilité Cardinalité ~= 1000 Cardinalité ~= 1000
“satisfait”
Cardinalité: 10 x
1000 = ~10000
10 produits 10 produits
Cardinalité des exigences Cardinalité des tests
~= 10000 ~= 10000
Traçabilité “verifie”
Cardinalité: ~10000
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 11

13. Cas 1: duplication
Third parties / partners
customer
end user marketing corporate etc.
factory Standards / legal Program / Cas 1: Duplic
a
Recopie des a tion :
regulations cust. operation
rtefacts du
projet = ré-ut
ilisation non
Bénéfices: planifiée
Exigences d'entrée
●
simple à mett
re en oeuvre,
●
pas d'effet de
bord (par con
modification struction la Produit
d'un produit n systèmes
Exigences 'impa
autre produit cte pas un Tests systèmes
).
SysReq SysReq SysReq
SysReq SysReq SysReq Test Test Test Test Test Test
Traçabilité Cardinalité ~= 1000 Cardinalité ~= 1000
Inconvénient
“satisfait” s: avec la m
vCardinalité: 10es
ariantes d x p ultiplication d
roduits: es
● 1000 = ~10000
Explosion des
artefacts de l'produits
10 ingé
(exigences, .. nierie 10 produits
.) Cardinalité des exigences Cardinalité des tests
●
Explosion de ~= 10000 ~= 10000
l'effort de mi Traçabilité “verifie”
de maintenan se en oeuvre
ce et
Cardinalité: ~10000
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 10

14. Les stratégies de ré-utilisation du logiciel
●
Cas 1: Duplication (des exigences, du code, des tests ..)
●
Cas 2: Delta (on référence un produit “base” et on définit ce
qui change)
●
Cas 3: Ré-utilisation planifiée de “features”
●
Cas 4: Ingénierie des lignes de produit logiciel “SPLE”: la
variabilité est modélisée explicitement et indépendament des
artefacts de l'ingénierie (exigences, tests, composants, ..).
●
Cas 5: Domain Specific Language (DSL)
●
Cas 6: Aspect Oriented Software Development (AOSD)
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 14

15. Cas 2: Delta
Third parties / partners
customer
end user marketing corporate etc.
factory Standards / legal Program /
regulations cust. operation
Produit B
Exigences systèmes Tests systèmes
Exigences d'entrée
SysReq
SysReq Test Test
Same as Same as
Delta Delta
Produit A
Exigences systèmes Tests systèmes
SysReq SysReq SysReq
SysReq SysReq SysReq Test Test Test Test Test Test
Cardinalité ~= 1000 Cardinalité ~= 1000
Traçabilité “satisfait”
Cardinalité: ~1000
Traçabilité “verifie”
Cardinalité: ~1000
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 13

16. Cas 2: Delta
C parties partners
Third as 2: /Delta:
customer
●end user marketing corporate
Un produit “B etc.
” es t “
ufactory duStandards / legalbasé” sur/
n pro it “A” Bénéfices:
Program
pré
regulations-excust. operation
istant – ●
qui n'a pas ét Beaucoup plu
é conçu à cet Produit B
s économe qu
effet. eTestsméthode
“duExigences systèmes
plication” la systèmes
Exigences d'entrée
Les différenc
●
Adapté aux ch
angements sTest Test
●
es sont re-dé SysReq
SysReq
imples sur un
explicitement finies base sta
localement. ble (ex. Chan e
téléphone ..) Same as ger la couleur Same as
d'un
●
Ce qui n 'est pas re-dé Delta Delta
localement e fini
st hérité du
produit de ba
se Produit A
Inconvénient Exigences systèmes Tests systèmes
s:
●
GouvernanSysReq SysReq SysReq
ce SysReqpartiesSysReq
des SysReq co Test Test Test Test Test Test
le produit “B” mmunes: com
veut corriger ment faire lo
appartenant àCardinalité ~= 1000 une erreur d'u rsque
“A” ? nCardinalitéo~=a1000
comp s nt
●
Explosion de
la complexité
Traçabilitéa
“satisfait”
ugme lorsque le nom
Cardinalité: ~1000 nte – et lorsque bre des varian
la base évolu tes
e.
Traçabilité “verifie”
Cardinalité: ~1000
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 15

17. Les stratégies de ré-utilisation du logiciel
●
Cas 1: Duplication (des exigences, du code, des tests ..)
●
Cas 2: Delta (on référence un produit “base” et on définit ce
qui change)
●
Cas 3: Ré-utilisation planifiée de “features”
●
Cas 4: Ingénierie des lignes de produit logiciel “SPLE”: la
variabilité est modélisée explicitement et indépendament des
artefacts de l'ingénierie (exigences, tests, composants, ..).
●
Cas 5: Domain Specific Language (DSL)
●
Cas 6: Aspect Oriented Software Development (AOSD)
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 17

18. Cas 3: réutilisation planifiée de “features”
Third parties / partners
customer
end user marketing corporate etc.
factory Standards / legal Program /
regulations cust. operation
Produit 10
Produit ...
Produit 01
Exigences d'entrée
Ligne de produit
Feature 01 Feature 02 Feature N
F-Spec ... F-Tests F-Spec ... F-Tests
SysReq SysReq Test Test Test
SysReq SysReq SysReq Test Test Test
SysReq
Traçabilité “verifie”
Traçabilité “satisfait”
Cardinalité: ~ 2000
~ 50 “features”, ~40 exigences (et tests) par feature,
Cardinalité des exigences système ~= 2000,
Cardinalité des tests système “vérifie” ~= 2000
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 15

19. Cas 3: réutilisation planifiée de “features”
Bénéfices:
Third parties / partners
customer
Cas
end user 3 marketing
: Feature bascorporate ●etc.
Ré-utilisation
e
Standards / legal d re-use:/
factory plus efficace
Les “features regulations
Program
“delta” car la que dans le c
” sont des un réutilisation d
cust. operation as
de ré-utilisatio ités gérée es f10atures es
Produit e
sont gouvérné
n planif iée, qui t Produit ...
e s p a r u ne Produit 01
autorité cExigences d'entrée
ommune à la
de produits. famille Ligne de produit
La “feature”
sert à la fois: Feature 01 Feature 02 Feature N
●
d'unité de str
ucturation de
artefacts de l' s
ingénierie F-Spec ... F-Tests F-Spec ... F-Tests
(exigences, te
sts, code ..)
●
d'unité de com
position du SysReq SysReq Test Test Test
SysReq SysReq SysReq Test Test Test
SysReq
produit (un p
roduit = une
liste de featu
res). Traçabilité “verifie”
Traçabilité “satisfait”
Cardinalité: ~ 2000
~ 50 “features”, ~40 exigences (et tests) par feature,
Cardinalité des exigences système ~= 2000,
Cardinalité des tests système “vérifie” ~= 2000
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 17

20. Cas 3: réutilisation planifiée de “features”
InconThird partiest/ partners customer néfices:
vénien Bé
end user 3 marketing s: corporate
●Cas
La :“featuree” sed re-use:●etc. Ré-utilisatio
Fea
tur ba s port
factory e deux contra n plus efficace que d
Standards / legalupProgram /
Les “featnité de défin operation “delta” cainla s:
u ure r te réutilisat ans le cas
✔ regulations
it ité
cust.
s” sont des union de la
va ionProduit f10atu
des e
prod ion pla
de ré-utilisatuit) s gérée riabilité (unité
nifié dProduitmpositio res est
e co ...
unité ese ar ruc e, qui
sont✔ gouvérné
d pd'entrée turat
s t u ne Produit 01
n du
d'évolution laofamille ion des spec, des tests, d
autorité cExigences
ommune à
de produits. f nctionnelle de produit
Ligne u code (et do
de la plate-fo nc unité
rme dans le t
La “Diffuce”té maje
●
feat i r ul sert
emps).
ure
●
d'une e st tucrà la fois:: le “featFeature coping”Feature 02
d'unité dfear u
ter(eion deses
ure s 01 : comment dé
Feature N
u at t de s finir la portée
artéfaets de l'
d e p cndancegénierie points de vari
(exigences, te
in s ass
ociées pour p
F-Spec a
... F-Teststion inte F-Spec ... F-Tests
rne) ainsi que
“dan l vrsts, de ermett u les
●
d'unité s e a omaie coie”..)
d c positio v . SysReq SysReq Test TesteTestne ré-SysReq ation Test Test Test
utilis SysReq eff
produit (un p n du SysReq SysReq icace
●
R e d u f : turoduit
listisqe eeamultip = une
res). lication de
fonctionnalité s features en Traçabilité “verifie”
Traçabilité “satisfait” en réponse à d
tant qu'incrém
fait pas r~ 2000 es besoins clie ents de
Cardinalité: é-utilisables. nt - mais qui
cas 2 “Delta” Risque d'arriv ne soient en
. er à une expl
otests) si feature,
~ 50 “features”, ~40 exigences (et sionpar milaire
Cardinalité des exigences système ~= 2000,
au
Cardinalité des tests système “vérifie” ~= 2000
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 18

21. Les stratégies de ré-utilisation du logiciel
●
Cas 1: Duplication (des exigences, du code, des tests ..)
●
Cas 2: Delta (on référence un produit “base” et on définit ce
qui change)
●
Cas 3: Ré-utilisation planifiée de “features”
●
Cas 4: Ingénierie des lignes de produit logiciel “SPLE”: la
variabilité est modélisée explicitement et indépendament des
artefacts de l'ingénierie (exigences, tests, composants, ..).
●
Cas 5: Domain Specific Language (DSL)
●
Cas 6: Aspect Oriented Software Development (AOSD)
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 21

22. Cas 4: Ingénierie des lignes de produit logiciel “SPLE”
L'AOSD (“Aspects Oriented Software Development), les “Languages spécifique
de domaine” (DSL), et le “SPLE” (L'ingénierie des lignes de produit logiciel) sont
des mécanismes de modularité du logiciel qui tentent d'apporter des réponses à
ces difficultés de la réutilisation des “features” entre les membre d'une famille
de produit.
Ci-dessous une introduction à l'ingénierie des lignes de produit logiciel (option
“feature model”). L'idée de base du SPLE: séparer la modélisation de la
variabilité de la structuration des composants de l'ingénierie:
key principles behind software product
line engineering (see [Pohl2005]):
(1) the separation of software development
in two distinct processes, domain and
application engineering;
(2) the explicit definition and management
of the variability of the product line
across all development artifacts.
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 22

23. SPLE - Software product line engineering
feature modeling Engineering artefact modeling
(problem domain) (solution domain)
Domain
engineering
(platform
level)
key principles behind software product
line engineering (see [Pohl2005]):
(1) the separation of software development
Application in two distinct processes, domain and
engineering
(product application engineering;
customization)
(2) the explicit definition and management
of the variability of the product line
across all development artifacts.
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 23

24. SPLE – Software product line engineering
feature modeling Engineering artefact modeling
(problem domain) (solution domain)
1 Exigences ré-utilisables
2
Domain
engineering
Test cases ré-utilisables
(platform
level)
Feature model
etc.
3 4
Application Spécifications des exigences
engineering du produit
(product
customization) Variant description model
(i.e. choices in the Plan de test du produit
feature model)
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 24

25. 1 Construire le “feature model”
feature modeling Engineering artefact modeling
(problem domain) (solution domain)
1
Domain
engineering
(platform
level)
Feature model
Étape 1: exprimer la structure
Application et la variabilité de la famille de produit
engineering
(product
customization)
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 25

26. 1 Rôle du “feature model”
Feature model: Mandatory
1) structurer la famille de produit
2) définir les points de variation – et les variantes Optional
associées
(d'un point de vue “système” - i.e. “boîte noire”). Alternative
Or
MobilePhone
(source [Wikip_FM] et [Beuche2004])
SW SW_Packages HW Mecha
MMDIA CNX ... PIM Camera ... Chipset FormFactor Screen
Imager MediaPlayer Autofocus Resolution XA1 XA2 ZB3 CandyBar Clam Tablet
AppCam VidRec 2MP 5MP 8MP 12MP
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 25

27. 1 Définition des dépendances
Exprimer les dépendances entre les variantes. Conflicts
Par exemple la fonction “autofocus”, qui est un
équipement optique volumineux, est ici incompatible Requires
avec le form factor “CandyBar”.
MobilePhone
SW SW_Packages HW Mecha
MMDIA CNX ... PIM Camera ... Chipset FormFactor Screen
Imager MediaPlayer Autofocus Resolution XA1 XA2 ZB3 CandyBar Clam Tablet
AppCam VidRec 2MP 5MP 8MP 12MP
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 26

28. 1 Définition du feature model
Exemple de mise en oeuvre
du “feature model” avec
l'outil de gestion des variantes
“pure::variants”
(http://www.pure-systems.com)
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 27

29. 2 Construire les artefacts réutilisables de l'ingénierie
feature modeling Engineering artefact modeling
(problem domain) (solution domain)
Exigences ré-utilisables
2
Domain
engineering
Test cases ré-utilisables
(platform
level)
etc.
Étape 2
Application Organiser et construire les artefacts réutilisables
engineering de l'ingénierie (exigences, tests, composants ..)
(product
customization)
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 29

30. 2 feature versus feature
Mandatory
Optional
“Core assets tree”
Alternative Structure les artefacts ré-utilisables
Or de l'ingénierie par “composants”
(parfois appelés “Features” ! )
MobilePhone
Composant 01
SW HW
F-Spec ... Cmp. “Camera”
F-Tests
MMDIA CNX ... PIM Camera
F-Spec ...
SysReq SysReq Test Test Test
SysReq Composant N
F-Tests
Imager MediaPlayer AutofocusResolution F-Spec ...
SysReq SysReq Test Test Test
SysReq F-Tests
SysReq SysReq Test Test Test
SysReq
AppCam VidRec 2MP 5MP 8MP
Feature model : Core assets tree :
1. Express the variability 2. Organise the engineering artefacts
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 30

31. 2 Exigences
Spécifications des exigences du composant
(ici le composant “Camera”)
Feature
model
The link between the feature model (above)
and the Technical Requirements Specification
document (on the right) can be made
“manually” (as depicted here).
It can also be implemented by a tool – so that
the relevant specification document is generated by
a tool based on a variant model (demo possible).
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 31

32. 2 Tests
Test suite (composant “Camera”)
Feature
model
The test plan is linked with
the feature model, so that
the product specific test plan can
be generated from the variant model.
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 32

33. 2 “Verify” traceability
Spécifications des exigences du composant
Suite de tests (composant “Camera”)
(ici le composant “Camera”)
“verify” traceabilty (ie. tests to requirements)
is maintained at “Camera” component level.
Implementation can be implemented within
A dedicated tool (“DOORS”, “QualityCenter” ...)
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 33

34. 2 “Satisfy” traceability
Spécifications des exigences du composant
Exigences client
(ici le composant “Camera”)
Third parties / partners customer
end user marketing corporate
factory Standards / legal etc.
regulations
Program /
cust. operation
“satisfy” traceabilty (ie. Feature technical
requirements to customer requirements) is
maintained at “Camera” component level.
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 34

35. 3 Choisir les variantes du produit
feature modeling Engineering artefact modeling
(problem domain) (solution domain)
Domain
engineering Étape 3 :
(platform “variant modeling”:
level) Le produit est défini par le choix d'une variante pour
chaque point de variation du “feature model”
3
Application
engineering
(product
customization) Variant description model
(i.e. choices in the
feature model)
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 35

36. 3 Variant modelling
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 36

37. 4 Solution binding – générer le produit
feature modeling Engineering artefact modeling
(problem domain) (solution domain)
Domain
engineering
(platform Étape 4:
level) “solution binding” -
généreraton des artefacts du produit.
4
Application Spécifications des exigences
engineering du produit
(product
customization)
Plan de test du produit
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 37

38. 4 Solution binding
feature modeling Engineering artefact modeling
(problem domain) (solution domain)
1
domain
engin-
eering
(plat-
form
level)
applica-
tion
engin-
eering
(product
customi-
zation)
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 38

39. 4 Solution binding
feature modeling Engineering artefact modeling
(problem domain) (solution domain)
1 2
domain
engin-
eering
(plat-
form
level)
applica-
tion
engin-
eering
(product
customi-
zation)
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 39

40. 4 Solution binding
feature modeling Engineering artefact modeling
(problem domain) (solution domain)
1 2
domain
engin-
eering
(plat-
form
level)
3
applica-
tion
engin-
eering
(product
customi-
zation)
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 40

41. 4 Solution binding
L'ensemble de
s arte
feature modeling fa
l'ingénierie pe domain) cts de
Engineering artefact modeling
(problem (solution domain)
ut être
généré de la
sorte:
●
Spécification
domain exig
des 1 2
engin-
ences,
eering T sts,e
●
(plat-
form
●
Composants,
level) etc.
●
3 4
applica- Transformation
tion can
engin- be
eering either
(product manual
customi- or
zation) automatic
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 41

42. SPLE Benefits 1 : Reduced costs of development
(From [Pohl2005])
g
r in
Accumulated ee
g in
costs en
ct
ro du
p
gle
Sin
Break-even g
gineerin
point produc t line en
Up-front Software
investment
Lower cost per
product
Approx. 3 systems Nb. of products
(sw engineering)
Cost reduction is typically an essential reason for introducing product line
engineering. Efficient re-use decreases global cost.
Empirical investigations reveals that – for software - approximately three products
are necessary before the Software Product Line Engineering is beneficial.
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 41

43. SPLE Benefits 2 : Enhancement of quality
(From [Pohl2005])
●
Because they are build for re-use, the platform artifacts are defined,
designed, coded, reviewed an tested more thoroughly
●
Because the concept promotes re-use and restrict product specific changes,
the quantity of “product specific” artifacts is reduced.
●
Further, the “product specific” team is very well aware of what is re-used
within platform agreed context versus and what is new or re-used outside
what the platform had planed. Therefore product specific verification can be
more easily focused on a smaller set of changed SW artefacts.
●
For all the reasons above, there is a significantly higher chance of detecting
faults in a software product line context.
●
Last, fixing a fault on a platform asset is easier than in a tree of “copied and
slightly changed” code files → better chance to have fixes propagated to the
relevant target products.
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 42

44. SPLE Benefits 3 : Reduction of time to market
(From [Pohl2005])
Time for
building Single product engineering
Time to
Market for common Software product line engineering
one product artifacts
Shorter development
cycle due to reuse
Nb. of products
[Pohl2005] states that the initial time to market is higher, as common artifacts
have to be build first.
After having passed this hurdle, the time to market is considerably shortened as
many artifacts can be re-used for each new product.
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 43

45. Additional benefits
[Pohl2005] proposes further benefits :
●
Reduced maintenance effort – because assets are re-used
●
Facilitated evolution – because evolution management is core process
of the product line engineering
●
Improved ability to cope with increasing complexity
●
Improved (faster, safer) new product cost (and feasibility) evaluation
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 44

46. exibri
Processus SPLE : [Pohl2005]
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 46

47. exibri
Processus SPLE : ConIPF methodology [ConIPF2006]
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 47

48. Outils
Les outils d'ingénierie des lignes de produits logiciel permettent:
1 de modéliser la variabilité et les dépendances dans le “feature
●
model”
2 de modéliser le “solution domain” (exigences, code, tests) et leurs
●
dépendances avec les variantes du feature model
3 de vérifier la validité d'une variante de produit
●
4 De générer les composants produits (exigences, code, tests) à partir
●
de la variante de produit
Exemples d'outils:
●
pure::variants (commercial, http://www.pure-systems.com )
●
GEARS (commercial, http://www.biglever.com/ )
Études et comparaisons:
●
Chapter 14 of [ConIPF2006]
●
“Hataichanok 2008 - Comparison of Variability Modeling and
Configuration Tools for Product Line Architecture”
●
Simon Chong, 2008, Nasa report, “An Evaluation Report for Three
Product-Line Tools (Form, Pure::Variants and Gear)”
http://sarpresults.ivv.nasa.gov/DownloadFile/134/14/3_Product_Line_Verification_Tools.pdf
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 47

49. Les stratégies de ré-utilisation du logiciel
●
Cas 1: Duplication (des exigences, du code, des tests ..)
●
Cas 2: Delta (on référence un produit “base” et on définit ce
qui change)
●
Cas 3: Ré-utilisation planifiée de “features”
●
Cas 4: Ingénierie des lignes de produit logiciel “SPLE”: la
variabilité est modélisée explicitement et indépendament des
artefacts de l'ingénierie (exigences, tests, composants, ..).
Mais encore: Domain Specific Language (DSL); Model Driven
Engineering (MDE, MDD); Aspect Oriented Software Development
(AOSD) ...
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 49

50. References
[Pohl2005]
Pohl, K., Böckle, G. & Linden, F. J. v. d. (2005). “Software Product Line Engineering:
Foundations, Principles and Techniques”. Springer.
[Obbink 2005] H. Obbink and K. Pohl(Eds.). Software product lines - 9th Inter-national
Conference, SPLC2005, Rennes, France. Springer-Verlag, 9. edition, 2005.
[Beuche 2004] Danilo Beuche - Variability management with feature models
[Wikip_FM] http://en.wikipedia.org/wiki/Feature_model
[CoonIPF 2006] “Configuration in Industrial Product Families - The ConIPF
Methodology” Authors: L. Hotz, K. Wolter, T. Krebs, S. Deelstra, M. Sinnema, J. Nijhuis
and J. MacGregor. Infix. September 2006
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 50

51. Questions ?
Me rc i !
Daniel Lucas-Hirtz
daniel@exibri.com
Retrouvez cette présentation sur www.exibri.com www.exibri.com
Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
Page 51