一種改進的軟件開發模型
——組合模型研究

王雪梅，張春海

(中國海洋大學 信息科學與工程學院，山東 青島 266100)

0 引言

軟件開發模型是跨越整個軟件生存周期的系統開發、運行、維護所實施的全部工作和任務的結構框架，給出了軟件開發活動各階段之間的關系[1-3]。軟件產品質量好壞取決于很多因素，而軟件開發模型指導整個軟件活動，其指導地位至高無上，因此不少專家對其越來越關注，陸續提出了一些傳統開發模型，如瀑布模型、原型模型、增量模型及螺旋模型等[4-8]。隨著時代發展，軟件產品本身也發生著深刻變化，越來越復雜，在開發過程中遇到的問題也越來越多，這些傳統開發模型逐漸暴露出很多缺陷，變得不再適合，因此選擇一個合適的軟件開發模型指導軟件開發極其重要[9-11]。

本文通過對傳統瀑布模型、原型模型、增量模型及螺旋模型的深入研究，分析其優缺點，對其進行改進，提出“組合”模型，并將該模型運用到典當行業O2O后臺管理系統開發項目中。實踐表明，該模型改善了傳統模型的不足，降低了開發成本，有效提高了軟件開發效率。

1 傳統軟件開發模型缺陷

1.1 瀑布模型

瀑布模型最早由Winston Royce在1970年提出，是最早的軟件開發模型，它將軟件生命周期劃分為6個基本活動，即制定計劃、需求分析、設計、實現、測試和維護[12-13]，并規定了這些活動是自上而下的，且它們之間的順序不能改變。在項目開發中，要求這些活動嚴格按照順序進行，在每一階段都要有文檔生成，以保證軟件產品質量。但是，隨著軟件規模越來越大，功能趨向復雜和多樣，這種固有模式已經無法適應開發需要，當用戶需求隨時改變后，就要重新進行分析，浪費了大量時間、人力等資源。

1.2 原型模型

原型模型相比于瀑布模型有較大改進，開發人員先同用戶商議基本需求，根據這些需求建立一個原型，然后再對需求逐步求精，進一步細化，再進行改進，如此循環迭代，直到達到一個共同滿意的原型系統[14-15]。該模型的優點是快速、充分考慮用戶需求，彌補了瀑布模型的缺點，但該模型在起初階段沒有從整體出發全盤考慮，從而影響到軟件產品的整體質量。長期來看，這種模型的維護性很差，只是為了達到與用戶需求一致，在一定程度上開發人員舍棄了某些創新。

1.3 增量模型

增量模型是在瀑布模型和原型模型的基礎上開發的。該模型中軟件被看作是無數的增量集合構成，將軟件分解為不同的功能模塊。開發人員先開發最核心最基礎的模塊[16]，開發完成后先讓用戶評審，之后再根據用戶需求進行迭代開發，直至最后將用戶的完整需求都開發出來，集成最終的產品。它在一定程度上改進了瀑布模型和原型模型，但也有不足：如增量模型要求軟件具有很好的開放性與穩定性，能夠順利實現功能模塊的分解和增量的集成。當把一個新的增量集成到已有結構中時，一般要求此增量盡可能少地改變原來的軟件結構，所以要求增量具有相當好的功能獨立性。

1.4 螺旋模型

螺旋模型是1988年由Barry Boehm[17]提出，是一種周期迭代模型，該模型提出了“風險分析”步驟，這是其它傳統模型所不具備的。其每一次迭代都包括需求定義、風險分析、工程實現和評審4個階段，每次開發前都要進行風險分析，及時識別風險并進行有效控制進而提高軟件質量。螺旋模型也有不足，如要求軟件開發人員或風險分析人員有豐富的風險評估經驗和專門知識，能力要求較高。

2 局限性總結

對以上傳統軟件開發模型的局限性進行如下概括：

(1)軟件測試只是軟件開發的一部分，并未貫徹到整個軟件開發活動中。

(2)對于任何一個軟件產品來說，風險都是隨時隨地存在的，風險會對軟件產品的質量造成傷害，但大多數傳統模型都沒有做到控制風險。

(3)對軟件的需求分析往往不夠充分，不夠明確，最后可能導致用戶不滿意軟件產品，造成資源浪費。

3 改進的軟件開發模型

針對上述不足進行改進，提出了“組合”模型，如圖1所示。

圖1 “組合”模型

“組合”模型改進要點如下：

