淺談軟件生命周期模型及其選擇

朱婕

摘 要 同任何事物一樣，一個軟件產品或軟件系統(tǒng)也要經歷孕育、誕生、成長、成熟、衰亡等階段，一般稱為軟件生存周期（軟件生命周期）。把整個軟件生存周期劃分為若干階段，使得每個階段有明確的任務，使規(guī)模大，結構復雜和管理復雜的軟件開發(fā)變的容易控制和管理。通常，軟件生存周期包括可行性分析與開發(fā)項計劃、需求分析、設計（概要設計和詳細設計）、編碼、測試、維護等活動，可以將這些活動以適當?shù)姆绞椒峙涞讲煌碾A段去完成。

關鍵詞 軟件生命周期 瀑布型 快速原型

中圖分類號：TP31 文獻標識碼：A

1瀑布模型

雖然瀑布模型仍然存在很多的問題有待解決，但瀑布模型仍然是最基本的和最效的一種可供選擇的軟件開發(fā)生命周期模型.瀑布模型要求軟件開發(fā)嚴格按照：需求->分析->設計->編碼->測試的階段進行，每一個階段都可以定義明確的產出物和驗證準則.瀑布模型在每一個階段完成后都可以組織相關的評瀑布模型的優(yōu)點仍然是可以保證整個軟件產品較高的質量，保證缺陷能夠提前的被發(fā)現(xiàn)和解決。采用瀑布模型可以保證系統(tǒng)在整體上的充分把握，使系統(tǒng)具備良好的擴展性和可維護性.但對于前期需求不明確，而又很難短時間明確清楚的項目則很難很好的利用瀑布模型。另外對于中小型的項目，需求設計和開發(fā)人員往往在項目開始后就會全部投入到項目中，而不是分階段投入，因此采用瀑布模型會導致項目人力資源過多的閑置的情況，這也是必須要考慮的問題。審核驗證，只有在評審通過后才能夠進入到下一個階段。

瀑布模型強調文檔的作用，并要求每個階段都要仔細驗證。但是，這種模型的線性過程太理想化，已不再適合現(xiàn)代的軟件開發(fā)模式，幾乎被業(yè)界拋棄，其主要問題在于：

（1） 各個階段的劃分完全固定，階段之間產生大量的文檔，極大地增加了工作量。

（2） 由于開發(fā)模型是線性的，用戶只有等到整個過程的末期才能見到開發(fā)成果，從而增加了開發(fā)的風險。

（3）早期的錯誤可能要等到開發(fā)后期的測試階段才能發(fā)現(xiàn)，進而帶來嚴重的后果。

2螺旋模型

首先螺旋模型是遵從瀑布模型的，即需求->架構->設計->開發(fā)->測試的路線。螺旋模型最大的價值在于整個開發(fā)過程是迭代和風險驅動的，通過將瀑布模型的多個階段轉化到多個迭代過程中，以減少項目的風險。

螺旋模型的每一次迭代都包含了以下六個步驟：

（1）決定目標

（2）替代方案和約束識別和解決

（3）項目的風險評估技術方案和替代解決方案開發(fā)

（4）本次迭代的交付物和驗證迭代產出的正確性

（5）計劃下一次迭代

（6）提交下一次迭代的步驟和方案

螺旋模型是隨著項目成本投入不斷增加，風險逐漸減小的，以幫助我們加強項目的管理和跟蹤，在每次迭代結束后都需要對產出物進行評估和驗證，當發(fā)現(xiàn)無法繼續(xù)進行下去時可以及早的終止項目。

螺旋模型復雜的地方在于盡責，專心和知識淵博的管理。因為對于每一次迭代都要制定出清晰的目標，分析出相關的關鍵風險和計劃中可以驗證和測試的交付物并不是一件容易的事情。

3增量迭代模型

迭代式模型是RUP（RationalUnifiedProcess，統(tǒng)一軟件開發(fā)過程，統(tǒng)一軟件過程）推薦的周期模型。在RUP中，迭代被定義為：迭代包括產生產品發(fā)布（穩(wěn)定、可執(zhí)行的產品版本）的全部開發(fā)活動和要使用該發(fā)布必需的所有其他外圍元素。所以，在某種程度上，開發(fā)迭代是一次完整地經過所有工作流程的過程：（至少包括）需求工作流程、分析設計工作流程、實施工作流程和測試工作流程。實質上，它類似小型的瀑布式項目。RUP認為，所有的階段（需求及其它）都可以細分為迭代。每一次的迭代都會產生一個可以發(fā)布的產品，這個產品是最終產品的一個子集。

