王尉

摘 要：以某EPC企業(yè)PLM實(shí)施及二次開(kāi)發(fā)項(xiàng)目中的軟件工程實(shí)踐為基礎(chǔ)，介紹一種裁剪的基于進(jìn)化式原型的快速原型過(guò)程，對(duì)其角色、中間產(chǎn)品、行動(dòng)和前后條件加以描述，并對(duì)該過(guò)程的風(fēng)險(xiǎn)和適用性進(jìn)行了分析。

關(guān)鍵詞：軟件工程；快速原型法；PLM

DOIDOI：10.11907/rjdk.171816

中圖分類號(hào)：TP319

文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1672-7800（2017）007-0122-03

1 PLM系統(tǒng)實(shí)施項(xiàng)目的特點(diǎn)

產(chǎn)品生命周期管理（Product Lifecycle Management，PLM）作為一項(xiàng)能夠解決產(chǎn)品生命周期范圍內(nèi)產(chǎn)品信息共享、交互與管理問(wèn)題的技術(shù)，在研發(fā)、設(shè)計(jì)、制造和工程等領(lǐng)域有著日趨廣泛的應(yīng)用。大部分企業(yè)會(huì)選擇實(shí)施成熟的商業(yè)PLM系統(tǒng)。但PLM系統(tǒng)向來(lái)無(wú)法“開(kāi)箱即用”[1]，必須結(jié)合客戶的戰(zhàn)略和業(yè)務(wù)需求，進(jìn)行二次開(kāi)發(fā)，而且產(chǎn)品數(shù)據(jù)的靈活性決定了PLM實(shí)施的技術(shù)開(kāi)發(fā)量通常顯著多于ERP等軟件的實(shí)施。因此，PLM項(xiàng)目的實(shí)施可看作由一個(gè)以實(shí)現(xiàn)PLM思想、梳理業(yè)務(wù)流程和實(shí)現(xiàn)管理提升為目標(biāo)的業(yè)務(wù)咨詢活動(dòng)，和一個(gè)以交付軟件產(chǎn)品為目的的軟件開(kāi)發(fā)活動(dòng)共同組成。

本文圍繞某EPC企業(yè)PLM實(shí)施項(xiàng)目中的軟件二次開(kāi)發(fā)過(guò)程展開(kāi)分析，項(xiàng)目中使用了一個(gè)裁剪的基于進(jìn)化式原型的快速原型過(guò)程，具有完整的生命周期。該軟件過(guò)程對(duì)PLM的實(shí)施有借鑒意義。

2 快速原型法在項(xiàng)目中的應(yīng)用

快速原型法的核心思想就是通過(guò)構(gòu)造能夠體現(xiàn)目標(biāo)系統(tǒng)主要特征的原型（Prototype），將目標(biāo)系統(tǒng)以可視化的形式展現(xiàn)給用戶，在經(jīng)過(guò)評(píng)估后對(duì)原型進(jìn)行修改，逐步求精，繼續(xù)評(píng)估、修改，直到用戶滿意為止，它是一個(gè)循環(huán)迭代的過(guò)程[2]?？焖僭头梢詰?yīng)用于需求采集，也可應(yīng)用于技術(shù)方案驗(yàn)證和整個(gè)系統(tǒng)的開(kāi)發(fā)。

參考業(yè)內(nèi)對(duì)PLM實(shí)施方法論的研究[3-4]，本文提出的PLM項(xiàng)目的軟件過(guò)程是一個(gè)裁剪的基于進(jìn)化式原型的快速原型過(guò)程。進(jìn)化原型是創(chuàng)建軟件系統(tǒng)的一種形式，它不會(huì)在構(gòu)建后被拋棄，而是通過(guò)修改和追加功能逐漸豐富，直至產(chǎn)生覆蓋用戶和系統(tǒng)需求的可運(yùn)行的系統(tǒng)。該快速原型過(guò)程經(jīng)過(guò)裁剪來(lái)適應(yīng)開(kāi)發(fā)的需要。

2.1 角色定義

以軟件工程中原型法的角色定義為基礎(chǔ)[5-6]，本軟件過(guò)程涉及9個(gè)角色，一個(gè)人可任多個(gè)角色，多個(gè)人也可共同承擔(dān)一個(gè)角色。按同樣的方式，這些角色被分為3個(gè)組。

