• Aucun résultat trouvé

Patterns for Product Line Engineering

N/A
N/A
Protected

Academic year: 2022

Partager "Patterns for Product Line Engineering"

Copied!
21
0
0

Texte intégral

(1)

E1Ͳ1

PatternsforProductLineEngineering

ChristaSchwanninger,MichaelKircher,SiemensAG

Introduction

SoftwareProductLineEngineering(PLE)hasbecomeanimportantwayofbuildingandreusing software.InPLE,thefocusisshiftedfrombuildingisolatedproductstobuildingfamiliesofrelated products,whilereuseisdiscussednotatanindividualobjectlevel,e.g.librariesorcomponents,but asawhole:organizational,processͲwise,andalsolifecyclewiseendͲtoͲendfromrequirementsto actuallydeployedvariabilityatthecustomer.WeconsideronlythoseplatformsPLEeffortsthatare plannedandprescribedtobereusedinadedicatedproductportfolioortobuildsolutionsina specificmarketsegment,hencetypicalgeneralpurposetechnologyplatforms,suchasEclipse,JBoss, or.NET,donotfallintothiscategory.

WhilealotofliteratureonPLEexists,thereisstillnoconsistentcollectionofeasytouseand practicalpatterns.Thepatternsdescribedinthispaperbuildontheexistingliterature,likethebook ofClementsandNorthrop[3]orKlausSchmid’’sPhDThesis[8].Withthisinitialcollectionofpatterns wehopetomotivatemorepatternsonPLE.Thepatternsdescribehowtocentralizeandobjectify decisionmaking,howtopartitionthedomainintoseveralsubͲdomains,howtosetupyourreleases, andhowtoavoiddangerouscomplexity.

Thispaperisintendedforanyleadershipstaffconcernedwiththeproductportfoliocontent, organization,process,technology,architecture,oractualprojectexecutionofaPLEinitiative.We assumesomebackgroundinPLE.Referto[1]or[2]foramoredetailedintroduction.

PLEhastobeadaptedtothespecificorganizationathandtobesuccessful.Manyfactorsinfluence howPLEisexecutedinaspecificorganization.Theoneswiththelargestimpactare:sizeofthe organization,kindofbusiness,numberofproductlines,maturityofthedomain,andprocess discipline.WhilethosefactorsinfluencePLE,theywillinreturngetinfluencedbyintroducingPLE.

ThepatternsinthispaperapplylargelytomidͲandlargeͲscaleorganizations,astheytypicallyhave severalproductlineswithseveralinvolvedsubͲorganizationswithvaryingbusinessgoals,which makesdecisionmakingamultiͲdimensionaloptimizationproblem.Organizationswithonlyadozen involvedstaffdonothavesuchissues;insteadmostofthechallengebecomesatechnicalissueof howtodealwithvariability––whichisnotthefocusofthispaper.

Thepatternsdealwithsettinguptheorganization,theprocessandmethodologicalbestpractices.

ThispaperdoesnotprovideanyanalysisadvicewhentouseaPLEeffortornot,insteaditassumes thatareturnoninvest(ROI)analysishasbeendoneinadvanceandthataPLEapproachproved superioroverclassicaloneͲoffdevelopment.

ForreaderswhoarenotfamiliarwithPLEterminology,pleasereadtheglossaryattheendofthe patterncollection.

(2)

E1Ͳ2

Copyrightretainbyauthors.PermissiongrantedtoHillsideEuropeforinclusionintheCEURarchive ofconferenceproceedingsandforHillsideEuropewebsite.

(3)

ScopingPatterns

CentralDecisionMaking

Context

Anorganizationisadoptingproductlineengineering.Uptonowitdevelopedproductsorsolutionsin parallel,withcopy&pastereuse,technologicalplatformusage,orusingastandardizedinfrastructure.

Everyproductdevelopmentgroupwasresponsiblefordecidingonthescopeandreleaseplanofits product,ataskcalledproductmanagement.Theorganizationwantstoincreasethebenefitfrom reuseamongproducts/solutions.Thedevelopmentofasetofreusablecoreassetsisstarted.Ithas tobedecidedwhatthesecoreassetsshouldbe:thescopeofthereuseinfrastructure.Thereasonfor startingtheproductlineistomaximizethereturnoninvestment(ROI)forbuildingreusableassets forthewholeorganization.Figure1showsthedesiredstate,onedomainengineeringactivitythat producesreusableassetsandseveralapplicationengineeringactivitiesthatreusetheseassets.

Figure1:Relationshipbetweendomainandapplicationengineering

Problem

Whodecideswhatassetsshouldbedevelopedasreusablecoreassetsandwhatassetsshouldbe keptproductspecific?

x Everyproductmanagertypicallypusheshisownproducts.Reuseisonlyinterestingifitsaves effortorotherwisebenefitshisproducts.Supportinghisownproductsiswhatheistrained todo.

x Withoutmoderationeitherthestrongestinagroupofproductmanagersdictateswhatwill beimplementedasreusablecoreassetortheproductmanagersagreeonsome

