ContentslistsavailableatSciVerseScienceDirect
The
Journal
of
Systems
and
Software
j our na l h o me p a g e :w w w . e l s e v i e r . c o m / l o c a t e / j s s
MDE
software
process
lines
in
small
companies
Julio
Ariel
Hurtado
a,b,∗, María
Cecilia
Bastarrica
a, Sergio
F.
Ochoa
a, Jocelyn
Simmonds
c aComputerScienceDepartment,UniversidaddeChile,ChilebIDISGroup,SystemsDepartment,UniversidaddelCauca,Colombia cInformaticsDepartment,UniversidadTécnicaFedericoSantaMaría,Chile
a
r
t
i
c
l
e
i
n
f
o
Articlehistory:Received28November2011 Receivedinrevisedform 20September2012 Accepted25September2012 Available online 20 November 2012 Keywords:
Softwareprocesslines Model-drivenengineering Processassetreuse
a
b
s
t
r
a
c
t
Softwareorganizationsspecifytheirsoftwareprocessessothatprocessknowledgecanbesystematically reusedacrossprojects.However,differentprojectsmayrequiredifferentprocesses.Defininga sepa-rateprocessforeachpotentialprojectcontextisexpensiveanderror-prone,sincetheseprocessesmust simultaneouslyevolveinaconsistentmanner.Moreover,anorganizationcannotenvisionallpossible projectcontextsinadvancebecauseseveralvariablesmaybeinvolved,andthesemayalsobecombined indifferentways.Thisproblemisevenworseinsmallcompaniessincetheyusuallycannotaffordto definemorethanoneprocess.Softwareprocesslinesareaspecifictypeofsoftwareproductlines,inthe softwareprocessdomain.Abenefitofsoftwareprocesslinesisthattheyallowsoftwareprocess cus-tomizationwithrespecttoacontext.Inthisarticleweproposeamodel-drivenapproachforsoftware processlinesspecificationandconfiguration.Thearticlealsopresentstwoindustrialcasestudiescarried outattwosmallChileansoftwaredevelopmentcompanies.Bothcompanieshavebenefitedfrom apply-ingourapproachtotheirprocesses:newprojectsarenowdevelopedusingcustomprocesses,process knowledgeissystematicallyreused,andthetotaltimerequiredtocustomizeaprocessismuchshorter thanbefore.
© 2012 Elsevier Inc. All rights reserved.
1. Introduction
Softwaredevelopmentlifecycles,fromtraditionalmodelslike Waterfall,tomoremodernoneslikeRUP,ScrumandXP,suggest specificactivitiesthatneedtobecarriedoutaspartofthe devel-opmentprocess,aswellastheorderoftheseactivities.Moreover, ifacompanywantstocertifyorevaluateitssoftwaredevelopment process,thisprocessmustberigorouslydefinedasprescribedby themostpopularmodelsandstandards(e.g.,CMMI,2006;ISO/IEC 12207, 2008). Specifying an organizational process requires an enormousamountofeffort,andtheresultingprocessmuststillbe adaptedinordertosatisfythespecificcharacteristicsofdifferent projectsettings(MirbelandRalyté,2006).
There is no optimal software process since appropriateness dependsonvariousorganizational,projectandproduct character-isticsand,evenworse,thesecharacteristicsevolvecontinuously. Therefore,aone-sizefits-allapproachdoesnotworkforsoftware development(Firesmith,2004).Eachprojecthasitsown character-isticsandrequiresaparticularrangeoftechniquesandstrategies
∗Correspondingauthorat:IDISGroup,SystemsDepartment,Universidaddel
Cauca,Colombia.
E-mailaddresses:[email protected](J.A.Hurtado),[email protected] (M.C.Bastarrica),[email protected](S.F.Ochoa),[email protected] (J.Simmonds).
(LaplanteandNeill,2004).Theprocessofselectingasetof prac-ticesandthenintegratingthemintoacoherentprocessmustalsobe alignedwiththebusinesscontext(Cusumanoetal.,2009).Basedon thefindingspresentedinDörretal.(2008),wesupporttheideathat aproject’scontextmustbetakenintoaccountwhendecidingwhich processvariantbestfitstheproject.Additionally,thespecific pro-cessappliedshouldnotvarydramaticallyfromprojecttoproject, sothattheprocessknowledgeacquiredbythedevelopmentteam canbereused.
Theprocessthroughwhichageneralsoftwareprocessis con-figured in order to adapt it to a project’s particular setting is known as tailoring (Pedreira et al., 2007). In other areas, like SituationalMethodEngineering,thisprocessisalsoknownas con-figuration.Inthiswork,weconsiderconfigurationandtailoringas synonyms.Empiricalstudiesshowthatprocesstailoringisdifficult becauseitinvolvesintensiveknowledgegenerationand deploy-ment(Rolland,2009),anditisalsotime-consuming(Ocampoetal., 2005).Moreover,theexpertiserequiredtoproduceagoodprocess tailoringmaybelostfromoneprojecttothenext.Therefore,the tailoringprocessitselfishardtoreplicateanddoesnotscaleifdone manually.
Weapplytwocomplementaryapproachestoprocesstailoring:
model-drivenengineeringandsoftwareprocesslines.Model-driven engineering(MDE)isasoftwaredevelopmentapproachthat advo-catesthecreationofabstractmodels,whicharethensystematically transformedintomoreconcretemodels,andeventuallyintosource
0164-1212/$–seefrontmatter© 2012 Elsevier Inc. All rights reserved. http://dx.doi.org/10.1016/j.jss.2012.09.033
Fig.1.Theproductlineengineeringframework(Pohletal.,2005),adaptedtoallow softwareprocesslinedevelopment.
code(Schmidt,2006).Thisapproach promotesreuse through a generativestrategy.MDEcanalsobeusedinthesoftwareprocess engineeringdomain(BretonandBézivin,2001),where transforma-tionsareusedasinstantiationstrategies(Killispergeretal.,2009). Onthe otherhand,a software productline(SPL) is a setof software-intensivesystemsthatshareacommonandmanagedset ofassetssatisfyingthespecificneedsofaparticularmarketsegment ormission(ClementsandNorthrop,2001).Teamproductivityand productqualityincreaseasaconsequenceoftheresultingmassive reuseofassets.Analogously,softwareprocesslines(SPrL)isaset ofsoftwareprocesses,builtfromaseriesofsharedprocessassets inordertoreuseprocessknowledgeacrossprojectswithdifferent needs.AccordingtoRombach,aSPrLisasystematicmechanismfor managingaprocessanditsvariants(Rombach,2005).
The FAST (Family-Oriented Abstraction, Specification, and Translation) process(Weiss and Lai, 1999), which was particu-larlyproposedtodefineproductsfamilies,separatesproduct-line engineeringprocessintotwomainstages:domainengineeringand
productengineering.Indomainengineering,commonandvariable elementsareidentified,aswellashowthesemaybecombined inordertogenerateparticularproducts.Eachoftheseelementsis implementedasareusableasset.Duringtheproductengineering stage,membersoftheproductfamilyarebuiltusingthepreviously definedassets.
EachstageoftheSPLdefinitionisfurthersubdividedintoother phases: analysis, design, implementation and verification (Pohl etal.,2005).InFig.1,weshowhowtheanalysisanddesignphasesof domainandproductengineeringwereadaptedtoallowthe devel-opmentofSPrLs.TheactivitiesinvolvedintheseSPrLphasesare describedintherestofthearticle.Wealsoshowtheirapplication intwoindustrialcasestudies.
Thus, themain contributionof this articleis an MDE-based approachtosoftwareprocess lineanalysisanddesign, focusing onprocesstailoringwithrespecttoacontext.Therearemultiple advantagestocombiningMDEandSPrL:byexplicitlyspecifying implicittailoringknowledgeastailoringtransformations(as pro-posedbyMDE),andbycreatingagenerallibraryofreusableprocess assets(asproposedbySPrL),wecansystematicallytailorgeneral, reusableprocesseswithrespecttoaspecificprojectcontext.
SmallSoftwareOrganizations(SSO)hasparticular characteris-ticsthataffecttheirsoftwareprocessesandmakethemdifferent frommedium-size and largeorganizations.Onlysomeof these companieshavearigorousorganizationalstructureandaformally defineddevelopmentprocess(vonWangenheimetal.,2006a,b). Theyusuallyworkonsmallprojects,involvingsmallgroups(Batista andDeFigueiredo,2000;Harrisetal.,2007),andbasingtheir com-petitivenessonbeingspecialized(Arandaetal.,2007).Therefore,
a successfulSSOis usuallylinked toaparticular niche(Aranda etal.,2007;Jantunen,2010)whichmakesthedevelopmentcontext ratherstableandthusreducestherequiredvariabilityofthe orga-nizationalsoftwareprocess.Thesecompaniestypicallyconsidera fewprojectcontextvariables(Hofer,2002),butdifferent configu-rationsofthesevariablesrequiredifferentdevelopmentprocesses (Hurtadoetal.,2011).Wehavevalidatedourapproachintwosmall companies:KITeknologyandAmisoft.Theseorganizationsare con-sideredsmallaccordingtoEuropeanCommission(2005)because theybothhavearound50employees,andtheirannualturnover doesnotexceed10millionEuros.Theselectedcompaniesdevelop softwarefornichemarkets(Arandaetal.,2007;vonWangenheim etal.,2006b),sothedomainandtechnologydonotchange dra-maticallyfromprojecttoproject.KITeknologydevelopsweb-based applicationsandAmisoftfocusesonjudiciaryinformationsystems. Therestofthepaperisstructuredasfollows.Section2presents therelatedwork.InSection3,wedescribethetailoringprocess,as wellasthemodelsandtransformationsrequiredbyourapproach, illustratingthesewitharunningexample.InSections4and5,we describetwocasestudieswhereweappliedtheproposedtailoring approach.Finally,Section6presentstheconclusionsandfuture work.
2. Relatedwork
Inthissection,wefirstgiveabriefoverviewofsoftware prod-uct lines and software process lines. We then discuss several approachestosoftwareprocesstailoring,andfinally,wereview variousproposalsforrepresentingandusingcontextinformation.
2.1. Softwareproductlinesandsoftwareprocesslines
Given that software processes are software too (Osterweil, 1987),asoftwareprocessline(SPrL)canbeconsideredasaspecial softwareproductline(SPL)inthesoftwareprocessengineering domain.ProcessesinaSPrLsharecommonfeatures andexhibit variability(StanleyandOsterweil,1996).Consequently,aSPrLis anidealwaytodefine,tailorandevolveasetofrelatedprocesses, anopinionthatissupportedbytheworkonprocessvariability representation(Simidchievaetal.,2007),processfamilies(Rolland andNurcan,2010),SPrLarchitectures(Washizaki,2006),process domainanalysis(Ocampoetal.,2005),andSPrLscoping(Armbrust etal.,2009).Aclassictailoringapproachreactivelyintegrates unan-ticipatedvariabilityintheprocessmodel(Armbrustetal.,2009), whileaSPrLapproachfacilitatesplannedreuse.Nevertheless,as statedinDeelstraetal.(2005),derivingproducts(processes)inthe contextofaSPL(SPrL)isachallengingtask.
SPEM2.0(OMG,2007)istheOMGstandardformodeling soft-wareandsystemsdevelopmentprocessesandtheircomponents. VarioussmallChileansoftwaredevelopmentcompanies,aspartof theTutelkánproject(Valdésetal.,2010),formalizedtheirprocesses usingSPEM2.0.Thisstandarddefinesfourprimitivesforspecifying variability,whichmustbespecifiedbetweentwoprocesselements ofthesametype:
1. Contributes:asourcevariabilityelementcontributesits proper-tiestothetargetvariabilityelementwithoutdirectlyaltering anyofthetargetelement’sproperties.Thetargetelementtakes onanyextraattributesandassociationsdefinedbythesource element,exceptforthosealreadydefinedbythetargetelement. 2.Replaces:asourcevariabilityelementreplacesitstarget variabil-ityelement.Inthiscase,onlytheincomingassociationsofthe targetelementarepreserved,boththetarget’sattributesand outgoingassociationsarereplacedbythesourceelement’s.The
targetofmultiplereplacesrelationscanonlybereplacedbyone sourceelementinaconfiguration.
3.Extends:asourcevariabilityelementextendsthedefinitionof itstarget variability element,possiblyoverridingthe target’s attributesandassociations.
4.Extends-Replaces:inthisrelationship,asourcevariability ele-mentfirstextendsitstargetvariabilityelement,andthenreplaces
it.
Instancesoftheserelationsmayoverrideeachother,so variabil-ityrelationsmustberesolvedinthepresentedorder.Theprocess tailoringstepissuccessfuliftheprocessengineercanresolveaway allvariabilityinanon-conflictingmanner.Apriori,itishardto predicthowvariabilityrelationsinteractwitheachother,whichis whytheSPEM2.0variabilitymechanismsarerarelyusedinpractice (Martínez-Ruizetal.,2011).
2.2. Tailoringapproaches
Thereareseveralapproachestoprocesstailoring,whichmainly differintermsofexpectedprocessformality,sizeofthecompany, and available tool support(Pedreiraet al., 2007).For example, theassembleapproachpresentedinDaiandLi(2007)providesa reducedsetofprocessmodificationactions(add,delete,splitand mergeoperation),whichareusedto“assemble”anewprocessfrom apreviousversion.TheunderlyingformalismisPetrinets,andas such,processmodelsonlyconsiderprocessactivities,ignoringroles andworkproducts,andtherearenovariableelements.Also,the projectcontextisnotformallyusedtoguidetheadaptationprocess, astailoringisdoneinanadhocmannerbytheprocessengineer, whoselectswhatactiontoapplyandwhen.
Thesituationalmethodengineering(SME)approachfocuseson project-specificprocessconstruction(Ralytéetal.,2003),where pre-existing pieces of methods are selected and combined in an attempt to produce the most appropriate process for an organization or a project. This is an active research area, see (Henderson-SellersandRalyté,2010;Tolvanenetal.,1996)for sur-veysonthesetechniques.SMEtechniquescanbeusednotonlyto customizeasoftwaredevelopmentprocesstoaparticularproject context,butalsotoperformacontinuousimprovementprocess (Bajec etal.,2007a,b).Nevertheless,inmostcasestheeffortfor tailoringtheprocess is stillhuge, especially when anassemble approachisadopted(MirbelandRalyté,2006).Thisisabig prob-lembecauseprocesstailoringisnormallytheresponsibilityofthe projectmanager,butitrequirestheexperienceandknowledgeofa softwareprocessengineer,soitisdifficulttoachieveareasonable separationoftheirtasks(Baietal.,2012).Thetwomost signifi-cantchallengesfortheSMEcommunityaretherateofindustry adoptionandhowtoautomatethemethodconstructionprocess (Henderson-SellersandRalyté,2010).ProvidedthatSMEfollowsa bottom-upapproach,itisacreativetaskandrequiresthe knowl-edgeandexperienceofamethodengineer;thus,automationin SMEisverycomplexifpossibleatall.Instead,ourapproachusesa top-downstrategy,whereaprocessstructureincludingvariation pointsandtheirvariantsaredefined.Inourapproach,the flexibil-ityiscontrolledandonlysomeprocesscouldbedefinedaccording tothevariationpoints.However,thislimitedvariationallowsusto implementapracticaltransformationalstrategyforautomatically generatingeachprocess.Hence,ourapproachfollowsatrade-off criterionbetweenflexibilityandpracticality.
SomeprocessesliketheUnifiedProcess(Jacobsonetal.,1999) useanadjustmentguideapproach,wheretailoringrulesare spec-ifiedasgeneralguidelinesabouthowtoadaptphases,iterations anddisciplinesaccordingtoproject-specificsituations.Thiswas theapproachoriginallyfollowedbyKI,thecompanysubjectofour firstcasestudy(seeSection4).Thesuccessfulapplicationofthis
approachhighlydependsontheprocessengineer,whomustbe carefultobeconsistentwithhowtheseguidelinesareappliedto differentprojects(eachonewithapotentiallydifferentcontext).
Agile methods such as XP (Beck and Andres, 2004) usean
auto-adaptable approach, where theproject- and team-adapted processemergesfromthesetofprinciples,valuesandpractices thatdefinetheagilemethodology.OtherprocessessuchasCrystal Methodology(Cockburn,2000)followatemplate-basedapproach, whereafamilyofmethodologytemplatesaredefined(Clear, Yel-low,Orange andRed),andeach templateis moredetailedthan thelast.Commercialprocesses,suchasRUP(Kruchten,2003),use aframework-basedapproach(BelkhatirandEstublier,1996)(also knownasa configurationapproach),wherea generalprocessis defined anda specific configurationis createdfor eachspecific project.Processesdevelopedusingthisapproachtendtobelarge andcomplex,andahighlevelofprocessengineeringknowledge isrequiredtoproducevalidconfigurations,whereasthedifficulty ofthetemplatestrategyisthatitishardtodefineanadequateset oftemplatesthatsatisfyallthepossibleprojectscenarios(Bustard andKeenan,2005).
Killisperger et al. (2009) propose an instantiation-based
approach;itconsistsofdefiningageneralprocessthatis instan-tiatedforeachprojectuptotheenactmentlevel.Thisapproach requiresanenormousamountofprocessformalizationinorderto obtainalloftheexpectedbenefits.Inourwork,wetailorthegeneral processaccordingtothecharacteristicsoftheprojectcontext,and theresultingSPEMprocessservesasaprocessguide.However,we donotreachtheenactmentlevelasthisisnotsupportedbySPEM.In thisarticle,werepresentprocessmodelvariabilityusingaprocess featuremodel,similartoasoftwareproductfeaturemodels(Kang etal.,1990),andtheorganizationalsoftwareprocessismodeled usingeSPEM,ametamodelincludingthecoreSPEMconceptsand relationsrequiredbyourproposedtailoringmechanism.TheMDE strategyweapplyhelpsachieveaseparationbetweentheprocess modelingstakeholdersandprocessenactment(project) stakehol-ders(Baietal.,2012),andithidesthecomplexitybyintensively reusingtailoringknowledge.
2.3. Contextmodeling
Contextrepresentationinsoftwaredevelopmenthasgained rel-evancelately,particularlybecauseofitsuseinsoftwareprocess tailoring.However,itsdefinitionandscopedifferinalmostevery proposal.Theliteraturereportstheuseofthecontexttoaddress severalchallenges,e.g.,estimatingprojectcosts,selectingthe soft-wareprocesstobeusedinaparticularproject,orcharacterizing aSPrL.Mostcontextrepresentationsinvolvespecificationsintext (KettunenandLaanti,2005;Xu,2005),tables(Killispergeretal., 2009;KoolmanojwongandBoehm,2012)orsomekindsof check-lists(MaandWang,2006;Parketal.,2006),whicharenotalways ineasy-to-processformats.
TheworkofPérezetal.(1995)presentsasetofcontext char-acteristics related with processes. Such context characteristics supportthecustomizationofsoftwareprocessmodels.Armbrust etal.(2009)definethreedimensions(orcontextvariables)todefine thecontextcharacteristicsintheSPrLscopedefinition:product, projectandprocess.TheCOCOMOIImodel(Boehmetal.,1995) definesasetofattributesanddimensionsthathelpestimateproject metrics.Suchcontextvariablesarealsousefulforrepresenting con-textmodels.TheIncrementalCommitmentModel(ICM)process (KoolmanojwongandBoehm,2012)definesfourprocesspatterns for rapidprocessdeployment usingcontextualizedinformation, processesfornewprojectsarederivedfromthesepatterns.Zowghi etal.(2005)proposeastrategytodefineanappropriate require-mentsengineeringmethodthatiswell-suitedfor theparticular systemorapplicationdevelopmentendeavorunderconsideration.
Fig.2. Generativestrategyforprocesstailoring.
Thecontextinformationusedtoperformthisactivityisembedded inasetofguidelinesusedassupport.
Kornyshovaetal.(2010)describethecontextdimensionsand variablesaffectingthetailoringprocessintheinformationsystems domain.Theyalsopresentaprocessforcontextualizingmethods andselectingmethodcomponentsbased ontheproject charac-teristics.ThecontextmodeldescribedinKornyshovaetal.(2010)
is focused onthe contextualization of method components for selectingandreusingmethodcomponentsinsteadoftailoringthe softwareprocesstoaspecificsituation.Thecomponentselection iscarriedoutusingqueriesonthevaluesofthecharacteristicsof theavailablemethodcomponents.Ifthequerydoesnotprovide aconclusiveresult,themethodengineercouldconsidererother methods,modifytherequiredcharacteristics’values,orrank char-acteristicsbytheirorderofimportance.Ourapproachusescontext informationtoidentifytherelationshipbetweentheprocess vari-abilityandcontextattributes,andattailoringtimealsotodefine thespecific situation(context attribute values) where the pro-cessmodelwillbeapplied.Whereasmethodcomponentscontext is oriented to method reuse following a bottom-up approach, project-specificcontextisorientedtoprocessadaptationfollowing atop-downapproach.
Hurtadoetal.(2011)presentasurveyofcontextrepresentations thatcanbeusedfortailoringsoftwaredevelopmentprocesses,and alsoasimplelanguagetorepresenttheprojectcontexts.Our pro-posalusesthislanguagetorepresentsoftwarecontextmodels.
In order to help organizations to determine their relevant dimensionsandcontextattributestoperformthetailoring activ-ities, we have defined a Software Process Context Metamodel, basedontheideaspresentedinHurtadoandBastarrica(2009).We describethismetamodelinSection3.2.
3. Tailoringthesoftwareprocess
Definingan organizationalsoftwareprocess isnecessaryif a companywantstoimprove itsdevelopmentprocess,and abso-lutelynecessaryinordertoachieveanevaluationorcertification suchasCMMIorISO/IEC12207.Althoughdefiningand document-ingageneralprocessrequiresasignificantamountofwork,this processisnotnecessarilyappropriateforallprojects,evenwithin the same organization. Moreover, an organization that usually developscertaintypesofprojectsusingaparticularprocessmay eventuallybecomeinvolvedinadifferenttypeofproject,andthus theprocessthatworkedwellbeforebecomesinadequate.Defining
acustomizedprocessforeachprojectistooexpensiveduetothe amountofresourcesthiseffortwouldconsume,resourceswhich couldbeusedbytheprojectinstead.Havingasetofpredefined pro-cessesforaseriesofdifferentcontextsimpliesahighmaintenance cost,anditstilldoesnotensurethatallpossiblecontextsaretaken intoaccount.Therefore,tailoringtheorganizationalprocessseems tobeagoodtrade-off.
Fig.2presentsanoverviewofourproposedtailoringapproach, whichusestwomodelsasinput:thesoftwareprocessmodelandthe
contextmodelforaspecificproject.Then,usingasetof transforma-tionrules(embeddedinthetailoringtransformationcomponent), thesoftwareprocessistailoredaccordingtotheprojectcontext modelinordertogeneratetheadaptedsoftwareprocessmodel.This tailoringproposalwasbrieflyintroducedinHurtadoetal.(2012b), andisillustratedwithanexampleintherestofthissection.
TheinputsoftwareprocessmodelisaneSPEMmodelthat repre-sentsthegeneralorganizationalprocessthatwillbetailored.This modelmustbecustomizedatthebeginningofeachnewproject. eSPEMmodelsconsistoftask,workproductandroledefinitions, aswellasaspecificationofhowtheseprocesselementsinteractin ordertoaccomplishtheprocess’sgoals.Theinitialsoftwareprocess modelincludesthespecificationofitsvariability,whichisresolved throughthetailoringprocessinordertoachievetheadapted soft-wareprocessmodel.
In ourtailoringapproach, theorganization must alsodefine thecontextmodel,whichisusedtodescribethedifferenttypesof projectsthatthecompanyhandles.Thiscontextmodelspecifies rel-evantprojectvariables(e.g.,theprojecttype),theirpossiblevalues (e.g.,developmentormaintenance),aswellashowthesevariables areclassifiedalongdifferentdimensions.
Thetailoringtransformationcomponent,thatinvolvesthesetof transformationrulesexpressedinATL(Jouaultetal.,2006), indi-catesunderwhichconditionsthegeneralprocessmodelshould change,andhow.Ruleconditionsareexpressedusingthecontext variablesandvalues,andvalidprocesschangesincludetask,work productandroleinclusion/elimination,aswellaschoosingfroma setofpossiblealternatives.Inthecaseoforganizationswithmature developmentprocesses,theserulescanusuallybededucedfrom (semi-)formalgeneralprocessadaptationguidelines.Inothercases, theserulesmustbeformalizedfromscratchorreverse-engineered fromexistingprojects.Thisformalizationisoneofthemost diffi-cultstepsintheproposedapproach,butoncethetransformation rulesareformalizedandvalidated,tailoringbecomessimpler,more consistent,andlesserror-prone.
Fig.3.TheexperimentalSPEM(eSPEM)metamodel,wheretheprocesselementmetaclassesthatcanvaryhavebeenmarked.
Wehavedevelopedaproof-of-concepttoolchaintosupportour empiricalwork.ThistoolchainisbuiltontopoftheEclipse Mod-elingFramework–EMF3.41andtheATLplug-in2.0.2Metamodels
weredefinedasecore metamodelsinEMFand the transforma-tionswereimplementedasATLrules.Modelswereimplementedas instancesofdefinedmetamodelsandeditedusingExeed(Extended EMFEditor),theEMFreflectiveeditor.
In this section,we first definethe models and metamodels involved in the proposedtailoringapproach, and then the ATL transformationsthatimplementthetailoringprocess.Allstepsare illustratedusingasimpleexample.
3.1. Organizationalprocessmodel
SPEM2.0(OMG,2007)istheOMGstandardformodeling soft-wareandsystemsdevelopmentprocessesandtheircomponents. SPEM2.0isdefinedbothasaMOFmetamodelandasaUML2.0 profile,andtakesanobject-orientedapproachtoprocessmodeling. SPEMdiagramsareusedtomodeltwodifferentviewsofaprocess: astaticview,whereprocesscomponents(tasks,workproductsand roles)aredefined;andadynamicview,whereinteractiondiagrams (likeUMLactivitydiagrams)areusedtomodelhowprocess com-ponentsinteractinordertoaccomplishthegoalsofthemodeled process.
Inordertoencourage processmaintenanceand reuse,SPEM 2.0makesadifferencebetweenthedefinitionofprocessbuilding blocksandtheirlateruse.Processcomponents,liketasks,rolesand workproducts,aredefinedandstoredinaMethodLibrary.An activ-ityisa“big-step”groupingofrole,workproductandtaskuses,and activitydiagramsareusedtomodeltheworkflowbetweentasks oftheactivity.Rolesperformtasks,andworkproductsserveas input/outputartifactsfortasks.
InSPEM,aprocessisasetofactivities,wheretherelationship betweentheseactivitiesisalsospecifiedasaworkflow.Task,role, workproductandactivitydefinitionsarerecommendationsmade byaprocessengineer,sothesecanbeoverriddenwhencreating anewprocess,e.g.,byadding/removingtheassociationbetweena workproductandatask.
In our approach, process models are defined using eSPEM (Hurtado et al.,2012b), a SPEM2.0 subset,which is expressive enoughforourexperimentalpurposes.ThemetamodelforeSPEM isshowninFig.3.Task-,Role-andWorkProductDefinitionare sub-classesoftheMethodContentElementmetaclass,whichinturnis
1EMFwebsitehttp://download.eclipse.org/tools/emf. 2ATLwebsitehttp://www.eclipse.org/downloads/.
asubclassoftheVariabilityElementmetaclass.Ontheotherhand,
Activity, Task-, Role- and WorkProductUse are subclasses of the
WorkBreakDownElementmetaclass.AVariabilityElementisaprocess elementthatcanbemodifiedorextendedbyother VariabilityEle-mentsofthesamekindthroughavariabilityrelationship(defined bytheVariabilityTypeenumeration).
WeuseVariabilityElementstoimplementalternatives(labeled withanalternativesymbolsimilartothatusedinfeaturemodels). AsetofalternativescanbedefinedfromthesameVariabilityElement
(whichmaybeabstract).So,whenaProcessElementislinkedtothe
VariabilityElement,oneofthesealternativescouldbeselected.For example,aTaskUsecanbelinkedtooneofmanyavailableand con-sistentTaskDefinitions.Additionally,eachWorkBreakDownElement
canbeconsideredasoptionalornotaccordingtotheisOptional
attribute.Optionalelementsarelabeledwithanemptycircle. For example, the general requirements engineering process showninFig.4isapartoftheoveralldevelopmentprocessfollowed by students taking CC51A, an advanced software development coursetaughtattheUniversityofChile.Thisprocessconsistsof three activities: Exploration, User Requirements Specification and Validation,andSoftwareRequirementsSpecificationandValidation, carriedoutinsequence.Themaingoalofthiscourseistoexpose seniorstudents,ingroupsof5–6,toareal-lifeworkenvironment, developingrealapplicationsforrealclients.Theprocessitselfis simplebecausestudentsonlyhavefourmonthstocompletetheir projects.Fig.5showstheeSPEMspecificationofthisprocess.
Fig.5.eSPEMmodeloftheCC51Arequirementsengineeringprocess.
DuringtheExplorationactivity,theclient,analystandproject managermeetinordertodefinetheproject.Occasionally,aclient showsupwithaclearlydefinedprojectandthisactivityisnot nec-essary,whichiswhyitismarkedasoptional(enclosedinayellow box).Thisnotationisadhoc,sincetheSPEMstandarddoesnot recommendhowtovisuallyindicateelementoptionality.During theUserRequirementsSpecificationandValidationactivity,theteam membersspecifythegoalsandscopeoftheirprojectintermsof userrequirements.Performingthisactivitymayinvolvetheuseof simpleprototypesthathelpclientsandteammemberstovalidate theuserrequirementsandconceivethehigh-levelsolution.This activitytakesasinputaprojectdefinition,andproducesasoutput auserrequirementsspecification.
DuringtheSoftware RequirementsSpecification andValidation
activity,each user requirement is translated into one or more
softwarerequirements.Theresultinglistrepresentsthesoftware requirementsspecificationfortheproject(whichmustbevalidated bytheusersandclients).Iftheteammembersarefamiliarwiththe projectdomain,thisvalidationcanbedoneinternally;otherwise, theteammustcreateanoperationalprototypeandvalidateitwith theclient.
Following a general approach for specifying variability in DomainEngineering,we usefeature models(Kanget al.,1990) toformallyspecifyprocessvariabilityata highlevelof abstrac-tion(SimmondsandModeling,2011).Featuresrepresentactivities, tasks,rolesandworkproducts,andweallowcross-treeconstraints betweenfeaturesofanykind.
Forexample,thefeaturemodelinFig.6showsboththe com-monandvariableelementsoftheCC51AREprocess.Thismodel showstheSoftwareRequirementsSpecificationandValidation activ-ityinmoredetail,breakingitdownintothreeparts:aSoftware Requirements Specification task, an (optional) Operational Proto-typingactivity,anda Software RequirementsValidation task.The
SoftwareRequirements Validationis furtherbroken down, repre-sentingthetwovalidation alternativesmentionedpreviously.If theteamisfamiliarwiththeprojectdomain,theycancarryout anInternalValidation,otherwise,theymustdoaPrototypeBased Validation(butinordertodothis,theteammusthavefirstcarried outtheOperationalPrototypingactivity).
3.2. Contextmodel
Thecontextofaprojectmayvaryaccordingtodifferentproject variablesalongspecificdimensionssuchas:size,duration, com-plexity,developmentteamsize,knowledgeabouttheapplication domain,orfamiliaritywiththetechnologyinvolved.Formalizing thesecharacteristicsasamodelenablesustoautomatically tai-lortheorganizationalprocessaccordingtothem.Wehavedefined SPCM(SoftwareProcessContext Metamodel)for specifyingthe contextmodelforeachproject.ThemetamodelforSPCMisshown inFig.7.
SPCMisbasedonthreebasicconcepts:ContextAttribute, Dimen-sion and ContextAttributeConfiguration. Every element in SPCM extendsa ContextElement that hasa nameand a description.A
Fig.7.TheSoftwareProcessContextMetamodel–SPCM.
ContextAttributerepresentsarelevantcharacteristicoftheprocess contextrequiredfortailoring.TheContextAttributeincludesa pri-ority(usedwhenatrade-offamongcontextattributesisrequired). AContextAttributecantakeoneofasetofvaluesdefinedas Contex-tAttributeValue.AnexampleofaContextAttributeisthesizeofthe project(Size).ContextAttributeValuerepresentsatypeforqualifying aContextAttribute.ExamplesofContextAttributeValuesforthe Con-textAttributeSizearetheContextAttributeValues{Small,Medium, Large}. Dimension represents a collection of related ContextAt-tributes.BygroupingContextAttributesbyDimension,thecontext modeliseasiertounderstand.AnexampleofaDimensionisTeam, whichcanbeusedtogroupteamattributeslikeTeamSizeandTeam Capabilities.AContextmodelisacollectionofDimensions.
For example,the context model ofthe CC51AREprocess is depictedinFig.8.Thiscontextmodelhasthreedimensions:project, product and team. This model also has six context attributes: domainknowledge,complexity,projecttype,duration, sizeand training.Thefirstthree attributetypesareassociatedwith pre-determined context attribute values (throughenumeration) for eachproject,whilethelastthreeattributesareconstantsprovided thatthisprocessisfollowedbystudentsaspartofacourse.
A ContextConfiguration is a set of ContextAttributeConfigura-tions,whereeachContextAttributeValueisavalidContextAttribute. Therefore, each ContextAttributeConfiguration is associated with a ContextAttribute and to one unique ContextAttributeValue. For example,a possible ContextAttributeConfigurationis the Project-TypeConfiguration for a development project, where one of its
ContextAttributesisProjectTypeanditsassociatedAttributeValue
is“Development”.
Table1showshowthedifferentcontextattributesaffectthe variableelementsoftheCC51AREprocess.Iftheteam’sdomain knowledgeisMediumtoHigh,thentheteamcanavoiddoinga prototype-basedvalidationofthesoftwarerequirements,skipping theOperationalPrototyping activity.Theteam’slevel ofdomain knowledgedoesnotaffecttheoptionalExplorationactivity,since therealizationofthisactivitydependssolelyontheprojecttype.
Fig.8.ContextmodelfortheCC51Arequirementsengineeringprocess.
However,thetypeofprojectdoesaffectwhetherornotthe Explo-rationactivityiscarriedout.Complexitydoesnotaffecttheprocess.
3.3. Tailoringbymodeltransformation
WeuseATL(Jouaultetal.,2006)fordefiningthetailoring trans-formationrules.Rulesabouttailoringthegeneralprocessmodel accordingtothevaluesofdifferentcontextattributescanbe com-posedincrementally.Inthiswaywe canconfigure newprocess modelsthroughagenerativestrategybyrecombiningpartial tail-oringtransformationrules,andthusreusingtheknowledgethey embody.MatchedrulesconstitutethecoreofanATLdeclarative
Table1
ProcessscopingaccordingtoCC51Acontextmodel.
Contextattribute Attributevalue Exploration Operationalprototyping Softwarerequirementsvalidation
Domainknowledge High – False Requirementsvalidation
Medium – False Requirementsvalidation
Low – True Prototypebasedvalidation
Complexity High – – –
Medium – – –
Low – – –
Projecttype Development True – –
Extension False – –
Fig.9. ATLtailoringtransformation.
transformationsincetheyallowustospecify:(i)whichtarget ele-mentsshouldbegeneratedforeachsourceelementand(ii)how generatedelementsareinitializedfromthematchedsource ele-ments.
Our tailoring transformation is endogenous (Czarnecki and Helsen,2006)becauseitsoutputconformstothesamemetamodel astheinput.However,itisnotinplacesincewewanttopreserve theorganizationalprocessmodelforfutureconfigurations.Weuse
ATLCopier3asabasictemplate,andwemodifyitsothatonlythose
elementswhoserulesevaluatetotrueareactuallycopiedtothe tar-getmodel.AllcommonelementsoftheeSPEMmodelarecopied overtotheadaptedmodel,andwespecifyrulesforthevariation points.Eachvariationpointhasanassociatedhelpercalledfrom thematchedrule.
Fig.9showstheruleTaskUse.ThesourcepatternMM!TaskUse
is defined after the keyword from, meaning that the rule will generatetargetelementsfor eachsourceelementmatchingthe pattern. In order toselect onlythose source elementsthat are relevantforthespecificproject,anextraconditionisadded:an Optionalityruleimplementedasahelperfunction(notshownin
Fig.9)thatmakes ofthecontext configuration.Whenthis rule returnsfalse, theelement needs tobe removed from the pro-cess.Attributeinitializationusesthevaluesinthesourceprocess modelelement.However,andprovidedthatweuseeSPEM vari-ability mechanisms, a process element (e.g., TaskUse) couldbe linkedtoseveralvariantsof methodelements(e.g.,Task Defini-tion).Therefore,wedefineanAlternativeTailoringRuleasaselecting rulethat returns the methodelement chosen according tothe helper rule. The AlternativeTailoringRule chooses the appropri-ateTaskDefinition variant,according to the Domain Knowledge valueinthecontext(inthefigure,thisvalueis “Low”).Ifthere were more variability points, a conjunction of rules would be applied, also specifying priorities to make trade-offs, if neces-sary.
3 http://www.eclipse.org/m2m/atl/atlTransformations/.
3.4. Projectadaptedprocessmodel
TheprojectadaptedprocessmodelalsoconformstotheeSPEM metamodel,butitcannothavevariabilities,soallvariabilities iden-tifiedaspartoftheorganizationalprocessmodelareresolvedby thetailoringtransformation.Fig.10 shows theadapted process afterapplyingtherulesinFig.9toanextensionprojectwithalow domainknowledge.
3.5. Discussion
Thisproposalisonlyapplicableincompaniesthathavetheir softwareprocessformalized.Largecompaniesaremorelikelyto havetheirprocessformalized,buttheirsurvivaldoesnotdepend onsmallimprovementsinproductivity.ThisisnotthecaseforSSO, whereinefficiencymayleadthemtofailure.Moreover,evenlarge companiestendtoorganizetheirdevelopmentinsmallerentities
(Anon.,2011)thatcanalsobenefitfromourapproach.Accordingto
OECD(2005),mostsoftwarecompaniesaroundtheworldaresmall, sotheproposalhasthepotentialofhavingabigimpact.InChile,we haveseenthatthereisagrowinginterestinprocessformalization amongsmallsoftwarecompanies(Ruizetal.,2012).
Softwaredevelopmentinsmallentitiesmayvaryaccordingto asmallsetofvariables:thereisonlyasmallgroupofpeoplethat maybeassignedtoaproject,thereareonlyoneorafewcustomers, andtheprojectsarealwaysshortinduration.Evenmore,notallthe combinationsofthesevariablesarevalid,e.g.,ifthetypeofprojectis maintenancethecustomermustbeknown,iftheprojectisincident theprojectdurationcannotbelong,thusthereisalimitedamount ofvalidcontextconfigurations.Ourproposalallowstodetermine auniqueprocesstobefollowedoncethecontextconfigurationis defined,i.e.,itisafunction:
Tailoring:Context→Process
So,foreachcontextconfigurationthereisauniqueprocessthatis themostappropriateone,andfortwoidenticalcontext configura-tions,theprocessisexactlythesame.Moreover,differentcontexts mayleadtothesameprocess.Therefore,thenumberofpotentially differentprocessesthatmaybegeneratedisatmostequaltothe numberofcontextconfigurations.
Whenthenumberofcontextvariablesgrows,thenthenumber andcomplexityofthetailoringrulesalsogrows.Thismakesthe modelingactivitymoredifficult,andprogrammingtherules,that isalreadythemostsophisticatedpartoftheapproachevenmore complex.Theseissueschallengetheproposal’sadoption,atleast untilwedeveloptoolsforsupportingmodelingandrulegeneration.
4. TailoringtherequirementsengineeringprocessatKI
Wehaveformalizedthegeneralrequirementsengineering(RE) processusedbyKI,4asmall-sizedChileansoftwarecompany.This
companyisCMMILevel2certified,anditsorganizationalsoftware processisbasedonRUP.ItsprocessispartoftheTutelkánproject (Valdésetal.,2010),andispubliclyavailable.
ThisREprocessisaccompaniedbyasetofadaptation guide-lines.Theseguidelinesindicatewhichartifactsshouldorshould notbeincludedaspartoftheadaptedprocess,accordingtocertain projectcontextvalues.ThisisthewayKIhasaddressedthe prob-lemofmanuallytailoringageneralprocesstoasmall,predefined setofprojecttypes:largedevelopment,smalldevelopment, main-tenanceandincident.Eachprojecttypehasbeenclearlyidentified bythecompany’sprocessengineerasavalidprojectcontext.
Inthissection,wefirstdescribetheinputorganizational pro-cessandthecontextmodel.Wethenillustratehowtheadaptation guidelinesareturnedintorules.Finally,weshowtheresultsofthe automatedtailoringprocess,whichproduced theexpected pro-cessfor each predetermined projecttype. We alsopresent the resultsofapplyingourapproachtoanunexpectedprojectcontext: amaintenance-enhancementprojectforan unknowncustomer. Ourapproachsuccessfullygeneratedanadequateprocessforthis context.Theresultspresentedinthissectionhavebeenanalyzed andvalidatedbythecompany’sprocessengineer.
4.1. OrganizationalREprocessmodel
The studied requirements engineering process consists of two activities, which are carried out in parallel: Requirements Development and Requirements Management. Fig. 11 shows the organizational process, and Fig. 12 shows its formalization in
4http://www.kiteknology.com.
Fig.11. KIgeneralrequirementsengineeringprocess.
eSPEM.ThisprocessincludestheRequirementsEngineeringand Managementactivities,andispartofalargerprocess.
TheRequirementsDevelopmentactivityisdepictedinmoredetail inFig.13.Thisactivitymaytakeontwodifferentforms,depending onwhetherornottheprojectisinitsinceptionphase.Inthefirst case,theRequirementsDevelopmentactivityconsistsoftwooptional sub-activitiesthatcanbecarriedoutinparallel:ProblemAnalysis
andEnvironmentSpecification.Inallotherphases,thisactivityis brokendownintothreesub-activitiesthatarecarriedoutin paral-lel:RequirementsSpecification,RequirementsAnalysisandValidation
Fig.13.KI–theRequirementsDevelopmentactivity.
andEarlyChangeManagement;onlythelastoneisoptional.Yellow rectanglesareusedtovisuallyindicateprocesselementoptionality. The Requirements Management activity consistsof four sub-activities: the Requirements Understanding and Requirements Commitmentactivitiesarefirstcarriedoutsequentially,afterwhich theRequirementsTrackingandRequirementsChangeManagement
activitiesare carriedoutin parallel(seeFig.14).None ofthese sub-activitiesareoptional.TheRequirementsUnderstanding activ-ityisfurthersubdividedintothreesequentialsub-tasks:Identify RequirementsProviders,RequirementsReviewandEnsuringCommon RequirementsUnderstanding (see Fig.15). Note that theIdentify RequirementsProviderstaskismarkedasoptional.Thistaskisonly carriedoutiftheprojectisanewdevelopmentproject.Finally,the featuremodelinFig.16showsboththecommonandvariable pro-cesselementsoftheGeneralRequirementsEngineeringprocess presentedinthissection.
Fig.14.KI–theRequirementsManagementactivity.
Fig.15.KI–theRequirementsUnderstandingactivity.
4.2. Contextmodel
TheGeneralRequirementsEngineeringprocesspresentedinthe previoussubsectionisappliedtodifferenttypesofprojects.We havedefinedacontextmodelforKI,showninFig.17.Thiscontext modelhasthreedimensions:Domain,TeamandManagement.For example,theDomaindimensionhasthreeattributes:Application Domain,Development Environmentand Source of Documentation. Thefirsttwoattributescantakeontwopossiblevalues:“known” or“unknown”,whereastheSourceofDocumentationhasthree pos-siblevalues:“exist”,“doesnotexist”and“expert”(anexpertis thesourceofinformation).Theothertwodimensionsaresimilarly disaggregatedintoattributes,eachwithitsownpossiblevalues.
Weshowthecontextcharacterizationoftwotypicalprojects inTable2.Thepartsofthecontextmodelthatarerelevanttothe tailoringprocessarelistedinthefirsttwocolumns,andeachofthe remainingcolumnsrepresentsaparticularprojectcontext charac-terization.Forexample,thethirdcolumnliststhecontextattribute valuesthatcharacterizeasmall,newdevelopmentproject,within anunknownapplicationdomain.Inthistypeofprojectthereis nopreexistingdocumentation,boththedevelopmentenvironment andcustomertypeareunknown,theproviderisin-house,andthe projectdurationissmall(short).WeexpectthattheREprocess tailoredtosuchaprojectincludesalloptionaltasks,rolesandwork products,asthisisoneofthemostcomplextypesofprojectthatKI develops.
Ontheotherhand,theattributevalueslistedinthefourth col-umnofTable2describeasimplecorrective-maintenanceproject, where the application domain, development environment and customertypeareknown,documentationexists,theprovideris in-houseandtheprojectdurationismedium.Inthiscase,weexpect thattheresultingtailoredprocesswillbemuchsimplerthanthe oneforsmalldevelopmentprojects:duringtheInceptionphase, theRequirementsDevelopmentactivityjustincludestheProblem Analysissub-activity(inadditiontothemandatorysub-activities),
Fig.16. KI– featuremodelcorrespondingto:(a)theRequirementsDevelopmentactivityand(b)theRequirementsManagementactivity.
whileintherestofthephases,theRequirementsDevelopment activ-ityjustconsistsofthetwomandatorysub-activitiesRequirements SpecificationandRequirementsAnalysisandValidation.
TheRequirementsUnderstandingactivityforbothtypesofproject should consist of just two sequential activities: Requirements
ReviewandEnsuringCommonRequirementsUnderstanding.Thisis becausetherequirementsprovideris“in-house”.Fig.18showsthe resultingRequirementsDevelopmentandRequirements Understand-ingworkflows,whentailoredtotheSimpleMaintenanceproject context.
Table2
KI–contextcharacterizationsoftwotypicalprojects.
Dimension Contextattribute Smalldevelopment SimpleMaintenance
Domain Applicationdomain Unknown Known
Developmentenvironment Unknown Known
Sourceofdocumentation Doesnotexist Exists
Management Projecttype Newdevelopment Maintenance-correction
Provider In-house In-house
Customertype Unknown Known
Fig.17.KI–contextmodel.
Fig.18.KI–theRequirementsDevelopmentandRequirementsUnderstandingactivities,tailoredtotheSimpleMaintenanceprojectcontext.
4.3. Tailoring
KIhasasetofadaptationguidelines,whichtheyusetomanually tailor their process. Table 3 is a partial listing of the adapta-tionguidelinesprovidedbyKI.Theseguidelinesareexpressedas guardedactions,wheretheprocesselementsthatappearinthe “Action”columnare thosevariation pointsindicated in Fig.16. Forexample,ifwewanttotailorthegeneralrequirements pro-cesstoamaintenance-enhancementproject,thentheProblemand ProjectScopeDefinitiontaskisrequired,i.e.,thetailoredprocess mustincludethistask.
Theadaptationguidelinesforcommoncontextstendtobeclear enoughsothatthereisnoambiguityaboutwhattoexpectinthe adaptedprocess.Forexample,theEarlyChangeManagement activ-ityshouldneverbecarriedoutduringamaintenance-correction project.However,certainattributecombinationsarenotfully docu-mentedintheseguidelines.Forexample,iftheProviderisin-house, thentheProblemandProjectScopeDefinitiontaskmayormaynot berequired,dependingonthevaluesofothercontextattributes. Inothersituations,likethecaseinwhichthereisaSourceof Doc-umentation(“Exist”),nospecificactionhasbeenspecified.Fig.19
presents,asanexample,theATLimplementationofRule2,which
Table3
KI–adaptationguidelines(partiallisting).
Contextattribute Value Action
Projecttype Maintenance-enhancement ProblemandProjectScopeDefinitiontaskrequired Projecttype Maintenance-correction EarlyChangeManagementactivitynotrequired
Provider In-house ProblemandProjectScopeDefinitiontaskmayberequired
Provider Outsource ProblemandProjectScopeDefinitiontaskrequired
Sourceofdocumentation Doesnotexist EnvironmentSpecificationactivitymayberequired
Fig.19.ATLrule,determineswhethertheEnvironmentSpecificationactivityisrequired.
Fig.20.KI–theRequirementsDevelopmentprocesswhennodocumentationexists.
determineswhentheEnvironmentSpecificationactivityisincluded inthetailoredsoftwareprocess.Iftherulereturns“true”,the activ-itymustbeincludedintheprocess.
Letusnowconsiderthecaseofanunexpectedcontext,i.e.,a validcontextconfigurationthatwasnotrecognizedbythe com-panyasatypicalprojectcontext.Forexample,KIcouldreceivea maintenance-enhancementrequestfromanunknowncustomer. This project context is similar to Simple Maintenance context (fourthcolumn,Table2);however,nodocumentationexistsfor thisproject(sourceofdocumentationdoesnotexist).Therefore, thistypeofmaintenance-enhancementrepresentsanewproject contextfortheorganization.Althoughtheadaptationguidelines donotcontemplatethiscase,theguardedactionslistedinTable3
canbeusedtomake somedecisionsaboutthevariationpoints.
Table4
KI–maintenance-enhancementwithoutdocumentation.
Contextattribute Attributevalue
Applicationdomain Known
Developmentenvironment Known Sourceofdocumentation Doesnotexist
Projecttype Maintenance-enhancement
Provider In-house
Customertype Known
Projectduration Medium
Thecontextconfigurationforthisnewtypeofprojectisshownin Table4.Wecannowapplythetailoringrules.
Fig.20showstheresultofapplyingourtailoringrulestothisnew context.ThisprocessincludestheEnvironmentSpecification activ-ity,whichwasnotincludedintheprocessconfiguredtoSimple Maintenance(seeFig.18),sinceRule2indicatesthatthisactivity mustonlybeincludedwhennodocumentationexists.According tothecompany’sprocess engineers,this istheexpectedresult, eventhoughitwasnotexplicitlystatedintheoriginaladaptation guidelines.
4.4. Evaluation
Our MDE-basedtailoring solutionwasvalidated duringa 4-hworkshop that we organizedat KI. Participants included the company’sCEO,processengineer,andprojectmanagers.Atthis workshop,wepresentedthetechnicalaspectsofourproposal,as wellasademonstrationofourtoolchain.Weefficientlygenerated eachpossibleadaptationoftheprocess,andvalidatedeachonein conjunctionwiththeorganization’sprocessengineer.Thetailored processesweproducedwerecorrectandsuitableforeach particu-larprojectcontextaccordingtothecompany’sstakeholders.Also, sincethetailoringprocessisnowreplicableandfast,thecompany isconsideringtoincludethisasthefirststepofanynewproject.
Fig.21.Amisoft–organizationalsoftwareprocess.
5. TailoringthesoftwareprocessatAmisoft
Inthissection,wepresenttheapplicationofourapproachtothe developmentprocessofAmisoft,5anothersmallChileansoftware
company.Thiscompanydefineditsorganizationalprocessin2009, anditiscurrentlyimplementingtheISO9001:2008standard,as wellascertifyingCMMILevel2.Thissoftwaredevelopmentprocess isbasedontheOpenUPprocessmodel.
Inordertoapplytheproposedtailoringapproach,wefirst for-malizedtheorganizationalsoftwareprocessinEMF,withthehelp ofthecompany’sprocessengineer.Asinthepreviouscasestudy, processvariabilitywasmodeledinafeaturemodel.Wethen for-malizedthecontext model forAmisoft, aswellas two context characterizations.Afterthat, wedefinedthetailoringrules that specifyhow theprocessmust changeaccordingtothecontext. Finally,wedescribehowourproposedapproachwasusedtotailor theorganizationalsoftwareprocesstooneoftheprojectcontext characterizations.
5.1. Organizationalprocessmodel
Amisoft’s organizational process considers two predefined projecttypes: developmentand maintenance.Since this organi-zation typically addresses small software projects, particularly informationsystems, itsdevelopmentprocessis simple. Fig.21
shows the specification of this process, which consists of four sequentialactivities:Analysis,ArchitecturalDesign,DetailedDesign
andImplementation.
TheAnalysis activity involvesfour tasks: Elicitation, Require-ments Analysis, Prototyping and Requirements Specification (see
Fig. 22). The Elicitation and Requirements Analysis tasks focus ondeterminingtheusers’requirements,while theRequirements Specification task focuses on identifying the project’s software requirements.Iftheprojectinvolvesthedevelopmentofanew soft-wareproductthePrototypingtaskiscarriedout,helpingvalidate users’ requirements and translate them into software require-ments.However,thistaskisnotrequiredformaintenanceprojects, thusitisoptional.TheRequirementsSpecificationtaskshouldalways becarriedout;however,aformalrequirementsdocumentisonly producedwhen anewsystemis beingdeveloped,or whenthe developmentteam doesnot havea lotof experience.Forthese reasons,theorganizationalsoconsidersthistaskasoptional.
TheArchitecturalDesignactivityis optional,becauseitis not requiredformaintenanceprojects.Thisactivitydoesnothaveany variabilityinitsworkflow,andthuswedo notshowthe corre-spondingmodel.
TheDetailed Designactivity startswithtwo sequential tasks (DesignConceptionandDesignReuse)andendswiththree concur-renttasks(ComponentsDesign,DatabaseDesignandInterfacesand CommunicationDesign).Thespecificationofthisactivityisshown inFig.23.DuringtheDesignConceptiontask,designersdetermine whichcomponentsmustbepartofthesolutionandduringthe
DesignReusetask,theyidentifywhichcomponentdesignscanbe
5 http://www.amisoft.cl.
reusedfrompreviousprojects.Thesetwoinitialtasksareoptional, sincetheyarenotrequiredduringmaintenanceprojects. Compo-nentsDesignand DatabaseDesignaremandatorytasks.Thefirst oneaddressesthemodelingof componentsthathave yettobe designed,whilethesecondonefocusesonthedatabaseor datas-pace model.Since this companytypically develops information
Fig.22.Amisoft– theAnalysisactivity.
Fig.24.Amisoft–theImplementationactivity.
systems, theDatabase Designtask is mandatory.Some mainte-nanceprojectsdonotrequiredatabasechanges,buteventhenthis taskiscarriedout,sincechangesmadetothesoftwaremay trig-gersomedatabaseadjustments,e.g.,requiringthecreationofnew indexes.TheInterfacesandCommunicationDesigntaskdealswith theHuman–ComputerInteractionaspectsofthesoftwareproduct andalsocommunicationwithothersystems.Thistaskisoptional becauseitisnotrequiredduringmaintenanceprojects.
Finally,theImplementationactivityconsistsofthreeconcurrent tasks: ComponentsImplementation,DatabaseImplementation and
InterfacesandCommunicationImplementation(seeFig.24).During thesetasks,therolesresponsibleforthemimplementthedesigns producedduringtheDetailedDesignactivity.
Fig.25is thefeaturemodel associatedtothis software pro-cess.TherearetworequiresconstraintsbetweentheInterfacesand CommunicationDesignandInterfacesandCommunication Implemen-tationtasks:(1)fromtheimplementationtothedesigntask,which modelsthatthedesigntaskmustbecarriedoutbeforecodingcan occurand(2)fromthedesigntotheimplementationtask,whichis toensurethatthedesignisnotawasteworkproduct.
5.2. Contextmodel
Fourdimensions were identified by theorganization as rel-evantfor characterizingits projects:Team,Project,Business and
Product. The correspondingcontext model is shown in Fig. 26. TheTeamdimensionhastwoattributes:TechnicalKnowledgeand
Fig.26. Amisoft–contextmodel.
DevelopmentSkills,whichmodeltheteam’srequiredlevelof tech-nicalknowledgeanddevelopmentskills,respectively.TheProject
dimensionalsohastwoattributes: ProjectType,which cantake ononeoftwovalues(“Maintenance”or“Development”),andthe
ResourcesAvailabilitythatmodelsthelevelofavailabilityofhuman resources. TheBusiness dimension considers just one attribute:
TypeofDeliverable,whichcanbe“process-oriented”or “product-oriented”. When this attribute is set to “process-oriented”, a deliverablemustbegeneratedbyeachphaseoftheprocess(e.g.,a requirementsspecification,asoftwarearchitecturedocument,and soon).Whentheattributevalueis“product-oriented”,onlythe sourcecodeoftheproductmustbedeliveredtotheclient organiza-tion.Finally,theProductdimensionconsidersjustanIntegrationReq
attribute,whichindicateswhethertheprojectmustbeintegrated toanexistingsolution.
Fig.27.Amisoft–tailoringdecisions.
Fig.28.ATLtailoringrule,determineswhethertheRequirementsSpecificationtaskisrequired. 5.3. Tailoringrules
Thetailoringrulesforthisprocesswerespecifiedusingatable thatrelatesthecontextdimensionsandattributestoprocess fea-tures.Fig.27showsapartialviewofthistailoringtable.Sinceall therulesarespecifiedinasinglegraphicalrepresentation,the pro-cessofvalidatingwhentoapplyeachrulebecomeseasytocarry out.The intersectionbetween eachrow andcolumn character-izestherelationshipbetweenthecorrespondingattributevalue (row)andprocessvariationpoint(column).Acellisleftemptyif thereisnorelationbetweenthereferencedcontextattributeand variationpoint.Otherwise,weusethevaluesTrueandFalseto indi-catewhetherthereferencedtaskmustbeincludedorremoved fromthe tailoredprocess, respectively. We additionallyextend these values with +and − symbols, indicating whethera con-textattributehasahigherorlowerprioritywithrespecttoother attributes.
For example, the Requirements Specification task is weakly selectedwhentheteamhasmedium/lowDevelopmentSkills. How-ever,thistaskwillbestronglyomittedfromthetailoredprocess iftheprojectisproduct-oriented,i.e.,theRequirements Specifica-tiontaskwillnotbeincludedinthetailoredprocessforthistype ofproject.ThesetailoringguidelineswereformalizedusingATL.
Fig.28showsahelperrulethatdetermineswhentheRequirements Specificationtaskmustbeincludedinthisorganization’stailored softwareprocess.Here,the+and−valuesdeterminetheorderin whichthecontextattributesareevaluated:TypeofDeliverableis
evaluatedfirst(True+),whiletheDevelopmentSkillsandProjectType
attributesareevaluatedlast.
5.4. Context-adaptedprocesses
Table5 presents two examples of projectcharacterizations: SimpleandComplexMaintenance.Botharemaintenanceprojects (ProjectTypeis“Maintenance”),butthefirstonedoesnotrequire ahigh-leveloftechnicalknowledgeordevelopmentskills,while thesecondonedoes.Inbothcases,theonlydeliverableisthecode (TypeofDeliverableissetto“Product-oriented”).Thefirstcontext isprobablythesimplesttypeofprojectthatthiscompanydeals with,whilethesecondoneisabitmoredemanding.
Asinthefirstcasestudy,wetailoredthegeneralprocessusing the ATL rules derived from the tailoring decisions specified in
Fig.27.TheresultingprocessesareshowninFig.29.Inthefirst
Table5
Amisoft– twoprojectcharacterizations. Contextattribute Simple
Maintenance
Complex Maintenance Technicalknowledge Medium/low High Developmentskills Medium/low High Projecttype Maintenance Maintenance Resourcesavailability Low Low
Typeofdeliverables Product-oriented Product-oriented
Fig.29.Amisoft– thetailoredprocessmodelfor(a)aSimpleMaintenanceand(b)aComplexMaintenanceproject,respectively.
one,alloptionalprocesselementshavebeenremoved,asexpected; whereasthesecondoneissimilar,butalsoincludesthe Require-mentsSpecificationtask.
The adapted processes were analyzed by Amisoft’s process engineer,whoconsideredthattheyareappropriateforthe corre-spondingcontexts,andtheyarealsoconsistentwiththeguidelines definedbytheorganization.Inhisopinion,themostvaluableaspect of ourproposedtailoringmethodologyis its usability,since he couldquicklyadjustthecontextattributevaluesandimmediately seehowthesechangesaffectthetailoredprocesses.
6. Conclusionsandfuturework
Inthisarticle,wepresentanMDE-basedapproachfor automat-icallytailoringsoftwareprocesses,wheretransformationrulesare usedtoadaptageneralprocessmodeltoaspecificcontext.
The tailoring strategy takes as input two models, a general processmodelandaprojectcontextmodel,andproducesa context-specificprocess.Thisisdonebyapplyingasetoftransformation rulesthatdefinehowthegeneralprocessmodelvaries depend-ingonthecontext.Theserulesarespecifiedbyaprocessengineer andvalidatedbytheorganization’sprojectmanagers.Theproject managerisafterwardsonlyresponsibleforspecifyingthespecific project’scontext.
Thisapproachhasanumberofadvantages.Tailoringisdonein asystematicwaybecausethetransformationrulesareuniformly appliedaccordingtoacontextmodel.Thetotaltimerequiredto adaptaprocessismuchshorterthanbefore,sotheprocess engi-neercanquickly seetheeffect ofchanging a ruleor a context attributevalue.Wecanalsochecktheconsistencyoftheprocess engineer’stailoringknow-how.Inpractice,wealsoexpecttosee animprovementinproductivityinprojectsthatfollowprocesses adaptedusingourapproach.Thisisbecausethetailoredprocess onlyincludestheprocesselementsthat arestrictlyrequiredby aproject’scontextconfiguration,soonlytheessentiallyrequired resourcesshouldbeinvestedintheproject.
Thecasestudiespresentedinthispapershowedthatitis possi-bletoapplytailoringtransformationsbuiltforadaptingageneral processtodifferentprojectcontextsinaplannedmanner.Being abletovalidatethetransformationsforparticularknowncaseshas givenusconfidence oftheirvalidityinthegeneralcase. There-fore, whenever unanticipated scenarios happen, a combination of already builtand validated tailoringtransformations can be
applied,and as a consequence,anappropriate context adapted processcanbeobtainedquicklyandeasily.
Theexperiencehasallowedustoconcludethat:(1)the pro-posedtechniqueisaneffectivetooltoachieveprocesstailoring,(2) theapproachisusefulandpracticalbecauseitwaseasily imple-mentablebytheprocessgroup,and(3)itallowstorepresentand evolvethetailoringknowledgeofanorganization.However,(4) theprototypicaltoolmustbemoreusable,inparticulartodefine thetransformationrules.Additionally,theprocessengineersatone ofthecompaniessuggestedthatthetriplet(ContextConfiguration, TailoredProcessandResults)shouldbeusedtoempiricallyvalidate andimprovethecontextmodelandthetailoringdecisions.
Althoughthecasestudieswereconductedinnichecompanies withsmallprocesseswherethenumberofthecontextvariables andthenumberofprocessvariationpointsissmall,weexpectthat theapproachcouldbesuccessfullyappliedforlargerprocessesas well.Generally,largecompaniesareorganizedinsmallerentities whichbehavemuchlikesmallcompanies(Hamilton,1999). Never-theless,whenalargecompanyismanagedasawhole,thenumber ofprocessesfromtheprocesslinegrowsexponentiallyaccording tothenumberofvariationpointsandcontextconfigurations,and thisaddscomplexity.Performanceinprocesstailoringisnotan issuesinceitisdoneautomatically,butwritingtherulesand evolv-ingthemconsistentlymaybecomedifficultandexpensive.Further validationwithbigprocessmodelsisrequiredtoevaluatetheactual scalabilityoftheMDEapproach.
Wearecurrentlyexperimentingwiththisapproachinfourother Chileansoftwarecompanies,aspartoftheADAPTEproject,6alarge,
government-fundedinitiative.Thiswillallowustocontinue vali-datingthefeasibilityoftheproposedapproach.Sincethequality oftheinputmodelsisimportant,wearecurrentlyintegratingour toolchainwithsomeprocessqualityanalysistoolswehavealready developed(Hurtadoetal.,2012a).Moreover,wearenow work-ingonalsoimprovingmethodologicalandusabilityissuesofthe proposedtailoringapproach.
Acknowledgement
ThisworkhasbeenpartlyfundedbyprojectFondefD09I1171 ofConicyt,Chile.
References
Anon.,2011.SoftwareEngineering– LifecycleProfilesforVerySmallEntities(VSEs) – Part5-1-2:managementandengineeringguide:genericprofilegroup:basic profile.TechnicalReportISO/IECTR29110-5-1-2:2011,International Organiza-tionforStandardization,Geneva.
Aranda,J.,Easterbrook,S.,Wilson,G.,2007.Requirementsinthewild:howsmall companiesdoit.In:Proceedingsofthe15thIEEERequirementsEngineering Conference.IEEECSPress,pp.39–48.
Armbrust,O.,Katahira,M.,Miyamoto,Y.,Münch,J.,Nakao,H.,Ocampo,A.,2009. Scopingsoftwareprocesslines.SoftwareProcess:ImprovementandPractice14 (3),181–197.
Bai,X.,Huang,L.G.,Zhang,H.,2010.Onscopingstakeholdersandartifactsinsoftware process.In:Münch,J.,Yang,Y.,Schäfer,W.(Eds.),Proceedingsofthe2010 inter-nationalconferenceonNewmodelingconceptsfortoday’ssoftwareprocesses: softwareprocess(ICSP’10).Springer-Verlag,Berlin,Heidelberg,pp.39–51. Bajec,M.,Vavpotic,D.,Furlan,S.,Krisper,M.,2007a.Softwareprocessimprovement
basedonthemethodengineeringprinciples.In:SituationalMethod Engineer-ing:FundamentalsandExperiences,ProceedingsoftheIFIPWG8.1Working Conference,Volume244ofIFIP.Springer,pp.283–297.
Bajec,M.,Vavpotic,D.,Krisper,M.,2007b.Practice-drivenapproachfor creat-ingproject-specificsoftwaredevelopmentmethods.InformationandSoftware Technology49(4),345–365.
Batista,J.,DeFigueiredo,A.D.,2000.SPIinaverysmallteam:acasewithCMM. SoftwareProcess:ImprovementandPracticeJournal5(4),243–250. Beck,K.,Andres,C.,2004.ExtremeProgrammingExplained:EmbraceChange,2nd
ed.Addison-WesleyProfessional.
Belkhatir,N., Estublier,J.,1996. Supporting reuseand configurationforlarge scalesoftwareprocessmodels.In:SoftwareProcessWorkshop,1996. Pro-cessSupportofSoftwareProductLines,Proceedingsofthe10thInternational, pp.35–39.
Boehm,B.W.,Clark,B.,Horowitz,E.,Westland,J.C.,Madachy,R.J.,Selby,R.W.,1995. Costmodelsforfuturesoftwarelifecycleprocesses:COCOMO2.0.Annalsof SoftwareEngineering1,57–94.
Breton,E.,Bézivin,J.,2001.Modeldrivenprocessengineering.In:Computer Soft-wareandApplicationsConference,2001.COMPSAC2001,pp.225–230. Bustard,D.W.,Keenan,F.,2005.Strategiesforsystemsanalysis:groundworkfor
pro-cesstailoring.In:Proceedingsofthe12thIEEEInternationalConferenceand WorkshopsontheEngineeringofComputer-BasedSystems(ECBS’05).IEEE ComputerSociety,WashingtonDC,USA,pp.357–362.
Clements,P.,Northrop,L.,2001.SoftwareProductLines:PracticesandPatterns,3rd ed.Addison-WesleyProfessional.
CMMIProductTeamCMMIforDevelopment,Version1.2,2006.TechnicalReport CMU/SEI-2006-TR-008,SoftwareEngineeringInstitute.
Cockburn,A.,2000.Selectingaproject’smethodology.IEEESoftware17(4),64–71. European Commission, 2005. The New SME Definition: User Guide and Model Declaration. http://ec.europa.eu/enterprise/policies/sme/files/ smedefinition/smeuserguideen.pdf
Cusumano,M.A.,Cormack,A.M.,Kemerer,C.F.,Crandall,W.(B.),2009.Critical deci-sionsinsoftwaredevelopment:updatingthestateofthepractice.IEEESoftware 26(5),84–87.
Czarnecki,K.,Helsen,S.,2006. Feature-basedsurveyof modeltransformation approaches.IBMSystemsJournal45(3),621–645.
Dai,F.,Li,T.,2007.Tailoringsoftwareevolutionprocess.In:8thACISInternational ConferenceonSoftwareEngineering,ArtificialIntelligence,Networking,and Parallel/DistributedComputing,vol.2,pp.782–787.
Deelstra,S.,Sinnema,M.,Bosch,J.,2005.Productderivationinsoftwareproduct families:acasestudy.JournalofSystemsandSoftware74(2),173–194. Dörr,J.,Adam,S.,Eisenbarth,M.,Ehresmann,M.,2008.Implementingrequirements
engineeringprocesses:usingcooperativeself-assessmentandimprovement. IEEESoftware25(3),71–77.
Firesmith,D.,2004.Creatingaproject-specificrequirementsengineeringprocess. JournalofObjectTechnology3(5),31–44.
Hamilton,M.,1999.SoftwareDevelopment:BuildingReliableSystems.Enterprise ComputingInstituteSeries.PrenticeHall.
Harris,M.,Aebischer,K.,Klaus,T.,2007.Thewhitewaterprocess:softwareproduct developmentinsmallITbusinesses.CommunicationsoftheACM50(5),89–93. Henderson-Sellers,B.,Ralyté,J.,2010.Situationalmethodengineering:
state-of-the-artreview.JournalofUniversalComputerScience16(3),424–478.
Hofer,C.,2002.SoftwaredevelopmentinAustria:resultsofanempiricalstudy amongsmallandverysmallenterprises.In:Proceedingsofthe28thEuromicro Conference,pp.361–366.
Hurtado,J.A.,Bastarrica,M.C.,2009.Processmodeltailoringasameanforprocess knowledgereuse.In:2ndWorkshoponKnowledgeReuse,KREUSE,FallsChurch, Virginia,USA.
Hurtado,J.A.,Bastarrica,M.C.,Bergel,A.,2012a.Analyzingsoftwareprocessmodels withAVISPA.In:Raffoetal.(2011),pp.23–32.
Hurtado,J.A.,Bastarrica,M.C.,Quispe,A.,Ochoa,S.F.,2012b.AnMDEapproachto softwareprocesstailoring.In:Raffoetal.(2011),pp.43–52.
Hurtado,J.A.,Ochoa,S.F.,Quispe,A.,Bastarrica,M.C.,2011.Acontextmodeling languagetosupporttailoringofsoftwareprocesses.TechnicalReport TR/DCC-2011-14,ComputerScienceDepartment,UniversityofChile.
Jacobson,I.,Booch,G.,Rumbaugh,J.,1999.TheUnifiedSoftwareDevelopment Pro-cess.Addison-WesleyLongmanPublishingCo.Inc.
Jantunen,S.,2010.Exploringsoftwareengineeringpracticesinsmalland medium-sizedorganizations.In:Proceedingsofthe2010ICSEWorkshoponCooperative
andHumanAspectsofSoftwareEngineering(CHASE’10).ACM,SouthAfrica,pp. 96–101.
Jouault,F.,Allilaire,F.,Bézivin,J.,Kurtev,I.,Valduriez,P.,2006.ATL:aQVT-like transformationlanguage.In:Companiontothe21thAnnualACMSIGPLAN Con-ferenceonOOPSLA’2006.ACM,pp.719–720.
JTC1Informationtechnology/SC7,2008.ISO/IEC12207:2008systemsand soft-wareengineering–softwarelifecycleprocesses.TechnicalReport,International OrganizationforStandarizationISO.
Kang,K.C.,Cohen,S.G.,Hess,J.A.,Novak,W.E.,Peterson,A.S.,1990.Feature-Oriented DomainAnalysis(FODA).Feasibilitystudy.TechnicalReportCMU/SEI-90-TR-21, SoftwareEngineeringInstitute.
Kettunen,P.,Laanti,M.,2005.Howtosteeranembeddedsoftwareproject:tactics forselectingthesoftwareprocessmodel.InformationandSoftwareTechnology 47,587–608.
Killisperger,P.,Stumptner,M.,Peters,G.,Grossmann,G.,Stückl,T.,2009.Metamodel basedarchitectureforsoftwareprocessinstantiation.In:TrustworthySoftware DevelopmentProcesses,InternationalConferenceonSoftwareProcess,ICSP 2009,LNCS5543,pp.63–74.
Koolmanojwong,S.,Boehm,B.W.,2012.Theincrementalcommitmentmodel pro-cesspatternsforrapid-fieldingprojects.In:Münchetal.(2010),pp.150–162. Kornyshova,E.,Deneckère,R.,Claudepierre,B.,2010.Contextualizationofmethod
components.In:ProceedingsoftheFourthInternationalConferenceonResearch ChallengesinInformationScience(RCIS).IEEECSPress,pp.235–246. Kruchten,P.,2003.TheRationalUnifiedProcess:AnIntroduction.Addison-Wesley
LongmanPublishingCo.Inc.,Boston,MA,USA.
Laplante,P.A.,Neill,C.J.,2004.Opinion:thedemiseofthewaterfallmodelis immi-nent.ACMQueue1(10),10–15.
Ma,J.,Wang,Y.,2006.Aquantitivecontextmodelofsoftwareprocesspatternsand itsapplicationmethod.In:ProceedingsoftheSixthInternationalConferenceon QualitySoftware.IEEEComputerSociety,pp.243–250.
Martínez-Ruiz,T.,García,F.,Piattini,M.,Münch,J.,2011.Modellingsoftwareprocess variability:anempiricalstudy.IETSoftware5(2),172–187.
Mirbel,I.,Ralyté,J.,2006.Situationalmethodengineering:combining assembly-basedand roadmap-drivenapproaches. Requirements Engineering11 (1), 58–78.
Münch,J.,Yang,Y.,Schäfer,W.(Eds.),2010.InternationalConferenceonSoftware Process,ICSP2010.Proceedings,Volume6195ofLNCS.Paderborn,Germany, July8–9,2010.Springer.
Ocampo,A.,Bella,F.,Münch,J.,2005.Softwareprocesscommonalityanalysis. Soft-wareProcess:ImprovementandPractice10(3),273–285.
OECD,2005.Smallandmediumenterprise(sme)outlookreport.TechnicalReport, OrganisationforEconomicCo-operationandDevelopment.
OMG,2007.SoftwareprocessengineeringmetamodelSPEM2.0OMGbeta specifi-cation.TechnicalReportptc/07-11-01,OMG.
Osterweil,L.J.,1987.Softwareprocessesaresoftwaretoo.In:9thInternational Con-ferenceonSoftwareEngineering,ICSE’1987,pp.2–13.
Park,S.,Na,H.,Sugumaran,V.,2006.Asemi-automatedfilteringtechniquefor soft-wareprocesstailoringusingneuralnetwork.ExpertSystemswithApplications 30,179–189.
Pedreira,O.,Piattini,M.,Luaces,M.R.,Brisaboa,N.,2007.Asystematicreviewof softwareprocesstailoring.SIGSOFTSoftwareEngineeringNotes32(3),1–6. Pérez,G.,ElEmam,K.,Madhavji,N.H.,1995.Customisingsoftwareprocessmodels.
In:4thEuropeanWorkshopSoftwareProcessTechnology,EWSPT’95,Volume 913ofLNCS,Springer,pp.70–78.
Pohl,K.,Böckle,G.,vanderLinden,F.J.,2005.SoftwareProductLineEngineering: Foundations,PrinciplesandTechniques,1sted.Springer.
Raffo,D.,Pfahl,D.,Zhang,L.(Eds.),2011.InternationalConferenceonSoftwareand SystemsProcess,ICSSP2011.Proceedings.ACM,Honolulu,HI,USA,May21–22, 2011.
Ralyté,J.,Deneckère,R.,Rolland,C.,2003.Towardsagenericmodelforsituational methodengineering.In:CAiSE2003,LNCS2681.Springer-Verlag,pp.95–110. Rolland,C.,2009.Methodengineering:state-of-the-artsurveyandresearch
pro-posal.In:Proceedingofthe 2009ConferenceonNew TrendsinSoftware Methodologies,ToolsandTechniques.IOSPress,Amsterdam,TheNetherlands, pp.3–21.
Rolland,C.,Nurcan,S.,2010.Businessprocesslinestodealwiththevariability.In: Proceedingsofthe201043rdHawaiiInternationalConferenceonSystem Sci-ences,HICSS’10.IEEEComputerSociety,pp.1–10.
Rombach,H.D.,2005.Integratedsoftwareprocessandproductlines.In: Interna-tionalSoftwareProcessWorkshop,SPW2005,Beijing,China,pp.83–90. Ruiz,P.,Quispe,A.,Bastarrica,M.C.,HurtadoAlegría,J.A.,2012.Formalizingthe
soft-wareprocessinsmallcompanies.TechnicalReportTR/DCC-2012-2,Computer ScienceDepartment,UniversidaddeChile.
Schmidt,D.C.,2006.Model-drivenengineering.IEEEComputer39(2),25–31. Simidchieva,B.I.,Clarke,L.A.,Osterweil,L.J.,2007.Representingprocessvariation
withaprocessfamily.In:Wang,Q.,Pfahl,D.,Raffo,D.M.(Eds.),International ConferenceonSoftwareProcess,ICSP’2007,LNCS4470.Springer,Minneapolis, USA,pp.109–120.
Simmonds,J.,Bastarrica,M.C.,2011.Modelingvariabilityinsoftwareprocesslines. TechnicalReportTR/DCC-2011-10,UniversidaddeChile,Departamentode Cien-ciasdelaComputacion.
Sutton,S.M.,Osterweil,L.J.,1996.Productfamiliesandprocessfamilies.In:ISPW ’96:Proceedingsofthe10thInternationalSoftwareProcessWorkshop.IEEE ComputerSociety,Washington,DC,USA,p.109.
Tolvanen, J.P., Rossi, M., Liu, H.,1996. Method engineering: current research directionsandimplicationsforfutureresearch.In:ProceedingsoftheIFIP
TC8,WG8.1/8.2WorkingConferenceonMethodEngineering:Principlesof MethodConstructionandToolSupport.Chapman&HallLtd.,London,UK, pp.296–317.
Valdés,G.,Astudillo,H.,Visconti,M.,López,C.,2010.TheTutelkánSPIframework forsmallsettings:amethodologytransfervehicle.In:Proceedingsofthe17th EuroSPI,vol.99.CommunicationsinComputerandInformationScience, Greno-ble,France,pp.142–152.
vonWangenheim,C.G.,Weber,S.,Hauck,J.C.R.,Trentin,G.,2006a.Experienceson establishingsoftwareprocessesinsmallcompanies.InformationandSoftware TechnologyJournal48(9),890–900.
vonWangenheim,C.,Varkoi,T.,Salviano,C.,2006b.Standardbasedsoftwareprocess assessmentsinsmallcompanies.JournalofSoftwareProcess:Improvementand Practice11(3),329–335.
Washizaki,H.,2006.Buildingsoftwareprocesslinearchitecturesfrombottomup.In: Münch,J.,Vierimaa,M.(Eds.),Product-FocusedSoftwareProcessImprovement, LNCS4034.Springer,Amsterdam,TheNetherlands,pp.415–421.
Weiss,D.M.,Lai,C.T.R.,1999.SoftwareProduct-LineEngineering:AFamily-Based SoftwareDevelopmentProcess.Addison-WesleyProfessional.
Xu,P.,2005.Knowledgesupportinsoftwareprocesstailoring.In:Proceedingsofthe 38thAnnualHawaiiInternationalConferenceonSystemSciences,HICSS’05. Zowghi,D.,Firesmith,D.,Henderson-Sellers,B.,2005.UsingtheOPENprocess
frame-worktoproduceasituation-specificrequirementsengineeringmethod.In: Ralyté,J.,Agerfalk,P.J.,Kraiem,N.(Eds.),ProceedingsofSREP05.Paris,France, pp.59–74.
JulioArielHurtadoisanAssociatedProfessorattheSystemsDepartment,atthe Uni-versidaddelCauca.HeismemberoftheIDISgroup(SoftwareEngineeringResearch andDevelopment)since2005.HereceivedhisPh.D.inComputerSciencefrom theUniversidaddeChilein2012andaBachelorinElectronicand Telecommuni-cationsEngineeringfromtheUniversidadDelCaucain1997.Hismainresearch
topicsaresoftwareengineering,softwareprocessmodels,softwarearchitecture, model-drivenengineering,andsoftwareproductlines.Lately,hisworkhasfocused onapplyingusingMDEtechniquesandSPLapproachesfordesigningandanalyzing softwareprocessmodels.
MaríaCeciliaBastarricaisanAssistantProfessorattheComputerScience Depart-ment,attheUniversidaddeChile.ShecoordinatestheMaTEgroup(Modeland TransformationEngineering)since2007.ShereceivedherPh.D.inComputerScience andEngineeringfromtheUniversityofConnecticutin2000,aMasterofSciencefrom thePontificiaUniversidadCatólicadeChilein1994,andaBachelorinEngineering fromtheCatholicUniversityofUruguayin1991.Hermainresearchtopicsare soft-wareengineering,softwarearchitecture,model-drivenengineering,andsoftware productlines.Lately,herworkhasfocusedonapplyingusingMDEtechniquesfor modelingsoftwareprocesses.
JocelynSimmondsisaLecturerattheDepartmentodeInformaticaatthe Universi-dadTécnicaFedericoSantaMaría,Chile.ShereceivedherPh.D.fromtheUniversityof Torontoin2011.Hermainresearchareaissoftwareengineering,withspecific inter-estsinsoftwaretesting,behaviouranalysis,requirementsengineering,andmobile andwebdevelopment.
Sergio Ochoa is an Associate Professor of Computer Science Department at the Universidadde Chile.He receivedhis Ph.D. in EngineeringScience from Pontificia Universidad Católica de Chile in 2002 and a Bachelor in Software SystemsEngineerfrom UNICEN,Argentinain 1996. Hismain researchtopics areMobile/Ubiquitous/SocialComputing(particularlycontextawareness, loosely-coupledwork,positioning,adhocnetworking,systemsmodeling)andSoftware Engineering(softwaresystemsmodeling,developmentinsmallsoftware enter-prises:requirementsengineering,communicationandcoordinationandsoftware processtailoring).HeisactivememberoftheCARLandLACCIRnetworks;theSCCC conference,andtheIEEECS,ACMandCLEIjournals.
