exibri software product lines aosd

Réutilisation des exigences par l'ingénierie des lignes de produit logiciel

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 [email protected] 16/03/2010

http://www.meito.com/http://www.irisa.fr/ http://www.aosd.net/2010/

mailto:[email protected]

http://www.exibri.com/

http://www.meito.com/

http://www.irisa.fr/

http://www.aosd.net/2010/


exibri

exibri est un cabinet d'ingénieriedes 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.).


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.


Nos références


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, keydecisions too early in the process. Bypass the spec phase andyou’ll keep change cheap and stay flexible.

37Signals, in "Getting Real", http://gettingreal.37signals.com/toc.php

http://gettingreal.37signals.com/toc.php


L'ingénierie des exigences: c'est quoi ?

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 client a décrit

Ce que le chef de projet a compris

Ce que l'architecte

a conçu

Ce que le développeur

a programmé

Ce que le commercial

a vendu

Ce dont le client avait vraiment besoin

Une exigence est l'expression documentée d'un besoin que le système devra satisfaire.


Les stratégies de ré-utilisation du logiciel


L'enquête ExiOuest 2009sur l'ingénierie des exigences disponible sur www.exibri.com



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



● 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


● Cas 5: Domain Specific Language (DSL)● Cas 6: Aspect Oriented Software Development (AOSD)


Produit unique

Page 9

end user

factory Standards / legal regulations

corporatemarketing etc.

Third parties / partnerscustomer

Traçabilité “satisfait”Traçabilité “satisfait”Cardinalité: ~1000Cardinalité: ~1000

Traçabilité “verifie”Traçabilité “verifie”Cardinalité: ~1000Cardinalité: ~1000

Program / cust. operation

Exigences d'entrée

Exigences systèmes

SysReqSysReqSysReqSysReqSysReqSysReq

Cardinalité ~= 1000

Produit

Tests systèmes

Test Test Test Test Test Test



Cas 1: duplication

Page 11

end user





Exigences d'entrée

Exigences systèmes



Produit

Tests systèmes


Cardinalité ~= 1000Traçabilité Traçabilité “satisfait”“satisfait”Cardinalité: 10 x Cardinalité: 10 x 1000 = ~100001000 = ~10000


10 produitsCardinalité des exigences

~= 10000

10 produitsCardinalité des tests

~= 10000

Cas 1: Duplication :Recopie des artefacts du projet = ré-utilisation non planifiée


Cas 1: duplication

Page 10

end user





Exigences d'entrée

Exigences systèmes



Produit

Tests systèmes


Cardinalité ~= 1000Traçabilité Traçabilité “satisfait”“satisfait”Cardinalité: 10 x Cardinalité: 10 x 1000 = ~100001000 = ~10000


10 produitsCardinalité des exigences

~= 10000

10 produitsCardinalité des tests

~= 10000

Cas 1: Duplication :Recopie des artefacts du projet = ré-utilisation non planifiéeBénéfices: ● simple à mettre en oeuvre,● pas d'effet de bord (par construction la modification d'un produit n'impacte pas un autre produit).

Inconvénients: avec la multiplication des variantes des produits:● Explosion des artefacts de l'ingénierie (exigences, ...)● Explosion de l'effort de mise en oeuvre et de maintenance


Cas 2: Delta

Page 13

end user




Traçabilité “satisfait”Cardinalité: ~1000

Traçabilité “verifie”Cardinalité: ~1000


Exigences d'entrée

Exigences systèmes



Produit A

Tests systèmes



Exigences systèmes

SysReqSysReq

Delta

Produit B

Tests systèmes

Test Test

Same as

Delta

Same as


Cas 2: Delta

Page 15

end user




Traçabilité “satisfait”Cardinalité: ~1000

Traçabilité “verifie”Cardinalité: ~1000


Exigences d'entrée

Exigences systèmes



Produit A

Tests systèmes



Exigences systèmes

SysReqSysReq

Delta

Produit B

Tests systèmes

Test Test

Same as

Delta

Same as

Cas 2: Delta:● Un produit “B” est “basé” sur un produit “A” pré-existant – qui n'a pas été conçu à cet effet.

● Les différences sont re-définies explicitement localement.● Ce qui n'est pas re-défini localement est hérité du produit de base

Bénéfices: ● Beaucoup plus économe que la méthode “duplication”● Adapté aux changements simples sur une base stable (ex. Changer la couleur d'un téléphone ..)

Inconvénients:● Gouvernance des parties communes: comment faire lorsque

le produit “B” veut corriger une erreur d'un composant appartenant à “A” ?● Explosion de la complexité lorsque le nombre des variantes augmente – et lorsque la base évolue.


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

Page 15

end user




Traçabilité “satisfait”Traçabilité “satisfait”Cardinalité: ~ 2000Cardinalité: ~ 2000

Traçabilité “verifie”Traçabilité “verifie”


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

Cardinalité des tests système “vérifie” ~= 2000

Exigences d'entrée

Ligne de produit

Produit 10Produit ...

Produit 01

Feature 01

TestTestTest

F-Tests

SysReqSysReqSysReq

F-Spec ...

Feature N

SysReqSysReqSysReq TestTestTest

F-TestsF-Spec ...

Feature 02



Page 17

end user









Exigences d'entrée

Ligne de produit


Produit 01

Feature 01

TestTestTest

F-Tests

SysReqSysReqSysReq

F-Spec ...

Feature N


F-TestsF-Spec ...

Feature 02

Cas 3: Feature based re-use:Les “features” sont des unités de ré-utilisation planifiée, qui sont gouvérnées par une autorité commune à la famille de produits.

La “feature” sert à la fois:● d'unité de structuration des artefacts de l'ingénierie (exigences, tests, code ..) ● d'unité de composition du produit (un produit = une liste de features).

Bénéfices: ● Ré-utilisation plus efficace que dans le cas “delta” car la réutilisation des features est gérée



Page 18

end user









Exigences d'entrée

Ligne de produit


Produit 01

Feature 01

TestTestTest

F-Tests

SysReqSysReqSysReq

F-Spec ...

Feature N


F-TestsF-Spec ...

Feature 02

Cas 3: Feature based re-use:Les “features” sont des unités de ré-utilisation planifiée, qui sont gouvérnées par une autorité commune à la famille de produits.

La “feature” sert à la fois:● d'unité de structuration des artefacts de l'ingénierie (exigences, tests, code ..) ● d'unité de composition du produit (un produit = une liste de features).

Bénéfices: ● Ré-utilisation plus efficace que dans le cas “delta” car la réutilisation des features est gérée

Inconvénients:● La “feature” supporte deux contraintes:

✔ unité de définition de la variabilité (unité de composition du produit)

✔ unité de structuration des spec, des tests, du code (et donc unité d'évolution fonctionnelle de la plate-forme dans le temps).● Difficulté majeure: le “feature scoping”: comment définir la portée

d'une feature (et de ses points de variation interne) ainsi que les dépendances associées pour permette une ré-utilisation efficace “dans la vraie vie”.

● Risque: multiplication des features en tant qu'incréments de fonctionnalité en réponse à des besoins client - mais qui ne soient en

fait pas ré-utilisables. Risque d'arriver à une explosion similaire au cas 2 “Delta”.


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.


SPLE - Software product line engineering

Domainengineering(platform

level)

Applicationengineering

(productcustomization)

feature modeling (problem domain)

Engineering artefact modeling (solution domain)

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.




SPLE – Software product line engineering


level)



1

Feature model

2Exigences ré-utilisables

Test cases ré-utilisables

etc.

33

Variant description model(i.e. choices in the

feature model)

3 4

Spécifications des exigencesdu produit

Plan de test du produit




Construire le “feature model”


level)



1

Feature model

1

Étape 1: exprimer la structure et la variabilité de la famille de produit


Rôle du “feature model”

Page 25

MobilePhone

...CNXMMDIA

Imager MediaPlayer

Optional

Alternative

Or

MandatoryFeature model:1) structurer la famille de produit2) définir les points de variation – et les variantes

