1、關鍵字：軟件生命周期、軟件生命周期模型、軟件開發方法論瀑布模型、螺旋模型、增量模型、迭代模型、敏捷開發黑盒測試、灰盒測試、白盒測試 系統測試、集成測試、單元測試1軟件生命周期依據不同的原則對軟件生命周期的劃分也不同，軟件工程國家標準 一一計算機軟件開發規范(GB856688)中將軟件生命周期劃分為 8個階段：可行性 研究與計劃、需求分析、概 要設計、詳細設計、實現(包括單元測試卜組裝測試(集成測試卜確認測試、使用和維護。本書按照人們所習慣的粗分方法把上面8個階段劃分為計劃、開發和維護3個階段，在概述其他兩個階段的基礎上重點介紹軟件的開發過程。2.軟件生命周期模型瀑布模型/改進的瀑布模型雖然瀑布

2、模型仍然存在很多的問題有待解決，但瀑布模型仍然是最基本的和最效的一種可供選擇的軟件開發生命周期模型.瀑布模型要求軟件開發嚴格按照需求-> 分析-> 設計-> 編碼-> 測試的階段進行，每一個階段都可以定義明確的產出物和驗證準則.瀑布模型在每一個階段完成后都可以組織相關的評審和驗證，只有在評審通過后才能夠進入到下一個階段由于需要對每一個階段進行驗證，瀑布模型要求每一個階段都有明確的文檔產出，對于嚴格的瀑布模型每一個階段都不應該重疊，而應該是在評審通過，相關的產出物都已經基線后才能夠進入 到下一個階段.瀑布模型的優點仍然是可以保證整個軟件產品較高的質量，保證缺陷能夠提前的被

3、發現和解決.采用瀑布模型可以保證系統在整體上的充分把握，使系統具備良好的擴展性和可維護性.但對于前期需求不明確，而又很難短時間明確清楚的項目則很難很好的利用瀑布模型.另外對于中小型的項目，需求設計和開發人員往往在項目開始后就會全部投入到項目中，而不是分階段投入，因此采用瀑布模型會導致項目人力資源過多的閑置的情況，這也是必須要考慮的問題 .很多人往往會以進度約束而不選擇瀑布模型，這往往是一個錯誤的觀點.導致這種情況的一個關鍵因素往往是概念需求階段人力不足.因此在概念需求階段人力能夠得到充分保證的情況下，瀑布模型和迭代模型在開發周期上并不會存在太大的差別.反而是很多項目對于迭代或敏捷模型用不好，為

4、了趕進度在前期需求不明確，沒有經過一個總體的架構設計情況下就開始編碼，后期出現大量的返工而嚴重影響進度 .架構設計是軟件開發中一個重要的關注點.因此在RUP中也提及到軟件開發要以架構為核心.因此在架構設計完成后系統會被分為相關的子系統和功能模塊.每個功能模塊間的接口都可以定義清楚.在這種ff況下，當模塊B的詳細設計做完成后往往就沒有必要等到其它模塊的詳細設計都要 完全作完才開始編碼，因此在架構設計完成后可以將系統分為多個模塊并行開發，每個模塊仍然遵循先設計和編碼測試的瀑布模型思路.這是瀑布模型的一種最重要的改進思路，也可以說這是一種增量開發的模型.當一個新系統的開發存在多個完全不相關的獨立需求

5、的功能開發的時候，這個時候也可以選擇將整個開發過程按獨立的需求來分為多個小瀑布進行操作.這種方式的最大問題就是沒有一個完全總體的設計，架構設計人員無法在洞悉了所有需求后從系統的可擴展性，復用等方面總體規劃.在項目管理中有一種壓縮進度的方法叫趕工，因此瀑布模型的另外改進處就在適當的重疊各個階段過程，達到資源的有效利用.比如我們通過討論，會議確定的實現方式就可以開始執導下一個階段的工作而不一定完全等到相關的交付物文檔化出來螺旋模型首先螺旋模型是遵從瀑布模型的.即需求-> 架構-> 設計-> 開發-> 測試的路線.螺旋模型最大的價值在于整個開發過程是迭代和風險驅動的.通過將瀑

6、布模型的多個階段轉化到多個迭代過程中以減少項目的風險.制定計劃累計 施本風險分析風險分析風除分析可運行需求與測試單元測試設計確認 與驗證竟型A原型公原型軟件產詳細設討 品設計/決定目標 方案和限制提交線客戶評估實施工程 開發、胎證 下一產品評價方窠 識別風險 消除風險螺旋模型的每一次迭代都包含了以下六個步驟1 .決定目標，替代方案和約束2 .識別和解決項目的風險3 .評估技術方案和替代解決方案4 .開發本次迭代的交付物和驗證迭代產出的正確性5 .計劃下一次迭代6 .提交下一次迭代的步驟和方案.螺旋模型實現了隨著項目成本投入不斷增加，風險逐漸減小.以幫我我們加強項目的管理和跟蹤，在每次迭代結束后

7、都需要對產出物進行評估和驗證，當發現無法繼續進行下去時可以及早的終止項目.螺旋模型復雜的地方在于盡責，專心和知識淵博的管理.因為對于每一次迭代我們要制定出清晰 的目標，分析出相關的關鍵風險和計劃中可以驗證和測試的交付物并不是一件容易的事情螺旋模型的每一次迭代只包含了瀑布模型的某一個或兩個階段.如第二次迭代重點是需求，第三次迭代是總體設計和后續設計開發計劃等.因此這是和RUP提倡的迭代模型是有區別的，RUP的每一次迭代都會包含需求，設計，開發和測試等各個階段的活動.RUP迭代的目的在于逐步求精而 不是僅僅完成瀑布模型某一階段的工作增量和迭代模型增量迭代是RUP統一過程常采用的軟件開發生命周期模型

8、.增量和迭代有區別但兩者又經常一起使用.所以這里要先解釋下增量和迭代的概念.假設現在要開發 A,B,C,D四個大的業務功能，每個功能都需要開發兩周的時間.則對于增量方法而言可以將四個功能分為兩次增量來完成，第一個增量完成A,B功能，第二次增量完成 C,D功能；而對于迭代開發來將則是分兩次迭代來開發，第一次迭代完成A,B,C,D四個基本業務功能但不含復雜的業務邏輯，而第二個功能再逐漸細化補充完整相關的業務邏輯.在第一個月過去后采用增量開始時候A,B全部開發完成而 C,D還一點都沒有動；而采用迭代開發的時候A,B,C,D四個的基礎功能都已經完成.RUP強調的每次迭代都包含了需求，設計和開發，測試等

9、各個過程，而且每次迭代完成后都是一個 可以交付的原型.迭代不是并行，在每次迭代過程中仍然要遵循需求-> 設計-> 開發的瀑布過程.迭 代周期的長度跟項目的周期和規模有很大的關系.小型項目可以一周一次迭代，而對于大型項目則可以2-4周一次迭代.如果項目沒有一個很好的架構師，很難規劃出每次迭代的內容和要到達的目標，驗證相關的交付和產出.因此迭代模型雖然能夠很好的滿足與用戶的交付，需求的變化，但確是一個很難真正用好的模型.Organization along TimeDisciplinesOrganizationalongContenlBusin白冷 EngineeringRgWroE白

10、。梅An ulY,話 and DesignImplomvn IulianTfltlDeploymentCcnfigurjiUoc and Change Mtfrlhg4nwnt Project Management Envkonrrwnl就對風險的消除上，增量和迭代模型都能夠很好的控制前期的風險并解決.但迭代模型在這方面更有彳t勢.迭代模型更多的可以從總體方面去系統的思考問題，從最早就可以給出相對完善的框架或原型，后期的每次迭代都是針對上次迭代的逐步精化業界比較標準的增量模型往往要求在軟件需求規格說明書全部出來后后續的設計開發再進行增量.同時每個增量也可以是獨立發布的小版本.由于系統的總體設計

11、往往對一個系統的架構和可擴展性有重大的影響，因此我們推薦的增量最好是在架構設計完成后再開始進行增量，這樣可以更好的保證系統的健壯性和可擴展性.原型法原型一般都不是單獨采用的一種生命周期模型，往往會結合瀑布和增量迭代等方法一起使用.對于螺旋模型就可以理解為瀑布+迭代+原型+風險的一種生命周期模型 .對于迭代開發來講，每一個迭代周期的產出都可以看做是下個階段要精化的原型.而對于瀑布模型開發來講，我們在需求階段也可以進行界面和操作建模，形成DEMO后和用戶做進一部的需求溝通和確認.當你的用戶沒有信息系統的使用經驗，你的系統分析員也沒有過多的需求分析和挖掘經驗的時候需求分析和調研過程則更需要是一個啟發

12、式的過程.而原型則是這種很好的啟發式方法，可以快速的挖掘用戶需求并達成需求理解上的一致.否則即使雙方都簽字認可的需求往往仍然不是客戶真正想要的東西.原型可以分為拋棄型的和不拋棄型的.如果原型僅僅是需求階段方面和用戶溝通畫的DEMO,則這種原型一般都建議拋棄掉.而對于迭代開發來將，每次迭代的產出都是可以獨立運行和包含基 礎功能的系統，是后續細化的基礎，這類原型一般都不建議拋棄，后期的設計開發也要基于該原型 逐漸的進行完善.快速和敏捷開發我們一般將快速和敏捷開發做為方法論，而很少將其做為一種軟件開發生命周期模型.敏捷的目的是減少繁重和不必要的工件的輸出，提高效率.而不是要我們去挑階段或過程，不是分

13、析設計都還沒有做就去做開發.因此對于瀑布，增量迭代或原型我們都可以借鑒敏捷方法論中的一些好的實踐,這些實踐都是對傳統的生命周期模型很好的補充.對于敏捷方法論在此不再做過多的敘述關于選擇生命周期模型的最后的總結1 .在前期需求明確的情況下盡量采用瀑布模型或改進型的瀑布模型2 .在用戶無信息系統使用經驗，需求分析人員技能不足情況下一定要借助原型3 .在不確定性因素很多，很多東西前面無法計劃情況下盡量采用增量迭代和螺旋模型4 .在需求不穩定情況下盡量采用增量迭代模型5 .在資金和成本無法一次到位情況下可以采用增量模型，軟件產品分多個版本進行發布6 .對于完全多個獨立功能開發可以在需求階段就分功能并行，但每個功能內都應該遵循瀑布模型7 .對于全新系統的開發必須在總體設at完成后再開始增量或并行8 .對于編碼人員經驗較少情況下建議不要采用敏捷或迭代等生命周期模型9 .增量，迭代和原型可以綜合使用，但每一次增量或迭代都必須有明確的交付和出口準則.3、軟件的黑盒、灰盒、白盒測試與需求分析對應的是系統測試。因為需求分析的工作是分解用戶的功能和性能需求并規格化，所以系統測試的工作主要就是測試這些功能和性能指標是否都在軟件中正確實現。該測試把軟件作為一個黑盒，針對每個需求規格組織各種輸入并根據軟件輸出來判斷該需求規格是否正確實現，因此系統測試屬于黑盒測試。與概要設計對應的是集