王尉

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

關鍵詞：軟件工程；快速原型法；PLM

DOIDOI：10.11907/rjdk.171816

中圖分類號：TP319

文獻標識碼：A 文章編號：1672-7800（2017）007-0122-03

1 PLM系統(tǒng)實施項目的特點

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

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

2 快速原型法在項目中的應用

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

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

2.1 角色定義

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

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

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

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

2.2 軟件過程

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

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

2.2.1 項目規(guī)劃階段

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

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

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

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

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

2.2.3 第二輪迭代階段

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

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

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

2.2.4 第三輪迭代階段

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

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

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

3 快速原型法的風險點

PLM項目中應用快速原型模型不可避免地引入了其自身的風險[8-9]，針對本文提出的快速原型過程分析如下：

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

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

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

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

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

4 結(jié)語

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

參考文獻：

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

[2]祝世海，孟炯，李勝利，等.采用原型法減少軟件需求分析的風險[J].信息技術，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