（1）軟件工程組。負(fù)責(zé)引導(dǎo)項(xiàng)目方向，促進(jìn)配置管理，支持項(xiàng)目建議書編寫、領(lǐng)導(dǎo)文檔編寫工作及相關(guān)業(yè)務(wù)工作。組內(nèi)角色有：①項(xiàng)目經(jīng)理，負(fù)責(zé)執(zhí)行項(xiàng)目的總體監(jiān)管，確保配置管理的執(zhí)行，維護(hù)項(xiàng)目計(jì)劃，委派人員進(jìn)行需求收集，執(zhí)行項(xiàng)目實(shí)施，裁定出現(xiàn)的問(wèn)題；②技術(shù)文檔工程師，負(fù)責(zé)監(jiān)督和維護(hù)文檔，處理會(huì)議記錄和會(huì)議文檔，擔(dān)任配置管理專家，編寫保密和安全管理規(guī)定，并保證項(xiàng)目產(chǎn)出物遵循規(guī)定，如有需要，執(zhí)行項(xiàng)目實(shí)施；③需求工程師，負(fù)責(zé)領(lǐng)導(dǎo)需求收集工作，與干系人、客戶和最終用戶溝通，組織與干系人的訪談，擔(dān)任與用戶的接口人，按照策略將需求文檔化；④業(yè)務(wù)經(jīng)理，負(fù)責(zé)制定和維護(hù)業(yè)務(wù)藍(lán)圖。

（2）軟件質(zhì)保組。負(fù)責(zé)編寫對(duì)原型的測(cè)試用例和腳本，審查代碼和文檔，包括項(xiàng)目計(jì)劃、需求文檔和設(shè)計(jì)文檔。組內(nèi)角色有：①總架構(gòu)師，負(fù)責(zé)監(jiān)督系統(tǒng)的總體設(shè)計(jì)，對(duì)實(shí)施工作進(jìn)行歸類，完成資源計(jì)劃，執(zhí)行項(xiàng)目實(shí)施；②質(zhì)保工程師，負(fù)責(zé)設(shè)計(jì)測(cè)試用例，執(zhí)行測(cè)試，維護(hù)缺陷/錯(cuò)誤報(bào)告，執(zhí)行項(xiàng)目實(shí)施。

（3）軟件開(kāi)發(fā)組。負(fù)責(zé)支持用戶界面圖樣（UI）的創(chuàng)建，領(lǐng)導(dǎo)原型的開(kāi)發(fā)工作。組內(nèi)角色有：①主程序員，負(fù)責(zé)委派人員進(jìn)行實(shí)施工作，監(jiān)督缺陷的解決，執(zhí)行項(xiàng)目實(shí)施；②領(lǐng)域?qū)＜?，?fù)責(zé)熟悉和理解某些特定的領(lǐng)域，執(zhí)行項(xiàng)目實(shí)施；③用戶界面設(shè)計(jì)師，負(fù)責(zé)用戶界面圖樣（UI）設(shè)計(jì)。

2.2 軟件過(guò)程

PLM項(xiàng)目使用的快速原型法分為4個(gè)階段。第一階段是項(xiàng)目規(guī)劃階段，該階段建立業(yè)務(wù)藍(lán)圖，制定項(xiàng)目計(jì)劃，更好地理解用戶需求，建立對(duì)新軟件需求的基本認(rèn)識(shí)。第二階段是軟件設(shè)計(jì)開(kāi)發(fā)的第一輪迭代，該階段確保團(tuán)隊(duì)理解系統(tǒng)所追求的大致方向。通過(guò)一個(gè)拋棄式的用戶界面原型，向用戶演示項(xiàng)目組的意圖，該原型在項(xiàng)目中被稱為“一次原型”。第三階段是第一輪的進(jìn)化式原型，是一個(gè)可運(yùn)行的原型作為需求的一種真正具體化體現(xiàn)。用戶評(píng)價(jià)該原型并且增加和修改需求。在最后一個(gè)開(kāi)發(fā)迭代中，原型按照新的及修改后的需求演化。系統(tǒng)經(jīng)過(guò)測(cè)試后交付給用戶。

配置管理和質(zhì)量保證需要在項(xiàng)目的整個(gè)生命周期中執(zhí)行。配置管理依據(jù)配置管理計(jì)劃，由技術(shù)文檔工程師負(fù)責(zé)，并由項(xiàng)目經(jīng)理確認(rèn)。質(zhì)量保證由軟件質(zhì)保組負(fù)責(zé)，文檔和原型本身都受到質(zhì)量保證的控制。

2.2.1 項(xiàng)目規(guī)劃階段

