1.參考MIL-STD-498與IEEE/EIA-12207文件中敘述的Life Cycle Model有Waterfall、Spiral、Incremental、Evolutional 等4種model；

2.需求明確同時規劃一次完成之專案可採用Waterfall Model，2006年統計目前全球約有75%資訊專案是採用Waterfall Model。所謂需求明確意即甲方在發RFP時即能正確、完整、清晰（correct、complete、clear）將user’s needs轉換成requirements，因此在採購之前已完成Requirements Baseline，乙方只需要由Functional Baseline做起即可。測試工作依序進行Coding & Unit test、Component Test、CSCI Integration Test、System Integration Test （隨所選用的Standard會有所不同），彼此毫無重疊，且只做一次，FCA與PCA也只做一次，若有問題要修改，就提Software Revision的Software Change request ；

3.需求明確同時規劃分數次完之專案便可採用Incremental Model，在採購計畫書便須規劃有Build 1、Build 2、…等軟體版本，每一個軟體版本有其個別的Documents Tree，每一個Build有其Functional Baseline以及各自獨立的FCA與PCA，所以對於Incremental Model必須在Submit其Change Request給CMB時一併規劃其相對應之Test Plan。Incremental Model最常碰到的技術問題是經常在Build 1 release之後，會平行進行Build 2、Build 3、..等多項軟體版本之發展。通常可以採一次發RFP但以Milestone Decision Review方式，經由Task Order “turn on new build”，或是分為多次RFP執行，每一次build有其個別FCA，PCA是否要舉行隨產品是否要release而定（在採購計畫書中規劃）；每一個Build的test 程序基本上同waterfall model；

4.需求不明確但規劃一次完成的可以採用Spiral Model，與waterfall model的差別是在design phase之前加上進行確定requirements的spiral 過程，通常在spiral過程中以多次prototype用以確認需求，所以是由requirements baseline做起；Requirement development與software implement可分成二個合約執行，前面所敘述requirement development phase世藉由prototype來確認requirement，如果此項prototype是屬於re-useable approach，其軟體發展過程與測試過程同waterfall般，也就是一樣要寫plan、requirement document、design document，所有修改也要有CM；

5.需求不明確但規劃多次完成的可以採用Evolutional Model，每一次所完成的也同Incremental model稱之為Build x，Evolutional model的特性為 “I can not tell you what I want, but I’ll know it when I see it.”；

6.目前資訊系統技術變化速度已遠超過應用階段的時效性，且採購人員未必能夠切確掌握產品資訊，因此美國政府有關大型資訊系統採購幾乎都採用EASD (Evolutional Acquisition & Spiral Development) model，將採構需求分多次合約之遞增方式執行，每一個合約的需求與發展皆採用spiral model。

7.前述幾項model，最大差別在於需求是否明確，但軟體(CSCI)發展的測試基本上是相同的（這是屬於how-to-do，一般甲方不去管，只要乙方有CM即可），詳細步驟可參考MIL-STD-498 Sec. 5.7 （498適用於上述所有model，），只是相關於Incremental model的測試要再加上不同build版本的merge版測試。