compromise,e.g.everybodygetstheirmostimportantfeaturesin.Thisselectionislikelynot maximizingtheprofitofthewholeorganization.

x Coreassetdevelopmentisconfrontedwithallproductmanagersandtheircorresponding priorities.Fordecidingaboutaproductportfoliostrategydeepmarketknowledgeis required,whichtypicallyisnotavailableindevelopment.Developmentisinclinedeitherto

E1Ͳ3

(4)

giveinonthepressureofthestrongestordecidebythemselveswhathasthehighest priority,oftenaccordingtopurelytechnicalcriteria.

Solution

Centralizedecisionmakingregardingscopeandpriorities.Thebestwaytodothisisintroduceanew roleintheorganization,theproductlineproductmanager.Hisgoalistooptimizetheproduct portfolio,thesolutionscope,whichshallbesupportedbythesharedcoreassets.Forbigger organizationstheproductlineproductmanagementcanalsobestaffedwithseveralindividuals.

Figure2:TheProductLineProductManagerisresponsibleforthewholeproductline.

Coreassetdevelopmentshouldnotdecideaboutfeaturepriorities.However,coreasset

developmentestimatestheeffortforfeaturesandanalyzesdependenciesamongfeatures,whichis essentialinputfordecidingonwhatshouldbeimplementedascoreasset.Beawarethatproduct managementaloneisnotsufficienttofindtheoveralloptimizedscopeforabusiness,because constraintslikequality,time,andcostmightnotberepresentedsufficiently;seethepatterns BalanceConstraintsandCollaborationbetweenProblemandSolutionExperts.

TheProductLineProductManagerisresponsiblefortheoverallproductportfolio,thereforeis neitherpartofanyproductdevelopmentteam,norofthecoreassetdevelopmentteam.There mightbeconditionsthatrenderadedicated,independentrolenotpossible,e.g.iftheorganizations areseparateprofitcenterswiththeirownbusinesstargetsandnooperationalresponsibilitiesareat acommonmanagementlevel.TheProductLineProductManagerwouldinthiscasebepartofthe coreassetdevelopingorganization,whichmakeshispositionintheoverallorganizationweaker.It requiresadditionalprocesssupporttodealwiththissituation.ThissubͲpatternlanguageisyettobe mined.

Rationale

Foreffectivecoreassetdevelopmentasingleresponsibilityforprioritizationandscopingisrequired.

Inordertoprioritizefeaturesandscopetheproductlinetomaximizetheeconomicbenefitofthe

E1Ͳ4

(5)

E1Ͳ5

wholeorganization,knowledgeaboutthemarket(s),competition,andcustomersisimportantfor thatrole.Developmenttypicallylacksthefullunderstandingofcustomerandbusinessvalue.

Thispatternworksbestifthecoreassetsactuallyimplementdomainspecific––customervisible––

coreassets.Suchassetstypicallyheavilyinfluencetheactualproductportfolio.Incontrast,ifthe coreassetsaremainlytechnicalinfrastructureassets,theproductportfolioisonlymarginally influencedbythecoreassetscope.Insuchcasestheproductlinearchitectroleinsteadofthe productmanager,mayperformthescoping,becausehecanadequatelyjudgethescopeofthe mainlyinfrastructurecoreassets.TheProductLineArchitectthenfulfillstheroleoftheProductLine ProductManageraswell.

TheProductLineProductManagerroleresolvestheconflictamongstproductmanagersand betweenproductmanagementandcoreassetdevelopment.Wesaworganizationsthatsuffered fromthisconflict.Intheend,theproductlinesbrokeapartandthewholeeffortofdoingPLEwas seenasafailure.

TheRoleProductLineProductManagerhastoknowhowtomanagetheconflictinginterests betweenhisroleandtheproductmanagers.ThisconflictcanberesolvedwithComprehensible DecisionMaking.

ReferencesandKnownUses

ThispatternisappliedataSiemensHealthcaregroupdevelopinganimagingplatform.Theplatform customersaredifferentimagingproductlines,whichwereheavilyinvolvedindefiningthescopeof thenewplatformfromthebeginning.However,therewasnodedicatedproductmanagerforthe platform.Hence,fartoomanyfeatureswereassignedtotheplatform.Therewasnoclear

prioritization,anddespiteworkinghard,theplatformcustomerswereneversatisfiedwiththescope oftheplatform.Twoyearslatertheorganizationinstalledaplatformproductmanagement.The platformproductmanagerisnowresponsibletodefineacommonvocabularyandtodrivescopingof coreassetsincollaborationwiththeproductmanagersofthedifferentproducts.Hemoderates scopingsessionsandmakesthescopeandtherationalforthescopetransparenttoproduct developments.Theorganizationmanagedtoregaintrustfromtheproductgroups.Installinga productlineproductmanagerimprovedthesituationconsiderablyforboth,domainandapplication engineering.

