SlideShare une entreprise Scribd logo
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
Nos références




Réutilisation des exigences par l'ingénierie des lignes de produit logiciel
                                                                                         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


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

Contenu connexe

En vedette

Präsentation PM Forum - Social Software
Präsentation PM Forum  - Social SoftwarePräsentation PM Forum  - Social Software
Präsentation PM Forum - Social Software
GPMS
 
Software Academy 10 Erreurs Rh Par Altaide Et Moovement
Software Academy 10 Erreurs Rh Par Altaide Et MoovementSoftware Academy 10 Erreurs Rh Par Altaide Et Moovement
Software Academy 10 Erreurs Rh Par Altaide Et Moovement
ALTAIDE
 
Das Potential von Open Source Software nutzen und die Risiken minimieren
Das Potential von Open Source Software nutzen und die Risiken minimierenDas Potential von Open Source Software nutzen und die Risiken minimieren
Das Potential von Open Source Software nutzen und die Risiken minimieren
Matthias Stürmer
 
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-ToolsSoftware-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Andreas Schreiber
 
Torsten Grote: Freie Software
Torsten Grote: Freie SoftwareTorsten Grote: Freie Software
Torsten Grote: Freie Software
StefanMz
 
Freie Software in der (Groß-)Forschung
Freie Software in der (Groß-)ForschungFreie Software in der (Groß-)Forschung
Freie Software in der (Groß-)Forschung
Andreas Schreiber
 
Découvrez les solutions de virtualisation de Stockage DataCore et sa platefor...
Découvrez les solutions de virtualisation de Stockage DataCore et sa platefor...Découvrez les solutions de virtualisation de Stockage DataCore et sa platefor...
Découvrez les solutions de virtualisation de Stockage DataCore et sa platefor...
ljaquet
 
Einsatz von Social Software für Online-Marketing und virtuelle Zusammenarbeit...
Einsatz von Social Software fürOnline-Marketing und virtuelle Zusammenarbeit...Einsatz von Social Software fürOnline-Marketing und virtuelle Zusammenarbeit...
Einsatz von Social Software für Online-Marketing und virtuelle Zusammenarbeit...
styropor
 
Mia software mdday2010
Mia software mdday2010Mia software mdday2010
Mia software mdday2010
MD DAY
 
Open Source Software: Reif für den typischen CH KMU?
Open Source Software: Reif für den typischen CH KMU?Open Source Software: Reif für den typischen CH KMU?
Open Source Software: Reif für den typischen CH KMU?
Matthias Stürmer
 
2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...
2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...
2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...
Ayelt Komus
 
Lm software
Lm softwareLm software
Lm software
JeanFrancoisArn
 
Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...
Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...
Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...
Club Alliances
 
Social Software Im Unternehmen
Social Software Im UnternehmenSocial Software Im Unternehmen
Social Software Im Unternehmen
Helmut Nagy
 
Slide Lewis Chimarro
Slide   Lewis ChimarroSlide   Lewis Chimarro
Slide Lewis Chimarro
Lewis Chimarro
 
(In)Segurança De Software, Quebrando Códigos
(In)Segurança De Software, Quebrando Códigos(In)Segurança De Software, Quebrando Códigos
(In)Segurança De Software, Quebrando Códigos
Rafael Rosa
 
Arcsys software - Le coffre fort numérique
Arcsys software - Le coffre fort numériqueArcsys software - Le coffre fort numérique
Testen von Software (german)
Testen von Software (german)Testen von Software (german)
Testen von Software (german)
Markus Wichmann
 
Cubic Original AW2015 Catalog 'Laboratory Flowers'
Cubic Original AW2015 Catalog  'Laboratory Flowers'Cubic Original AW2015 Catalog  'Laboratory Flowers'
Cubic Original AW2015 Catalog 'Laboratory Flowers'
Jessica Garcia
 
METROfizierung industrieller Bedienoberflächen
METROfizierung industrieller BedienoberflächenMETROfizierung industrieller Bedienoberflächen
METROfizierung industrieller Bedienoberflächen
Ergosign GmbH
 

En vedette (20)

Präsentation PM Forum - Social Software
Präsentation PM Forum  - Social SoftwarePräsentation PM Forum  - Social Software
Präsentation PM Forum - Social Software
 
Software Academy 10 Erreurs Rh Par Altaide Et Moovement
Software Academy 10 Erreurs Rh Par Altaide Et MoovementSoftware Academy 10 Erreurs Rh Par Altaide Et Moovement
Software Academy 10 Erreurs Rh Par Altaide Et Moovement
 
