Applying the Value/Petri Process to ERP Software Development in China

Transcription

1 Applyng the Value/Petr Proce to ERP Software Development n Chna LGuo Huang Barry Boehm Computer Scence Department Unverty of Southern Calforna Lo Angele, CA , USA {lguohua, boehm}@ uc.edu Hao Hu Jdong Ge Jan Lü State Key Lab of Novel Software Tech. Inttute of Computer Software Nanjng Unverty, , Chna {myou, gjd,lj}@c.nju.edu.cn Cheng Qan Neuoft Co., Ltd. Neuoft Park Shenyang , Chna qc@neuoft.com ABSTRACT Commercal organzaton ncreangly need oftware procee entve to bune value, quck to apply, and capable of early analy for ubproce contency and compatblty. Th paper preent experence n applyng a lghtweght ynthe of a Value-Baed Software Qualty Achevement (VBSQA) proce and an Object-Petr-Net-baed proce model (called VBSQA- OPN) to acheve a manager-atfactory proce for oftware qualty achevement n an on-gong ERP oftware project n Chna. The reult confrmed that 1) the applcaton of valuebaed approache wa nherently better than value-neutral approache adopted by mot ERP oftware project; 2) the VBSQA-OPN model provded project manager wth a ynchronzaton and tablzaton framework for proce actvte, ucce-crtcal takeholder and ther value propoton; 3) proce vualzaton and mulaton tool gnfcantly ncreaed management vblty and controllablty for the ucce of oftware project. Categore and Subject Decrptor D.2.9 [Management]: Software proce model, Software qualty aurance (SQA), Lfe cycle General Term Management, Economc, Verfcaton, Performance. Keyword Software Qualty, Value, Cot, ROI, Object Petr Net (OPN), Software Proce Formalzaton, Software Proce Smulaton 1. INTRODUCTION Enterpre Reource Plannng (ERP) a bune management ytem that ntegrate all facet of the bune proce, ncludng plannng, manufacturng, ale, and marketng. The boomng Permon to make dgtal or hard cope of all or part of th work for peronal or claroom ue granted wthout fee provded that cope are not made or dtrbuted for proft or commercal advantage and that cope bear th notce and the full ctaton on the frt page. To copy otherwe, or republh, to pot on erver or to redtrbute to lt, requre pror pecfc permon and/or a fee. ICSE'06, May 20 28, 2006, Shangha, Chna. Copyrght 2006 ACM X/06/ $5.00. economy n Chna ha encouraged the development of ERP oftware to mprove varou bune operaton uch a nventory control, order trackng, cutomer ervce, fnance and human reource. Attracted by the potental huge proft, more and more oftware compane are jumpng nto th feld, whch lead to evere competton among ERP oluton provder. They are expected to provde contnuou value realzaton for ther uccecrtcal takeholder to urvve the competton. Thee trend drve the change n the charactertc of ERP oftware development n Chna a follow: A varety of takeholder wth dfferent value propoton are nvolved n the entre oftware development lfe cycle. Product lne are mantaned a a ba for future upgrade. Three proce pattern (deadlne-drven, product-drven and market-trend drven) are electvely appled n ther oftware development lfe cycle baed on dfferent bune cae. Dfferent oftware qualty aement crtera are et baed on dfferent bune cae by varou project ucce-crtcal takeholder. Thu dfferent oftware development actvte are adopted n dfferent proce pattern. ERP oluton provder n Chna have etablhed ther own et of oftware development proce actvte. Mot of the actvte are baed upon value-neutral approache and/or the Waterfall model, whch are dffcult to adapt to changng charactertc and often lead to project falure. 2. VALUE-BASED SOFTWARE QUALITY ACHIEVEMENT PROCESS FRAMEOWRK Value-Baed Software Qualty Achevement (VBSQA) proce framework [1] generated from the WnWn Spral Model [2] and coupled wth the theory of value-baed oftware engneerng [3]. It provde a top-level gudelne to generate the proce ntance for achevng the takeholder WnWn-balanced oftware qualty requrement baed on rk-drven concurrency. Intead of ung one-ze-ft-all metrc to meaure oftware qualty achevement, the VBSQA proce framework enable t uer to elct ucce-crtcal takeholder value propoton (.e., prortzaton, expected & dered value) wth repect to qualty (Q-) attrbute. It alo help dentfy ther value conflct on Q- attrbute through rk analy, archtecture/technology evaluaton and mletone revew. In addton, t help reolve the conflct by performng tradeoff analye to engneer the takeholder WnWn-balanced Q-attrbute requrement. Furthermore, the framework gude u to ue real earned value to 502