AseparategroupatSiemenspostalautomationstartedafirstplatformabout10yearsagotobenefit fromreuseamongtheircustomerprojects.Therewasnoplatformproductmanager,evennoexplicit scopingprocess.Theplatformuserswerenothappywiththeplatform,quicklystartedtocloneand ownpartsoftheplatformandtheplatformteamwasturnedintoaprojectteamforonespecific customerafterthreeyears.Today,theorganizationhasaverystrongproductmanagementthat knowsaboutthevalueofreusableassetsandactivelysupportsscopingandmarketingofreusable assets.Allbiddinginvitationsgothroughtheproductlinemanagementgroup,thatisateamof productlineproductmanagersandproductlinearchitects.Thescopingisdoneinseveralsteps:

decidingwhichexistingcoreassetswillbeofferedtothecustomer,whichcoreassetsshouldbe adaptedandwhichshouldbebuiltanewincasethecustomerprojectactuallyiswon.Basedonthis theofferismadetothecustomer.Whenthecustomeraccepts,theproductlinemanagementteam includestheeffortforbuildingtheassetsintotheoverallproductlinedevelopmentplan.

(6)

E1Ͳ6

ComprehensibleDecisionCriteria

Context

ThepatternProductLineProductManagerwasapplied.Aconflictpotentialisremainingbetween individualproductmanagersandtheProductLineProductManagerresponsibleforthewhole productlineportfolio.

Problem

Theproductmanagersresponsibleforsingleproduct/solutionareagroupofpeerswhohaveall conflictinggoals,whichispromotingthespecificproductstheyareresponsiblefor.Agreeingona scopeforthereusablebaseassetsmeansresolvingconflictsthatarisefromthesedifferentgoals.

x Everyproductmanagertypicallypushesonlyhisownproducts.Reuseisonlyinterestingifit saveseffortorotherwisebenefitshisproducts.Supportinghisownproductsiswhatheis trainedtodo.

x Coreassetsoftengetspecialfunding.Thecostissharedbetweenallproducts/solutions.

Oftenproductmanagerswanttounburdentheirproduct/solutionspecificbudgetandputas muchdevelopmenteffortaspossibletothecoreassetdevelopment.Thiswaymorebudget isavailableformakingownproductsbetter,cheaperorearlieronthemarket..

x WhentheselectionofwhatshallbeacoreassetandwhatshallbeproductͲspecificseems notcredible,developmentwillnotrespectthescopingdecisions.Developmentwilldecideon itsownpriorities.

Solution

Defineandcommunicateclearcriteriaforevaluatingthevalueoffeatures.Thecriteriashouldbe derivedfromtheorganization’’smission,vision,andstrategy,becauseonlythenthedecisionsarein linewiththebusinesstargets.Evaluatethecostandbenefitforeveryfeatureandforeveryproduct accordingtothesecommoncriteria.Decisionmakingboilsdowntocalculatingthesevaluesand decidingaccordingtoobjectivenumbers.

Thebestwaytodothisistodefinecriteriaforthebenefitandthecostofeachfeature.Benefit criteriacouldbehowmuchdoesthemarketrequestthisfeatureorhowwelldoesitsupportthe specificportfoliostrategy.Thecostsideneednotbeanestimationofthedevelopmentcostforthe feature,sincethismaybehardtobecalculatedearlyintheprocess,butamixtureofestimated complexity,novelty,andeffectonthecurrentproductlinearchitecture.

Startwithsimplebenefit/costevaluationformulasandimprovethemovertime.Theproduct managersandarchitectsthatdeliverthedatafortheformulatypicallydifferintheiraccuracyand reliabilityofthedatatheyprovide.Installmetricscomparingestimationswiththelaterfacts,e.g.

estimatedsalesfiguresandactualsalesfiguresforaproduct.Theresultsareusedascorrection factors.

(7)

E1Ͳ7

Rationale

Mostofthepotentialconflictcanbemitigatedwheneverystakeholdersharestheirbusinessvalue dataandtheresultismerelycalculated.Theproductlineproductmanagerdrivestheprocessand controlshowfairlyfeaturesareratedandimprovestheevaluationcriteriaandformulas.

ReferencesandKnownUses

TheplatformorganizationforimagingsystemswithinSiemensHealthcaredevelopedaformulafor prioritizingfeaturesandcalculatingthecostofeveryfeature.Itisfilledwithinformationfrom

productmanagementanddevelopmenttodeterminebenefitandcostofeveryfeature.Measuresfor afeature’’sbenefitareforexamplewhetheritisinnovativeorjusta““metoo””featureandhowoften itwouldbereused,measuresforitscostareforexamplethecomplexityandhowcrosscuttingitisin thesolutionspace.Theresultsaretakentodecidewhetherafeatureshouldbeimplementedinthe platformatallandwhatpriorityitshouldhave.

KlausSchmidsuggestsasimilarprocedurein[2].Inthiscontextitwastestedwithtwoproductlines ofMARKETMAKERSoftwareAGandwithoneproductlineinBosch.

