常聽到Water Fall Model 與 Spiral Model。
請問這二者的最大差別為何?
Life Cycle Model應由買方或賣方決定?
二者在Review與Audit方面有何差別?
與需求有何關連性?

Water fall model的最大特色就是：活動(activity)就是階段(phase)，階段就是活動，兩者分不開。意即，分析階段只做分析的事、設計階段只做設計的事…餘類推。因為極少數的專案是在一開始就完全瞭解需求的，因而這種做法的最主要的缺點就是很難對需求變更做出及時且適當的反應。

Spiral Model的最大特色就是要做雛型與風險分析，只有在完全掌握需求後才開始細部設計。因此在它的每一次循環(cycle)中有四個主要的活動：一、詳述軟體實體(software entity)的目的、限制與替代方案；二、評估相關替代方案的目的、限制與主要風險的來源；三、詳述專案的軟體實體的定義；四、為下個循環規劃，如果風險太大就終止專案，有把握地管理對客戶做出的承諾。

CNS 14837的1.5節中，明訂『使用本標準的雙方需負責為軟體專案選擇生命週期模型，並將本標準所訂之過程、作業及工作對應到此模型上。』所以，Life Cycle Model應由買方與賣方共同決定。

Review與Audit在任何生命週期模型中的做法基本上無太大差別，只是執行的時機應配合生命週期而進行。

這兩種生命週週期與需求的關連性，以於前文中說明了。再簡單重複一下：就是因為Water fall model不符合多數軟體開發專案中需求發展的實際狀況與需要，而有了Spiral Model。Spiral Model是在確實掌握了需求與風險，才往下進行細部設計以及其它的後續工作。

希望以上的說明能對您有所助益。

周茂松 敬上

有關於生命週期模型部分，Albert已提及。個人做一些小小補充：
在CNS 14837中1.5節(在ISO/IEC 12207:2008為第1.3節及5.1.6小節)述及軟體專案生命週期模型由供需雙方負責決定，但在CNS 14837中5.1節(ISO/IEC 12207:2008為第6.1.1節)並沒有把訂定生命週期模型這件事列出，而是在5.2.4.2小節(ISO/IEC 12207:2008為第6.1.2.3.4.2小節)及5.3.1.1小節(ISO/IEC 12207:2008為第7.1.1.3.1.1小節)中提到，"若在合約中未約定，供應者應定義或選擇一個適於專案的範圍、大小與複雜性的軟體生命週期模型"。在實務上(請自行參閱各發包單位的RPF與契約草案)，獲取者通常只會訂出取得可運行之軟體時程與其付款期程，因此，真正決定軟體生命週期模型的是供應者/發展者。這其實也是考慮到，發展者的能力、企業文化、組織制度、使用工具、對軟體專案所採取的策略等各有不同所致。

至於Review與Audit的工作。為了專案能達到目標，獲取者與供應者本身都需要去定義這兩種過程活動，只是Review與Audit工作的步驟與範圍，並沒有一定，需要有實務上的考慮，只是考量事項不單純是因為生命週期模型的差異而已，專案範圍、預算、期程、系統範圍、開發環境與工具、人員的能力、經驗、工作文化、對於領域知識的稔熟成度等等，都是Review與Audit規劃要考慮事項。

需求對於Waterfall或Spiral的選擇，影響並不大，其決定的因素應該是涉及系統使用技術的新穎程度、系統失效時可能產生的風險與衝擊、專案期程、專案經費籌措等等。如果是開發一個史無前例的產品，或是使用新技術開發，其實是不太適合用Waterfall方式開發的，因為，很容易變成，發展工作做到一半，發現技術上有無法突破的瓶頸，但是已經投入了相當多的人力物力了，因此，我們可以先使用少部分的經費發展一個雛型以進行試驗，以將專案失敗的風險與衝擊降至最低。在判斷一個軟體的發展究竟採行的是Waterfall或Spiral模型，應該從該產品或是該類型產品的全系列生命週期來看，會是比較清楚的。讀者可以試著研究一下，一個ERP系統的發展，到底是用了Waterfall或是Spiral模型。目前有許許多多的系統，基本上都是以既有的技術基礎做一些應用與調整，沒有所謂革命性作法。

----------------
引文:

誠如泰龍兄所言：「需求對於Waterfall或Spiral的選擇，影響並不大」，不過選用的生命週期模型卻大大的左右了開發者能否有效地掌握(管理與發展)軟體專案的需求。開發者有效掌握需求的能力，又是軟體專案成功的必要條件。因此，吾人對“為軟體專案選擇適用的生命週期模型”一事，實在不可掉以輕心。

此外，軟體生命週期模型亦不只有Waterfall或Spiral這兩種，其它有名的模型尚有UP/RUP與RAD…等可供選擇。選擇生命週期時除了要考量泰龍兄提到的那些因素外，可能還要考量開發團隊的能力，詳情可參考坊間的相關書籍。

國內的RFP中常有如下的規定：乙方應於D+n1日交付專案管理計畫;D+n2日交付SRS;D+n3日交付SDD…等(此處的n1,n2,n3…>0 且n1<n2<n3<…)；又RFP中也只要求這些文件於專案開發過程中交付這唯一的一次。其實，這已隱含著客戶單方面決定了專案的生命週期模型，那就是Water Fall Model。因為，其它的模型很難滿足這樣的要求，為了避免不必要的麻煩，開發者多半會選擇Water Fall Model。其後續的悲慘結果就不再贅言了。撰寫RFP的人對此點實在不可不慎。

標案的管理問題，並不在於RFP中是否真的以文件交付期程來框住生命週期模型。以個人在政府部門擔任甲方撰寫RFP的經驗而言，那些文件的交期的律定，只是因為要給供應商一定比例的金額，讓供應商不會因為財務的問題而做不下去，但是要給錢一定得要有相對的產出對財會部門交待才行。所以專案生命週期的律定與管理問題，不在RFP對產品(工程文件與軟體)交期的律定，而是甲乙雙方的工程、工程管理與專案管理能力的問題。另外，就是政府部門的經辦人想要避免一些制度面的程序。其實，經辦人可以在不影響期程、品質、預算的原則下(專案到最後也可以按規定與程序減價收受)，視情況下修改合約，只是有些經辦人怕麻煩--麻煩自己也麻煩長官。何況，就算文件提早交付了，也不見得後續不能提出更新版本(先給一個初始版本訂為基準，後續隨著開發的進度與對於需求的細緻化結果，提出修正版)，或者文件提早產生了，也是可以延後交付的，這些都是專案執行上的技術問題。像個人之前在專案中，每一份文件前前後後至少有七、八個版本以上。

----------------
引文: