Exibri Software Product Lines Aosd
Upcoming SlideShare
Loading in...5
×
 

Exibri Software Product Lines Aosd

on

  • 794 views

 

Statistics

Views

Total Views
794
Views on SlideShare
792
Embed Views
2

Actions

Likes
0
Downloads
14
Comments
0

1 Embed 2

http://www.slideshare.net 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Exibri Software Product Lines Aosd Exibri Software Product Lines Aosd Presentation Transcript

  • 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.). Réutilisation des exigences par l'ingénierie des lignes de produit logiciel 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. Réutilisation des exigences par l'ingénierie des lignes de produit logiciel Page 3 View slide
  • Nos références Réutilisation des exigences par l'ingénierie des lignes de produit logiciel Page 4 View slide
  • 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
  • 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
  • Les stratégies de ré-utilisation du logiciel Réutilisation des exigences par l'ingénierie des lignes de produit logiciel Page 7
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 3 Variant modelling Réutilisation des exigences par l'ingénierie des lignes de produit logiciel Page 36
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • exibri Processus SPLE : [Pohl2005] Réutilisation des exigences par l'ingénierie des lignes de produit logiciel Page 46
  • exibri Processus SPLE : ConIPF methodology [ConIPF2006] Réutilisation des exigences par l'ingénierie des lignes de produit logiciel 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 Réutilisation des exigences par l'ingénierie des lignes de produit logiciel Page 47
  • 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
  • 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
  • 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