(8)

E1Ͳ8

SeparateSubǦdomains

Context

Theorganizationhastodecidewhatwillbedevelopedascoreassetandwhatwillremainproduct specific––atypicalscopingdecision.Actually,theorganizationwillalsohavetodecideonaproduct portfoliothatallowsmaximizingthebenefitfromreuse.

Problem

Budgetandtimeforsettingupacoreassetbaseislimited.Iffindingoutwhichassetsareworthtobe developedascoreassettakestoomanyresources,theproductlinemightdiebeforeitevenstarts.

x Notallareasinadomainareequallystableandthereforesuitableforreuse.

x Scopingisapureplanningactivity.Itisnotproductiveandaccountsasnegativeiteminthe returnoninvestmentcalculationforaproductline.

x OftenamarketevaluationisanimportantpreͲconditionforscoping.Thescopingactivityhas tobeperformedinatimeframethattogetherwithimplementingthescopeisshortenough tocatchthemarketwindowthatwaslookedatintheevaluation.

x Thefeaturesinthecoreassetbasehavetobeselectedinawaysuchthatitispossibleto formaconsistentreferencearchitecture.Theycannotresultincompletelyindependent piecesoffunctionalityinsolutionspace.Itmustbepossibletoarchitectandimplementa coherentchunkoffunctionality.

Solution

DividetheapplicationdomaininsubͲdomainsthatcanbehandledseparately.Theeasiestwayto identifysubͲdomainsistolookatexistingsystems/products.Theirdivisioninsubsystemsisagood firstsubdivisionoftheoveralldomain.FirstestimatethereusepotentialforeverysubͲdomainbased onpastexperience.ThencontinuecloserinvestigationswithoneortwopromisingsubͲdomains.Find outwhatcanbereusedforthesesubͲdomainsandimplementtheseassets.

ThesubͲdomainsmightbeapplicationdomainspecificliketelephony,shortmessageserviceand dataservicesinamobilephone,ortechnical,likememoryorpowermanagement.

(9)

Figure3:ConsistentsubͲdomainsmaybevertical,horizontal,orscatteredacrossthearchitecture.

Rationale

ImplementingonlycoreassetsforoneortwosubͲdomainsgivesearlyfeedbacktoallstakeholders whethertheorganizationandprocesschangesforPLEweretherightoneswithoutbearingtoohigh riskforthewholeorganization.Withsuchpotentialquickwinstheorganizationismotivatedto extendtheproductlinealsotoothersubͲdomains.

ReferencesandKnownUses

CarmanufacturerstypicallydividetheircarsinsubͲdomainslikechassis,engine,electricalsystem,or safetysystems.Thisdivisionistypicallyalsomirroredintheorganizationalsetup;similarlythe configurationoptionsforthecustomersaregroupedinthesesubͲdomains.

ThefeaturesoftheimagingplatforminSiemensHealthcarearegroupedintoabout10subͲdomains thatstructuretheproblemaswellasthesolutionspace.

KlausSchmidintroducesanewapproachforevaluatingsubͲdomains,thedomainpotential assessmentin[2].

E1Ͳ9

(10)

E1Ͳ10

StartwithProductFeatureMap

Context

Anorganizationwantstobenefitfromreuse.Theorganizationalreadyimplementedsystemsinthe domainforawhile.Existingproductsorsolutionsareavailable.

Problem

Tobenefitfromreuseincurrentand/orfutureproductportfoliotheorganizationneedstofindout whichartifactsshouldbeimplementedforreuse.

x Takingalreadyavailableassetsandturnthemintoreusableassetsbyincreasingthequality andaddingvariationpointsisalowriskoptiontogetasetofcoreassets.Howeveritis unclearwhichvariantsshouldbesupported.

x Developmentknowswhatittakestobuildcertainfunctionalityandwhatshouldbereusable.

Butstillthisisatmostaprojectionfromthepastproductportfolio.

x DomainanalysislooksatsubͲdomainsthatpresumablyhavereusepotential,identifiesthe commonalitiesandvariantsineachsubͲdomainandgivesafeelingforreusepotential.

However,ifallvariantspossibleinasubͲdomainareconsidered,thiswillnotsupportthe businessoftheorganizationoptimally.

Solution

Beforethescopingofcoreassetsstarts,theproductsorsolutionsthatshallbesupportedbythese coreassetshavetobeclear.Thus,thefirststepistoidentifytheproductsandmarketsegmentsthat shallbeaddressedbytheproductline.Next,thecharacteristicsorfeaturesthatareincludedineach oftheproductsarelistedtoseethecommonalitiesandvariabilitybetweentheproductsormarket segments.Thisisthestartingpositionforfurthercommonality/variabilityanalysis.Theenvisioned productportfoliorestrictsthelistofpossiblefeaturesineachsubͲdomain.Atthesametimeproducts getbettershapedbydecidingforeachadditionalfeatureifitshouldorshouldnotbeintheproduct.

Rationale