Das Potential von Open Source Software nutzen und die Risiken minimieren
Das Potential von Open Source Software nutzen und die Risiken minimierenDas Potential von Open Source Software nutzen und die Risiken minimieren
Das Potential von Open Source Software nutzen und die Risiken minimieren
 
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-ToolsSoftware-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
Software-Engineering in der Luft- und Raumfahrt mit Open-Source-Tools
 
Torsten Grote: Freie Software
Torsten Grote: Freie SoftwareTorsten Grote: Freie Software
Torsten Grote: Freie Software
 
Freie Software in der (Groß-)Forschung
Freie Software in der (Groß-)ForschungFreie Software in der (Groß-)Forschung
Freie Software in der (Groß-)Forschung
 
Découvrez les solutions de virtualisation de Stockage DataCore et sa platefor...
Découvrez les solutions de virtualisation de Stockage DataCore et sa platefor...Découvrez les solutions de virtualisation de Stockage DataCore et sa platefor...
Découvrez les solutions de virtualisation de Stockage DataCore et sa platefor...
 
Einsatz von Social Software für Online-Marketing und virtuelle Zusammenarbeit...
Einsatz von Social Software fürOnline-Marketing und virtuelle Zusammenarbeit...Einsatz von Social Software fürOnline-Marketing und virtuelle Zusammenarbeit...
Einsatz von Social Software für Online-Marketing und virtuelle Zusammenarbeit...
 
Mia software mdday2010
Mia software mdday2010Mia software mdday2010
Mia software mdday2010
 
Open Source Software: Reif für den typischen CH KMU?
Open Source Software: Reif für den typischen CH KMU?Open Source Software: Reif für den typischen CH KMU?
Open Source Software: Reif für den typischen CH KMU?
 
2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...
2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...
2009 Wikimanagement: Neue Denkansätze für die Wissensnutzung im Geschäftsproz...
 
Lm software
Lm softwareLm software
Lm software
 
Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...
Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...
Solutions en mode SaaS (Software as a Service) : les PME accèdent-elles à des...
 
Social Software Im Unternehmen
Social Software Im UnternehmenSocial Software Im Unternehmen
Social Software Im Unternehmen
 
Slide Lewis Chimarro
Slide   Lewis ChimarroSlide   Lewis Chimarro
Slide Lewis Chimarro
 
(In)Segurança De Software, Quebrando Códigos
(In)Segurança De Software, Quebrando Códigos(In)Segurança De Software, Quebrando Códigos
(In)Segurança De Software, Quebrando Códigos
 
Arcsys software - Le coffre fort numérique
Arcsys software - Le coffre fort numériqueArcsys software - Le coffre fort numérique
Arcsys software - Le coffre fort numérique
 
Testen von Software (german)
Testen von Software (german)Testen von Software (german)
Testen von Software (german)
 
Cubic Original AW2015 Catalog 'Laboratory Flowers'
Cubic Original AW2015 Catalog  'Laboratory Flowers'Cubic Original AW2015 Catalog  'Laboratory Flowers'
Cubic Original AW2015 Catalog 'Laboratory Flowers'
 
METROfizierung industrieller Bedienoberflächen
METROfizierung industrieller BedienoberflächenMETROfizierung industrieller Bedienoberflächen
METROfizierung industrieller Bedienoberflächen
 

Similaire à Exibri Software Product Lines Aosd

Témoignage client ProxiAD
Témoignage client ProxiADTémoignage client ProxiAD
Témoignage client ProxiAD
EclipseDayParis
 
Soft fluent@md day2011
Soft fluent@md day2011Soft fluent@md day2011
Soft fluent@md day2011
MDDAY11
 
DevOps, quel futur pour les Ops ?
DevOps, quel futur pour les Ops ?DevOps, quel futur pour les Ops ?
DevOps, quel futur pour les Ops ?
Ludovic Piot
 
Solutions mobiles InterTek Ingénierie
Solutions mobiles InterTek IngénierieSolutions mobiles InterTek Ingénierie
Solutions mobiles InterTek Ingénierie
Philippe Jeandroz
 
Prototypage de Systèmes Embarqués
Prototypage de Systèmes EmbarquésPrototypage de Systèmes Embarqués
Prototypage de Systèmes Embarqués
boisgera
 
[TNT19] Hands on: Objectif Top Architecte!
[TNT19] Hands on: Objectif Top Architecte![TNT19] Hands on: Objectif Top Architecte!
[TNT19] Hands on: Objectif Top Architecte!
Alexandre Touret
 
