Year

2021-09-14 来源：独旅网

LAPPEENRANTAUNIVERSITYOFTECHNOLOGYDepartmentofInformationTechnology

SOFTWAREPROCESSIMPROVEMENTUSINGANELEC-TRONICPROCESSGUIDE

ThesubjectofthisthesiswasapprovedbythecounciloftheDepartmentofInformationTechnologyonthe21stofAugust,2001.

Supervisor:ProfessorJanVoracekInstructor:M.Sc.(eng.)KeijoMarttinen

Lappeenranta,November19,2001

MarkusMannioLeirikatu2G2

53600Lappeenranta

Tel.+358(0)407277794

ABSTRACT

Author:Subject:

MarkusMannio

Softwareprocessimprovementusinganelectronicprocessguide

Department:InformationtechnologyYear:Place:

2001Lappeenranta

Master’sthesis.LappeenrantaUniversityofTechnology.72pages,8ﬁgures,2tables,and3appendices.Supervisor:Keywords:

ProfessorJanVoracek

softwareprocess,softwareprocessimprovement,processmodelling,pro-cessguide

Softwareprocessesandtheirimprovementhavereceivedconsiderableattentioninthere-centyearsduetoanincreasinginterestinsoftwarequality.Softwareprocessimprovementmodels,suchasCMMandSPICE,arebeingintroducedtosoftwarecompaniesworld-wideinthequestforbettersoftware.Atthesametimeithasbeenrealisedthateffectiveprocessimprovementandperformancerequireadescriptionoftheprocesstoenablethor-oughprocessunderstandingandaccuratecommunication.Variouswaysfordescribingasoftwareprocessexisttoservedifferentpurposes.Aprocessguideisarepresentationofaprocessfocusedonprocessunderstandingandcommunication.Anelectronicprocessguideisaprocessguidetakingadvantageofthepossibilitiesofferedbywebtechnologies.Inthisworkanenvironmentfordevelopingelectronicprocessguidesforsupportingsoft-wareprocessimprovementandperformanceisdeveloped.Theenvironmentenablesthemodelling,customising,andinstantiatingofasoftwareprocessasaprocessguide.Theenvironmentisvalidatedbymodelingthesoftwareprocessofatelecommunicationssoft-warecompanyandcreatingelectronicprocessguidestosupporttheprocessimprove-mentandexecutionactivities.Finally,thesupportandpossibilitiesofferedbytheprocessguidesinthetargetcompanyareexploredanddiscussed.

TIIVISTELMÄ

Tekijä:Nimi:Osasto:Vuosi:Paikka:

MarkusMannio

OhjelmistoprosessinkehittäminensähköisenprosessioppaanavullaTietotekniikanosasto2001Lappeenranta

Diplomityö.Lappeenrannanteknillinenkorkeakoulu.72sivua,8kuvaa,2taulukkoaja3liitettä.Tarkastaja:Hakusanat:

ProfessoriJanVoracek

ohjelmistoprosessi,ohjelmistoprosessinkehittäminen,prosessinmallintami-nen,prosessiopas

Kasvavakiinnostusohjelmistojenlaatuakohtaanonherättänytohjelmistoprosesseihinjaniidenkehittämiseenkohdistuvaahuomiotaviimevuosina.Ohjelmistoyrityksetympärimaailmaaovatottaneetkäyttöönohjelmistoprosessinkehittämismalleja,kutenCMMjaSPICE,pyrkiessäänkohtiparempilaatuisiaohjelmistotuotteita.Samallaonhuomattu,ettätehokasprosessienparantaminenjasuorittaminentarvitseetuekseenkuvauksenproses-sista,jottaprosessinperusteellinenymmärtäminenjakommunikointiolisimahdollista.Ohjelmistoprosessejavoidaankuvatamonillaeritavoilla.Prosessiopasonprosessinesi-tysmuoto,jonkapäätarkoituksenaonhelpottaaprosessinymmärtämistäjakommunikoin-tia.ElektroninenprosessiopasonWeb-teknologiaahyödyntäväprosessiopas.

Tässätyössäluodaankehitysympäristöelektronisilleprosessioppaille,joidentarkoituk-senaontukeaohjelmistoprosessinkehittämistäjasuorittamista.Ympäristömahdollistaaohjelmistoprosessinmallintamisensekäyksilöllistenoppaidenluomisenjamuokkaamisen.Kehitysympäristöäkäytetäänmallintamaantietoliikenneohjelmistojavalmistavanyrityk-senohjelmistoprosessiasekäluomaanelektronisiaprosessioppaitatukemaanprosessinkehitystäjasuorittamista.Lopuksipohditaanprosessioppaidentarjoamaatukeasekämahdollisuuksiakohdeyrityksessä.

PREFACE

ThisthesiswasmadeinLappeenrantafortheDepartmentofInformationTechnologyofLappeenrantaUniversityofTechnologyandtheworkwascarriedoutinIntellitelCom-municationsLtd.

IwouldliketothankmyinstructorKeijoMarttinenandIlkkaToivanenforinvaluablesuggestions,guidance,andsupportthroughoutthiswork.Also,thanksareextendedtothesupervisorofthisworkProfessorJanVoracek.

MysincerestappreciationgoestomyparentsforofferingmethechancetodowhatIwant,andtoSuviforbearingmewhileIhavebeendoingit.VeryspecialthanksarereservedforJoonasandEinariforprovidingendlessentertainmentandfoodforrefreshingthoughts.AndwhileI’matit,ImustthankCaroandUrhoaswell.Ionlywishthattheycouldreadthis.

Lappeenranta,November19,2001

MarkusMannio

Contents

1INTRODUCTION

1.1Background.................................1.2Scopeandobjectives............................1.3

Structureofthework............................

2THESOFTWAREPROCESS2.1

Softwareprocessconcepts.........................2.1.1Processengineering........................2.1.2Softwareengineering........................2.1.3Processdeﬁnition..........................2.1.4Theprocesslifecycle........................

2.2

Softwareprocessimprovement.......................2.2.1Evaluateprocess..........................2.2.2Developprocess..........................2.2.3Installprocess............................2.2.4

Monitorprocessuse........................

2.2.5SPIManagement..........................2.2.6Processmaturityandcapability..................2.3

Softwareprocessimprovementandassessmentmodels..........2.3.1Capabilitymaturitymodel.....................2.3.2Softwareprocessimprovementandcapabilitydetermination...2.3.3

BOOTSTRAP...........................

3PROCESSREPRESENTATION3.1

Conceptualframework...........................3.1.1Entities...............................3.1.2Relationships............................3.1.3Behaviouralinformation......................3.2

Representationtypes............................3.2.1Processmodels...........................3.2.2Processtemplatesandforms....................

3.2.3Processguides...........................3.3

Processmodellinglanguagesandparadigms................

6688101111131415171819202121222223242526272729303132343436

3.3.1Multi-ViewProcessmodelingLanguage..............3.3.2AdaProcess-ProgrammingLanguageandJIL...........3.3.3IntegrationDeﬁnitionlanguage0.................3.3.4UniﬁedModelingLanguage....................3.3.5Process-orientedModellizationandEnactionofsoftwareDevel-opments...............................3.3.6

TheUniﬁedProcess........................

4THEEPGENVIRONMENT

4.1Conceptualschema.............................

4.1.1Entities...............................4.1.2Relationships............................4.1.3Behaviour..............................

4.2

Processmodelling..............................4.2.1Modellingobjectivesandscope..................4.2.2Conceptualschema.........................4.2.3Modellinglanguages........................4.2.4Toolselection............................4.2.5Elicitprocessknowledge......................4.2.6

Modelcreation...........................

4.2.7Modelandprocessanalysis....................4.3

EPGcreation................................4.3.1Planninginformationcontent....................4.3.2Customisinglayoutandmetrics..................4.3.3

Buildingtheguide.........................

4.3.4Customisinginstance.......................4.3.5Administratorguide........................4.4

Summaryoftheenvironmentarchitecture.................

5EPGSUPPORTFORPROCESSIMPROVEMENTANDENACTMENT5.1Evaluateprocess..............................5.2Developprocess...............................5.3Installprocess................................5.4

Performanceandmonitoring........................

37383838393941414143434445454647474850515152525454555858606162

5.4.15.4.2

Processperformance........................Monitorprocessuse........................

6263656DISCUSSIONANDCONCLUSIONS7SUMMARYREFERENCESAPPENDICES

676973

ABBREVIATIONS

ADAPPL/ACMMCPIEPGHTMLIDEF0IECISOKPAMVP-LOMGPALPMLPSEESADTSEISPISPICESPIESSD

ActivityDiagram

AdaProcessProgrammingLanguageCapabilityMaturityModelContinuousProcessImprovementElectronicProcessGuideHypertextMarkupLanguageIntegrationDeﬁnitionLanguage0InternationalElectrotechnicalCommissionInternationalOrganizationforStandardizationKeyProcessArea

Multi-ViewProcessmodelingLanguageObjectManagementGroupProcessAssetLibraryProcessModellingLanguage

Process-centeredSoftwareEngineeringEnvironmentStructuredAnalysisandDesignTechniqueSoftwareEngineeringInstituteSoftwareProcessImprovement

SoftwareProcessImprovementandCapabilityDeterminationSoftwareProcessImprovementEngineeringStaticStructuralDiagram

TCMToolkitforConceptualModelingUMLUniﬁedModelingLanguageUPUniﬁedProcessUPM

UniﬁedProcessModel

1INTRODUCTION

1.1Background

Duringthelastcoupleofdecadessoftwarehasbecomecommonplaceinthedailylivesofmanypeople.Whethertheyacknowledgeitornot,manypeopleareincontactwithsoft-wareormachinescontrolledwithsoftwarealmostconstantly.Thisnotonlyincludestheobvious,suchascomputersormobilephones,butalsothemoreinconspicuoushomeelec-tronicandmanycommonservices.Groceriespaidwithacreditcardupdatethedatabasesofacreditcompanyandmodernwashingmachines,coffee-makers,orcarsincludeem-beddedsoftwaremoreoftenthannot.Sincesoftwarehasbecomeanintegralpartoftheseservicesanddevices,theirperformanceandfunctionalitiesareaffectedbythecharacter-isticsoftheunderlyingsoftware.Theoverallqualityoftheserviceorproduct,whetheritisacomputerorawashingmachine,isaffectedbythequalityofthesoftware.Whereasqualityhasbeenafocusfortraditionalengineeringandmanufacturingfromthe1930s,thequalityofsoftwarehasreceivedattentiononlyfromthe1980s.

Muchofthecurrentinteresttowardssoftwarequalityisbasedontheassumptionthatthequalityofthesoftwareishighlydependentonthequalityoftheprocessusedtodevelopthesoftware-thesoftwareprocess[1,2,3].Thatis,thequalityofasoftwareprod-uctisheavilydependentonthepeople,organisation,andproceduresusedtocreateanddeliverit[1].Consequently,theassumptionhasleadtothenotionthatimprovingthesoftwareprocessshouldresultinimprovedsoftware.Unfortunately,softwareproductsandprocessesareseenascomplexentitieswhosesuccessfulimprovementinasoftwaredevelopingorganisationsseemtorequireconsiderableeffort[1,2,3,4].Fromanorgan-isationalviewpointsoftwareprocessimprovement(SPI)needssupportingorganisationalstructures,ﬁnancialinvestment,culturalenvironment,andtopmanagementsupport[2].TheseaspectsconstitutetheenvironmentwheresuccessfulSPIispossible,andtheab-senceofanyoftheseelementsislikelytocausethefailureofanSPIeffort[2].Fromanindividualviewpointthesoftwaredevelopersneedinformationaboutthemethods,tech-niques,andtoolstocarryoutthesoftwareprocess.Aboveall,softwareprocessimprove-mentseemstorequireprecisedeﬁnitionanddescriptionoftheprocessitself[1,4,5,6].Indeed,mostofthewidelyacceptedsoftwarequalityandimprovementmodels,such

ascapabilitymaturitymodel(CMM)andsoftwareprocessimprovementandcapabilitydetermination(SPICE),introduceexplicitprocessdescriptionasoneofthemostimpor-tantfactorssupportingprocessimprovement[4]tofunctionasthebaselineforprocesschangesrequiredbySPI.

RepresentationsofasoftwareprocessbasedonanexplicitprocessdeﬁnitioncanbeusedinasoftwaredevelopingorganisationalsofornumerousotherpurposesapartfromSPI,suchasvehiclesforprocessunderstandingandcommunication,andsupportforprocessexecutionandmanagement[1,7,9,8].Variousformalismsforcreatingprocessdeﬁni-tionsandrepresentationshavebeensuggestedbyresearcherstoaidinpresentingcomplexsoftwareprocessesinacomprehensiveway,butunfortunatelymostofthesenotationsorprocessmodellinglanguages(PML)haveproventobetoocomplextobeadoptedinpractise[1].Practitioners’primaryconcernsseemtobeunderstandingandcommunicat-ingtheprocesses,andconsequentlyprocessrepresentationsshouldbeintuitiveandeasytouse[1].Softwareengineersneedtounderstandandcommunicatetheprocesstheyareperformingaswellastheprocessengineersneedtounderstandandcommunicatetheprocesstheyareimproving.Theneedforunderstandablerepresentationsofrelativelyloosely-deﬁnedandfrequentlychangingprocesseshasrecentlybeenacknowledgedbyre-searchers[1,9],andapproachesforsupportingprocesstechnologyhavebeensuggested[9,10,11].

Electronicprocessguides(EPG)areweb-basedsoftwareprocessrepresentationsthatarefocusedoncommunicatingthesoftwareprocessinamannerthatcanbeeasilyunder-stoodandfollowedbysoftwareengineers[9].Inadditiontoprovidinginformationtothesoftwareengineers,anEPGcanalsobeusedasasupportingtoolforSPIefforts.WebtechnologiesenabletheuseofEPGasavehicleforcollecting,storing,andanalysingprocessrelatedinformationwhichcouldprovidetheprocessengineersinvaluableinfor-mationaboutthesoftwareprocess.AlthoughthedevelopmentofEPGsforofferingguid-ancetoprocessperformershasbeenpresented[9,10],thedevelopmentanduseofEPGsforsupportingSPIhasnotbeenwidelydiscussed.InthisworkthecreationanduseofEPGsforsupportingsoftwareprocessimprovementandperformancetoaidinimprovingsoftwarequalityisstudied.

1.2Scopeandobjectives

Themainobjectiveofthisthesiswastodevelopanelectronicprocessguideenvironmentforprocesseswhererepresentationsofthesoftwareprocesscanbecreated.Aprocessguidedevelopedwithintheenvironmentwastosupportsoftwareprocessimprovement,increaseprocessunderstanding,andfacilitatecommunicationwithinandbetweendiffer-entusergroups.Softwareandprocessengineerswereselectedastheprimaryusergroupsfortheprocessguides,andtheprimaryrequirementsfortheguideswereunderstandabilityandtheeaseoftheiruse.Theframeworkwasvalidatedbymodellingthesoftwarepro-cessofatelecommunicationssoftwarecompanyandexploringhowtheelectronicprocessguidesbasedonthemodelcouldsupportthesoftwareimprovementanddevelopmentac-tivitiesinthecompany.Theunderlyinggeneralhypothesiswasthataproperlydesignedprocessguidecanbeavaluableaidinallphasesofsoftwareprocessimprovement.

1.3Structureofthework

Therestofthethesisisorganisedinthefollowingway.

Chapter2focusesonthesoftwareprocessandsoftwareprocessimprovement.Softwareprocessandprocessimprovementcontext,concepts,anddeﬁnitionsarepresented.Chapter3describeshowthesoftwareprocesspresentedinChapter1canbedeﬁnedandrepresented.Thetopicsofthischapterincludetheconceptualframework,andthedifferentmethodologiesandlanguagesforrepresentingsoftwareprocesses.Especiallyprocessguidesasthemeanstorepresentprocessesarediscussed.

Chapter4describesthestructureanddevelopmentofanelectronicprocessguideframe-work.ThischapteriscloselyrelatedtoChapter3andthesoftwareprocessconceptspresentedinChapter2.

Chapter5discusseshowtheEPGsdevelopedintheframeworksupportthesoftwareprocessimprovementandexecutionactivitiesinatelecommunicationssoftwarecompany.

TheprocessimprovementpartofChapter2andChapter4asawholeformthebackgroundforthischapter.

InChapter6theEPGenvironmentpresentedinChapter4anditspossibleusesdescribedinChapter5arediscussedandconclusionsarealsomade.Finally,Chapter7presentsabriefsummaryofthethesis.

2THESOFTWAREPROCESS

Variousdeﬁnitionsforthesoftwareprocesshavebeensuggested[1,3,5].Commonlyaprocessisunderstood,asdeﬁnedintheCambridgeInternationalDictionaryofEnglish[12]