(1)從圖1可以看到，“組合”模型以增量模型為基本框架，以增量模型為基本框架是因為增量模型融合了瀑布模型和原型模型，其間又增添了很多具體信息。它要求先向客戶發布一個最核心的軟件產品，待用戶仔細評審和初步使用后，根據這個核心產品的滿意度再決定是否進行后續步驟。正因如此，在前期可不用投入過多人力，以免造成不必要的人力浪費；另一方面，先進行核心產品開發也可降低一定程度的風險，給最終的軟件產品增加一份保障。

(2)風險問題是軟件開發過程中不容忽略的重要問題[18-21]，風險有大有小，因此會在不同程度上影響軟件產品。在改進的軟件開發模型中，加強了風險控制，在每一階段的需求分析后都加入風險識別、分析與控制，每一階段都標示多個主要風險，爭取把所有風險因素找出來，從而選擇一個合適的對策減少風險帶來的損害，提高軟件產品質量。此外，應積極宣傳有關風險知識，定期舉行風險問題討論會，加強風險管理學習。

(3)對于一些大型軟件開發，軟件產品涉及工業、農業、商業等各行各業，這些行業的復雜程度很難想象，軟件開發人員在起初階段難以完整進行需求定義。為使開發人員對用戶提出的軟件需求理解更加充分，該模型借鑒了智能模型中的專家系統。首先從需求分析得出該軟件所涉及的背景、領域、書本、各類專家等方面知識，再基于一定的機制進行表示和編碼，構成一定的知識庫。從圖1可以看出，利用書本以及專家豐富的專業知識和經驗共同定義軟件需求，會使軟件需求更加明晰，對軟件有一個更好的把握，更有利于軟件開發。

(4)一個好的軟件開發模型的最終目的是提升軟件質量，盡早高效地檢測出錯誤。因此軟件測試地位與其它幾個階段是平等甚至說更加重要的，軟件測試應該始終伴隨軟件開發過程。當軟件功能越來越復雜時，出現的問題就會越多，越早發現就能越早改正，從而避免產生大的問題。在定義軟件需求時就進行需求測試，能保證需求階段軟件產品與用戶要求一致，這一方面能在一定程度上避免一些人力、物力等資源浪費，另一方面測試人員可了解用戶的部分需求信息，可從用戶和自身雙重角度設計測試用例，更有利于及早發現問題、解決問題，提高軟件質量。

(5)軟件編寫到后期階段一些問題才可能被發現，因為較高層次測試階段發現的軟件缺陷可能影響到較低層次的測試階段，所以當問題修改過后必須要回到起始階段做回歸測試。這些測試要循環進行，對測試用例也要不斷完善。另外，在測試完成后要交給用戶評審，若發現有需求變更或有錯誤的地方要及時更正，不斷地進行迭代開發，直至開發出令用戶滿意的產品。

(6)測試用例要廣而且多。為了實現測試用例的復用，可以建立一個測試用例庫，分析各種測試用例特點，找出其共性并添加到庫中，這樣做可以對一些測試用例進行復用，到下一次再有相似問題時直接使用，在一定程度上節省了資源和時間，加速了軟件開發。

4 測試實例

典當O2O(典寶網)后臺管理系統是一個集估價商品、典當商品、信息維護于一體的系統，總體模塊結構如圖2所示。

圖2 模塊結構

該系統3個功能相對獨立，存在的潛在風險也較大，估價和典當業務需要很專業的知識，往往需要這些領域專家的參與，如果只是單純使用4種傳統軟件開發模型，根本就不足以開發出一個完整項目。采用改進后的軟件開發模型進行開發，與傳統方法進行對比，結果見表1。開發包括從需求分析一直到整個軟件產品上線。

表1 各模型對比

瀑布模型只能進行線性開發，原型模型只注重了前期的需求、增量，螺旋模型沒有應用具體領域知識，對需求理解不是很準確，這些傳統模型在開發項目時遇到了不少困難。將改進的軟件開發模型進行開發項目，發現組合模型更占優勢，它不僅節省了時間，而且需要的總人數也較少，注重了產品質量，達到了用戶需求。

5 結語

選擇一個合適的軟件開發模型指導軟件開發極其重要。通過比較傳統開發模型的不足，在增量模型的基礎上進行改進，提出組合模型并運用到實際項目中。實踐表明，組合模型提高了軟件開發效率，避免了人力、物力等資源浪費，有一定的參考價值。