Chp2 - Cahier des Charges
Chp2 - Cahier des ChargesChp2 - Cahier des Charges
Chp2 - Cahier des Charges
Lilia Sfaxi
 
Mia software@md day2011
Mia software@md day2011Mia software@md day2011
Mia software@md day2011
MDDAY11
 
chapitres 3 technologies de communication de l'IoT partie II.pptx
chapitres  3 technologies de communication de l'IoT partie II.pptxchapitres  3 technologies de communication de l'IoT partie II.pptx
chapitres 3 technologies de communication de l'IoT partie II.pptx
merazgaammar2
 
Mohamed.marouan
Mohamed.marouanMohamed.marouan
Mohamed.marouan
Marouan MOHAMED
 
Softfluent speig mdday2010
Softfluent speig mdday2010Softfluent speig mdday2010
Softfluent speig mdday2010
MD DAY
 
Innovative Architecture Design
Innovative Architecture DesignInnovative Architecture Design
Innovative Architecture Design
Airmis
 
X-Analysis - for IBM partners - FR
X-Analysis - for IBM partners - FRX-Analysis - for IBM partners - FR
X-Analysis - for IBM partners - FR
Fresche Solutions
 
Créer des applications métier (LOB) pour Windows 8 et Windows Phone 8
Créer des applications métier (LOB) pour Windows 8 et Windows Phone 8Créer des applications métier (LOB) pour Windows 8 et Windows Phone 8
Créer des applications métier (LOB) pour Windows 8 et Windows Phone 8
Microsoft
 
Presentation BMIA
Presentation BMIAPresentation BMIA
Presentation BMIA
PMarsaud
 
TECHDAYS 2013 : Intégration de la chaîne de valeur
TECHDAYS 2013 : Intégration de la chaîne de valeurTECHDAYS 2013 : Intégration de la chaîne de valeur
TECHDAYS 2013 : Intégration de la chaîne de valeur
Inetum
 
Démo des nouvelles versions Dynamics CRM, L'utilisateur au centre des innovat...
Démo des nouvelles versions Dynamics CRM, L'utilisateur au centre des innovat...Démo des nouvelles versions Dynamics CRM, L'utilisateur au centre des innovat...
Démo des nouvelles versions Dynamics CRM, L'utilisateur au centre des innovat...
Microsoft Décideurs IT
 
Démo des nouvelles versions Dynamics CRM, L'utilisateur au centre des innovat...
Démo des nouvelles versions Dynamics CRM, L'utilisateur au centre des innovat...Démo des nouvelles versions Dynamics CRM, L'utilisateur au centre des innovat...
Démo des nouvelles versions Dynamics CRM, L'utilisateur au centre des innovat...
Microsoft Décideurs IT
 

Similaire à Exibri Software Product Lines Aosd (20)

Témoignage client ProxiAD
Témoignage client ProxiADTémoignage client ProxiAD
Témoignage client ProxiAD
 
Les usines à logiciels
Les usines à logicielsLes usines à logiciels
Les usines à logiciels
 
Soft fluent@md day2011
Soft fluent@md day2011Soft fluent@md day2011
Soft fluent@md day2011
 
DevOps, quel futur pour les Ops ?
DevOps, quel futur pour les Ops ?DevOps, quel futur pour les Ops ?
DevOps, quel futur pour les Ops ?
 
Solutions mobiles InterTek Ingénierie
Solutions mobiles InterTek IngénierieSolutions mobiles InterTek Ingénierie
Solutions mobiles InterTek Ingénierie
 
Prototypage de Systèmes Embarqués
Prototypage de Systèmes EmbarquésPrototypage de Systèmes Embarqués
Prototypage de Systèmes Embarqués
 
[TNT19] Hands on: Objectif Top Architecte!
[TNT19] Hands on: Objectif Top Architecte![TNT19] Hands on: Objectif Top Architecte!
[TNT19] Hands on: Objectif Top Architecte!
 
Chp2 - Cahier des Charges
Chp2 - Cahier des ChargesChp2 - Cahier des Charges
Chp2 - Cahier des Charges
 
Mia software@md day2011
Mia software@md day2011Mia software@md day2011
Mia software@md day2011
 
chapitres 3 technologies de communication de l'IoT partie II.pptx
chapitres  3 technologies de communication de l'IoT partie II.pptxchapitres  3 technologies de communication de l'IoT partie II.pptx
chapitres 3 technologies de communication de l'IoT partie II.pptx
 