Iftheproductportfolioormarketsegmentsofinterestarenotthestartingpointforcoreasset scoping,theassetswilltypicallybemoregenericthannecessary.Theadvantageofproductline engineeringoversimplereuseaspropagatedinthe1990sisthatonlythevariabilityelementary necessarytosupportaspecificbusinessisbuiltintothecoreassetsandnotmore––seeFavor PlatformSimplicity.Coreassetshavetobebuildconsideringvariabilitythatistobeexpectedfor futureportfolios,butthevariantsshouldbeclearlyidentifiableandevidentlymotivated.

ReferencesandKnownUses

Product/Featuremapsarequitecommoninportfoliodevelopment.CarmanufacturerslikeAudiand BMWpresenttheirportfolioinsuchlists.

Similarly,SiemensIndustryDriveTechnologiesscopetheirproductportfolioswiththehelpof product/featuremapsundusethecustomervisibleparttopresenttheirproductportfolioto customers,Figure4showsanexamplefromhttp://www.automation.siemens.com/.

(11)

Figure4:ExampleofSiemensAutomationandDrivesPortfolio

KlausSchmidsuggeststhisprocedurein[2].Inthiscontextitwastestedwithtwoproductlinesof MARKETMAKERSoftwareAGandwithoneproductlineinBosch.

In[3]PaulClementsandLindaNorthropsuggest““Developinganattribute/productmatrix””,whichis onepatternintheircollectionofPLEpatterns.Thepatternsin[3]wereminedfromexperiencewith consultingcompaniesthatintroducedorimprovedaPLEapproach.

E1Ͳ11

(12)

E1Ͳ12

CollaborationbetweenProblemandSolutionExperts

Context

Anorganizationdecidestobuildacoreassetbase.Ittriestooptimizethereturnoninvestment.

Problem

Neitherproductmanagement,nordevelopmentaloneissupposedtoknowalldetailsaround commonalityandvariability.

x Productmanagementknowsallfactsaroundmarket,marketablefeatures,valueoffeatures, andproducts.Further,itknowswhichfeaturesarecommonbetweenproductsonahigh levelofabstraction.However,withmoredetailedanalysisvariabilityquicklyincreases, especiallyifnonͲfunctionalrequirementsvary.Suchvariabilitycannotbespottedonahigh levelofabstraction.Hence,thecomplexityandcostforfeaturescannotbedeterminedto thefullextentbyproductmanagement.

x Developmentknowsthecostfordevelopingassets,bothforproductͲspecificandcoreassets.

Developmenthasthe‘‘solutionspace’’knowledgefordeterminingtheactualvariabilityand dependenciesbetweenvariationpoints.However,developmentlackstheknowledgeabout thevalueoffeaturesforcustomers.

Solution

Letscopingbeleadbyproductmanagement,butmakeitaniterativeandcollaborativeeffort betweenproductmanagementanddevelopment.Productmanagementinitiallysetsuptheproduct mapwithfeatureassignmentstoproducts.Developmentanalysesthefeatureindepthbydrafting designsandidentifyingtechnicaldependenciesbetweenvariants.Itmightforexamplebenecessary toincludecertainfeaturesintothecoreassetbasethatwouldnothavebeenselected,ifitwereonly basedontheirbusinessvalueforthecustomer,butbecausetheyarenecessarytodevelophigher prioritizedfeaturesefficiently.Theadditionaldependenciesandcostarefedbacktoproduct managementthatreͲestimatesthecost/benefitratioforfeaturesandproducts.Bothpartiesiterate overtheproductportfoliocommonlyandalternately.

Rationale

Whileproductmanagementisresponsibleforsettingupaproductportfoliothatoptimizesthe businessofanorganization,developmentisresponsibleforminimizingthecostofaproduct portfolio,potentiallyoptimizingreuseandtodecidewhetherafeaturesetcanbeimplementedina consistentplatformarchitectureatall.Neithercanproductmanagementestimateeffortsreliably,be itforproductͲspecificorcoreassets,norcandevelopmentdecideonprioritiesofproductsor

features.Thefeedbackfromdevelopmentofteninfluencestheproductportfoliodirectly.Product managementismadeawareofexistingknowledgeorassetsthatcanbemarketedbychangingthe portfolio.

ReferencesandKnownUses

FordecidingwhichfeaturesgointotheimagingplatformatSiemensHealthcare,datafromproduct managementisusedtocalculatethevalueofafeatureandfromarchitectstogetthecostof features.

(13)

E1Ͳ13

TheSiemenspostalautomationgroupandpartofthehotrollingmillautomationhaveproductline teamsinstalledthatconsistofproductmanagement(orsales)andarchitects.Togethertheydecide whetherafeatureisdevelopedintheplatformoronlyforonespecificsolution.

In[3]therisksofscopinginclude““scopeincludesthewrongproducts””.Further,theauthorsdescribe thatthereasontypicallyisthemissingcollaborationbetweenproductmanagementand

development.

(14)

E1Ͳ14