associées (d'un point de vue “système” - i.e. “boîte noire”).

HW MechaSW_PackagesSW

ChipsetCamera FormFactor

Autofocus Resolution

8MP2MP 5MP 12MP

...PIM

XA2XA1 ZB3

Screen

ClamCandyBar Tablet

(source [Wikip_FM] et [Beuche2004])

AppCam VidRec

1


Définition des dépendances

Page 26

MobilePhone

...CNXMMDIA

Imager MediaPlayer

Requires

ConflictsExprimer les dépendances entre les variantes.Par exemple la fonction “autofocus”, qui est un équipement optique volumineux, est ici incompatible avec le form factor “CandyBar”.

HW MechaSW_PackagesSW

ChipsetCamera FormFactor

Autofocus Resolution

8MP2MP 5MP 12MP

...PIM

XA2XA1 ZB3

Screen

ClamCandyBar Tablet

AppCam VidRec

1


Définition du feature model

Page 27

1

Exemple de mise en oeuvre du “feature model” avec

l'outil de gestion des variantes “pure::variants”

(http://www.pure-systems.com)

http://www.pure-systems.com/


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


level)



2Exigences ré-utilisables

Test cases ré-utilisables

2

Étape 2 Organiser et construire les artefacts réutilisables de l'ingénierie (exigences, tests, composants ..)



etc.


feature versus feature

Feature model :1. Express the variability

2

OptionalAlternative

Or

Mandatory

Core assets tree :2. Organise the engineering artefacts

Composant 01


F-TestsF-Spec ... Cmp. “Camera”


F-TestsF-Spec ... Composant N


F-TestsF-Spec ...

MobilePhone

...CNXMMDIA

Imager MediaPlayer

HWSW

Camera

AutofocusResolution

8MP2MP 5MP

PIM

AppCam VidRec

“Core assets tree”Structure les artefacts ré-utilisables

de l'ingénierie par “composants”(parfois appelés “Features” ! )


Exigences

Feature model

Spécifications des exigences du composant(ici le composant “Camera”)

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

2


Tests

Test suite (composant “Camera”)

The test plan is linked with the feature model, so that

the product specific test plan can be generated from the variant model.

Feature model

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

2



“Satisfy” traceability

“satisfy” traceabilty (ie. Feature technical requirements to customer requirements) is maintained at “Camera” component level.

Exigences client

end user

factory


Standards / legal regulations

corporatemarketing

etc.

Third parties / partners customer

2



Choisir les variantes du produit


level)



3

Variant description model(i.e. choices in the

feature model)

Étape 3 :“variant modeling”:

Le produit est défini par le choix d'une variante pour chaque point de variation du “feature model”

33

3




Variant modelling3


Solution binding – générer le produit


level)



4

Spécifications des exigencesdu produit

Plan de test du produit

Étape 4:“solution binding” -

généreraton des artefacts du produit.

4




Solution binding

domainengin-eering(plat-form level)

applica-tion

engin-eering

(productcustomi-zation)

1

4




Solution binding


applica-tion

engin-eering


1 2

4




Solution binding


applica-tion

engin-eering


1 2

3

4




Solution binding

Transformation can be

either manual

or automatic


applica-tion

engin-eering


1 2

3 4

4



L'ensemble des artefacts de l'ingénierie peut être généré de la sorte: ● Spécification des exigences, ● Tests,● Composants,● etc.


SPLE Benefits 1 : Reduced costs of development

Page 41

(From [Pohl2005])

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.

Approx. 3 systems (sw engineering)

Up-front investment

Nb. of products

Accumulatedcosts

Software product line engineering

Nb. of products

Single product e

ngineerin

g

Break-even point

Lower cost per product


SPLE Benefits 2 : Enhancement of quality

Page 42

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


SPLE Benefits 3 : Reduction of time to market

Page 43

(From [Pohl2005])

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

Time for building common artifacts

Nb. of products

Time to Market for one product

Nb. of products

Shorter development cycle due to reuse

Software product line engineering

Single product engineering


Additional benefits

Page 44

[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


exibriProcessus SPLE : [Pohl2005]


exibriProcessus SPLE : ConIPF methodology [ConIPF2006]


Outils

Page 47

Les outils d'ingénierie des lignes de produits logiciel permettent:● de modéliser la variabilité et les dépendances dans le “feature

model”● de modéliser le “solution domain” (exigences, code, tests) et leurs

dépendances avec les variantes du feature model● de vérifier la validité d'une variante de produit● 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

1

2

3

4

http://www.pure-systems.com/

http://www.biglever.com/

http://sarpresults.ivv.nasa.gov/DownloadFile/134/14/3_Product_Line_Verification_Tools.pdf






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


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

http://en.wikipedia.org/wiki/Feature_model


Questions ?

Daniel [email protected]

www.exibri.com

Merci !

Retrouvez cette présentation sur www.exibri.com

mailto:[email protected]

http://www.exibri.com/

exibri software product lines aosd

Technology