aseriesofactionsoreventsthatarepartofasystemoracontinuingdevelopment,oraseriesofactionsthataredonetoachieveaparticularresult

Insoftwaredevelopmentcontexttheparticularresultmentionedinthedeﬁnitioncanbethoughttobe,forexample,thesoftwareproductfulﬁllingtherequirementssettoit,ormorebroadlyasatisﬁeduserorcustomer.Fuggetta[1]deﬁnesthesoftwareprocessas

thecoherentsetofpolicies,organisationalstructures,technologies,proce-dures,andartifactsthatareneededtoconceive,develop,deploy,andmaintainasoftwareproduct

Asoftwareprocesswiththeabovedeﬁnitionorthegeneralprocessdeﬁnitioninsoftwaredevelopmentcontextwiththementionedendresults,especiallyinthebroadersense,cannotexistwithoutsupportinginfrastructure[3].Fuggetta[1]mentionsfourconceptsandcontributionsthatthesoftwareprocessexploits:

1.softwaredevelopmenttechnology,

2.softwaredevelopmentmethods,techniques,andguidelines,3.organisationalbehaviour,and4.marketingandeconomy.

AlthoughthisworkconcentratesonsoftwareprocessdeﬁnitionandrepresentationstoaidinSPIandprocessexecution,itshouldbeacknowledgedthattheseissuescoveronlyone

partofeffectiveutilisationofprocesstechnologyinsoftwaredevelopingorganisation.Anumberoforganisational,cultural,technological,andeconomicfactorsneededtosupportthesoftwareprocess[1]areoutofthescopeofthiswork.Theseissuesarecoveredmoreextensivelyinsoftwareprocessliterature,forexamplein[3].

Inthischapterthebasicconceptsofsoftwareprocessesandtheirimprovementaredis-cussed.First,thebasicsoftwareprocessconceptsandcontextareexplainedinmorede-tail.Next,generalsoftwareprocessimprovementconceptsarepresented.Finally,aviewtosomeofthemorecommonpracticalsoftwareprocessimprovementandassessmentmodelsisgiven.

2.1Softwareprocessconcepts

Inthissubchaptersomeessentialsoftwareprocessconceptsarediscussed.TheconceptsaredescribedinaframeworkforsoftwareprocessandsoftwaredevelopmentpresentedinFigure1.Thesquareboxesintheﬁgurerepresentobjectsorartifacts,whiletheroundedboxesshowtheactivities.Theﬁgureencompassesalltheactivitiesfromprocessengineer-ingtotheresultsofexecutingthesoftware,ascanbeseenbylookingattheuppermostandlowestboxesintheﬁgure.Nextthedifferentphasesinsoftwareprocessanddevelopmentarediscussedinmoredetail.

2.1.1Processengineering

Processengineeringistheactivityofperformingaprocessengineeringprocess[6].TheuppermostboxinFigure1representstheprocessengineeringprocessi.e.thedescriptionofhowprocessesareengineered.Thesecondboxshowstheactualexecutionofthepro-cessengineeringprocess,andthusitrepresentsprocessengineering.Inprocessterminol-ogytheexecutionofaprocessaccordingtoaprocessdeﬁnitionisoftencalledenactment[13],whichisalsousedinthisworkfromhereon.Processesareenactedbyagentsthatareentities,suchasindividuals,groups,ormachines[6,13];agentsasperformersofpro-cessactivitiesarediscussedmorethoroughlywithprocessmodellinginChapter3.The

ProcessEngineering

SoftwareEngineering

SoftwareExecution

Software Process Engineering Processis applied to develop and evolveProcess enactmentby process engineers

Software (Development) Processis applied to develop and evolveProcess enactmentby software engineers

Software Productis applied to developSoftware users

Results for UsersFigure1:TheProcessFramework[6].

processengineeringprocessdeﬁnitionintheﬁrstboxisameta-process,becauseitisaprocessoperatingonprocesses.Conceptuallymoreabstractlevelsofprocessesarenotneededbecausethemeta-processcanbeenactedtodevelopandevolveitself[6].ThiscouldbepresentedinFigure1asaloopinvolvingtheﬁrst,processengineeringprocess,andthesecond,processengineering,box.

Inthecontextofdevelopingsoftware,theuppermostboxrepresentsthedeﬁnitionoftheprocessofdevelopingasoftwareprocess.Inthesecondbox,representingprocessen-gineering,theprocessshownintheuppermostboxisenactedandasaresultasoftwareprocessiscreatedasshowninthethirdbox.Thus,insoftwareprocessengineeringac-tivitiesthethreeuppermostboxesareinvolved.Theactualsoftwareprocessengineering,inthesecondbox,isusuallyperformedbyprocessengineersorqualityengineers.Gen-erally,processengineeringisperformedbythepeopleresponsibleforthecreationandimprovementofsoftwareprocessdeﬁnitionsandmodelsinsoftwaredevelopingorgani-sations.

Softwaredevelopmentandprocessdevelopmentenjoynumeroussimilarities.Forexam-ple,processdevelopmentcanbedescribedinsoftwareengineeringterms,thusincludingactivitieslikeplanning,design,instantiation,andvalidation[6].Ithasevenbeensug-gestedthatsoftwareprocessesareaformofsoftwarethemselvesandthatprocessengi-neeringmethodscouldbeborrowedfromsoftwaredevelopment[5].Processengineeringisnotjustanisolatedactivityinsoftwaredevelopment,butitisalsohighlydependentofotheraspectsofthesoftwaredevelopingorganisation.Forexample,aculturalchangeandsupportinginfrastructureareneededtoswitchfromthemoretraditionalproduct-focusedorganisationtoamoreprocess-focusedone[3].

2.1.2Softwareengineering

Softwareengineeringisatechnologyconsistingofaprocess,asetofmethods,andtoolstobuildcomputersoftware[14].SoftwareengineeringactivitiesencompassthethreemidmostboxesinFigure1.Theﬁrstboxrepresentstheresultoftheprevioussoftwareprocessengineeringactivities,thesoftwareprocess.Inthenextboxthesoftwareprocessisenactedbysoftwareengineerswiththehelpofappropriatemethodsandtools,andas

aresultacomputersoftwareproductisobtainedasshowninthefollowingsquarebox.Althoughthesoftwareengineersareshownintheﬁgure“only”astheperformersofadeﬁnedprocess,itisgenerallyacknowledgedthatbuildingasoftwarerequirescreativitythattheprocessdisciplineshouldencourageratherthanstiﬂe[3].

Finally,thethreelowestboxesinFigure1describeasoftwareuserusingthesoftwaretoaccomplishsomethingofvalueforhimself.

2.1.3Processdeﬁnition

ThetwouppermostsquareboxesinFigure1representprocessdeﬁnitions.FeilerandHumphrey[13]deﬁneprocessdeﬁnitionas

animplementationofprocessdesignintheformofapartiallyorderedsetofprocessstepsthatisenactable.

Theyalsopresentthenotionsthataprocessdeﬁnitionmayconsistof(sub)processdeﬁ-nitions,andatalowerlevelofabstractioneachprocessstepmaybefurtherreﬁnedintomoredetailedprocesssteps.Processdeﬁnitionswhose“levelsofabstractionarefullyre-ﬁned”arereferredascompleteandﬁtforenactment.Animportantobservationispointedoutaboutthecompletenessofprocessdeﬁnitions,whichisconsideredtobedependentonthecontextandperformersoftheprocess.ThisalsosupportstheideaofKellneretal.[6]thatprocessesshouldbeengineeredtomeetspeciﬁcgoalsandobjectives,subjecttothereal-worldconstraintsthatapply.Currentskilllevelsofexistingstaffandlimitsoncycletimearepresentedasexamplesofsuchconstraints.Althoughthereisnocleartechnicallimittothelevelofreﬁnementforasoftwareprocess,FeilerandHumphrey[13]listanumberofpracticalconcernsthataffectthelimitofreﬁnementincluding

resourcesandtimeavailableforprocessdeﬁnition,levelofcapabilityorunderstandingoftheprocessusers,

scaleoftheprojectsforwhichtheprocessisdesigned,andscalabilityoftheprocessitself.

Inpractise,ﬁndingtherightlevelofabstractionforprocessdeﬁnitionsisdifﬁcultsincedeﬁnitionsreﬁnedtoexcessivedetailoftenresultintoocomplexprocessrepresentationswhiletoogeneraldeﬁnitionscanbecompletelyunusable[15].

Scalabilityoftheprocess,mentionedabove,iscloselyconnectedtoanotherimportantconcept,namelythereuseofsoftwareprocesses.Clearlyitisnotreasonabletodeﬁnecompletelynewprocessesforeachsoftwaredevelopmentprojectfromnothing,especiallywhensoftwareprocessdevelopmentcanbeveryexpensiveandtimeconsuming[13].Itislikelythatinsoftwaredevelopingorganisationsdifferentprojectswillhavesimilarneedsandcommonactivities,butitisalsohighlyprobablethatsomeoftheneedsofdifferentdevelopmentprojectsareverydifferent.FeilerandHumphrey[13]addressthisproblemofsharedprocessdeﬁnitionsbysuggestingthedevelopmentanduseofasetofgeneralpurpose,reusableprocesselements.Asinsoftwareengineeringalibraryofreusablecom-ponentscanbeused,alsoinprocessengineeringalibraryofreusableprocesscomponentscanbeseenasavaluableassetforanorganisation.Suchprocessassetlibrary(PAL)isdiscussed,forexample,in[6],[8],and[16].Ifsuitablegeneralprocessesareavailableanenactableprocesscanbeinstantiatedfromtheirdeﬁnitions.Thus,instantiationinprocessterminologyistheactofcreatingenactableprocesses,includingalltheelementsrequiredforenactment,fromprocessdeﬁnitions[13].

2.1.4Theprocesslifecycle

Abovethebasicconceptsofsoftwareprocesseswerepresented.Nowadescription,whichtiesthepreviouslyconceptstogetherisdescribed.

ThedescriptionpresentedinFigure2,theprocesscycle,isoriginallypresentedbyMad-havji[17]andfurtherexplained,forexample,in[8].Theprocesscyclecanineffectbethoughtasaviewtoaprocesslifecyclecontainingfourparts:descriptionanddeﬁni-tion,customisationandinstantiation,enactment,andimprovement.Theprocesscycle

Figure2:TheProcessCycle[8].

describestherelationshipsbetweenthekeyroles,tools,andgoalsindifferentpartsofaprocesslifecycle.Thecyclealsoincludesanimportantlinkbetweenprocessandsoftwareengineering,namelyprocessmanagement.

Theoutersectionsofthecyclearedividedintothreesectors,whichrepresenttheengi-neering,managing,andenactmentofsoftwareprocesses.Eachofthethreesectorshasitsowngoalsandpolicies,keyroles,andtools.Thecenterofthecycledescribestheprimaryitemstransferredbetweenthedifferentsectorsofthecycle.SectorAencom-passesthemainprocessengineeringactivitieswhereprocessengineersdesign,construct,andimprovegenericprocessdeﬁnitions.Thesedeﬁnitionsarenottailoredtoanyspeciﬁcproject,andtheycanbestoredtoaPAL.SectorBintroducestheprocessmanagementaspectwhereprocessmanagersareactinginacentralrole.AccordingtoFigure2pro-cessmanagerstailorthegenericprocessdeﬁnitionstoaspeciﬁcuse,andthusinstantiateprocesses.TheinstantiatedprocessesareenactedinsectorCbyprocessperformerswithapplicationspeciﬁcgoalsandpolicies.InthecontextofsoftwaredevelopmentpresentedinFigure1processengineeringcontainssectorsAandB,andsoftwareengineeringisincludedinsectorC.

Inthecenterofthecyclethemainitemsmovingbetweenthedifferentsectorsarede-scribed.TheprocessdeﬁnitionsarecreatedandupdatedinsectorA,fromwheretheyaretransferredtosectorBforinstantiation.TheinstantiatedprocessesareenactedinsectorC,whileprocessmanagersreceiveprocessfeedbackfromtheprocessperformers.Thisfeedbackmightreﬂect,forexample,thesmoothnesswithwhichassignedtasksarecarriedout,bottlenecksintheprocess,negativeeffectscausedbytimingconstraints,ortheneedforadditionalprocessstepsorremovalofsuperﬂuousones[8].Processmanagersmaymakechangestotheproject-speciﬁcprocessinstances,orsuggestchangestotheprocessengineersmaintainingthemoregeneralprocessdeﬁnitionsinsectorA.

2.2Softwareprocessimprovement

Intheprevioussectionthebasicconceptsofsoftwareprocessengineeringwerepresented.Also,adescriptionofsoftwareprocesslifecycleglueingtheprocessconceptstogether

wasintroduced.Inthissubchapterthefocusisshiftedtowardsimprovingthesoftwareprocess.

Alargenumberofdifferentmodelsandguidelinesforimprovingthesoftwareprocesshavebeenintroducedinthelastdecade[3,6,18].Infact,eventheprocesscyclede-scribedearlierinFigure2contains,amongotherthings,aninherentmechanismforsoft-wareimprovementthroughprocessfeedbackandexperience.Althoughthereseemstobeaplethoraofdifferentsoftwareprocessimprovementparadigmstochoosefrom,mostofthemorewidelyacceptedmodelsarebaseduponthesameideologicalbackground.ManyofthecurrentSPIeffortsarebuiltupontheworkbegunbyqualityresearchersoversixdecadesago:WalterShewhartpresentedthe“plan,do,check,act”cycleforqualityimprovementinthe30’s,whichEdwardsDemingamongothersfurtherdevelopedanddemonstrated[3].Adaptationsofthequalitymovementscyclicalimprovementmodeltoprocessesareseeninprocessmanagementliteratureintheconceptofcontinuousprocessimprovement(CPI).Oneofthemostinﬂuentialpersonsinprocessimprovementinsoft-waredevelopmenthasbeenWattsHumphrey,whoadaptedthelessonslearntinthequalitymovementforsoftwaredevelopment[3].

AnexampleofCPIinthecontextofsoftwaredevelopmentispresentedin[6]asthebasiccycleofthehelicalmodelofsoftwareprocessimprovementengineering(SPIE),whichisshowninFigure3.Thebasicconceptspresentedinthehelicalmodelaregenerallyalsofoundinanyothercyclicalprocessimprovementmodel(e.g.[18]),andthebasiccycleofthehelicalmodelisusedhereasanexampletoclarifytheseconceptsinthenextcoupleofsubsections.ToillustratethispointreferencestoHumphrey’sprocessimprovementcycle,reviewedin[3],arealsomade.

2.2.1Evaluateprocess

AlthoughthecycleinFigure3canbeenteredatanyphase,thenaturalwaytobeginim-provingaprocessistotrytounderstandthecurrentprocess.Ifaprocessmodeldoesnotexist,thecurrentprocesscanbemodeledinthisphasetoaidinunderstandingasdescribedinChapter3.Thus,modellingtheprocessatthisphaseisdescriptivemodelling,whichineffecttriestodescribethecurrentprocessasitisperformed[7].Also,allavailablein-18

EvaluateProcessManageSPIE

MonitorUseDevelopProcessInstallProcessFigure3:HelicalModel–TheBasicCycle[6].

formationabouttheprocessshouldbeusedtoevaluatetheprocess.Bothqualitativeandquantitativeanalysisshouldbeused:theinformationmaybequalitativeandsubjectiveatthebeginning,butshouldshifttowardsmorequantitativeinformationastheprocessimprovementactivitiesproceed.Measurementofthequantitativeinformation,suchasdefectcountsandcycletimes,shouldbeincludedaspartoftheimprovedprocess.Othersourcesofprocessinformationincludeprocessperformers,asshownintheprocesscy-cleinFigure2,otherprojects,andliterature[6].ThisphasecorrespondswiththeﬁrstphaseofHumphrey’ssixstepprocessimprovementcycleconsistingofunderstandingthecurrentprocess[3].

2.2.2Developprocess

Inthisphasetheactualimprovedprocessisdevelopedandchangestotheprocessareapplied.Accordingto[6],activitiesperformedinthisphaseare:

determinegoalsandconstraintsfortheprocess,

planprocessdevelopment,

identifyandunderstandprocessalternatives,analyseandchooseprocessalternatives,deﬁnetheimprovedprocess,reducerisks,and

documentandpackagetheprocessdeﬁnitionmaterials.

Someofthestepsaresomewhatself-explanatorywhereasotheractivitiesmayneedclariﬁ-cation.Theactivitiesfocusingontheprocessalternativesincludeidentifying,understand-ing,andchoosingthereusableprocessassetsthatmaybestoredinaprojectassetlibrary.Also,alternativeapproachesfortheprocessdevelopmentareconsideredandadecisionismadebasedonthegoals,constraints,andqualitativeandquantitativeconsiderationsoftheprocess.Indeﬁningtheprocess,modellingandthedevelopmentofaprocessguideareconsideredasanappropriateapproaches.Atthisphasethemodellingactivitiesincludemainlyprescriptivemodellinginwhich–asopposedtodescriptivemodellingmentionedinpreviousphase–theprocessismodeledasitshouldbeperformed[7].

