Exibri Software Product Lines Aosd

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

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.).

Page 2

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.

Page 3

Nos références

Page 4

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

Page 5

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

Page 6

Les stratégies de ré-utilisation du logiciel

Page 7

L'enquête ExiO
sur l'ingénierie uest 2009
d
disponible sur es exigences
www.exibri.co
m

Page 8


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) ...
Page 9


●
●
qui change)
●
Cas 3: Ré-utilisation planifiée de “features”
●
●
Cas 5: Domain Specific Language (DSL)
●
Cas 6: Aspect Oriented Software Development (AOSD)

Page 10

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

Page 9

Cas 1: duplication
customer
factory Standards / legal Program / Cas 1: Duplic
a
Recopie des a tion :
rtefacts du
projet = ré-ut
ilisation non
planifiée
Exigences d'entrée

Produit


Traçabilité Cardinalité ~= 1000 Cardinalité ~= 1000
“satisfait”
Cardinalité: 10 x
1000 = ~10000
10 produits 10 produits
Cardinalité des exigences Cardinalité des tests
~= 10000 ~= 10000
Cardinalité: ~10000

Page 11

Cas 1: duplication
customer
factory Standards / legal Program / Cas 1: Duplic
a
Recopie des a tion :
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
).

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

Page 10


●
●
qui change)
●
●
●
●

Page 14

Cas 2: Delta
customer
Produit B
Exigences d'entrée
SysReq
SysReq Test Test

Same as Same as

Delta Delta

Produit A


Cardinalité ~= 1000 Cardinalité ~= 1000

Cardinalité: ~1000
Cardinalité: ~1000

Page 13

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.
Cardinalité: ~1000

Page 15


●
●
qui change)
●
●
●
●

Page 17

Cas 3: réutilisation planifiée de “features”

customer
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

Cardinalité: ~ 2000

~ 50 “features”, ~40 exigences (et tests) par feature,
Cardinalité des exigences système ~= 2000,
Cardinalité des tests système “vérifie” ~= 2000

Page 15


Bénéfices:
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”
Cardinalité: ~ 2000

~ 50 “features”, ~40 exigences (et tests) par feature,

Page 17


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
au

Page 18


●
●
qui change)
●
●
●
●

Page 21

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.

Page 22

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.

Page 23

SPLE – Software product line engineering


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)

Page 24

1 Construire le “feature model”


1
Domain
engineering
(platform
level)
Feature model

Étape 1: exprimer la structure
Application et la variabilité de la famille de produit
engineering
(product
customization)

Page 25

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

Page 25

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

Page 26

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)

Page 27

2 Construire les artefacts réutilisables de l'ingénierie


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)

Page 29

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 Composant N
F-Tests

Imager MediaPlayer AutofocusResolution F-Spec ...
SysReq F-Tests

SysReq
AppCam VidRec 2MP 5MP 8MP

Feature model : Core assets tree :
1. Express the variability 2. Organise the engineering artefacts

Page 30

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).

Page 31

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.

Page 32

2 “Verify” traceability
Suite de tests (composant “Camera”)

“verify” traceabilty (ie. tests to requirements)
is maintained at “Camera” component level.
Implementation can be implemented within
A dedicated tool (“DOORS”, “QualityCenter” ...)

Page 33

2 “Satisfy” traceability
Exigences client

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.

Page 34

3 Choisir les variantes du produit


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)

Page 35

3 Variant modelling

Page 36

4 Solution binding – générer le produit


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

Page 37

4 Solution binding


1
domain
engin-
eering
(plat-
form
level)

applica-
tion
engin-
eering
(product
customi-
zation)

Page 38

4 Solution binding


1 2
domain
engin-
eering
(plat-
form
level)

applica-
tion
engin-
eering
(product
customi-
zation)

Page 39

4 Solution binding


1 2
domain
engin-
eering
(plat-
form
level)

3
applica-
tion
engin-
eering
(product
customi-
zation)

Page 40

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

Page 41

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.

Page 41

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.

Page 42

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.

Page 43

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

Page 44

exibri
Processus SPLE : [Pohl2005]

Page 46

exibri
Processus SPLE : ConIPF methodology [ConIPF2006]

Page 47

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
Page 47


●
●
qui change)
●
●
Mais encore: Domain Specific Language (DSL); Model Driven
Engineering (MDE, MDD); Aspect Oriented Software Development
(AOSD) ...

Page 49

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

Page 50

Questions ?

Me rc i !
Daniel Lucas-Hirtz
daniel@exibri.com
Retrouvez cette présentation sur www.exibri.com www.exibri.com

Page 51

Exibri Software Product Lines Aosd

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie Exibri Software Product Lines Aosd

Ähnlich wie Exibri Software Product Lines Aosd (20)

Mehr von Cédric WILLIAMSON

Mehr von Cédric WILLIAMSON (11)

Exibri Software Product Lines Aosd