Mohamed.marouan
Mohamed.marouanMohamed.marouan
Mohamed.marouan
 
Softfluent speig mdday2010
Softfluent speig mdday2010Softfluent speig mdday2010
Softfluent speig mdday2010
 
Innovative Architecture Design
Innovative Architecture DesignInnovative Architecture Design
Innovative Architecture Design
 
Gl rappels ac
Gl rappels acGl rappels ac
Gl rappels ac
 
X-Analysis - for IBM partners - FR
X-Analysis - for IBM partners - FRX-Analysis - for IBM partners - FR
X-Analysis - for IBM partners - FR
 
Créer des applications métier (LOB) pour Windows 8 et Windows Phone 8
Créer des applications métier (LOB) pour Windows 8 et Windows Phone 8Créer des applications métier (LOB) pour Windows 8 et Windows Phone 8
Créer des applications métier (LOB) pour Windows 8 et Windows Phone 8
 
Presentation BMIA
Presentation BMIAPresentation BMIA
Presentation BMIA
 
TECHDAYS 2013 : Intégration de la chaîne de valeur
TECHDAYS 2013 : Intégration de la chaîne de valeurTECHDAYS 2013 : Intégration de la chaîne de valeur
TECHDAYS 2013 : Intégration de la chaîne de valeur
 
Démo des nouvelles versions Dynamics CRM, L'utilisateur au centre des innovat...
Démo des nouvelles versions Dynamics CRM, L'utilisateur au centre des innovat...Démo des nouvelles versions Dynamics CRM, L'utilisateur au centre des innovat...
Démo des nouvelles versions Dynamics CRM, L'utilisateur au centre des innovat...
 
Démo des nouvelles versions Dynamics CRM, L'utilisateur au centre des innovat...
Démo des nouvelles versions Dynamics CRM, L'utilisateur au centre des innovat...Démo des nouvelles versions Dynamics CRM, L'utilisateur au centre des innovat...
Démo des nouvelles versions Dynamics CRM, L'utilisateur au centre des innovat...
 

Plus de Cédric WILLIAMSON

Hogunsoft presentation meito atelier crm
Hogunsoft  presentation meito atelier crmHogunsoft  presentation meito atelier crm
Hogunsoft presentation meito atelier crm
Cédric WILLIAMSON
 
Hisseo presentation meito atelier crm
Hisseo presentation meito atelier crmHisseo presentation meito atelier crm
Hisseo presentation meito atelier crm
Cédric WILLIAMSON
 
Hogunsoft presentation meito atelier crm
Hogunsoft  presentation meito atelier crmHogunsoft  presentation meito atelier crm
Hogunsoft presentation meito atelier crm
Cédric WILLIAMSON
 
Logica presentation meito atelier crm
Logica presentation meito atelier crmLogica presentation meito atelier crm
Logica presentation meito atelier crm
Cédric WILLIAMSON
 
Thales
ThalesThales
Jm Jezequel irisa Aom4 agility
Jm Jezequel irisa Aom4 agilityJm Jezequel irisa Aom4 agility
Jm Jezequel irisa Aom4 agility
Cédric WILLIAMSON
 
L Morisseau Adoption De L Agilite
L Morisseau Adoption De L AgiliteL Morisseau Adoption De L Agilite
L Morisseau Adoption De L Agilite
Cédric WILLIAMSON
 

Plus de Cédric WILLIAMSON (11)

Hogunsoft presentation meito atelier crm
Hogunsoft  presentation meito atelier crmHogunsoft  presentation meito atelier crm
Hogunsoft presentation meito atelier crm
 
Hisseo presentation meito atelier crm
Hisseo presentation meito atelier crmHisseo presentation meito atelier crm
Hisseo presentation meito atelier crm
 
Hogunsoft presentation meito atelier crm
Hogunsoft  presentation meito atelier crmHogunsoft  presentation meito atelier crm
Hogunsoft presentation meito atelier crm
 
Logica presentation meito atelier crm
Logica presentation meito atelier crmLogica presentation meito atelier crm
Logica presentation meito atelier crm
 
Thales
ThalesThales
Thales
 
Irisa p gros
Irisa p grosIrisa p gros
Irisa p gros
 
In pixal fusion_algos
In pixal fusion_algosIn pixal fusion_algos
In pixal fusion_algos
 
Advansee
AdvanseeAdvansee
Advansee
 
Jm Jezequel irisa Aom4 agility
Jm Jezequel irisa Aom4 agilityJm Jezequel irisa Aom4 agility
Jm Jezequel irisa Aom4 agility
 