2 montor and control the progre toward achevng the Q-attrbute requrement through each mletone revew. The top-level tep and anchor pont takeholder commtment mletone (bolded) of the VBSQA proce framework are lted n Table 1. Table 1. Top-level tep of VBSQA proce framework 1. Identfy top-level mon objectve and tage ncludng oftware qualty (Q-) objectve Perform project cot/beneft analy Etmate project budget 2. Develop reult chan to dentfy ucce-crtcal takeholder and ther top-level value propoton Stakeholder negotate mutually atfactory (Wn-Wn) 3. qualty (and other) goal and relevant mon cenaro. Concurrently engneer top-level Q-attrbute and other 4. requrement and oluton tradeoff pace. 5. Identfy top-level Q-rk, execute rk-mtgaton pral. Develop ytem top-level degn and ntal Feablty 6. Ratonale Decrpton (FRD). Hold Lfe Cycle Objectve (LCO) Revew 7. Pa: go to 8. Fal: go to 4. Concurrently engneer detaled Q-attrbute and other 8. requrement and oluton; reolve rk. Develop ytem detaled degn and detaled Feablty 9. Ratonale Decrpton (FRD). Hold Lfe Cycle Archtecture (LCA) Revew 10. Pa: go to 11. Fal: go to 8. Contruct, tet, and deploy ytem Ue the mon cenaro and Q-attrbute requrement level a progre metrc and tet cae 11. Core Capablty Demo (CCD) Montor progre and change requet; perform correctve acton Intal Operatonal Capablty (IOC) Readne 12. Revew 3. VBSQA PROCESS EXPERIENCE ON A REAL-WORLD PROJECT CASE STUDY The cae tudy wa orgnated from a real-world project n Neuoft, one of the bgget oluton provder and oftware compane n Chna. It produce oftware to upport ERP n the feld ncludng telecommuncaton, electrc power, enterpre e- bune, ocal nurance, fnance, educaton, tax, and moble Internet. We name all of thee oftware product a ERP oftware n th paper. Baed on the above VBSQA proce framework we conducted the ntal exerce wth 2 project manager from Neuoft and 2 facltator from Nanjng Unverty. And an undergong ERP oftware project n Neuoft, whch to upgrade a Document and Image Management Sytem (DIMS) 1 from veron 6.0 to 7.0, wa ued a a cae tudy. The current 6.0 veron of the DIMS oftware developed by Neuoft had been ued n everal department of Chnee government for three year. Some 1 The DIMS project anonymou for the ake of commercal confdentalty. department were gong to change ther databae platform. At the ame tme, they mght alo add, remove or update certan attrbute n the DIMS 6.0 databae chema. In th cae, DB admntrator needed to export all the data from the old databae and mport them to the upgraded one. Wth the common requrement of the DB admntrator from varou department, Neuoft decded to upgrade the DIMS from 6.0 to 7.0 by addng a new capablty of data mgraton. The objectve of th exerce wa to talor the VBSQA proce to the ERP oftware development actvte n Chna. 3.1 The New Proce Learnng Curve Two project manager from Neuoft were gven two-week ere of tutoral on the VBSQA proce framework and the WnWn Spral model. Then we tarted to evaluate the effectvene of the tutoral. Two project manager were to utlze the VBSQA proce framework a a gudelne to generate a value-baed proce ntance baed on the current ERP oftware development actvte n order to acheve the WnWn balanced DIMS qualty requrement from varou project ucce-crtcal takeholder. They developed a proce ntance compoed of 22 ERP oftware development actvte. Durng the dcuon after the exerce, we detected 6 mplaced actvte due to the mnterpretaton of the proce tep n the VBSQA proce framework. We alo dentfed 4 mng actvte whch hould have been ncluded n the proce ntance due to the mundertandng of value-baed approach and WnWn Spral model. Th exerce and prevou experence uggeted that project manager typcally had very hort attenton pan and low tolerance for new method nce they were uually very buy. They all uggeted that we provde an eay-to-ue proce framework wth a hort learnng curve. Furthermore, project manager tended to ue the VBSQA proce a a gudelne. They expected t to be able to adapt to the change n the ERP oftware development actvte and workflow. Thu, cutomzaton of VBSQA proce framework toward pecfc oftware development, uch a ERP oftware development, would mprove t applcaton and provde conderable value for project manager and oftware compane. 3.2 Mantanng the Flexblty of the Proce The VBSQA proce framework cover all the phae and mletone n the entre oftware development lfe cycle of the WnWn Spral model. It alo nclude varou oftware development actvte to ncorporate the value-baed conderaton. On the one hand, for mot Chnee ERP oluton provder, dfferent oftware qualty aement crtera are et baed on dfferent bune cae o that dfferent actvte may be elected to meet them. Three dfferent proce pattern (deadlne-drven, product-drven and market-trend drven) are uually appled n the oftware development baed on dfferent bune cae. Deadlne-drven bune cae apple when rapdly accommodatng a few mnor product upgradng requrement from one or two department wthn an organzaton. Productdrven bune cae apple when accommodatng a requet to upgrade to the next veron due to the aggregaton of ome common upgradng requrement from varou department. In th cae, the qualty of the upgraded product the proce drver 503