項(xiàng)目規(guī)劃階段如圖1所示，業(yè)務(wù)經(jīng)理以初始用戶輸入為基礎(chǔ)編寫業(yè)務(wù)藍(lán)圖。使用該信息，項(xiàng)目經(jīng)理和技術(shù)文檔工程師編寫項(xiàng)目計(jì)劃，包括角色、職責(zé)、排程和項(xiàng)目描述等信息；同時(shí)，創(chuàng)建項(xiàng)目管理程序。團(tuán)隊(duì)按照創(chuàng)建的管理程序合作，管理程序以及對(duì)程序的遵守將會(huì)體現(xiàn)在產(chǎn)出的系統(tǒng)質(zhì)量上。

管理程序建立之后，一組初始的需求可以從用戶、其它軟件系統(tǒng)和項(xiàng)目團(tuán)隊(duì)獲得，以便于理解系統(tǒng)必須實(shí)現(xiàn)的功能。需求工程師負(fù)責(zé)需求收集和文檔化。該階段最后通過(guò)會(huì)議的形式進(jìn)行一次項(xiàng)目組內(nèi)審查/風(fēng)險(xiǎn)審查，分析項(xiàng)目組的工作量、方向、問(wèn)題和解決方案。

2.2.2 第一輪迭代階段（一次原型）

為促進(jìn)用戶和開(kāi)發(fā)團(tuán)隊(duì)間的理解，并提供一條更具體的溝通途徑，第一輪迭代致力于創(chuàng)建拋棄式的用戶界面原型，以確保開(kāi)發(fā)按正確的方向進(jìn)行。該原型被稱為“一次原型”。該原型強(qiáng)調(diào)快速和低成本[7]?；谝淮卧陀懻摰挠脩艚缑嬗杉夹g(shù)文檔工程師根據(jù)適當(dāng)?shù)呐渲霉芾硪?guī)則來(lái)存檔。與此同時(shí)，總架構(gòu)師開(kāi)始基于識(shí)別出的需求進(jìn)行系統(tǒng)設(shè)計(jì)。該階段活動(dòng)如圖2所示。endprint

一次原型建立起用戶和項(xiàng)目團(tuán)隊(duì)之間溝通的橋梁，這使得參與方可以討論系統(tǒng)，發(fā)現(xiàn)溝通的不足和缺失的需求。本次迭代同樣有助于確保將來(lái)的開(kāi)發(fā)沿著正確的路線進(jìn)行。在用戶與開(kāi)發(fā)者討論原型時(shí)，新的或修改的需求會(huì)被發(fā)現(xiàn)。這些需求全部被技術(shù)文檔工程師文檔化，附加在原需求文檔上。該階段最后通過(guò)會(huì)議的形式進(jìn)行一次項(xiàng)目組內(nèi)審查/風(fēng)險(xiǎn)審查，給出項(xiàng)目狀態(tài)的一個(gè)公共性的理解，除發(fā)現(xiàn)和評(píng)估風(fēng)險(xiǎn)之外，還包括創(chuàng)建風(fēng)險(xiǎn)消除策略，并判斷風(fēng)險(xiǎn)消除策略的有效性。一次原型會(huì)被存檔，不會(huì)被再次使用。

2.2.3 第二輪迭代階段

在該階段初始，需求已經(jīng)創(chuàng)建并驗(yàn)證，系統(tǒng)設(shè)計(jì)已開(kāi)始，并且用戶提供了其意見(jiàn)作為輸入，確定了最初的軟件界面和功能模式。

結(jié)合新需求及用戶意見(jiàn)，對(duì)系統(tǒng)設(shè)計(jì)作出修改，作為已存在的需求與要實(shí)現(xiàn)的原型之間的橋梁?？偧軜?gòu)師負(fù)責(zé)監(jiān)督設(shè)計(jì)的完成，主程序員及其委派的開(kāi)發(fā)人員按照系統(tǒng)設(shè)計(jì)開(kāi)始構(gòu)建系統(tǒng)，質(zhì)保工程師基于需求創(chuàng)建軟件部件和系統(tǒng)測(cè)試。接下來(lái)，執(zhí)行系統(tǒng)的編碼、調(diào)試以及測(cè)試直到滿足需求和系統(tǒng)設(shè)計(jì)。

原型完成后，將其展現(xiàn)給用戶。用戶和開(kāi)發(fā)者一起檢查創(chuàng)建的系統(tǒng)，可能發(fā)現(xiàn)新的需求，或已有需求需要變更。與之前的迭代一樣，新的或修改的需求全部被文檔化，附加在原需求文檔上。在最后階段，與上一輪迭代一樣，通過(guò)會(huì)議的形式進(jìn)行一次項(xiàng)目組內(nèi)審查/風(fēng)險(xiǎn)審查。該階段活動(dòng)如圖3所示。