L Morisseau Adoption De L Agilite
L Morisseau Adoption De L AgiliteL Morisseau Adoption De L Agilite
L Morisseau Adoption De L Agilite
 
Anteo Mda Aosd
Anteo Mda AosdAnteo Mda Aosd
Anteo Mda Aosd
 

Dernier

Les Vidéoprojecteurs : Guide d'achat et Comparatif
Les Vidéoprojecteurs : Guide d'achat et ComparatifLes Vidéoprojecteurs : Guide d'achat et Comparatif
Les Vidéoprojecteurs : Guide d'achat et Comparatif
Top-plans
 
Technologie hydrostatique, innovation pour la stérilisation des aliments : HI...
Technologie hydrostatique, innovation pour la stérilisation des aliments : HI...Technologie hydrostatique, innovation pour la stérilisation des aliments : HI...
Technologie hydrostatique, innovation pour la stérilisation des aliments : HI...
InnovaSter-Trade Ltd.
 
INTELLIGENCE ARTIFICIELLE + INFORMATIQUE QUANTIQUE = LA PLUS GRANDE RÉVOLUTIO...
INTELLIGENCE ARTIFICIELLE + INFORMATIQUE QUANTIQUE = LA PLUS GRANDE RÉVOLUTIO...INTELLIGENCE ARTIFICIELLE + INFORMATIQUE QUANTIQUE = LA PLUS GRANDE RÉVOLUTIO...
INTELLIGENCE ARTIFICIELLE + INFORMATIQUE QUANTIQUE = LA PLUS GRANDE RÉVOLUTIO...
Faga1939
 
Rapport Projet ERP - Plateforme Odoo 16 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 16 (PFE Licence)Rapport Projet ERP - Plateforme Odoo 16 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 16 (PFE Licence)
Chadi Kammoun
 
La Gestion des risques selon ISO 27005.pdf
La Gestion des risques selon ISO 27005.pdfLa Gestion des risques selon ISO 27005.pdf
La Gestion des risques selon ISO 27005.pdf
SoniazghalKallel
 
M365 Community Days MTL 2024 - Découverte du Process Mining et du Task Mining...
M365 Community Days MTL 2024 - Découverte du Process Mining et du Task Mining...M365 Community Days MTL 2024 - Découverte du Process Mining et du Task Mining...
M365 Community Days MTL 2024 - Découverte du Process Mining et du Task Mining...
Nicolas Georgeault
 

Dernier (6)

Les Vidéoprojecteurs : Guide d'achat et Comparatif
Les Vidéoprojecteurs : Guide d'achat et ComparatifLes Vidéoprojecteurs : Guide d'achat et Comparatif
Les Vidéoprojecteurs : Guide d'achat et Comparatif
 
Technologie hydrostatique, innovation pour la stérilisation des aliments : HI...
Technologie hydrostatique, innovation pour la stérilisation des aliments : HI...Technologie hydrostatique, innovation pour la stérilisation des aliments : HI...
Technologie hydrostatique, innovation pour la stérilisation des aliments : HI...
 
INTELLIGENCE ARTIFICIELLE + INFORMATIQUE QUANTIQUE = LA PLUS GRANDE RÉVOLUTIO...
INTELLIGENCE ARTIFICIELLE + INFORMATIQUE QUANTIQUE = LA PLUS GRANDE RÉVOLUTIO...INTELLIGENCE ARTIFICIELLE + INFORMATIQUE QUANTIQUE = LA PLUS GRANDE RÉVOLUTIO...
INTELLIGENCE ARTIFICIELLE + INFORMATIQUE QUANTIQUE = LA PLUS GRANDE RÉVOLUTIO...
 
Rapport Projet ERP - Plateforme Odoo 16 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 16 (PFE Licence)Rapport Projet ERP - Plateforme Odoo 16 (PFE Licence)
Rapport Projet ERP - Plateforme Odoo 16 (PFE Licence)
 
La Gestion des risques selon ISO 27005.pdf
La Gestion des risques selon ISO 27005.pdfLa Gestion des risques selon ISO 27005.pdf
La Gestion des risques selon ISO 27005.pdf
 
M365 Community Days MTL 2024 - Découverte du Process Mining et du Task Mining...
M365 Community Days MTL 2024 - Découverte du Process Mining et du Task Mining...M365 Community Days MTL 2024 - Découverte du Process Mining et du Task Mining...
M365 Community Days MTL 2024 - Découverte du Process Mining et du Task Mining...
 

Exibri Software Product Lines Aosd

  • 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