Reducingrisksincludesactivities,suchasveriﬁcationandvalidationofthedeﬁnedpro-cess.Inthelaststep,theresultsofthepreviousphasesaredocumentedaccordingthenextintendeduseofthematerials.Theﬁnalresultmaybeadetailedmodel,ahigh-levelmodel,aprocessguide,ortrainingmaterialdependingonthepurposeoftheprocessimprovement[6].IncomparisonwithHumphrey’scycle,thisphaseofthehelicalcycleincludesthethreefollowingstepsofHumphrey’scycle:developingavisionofthedesiredprocess,establishingalistofrequiredprocessimprovementactions,andproducingaplantoaccomplishtherequiredactions[3].

2.2.3Installprocess

InthispartofthecyclepresentedinFigure3theinfrastructureforsupportingtheenact-mentoftheprocessisestablished,andtheinstallationoftheprocesstoprojectsisplanned.

Processinfrastructureprovidesoperationalsupportfortheprocessactivitiesandmanage-mentconsistingoftheorganisationalandmanagerialrolesandresponsibilitiesaswellastechnicalfacilities[3].Infrastructure-relatedactivitiesinthisphaseincludeassigningstaff,andtrainingtheintendedprocessperformersinthenewprocessandinthesupport-ingmethodsandtools[6].Installingtheprocesstoaprojectrequirescarefulplanningandpossiblytailoringoftheprocessfromthemoregeneralprocessdeﬁnitions.Refer-ringtotheprocesscycleinFigure2,thedevelopmentactivitiesinthepreviousphasearemainlylocatedinsectorA,whereastheinstallingactivitiesareperformedbytheprocessmanagersinsectorBofthecycle.TheﬁfthstepinHumphrey’ssixstepcycleisaboutimplementingtheprocessimprovementplan[3],whichispartlyrealisedinthepreviousphaseofthehelicalcycleandpartlyinthisphase.

2.2.4Monitorprocessuse

Thispartofthehelicalcycleconcentratesonmonitoringtheenactmentoftheprocess.Somebasicusageissuestomonitorarewhethertheprocessisunderstoodandfollowed,andwhatproblemsariseduringitsuse[6].Also,itshouldbeensuredthatthemeasure-mentsspeciﬁedintheprocessdeﬁnitionaretakenandthatanyvariationsoftheprocessareidentiﬁedanddocumented.Theprocessperformersshouldbeassistedinusage,andimprovementsuggestionsandotherfeedbackshouldberecorded.Thisphaseisconcep-tuallyincludedintheﬁrststepofHumphrey’ssoftwareimprovementcyclewherethecurrentstatusofthedevelopmentprocessisevaluated[3].

2.2.5SPIManagement

Asanylarge-scaleproject,SPIactivitiesrequiremanagementactivitiesforcoordinationandcontrol.Inthehelicalcyclethemanagementpartisplacedinthecenterofthemaincycletoillustratethefactthatitisneededinalltheotherphases.InthecenteroftheFigure3,thetermSPIEisusedwiththedeﬁnitionoftheactivitiesofsoftwareprocessengineeringthatarespeciﬁcallyrelatedtoSPIactivities[6].Themanagementactivitiesareexecutedconcurrentlywiththeotherphasesofthecycle.Kellneretal.[6]suggest

thateachmajorSPIEundertakingshouldbemanagedlikeaproject.Projectmanagementisalargeresearchareainitselfandisoutofthescopeofthiswork–forthoseinterestedinprojectmanagementawidearrayofliteratureisavailable.

2.2.6Processmaturityandcapability

Themainassumptionbehindthecyclicalsoftwareimprovementmodelsisthenotionthatwhilethephasesofamodelareexecutedincyclicalfashion,thesoftwareprocessgraduallyimprovesi.e.getsbetter.Asaconsequence,thesoftwareprocessissaidtobecomemoremature.Thematurityofaprocesscanbemeasured,forexample,usingoneofthereferencemodelspresentedinthenextsubchapter.Processcapabilityisanotherconceptcloselyrelatedtoprocessmaturity.Whereasprocessmaturityisacharacteristicthatisdifﬁculttomeasureobjectivelywithoutareferencemodel,processcapabilitycanbemeasuredmoreeasilyviatheresultsifaprocess.Zahran[3]deﬁnesprocesscapabilityas

Therangeofexpectedresultsthatcanbeachievedbyfollowingaprocess

Zahran[3]alsopresentsanassumptionthatthehighertheleveloftheprocessmaturityofanorganisation,thehigheritsprocesscapability.

2.3Softwareprocessimprovementandassessmentmodels

Intheprevioussubchaptergenericstepsforcyclicalsoftwareprocessimprovementwerediscussed.Inthissubchapterabriefoverviewtosomewidelyacceptedpracticalmodelsfocusingonsoftwareprocessimprovementandassessmentispresented.Anyofthemod-elswillﬁtinthemoregeneralCPIstepspresentedinFigure2.Althoughthemodelshavedifferentarchitectureandfocus,allofthemcanbeandareusedinsoftwaredevelopmentorganisationsasthebasisofdesigningandimprovingtheirsoftwareprocesses.Processimprovementmodelsfocusonhowtocarryouttheprocessofimprovingaprocess,while

processassessmentconcentratesonthedeterminationofthedegreeofmaturityofapro-cesswithrespecttoaqualitymodel[1].Sincetheassessmentofthecurrentstateofthesoftwareprocessisanintegralpartofanysoftwareprocessimprovementandthroughprocessassessmentthesoftwareprocesscanbeimproved,astrictlinecannotbedrawnbetweenthetwotypesofmodels.

2.3.1Capabilitymaturitymodel

Thecapabilitymaturitymodel(CMM)wasdevelopedbytheSoftwareEngineeringIn-stitute(SEI)basedontheworkofWattsHumphrey[3].AwidelyaccepteddeﬁnitionofCMMpresented,forexample,byZahran[3]is

CapabilityMaturityModel:Adescriptionofthestagesthroughwhichsoftwareorganizationsevolveastheydeﬁne,implement,measure,controlandimprovetheirsoftwareprocesses.

TheCMMisfocusedonprocessassessmentanditcanbeusedinanorganisationtodeterminethecapabilitiesoftheircurrentprocessandidentifythemostcriticalaspectsoftheprocessforsoftwareprocessimprovement[3].CMMwasinitiallyfocusedtowardsthesoftwareprocessbutafterthegenericnatureofthemodelwasfullydiscovered,severalvariationsofthemodelweredeveloped.CMMforsoftware(SW-CMM)isthemodelconcentratingonthesoftwareprocess.

TheCMMincludesﬁvelevelsofprocessmaturity,whichdeﬁnethescaleformeasuringanorganisation’ssoftwareprocessandtheprocess’capability[3].Eachoftheﬁvelevels,excepttheﬁrstInitialLevel,iscomposedofseveralkeyprocessareas(KPA),whichinturnconsistofkeypractisesorganisedintoﬁvesectionscalledcommonfeatures[19].TheKPAsareuniqueamongthematuritylevelsandincludethecommonareasinsoftwaredevelopment,suchasRequirementsManagement.EachoftheKPAshasitsowngoals,whichareaccomplishedthroughaddressingthecommonfeaturesoftheKPAbyfollowingthekeypractisesrelatedtothefeature.

2.3.2Softwareprocessimprovementandcapabilitydetermination

Thesoftwareprocessimprovementandcapabilitydetermination(SPICE)isaprojectlaunchedin1993toassistindevelopinganewInternationalOrganizationforStandard-ization(ISO)andInternationalElectrotechnicalCommission(IEC)standardforsoftwareprocessimprovementandassessment.ThegoalsoftheSPICEprojectweresettoaidinthestandardisationprocessindevelopingafullinternationalstandardISO/IEC15504,toconductindustrialtrialsoftheemergingstandard,andtopromotethestandardtocreatemarketawarenessinthesoftwareindustry[20].

Structurally,incontrasttoone-dimensionalCMM,theproposedISO/IEC15504containsatwo-dimensionalreferencemodelfordescribingprocessesandprocesscapabilities.Theprocessdimensionofthereferencemodeldeﬁnes40processesandgroupsthemintothreelifecycleprocessgroupingswhichcontainﬁveprocesscategories,accordingtothetypeofactivitytheyaddress.Theobjectivesofeachprocessaredescribedintermsofapurposestatement.Thereferencemodeldoesnotdeﬁnehow,orinwhatorder,theelementsoftheprocesspurposestatementsaretobeachievednorthedetailedtasksandactivitiesrelatedtotheprocesses.Theotherdimensionistheprocesscapabilitydimensionwhichischaracterizedbyaseriesofmeasurableprocessattributesthatareapplicabletoanyprocess.Thecapabilitydimensionconsistsofsixcapabilitylevelswhichprovideawayofprogressingthroughimprovementofthecapabilityofanyprocess[20].

Inadditiontothereferencemodel,theISO/IEC15504containsguidestoperforminganassessment,qualiﬁcationofassessors,andprocessimprovement.Theguideforprocessimprovementdescribeshowtodeﬁnetheinputstoandusetheresultsofanassessmentforthepurposesofprocessimprovement.Italsoincludesexamplesoftheprocessim-provementinavarietyofsituations[3].

VarkoiandMäkinen[19]presentacomparisonbetweenCMMandSPICEinsoftwareprocessassessment.Althoughnosimpleandgeneralwaywasfoundtoconcludethatcer-tainSPICEcapabilitiescorrespondtoCMMmaturitylevels,itisconcludedthatatlargethesameinformationcanbeacquiredwithbothmodelstosupportprocessimprovementpurposes.

2.3.3BOOTSTRAP

TheBOOTSTRAPmethodologyisaresultofaEuropeanCommunityprojectconsistingofthedevelopmentoftheBOOTSTRAPmodelandmethod,andindustrytrials.Al-thoughtheprojectﬁnishedin1993,themethodologyhasbeenfurtherdevelopedandmarketedbytheBOOTSTRAPinstitute.BOOTSTRAPcontainsasoftwareprocessas-sessmentmethodandprovidesalsoguidelinesfortransformingtheassessmentresultsintoanactionplanandprioritisingtheactions.Theassessmentmethodisthree-dimensionalcontainingorganisational,methodological,andtechnologicaldimensions.ThecapabilityscaleoftheassessmentmethodisbasedontheCMMsﬁve-levelmaturityscalewithsomemodiﬁcations[3].

3PROCESSREPRESENTATION

Aprocessrepresentationisadescription,depiction,likeness,orportrayalofaprocess[9].Aprocesswithoutarepresentationisdifﬁculttoperform,control,orimprove.Iftheprocessisrepresentedonlybyanimageinthemindsofthepeopleperformingtheprocess,onecanargueiftheprocessevenexists.Aprocessrepresentationcapturestheaspectsofaprocessdeﬁnitionthatarerelevanttotheaparticulartask[13],whichmaybe,forexample,improvingorenactingasoftwareprocess.Thenatureofthetaskimpliestheusersandtherequirements,whichinturnaffectthestructureandcompositionoftherepresentation.Asaconsequence,arepresentationofaprocessforprocessimprovementpurposesmaydiffernotablyfromarepresentationofthesameprocessforsomeotherpurpose.Threekeymodesofprocessrepresentations,primarilydistinguishedbyformandusage,havebeensuggested:processmodels,processtemplatesandforms,andprocessguides[9].Althoughthemodesmaysuperﬁciallydiffernotablyfromeachother,theyenjoysimilaritiesinthebasicconceptualframeworkandprocessdeﬁnition.

Inrelationtotheconceptspresentedinthepreviouschapter,processrepresentationsarecreatedandupdatedinsectorAoftheprocesscycleinFigure2,andrespectivelyintheevaluationanddevelopmentphasesofthesoftwareprocessimprovementcycleinFigure3.Also,therepresentationsmaybemodiﬁedintheinstantiationoftheprocessinsectorBoftheprocesscycle,andintheinstallationphaseofthehelicalsoftwareprocessimprovementcycle.

Intherestofthischapterasurveyintothebasicsofanysoftwareprocessrepresenta-tionismade,anddifferenttypesofrepresentationsfordifferentpurposesaredescribed.First,thecommonconceptualframeworkunderlyingasoftwareprocessrepresentationisdescribed.Second,thethreedifferentmodesofprocessrepresentationsaredescribed.Fi-nally,differentprocessmodellinglanguages(PML)andmethodologiesforimplementingtheconceptualframeworkfordifferentpurposesareinvestigated.

3.1Conceptualframework

Inthispartageneralconceptualframeworkforsoftwareprocessrepresentationsisde-scribed.Theframeworkisfocusedupontheinformationthatisneededforhumanenact-mentoftheprocessanditisdescribedinnaturallanguage–thelanguagesandmethod-ologiesforpracticalimplementationsaredescribedinthenextsubchapters.Theintentionoftheframeworkistodescribethetypesofinformationthatshouldbeinaprocessdeﬁni-tionorrepresentation.Theframeworkisoriginallypresentedin[21]andfurtherdiscussedalsoin[9].Integratingmeasurementtoaconceptualframeworkofamodelisdiscussedinmoredetailin[22].Aprocess,itsconceptualframework,andrepresentationarepre-sentedinFigure4,whichisadaptedfrom[21].Theﬁgureconsistsofthreepartsandtheirinterconnections,whicharelabeledontherightsideoftheimage.Theuppermostpartdescribestheactualprocess,whichistransformedintoamoreabstractconceptualschema,whichinturnisdescribedasarepresentationoftheoriginalprocess.Aschemacanbethoughtasanimplementationoftheconceptualframework.Next,thedifferentaspectsoftheconceptualframeworkareexplainedinmoredetail.

3.1.1Entities

Typicalconsiderationsaboutasoftwareprocessare:

1.whathappensandhowitisdone,2.whatthingsareusedandproduced,3.whodoesit,and4.whenitisdone.

ThesefourbasicquestionsarealsopresentedattheuppermostpartofFigure4wheretheyareconnectedtotheactualprocess.Fromtheﬁrstthreeofthesequestions,threeprincipalentityclassesorabstractionsinvolvedinsoftwareprocessescanbeidentiﬁed[21].

what happens and howwhen it is done

processProcess

things usedand producedbehaviourwho does itAbstraction

activitiesrelationshipsConceptualframework

artifactsagentsDescription

ProcessDefinitionDocumentProcess modelProcess

representation

Figure4:Conceptualframeworkforsoftwareprocess.

ActivitiesArtifactsAgents

whatandhowisdone

thingsusedandproduced(byactivities)whoorwhatdoesit(i.e.,performstheactivity)

TheentitiesareshownasboxesinthemidmostpartofFigure4.Eventhoughanactivitydescribesboththe“what”andthe“how”inaprocess,itisoftenconvenienttoseparatethetwoinformation.The“how”partcanbedescribedinaseparateprocedure,whichisaseparatedescriptionwithinanactivity[21].Thetoolsoftheprocesscanbeconsideredtobeapartoftheprocedurebutalsoaseparateentitycanbeusedtorepresentthemassuggested,forexample,in[1].

Thethreebasicclassesarecommonforallkindsofprocesses.Furtherclassescanbeaddedtoaschematoenableabetterﬁtforaparticularuse,forexamplebycreatingsubclassesfromtheprincipalclasses.Theagentclass,forinstance,canbesubclassedtoafunctionalagent(commonlycalledarole)andorganisationalagentclasses[9].Aprocessusuallyinvolvesmanyinstancesofeachoftheencompassedentityclasses,whichcomprisestheactualdatainaninstantiatedprocess.

3.1.2Relationships

Entityclassesbythemselvesarenotenoughtoformacompleteprocessrepresentation.Theinteractionsbetweenandwithintheclasses,andthebehaviouroftheentitiesovertimealsohavetobedeﬁned[21].ThelinesinthemiddlepartofFigure4representtherelationshipsofthebasicentityclasses.TherelationshipswithinaclassareshowninFigure4aslineswhosebothendsareinthesameentity.Examplesofrelationshipswithinthebasicentityclassesinclude

activitymaycompriseofactivities,andagentmanagesanotheragent.

Therelationshipsamongthebasicentityclassesareshownintheﬁgureaslinesbetweentheboxes.Examplesofrelationshipsamongthebasicentityclassesinclude

activitiesareperformedbyagents,andagentsownartifacts.

Theentitieswiththeirconstraints,entityhierarchy,andtherelationshipswithinandamongtheentityclassesmakeupthestaticpartofasoftwareprocessrepresentation[23].Thus,thestaticpartgivesthedescriptionoftheelementsorentitiesthatareincludedinarepresentation.

3.1.3Behaviouralinformation