迭代和瀑布的最大的差別就在于風險的暴露時間上。“任何項目都會涉及到一定的風險。如果能在生命周期中盡早確保避免了風險，那么您的計劃自然會更趨精確。有許多風險直到已準備集成系統(tǒng)時才被發(fā)現(xiàn)。不管開發(fā)團隊經驗如何，都絕不可能預知所有的風險?！庇捎谄俨寄Ｐ偷奶攸c（文檔是主體），很多的問題在最后才會暴露出來，為了解決這些問題的風險是巨大的。在迭代式生命周期中，您需要根據(jù)主要風險列表選擇要在迭代中開發(fā)的新的增量內容。每次迭代完成時都會生成一個經過測試的可執(zhí)行文件，這樣就可以核實是否已經降低了目標風險。

4快速原型（RapidPrototype）模型

快速原型模型在功能上等價于產品的一個子集。注意，這里說的是功能上。瀑布模型的缺點就在于不夠直觀，快速原型法就解決了這個問題。一般來說，根據(jù)客戶的需要在很短的時間內解決用戶最迫切需要，完成一個可以演示的產品。這個產品只是實現(xiàn)部分的功能（最重要的）。它最重要的目的是為了確定用戶的真正需求。在我的經驗中，這種方法非常的有效，原先對計算機沒有絲毫概念的用戶在你的原型面前往往口若懸河，有些觀點讓你都覺得非常的吃驚。在得到用戶的需求之后，原型將被拋棄。

上述的模型中都有自己獨特的思想，其實現(xiàn)在的軟件組織中很少說標準的采用那一種模型的。模型和實用還是有很大的區(qū)別的。軟件生命周期模型的發(fā)展實際上是體現(xiàn)了軟件工程理論的發(fā)展。在最早的時候，軟件的生命周期處于無序、混亂的情況。一些人為了能夠控制軟件的開發(fā)過程，就把軟件開發(fā)嚴格的區(qū)分為多個不同的階段，并在階段間加上嚴格的審查。這就是瀑布模型產生的起因。瀑布模型體現(xiàn)了人們對軟件過程的一個希望：嚴格控制、確保質量。可惜的是，現(xiàn)實往往是殘酷的。瀑布模型根本達不到這個過高的要求，因為軟件的過程往往難于預測。反而導致了其它的負面影響，例如大量的文檔、繁瑣的審批。因此人們就開始嘗試著用其它的方法來改進或替代瀑布方法。例如把過程細分來增加過程的可預測性?，F(xiàn)總結如下：

（1）在前期需求明確的情況下盡量采用瀑布模型或改進型的瀑布模型。

（2）在用戶無信息系統(tǒng)使用經驗，需求分析人員技能不足情況下一定要借助原型。

（3）在不確定性因素很多，很多東西前面無法計劃情況下盡量采用增量迭代和螺旋模型。

（4）在需求不穩(wěn)定情況下盡量采用增量迭代模型。

（5）在資金和成本無法一次到位情況下可以采用增量模型，軟件產品分多個版本進行發(fā)布。

（6）對于完全多個獨立功能開發(fā)可以在需求階段就分功能并行，但每個功能內都應該遵循瀑布模型。

（7）對于全新系統(tǒng)的開發(fā)必須在總體設計完成后再開始增量或并行。

（8）對于編碼人員經驗較少情況下建議不要采用敏捷或迭代等生命周期模型。

（9）增量，迭代和原型可以綜合使用，但每一次增量或迭代都必須有明確的交付和出口準則。

參考文獻

[1] （美）MichaelHoward&（美）SteveLipner.軟件安全開發(fā)生命周期（中譯本掃描版）.電子工業(yè)出版社，2008.01.

[2] 張向宏.軟件生命周期質量保證與測試.電子工業(yè)出版社，中國軟件評測中心組編，2009.05.01.