互聯網的產業裏，網絡遊戲產業也是其中的一部分，改良流程的一部分也介紹一些基礎的模型。本章介紹的是瀑布模型的應對辦法。
瀑布生命週期模型：（也被稱爲線性模型）
[需求分析]=>[概要設計]=>[詳細設計]=>[編碼和單元測試]=>[軟件集中]=>[系統集中]=>[驗收測試]=>[結束]
這是一個版本簡單的交付過程，最後一步測試才介入。這個軟件行業剛發展時的流程。現在依然還是不少遊戲公司的交付模式。
遊戲產業有些許的變化：
前者
[需求分析]由策劃部門給予 通常由2個部門執行：程序，美術
[概要設計]通常由3個部門執行：策劃，程序，美術。
[詳細設計]通常由3個部門執行：策劃，程序，美術。
[編碼和單元測試]由程序部門執行。
遊戲產業測試大部份公司都無法獲悉代碼，所以這部分就沒辦法了。
[軟件集中]由程序部門執行。
這個應該是程序的代碼view，具體對不對我也不清楚。
[系統集中]功能模塊的集中，準備交給測試了。
在瀑布生命週期裏，這時候還是沒有交給測試。
[驗收測試]
這個版本的內容終於交到測試手中了。
如果遇到這種情況，我們該怎麼辦呢？接下來看看這個流程：
後者
[需求分析]由策劃部門給予 對口的部門：程序，美術，測試
測試獲得策劃部門的策劃案後，先進行需求分析。添加總表的測試計劃，分析關係點和測試粒度。
[概要設計]通常由3個部門執行：策劃，程序，美術，測試。
測試也可以加入，但是和其他2個部門無交集。編寫第一個版本的測試用例。
[詳細設計]通常由3個部門執行：策劃，程序，美術。
測試也可以加入，可能和策劃溝通較多。考慮到一些接口設計和測試用例補充完整。
[編碼和單元測試]由程序部門執行。
當然如果你願意的話，也可以提供些靜態代碼測試工具。例如PR公司的PRQA。靜態的代碼不需要經過調式。
[軟件集中]由程序部門執行。這個我不清楚具體內容，不發表評論。可以在這個階段進行功能單元模塊測試。功能的迭代測試。
[系統集中]功能模塊的集中。可能在這個階段進行了多次迭代測試。當缺陷數量滿足缺陷密度大概2次左右，實際是根據當前版本內容而定的。
[驗收測試]
接下來按策略進行快速回歸和冒煙就可以發佈，看這個時候就能輕鬆交版本了。而測試團隊的能力也不會因爲大量等待的空檔期而荒廢。
然後前者傳統等待的辦法，會一時很緊一時過鬆。而且整個項目的進度也會因爲測試周期和延後修復bug佔用正常研發團隊的沉餘時間。
另外注意一些固定規則的無益：
（1）團隊比較忌諱有不合理的空檔期 （2）在缺陷密度已經達到後，依然進行量化測試、 end