3 rather than meetng a chedule. Market-drven bune cae apple when the upgrade of the product drven by the market trend or rval product, for ntance, a change from the Clent/Server archtecture to the Web-baed archtecture. In th cae, provdng uperor capablte to capture greater market hare a early a poble the key proce drver. To meet the dfferent requrement of dfferent bune cae, a flexble proce generaton platform hould be created to enable the trm and/or addton of the tep/actvte baed on the VBSQA proce framework. 3.3 Identfyng Flaw n a Proce Intance Mantanng the flexblty of the VBSQA proce framework mght ntroduce flaw durng proce ntance creaton. Whle a proce tep and/or a oftware development actvty n the proce ntance could be ncluded or excluded by project manager, the created proce ntance mght contan flaw and/or rk. For ntance, the dropped actvte mght caue the volaton of the crtcal path actvty dependence o that the precondton() of a pecfc actvty could not be atfed pror to t executon. 3.4 Tradeoff among Conflctng Qualty (Q-) Attrbute Software qualty an ntegratve concept contng of a number of attrbute dmenon uch a avalablty, ecurty, performance, evolvablty, chedule and cot. Thu, achevng oftware qualty a mult-attrbute decon problem. Each project ucce-crtcal takeholder can defne h/her expected and derable level for each Q-attrbute. The WnWn-balanced qualty requrement are the reaement and comprome of the Q-attrbute among ucce-crtcal takeholder. A reported by the project manager, there uually exted at leat one par of conflctng Q-attrbute n many ERP oftware project. In the DIMS upgrade project, Performance and Evolvablty were a par of conflctng Q-attrbute. There were everal archtecture opton to elect from. Drect copy between DB favored Performance n term of both throughput and torage pace at the cot of Evolvablty. XML-baed archtecture favored Evolvablty by accommodatng future change of DB platform and chema at the cot of Performance. Developer had to elect one feable archtecture from everal opton n order to balance the takeholder conflctng Q-attrbute requrement. If we could dentfy the conflctng Q-attrbute a early a poble n the oftware development lfe cycle, we would be able to mtgate the rk of project falure by performng tradeoff analy among conflctng Q-attrbute. Our exerce howed that the takeholder nteracton actvte (e.g., External Prototype Evaluaton, Archtecture opton external revew, Selected archtecture external revew) n the oftware development proce were more effectve n dentfyng the conflctng Q-attrbute and that the takeholder negotaton actvte were more effectve n performng tradeoff analy. 3.5 The Importance of Determnng Project Stakeholder Perpectve and Interacton Pont() Our exerce howed that not all the takeholder were requred to have the ame level (ntenty) or type of nvolvement [6] n every actvty n the oftware development proce. Thu plannng the level of nvolvement of each takeholder wa crtcal. In the mean tme, the project ucce-crtcal takeholder nteracton actvte could ether mtgate the oftware qualty rk or drve the change of takeholder value-propoton. And the cot (.e., actvty cot, potental rework cot) are alo aocated and/or reulted from uch actvte. Thu, plannng the actvte for takeholder nteracton and negotaton at dfferent phae of the oftware development lfe cycle mght reult n dfferent Return-On-Invetment (ROI). For ntance, the ROI of the External Prototype Evaluaton actvty and Archtecture Opton External Revew n LCO tage mght be dfferent than the counterpart n LCA tage. Therefore, determnng the tme of the takeholder nteracton actvte n a proce ntance wa very mportant. 4. MODELING VBSQA PROCESS USING OBJECT PETRI NETS (OPN) To tackle the problem encountered n our frt attempt at the VBSQA proce tranng and exerce, we bult a VBSQA proce mulaton tool VBSQA Proce Generator whch could be ued for ERP oftware development n Chna. Some related work on proce mulaton have been nvetgated n [4, 5].The purpoe of proce mulaton modelng are dcued n [4]. And a dcrete-tme proce mulator to upport oftware project manager n tak chedulng preented n [5]. The overall tructure of VBSQA Proce Generator hown n Fgure 1. It compoed of three component: VBSQA Proce Creator, VBSQA Proce Checker and VBSQA Proce Smulator. The mulaton reult can be utlzed a a feedback to adjut and mprove the current VBSQA proce ntance. Ther applcaton llutrated ung DIMS upgrade cae tudy n ecton 5. It am to help ndutral practtoner vualze the proce and generate an approprate and optmzed VBSQA proce ntance baed on a certan project bune cae. Fgure 1. The overall tructure of VBSQA Proce In order to buld the proce mulaton tool, frt we needed to model the VBSQA proce ung a proce language that could capture t charactertc. Furthermore, the proce language hould be prece enough to eventually upport verfcaton and drve mulaton whch could help u addre ome problem dentfed n ecton