GeneralPatterns

RegularPlatformReleases

Context

Onlyalimitednumberofknowledgeablepeopleexistpercoreassetthatcanchangeorextenda specificcoreasset.Coreassetsfacehighdemandofchangeandextensionbytheproductsthatare reusingthem.Howdoyoumitigatethepressure?

Problem

Acceptingthehighpressure,specificallyregardingtime,canresultinseveralshortsightedsolutions.

x Severalbranchesofthesamecodepartsfordifferentproductsinparallel.Theconsequence ishighmergeeffortsbetweenthebranchesandoverheadofswitchingbetweenthe

branchesforindividualdevelopers.

x Highflexibilityofthecodepartstoacceptanyvariant,e.g.overly‘‘strategized’’designor creatinga#ifdefhell.

x Inurgentcasesapplicationdevelopersareinclinedtofallbacktocopy&pastereuse,oreven reͲwritethefunctionalityproductspecific.

Solution

Therefore,prioritizeyourtotalfeaturebacklogconsideringwhenreusablecomponentshavetobe availableforwhichproductsandprovidehighqualityreleasesregularly,e.g.every3months.Ifa platformuserurgentlyneedsanychangeorextension,thefeaturebacklogcanbereprioritized accordingly.

Rationale

Regularreleasesalleviatethehighpressurethattypicallyleadstomultiplebranches;hencebranches cantypicallybeavoidedoratleastminimizedintheirnumber.Inordertobeacceptedbythe

platformusersthequalityoftheregularreleasesmustbesufficientlyhigh.Fullyautomated

regressiontestsuitesthatareexecutedoneverychange,uptotheextentofContinuousIntegration, securethequalitywhileminimizingextraefforts.

However,providingregularreleaseschallengestheorganizationtodefineaproperversioning strategythatregulateswhichreleasesarecompatible,e.g.allminorreleases,andwhichreleases containincompatibleAPIchanges,e.g.majorreleases.

(15)

E1Ͳ15

FavorPlatformSimplicity

Context

Sourcecodeofreusableassetsgetscomplexveryeasy.OftenitisthewellͲintendedflexibility designedandimplementedbydevelopersthatincreasesthecomplexity.

Problem

Platformsareintendedforlongevity,butthehighcomplexityletsthemdiethetooͲcomplexͲandͲnotͲ maintainableͲanyͲmoredeadfasterthanexpected.Howdobuildthesimplestpossibleplatform?

x Platformdevelopmentisoftendefinedasprovidingthesoftwarewithenoughvariability mechanisms,suchasheavilyapplyingtheStrategypatternandallowingfordeclarative programmingviaconfigurationfiles.

x Hardwiringonlytheverycurrentrequirementsmightleadtomonolithicdesign,hencebadly maintainableandevolvablesoftware,too.

Solution

Therefore,establishthemindsetofthebeautyofsimplicity.Favorsimplicityinsteadofflexibility.

Firstly,differentiatebetweentheinherentcomplexityofaproblemandtheaccidentalcomplexity.At alltimesbeawareoftheinherentcomplexityofaproblem.

Forexample,thedemandedvariabilityofanapplicationdomainisinherentcomplexity,whilethe solutionapproach,e.g.flexibility,dynamicity,orgenericityaretypicallysourcesofaccidental complexity.InmanyregardsthisalsomeansthattheuseoftheclassicalGoFdesignpatternshasto belimitedtothebareminimum.Basicallyitis““Dothesimplestthingthatcouldpossiblywork””[9], whilenotobstructingfuturepotentialextension.

Reducingtheinherentcomplexityisonlypossiblebyreducingtherequiredvariability,whichinturn meansreducingthescopeoftheproductline.Accidentalcomplexitycanbeavoidedbydemanding thatallflexibilityintheplatformhastobejustifiedbyvariabilityinthechosenscopeoftheproblem space.

Rationale

Whilethesolutionmightsoundtrivial,itisnot.Withalltheintrinsicmotivationandcreativityofa typicalsoftwaredeveloper,onlylotsofdisciplineandexperiencewillallowhimtoactuallyfocuson theessentials.Simplicityshouldguideitselfontheactuallydemandedvariability,thescope,ofthe productline,notthegeneralinterestintechnology,preparingforallpotentialvariationsorthe applicationofthemostpatterns.Soinsomesensethispatternismeantasreminderofadheringto bestpracticeandpragmatism.Inhardwaredevelopmentcreatingflexibilityismuchmoreexpensive comparedtosoftware,henceoverlyͲflexibledesigninhardwareislessofanissue.

Theroleofthesoftwarearchitect,oftenalsocalledtechnicallead,iscrucialinthisaspect.Heguides theorganizationbyestablishingtherightmindset.Continuousreviewofdesigndecisionsby

developmentteamsallowshimgiveinputandpotentiallycorrectmisguideddesigndecisions.

(16)

E1Ͳ16

ReferencesandKnownUses