Sinceprocessesareessentiallydynamicinnature,theirbehaviourovertimeisacriticalaspect[21].Thestaticpartofaprocessdoesnottaketimeintoaccountandconsequentlyitignoresthebehaviouralaspectoftheentities.Thebehaviouralaspectofaprocessisdescribedinthedynamicpartofaprocessrepresentation,whichdescribestheorderingofthetaskstobeexecutedduringtheprocessenactment[23].Thedynamicpartprovidestheanswertothe“when”questionintheuppermostpartofFigure4,anditisalsoshowninthemidmostpartasthegrayedareaaffectingalltheentities.Examplesofthebehaviouralinformationofthedynamicpart,presentedin[21],include

when(underwhichcircumstances)anactivitycanbegin,

when(underwhichcircumstances)thestateofanartifactistobechanged,andwhen(underwhichcircumstances)alternativepathsaretobetaken.

Twodistinctiveparadigmsforthecontrolofthedynamicpartofaprocessexist:proactiveandreactive.Reactiveparadigmiseventdrivenbytriggersorexceptions,whileproactiveismainlybasedonprecedencerelationships[24].Thus,reactivecontrolisconcerned

withperformingactionsinresponsetosomeevents,whileproactivecontrolisestablishedaccordingtopre-maderules.Accordingto[23],fourkindofprecedencerelationshipscanbedistinguished:

Strongprecedences:Anactivitycanbegunonlywhenanotheractivityhasﬁnished.Weakprecedences:Anactivity(a)canbeginafteranotheractivity(b)hasbegunandb

mustﬁnishbeforeaﬁnishes.Startsynchronisingprecedences:Anactivitymustbeginbeforeanotheractivityisbe-gun.Endsynchronisingprecedences:Anactivitymustﬁnishbeforeanotheractivityﬁnishes.

Asitcanbeseen,weakprecedencescanbeconstructedbyformingacombinationofthesynchronisingprecedences.

3.2Representationtypes

Representationsofasoftwareprocessmaybedevelopedformanydifferentpurposes.Oneprocessmayhavenumerousdifferingrepresentationsfordifferentusesinansoftwaredevelopingorganisation.Processrepresentationsaredevelopedforparticularusers,userneedsandrequirements,andusagescenarios.Theirintendeduseaffectswhattheycontainandhowtheyarestructured[9].Forexample,thehelicalsoftwareimprovementmodelinFigure3referstoprocessrepresentationsormodelsinvariousphases.Somepossiblepurposesfortherepresentationslistedin[1],[9],[8],and[7]include

increaseprocessunderstandinginorganisation,facilitatecommunicationabouttheprocess,aidintrainingandeducationofpersonnel,offersupportforprocessenactment,

facilitateworktrackingbycapturinginformation,offersupportforsoftwareprocessimprovement,aidindesigninganewprocess,aidinﬁndingtaskstoautomate,

aidinprocesssimulationandoptimisation,andsupportprocessmanagement.

Inthissubchapterthreetypesofprocessrepresentationsaredescribed:processmodels,processtemplatesandforms,andprocessguides.Eachofthethreetypesmayservedifferentpurposesfordifferentusers.

3.2.1Processmodels

Aprocessmodelisarelativelydetailed,formalorsemiformalrepresentationofaprocess[9].Theprimaryusersofaprocessmodelaretheprocessengineersorqualityengineers,whoareresponsibleforprocessengineeringactivities.Processmodelcanberepresentedintextualorgraphicalformdependingontheintendeduseofthemodel.TraditionallyprocessmodelshavebeenmodeledbyusingadetailedandformalPML.Theirmainpurposehasbeenautomatingorformalisingaprocessformachineassistedenactmentandservingasabasisforprocessengineering[9].Processmodellingcanbedescrip-tiveorprescriptivedependingonwhethertheprocessismodeledasitisorasitshouldbe.Beckeretal.[7]presentanapproachfordescriptivemodellingbasedonpracticalexperiencecomprisingthefollowingeightsteps:

1.stateobjectivesandscope,

2.selectordevelopaprocessmodellingschema,3.select(asetof)processmodellinglanguages,

4.selectandtailortools,5.elicitprocessknowledge,6.createmodel,

7.analysetheprocessmodel,and8.analysetheprocess.

Firstfourofthestepsareproposedtobeexecutedonlyinfrequentlywhiletheremainingfouraresuggestedtobeexecutedeverytimeprocessmodellingisperformed.Intheﬁrststeptheobjectivesofthemodellingareuncoveredbasedontheintendeduseofthemodel.Next,themodellingschemaisdesigned–forexamplebyusingtheconceptualframeworkdescribedintheprevioussubchapter.InthethirdandfourthstepthePMLs,andthesupportingtoolsareselected.Thetoolcanbeassimpleasatext-editorordrawingtooldependingonthetypeofthePML.Thenexttwostepsconcentrateontheactualinformationgatheringandmodellingtheprocessaccordingtheselectedschemaandusingtheselectedtools.Thelasttwostepsincludethedetectionofinconsistenciesintheprocessmodelandmonitoringtheenactmentoftheprocessforqualitativeorquantitativeanalysis.Theapproachisalsoconsistentwiththemodellingmeta-processusedintheindustrialcasepresentedin[4].Prescriptivemodellingcanalsobeperformedusingsimilarstepstothoseabovewithminormodiﬁcations.Usually,inSPI,descriptivemodellingisperformedﬁrsttoworkasthebaselineforprescriptivemodelingactivities,assuggestedin[6].ManyoftheexistingPMLsarecomplex,detailed,extremelysophisticated,andstronglyorientedtowardsdetailedmodellingofprocesses.Thesemodelsareoftenﬁne-grained,comprehensivedescriptionsofwell-deﬁned,relativelystaticprocesses[9].However,re-centlyithasbeensuggestedthatthesehighlycomplex,detailed,andstaticmodelsmaynotbewhatisneededbythesoftwaredevelopers[1,9].PractitionersarenotusingthecomplexPMLsandthemodelscreatedwiththembecausethelanguagesdonotrespondtotheirneeds.Althoughthedetailedandcomplexmodellingofaprocessisjustiﬁedbythedesiretobepreciseandtoprovideenoughinformationtoenableprocessautomation,thepractitioners’mostimportantneedisoftentodescribeprocesseswiththepurposeofcommunicatingandunderstandingthem.ThismayhindertheadoptionofPMLsinprac-tisebycreatingsigniﬁcantbarriersfortheiracceptance[1].SuttonandOsterweil[25]

presentthebalancingofthetechnicalaspectsandeaseofuseofthemodellinglanguagesasakeyissuefortheadoptionofthesePMLs.

3.2.2Processtemplatesandforms

Processtemplatesandformsarestructuredtextualprocessrepresentationswherethein-formationisorganisedintopredeﬁnedslots,andoftenarrangedinahierarchicalfashion.Theyareintendedtosupportprocessengineersinorganising,recording,andreportingprocessinformation.Templatesmayserveasinterviewguidesandasavehicleforrecord-ingelicitedinformationwhengatheringinformationthroughinterviewsduringdescriptiveprocessmodelling.Templatesandformshavealsobeenusedasamediumforreportingprocessinformationinstandardformattoprocessparticipants[9].

3.2.3Processguides

Aprocessguideisintendedtodescribeaparticularprocessforthemainpurposeofsup-portinghumanenactmentofthatprocess.Asaconsequence,processparticipantsaretheprimaryintendedusersofprocessguides.Aprocessguideisastructured,work-ﬂowori-entedreferencedocumentforaparticularprocesswiththemainpurposeofsupportingprocessparticipantsincarryingouttheintendedprocess.Thus,aprocessguideshouldbeeasytounderstand,communicate,andfollow.Additionallyaprocessguidecanalsosupportprocesstraining,planning,andcertiﬁcation.Processguidesgenerallyincludebothtextandgraphics,andcontainselectedportionsofanunderlyingprocessdeﬁnitionormodel.Butasacontrasttoprocessmodels,processguidesshouldcontainmuchmoreinformationthansimplyaformattedprocessmodel[9].

Softwaredevelopmentprocessesaresocomplexentitiesthattheperformersneedtobeprovidedwithprocessknowledgetoperformtheirtasksadequately[10].Processdocu-mentationexistsinmanyorganisationsintheformofpapermanualsandprocesshand-books,whichcanbethoughtaspaperprocessguides.However,processperformersarefrequentlydissatisﬁedwiththisdocumentationandinmanycasesitissimplynotused.

Theformatandcontentofpaperprocessguidesinsoftwaredevelopingorganisationsareoftendeﬁcientandfailtoprovidethenecessaryinformationinsuitableformat[9].Evenifapaperprocessguidecontainsallnecessaryinformation,someseriouslimitationsarestillpresent.Kellneretal.[9]presentsuggestionsforthecontentandformofpaperpro-cessguidesandalsopointoutnumerousproblemsrelatedtoboththeirdevelopmentandusability.Problemswithpaperprocessguidespresentedin[9]andalsoin[10]and[11]includenavigation,searching,maintaining,customising,distributing,longupdatecycles,informationrepetition,managingdynamiccontent,andversioncontrol.Someoftheseproblemscanbesolvedbyusingformalprocessmodellinglanguagestodevelopprocessdocumentation,butstillotherproblemsandchallengesremain[9].

Electronicprocessguidesareweb-basedprocessguidesthathavebeensuggestedtosolvemanyoftheproblemsrelatedtopaperprocessguidesmentionedabove[9,10,11].Asorganisationintranetshavebecomemorecommonalsoprocessdocumentationhasbeenmadeavailablethroughaweb-browser.Kellneretal.[9]presentthreedifferentcom-monlyusedmethodsformovingfrompaperguidestoelectronicones:documentscanbemadeavailablefordownloadfromintranetintheirnativeformat,astraightforwardconversionofdocumentsfromnativeformatintosomemorebrowser-friendlylanguage(e.g.HTML[26])canbemade,oramoreextensiveconversioncanbemadesothatcross-referenceswithinadocumentareconvertedtohyperlinks.Anyofthesemethodswillaidinsolvingsomeoftheissueswithpaperguidesbyfacilitatingthemaintenanceanddistri-butionofprocessdocumentation.However,anEPGshouldprovidemoreextensiveusageofweb-basedtechnologythanjustlinkstoprocessdocumentation.Someoftherequire-mentspresentedforEPGsincludeasolidconceptualframework,adequateinformationcontent,easyandeffectivenavigation,andclearandinformativeuserinterface[9,10].AdditionalpossibilitiesforEPGsarepresentedin[11]intheformofstorageofprocessstateinformation,onlineaccesstotemplatesandmanuals,andlinkstootherresourcesonotherwebsites.AlthoughjustmakingthepaperdocumentationavailablethroughintranetdoesnotqualifyasanEPGinitself,itcanstillbeagoodstartingpointforcreatingafullscaleEPG.AnincrementalapproachfordevelopingaprocessmodeloranEPGisconsideredtobeagoodwaytointroduceprocesstechnologyintoanorganisationandthushelpthepractitionersinadjustingtotheresultingchange[1,10].Fuggetta[1]suggeststhattheprocessrepresentationmaybeincomplete,informal,andpartialatthe

beginningandifneeded,therepresentationcanbeenrichedandmademoreformalatlaterstages.

Becker-Kornstaedtetal.[11,27,28]discussamodellingtoolandanEPGgenerator,whichallowsthegenerationofEPGsdirectlyfromtheprocessmodels.TheysuggestthattheautomatedgenerationofanEPGfromthemodelsisafast,accurate,andinexpensivewaytodevelopandupdateanEPG.

3.3Processmodellinglanguagesandparadigms

Processmodellinglanguagesarelanguagesorformalismsusedtoexpresssoftwarepro-cessmodels,andconsequentlyotherprocessrepresentationsbasedonthemodels.Numer-ousdifferentPMLshavebeenintroducedtosoftwareprocessengineeringbutnosinglePMLhasacquiredadominantpositioninmodellingsoftwareprocesses[24,25,29].Var-iousreasonsfornothavingasinglestandardlanguageformodellingsoftwareprocesseshavebeenpresented,suchasexcessivestrictness,andlackingformality,modularity,hu-mancomprehensibility,andreuseabilities[24,30].Also,non-linguisticaspects,suchasorganisational,methodological,andtechnologicalsupporthavebeenpresentedasobsta-clesforthewidespreadacceptanceanduseofasinglelanguage[25].Ontheotherhanditmaybepossible,consideringthemultitudeofreasonsprocessesaremodeledfor,thatsimplynosinglePMLcanexistsatisfyingalltheneedsforaprocessrepresentation.Forexample,somePMLsaremoresuitabletohigh-levelmodellingwhileothersarebetterinlow-level,ﬁne-grainedmodelling[30].ZamliandLee[29]presentﬁvecharacteristicsforPMLs:

Modellingsupport:APMLmustbeabletorepresentthebasicconceptualelementsofa

processdiscussedintheﬁrstpartofthischapter.Also,thecommunicationmech-anismsbetweenactivitiesandrolesanddifferentlevelsofabstractionshouldbe

supported.

Enactmentsupport:TwoaspectsofenactmentsupportthatmaybeaffectedbyaPML

arepresented.Enactmentsupportindistributedenvironmentisanissueconcerned

withphysicallydistributedenvironmentsandsupportacrossorganisationalborders.Enactmentsupportforincompletelyspeciﬁedprocessmodelsallowstheincremen-talconstructionofmodelsandenactmentofincompletesoftwareprocesses.Evaluationsupport:APMLshouldsupportprocessmeasurementbyprovidingrelevant

softwaremetrics.Evolutionsupport:Supportforevolvingsoftwareprocessesisdividedintotwocate-gories.Meta-processsupportisthesupportfortheprocessofdevelopingaprocessthatwasdiscussedinChapter1andvisualisedinFigure1.Thesecondcategory,processevolutionsupport,shouldenabletoapplicationofchangestotheprocess.Humandimensionsupport:Categoriesforhumandimensionsupportpresentedby[29]

includesupportforvisualnotation,userawareness,processawareness,andprocessvisualisation.Processvisualisationisdescribedasthepossibilitytohavemultipleviewsofthesameprocessfromdifferentperspectives.

IncontrasttoPMLs,whichareusedtodescribeprocessmodels,anumberofprocess-centeredsoftwareengineeringenvironments(PSEE)existthatsupportthecreationandexploitationofsoftwareprocessmodels.CommonfeaturesofferedbyPSEEsincludesupportfordeﬁnition,modiﬁcation,analysis,andenactmentofprocessmodels.InthissubchapterabriefdescriptionofsomeofmorecommonPMLsandmodellingparadigmsispresented.SincenumberofsurveyshavebeenpublishedpresentingandcomparingPMLs[29],onlyabriefdescriptionisgivenwiththefocusonthelanguagesandapproachesthathavebeenusedinpractiseformodellingsoftwareprocesses.

3.3.1Multi-ViewProcessmodelingLanguage

Multi-ViewProcessmodelingLanguage(MVP-L)isalanguagedevelopedforbuild-ingdescriptivemodelsoflarge,real-worldprocessesandtheiruseforunderstanding,analysing,guiding,andimprovingsoftwaredevelopmentprojects.MVP-Lwasprimarilydesignedformodellingin-the-large(i.e.highlevel)tosupportprocessunderstanding.Eventhoughthelanguageisrule-basedandtextual,somegraphicaltoolsforviewingthe

modelsalsoexist[30].ThemodelsintheintegratedmodellingandEPGcreationtool,presentedin[11,28],arebasedonanextendedMVP-L.

3.3.2AdaProcess-ProgrammingLanguageandJIL

TheAdaProcess-ProgrammingLanguage(APPL/A)isbasedontheAdaprogramminglanguagewithextensionstoprocessmodelling.Thus,itisatextualmodellinglanguageandmodellingtheprocesseswithAPPL/Aisinfactprocessprogramming.JILisafor-mallydeﬁned,executableprocessprogramminglanguage,whichcanbethoughasasuc-cessortotheAPPL/A[29].ThemaingoalsforthedesignofJILincludedsemanticrich-ness,easeofuse,andsupportforvisualisation.JILoffersavarietyofsemanticattributesandprocesscontrolmechanismsandisbasedontheAdaprogramminglanguage[25].

3.3.3IntegrationDeﬁnitionlanguage0

IntegrationDEFinitionlanguage0(IDEF0)isbasedontheStructuredAnalysisandDe-signTechnique(SADT).IDEF0includesagraphicalmodellinglanguageandamethodol-ogyfordevelopingmodels.IDEF0isacoherentandsimplelanguagedesignedtoenhancecommunicationbetweenanalysts,developers,andusers.Inadditiontothemodellinglan-guage,IDEF0alsoincludesamethodologyprescribingproceduresandtechniquesfordevelopingandinterpretingmodels[31].AlthoughthegraphicalnotationusedinIDEF0lacksthepossibilitytoexpresssomeofthebehaviouralaspectsofaprocess,textcanattachedtothemodelstocompensatetheseshortcomings.