4 4.1 Purpoe of VBSQA-OPN Proce Modelng Value-baed oftware development procee tend to be takeholder nvolved wth a great deal of concurrency and backtrackng. VBSQA proce one of thee procee wth the empha on achevng takeholder WnWn-balanced oftware qualty requrement. Thu, t uually nvolve multple takeholder wth dfferent value propoton on Q-attrbute and dfferent perpectve about the on-gong proce. Object Petr Net (OPN) [10], whch an extenon of tradtonal Petr Net, wa choen to model the VBSQA proce. Baed on the fact that the control tructure of oftware procee are mlar to thoe of programmng language, Oterwel propoed the dea of Software procee are oftware too [7]. Becaue the control tructure of Petr Net (PN) are mlar n expreon to programmng language, they can be ued to model oftware procee [8]. Aalt ha lted three reaon for ung Petr Net for proce modelng and analy: 1) formal emantc depte the graphcal nature, 2) tate-baed ntead of event-baed, 3) abundance of analy technque [9]. Furthermore, PN ha the mert of modelng concurrent proce actvte. A an extenon of tradtonal PN, OPN nhert thee mert of PN n proce modelng. In addton, OPN upport the eparaton of concern among dfferent takeholder perpectve of the proce by object orented approach. Each takeholder proce ntance can be modeled n a eparate Object Net (ON) by nhertng the actvte from the relevant proce tep n the Sytem Net (SN) (.e., the VBSQA proce framework). We took the object-orented approach n the ene that the VBSQA proce framework wa modeled a a SN whch wa ued a a proce gudelne. And each takeholder proce ntance wa modeled a an object that followed the workflow of the gudelne to perform the ERP oftware development actvte. Then the nteracton and negotaton among takeholder and the ynchronzaton between each takeholder ON and the SN could be defned later. Thu, OPN able to adapt to the change n the ERP oftware development actvte and workflow. VBSQA-OPN model provde a feable oluton to automaton or em-automaton of the VBSQA proce. Secton 4.2 provde the formal defnton of our VBSQA-OPN proce modelng. 4.2 Formal Defnton of VBSQA-OPN Proce Modelng In th ecton, we preent the formal defnton of the VBSQA- OPN. Defnton 1. Object Petr Net (OPN) A Petr net a 3-tuple PN = ( P, T, F), where P a fnte et of place, T a fnte et of tranton, P T = φ, F ( P T ) ( T P) a et of arc, repreentng the flow relaton between place and tranton. Token, repreentng the pre- and pot- condton of actvatng a pecfc tranton, flow from one place to another. In the dagram, we ue a crcle to repreent a place, ue a bar to repreent a tranton and ue a old dot to repreent a token. Pleae refer to [11] for the bac concept of Petr net. An OPN a 3-tuple OPN = ( SN, ON, ρ). Th defnton upport mult-object and t extended from the Valk defnton [10]. SN = ( P, T, W ) a Petr net, named Sytem Net, W ( P T ) ( T P). The token n SN refer to the Object Net defned below. ON S = { ON1,..., ONn} (n>1) a fnte et of Object Net n OPN, ON = ( B, E, F ) a Petr net, named Object Net. F ( B E ) ( E B ). SN and ON ynchronze va channel ( ρ ). ρ the ynchronou relaton between SN and ON, ρ T E, where E : = U { E 1 n}. To upport mult-object n VBSQA-OPN model, we extend a pecal Occurrence Rule baed on the Valk' Three Occurrence Rule [10], whch are omtted here. Defnton 2. VBSQA-OPN VBSQA OPN( SN, ON, ρ) the modelng of VBSQA proce baed upon OPN, where SN = ( P, T, W ) the VBSQA proce framework. Here, the tranton et T repreent the tep/mletone and t dvded nto two djont ubet T yn and T, where t T = T yn T t. T a et of ynchronou tranton, whch yn repreent the proce tep/mletone that are actually performed by takeholder() n ther proce ntance. T a et of tatu tranton. A tatu tranton can t only mmedately follow a ynchronou tranton n the SN. The graphcal repreentaton of the two type of tranton are hown n the legend of Fgure 2. The token n SN refer to Object Net (.e., takeholder proce ntance) and pont to the markng of Object Net. Here, SN can be ether the entre VBSQA proce framework SN or a talorng from 0 SN baed on the project 0 bune cae. Gven the et of tranton to be deleted, we can contruct the talored proce framework SN a follow. The et of tranton to be deleted are denoted a DEL. When tranton t deleted, 1) Let DEL : = { t}, 2 DEL : = DEL {the tatu tranton mmedately followng t } 3) x DEL, f, x Loop then DEL = DEL Loop. Loop denote the et of tranton whch belong to the ame cloed loop n the drected graph. 4) Delete the tranton n DEL and add the arc() from the place before DEL to the tranton followng DEL. ON S = { ON1,..., ON n} (n>1) repreent a et of proce ntance of takeholder and ON = ( B, E, F ) the proce ntance of takeholder. In ON, the tranton et E repreent the ERP oftware development actvte that hould be performed by takeholder and t nclude three 505

5 djont ubet, E, auto E, E, where yn t E = Eauto Eyn E. t E a et of the object-autonomou tranton, auto whch repreent the autonomou actvte of takeholder that can not be mapped to any gven tep/mletone n SN (.e., VBSQA proce framework ). Eyn a et of ynchronou tranton, whch can be mapped to the tep/mletone n SN (.e., VBSQA proce framework ) and ha ynchronou relaton wth SN. E a et of tatu tranton, whch can only t mmedately follow a ynchronou tranton. The graphcal repreentaton of the three type of tranton are hown n the legend of Fgure 3. The token n ON repreent the Q-attrbute (e.g., Performance, Evolvablty, Schedule, Cot, etc.) concerned by the takeholder. = T yn Eyn ρ ( Eyn : = U { Eyn 1 n}) defne the ynchronou relaton between SN and ON, that, a mappng between the VBSQA proce framework tep/mletone and ERP oftware development actvte. Guard functon are defned to et the actvaton condton() for ome tranton. In th cae, a tranton t T actvated n a markng M (denoted a M[ t > ) ff M t and the t tranton guard functon are both atfed. Contrant 1. The chronologcal order of ERP oftware development actvte n the takeholder proce ntance ON content wth the chronologcal order of VBSQA proce framework tep/mletone n the SN baed on ther mappng. For a VBSQA OPN = ( SN, ON, ρ), f there a path from tep A to B n the SN, denoted a A p B, and n the ON, there ext two ERP actvte A o and B uch o that ( A, Ao ) ρ and ( B, Bo ) ρ, then there mut ext a path from A to o B, denoted a o Ao p B. o Contrant 2. Crtcal Path Actvty Dependency. For a VBSQA OPN = ( SN, ON, ρ), f tranton A mut be completed before tranton B (.e. A p B ) n the SN, (denoted a B a A ), and tranton B o ext n ON, that, Bo E, ( B, Bo ) ρ n ON = ( B, E, F ), then A o E j,( A, Ao ) ρ n ON j = ( B j, E j, F j ) (denoted a Bo a A o ). 5. APPLYING VBSQA PROCESS GENERATOR BUILT ON VBSQA-OPN MODEL Baed on the VBSQA-OPN Modelng of the VBSQA proce, the VBSQA Proce Generator wa bult. We aked two project manager to apply th tool on the DIMS upgrade cae tudy. Secton 5.1 how how to ue the VBSQA Proce Creator to create the proce ntance for project ucce-crtcal takeholder baed on the VBSQA proce framework. Secton 5.2 llutrate how to dentfy the flaw of a proce ntance baed on defned proce contran n the VBSQA Proce Checker. Secton 5.3 preent ome mulaton reult of the ERP VBSQA proce. 5.1 VBSQA Proce Creator: Creatng an ERP VBSQA Proce Intance Mappng the ERP Software Development Actvte nto VBSQA Proce Framework To horten the VBSQA proce learnng curve and to reduce the flaw uch a the mplacement of ERP development actvte when creatng a proce ntance, we mapped the ERP oftware development actvte nto each tep/mletone n the VBSQA proce framework. Table 2 how a part of th mappng baed on the current ERP oftware development actvte. In the VBSQA-OPN model, VBSQA proce framework wa modeled a the Sytem Net (SN) and each takeholder cla proce ntance wa modeled a an Object Net (ON) nherted from the SN. Note that we only dtnguhed dfferent takeholder clae n creatng a proce ntance but not the varou role n one takeholder cla. For ntance, we aumed that IV&V team and tetng team belong to the Developer. Thu, to create a proce ntance for a takeholder, project manager jut needed to elect a pecfc actvty mapped nto the VBSQA proce tep and added t nto the plan for th takeholder. The chronologcal order of thee actvte were automatcally nherted from the SN, whch elmnated the proce flaw of mplaced actvte due to the mnterpretaton of the proce tep n the VBSQA proce framework a dcued n ecton 3.1. And new actvte whch were not mapped nto any tep/mletone could be added nto the takeholder ON a needed. Furthermore, f the ERP oftware development actvte and/or workflow are changed n the future, we wll only need to change the mappng DIMS Upgrade Cae Study: Creatng the ERP VBSQA Proce Intance In the DIMS upgrade cae tudy, we dentfed 4 takeholder clae ncludng Sytem Acqurer, DB Admntrator, Software Mantaner and Developer. Fgure 2 how a egment of the SN (.e, VBSQA proce framework). Fgure 3 llutrate the correpondng egment of the ON repreentng a proce ntance for the Developer generated from the SN. Fgure 4 llutrate the correpondng egment of the ON repreentng a proce ntance for the Sytem Acqurer. Fgure 5 how an example of the creaton of the Developer proce ntance ung VBSQA Proce Creator. When the moue curor wa reted over a partcular proce tep/mletone of the SN n the VBSQA Proce Creator a hown n Fgure 5, the applcable procedure/approach, f any, wa dplayed n a textbox. In th way, a project manager could aocate the procedure/approach to the pecfc actvty mapped to th proce tep/mletone. Smlarly, when the moue curor wa reted over a partcular actvty n the ON repreentng the takeholder proce ntance, the correpondng takeholder reponblte (e.g., the document and/or product to be delvered) were dplayed n a textbox. Therefore, by creatng dfferent proce ntance for varou takeholder, we could 506

6 eparate one takeholder reponblte from other wth repect to the actvte that he/he wa nvolved n. Table 2. Mappng the ERP oftware development actvte nto VBSQA proce framework tep/mletone VBSQA Proce Framework Step/Mletone (Sytem Net) Intate project Project cot/beneft analy SCS defne acceptable & dered value for Q-attrbute Rk analy & archtecture/technology evaluaton Identfy conflctng Q-attrbute & perform tradeoff analy SCS adjut acceptable value for Q-attrbute Sytem top-level degn and ntal Feablty Ratonale Decrpton (FRD) LCO Revew SCS refne acceptable & dered value for Q-attrbute Sytem detaled degn and detaled Feablty Ratonale Decrpton (FRD) LCA Revew ERP Software Development Actvte (Object Net) Acqure ytem upgrade requrement (Developer) Etmate ytem upgrade cot & develop DMR reult chan (Developer) Verfy ytem upgrade cot (Sytem Acqurer) Requrement elctaton meetng Groupware WnWn negotaton Internal prototype evaluaton (Developer) External prototype evaluaton Identfy conflctng Q-attrbute & perform tradeoff analy Stakeholder renegotaton Sytem top-level degn (Developer) Archtecture opton nternal revew (Developer) Archtecture opton external revew Requrement elctaton meetng Groupware WnWn negotaton Sytem detaled degn (Developer) Selected archtecture nternal revew (Developer) Selected archtecture external revew One way to valdate the proce wa to provde a proce analy capablty to verfy that crtcal path actvty dependency contrant were not volated by the proce defnton. Thee contrant were repreented a formal properte defned n the VBSQA-OPN Sytem Net (SN) and mplemented n the VBSQA Proce Checker. Some example of the actvty dependency contrant n the SN could be a follow: SCS defne acceptable & dered value for Q-attrbute mut be completed before Rk analy & archtecture/technology evaluaton Rk analy & archtecture/technology evaluaton mut be completed before Sytem top-level degn Sytem top-level degn mut be completed before LCO Revew Value-baed core capablty tetng mut be completed before CCD And they needed to be tranlated nto the prece formal defnton baed on the Contrant 2 of Defnton 2 n ecton 4.2. Core capablty mplementaton Value-baed core capablty tetng CCD Remanng feature mplementaton IOC Acceptance Revew Core capablty mplementaton (Developer) Internal core capablty tetng (Developer) Internal core capablty demo (Developer) Onte core capablty demo Complete ytem mplementaton (Developer) Onte Sytem Acceptance Revew 5.2 VBSQA Proce Checker: Identfyng the Flaw n a VBSQA Proce Intance Baed on the project bune cae, the project manager could chooe to kp ome tep n the VBSQA proce framework durng the ERP VBSQA proce ntance creaton for uccecrtcal takeholder. That, t allowed project manager to nhert a NULL actvty from each tep n the SN (.e., VBSQA proce framework). However, uch flexblty provded by the tool could be both a trength and a weakne. It mght ntroduce the flaw of mng actvte whch could caue the volaton of crtcal path actvty dependence n a proce ntance. Fgure 2. VBSQA-OPN Sytem Net (SN): the LCO phae of VBSQA proce framework 507

7 Fgure 5. VBSQA Proce Creator: VBSQA Proce Framework (Sytem Net) and the generated Developer proce ntance (Object Net) Fgure 3. VBSQA-OPN Developer Object Net (ON): the LCO phae of the Developer proce ntance generated from the SN Fgure 4. VBSQA-OPN Sytem Acqurer Object Net (ON): the LCO phae of the Sytem Acqurer proce ntance generated from the SN For ntance, the actvty Sytem top-level degn had been planned n the LCO phae of the Developer proce ntance. However, nether Internal prototype evaluaton nor External prototype evaluaton whch were mapped to the Rk analy & archtecture/technology evaluaton a hown n Table 2 wa planned n any takeholder proce ntance. After analyzng the takeholder proce ntance n ON baed on the defned crtcal path actvty dependency contrant, the VBSQA Proce Checker would dplay a warnng meage a Rk analy & archtecture/technology evaluaton mut be completed before Sytem top-level degn. 5.3 VBSQA Proce Smulator: Comparng the ROI of Synchronou Stakeholder Interacton Actvte The ynchronou takeholder nteracton actvte n the VBSQA proce were uually effectve n mtgatng the oftware qualty rk. At the ame tme, hgher actvty cot and dfferent potental rework cot were ncurred by uch actvte n dfferent phae of oftware development. Thu, performng the takeholder nteracton actvty at dfferent phae of the oftware development lfe cycle mght reult n dfferent Return-On- Invetment (ROI). However, there lacked of the quanttatve analy approache and mulaton tool to help project manager determne when to perform the ynchronou takeholder nteracton actvte durng oftware development. In th ecton, we preent the mulaton reult of dfferent ROI for varou takeholder nteracton actvte n dfferent oftware development phae. The ROI wa computed a followng: Value Cot ROI = (1) Cot 508

8 5.3.1 Value Earned: the Synchronou Stakeholder Interacton Actvty v. Developer Internal Actvty Let aume that totally m Q-attrbute were dentfed for the project. And n (n=4) oftware development phae were defned n the VBSQA proce framework (LCO, LCA, CCD and IOC). Value = m n (( 1 (1 E )) R V ) (2) = 1 j = 1 V: the total value of the project; E j (0-1): the effectvene of a pecfc proce actvty on mtgatng the rk of Q-attrbute f t performed n phae j; R (0-1): the rk of Q-attrbute to the total value of the project. In DIMS upgrade cae tudy, two project manager provded the nput for each parameter baed on ther experence and expert judgement. Total value of the project wa etmated a the contracted payment ($50,000) that Neuoft would obtan from the ytem acqurer after the project wa uccefully completed by atfyng of all ucce-crtcal takeholder Q-attrbute requrement. Totally 4 Q-attrbute and ther related operatonal cenaro were dentfed for th project a hown n Table 3. Table 3. DIMS upgrade project: Q-attrbute and ther rk to the project value (R ) Q- attrbute Performance Evolvablty j Related Scenaro Prorty R (0-1) Complete data mgraton from the old DB to the upgraded DB wthn 1 day and wthn requred torage pace Accommodate dfferent DB platform and chema n data mgraton Hgh 0.8 Medum 0.4 Schedule Hgh Cot Hgh We treated the falure of achevng a Q-attrbute requrement a the rk to the total value of the project. Table 3 lt the rk of Performance and Evolvablty to the project value, denoted a R. R the product of the rk mpact and the probablty of rk occurrence. We defned the rk mpact a the proporton of the total project value that would have been lot f that Q-attrbute rk had occurred. Thu R wa from 0 to 1. In th project, Performance wa a Hgh prorty requrement from DB admntrator and falure of achevng t would reult n 80% lo of the project value. Evolvablty wa a Medum prorty requrement from oftware mantaner and falure of achevng t would reult n 40% lo of the project value. In th cae tudy, we dd not take nto account the other two Q-attrbute (Schedule, Cot) becaue they were not the major rk to th project. Some tep n the VBSQA proce framework uch a Rk analy & archtecture/technology evaluaton, LCO Revew, LCA Revew, CCD amed to mtgate the qualty rk. A hown n Table 2, two type of ERP oftware development actvte were mapped to each of them, whch were developer nternal actvte and ynchronou takeholder nteracton actvte. The example of the former were Internal prototype evaluaton, Archtecture opton nternal revew, Selected archtecture nternal revew, Internal core capablty demo a hown n the rght column of Table 2. Thee actvte were accomplhed only by developer wthout other takeholder partcpaton. They were uually le effectve n dentfyng Q-attrbute rk. The example of the latter were External prototype evaluaton, Archtecture opton external revew, Selected archtecture external revew, Onte core capablty demo. Thee actvte were accomplhed by developer and other ucce-crtcal takeholder(). Stakeholder were able to evaluate the prototype(), revew the archtecture() or tet the core capablte together under the realtc operatonal envronment. Thu, thee actvte were uually more effectve n dentfyng Q-attrbute rk. Furthermore, thee actvte at dfferent phae of the oftware development lfe cycle alo had dfferent effectvene n dentfyng Q-attrbute rk. Table 4 how the effectvene of a pecfc proce actvty on mtgatng the rk of Q-attrbute f t wa performed n phae j, denoted a E j. Project manager provded the etmate of E j a the proporton by whch the rk of Q-attrbute would have been reduced f that proce actvty had been performed n phae j. Thu E j wa from 0 to1. Note that we treated the rk mtgaton E j n t mot general ene, whch ncorporated both the decreae of the probablty of rk occurrence and ther mpact on the project value. Table 4. DIMS upgrade project: the effectvene of developer nternal actvte v. takeholder nteracton actvte on Q-attrbute rk mtgaton (E j ) Project Phae LCO (Lfe Cycle Objectve) LCA (Lfe Cycle Archtecture) CCD (Core Capablty Demo) IOC (Intal Operatonal Capablty) Proce Actvte Archtecture opton nternal revew Archtecture opton external revew Selected archtecture nternal revew Selected archtecture external revew Internal core capablty demo Onte core capablty demo Onte ytem acceptance revew Rk Mtgaton (E j ) (0-1) Performance Evolvablt y Cot: the Synchronou Stakeholder Interacton Actvty v. Developer Internal Actvty Two type of cot, the actvty cot and the potental rework cot, were aocated wth a ynchronou takeholder nteracton actvty or a developer nternal actvty. The cot wa computed a followng: Cot = n j = 1 C aj + C r C aj : the cot of a proce actvty at phae j; C r : the potental rework cot. (3) 509

9 Actvty Cot (C aj ) The cot of the developer nternal actvty n DIMS upgrade project wa etmated a $500 by ERP oftware project manager. The ynchronou takeholder nteracton actvty uually had 2 or 3 tme hgher actvty cot, etmated a $1, Rework Cot (C r ) Whenever a Q-attrbute rk wa dentfed by a proce actvty, ome amount of rework wa needed a a remedy. Table 5 how the potental rework cot C r at 4 phae of VBSQA oftware development proce. In the bet cae, rework wa only needed for the current phae. However, ometme rework extended to the prevou phae. In the wort cae, the rework needed to be done from the begnnng of the project. The number n Table 5 how the rework cot C r from phae(s) to phae(f). The number n the dagonal of Table 5 repreent the rework cot wthn the LCO, LCA, CCD and IOC phae repectvely. For ntance, the cot of only reworkng LCA phae wa $9,000, the cot of reworkng LCA and CCD phae wa $35,000 and the cot of reworkng LCA, CCD and IOC phae wa $46,000. Note that f developer needed to rework both the LCA and CCD phae becaue a rk wa dentfed at the Onte Core Capablty Demo, the rework cot provded by project manager wa $35,000, whch wa larger than the um of the rework cot wthn LCA and CCD phae ($9,000 + $19,000). They explaned that nce developer had to change the detaled archtecture degn and to redo the Core Capablty Implementaton, they uually needed extra effort to become famlar wth the programmng technque for the new archtecture degn. Baed on the ERP project manager, developer nternal actvte uually ncurred lttle rework. Table 5. DIMS upgrade project: potental rework cot C r at dfferent phae of VBSQA oftware development proce Rework Cot Phae (F) C r ($) LCO LCA CCD IOC Phae (S) LCO 3,000 12,000 38,000 50,000 LCA 9,000 35,000 46,000 CCD 19,000 31,000 IOC 11, Smulaton Reult: ROI Aumng that the ynchronou takeholder nteracton actvty (.e., Onte Sytem Acceptance Revew) wa requred n the IOC phae, we enumerated the poble combnaton of takeholder nteracton actvte and developer nternal actvte n the frt three phae of oftware development lfe cycle (LCO, LCA and CCD). A hown n the econd column of Table 6, LCO() denote that we performed the developer nternal actvty (.e., Archtecture Opton Internal Revew) n the LCO phae. LCO() denote that we performed ynchronou takeholder nteracton actvte (.e., Archtecture Opton External Revew) n the LCO phae. The ame notaton apple for other phae. Gven the nput from two project manager, our mulaton computed two ROI for each proce actvty combnaton except the frt one a hown n Table 6. One wa for the wort-cae cenaro; the other wa for the bet-cae cenaro n term of the potental rework cot. In the wort-cae cenaro, we aumed that rework happened after each ynchronou takeholder nteracton actvty. And performng uch actvty n a certan phae could only avod the future rework extendng to th phae. For ntance, only performng the Selected Archtecture External Revew n the LCA phae (.e., LCO()\LCA()\CCD()\IOC()) would ncur the rework on both LCO and LCA and another rework on both CCD and IOC. In the bet-cae cenaro, we aumed that once we performed uch actvty n a certan phae the rework would only be needed from the begnnng of the project to th phae and t could avod all the future rework ncurred by the Q-attrbute rk afterward. Even n the wore cae cenaro, Selected Archtecture External Revew n the LCA phae wa partcularly effectve n mprovng the ROI nce all the combnaton wth th actvty (ee 3, 5, 7, 8) n Table 6 produced relatvely hgh wort-cae ROI (0.162, 0.194, 0.205, 0.215). In the bet-cae cenaro, Archtecture Opton External Revew n the LCO phae wa partcularly effectve n mprovng the ROI becaue we aumed that t avoded all the future rework ncurred by Q-attrbute rk after the LCO phae. Both reult mpled that performng ynchronou takeholder nteracton actvte n the archtectng phae of a oftware project could produce hgher return n term of oftware qualty rk mtgaton. Fgure 6 a naphot of ung VBSQA Proce Smulator to compute the ROI of a combnaton of takeholder nteracton actvte and developer nternal actvte baed on the Sytem Net (.e., VBSQA proce framework). Table 6. Comparng the ROI of varou combnaton of ynchronou takeholder nteracton actvte and developer nternal actvte ROI Proce Actvty Combnaton Wort-Cae Scenaro Bet -Cae Scenaro 1 LCO()\ LCA() \ CCD() \ IOC() LCO()\ LCA() \ CCD() \ IOC() LCO()\ LCA() \ CCD() \ IOC() LCO()\ LCA() \ CCD() \ IOC() LCO()\ LCA() \ CCD() \ IOC() LCO()\ LCA() \ CCD() \ IOC() LCO()\ LCA() \ CCD() \ IOC() LCO()\ LCA() \ CCD() \ IOC() Feedback on the ROI Smulaton Reult The reult n Table 6 enabled the project manager to rapdly ae the bet-cae and wort-cae outcome for ther rk mtgaton decon opton. Baed on the feedback from two ERP project manager, the bet-cae cenaro wa uually not applcable n th project epecally for the Performance attrbute. In the LCO Revew, developer uually could only provde the top-level ytem degn and the non-functonal prototype. Thu, the aumpton that the Archtecture Opton External Revew n the LCO phae could avod all the future rework wa too optmtc. However, n the LCA Revew, when the detaled ytem degn and the functonal prototype were avalable, the aumpton of avodng the future rework after LCA phae wa more applcable. Therefore, the real cae cenaro for Performance and Evolvablty attrbute n the DIMS upgrade project wa cloer to the wort-cae cenaro. 510

10 The experence wth the VBSQA Proce Generator alo told u proce vualzaton and mulaton tool gnfcantly ncreaed management vblty and controllablty for the ucce of oftware project. In order to buld uch tool to vualze, verfy and mulate the value-baed procee nvolved by varou takeholder, the Object Petr Net (OPN) provded a feable oluton to the value-baed proce modelng. 7. ACKNOWLEDGEMENT Th reearch funded by the Natonal Scence Foundaton n the US and by 863 Program (2004AA112090, 2005AA113160), 973 Program (2002CB312002) and NSFC ( , ) n Chna. We would lke to thank Weje Zhu, Qang Ln, Chao You and Fe Xong n the Inttute of Computer Software at Nanjng Unverty, for ther help n tool mplementaton. We would alo lke to expre pecal thank to DIMS project team n Neuoft Co., Ltd. Fgure 6. VBSQA Proce Smulator: Computng the ROI of a combnaton of takeholder nteracton actvte and developer nternal actvte n an ERP VBSQA proce A a reult of th analy, the DIMS project manager commtted to hold a Selected Archtecture External Revew at the end of the LCA phae to evaluate the performance of elected XML archtecture wth totally 3,840,000 DB record. Wth the partcpaton of DB admntrator, oftware mantaner and developer n th actvty, they dentfed the archtectural rk on the Performance of data mgraton becaue the entre memory would be conumed by totally 97 ntermedate XML fle generated. After takeholder renegotaton, the developer rearchtected the capablty a Drect Copy wth addtonal algorthm to only accommodate certan DB platform and chema. Baed on the project manager, wthout uch analy reult they would have planned the proce actvte n a valueneutral way (e.g., holdng Selected Archtecture Internal Revew at the end of the LCA phae only to ave ome actvty cot) whch would have ncreaed the chance of project falure. 6. CONCLUSIONS AND LESSONS LEARNED A we dcovered n our applcaton experence of VBSQA proce, olvng a problem n theory and n practce were very dfferent. In pte of the practcal dffculte n applyng a new proce n oftware ndutry where tradtonal procee and method domnated, the reult howed that the applcaton of value-baed approache wa nherently better than the valueneutral one that mot ERP oftware project employed n Chna. In Mcrooft Secret [12], the ablty to ynchronze and tablze multple nternal development team dentfed a a Mcrooft crtcal ucce factor. The VBSQA-OPN model provded a framework n whch the actvte, value propoton, and commtment of multple ucce-crtcal takeholder could be ynchronzed and tablzed for a wde varety of proce drver. 8. REFERENCES [1] L. Huang, A Value-Baed Proce for Achevng Software Dependablty, Proceedng of Internatonal Software Proce Workhop, May, 2005, Bejng, Chna. [2] B. Boehm, W. Hanen, Undertandng the Spral Model a a Tool for Evolutonary Acquton, CroTalk, May, [3] B. Boehm and A. Jan, An Intal Theory of VBSE n A. Aurum, S. Bffl, B. Boehm, H. Erdogmu, and P. Gruenbacher, Value-Baed Software Engneerng, Sprnger Verlag, [4] Kellner MI, Madachy RJ, Raffo DM: Software proce mulaton modelng: Why? What? How?", Journal of Sytem and Software, Vol. 46, No. 2/3, Aprl, [5] F. Padberg, A Software Proce Schedulng Smulator," Proceedng of 25th Internatonal Conference of Software Engneerng (ICSE'03), May, 2003,. [6] M. Wet, Real Proce Improvement Ung the CMM, CRC Pre, Feb. 1, [7] L. J. Oterwel, Software Procee are Software too, Proceedng of Internatonal Conference of Software Engneerng, 1987, pp [8] W. Deter and V. Gruhn, The FUNSOFT Net Approach to Software Proce Management, Internatonal Journal on Software Engneerng and Knowledge Engneerng, 1994, pp [9] W. M. P. van der Aalt, The Applcaton of Petr Net to Workflow Management, Journal of Crcut, Sytem, and Computer, 1998, pp [10] R. Valk, Petr net a token object: An ntroducton to elementary object net, Proceedng of Applcaton and Theory of Petr Net, Sprnger-Verlag, 1998, pp [11] W. Reg, Petr Net, An Introducton, Sprnger Verlag, Berln, [12] M. Cuumano and R. Selby, Mcrooft Secret, The Free Pre, October,