AttheimagingplatformdevelopmenteffortinSiemensHealthcarethispatternisappliedtoensure thelongevityoftheplatformaswellasthedevelopmentefficiencyoftheapplicationsontop.The groupintroducedthetrackingandtracingofdependenciesbetweensolutionandproblemspace variability.Duetotheregulatoryrequirements,whichalreadyrequiresomeextentoftracing,this stepwasnottoodifficult.Theadditionaltracingcausessomeoverheadinmaintaining,butonthe positivesideforcesdeveloperstodesignforsimplicity.

(17)

E1Ͳ17

BalanceConstraints

Context

Strategicandoperationaldecisionsneedtobemade.Everyprojectfollowstheconstraintsofthe projectmanagementtriangle[4].Mappedtotheareaofsoftwaredevelopmenttheyaredefinedas:

x Scope––thefunctionalityespeciallytheuniquesellingpointsofferedbyaproduct

x Quality––thedevelopmentalaswellasoperationalqualities,bothdeterminingthetotalͲcostͲ ofͲownership

x Time––thedurationittakestodeveloptheproduct,hencethetimeͲtoͲmarket

x Cost––thecostofpersonnel,mostlywages,andcostsfortheinfrastructure,likePCs,servers, building.Typicallythelargestpartofthecostisdirectlyrelatedtothedevelopmenttimeand involvedstaff.

Problem

Individualrolesinasoftwaredevelopmentorganizationtypicallyspannotallfourcategories,hence decisionscaneasilybeconcentratedonscope,quality,time,orcostonly.Theclassicalseparationis asfollows.

x Projectmanagementtypicallyfeelsmostresponsibleforthetripleconstrainttime,cost,and developmentalquality,suchasregulatorycomplianceandavailabilityofalldocumentation artifacts.

x Productmanagementtypicallyfeelsmostresponsibleforscope,time,andcustomervisible quality,likeperformanceandusability.

x Technicalleadership(architects)typicallyfeelsmostresponsibleforscopeand developmentalaswellasoperationalquality.

Lettingonlyoneortwooftherolesdecideonastrategyleadstopotentiallyunbalanceddecisions.

Solution

Witheverydecisionmakesureyouhaveabalancebetweenthefourconstraintsthroughthe involvedroles.Atypicalsteeringcommitteeshouldconsistofrepresentativesfromallstreamsof leadership(projectmanagement,productmanagement,technicalleadership).Onlythiswayyoucan makesurethatsounddecisionswithproperriskassessmentarebeingmade.

Rationale

Thepartitioningbetweenprojectmanagement,productmanagement,andtechnicalleadershipisthe classicalseparation.Agilemethodologyapproachesprovideaslightlydifferentpartitioning,e.g.

Scrumproductownersaretypicallybroadersetupandcareabouttime,scope,andquality.The Toyotaapproach[10]wouldevengosofartointegrateallconstraintsintoasingleperson:thechief engineer.Ofcourseinthiscasethereisnoneedanymoretobalancetheconstraints,besidesmaking sureyoupickthe‘‘right’’chiefengineerforyourbusinesssuccess.

(18)

E1Ͳ18

ReferencesandKnownUses

ManygroupsinSiemens,amongthemthepostalautomationgroupandthehotrollingmill automationgroup,intensivelyapplythispatterntotheiradvantage.Theyarewellawareofthe differentforcesofaprojectandusetherespectiveperspectivestotheadvantageofcreating innovativeandexcellentproducts.

(19)

Acknowledgements

WethankourshepherdJasonYipforhiselaboratecommentsandhispatience.Specialthanksalsoto ourWriter’’sWorkshopgroupatEuroPLoP2009:ReneBredlau,EduardoFernandez,ClaudiusLink, KlausMarquart,DietmarSchütz,MarkusVölter,andAlainͲG.VouffoFeudjio.Inthispaperwebase onthefoundationslaidbyauthorslikeKlausSchmid,LindaNorthrop,andPaulClements.Our learningcontinuedoutoftheirproductlineengineeringexperiences.

Terminology

Coreasset––Asetofreusableartifacts,i.e.requirements,domainmodels,architecture,patterns, concepts,documentation,testcases,budgetplans,workplans,process,tools,workflowsandcode assets.

Platform––Thesumofallcoreassetsistypicallycalledtheproductlineplatform.However,theterm platformissometimesalsousedforabaseoftechnologiesonwhichothertechnologiesorprocesses arebuilt[1],e.g.anoperatingsystem,middlewareorcomponentcontainer.Inthispaperwereferto thefirstinterpretation.

Mission,Vision,Strategy––Mission=whydoIexist?Vision=wherewouldIliketobe?Strategy=

howwouldIliketogetthere?

TotalͲcostͲofͲownership(TCO)––Thesumofallcostsrelatedtodeveloping,maintaining,supporting, installing,servicing,andowningacertainproductoftheprovidingaswellasreceivingparty.