3.3.4UniﬁedModelingLanguage

TheObjectManagementGroups(OMG)UniﬁedModelingLanguage(UML)isagraphi-callanguageoriginallydesignedforvisualising,specifying,constructing,anddocument-ingtheartifactsofasoftware-intensivesystemusinganobject-orientedapproach[32].However,theuseofUMLinprocessmodellinghasalsobeeninvestigated[24,29,33,34],

andtheOMGhasalsoreleasedaninitialsubmissionofaUniﬁedProcessModel(UPM)[35]whichcontainsamodelusedtodescribesoftwaredevelopmentorrelatedprocessesusingUML.TheUMLconstitutesofseveraldifferentdiagrammaticnotationswhichareproposedtobeusedfordifferentpurposesinsystemdesign.Formodellingthesoftwareprocessthemostsuitablenotationshavetobeselected.WhiletheadequacyofthevariousUMLstaticdiagramsformodellingthestaticpartofsoftwareprocesseshasbeencon-ﬁrmed,modellingthedynamicpartofprocesseswithUMLhasbeenquestioned[24,33].Asaconsequence,someextensionstotheUMLnotationforprocessmodellinghavebeensuggested[23].TheUMLiswidelyusedinsoftwareengineeringintheindustryandalsoactivelystudiedinacademia[24].

3.3.5Process-orientedModellizationandEnactionofsoftwareDevelopmentsProcess-orientedModellizationandEnactionofsoftwareDevelopments(PROMENADE)isanapproachforsupportingsoftwareprocessmodellingbuildingontheUMLnotation.Inadditiontopresentingthenotationstouseinmodelling,PROMENADEalsopresentsaconceptualschemafordescribingasoftwareprocess.Thepresentedschemacanbede-scribedwithintheconceptualframeworkdiscussedearlierinthischapter.PROMENADEusesstandardstaticUMLdiagramstodescribethestaticpartofaprocessconsistingoftheentitiesandrelationships.Thedynamicpartisexpressedwithatextualnotationsup-portingbothproactiveandreactivecontrols,asinJIL[23].

3.3.6TheUniﬁedProcess

TheUniﬁedProcess(UP)isarepresentationofasoftwaredevelopmentprocesswiththemaingoalofguidingthedevelopersinimplementinganddeployingsystems[36].TheUniﬁedProcessifheavilybasedontheUMLanditgivesguidelineshowandwheretousethedifferentnotationsofthelanguageinsoftwaredevelopment.TheUPisfocusedonthelifecycleofasoftwaresystemwithaniterativeandincrementalapproachwhereeachiterationovertimeconsistingofspeciﬁcphasesincrementallyaddstothesystem.Ineachiterationvariousmodelsofthesystemarebuiltthatareusedandupdatedinsubsequent

iterations.Thus,inadditiontotheguidelineshowtousetheUMLnotationsinsoftwaredevelopment,theUPprovidesasoftwarelifecyclemodelconsistingofpredeﬁnedphases,suchasrequirements,analysis,design,andimplementation.

Inasense,theUPcanbethoughttobeaprocessguideofageneralsoftwareprocessthatcanbetailoredtomeettheneedsofaspeciﬁcorganisation.However,theUPdoesnotseemtohaveaconceptuallysolidprocessmodelbehindit.RecentlyeffortshavebeenmadetoformalisethemodelbehindUPbyformallyexplainingtheentitiesandbe-haviouralaspectsbehindit[36].Onemotivationfortheseeffortsistoenablethecheckingtheconsistencyofthevariousmodelsofthesystem[36].

4THEEPGENVIRONMENT

InthischapteranenvironmentforprocessmodellingandautomaticEPGcreationisde-scribed.Also,theusageoftheenvironmentinmodellingandcreatingEPGinstancesoftheprocessesofatelecommunicationssoftwarecompanyisinvestigated.Thisservesasatypicalexamplecaseofmodellingtheprocessesofamodernsoftwaredevelopingorganisation.

First,theconceptualschemaonwhichtheprocessmodelsarebasedonisdiscussed.TheschemaisbuiltontheconceptualframeworkpresentedinChapter3.Next,thepro-cessmodellingactivitiesintheenvironmentformodellingtheprocessesofthesoftwarecompanyarepresented.Theactivitiesfollowtheguidelinespresentedintheprocessmod-ellingsubsectioninChapter3.Third,thecreationofanEPGfromtheprocessmodelintheenvironmentisdescribed.Finally,asummaryofthearchitectureoftheenvironmentisgiven.

4.1Conceptualschema

InthissubchaptertheconceptualschemausedintheprocessmodellingintheEPGen-vironmentisdiscussed.Theschemafollowstheconceptualframeworkdescribedin[21]and[9].ThenotationusedinsomeofthefollowingﬁguresisUMLstaticstructuraldi-agram(SSD)notation.SSDsarealsooftencalled“classdiagrams”buttheterm“staticstructuraldiagram”isusedinthisworksinceitdescribesthenatureofthediagramsinthisworkmoreaccurately.Thenotationispresentedindetailin[32].

4.1.1Entities

ThestructureoftheentitiesusedintheenvironmentandinmodellingtheprocessesforthesoftwarecompanyisdescribedinFigure5.Theﬁgureishorizontallydividedintothreeparts:

Element

Entity

Schema level

ArtifactAgentActivityResource

Organisational

unitProductdevelopment

Organisational

subunit

Testing

Process definition

level

Type

Testingengineer

InstancePerson

Process instance

level

Figure5:Entitystructure.

SchemalevelThesearetheentityclassesthatareimplementedinthecon-ceptualschemaitselfandthusareindependentofthedeﬁnedprocesses.

Processdeﬁnitionlevel

Thisisapartofaprocessdeﬁnitioncreatedandupdatedbytheprocessengineersandmayvarydependingofthedeﬁnedprocess.

Thislevelcontainstheentitiesassignedbytheprocessman-agersattheinstanceleveloftheprocessdeﬁnitions.

Instancelevel

IntheuppermostpartthebasicentitiesoftheschemaarepresentedaccordingtotheframeworkdescribedinChapter3.Themiddlepartgivesamoredetaileddescriptionoftheentities,whichwereusedintheexamplecaseprocessdeﬁnitions.Asshownundertheartifactbasicentityclass,theclasseswerefurthersubclassedaccordingtotheorgan-isationalstructureofthesoftwarecompany.Anexampleofthesubclassingispresentedbelowtheagentbasicentityclass,whereexamplesoftheorganisationalunits,agenttype,andinstanceareshown.Thelowestpartoftheﬁgureshowstheinstancelevelwheretheprocessinstancesareenactedbyspeciﬁcprocessperformers.ApracticalexampleoftheentitystructureisalsopresentedinAppendix1.

4.1.2Relationships

ThebasicrelationshipsbetweenthebasicentityclassesareshowninFigure6withSSDnotation.Theﬁgureisincompleteinthesensethatitonlypresentsthemostimportantrelationshipsbetweenthebasicentityclassesatahighlevel.Inpractise,amorecomplexstructureisneededtodescribetherelationshipsinadatabase.

4.1.3Behaviour

Theschemasupportsseveraldifferentwaystodescribeprocessbehaviour.Reactive,event-drivencontroloftheprocessisfullysupportedwhileproactivecontrolissupported

contain

Resource

*use*

Agent

own

perform

Activity*use*Artifact

*produce**

containFigure6:Basicrelationshipsinthemodel.

withsomelimitations.Strongprecedencesofactivitiesarefullysupported,whereasweakandsynchronisingprecedencesarenotsupportedwithatomicactivities.Theeffectsofthislimitationcanbenotablylessenedbyreﬁningtheactivitiestoanappropriatedetaillevelbycreatingsubactivitiesandusingreactivecontrol,asdescribedinthefollowingsubchapterfocusingonmodellinglanguages.Also,artifactandactivitystatesaresup-portedintheenvironment.

4.2Processmodelling

Inthissubchapterthephasesofthesoftwareprocessmodellingactivitiesintheenviron-mentandinthesoftwarecompanyaredescribed.Althoughthephasesarepresentedinthecontextofanexamplecase,theyaredescribedinagenericwaysothattheyillustratethemodellingintheenvironment.Thewholedescriptivemodellingapproachisbasedontheeight-stepapproachpresentedbyBeckeretal.[7].Theﬁrstfourstepsareexecutedonlyonce,whilethesubsequentphasesmaybeexecutedalsoduringfurtherSPIactivities.

4.2.1Modellingobjectivesandscope

ThemainobjectiveforthemodellingwastocreateasuitablemodelfromwhereEPGscouldbeeasilycreated.ThemostimportantgoalsfortheEPGscreatedfromthemodelwere

helpcommunicationaboutandincreaseunderstandingoftheprocesses,offersupportfortheprocessperformers,andaidinprocessimprovement.

TheEPGsweremeantfortheuseofallthepersonnelintheorganisation.Softwareengineers,astheperformersofthesoftwareprocess,andqualitypersonnelresponsibleforprocessimprovementwerenaturaltargetusergroupsoftheEPGs.Alsootherpersonnelgroupsinthecompanyshouldbeawareatthesoftwareprocessatahighleveltobeabletocommunicatewithotherpersonnelandbetterunderstandthesoftwarethatwasproduced.Finally,althoughthesoftwareprocesswastheﬁrsttargetofthemodellingactivities,alsootherprocessesintheorganisationcouldbemodeledatalaterstageintheenvironmenttoformanorganisation-wideprocessguide.Asaconsequence,understandabilityandtheeaseofuseweresetastheprimerequirementsfortheEPGs.Consequently,theprimerequirementfortheunderlyingprocessmodelwastoenablethecreationofEPGsfulﬁllingtheserequirements.

4.2.2Conceptualschema

Theconceptualschemaoftheprocessmodelwaspresentedintheprevioussubchapter.AsproposedbyBeckeretal.[7],theobjectivesofthemodelinﬂuencedthedevelopmentoftheschema.TheprimegoalsandrequirementsofthemodelandEPGsincludedcom-municationandunderstandability,andconsequentlytheschemawasdesignedassimpleaspossibletofulﬁltheneedsoftheusersandtheorganisation.

4.2.3Modellinglanguages

Asuitablelanguageorlanguageshadtobeselectedforthemodellingtask.TofulﬁltherequirementssettothemodelandEPGs,thelanguage(s)shouldbegraphicalandread-ablebyallpersonnelwithoutextensivetraining.Modelsconcentratingmainlyonbetterunderstandingoftheprocessshouldbedescribedwithgraphicalrepresentation,andpre-cisionshouldnotbeoveremphasisedinmodelsusedforprocessimprovementpurposeseither[7].Introducingacompletelynewandcomplexlanguagetotheorganisationwasoutofthequestion,sincetheunderstandabilityoftheprocesseswasaprimerequirementandtheoverheadoftrainingwastobeminimised.Itwasacknowledgedthattheselectionofareadable,graphicallanguagecouldmeanmoreinformalprocessdescriptions.Sinceautomatingorsimulatingtheprocesseswasnotanissueandtransitionstowardsmoreunderstandablerepresentationsaresuggestedbyresearchers[1,9],thiswasnotconsid-eredamajorproblem.Also,presentingtheEPGsandtheunderlyingprocessmodelwithdifferentsetsoflanguageswasconsidered,buttheoverheadcausedbyusingseverallan-guagesfordifferentpurposes,probablecomplexityofthesystem,andlackofsupportingtoolsweresomeofthereasonsforchoosingthesamelanguage(s)forbothmodellingandpresentingtheEPGs.

Table1:RepresentationofmainrelationshipsRelationshipRepresentation

Activityisperformedbyanagent

Activityproducesanartifact

Artifactcontainsartifact

Form

Resourceisusedbyagent

Commentconnectedtoactivity

SubclassesOutgoingdashedlineActivityatswimlane

TwodifferentUMLnotationswereselectedformodellingandEPGpurposes.ThemainreasonsforselectingUMLnotationswastheirfamiliarity,readability,andexpressive-ness.ThestaticpartoftheprocessesweredecidedtobemodeledwithUMLSSDs,andthedynamicpartwithUMLactivitydiagrams(AD)whichhavebeenfoundtobethe

mostsuitableUMLnotationsformodellingthebehaviourofprocesses[33].WhereasthesuitabilityofSSDsformodellingthestaticpartofprocesseshasbeenfoundadequate,the

suitabilityofADsformodellingthedynamicparthasbeenquestioned[24,33].ThelackofmechanismstoexpressproactivecontrolandactivitypropertieshavebeenpresentedasthemainlimitationsofADs.Inourmodellingapproachtheﬁrstissuewascircumventedbyreﬁningtheactivitiestomoredetailedsubactivitiesandusingreactivecontrolwiththesubactivitieswherenecessary.Thelatterofthedeﬁciencieswaslessenedbyintroduc-ingtextualformsforeachentityinthemodelcontainingdetailedinformationabouttheentityinquestion.TherepresentationofthemainrelationshipsillustratedinFigure6isdescribedinTable1andpracticalexamplesofthediagramsarepresentedinAppendix1.

4.2.4Toolselection

ToolswereneededtosupportthegenerationoftheUMLdiagramsandtextualforms.Somerequirementsforthetoolsweretheeaseofuseandeffortlessupdatingexistingmod-els.ToolkitforConceptualModeling(TCM)[37],whichincludessupportfortheneededUMLdiagramsandincludesalsolimitedsyntaxchecking,wasselectedasthetooltodrawthediagrams.AdditionaladvantagesofTCMwereawell-documentedhuman-readableﬁleformat,whichwasneededforinformationextractionfromthemodels,andgoodex-portingfeaturesforotherimageformats.Therepresentationofsubactivitydiagramswasnotsupportedbythetoolandﬁle-systemdirectoryhierarchywasutiliseddescribetheserelationships.Also,versioncontrolofthediagramswasnotimplementedinTCMandexternalmethodswereused.Web-browserwasselectedasthemainuserinterfacetooltobeused,forexample,inupdatingthetextualformscontainingthedetailedentityprop-erties.Usingafamiliarinterface,suchasaweb-browser,foraccessingandupdatingtheprocessinformationsupportsthefulﬁlmentoftheobjectivesofeaseofusesetfortheprocessmodels.

4.2.5Elicitprocessknowledge

Theinitialgoalofthemodellingwastocreateadescriptivemodeland,consequently,elicitingexistingprocessknowledgewasnecessarytoacquiretheinformationtodescribetheprocess.Themainmethodsusedatthisphasewerestudyingexistingdocumentation,

observation,andinterviewinginvolvedpeople.Althoughprevioussystematiccompany-wideprocessmodellingactivitieshadnotbeenexecutedintheorganisation,processdocu-mentationexistedformanyoftheindividualprocessesinvariousforms.Wheresuitable,up-to-dateprocessdocumentationdidnotexist,moreemphasiswasputtoobservationandinterviews.

4.2.6Modelcreation

Atthisphasetheinformationgatheredintheelicitationphaseisformalisedandmod-eledbasedontheconceptualschemawiththeselectedlanguagesandtoolstoachievetheobjectiveswithinthescopeofthemodel.Assuggestedin[7],themodellingintheenvironmentshouldbeginbymodellingtheentities.Theagentsandartifactswiththeirstructuralhierarchies,presentedinthemiddlepartofFigure5,weremodeledasSSDsus-ingtheTCMmodellingtool.EachofthesubclasseswasmodeledasaseparateSSDﬁletocreateamodulartreehierarchy,whichcouldbeeasilymanagedandfurtherprocessed.ApracticalexampleofaSSDtreeispresentedinAppendix1.

Next,theactivities,artifactﬂow,andprocessbehaviourweremodeledasADswiththedrawingtool.ThewholeprocesswasnotdescribedwithasingleADbutalayeredstruc-turewascreatedwithdifferentlevelsofabstraction.Atthehighestlevelonlyasingleactivityneedstoexist(e.g.’Createsoftware’)whichcanthenbereﬁnedwithsubactiv-itiesasneeded.Thus,atree-likestructureofthesoftwareprocesswasgeneratedwheretheleavesrepresenttheatomicactionstates.Everynodeinthetree,withtheexceptionoftheatomicleafnodes,isrepresentedbyaUMLdiagramandconsequentlyasingleTCMﬁle.Thedescribedstructureishighlymaintainableenablingtheprocessengineerstoconcentrateonspeciﬁcpartsoftheprocessatachosenabstractionlevel.Theprocessescanbereﬁnedtoanappropriatelevelaccordingtothecontextandperformers,assug-gestedby[13].Thestructurealsosupportsthereuseofprocesseswithinthemodelbyallowinglinkingofnodestodifferentpartsofthetree.Incrementalmodelling,suggestedin[10,13],isalsosupportedbyallowingthemodeltobeginatahighabstractionlevel.AverysimpleexampleofanactivitystructureispresentedinFigure7andapracticalexampleofanactivity/subactivityrelationshipisshownintwoADsinAppendix1.

