1）瀑布模型，
2）快速原型模型，
3）漸增模型，
4）演進模型。
下面我們重點闡述前3種常用的生命周期模型。
2．1瀑布模型
顧名思義，該模型就是像瀑布一樣。這是一個最傳統的生命周期模型，是一種順序的模型，自頂向下把一個軟件開發過程分為：系統定義、需求分析、設計、編碼、 測試和維護等階段。在開發過程中這些階段順序進行，就像是一個飛流直下的瀑布，因此得名。該模型可以用下面的圖形來表示。
系統定義
\|/
需求分析
\|/
設計
\|/
編碼
\|/
測試
\|/
維護
有時，根據項目的特點，設計又可分為概要設計和詳細設計。
上圖中各階段所要完成的工作在一般的論述軟件工程的書籍中都有描述，這里就不再細述。
雖然上面的階段是順序進行的，但是這并不是限定我們的軟件項目必須在完成了上個階段的工作后才能進行下個階段的工作。在實際的開發過程中，我們常常會遇到這樣的情況：階段反復和重疊。
在前面的需求管理部分我們曾經闡述過需求變更管理。也就是說，在軟件開發的某個階段可能發生需求變更，而一旦軟件需求發生變化，就勢必會造成軟件設計的改 變，因此，如果該軟件項目已經進行到了測試階段，那么我們就必須回過頭來重新進行需求分析、概要設計、詳細設計和編碼。像這種在后面的階段又返回來做前面 階段工作的情形，就成為階段反復。當然，也有可能因為開發人員前面的工作做得不夠準確而導致階段反復。階段反復常常會造成進度延遲，但是，只要嚴格控制好 每個階段的輸入和輸出，我們還是可以有效的控制軟件項目的開發過程。
在實際的開發過程中我們還會遇到這種情況：如果一個軟件項目規模較大，而 且各功能模塊相對獨立，那么，我們就沒有必要要求所有模塊的進度都一致，也就是說，模塊1可能很快就能完成概要設計和詳細設計，而模塊2由于太復雜概要設 計可能就需要很長的時間。對于這種情況，只要控制好模塊1各階段的輸入和輸出，完全可以讓模塊1先行，直到完成或者必須停下來等待其他模塊。像這種情況， 一個軟件項目的各模塊可能處于不同的階段，就成為階段重疊。出現這種情況，必須是某些模塊比較獨立，否則就不可能比其他模塊先行。
雖然階段的 重疊和反復是允許的，但是我們卻不能允許這種情況隨意發生。比如說，需求分析和設計可以重疊，但是如果需求分析和編碼也重疊就很難說代碼會寫成什么樣了； 編碼階段可以因為需求變更回過頭來進行需求分析和設計，但是如果已經進行系統測試了還在進行階段反復，這就等于又開發一個新項目了。因此，為了更好的控制 軟件開發過程，要盡量減少階段重疊和反復，如果實在不可避免，應該對所有的變更進行嚴格控制，這樣才能保證我們的開發過程陷入無序狀態。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