2.2.4 第三輪迭代階段

如圖4所示，在該階段的開(kāi)始，一份最終需求已經(jīng)創(chuàng)建并驗(yàn)證，用戶已對(duì)形成的原型提供了反饋。

與上一輪迭代一樣，結(jié)合新需求及用戶意見(jiàn)，修改系統(tǒng)設(shè)計(jì)，開(kāi)始構(gòu)建系統(tǒng)。執(zhí)行系統(tǒng)的編碼、調(diào)試以及測(cè)試直到滿足需求和系統(tǒng)設(shè)計(jì)。

作為系統(tǒng)實(shí)施工作的結(jié)束，開(kāi)發(fā)者使用軟件質(zhì)保組創(chuàng)建的測(cè)試腳本及其它全覆蓋測(cè)試所需的測(cè)試腳本來(lái)徹底地測(cè)試系統(tǒng)，修正發(fā)現(xiàn)的缺陷或錯(cuò)誤。在系統(tǒng)通過(guò)測(cè)試之后，通過(guò)會(huì)議的形式進(jìn)行一次項(xiàng)目組內(nèi)審查/風(fēng)險(xiǎn)審查，總結(jié)完成的系統(tǒng)構(gòu)建工作，討論未解決的問(wèn)題。最終，完整的系統(tǒng)將交付給用戶，該系統(tǒng)涵蓋所需功能，并達(dá)到用戶對(duì)質(zhì)量的要求。

3 快速原型法的風(fēng)險(xiǎn)點(diǎn)

PLM項(xiàng)目中應(yīng)用快速原型模型不可避免地引入了其自身的風(fēng)險(xiǎn)[8-9]，針對(duì)本文提出的快速原型過(guò)程分析如下：

（1）人力和成本原型建立。在項(xiàng)目初期建立原型需要付出前期投入和人力成本，如果原型設(shè)計(jì)不佳導(dǎo)致受客戶牽制而在原型上反復(fù)修改，則成本更高。原型法要想體現(xiàn)出其優(yōu)勢(shì)，需要在前期盡快并且廉價(jià)地建立拋棄式原型，用最少的投資開(kāi)發(fā)那些用于回答問(wèn)題和解決需求不確定性的原型，不要努力去完善一個(gè)拋棄式原型的用戶界面。在建立原型的過(guò)程中，充分利用重用機(jī)制。

（2）原型進(jìn)化方向控制。使用進(jìn)化原型時(shí)，在軟件開(kāi)發(fā)的方向和目標(biāo)上與所有干系人都達(dá)成一致是很困難的。下一個(gè)原型的內(nèi)容也會(huì)難以決定，在管理上會(huì)形成數(shù)個(gè)版本和決策。最終，原型系統(tǒng)的完成度通常是很難評(píng)判的，原型系統(tǒng)有可能被過(guò)度進(jìn)化或過(guò)早的交付。目前，有很多方法用于解決此問(wèn)題。以控制進(jìn)化過(guò)程為目的，主要方法有：有限制的迭代周期、使用風(fēng)險(xiǎn)分析。發(fā)現(xiàn)和培養(yǎng)關(guān)鍵用戶也十分重要。

（3）功能漂移的可能性。選擇進(jìn)化原型作為過(guò)程模型的主要優(yōu)點(diǎn)是，它使得系統(tǒng)符合已知的用戶需求，但可以改變，以滿足后續(xù)發(fā)現(xiàn)的需求，這有助于生產(chǎn)出用戶想要的系統(tǒng)。然而，這同樣也帶來(lái)負(fù)擔(dān)，用戶經(jīng)常會(huì)一再要求增加新的特性，這些特性將增加開(kāi)發(fā)的時(shí)間和成本。可以使用嚴(yán)格的時(shí)間限制和迭代次數(shù)限制來(lái)緩和這種缺點(diǎn)。

（4）軟件結(jié)構(gòu)上的不足。由于制作原型時(shí)常希望快速提供原型，往往缺乏軟件結(jié)構(gòu)的細(xì)致設(shè)計(jì)，并且用戶新的或修改的需求可能會(huì)顛覆之前的設(shè)計(jì)，導(dǎo)致進(jìn)化原型總是伴隨著一定數(shù)量的不精良的軟件結(jié)構(gòu)，使得可維護(hù)性降低。這個(gè)結(jié)構(gòu)上的缺陷主要由進(jìn)化模型的迭代過(guò)程導(dǎo)致。通常，與傳統(tǒng)瀑布模型相比，進(jìn)化原型形成的系統(tǒng)結(jié)構(gòu)在效率上較低。在迭代中對(duì)原型進(jìn)行改良時(shí)必須格外注意，來(lái)保持設(shè)計(jì)的整潔性。