TimeͲtoͲmarket(TTM)––Thetimeittakestodeliveraproductfrominitialconceptiontoactual availabilityonthemarkettobeboughtbycustomers.Thelongerthedelaythehigherthechancesfor thecompetitionbringtheirproductsintothemarketandendangerthepotentialmarketsharefor theownproduct.

Projectmanagementtriangle––Thetriangledescribestheconstrainingrelationshipbetweenscope, time,andcostassumingthequalitytobefixed.Allareinterrelated;youcannotchangeanyofthem withoutadoptingtheothers[4].

Scoping––Scoping[1][3][5]isanactivitytofindtheboundariesofaproductlinethatcanbedivided intothreesubͲsteps[6][7]:productlinescoping,scopingthedomain,andscopingthereusableassets (platform).Theobjectiveofproductlinescopingcomprisesdefiningthesetofproductsandthemain featurestobeincludedintheproductline.Domainscopingrepresentstheprocessofidentifying appropriateboundariesforthesubͲdomainsoftheoverallproductline.Scopingtheassetsresultsin thedecisionwhichoftherequiredfunctionalityadevelopmentorganizationshouldimplementas reusablebaseassetsandwhichitshouldconsiderproductspecific.Forsimplicitywecansticktothe

E1Ͳ19

(20)

E1Ͳ20

followingdefinition:Scopingmeanssettingthefocusofreuseonthefunctionalitythatpromisesan optimalreturnoninvestment[8].

ApplicationandDomainEngineering––DomainEngineering(DE)isthesubͲprocessofPLEthatis responsibleforbuildingandmanagingreusablebaseassets,whileApplicationEngineering(AE)is aboutbuildingproductsorsolutionsfromthesebaseassets.Variationinorganizationforms––PLE organizationsmaybesplitinaDomainEngineeringpartthatisresponsibleforimplementingthecore assetsandseveralApplicationEngineeringpartsthatbuildproducts/solutionsbasedthecoreassets andaddingproductspecificfeatures.

Alternatively,PLEorganizationsmayaswellbedividedalongsubͲdomainsthatdoboth,

developmentofcoreassetsandproduct/solutiondevelopment.ThissetupiscommoninmaturePLE organizations,mostlyforsolutiondevelopment.Suchadivisionisveryefficientsincenohandover betweenthetwodisciplinesisnecessary.Howtosetupthebestorganizationforaproductline wouldbeapatternlanguageonitsown.

Proactiveevolution––Coreassetsareidentifiedupfrontanddevelopedforreuse.

Reactiveevolution––Creationofcoreassetsbasedonexisting,previouslyproductͲspecificassets.

(21)

E1Ͳ21

References

[1]Pohl,Böckle,vanderLinden,SoftwareProductLineEngineering,Springer,2005

[2]KlausSchmid,PlanningSoftwareReuse––ADisciplinedScopingApproachforSoftwareProduct Lines,Dissertation,FraunhoferIRBVerlag,2003

[3]Clements,P.&Northrop,L.SoftwareProductLines:PracticesandPatterns,AddisonͲWesley,2002 [4]http://en.wikipedia.org/wiki/Project_triangle

[5]K.CzarneckiandU.W.Eisenecker,GenerativeProgramming.Methods,Tools,andApplications.

Amsterdam:AddisonͲWesleyLongman,2000.

[6]JanBosch,DesignandUseofSoftwareArchitectures:AdoptingandEvolvingaProductͲLine Approach,AddisonͲWesleyReading,2000.

[7]KlausSchmid,SteffenThiel,JanBosch,SusanneJohnsson,MichelJaring,BernhardThomé, SiegfriedTrosch,Scoping,EASPSconsortiumwidedeliverableCWD1.2.4,2001.

[8]KlausSchmid,AComprehensiveproductLineScopingApproachandItsValidation,InProceedings ofthe24thInternationalConferenceonSoftwareEngineering(ICSE2002),ACMPress,2002,pp.593Ͳ 603

[9]XPguidance““Dothesimplestthingthatcouldpossiblywork””

[10]http://www.poppendieck.com/leadership.htm

Références

Documents relatifs

In addition, the separation in two independent components between PL expression derivation and UML2 state machines processes allows using PLiBS in the context of

The contribution of this paper is to propose architectural constraints for Product Line expressed in UML as meta-level OCL constraints, providing a set of patterns for

We propose a MAS-PL approach to address the aforemen- tioned issues by representing Generic MAS variability according to MAS concepts such as agents, environment, interaction

We will explore the product configuration using other variability modeling techniques such as text variability modeling or domain specific language, which will be compared to the

First, a set of extensions are proposed to model product line variability in two types of UML models: class diagrams (the static aspect) and sequence diagrams (the

The review included literature published from 2000 to 2013 reporting on research issues for ERP configuration and customization using software product line techniques..

VariaMos (Variability Models) is an Eclipse plug-in for specification, automatic verification, analysis, configuration and integration of multi-view product line

Keywords: multi-level modelling, domain specific modelling languages, con- figuration, variability, software product line engineering, feature modeling.. 1