快速原型法在PLM系統二次開發項目中的應用

王尉

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

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

DOIDOI：10.11907/rjdk.171816

中圖分類號：TP319

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

1 PLM系統實施項目的特點

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

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

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

快速原型法的核心思想就是通過構造能夠體現目標系統主要特征的原型（Prototype），將目標系統以可視化的形式展現給用戶，在經過評估后對原型進行修改，逐步求精，繼續評估、修改，直到用戶滿意為止，它是一個循環迭代的過程[2]。快速原型法可以應用于需求采集，也可應用于技術方案驗證和整個系統的開發。

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

2.1 角色定義

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

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

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

（3）軟件開發組。負責支持用戶界面圖樣（UI）的創建，領導原型的開發工作。組內角色有：①主程序員，負責委派人員進行實施工作，監督缺陷的解決，執行項目實施；②領域專家，負責熟悉和理解某些特定的領域，執行項目實施；③用戶界面設計師，負責用戶界面圖樣（UI）設計。

2.2 軟件過程

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

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

2.2.1 項目規劃階段

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

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

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

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

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

2.2.3 第二輪迭代階段

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

結合新需求及用戶意見，對系統設計作出修改，作為已存在的需求與要實現的原型之間的橋梁?？偧軜嫀熦撠煴O督設計的完成，主程序員及其委派的開發人員按照系統設計開始構建系統，質保工程師基于需求創建軟件部件和系統測試。接下來，執行系統的編碼、調試以及測試直到滿足需求和系統設計。

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

2.2.4 第三輪迭代階段

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

與上一輪迭代一樣，結合新需求及用戶意見，修改系統設計，開始構建系統。執行系統的編碼、調試以及測試直到滿足需求和系統設計。

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

3 快速原型法的風險點

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

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

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

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

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

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

4 結語

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

參考文獻：

[1]孫康明.國內航空制造企業PLM系統實施項目管理研究[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