（5）能否有用戶的持續(xù)參與。對(duì)于基于進(jìn)化原型的項(xiàng)目，最終用戶是改進(jìn)需求和評(píng)估原型過(guò)程中不可缺少的部分。與其它傳統(tǒng)過(guò)程相比，需要他們更長(zhǎng)時(shí)間的參與。用戶必須意識(shí)到原型的狀態(tài)，并表達(dá)出對(duì)原型的期望。業(yè)務(wù)部門的真正投入和部門之間的溝通協(xié)作是項(xiàng)目順利推進(jìn)的關(guān)鍵。

4 結(jié)語(yǔ)

在PLM實(shí)施項(xiàng)目二次開(kāi)發(fā)過(guò)程中應(yīng)用的快速原型法，具有用戶需求清晰化、允許需求變更、逐步集成元素、盡早降低風(fēng)險(xiǎn)等優(yōu)點(diǎn)。項(xiàng)目上線后，得到了用戶的充分肯定?？焖僭头椒ㄊ欠襁m用，可以從系統(tǒng)結(jié)構(gòu)、邏輯結(jié)構(gòu)、用戶特征和應(yīng)用約束等多方面考慮[10]。從系統(tǒng)結(jié)構(gòu)方面而言，聯(lián)機(jī)事務(wù)處理類系統(tǒng)適合采用原型化方法，而批處理等結(jié)構(gòu)不適于用原型化方法；從邏輯結(jié)構(gòu)方面而言，管理信息系統(tǒng)、記錄管理系統(tǒng)等適合用原型化方法，而基于大量算法的系統(tǒng)不適合用原型化方法；從用戶方面來(lái)講，對(duì)難以預(yù)先作系統(tǒng)說(shuō)明、不容易肯定詳細(xì)需求、愿意為定義和修改原型投資的用戶，適合采用原型化方法；從系統(tǒng)應(yīng)用情況來(lái)看，對(duì)已經(jīng)運(yùn)行的系統(tǒng)作修補(bǔ)，不適合用原型化方法。從PLM系統(tǒng)的特點(diǎn)來(lái)看，在PLM實(shí)施項(xiàng)目中使用快速原型法是十分合適的。

參考文獻(xiàn)：

[1]孫康明.國(guó)內(nèi)航空制造企業(yè)PLM系統(tǒng)實(shí)施項(xiàng)目管理研究[D].上海：復(fù)旦大學(xué)， 2013.

[2]祝世海，孟炯，李勝利，等.采用原型法減少軟件需求分析的風(fēng)險(xiǎn)[J].信息技術(shù)，2002（2）：2-3.

[3]SCHUH G，ROZENFELD H，ASSMUS D，et al.Process oriented framework to support PLM implementation[J].Computers in Industry，2008，59（2）：210-218.

[4]BOKINGE M，MALMQVIST J.PLM implementation guidelines - relevance and application in practice： a discussion of findings from a retrospective case study[J].International Journal of Product Lifecycle Management，2012，6（1）：79-98.endprint

[5]BLEEK W G，JEENICKE M，KLISCHEWSKI R.Developing web-based applications through e-prototyping[C].International Computer Software and Applications Conference，2002：609-614.

[6]MOE N B，AURUM A，DYBA T.Challenges of shared decision-making：a multiple case study of agile software development[J].Information & Software Technology，2012，54（8）：853-865.

[7]LANA S，AL-SALEM，ALA M，et al.Strategy-focused requirements engineering method for web applications[J].International Journal of Web Engineering and Technology，2007，3（4）：397-419.

[8]CARTER R A，N A I WILLIAMS L，et al.Evolving beyond requirements creep：a risk-based evolutionary prototyping model[C].IEEE International Symposium on Requirements Engineering，2001：94-101.

[9]LICHTER H，SCHNEIDER-HUFSCHMIDT M，LLIGHOVEN H.Prototyping in industrial software projects—bridging the gap between theory and practice[C].International Conference on Software Engineering，1993：221-229.

[10]COOPER K G.Rapid prototyping technology：selection and application[M].New York：Marcel Dekker，2001.endprint