王雪梅，張春海

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

0 引言

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

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

1 傳統(tǒng)軟件開發(fā)模型缺陷

1.1 瀑布模型

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

1.2 原型模型

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

1.3 增量模型

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

1.4 螺旋模型

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

2 局限性總結

對以上傳統(tǒng)軟件開發(fā)模型的局限性進行如下概括：

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

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

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

3 改進的軟件開發(fā)模型

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

圖1 “組合”模型

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

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

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

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

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

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

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

4 測試實例

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

圖2 模塊結構

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

表1 各模型對比

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

5 結語

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