Createsoftware

Abstraction

level

DesignImplement

DesignmoduleDesignmodule testsCodemoduleDocumentmodule

Activity AActivity BActivity CActivity DActivity E

Figure7:Examplestructureofanactivitytree

Theactivity-subactivityrelationshipsareillustratedinFigure7withtheverticallyalignedsolidlines.Oneactivitymayhaveamaximumofoneparentnodebutanunlimitednum-berofsubactivitynodes.Thedottedlinesrepresentthelinksenablingthereuseoftheprocessesindifferentprocessesandpartsofthetree,i.e.anactivitymaybeasubactivityformultipleactivities.Forexample,intheﬁgureActivityCisacommonsubactivityofthreeactivitiesbutithasonlyoneparentDesignModuleTests–theothertwoactivitiesareonlylinkedtoActivityC.Themorehorizontallyaligneddashedlinesrepresentthebe-haviouralrelationshipsbetweenactivities.Usuallyallthesubactivitiesofagivenactivityhavebehaviouralrelationshipswitheachother,andallthebehaviouralinformationpre-sentedhigherinthetreeaffecttheactivitieslowerinthesamebranch.Activitiesthatarelinkedassubactivitiesareaffectedbythebehaviouralinformationpresentedinthebranchofthelinkingnode,i.e.oneactivitymaybeaffectedbydifferentbehaviouralinformationdependingonthebranchitisaccessedfrom.

Next,processinformationisextractedfromtheSSDsandADs,andinsertedtoadatabase.Thisinformationincludes,forexample,theentitieswiththeirstructure,artifactﬂow,ac-

tivity/subactivityrelationships,etc.TheinformationextractionisfullyautomatedandperformedbyaprogramtraversingtheSSDandADtreehierarchy,andparsingtheTCMsourceﬁles.Aftertheprocessdatabasehasbeencreated,otherinformationaboutthepro-cessentitiesmaybeinsertedintothedatabasebyﬁllingformswithaweb-browserusinganadministratorprocessguidedescribedinthenextsubchapter.Examplesofinsertedentitypropertiesincludeentitydescriptions,activityobjectivesandprocedures,andtheartifactownerrelationship.Thus,theproblemsresultingfromADsdeﬁcienciesinpre-sentingactivitypropertiesareremovedbypresentingthisinformationinseparateforms.Althoughmodellinginabottom-upfashionissuggestedasthemeansforprocessmod-ellinginaneworganisation[7],intheexamplecasethemodellingwasperformedasacombinationoftop-downandbottom-upapproaches.Whilebottom-upmodellingwasusedwhencollectingtheinformationaboutindividualprocessstepsfromtheperformersandexistingdocumentationtoformlargerentities,thetop-downapproachwasusedinthehigherpartsofthestructuraltreeinﬂuencedmainlybytheorganisationalstructureofthecompany.Intheinitialphasesomeofthemostimportantdevelopmentprocessesinthecompanyweremodeledintheenvironmentaccordingthemethodpresentedhere.Atthisstageamodelconsistingofasetofover400activities,50artifacts,and25roleswascreatedandpresentedintheSSDandADtreesdiscussedabove.ThemaximumdepthoftheADtreewasﬁvelevels.

4.2.7Modelandprocessanalysis

Theprocessmodelshouldbeanalysedtoensurethattheprocessisconsistent[7].Syntac-ticandsemanticanalysisofthemodelshouldbeconductedtoavoidinconsistenciesandresultingperformermisunderstandingandconfusion.Inthemodelcreated,theanalysiswasperformedmostlymanuallybytheprocessengineers.Althoughthedrawingtool(TCM)includedsomesyntaxcheckingfacilities,theywerenotusedextensivelybecauseoftheirlimitedcapabilities.Semanticanalysisofthemodelwasperformedmainlybytheprocessengineersandtheperformersoftheprocessvalidatingthemodeledprocesses.QualitativeandquantitativeprocessanalysisusingthemodelandtheEPGswithintheorganisationisdiscussedinthenextchapter.

4.3EPGcreation

InthissubchapterthecreationofEPGsfromtheprocessmodelisdescribed.ThemodelconsistsoftheSSDs,ADs,andadatabasecontainingprocessinformation,asdescribedintheprevioussubchapter.Thedatabasewascreatedbasedontheinformationextractedfromthediagrams,andinsertedviaforms.Thecreatedmodelisagenericmodelfromwhereinstancescanbecreatedfordifferentpurposes.Infact,aprocessguidecanbeseenasaninstanceoftheunderlyingprocessmodelcontainingtherelevantpartsofthemodeldependingontheintendeduseoftheguide.AnEPG,asanyotherinstance,canbecustomisedtoincludemodiﬁedoradditionalinformationabouttheprocess.Inthissubchapterthephasesinvolvedincreatinginstancesofthegenericmodel,forEPGorotheruse,aredescribed.

4.3.1Planninginformationcontent

Planningtheinformationcontentofthetheinstancedependingonitsintendeduseistheﬁrststepininstancecreation.Decisionsaboutpresentingthewholeprocessmodelorjustspeciﬁcpartshavetobemade.Also,anyadditionalinformationneededintheinstance,suchasnotes,externaldocumentation,andhyperlinksconnectedtospeciﬁcentities,hastobedecidedupon.Examplesofsuchinformationincludeinstancespeciﬁcguidelines,warnings,andsmalldeviationsfromthegenericprocess.Largedeviationsfromtheunderlyingprocessmodelarenotpossibleinthisframework,andamodiﬁedprocessmodelshouldbecreatedforsuchdeviations.Althoughcreatinganew,modiﬁedprocessmodelisfairlysimplebycopyingandmodifyingtheexistingmodel,thesufﬁcientgeneralityoftheexistingmodelcanbequestionedinsuchacase.Theinclusionofmetricstomeasuretheenactmentoftheprocess,neededespeciallyinSPIactivitiesasdescribedinChapter1,hasalsotobedecided.

SeveralEPGinstanceswerecreatedintheorganisation.Oneorganisation-wideguidewasdevelopedasageneralbrowsabledescriptionofalltheprocessespresentingtheprocessmodelwithoutanyadditionalinformation.Alsoproject-speciﬁcinstanceswerecreatedforprocessmodelvalidationpurposeswithadditionalinformationandmetrics.

4.3.2Customisinglayoutandmetrics

AfterthecontentoftheEPGhasbeenplanned,theformatinwhichthecontentispre-sentedhastobedesigned.Sincetheguideispresentedinhypertextformat,thelayoutdesigninvolvesdesigningsuitableHTMLtemplatesfortheinformation.ThetemplatescontainHTMLwithspeciﬁctagsdenotingtheinsertionofthedatafromthemodel.UsingHTMLenablesthepossibilitytocustomisethelookandcontentsoftheguideaccordingtothepreferencesoftheusers.Optionallycustomisingscriptscanbecreatedtoperformspeciﬁcactions,suchasfetchingacurrentversionofadocumentatthecreationtimeoftheguide.Differenttemplatesandscriptscanbespeciﬁedforeachnodeofthemodelhierarchytreeexcepttheleafnodes,whicharenotpresentedbySSDsorADs.Also,iftheneedforprocessmeasurementwasuncoveredintheinformationplanningphase,thescriptsforincludingthemetricsinthemodelarepreparediftheydonotexistalready.Inalltheinstancesthatwerebuilt,thesamelayoutwasusedsothatalltheinstanceshadasimilarlookandonlyonesetofHTMLtemplateswasneeded.Somecustomisedscriptswereusedtofetchup-to-datedocumentationtotheguidefromdifferentpartsofthecompanyintranetatguidebuildtime.Formeasurementandperformerfeedbackpurposesthreepossibilitieswerecreatedwithdifferentoptionsforprocessenactmenttimeinput.Intheorganisation-wideguideitwaspossibletoinserttextasfeedbackrelatedtoanyentityofthemodelthroughtheweb-browser.Intheproject-speciﬁcinstancestheinsertionofactivityperformancetimeatprocessenactmenttimewasaddedasanadditionalmetric.Thethirdpossibilitywasa“bare”versionwithoutanyperformerinputfeatures.ExamplesofthesimpleguidelayoutforADsandSSDsarepresentedinAppendix1andexamplesofthetextualforms,includingascreendescribingtheinsertionofactivityperformance,arepresentedinAppendix2.

4.3.3Buildingtheguide

Atthisphaseaguideisbuiltbasedtheinformationprovidedbythemodelandtheplannedinformationcontentwiththelayoutdeﬁnedinthepreviousphase.ThebuildingoftheguidefromtheTCMsourceﬁlesandprocessdatabaseisfullyautomated,onlythename

oftheguide,thelocationoftherootnodeoftheguideintheprocessmodeltreehierarchy,andinformationaboutthecustomisingandlayoutscriptsareneeded.Thus,theguidemayconsistofanysubtreeofthemodelandconcentrateonspeciﬁcprocesses.AsillustratedinFigure7,anactivitymayhavelinkstootheractivitiesintheactivitytreewhichalsohavetobefollowedtocreateacompletesubtree.Forexample,ifaprocessguidewastobecreatedaboutImplementation,ActivityCwouldbeapartofthisguidesinceitislinkedtosubactivitiesoftheimplementationnode.TheHTMLtemplateschosenatthepreviousphaseareusedtocreatethelayoutoftheguideandthescriptsusedformeasurementareincluded,ifneeded.Thegeneratedguideconsistsofthreeinterconnectedparts:

Dynamicpart:ThedynamicpartconsistsoftheADsandtheinstance-relatedinforma-tionpresentedwiththedesignedlayout.TheADitselfisanimagecreatedfromtheTCMsourceswithallentitiesparsedtoHTMLimagemaps,sothateveryen-tityon-screenisaclickablehyperlink.Theimagemappedhyperlinksareusedtodescribethestructureoftheselectedsubtreebyillustratingtheactivity/subactivitystructureandlinksinthetree.Also,thehyperlinksenabletheaccesstothedetailedpropertiesofeachentity.

Staticpart:ThestaticpartcontainstheSSDsandthecustomisedinstanceinformation

presentedwithalayoutdesignedinthepreviousphase.Asinthedynamicpart,

theSSDsarerepresentedbyimagescreatedfromTCMsources.Theentitiesarerepresentedbyclickablehyperlinkstodescribethedetailedentitypropertiesandstructureofthestaticpartofthemodel.

Textualpart:Thetextualpartcontainsthedetailedentitypropertieswithinstanceinfor-mation.Hyperlinkstootherrelevantpartsoftheguideandadditionalinformation

abouttherelationshipsoftheentitiesisalsoprovided.Examplesoftheautomati-callycreatedweb-formsincludedetailsoftheﬂowofaspeciﬁcartifact,activitiesofaspeciﬁcagent,etc.Also,thepossiblemeasurementsinsertedintheinstancearepresentedinthetextualpartoftherelatedentity.

Thebuildingofaguidecanbemanagedthroughaweb-interfacewheretheinformationneededtobuildtheinstanceisinserted.ExamplesofthescreensofthedifferentpartsofaguidearepresentedinAppendices1and2.

NavigationwithintheguideisprovidedwiththemeansdescribedinTable2.Onethingtonoticeisthatatthisstagethereisnotstraightlinksbetweenthedynamicandstaticparts–navigationbetweenthesepartsmustgothroughthetextualpart.Theimplementa-tionofthesestraightlinkshasnotbeenconsiderednecessaryduetotheothernavigationmechanisms.

Table2:EPGnavigation.

From

Activitydigrams

Textualforms

Staticstructurediagrams

Activitydiagrams

Staticstructurediagrams

Textualforms

Hyperlinks

Imagemapsandhyperlinks

Hyperlinks

How

Imagemapsandhyperlinks

4.3.4Customisinginstance

Beforetheguidewasbuilt,someofthepropertiesoftheguidewerealreadycustomisedinthelayoutdeﬁnitionphase.TheseincludedinformationwithintheHTMLtemplatesofthedynamic,static,andtextualparts,whichcouldalsobeenhancedwithscriptsexecutedatbuildphase.Also,theinclusionofmetricstomeasuretheprocesswascustomisedbeforebuildingtheguide.Atthisphasetheinformationcontainedinthetextualpart,i.e.thedetailedentityproperties,canbecustomisedwithaweb-interfacecreatedatthebuildtime.Thisinformationcaninclude,forexample,guidelinesorproceduresrelatedtoaentityinthisspeciﬁcinstanceoftheprocessmodel.

4.3.5Administratorguide

Theadministratorguideisaspecialversionofthemodelthatcanbebuiltsimilarlytoaregularprocessinstance.Theguideallowsthemodiﬁcationoftheinformationstoredintheprocessdatabasebyprovidingaweb-interfacetothedatabase.Onlytheentitypropertiescanbemodiﬁedthroughtheadministratorguide–modifyingthebehaviour

orrelationshipsoftheentitiesisnotnecessarysincetheinformationisextracteddirectlyfromtheSSDsandADs.Modiﬁcationsmadewiththeadministratorguidearerelatedtotheprocessmodelandthusaffectalltheinstancesbasedonthemodel.Theadministratorguideisaneasyandfastwaytoinsertandupdatethedetailedprocessinformationinthedatabase.ExamplesofthescreensofanadministratorguideareshowninAppendix3.Thescreensoftheadministratorguidearesimilartothescreensofaregularinstancewiththeexceptionthatmostoftheﬁeldsareeditable.

4.4Summaryoftheenvironmentarchitecture

InthissubchapterasummaryoftheenvironmentcombiningtheprocessmodellingandEPGcreationispresented.Also,aviewtotheunderlyingtechnicalarchitectureoftheen-vironmentisgiven.ThesummaryoftheenvironmentisgivenintheformofadescriptionofthestepsperformedintheEPGcreationintheexamplecase:

1.settingobjectivesandscope,2.designingconceptualschema,3.selectionoflanguagesandtools,4.processinformationelicitation,5.modelcreation,

(a)drawingormodifyingtheSSDsandADswithTCM,(b)buildingaprocessdatabasefromtheTCMsourceﬁles,(c)buildinganadministratorguidefromtheTCMsourceﬁles,

(d)insertinggeneralprocessinformationintothedatabasewiththeadministrator

guideweb-interface,6.EPGcreation,

(a)planninginformationcontent,

(b)customisingguidelayoutandmetrics,

(c)buildingtheEPGfromtheTCMsourceﬁlesandprocessdatabase,and(d)customisingtheEPGdetailswiththeweb-interface.

Theﬁrstthreestepswereexecutedonlyduringthecreationoftheenvironmentandneednottobeexecutedinthefutureunlesschangestotheschemaareneeded.Thefollowingtwostepsmaybeexecutedwhenchangestothemodelareneeded,andthelaststepwheneveraninstanceofthemodelhastobecreated.Smallchangestothemodelandalltheinstancesbasedonitcanbemadewiththeadministratorguideatanytime,whilelargerchangesrequirebuildingthewholemodelanew.

ThearchitectureoftheenvironmentisillustratedinFigure8wherethepeople,tools,andtheunderlyingarchitectureoftheenvironmentareshowninterconnectedwitharrowsrep-resentingtheinformationﬂow.ThearchitecturecanbecomparedtotheprocesscyclepresentedinFigure2toillustratehowthedifferentpartsofthearchitecturecorrespondtothesectionsoftheprocesscycle.ThethreesectorsA,B,andCinthecyclearealsopre-sentedwiththreeverticalsectionsinFigure8withtheirrespectiveperformingrolesandtools.Theinformationﬂowspresentedinthecenteroftheprocesscycle–feedback,pro-cessdescriptions,andinstantiatedprocess–arepresentedinthearchitectureinformationﬂows.

Althoughprocessfeedbackisshownasﬂowingstraightfromaroletoanother,theEPGitselfcanbeusedasthemeansfortheperformersgivingprocessfeedbacktotheprocessmanagers,asdescribedinthesubsectionconcentratingoncustomisingtheEPGlayout.Inthiscasetheprocessfeedbackisstoredintheprocessinstancedatabase.

User

Userinterface

Tools

Database

Process engineer

Process managerProcess performer

feedbackfeedbackTCMWWW−WWW−WWW−browserbrowserbrowserCreateCreatemodelAUpdatemodelinstanceBPerforminstanceCBuildAdministratorBuildenvironmentguideenvironmentEPGinstantiatedprocessModelprocessdatabasedescriptionsInstance databaseFigure8:EPGenvironmentarchitecture.

5EPGSUPPORTFORPROCESSIMPROVEMENTANDENACTMENT

InthischaptertheusageoftheEPGscreatedintheenvironmentdescribedinpreviouschapterisinvestigatedinatelecommunicationssoftwarecompany.Theusageisexam-inedfromtheviewpointsoftheobjectivessettotheEPGsintheprocessmodellingpart,namelythesupportforprocessperformersandthesupportforSPIactivities.Theobjec-tivewastoexplorehowtheEPGsandtheenvironmentcouldsupporttheexistingSPIandprocessperformanceactivitiesintheexamplecompany.Thestructureofthechapterfol-lowsthestructureoftheprocessimprovementmodelpresentedinFigure3asanexampleofthegenericstepsusedinCPI.ThepossibleusesoftheenvironmentandtheEPGsintheindividualstepsofthecyclearediscussedinthecontextofthetargetorganisation.

5.1Evaluateprocess

Inthisphasethemainobjectivesareunderstandingthesoftwareprocess,evaluatingtheprocessusingqualitativeandquantitativeinformation,andﬁndprocessimprovementop-portunities[6].Therecommendedmeansforunderstandingtheprocessistocreateadescriptivemodel[6].Inthecompanyapreviousprocessmodelexisted,whichwascon-sideredtobeoutdatedandtoorigidforthecurrentneedsofthecompany.Althoughdescriptionshadbeendevelopedformostindividualpartsofthesoftwareprocess,therewasaneedforamoreholisticviewoftheprocessesinthecompany.Theindividualprocessesweredocumentedwithsemiformaltextualformsorgraphicalnotationsandastandardformallanguagetodescribeprocessesdidnotexist.

ThesoftwareprocesshadbeenevaluatedthroughexternalSPICEassessmentsandsmallerscaleinternalassessmentsandtheresultingqualitativeinformationhadbeenusedforevaluatingthecurrentstateoftheprocessandplanningfurtherprocessimprovement.IncomparisonwithotherFinnishsoftwarecompaniestheresultsoftheassessmentsofthetargetcompanywerewellaboveaverage.Alsosomequantitativeinformationforprocessanalysishadbeenavailable,suchasdefectcounts,buttheneedformoreprojectspe-58

ciﬁcquantitativedataforprocessanalysiswasacknowledged.Whiletheprocessassess-mentswerethemainsourceforprocessimprovementopportunities,alsootherimportantsources,suchasprocessperformers,customers,andmanagement,wereusedtoidentifypossibletargetsforimprovement.

IncreasingprocessunderstandinginthecompanywasoneofthemainobjectivesoftheEPGscreatedintheenvironment.Especiallytheprocessengineersdesigningandim-provingtheprocessesrequirethroughunderstandingabouttheindividualprocessesandthesoftwareprocessasawhole.Theadministratorguidecontainingthewholeprocesstreeandtheunderlyingmodelprovidesaholisticviewtotheprocessesofthecompanyataneededlevelofdetail.Inasense,antheEPGenvironmentprovidedthegluetobindtheindividualprocessestogetherandtodescribetheirinterconnections.Whiletheexistingprocessdocumentationwasconvertedtoacommonnotation,alsotheoriginaldocumentswereattachedtoappropriateplacesintheprocessframework.Thus,theadministratorguideandotherprocessinstancesworkalsoasacentrallocationfromwhereallprocessdocumentationinthecompanycanbeaccessedandmaintained.Theprocessengineerscanaccessandupdatespeciﬁcpartsofthesoftwareprocessandalltheirrelateddocu-mentationbybrowsingtheadministratorguide.Oncetheunderlyingdescriptivemodeloftheprocesswascreatedandkeptup-to-date,separatemodellingphasesarenotneededinsubsequentSPIcycles[6].

ThedesignoftheEPGenvironmentallowstheinsertionofmeasurementsatanygivenactivities,artifacts,orrolesforspeciﬁcprocessinstances.Asanexample,theperfor-manceinformationofanactivityinaprojectwasdescribedinthepreviouschapterandillustratedinAppendix2.ProjectspeciﬁcEPGinstancesoftheprocessmodelwiththeneededmetricscanbecreatedandpublishedinthecompanyintranetasatooltogatherinformationaboutindividualprocessesorprojects.MeasurementssubmittedinanEPGthroughaweb-browserareinsertedtotheinstancedatabase,fromwheretheycanbefetchedforfurtheranalysis.Thus,theEPGinstancesprovidethemeansforacquiringquantitativeinformationaboutprocesses,whichispresentedasthepreferredbasisforprocessevaluation[6].

Aprocessrepresentationdoesnotsuggestanyprocessimprovementopportunitiesinit-self,butanEPGcanbeusedasavehicleforgatheringprocessimprovementideasfrom

performersormanagement.TheideassubmittedthroughanEPGinstanceinanyprojectareattachedtoaspeciﬁcprocessorentityandstoredtoadatabase.ThisenablestheEPGtofunctionasarepositoryforprocessimprovementproposals,whichispresentedasausefulsourceofideasforSPI[6].

5.2Developprocess

Thedevelopprocessphaseincludessettingthegoals,planning,andexecutingofthepro-cessdevelopment[6].ThegoalsettingorprocessdevelopmentplanningarenotdirectlyaffectedbytheEPGenvironment.Althoughtheavailabilityofalargeramountofquan-titativeinformationfromprocessesmayenablethesettingofmorespeciﬁcgoalsandconstraintsforprocessdevelopment,thecurrentproceduresusedinplanningprocessde-velopmentinthecompanyarenotaffected.Existing,formalPALtohelpinidentifyingandunderstandingreusableprocessassetswasnotavailable,andthemainsourcesforprocessalternativesinthecompanywerethevariousexistingdocumentation,processperformers,andliteratureasalsosuggestedin[6].Theprocessalternativeswereeval-uatedmainlybasedonqualitativeinformationfromassessingtheprocess,andasinglestandardmethodfordescribingthechosenprocessdidnotexist.Usuallytheprocesswasdocumentedwithatextualdocumentandsemiformaldiagrams,suchasﬂowcharts.TheEPGenvironmentsupportsprocessreuseindifferentprocessesandinstancesthroughthelinkingofdifferentpartsoftheprocesstreeasdescribedinthepreviouschapter.Thisallowsthereuseofprovenprocessesorsubprocessesinprocessdevelopment,andfacilitatesthesearchforalternativesinexistingprocesses.Theprocessengineersmaybrowsetheprocessmodelthroughtheadministratorguideinsearchingsuitablecandidatesforprocessreuse.Also,ifthefoundalternativeshavebeenusedinapreviousproject,quantitativeinformationmaybeavailabletoaidintheirevaluation.TheprocessesaredescribedwiththeUMLnotationsandformsusingthetoolspresentedinthepreviouschapter,whichtheprocessengineershavetobefamiliarwith.Additionalandexistingdocumentationinanyformatcanbeattachedwithhyperlinkstoanypartoftheprocessmodel.

Verifying,validating,andpossibleprototypingtheprocessarealsotasksbelongingtothisphase[6].Sincetheprocessmodelisdescribedinamoreformalmannerthantheprocessesinthecompanybefore,moreattentionhastobepaidtotheveriﬁcationoftheprocessestokeepthemodelconsistent.Thisrequiressyntacticalandsemanticalanalysisoftheindividualprocessesandthemodelasawholebytheprocessengineers.EPGinstancescanbecreatedtosupportandprovidefeedbackchannelsfortheusualreviewsandpossibleprototypingofprocessesduringvalidationphase.

ThenextstepinthespiralmodelpresentedbyKellneretal.[6]isdocumentingandpackagingtheprocessmaterialtoanappropriateformdependingonthesubsequentuseoftheprocess.IntheEPGenvironmentthiswouldmeantheinstantiationandcustomisingofanEPGinstancetosatisfyneedsofitsplanneduse.

5.3Installprocess

Atthisphasetheprocessdevelopedinthepreviousstepsisintroducedtotheorganisationbyestablishingthesupportinginfrastructureandperformingdetailedprojectplanningfortheprojectswheretheprocessistobeinstalled[6].Staffandotherresourcesforsupport-ingtheprocessperformanceinprojectshavetobeassignedregardlessofthetoolsandprocessmodelsused.TheadvantageoftheEPGenvironmentmaypresentinthisphaseisinthetrainingofthestaffforthenewprocess.Instancesoftheprocesseswithcommonlookandfeelcanbecreatedfortrainingpurposes,thusprovidingavehicleforprocesstrainingthattheperformerstobetrainedarefamiliarwith.Theprocessdescriptionsinthecompanyhadpreviouslybeentrainedwithdifferingnotationsandtools,andtherewasnotasinglestandardwayforpresentingtheprocessestoperformers.Naturally,thenotationsusedintheEPGhavetobetrainedinthecompanytopeopleunfamiliarwithUML,butsincealltheprocessesarepresentedwiththesamenotationsthetrainingcouldbeorganisedwithreasonablysmalleffort.

Projectspeciﬁcplanningforprocessusemayinvolvetailoringtheprocesstothespeciﬁcprojectneeds,whichcanbedonebyprocessinstancecustomising.EPGinstancescanbecreatedforprojectsandcustomisedaccordingtheneedsoftheproject.

5.4Performanceandmonitoring

SincetheEPGenvironmentwastoprovidesupportforbothSPIandprocessperform-ers,thissubchapterisdividedintotwopartsrespectively.First,thesupportforprocessperformersisdiscussedandafterwardsthesupportforSPIbymonitoringtheuseoftheprocessisinvestigated.

5.4.1Processperformance

ThemainmotivationforEPGshasbeenthesupportforprocessperformersandtheiruseforthispurposehasbeendiscussed[6,9,10].InthissubchaptertheEPGsupportforprocessperformersisdiscussedinthecontextofthedescribedEPGenvironmentandthetargetcompany.Asmentionedearlier,thecompanyhadexistingprocessdocumentationalbeitinvariousformatsandlocationsinthecompanyintranet.Existingemployeeswereconsideredtohaveagoodunderstandingaboutthepartsofthesoftwareprocessdirectlyaffectingthem,andtheprocessdocumentationwasrarelyusedasareference.Thedocu-mentationwasmainlyusedwhentheprocessesneededtobecommunicatedandchangeswereneeded.However,theneedforincreasingtheunderstandingoftheinterconnectionsoftheindividualprocessesandthesoftwareprocessasawholewasacknowledged.Es-peciallynewemployeesneededprocessdocumentationthatcouldbeeasilyaccessedandunderstood.Also,tailoredprojectspeciﬁcprocessdocumentationwasuncommonandconsequentlyprocesseventinformation,asmentionedin[9],wasnotcaptured.TheEPGenvironmentprovidesaneasilynavigable,centralisedlocationforprocessdoc-umentationthatisaccessibleforperformersoftheprocessthroughaweb-browser.Theprocessesaredescribedwithacommonnotation,eventhoughdocumentationinotherformatsandnotationscanalsobeattached.Duetothetree-likestructureofthedescrip-tion,theprocessescanbeviewedatanindividualoratahigherlevelprovidingaviewtothesurroundingorconnectedprocessesofanygivenprocess.Thisenablestheprocessperformerstohaveabroaderlookofthesoftwareprocess.TheEPGscanbeusedincom-municatingandvisualisingchangestotheprocesseswithacommonnotation.Additionalinformation,suchaslinkstotemplatesandotherinternalorexternaldocumentation,can

beincludedintheguidesespeciallytohelpnewemployeesinfamiliarisingthemselveswiththecompany’ssoftwareprocess.Thecreationofprocessinstancesenablesthepro-cessperformerstotracktheirworkandstoreprocessinformationbyinsertingdata.

5.4.2Monitorprocessuse

ThisphaseispartoftheSPIEfocusedonmonitoringtheactualuseoftheprocess[6],describedalsointheprevioussubchapter.Basicissuestomonitorinprocessperformanceincludeprocessunderstanding,adherencetotheprocessdeﬁnition,problemsduringexe-cution,measurementrecording,andrecordingprocessvariations.Additionally,improve-mentsuggestionsandfeedbackshouldbecollected,andassistanceforprocessperformersandmanagersshouldbeofferedthroughoutthisstageoftheprocess[6].

Generalprocessunderstandinginthecompanyhadbeenmeasuredbyinternalassess-mentsconcentratingonsoftwareprocess.ThemethodusedwasFinnishKYKYmodel,whichisaself-assessmentmethodbasedontheISO9001,CMM,andSPICEdevelopedforfastevaluationofprocesses.Theresultsoftheassessmentsindicatedthatthecom-panyratedamongthetopcompaniesinFinlandinunderstandingtheprocess-orientedwayofwork.Monitoringadherencetothedeﬁnedprocessesandrecordingprocessvaria-tionsinsingleprojectshadnotbeensystematicallypractised.Monitoringtherecordingofmeasurementswaspossiblethroughaweb-browserwhenspeciﬁcmeasurements,suchasdefectcounts,werecollectedtotheintranetbytheprocessperformers.Acquiringfeed-backabouttheprocessfromtheperformersandprocessmanagerswasaccomplishedwithtraditionalwaysofcommunication,withoutanyspeciﬁcmethodsandtools.

TheEPGsprovideafeedbackchannelfortheprocessperformerswherethefeedbackcanbetargetedtoaspeciﬁcentityontheprocessandstoredtoadatabaseforfurtherprocessing.Forexample,problemsandimprovementsuggestionscanbeinserteddirectlyintotherelatedartifactoractivityinaprocessinstancethatisaffectedbythefeedback.Also,sincethemeasurementsareintegratedintheEPGinstancesthemselves,theycanbemonitoredrealtimebyextractinginformationfromtheinstancedatabase.Notonlytheinsertionofmeasurementscanbetrackedbutalsothestateoftheprocessitselfcanbemonitoredwithinthepossibilitiesofferedbythespeciﬁedmeasurements.Inspecting

keyactivityperformancetimes,forexample,mayprovideusefulinformationaboutthewholeprocess.ProcessengineerscanofferassistanceforprocessperformersbyinsertingadditionaldocumentationtoanyentityintheEPGinstanceviatheadministratorguide.

6DISCUSSIONANDCONCLUSIONS

ThepurposeofthisworkwastodevelopanenvironmentforcreatingEPGsaboutthesoftwareprocesstosupportsoftwareprocessimprovementandenactment.Themotiva-tionfortheworkwasbasedontheassumptionthataproperlydesignedandimplementedEPGcanbeavaluabletoolinallphasesofSPIactivitiesaswellasprocessenactment.TheusabilityoftheEPGscreatedintheenvironmentforsupportingSPIwasinvesti-gatedbymodellingthesoftwareprocessofatelecommunicationssoftwarecompanyandstudyinghowthecurrentSPIeffortsandprocessperformanceinthecompanycouldbesupportedbytheEPGs.

ThemaingoalofthisworkwastodesignanddeveloptheEPGenvironmentitself.TheEPGshavenotyetbeenexperimentedwithinlarge-scalepracticalSPIorprojectactivi-ties,althoughthepossibilitiesforpracticalimplementationshavebeendiscussedwiththeprocesspersonnelinthetargetcompany.TheresultsofthesediscussionsabouttheuseoftheenvironmentandtheEPGsinsupportingSPIandprocessperformanceinthecompanywerepresentedinChapter5.Althoughthemajorityofthediscussionsabouttheenviron-mentandtheuseoftheEPGswerepromising,andthearchitecturewasfoundtoprovidesupportformanyaspectsofsoftwareprocessengineeringinthecompany,therealvalueoftheworkcanonlybeevaluatedthroughpracticalexperience.Themostusefulfeatureofferedbytheenvironmentfromtheprocessperformersviewpointwasconsideredtobetheuseoftheenvironmentasaneasilyaccessible,centralisedsourceforprocess-relatedinformation.ThemostpromisingopportunitiesofferedfortheSPIeffortsinthecompanywasthesupportforprocesstracking,measurement,andfeedback.Possibleproblemsfac-ingthepracticaluseoftheenvironmentwerethoughttobethenecessarytrainingandmotivationoftheprocessperformersandpersonnel.Eventhoughthisworkwasfocusedonthetheactualprocessmodelandtools,theyareonlysmallpartoftakingadvantageofprocesstechnology.Neglectingtheculturalandorganisationalissues,discussedforexamplein[3],willresultinineffectiveprocessuse.

Kellneretal.[9]discussEPGsforofferingguidancetoprocessparticipantsandpresentaninitialprototype.TheyproposeanumberchallengesforfutureEPGdevelopment,includingdynamiccreationoftheEPGsfromaprocessmodeldatabase,easierlayout

managing,searchableEPGs,andconﬁgurationmanagement.Intheenvironmentpre-sentedinthisworkmanyofthoseissueswereaddressed:theEPGswerecreatedfromamodeldatabase,thelayoutoftheguidescouldbemanagedwithoneHTMLtemplate,andqueriestotheunderlyingprocessdatabasecouldbeinsertedintheguides.AlthoughseveralversionsofprocessmodelsandEPGscouldexistintheenvironment,conﬁgura-tionmanagementisacomplexresearchareainitselfandcanpossiblybehandledbestbyspecialised,externaltools.InstantiationandcustomisationoftheEPGshavealsobeenpresentedaspossibleareasforfutureimprovement.Tailoredpersonalorgroupcopieswithvariouspossibilitiesforinteractivity,suchasinsertingpersonalannotationsandcol-lectingdatafromprocessparticipants,areexamplesoftheopportunitiesdiscussedforfutureEPGs[10,9].Inthiswork,theseaspectsofEPGsareapproachedbyofferingapossibilitytocreateandcustomiseprocessinstances,andtoinserttheelementsneededforinteractiondirectlyinthem.

ThecombinedprocessmodellingtoolandEPGgenerator,presentedbyBecker-Kornstaedtetal.[11,28],isanapproachcombiningthedevelopmentofprocessmodelsandEPGcreationwitharecentlyaddedsupportforprocessparticipantannotations[27].Themaingoaloftheapproachistoprovidesupportfortheprocessperformers[28],andtheuseofthearchitectureinSPIcontexthasnotbeenextensivelydiscussed.InthisworkadifferingapproachtoEPGdevelopmentandusagewastakenduetotheSPIfocus.Forexample,methodsforproject-speciﬁcEPGcreationandtheintroductionofmetricsintheinstanceswerediscussedandimplemented.However,thebasicrequirementsforEPGsofferingsupportforprocessperformersandSPIareessentiallythesame,namelyincreasingpro-cessunderstandingandimprovingcommunicationabouttheprocesswithinandbetweendifferentusergroups,althoughthedetailsofthecommunicationmaybedifferent.ThefeedbackfromtheinitialstudyinthesuitabilityofanEPGforsupportingSPIactivi-tiesinthetargetcompanywaspromising,andworkshouldcontinuewithexperimentingwiththeuseoftheEPGsinpractise.Theusabilityandpossibleadvantagesoftheenvi-ronmentandtheEPGscannotbedeterminedwithoutvalidatingthemwithactualusers.Infuture,experimentswiththeEPGsinpractiseareneededtofullyassesstheusabilityoftheenvironment.IftheenvironmentandtheEPGsprovetobeahelpfultoolinsoft-waredevelopmentcontext,themodelmaybeextendedtocoveralsootherprocessesinanorganisation,andthusevolvetowardsanorganisation-wideprocessguide.

7SUMMARY

Thequalityofsoftwarehasreceivedconsiderableattentioninthelastcoupleofdecadesbothinacademiaandindustry.Theattentionislargelybasedontheassumptionthatthequalityofthesoftwareishighlydependentonthequalityoftheprocessusedtoproduceit.Asaconsequence,thesoftwareprocessanditsimprovementhasbeenafocusofmostoftheattemptsinimprovingsoftwarequality.Unfortunately,softwareprocessesarecomplexentitiesandtheirunderstandingandperformanceisnotatrivialtask.

Inordertofullyunderstandaprocess,adescriptionoftheprocesshastoexist.Whereasasingleindividualmayunderstandandperformaprocessﬂawlesslywithoutexplicitpro-cessdescriptionotherthananimageinhismind,processesaffectingmorethanoneper-sonencounterproblems.Imagesinthemindsoftwopeopleaboutaprocesswillrarelybeexactlysame,andwhilebothofthemthinktheyareperformingthesameprocess,theyprobablyarenot.Toformacommonunderstandingandagreementofaprocess,thepro-cesshastobecommunicated.Processengineersdevelopingprocesses,processmanagersintroducingthemintotheirprojects,andprocessperformerscarryingoutthesoftwareprocessallneedadescriptionoftheprocesstoperformtheirpartandcommunicatetheprocesstootherpeople.

Softwareprocessimprovementisnoexception.Somethingthatisnotunambiguouslyunderstoodandcannotbecommunicatedisimpossibletoimprove.Thesuccessfulintro-ductionofthevarioussoftwareimprovementandassessmentparadigms,suchasSPICEorCMM,requiresexplicitlydeﬁnedanddescribedprocessesfromasoftwaredevelopingorganisation.Processimprovement,ifanything,involvesintensecommunicationbetweendifferentpartiesandthoroughunderstandingoftheprocessitself.

Mostoftheattemptsondescribingthesoftwareprocesshavebeenfocusedonhighlysophisticatedanddetailedprocessdeﬁnitionsthataredescribedwithtextual“processprogramminglanguages”orcomplexgraphicalmodels.Whiletheserepresentationsarejustiﬁedbytheneedtobepreciseandtheyarerequiredforcomplexsimulationsandau-tomation,oftentherealneedforprocessdescriptionsisprocessunderstandingandcom-munication.Notonlyarethesetraditionalprocessmodelsoftendifﬁculttounderstand

andupdatebytheprocessperformers,managers,andengineers,buttheirdevelopmentandmaintenancecanbetime-consumingandexpensive.Forthepurposesofcommuni-catingandunderstandingaprocess,themethodandmediumusedtorepresenttheprocessinformationalsoplaysanimportantrole.Traditional,paper-basedprocessdocumentationplacesnumerouslimitationsforeffectiveprocessmaintenanceandcommunication.Inthisworkanenvironmentforcreatingprocessdeﬁnitionsandrepresentationsforthepurposesofsupportingprocessimprovementandperformancewasdescribed.Themainrequirementsfortherepresentationscreatedintheenvironmentwereunderstandabilityandtheireaseofuse,withoutsacriﬁcingthenecessaryaccuracyandprecisenessofthedescription.IntheenvironmenttheprocessesaremodeledbasedonasolidconceptualschemawithatoolusinggraphicalUMLnotations.Theindividualprocessesaremod-eledinseparatediagramswithvariouslevelsofabstractiontoformtree-likestructuresofthestaticanddynamicaspectsofthesoftwareprocess.Usefulprocessinformationisextractedfromthediagramsandinsertedtoadatabaseusingautomatedscripts.Theprocessmodel,consistingofthediagramsandthedatabase,canbemodiﬁedandupdatedthroughaweb-interface.Instances,orelectronicprocessguides,oftheprocessmodelcanbecreated,customised,andpublishedusingaweb-browser.Theprocessinstancestakeadvantageofcurrentweb-technologiesbyprovidinganeffectiveandusableinterfaceforthenavigationandmodiﬁcationofinstance-relatedinformation.Also,processinstancecreationforspeciﬁcprojectsenablestheinsertionofproject-speciﬁcmeasurementsandprovidesacommunicationchannelforsupportingsoftwareprocessimprovementactivi-ties.

Theenvironmentwasusedtomodelthesoftwareprocessofatelecommunicationssoft-warecompany.Thesupportofferedbytheprocessmodelinstancesforthesoftwarepro-cessperformersandimprovementwasinvestigatedinthecompanybyexploringthepos-sibilitiesfortheiruse.IntheinitialinvestigationstheenvironmentandtheEPGinstanceswerefoundtoofferwidesupportforprocessimprovementandperformanceinthecom-pany.However,furtherexperimentswiththeenvironmentandtheinstancesareneededtoassesstheirtrueusability–aproperassessmentcannotbedonewithoutresultsandfeedbackfromrealusersinconcreteprojects.

REFERENCES

[1]FuggettaA.Softwareprocess:aroadmap.InFinkelsteinA,editor.Thefutureof

softwareengineering.ACMPress,2000.

[2]GibsonR.Softwareprocessmodeling:theory,resultsandcommentary.Proceedings

ofthe31stHawaiiInternationalConferenceonSystemSciences;1998Jan6-9;KohalaCoastHI,USA;IEEEComputerSocietyPress,1998.

[3]ZahranS.Softwareprocessimprovement.Harlow,England:Addison-Wesley,1998.[4]BandinelliS,FuggettaA,LavazzaL,LoiM,PiccoGP.Modelingandimproving

anindustrialsoftwareprocess.IEEETransactionsonSoftwareEngineering1995;

21(5):440-454.

[5]OsterweilLJ.Softwareprocessesaresoftwaretoo,revisited:aninvitedtalkonthe

mostinﬂuentialpaperofICSE9.ProceedingsoftheInternationalConferenceonSoftwareEngineering;1997May17-23;BostonMA,USA:ACMPress,1997.[6]KellnerMI,BriandL,OverJW.Amethodfordesigning,deﬁning,andevolving

softwareprocess.Proceedingsofthe4thInternationalConferenceontheSoftwareProcess;1996Dec2-6;Brighton,UK:IEEEComputerSocietyPress,1996.[7]BeckerU,HamannD,VerlageM.Descriptivemodelingofsoftwareprocesses.

Proceedingsofthe3rdConferenceonSoftwareProcessImprovement;1997Dec;Barcelona,Spain.1997.[8]HeinemannGT,BotsfordJE,CaldieraG,KaiserGE,KellnerMI,MadhavjiNH.

Emergingtechnologysupportingtheprocesscycle:theprocessreusestudyatIBM

CAS.IBMSystemsjournal1994;33(3):501-529.

[9]KellnerMI,Becker-KornstaedtU,RiddleWE,TomalJ,VerlageM.Processguides:

effectiveguidanceforprocessparticipants.Proceedingsofthe5thInternationalCon-ferenceontheSoftwareProcess;1998Jun14-17;NewJersey,USA:TheInterna-tionalSoftwareProcessAssociationPress,1998.

[10]Becker-KornstaedtU,VerlageM.TheV-Modellguide:experiencewithaweb-based

approachforprocesssupport.Proceedingsofthe9thInternationalWorkshopon

SoftwareTechnologyandEngineeringPractice;1999Aug30-Sep2;PittsburghPA,USA:IEEEComputerSocietyPress,1999.[11]Becker-Kornstaedt

U,ScottL,ZettelJ.Processengineeringwith

Spearmint/EPG.Proceedingsofthe22ndInternationalConferenceonSoftwareEngineering;2000Jun4-11;Limerick,Ireland:IEEEComputerSocietyPress,2000.

[12]Cambridgedictionariesonline[online]2001[cited2001Nov5].Availablefrom:

http://dictionary.cambridge.org/.[13]FeilerPH,HumphreyWS.Softwareprocessdevelopmentandenactment:concepts

anddeﬁnitions.Proceedingsofthe2ndInternationalConferenceontheSoftwareProcess;1993:IEEEComputerSocietyPress,1993.[14]PressmanRS.Softwareengineering:apractitioner’sapproach.4thed.Cambridge,

England:McGraw-Hill,1997.[15]DandekarA,PerryDE,VottaLG.Astudyinprocesssimpliﬁcation.Proceedingsof

the4thInternationalConferenceontheSoftwareProcess;1996Dec2-6;Brighton,UK:IEEEComputerSocietyPress,1996.[16]RossiS,MarttiinP.Adoptionofintegratedprocessandproductsupportforsoftware

engineeringinSPJyväskylä.ProceedingsoftheInternationalConferenceonSoft-wareMethodsandTools;2000Nov6-10;Wollongong,Australia:IEEEComputerSocietyPress,2000.

[17]Madhavji,NH.Theprocesscycle.Softwareengineeringjournal1991;6(5):234-242.[18]McFeeley,B.1996.IDEAL:auser’sguideforsoftwareprocessimprovement.

Technicalreport.PittsburghPA,USA:SoftwareEngineeringInstitute,Carnegie

MellonUniversity;1996Feb.ReportNo.:CMU/SEI-96-HB-001.

[19]VarkoiTK,MäkinenTK.CasestudyofCMMandSPICEcomparisoninsoftware

processassessment.ProceedingsoftheInternationalConferenceonEngineeringandTechnologyManagement;1999May3-5;SanJuan,PuertoRico:IEEE,1998.

[20]InternationalOrganizationforStandardization(ISO),InternationalElectrotechni-calCommission(IEC).ISO/IECTR15504-2:1998(E).Technicalreport.ISO/IEC;1998.

[21]ArmitageJW,KellnerMI.Aconceptualschemaforprocessdeﬁnitionsandmodels.

Proceedingsofthe3rdInternationalConferenceontheSoftwareProcess;1994:

IEEEComputerSocietyPress,1994.

[22]WebbyR,BeckerU.Towardsalogicalschemaintegratingsoftwareprocessmodel-ingandsoftwaremeasurement.ICSE97WorkshoponProcessModellingandEm-piricalStudiesofSoftwareEvolution;1997May17-23;BostonMA,USA;IEEEComputerSocietyPress,1997.

[23]FranchX,RibóJM.PROMENADE:Amodularapproachtosoftwareprocessmod-ellingandenaction.Researchreport.Barcelona,Spain:SoftwareDepartment,Tech-nicalUniversityofCatalonia;1999.ReportNo.:LSI-99-13-R.

[24]FranchX,RibóJM.Somereﬂexionsinthemodellingofsoftwareprocesses.Pro-ceedingsoftheInternationalProcessTechnologyWorkshop;1999Sep;Grenoble,France.1999.[25]SuttonSMJr.,OsterweilLJ.Thedesignofanext-generationprocesslanguage.Pro-ceedingsoftheJoint6thEuropeanSoftwareEngineeringConferenceandthe5th

ACMSIGSOFTSymposiumonthefoundationofSoftwareEngineering;1997Sep22-25;Zürich,Switzerland:Springer,1997.

[26]Worldwidewebconsortium[online]2001[cited2001Nov5].Availablefrom:

http://www.w3.org/.[27]Becker-KornstaedtU,ReinertR.Usingannotationsinanelectronicprocesshand-booktosystematicallyincorporateexperienceintoprocesses.Technicalreport.

Kaiserslautern,Germany:FraunhoferInstituteforExperimentalSoftwareEngineer-ing;2001Jun.Reportno.:041.01/E

[28]Becker-KornstaedtU,HamannD,KempkensR,RöschP,VerlageM,WebbyR,

ZettelJ.TheSpearmintapproachtoprocessdeﬁnitionandprocessguidance.Tech-nicalreport.Kaiserslautern,Germany:FraunhoferInstituteforExperimentalSoft-wareEngineering;1998Jun.Reportno.:035.98/E.

[29]ZamliKZ,LeePA.Taxonomyofprocessmodelinglanguages.Proceedingsofthe

ACS/IEEEInternationalConferenceonComputerSystemsandApplications;2001Jun25-29;Beirut,Lebanon.2001.

[30]BröckersA,LottCM,RombachHD,VerlageM.MVP-Llanguagereport(version

2).TechnicalReport265/95.Kaiserslautern,Germany:DepartmentofComputerSciences,UniversityofKaiserslautern;1995.[31]NationalInstituteofStandardsandTechnology(US).Integrationdeﬁnitionforfunc-tionmodeling(IDEF0).FederalInformationProcessingStandardsPublication183;

1993.

[32]ObjectManagementGroup.OMGUniﬁedmodelinglanguagespeciﬁcation(Version

1.3).ObjectManagementGroup;2000.[33]FranchX,RibóJM.UsingUMLformodellingthestaticpartofasoftwareprocess.

ProceedingsoftheSecondUniﬁedLanguageConference(UML’99);1999Oct;Fort

CollinsCOL,USA:LNCS1723,1999.

[34]SchaderM,KorthausA.ModelingbusinessprocessesaspartoftheBOOSTERap-proachtobusinessobject-orientedsystemdevelopmentbasedonUML.Proceedings

ofthe2ndInternationalEnterpriseDistributedObjectComputingWorkshop;1998Nov2-5;SanDiegoCA,USA;1998.

[35]ObjectManagementGroup.Softwareprocessengineeringmanagement:theuniﬁed

processmodel(UPM).Initialsubmission.OMGdocumentnumberad/2000-05-05;2000.[36]PonsC,GiandiniR,BaumG.DependencyrelationsbetweenmodelsintheUniﬁed

Process.Proceedingsofthe10thInternationalWorkshoponSoftwareSpeciﬁcation

andDesign;2000Nov5-7;SanDiegoCA,USA;IEEEComputerSocietyPress,2000.

[37]Toolkitforconceptualmodeling[online]2001[cited2001Nov5].Availablefrom:

http://wwwhome.cs.utwente.nl/~tcm.

Appendix1.Examplescreensofthedynamicandstaticpart

DynamicviewoftheactivitySystemDesign

DynamicviewoftheactivityDesignSystemModule

StaticviewoftheDesignSpeciﬁcationinImplementationArtifact

Appendix2.Examplescreensofthetextualpart

TextualviewoftheroleSoftwareEngineer

TextualviewoftheactivitiesoftheroleSoftwareEngineer

TextualviewoftheactivityWriteSpeciﬁcation

TextualviewoftheperformancesoftheactivityWriteSpeciﬁcation

TextualviewoftheﬂowoftheartifactDesignSpeciﬁcation

TextualviewoftheartifactDesignSpeciﬁcation

Appendix3.Examplescreensoftheadministratorguide

Createnewprocessinstancescreen

AdministratortextualviewoftheactivityWriteSpeciﬁcation

因篇幅问题不能全部显示，请点此查看更多更全内容

查看全文

全部栏目

Year