1 軟件生命週期
軟件生命週期也就是軟件生存的週期。同萬物一樣，軟件也有誕生和消亡，軟件生命週期就是指軟件自開始構思與研發到不再使用而消亡的過程。有關軟件生命週期的階段劃分，不同的標準有不同的規定。在 GB8566-88 （ 《 軟件工程國家標準 —— 計算機軟件開發規範 》 ）中將軟件生命週期劃分爲8個階段：可行性研究與計劃 、 需求分析 、 概要設計 、 詳細設計 、 實現、集成測試、確認測試、使用和維護。
（1）可行性研究與計劃
在決定是否開發軟件之前，首先需要進行可行性研究。通過可行性研究，來確定開發此軟件的必要性，並根據可行性研究的結果初步確定軟件的目標 、 範圍 、 風險 、 開發成本等內容。從而制定出初步的軟件開發計劃。通過可行性研究，如果確定該軟件具有研發的必要，則將產生 《 可行性研究報告 》 和 《 軟件開發計劃 》 ，並進入需求分析的階段。
（2）需求分析
需求分析是軟件開發的重要階段。經過可行性研究後，初步確定了軟件開發的目標和範圍，之後則需要對軟件的需求進行細緻的分析，來確定軟件要做成什麼樣的。需求分析是軟件開發過程中極其重要的一環，如果需求分析出現了重大偏差，那麼軟件開發必然會偏離正確的道路，越走越遠。尤其是需求分析的錯誤如果在軟件開發後期才被發現，修正的代價是非常大的。
（3）概要設計
概要設計確定整個軟件的技術藍圖，負責將需求分析的結果轉化爲技術層面的設計方案。在概要設計中，需要確定系統架構 、 各子系統間的關係 、 接口規約 、 數據庫模型 、 編碼規範等內容。概要設計的結果將作爲程序員的工作指南，供程序員瞭解系統的內部原理，並在其基礎上進行詳細設計和編碼工作。
（4）詳細設計
詳細設計完成編碼前最後的設計，詳細設計在概要設計的基礎上，進行細化，如類設計。詳細設計不是開發過程中必需的階段，在一些規模較小 、 結構簡單的系統中，詳細設計往往被省略。同樣，在某一次軟件開發中，可能只會對部分關鍵模塊進行詳細設計。
（5）實現
實現過程包括編碼和單元測試。單元測試指的是對剛剛編寫出的一個小的程序單元進行測試，如某一個過程 、 方法或函數。因爲單元測試的對象是小的程序單元，而不是完整的程序，因此往往需要編寫一些測試程序來進行測試。有效的單元測試可以大大提高編碼的質量，降低軟件系統的缺陷率。
（6）集成測試
集成測試又稱爲組裝測試。通過單元測試的程序並不意味着沒有缺陷，當程序單元被集成到一起進行交互的時候，往往會出現單元測試中不能發現的問題。同單元測試不同，集成測試必須經過精心的組織，指定集成測試計劃，確定如何將這些程序單元集成到一起，按照什麼樣的順序進行測試，使用哪些測試數據等問題。
（7）確認測試
當完成集成測試後，軟件之間的接口方面的錯誤已經排除，這時需要驗證軟件是否同需求一致，是否達到了預期目標。同集成測試一樣，確認測試也需要進行計劃和組織，逐步地驗證軟件系統同需要的一致性。經過確認測試的軟件將投入正常使用，並進入維護期。
（8）使用和維護
即使通過了單元測試 、 集成測試和確認測試，也不可能發現軟件系統中的全部缺陷；軟件系統的需求也會根據業務的發展變化而變化。因此，在軟件使用過程中，必須不斷地對軟件進行維護，修正軟件中的缺陷，修改軟件中已經不能適應最新情況的功能或者增加新的功能。軟件維護的過程會貫穿整個軟件的使用過程。當使用和維護階段結束後，軟件系統也就自然消亡，軟件系統的生命週期結束。
2 軟件開發模型
在計算機剛剛誕生的年代，計算機是一種只有天才才能掌握的工具。人們對軟件的認知僅僅停留在程序的層面上，所謂的軟件開發就是那些能夠掌握計算機的天才們寫的一些只有計算機才能理解的二進制序列。但隨着技術的發展，軟件的複雜度不斷提高，人們進入了大規模軟件開發的時代。這時，人們發現，軟件系統已經變得非常複雜，需要遵循一定的開發方法才能取得成功，於是稱這些模式化的開發方法爲開發模型。
2.1 瀑布模型
顧名思義，瀑布模型就如同瀑布一樣，從一個特定的階段流向下一個階段，如圖 1 所示。
2.1.1 瀑布模型的核心思想
瀑布模型認爲，軟件開發是一個階段化的精確的過程。就像要製造一艘航空母艦，首先需要知道航空母艦的參數（長 、 寬 、 高 、 排水量 、 航速等）。在這些參數的技術上需要對航空母艦進行設計，設計包括總體設計和詳細設計。只有設計得一清二楚的圖紙才能交付施工，否則造出的零件肯定拼裝不到一起。製造完畢後，要把這些零件一個一個地拼裝起來，拼裝成發動機 、 船艙等部分，並檢查這些部分是否符合設計標準，這就是集成測試。最後，把各個部分組合在一起，造出一艘巨大的航母。這個過程正如圖 1 中的描述，軟件要經過需求分析 、 總體設計 、 詳細設計 、 編碼 、 調試 、 集成測試和系統測試階段才能夠被準確地實現。在圖 1 中，每一階段都有回到前一階段的反饋線，這指的是，在軟件開發中當在後續階段發現缺陷的時候，可以把這個缺陷反饋到上一階段進行修正。
從圖 1 中可以看出瀑布模型的一個重要特點：軟件開發的階段劃分是明確的，一個階段到下一個階段有明顯的界線。在每個階段結束後，都會有固定的文檔或源程序流入下一階段。在需求分析階段結束後，需要有明確的描述軟件需求的文檔；總體設計結束後，需要有描述軟件總體結構的文檔；詳細設計結束後，需要有可以用來編碼的詳細設計文檔；而編碼結束後，代碼本身被作爲文檔流到下一個階段。因此也稱瀑布模型是面向文檔的軟件開發模型。
當軟件需求明確 、 穩定時，可以採用瀑布模型按部就班地開發軟件，當軟件需求不明確或變動劇烈時，瀑布模型中往往要到測試階段纔會暴露出需求的缺陷，造成後期修改代價太大，難以控制開發的風險。
2.1.2 瀑布 V 模型
瀑布 V 模型是瀑布模型的一種變體。隨着對瀑布模型的應用，人們發現，缺陷是無法避免的，任何一個階段都會在軟件中引入缺陷，而最後的測試也不能保證軟件完全沒有缺陷，只能爭取在交付前發現更多的缺陷。測試成爲軟件開發中非常重要的環節，測試的質量直接影響到軟件的質量。因此，人們對瀑布模型進行了小小的更改，提出了更強調測試的瀑布 V 模型，如圖 2 所示。
整個瀑布模型在編碼與調試階段轉了個彎，形成了一個對稱的 V 字。瀑布 V 模型同標準瀑布模型一樣，在進行完需求分析後就將進入總體設計階段，但是除總體設計外，需求分析還有一條虛線指向系統測試。這指的是，需求分析的結果將作爲系統測試的準則，即需求分析階段也將產生同軟件需求一致的系統測試；同時軟件產品是否符合最初的需求將在系統測試階段得到驗證。以此類推，總體設計對應了集成測試，詳細設計對應了單元測試。瀑布 V 模型不但保持了瀑布模型的階段式文檔驅動的特點，而且更強調了軟件產品的驗證工作。
2.1.3 瀑布模型的缺點
雖然是經典的開發模型，但瀑布模型中仍存在一些難以克服的缺陷，即使是在改進的瀑布 V 模型中還是會存在。
-
首先，在瀑布模型中，需求分析階段是一切活動的基礎，設計 、 實現和驗證活動都是從需求分析階段的結果導出的。一旦需求分析的結果不完全正確，存在偏差，那麼後續的活動只能放大這個偏差，在錯誤的道路上越走越遠。事實上，由於用戶和開發者的立場 、 經驗 、 知識域都不相同，不同的人對同一件事物的表述也不同，這就造成需求分析的結果不可能精確 、 完整地描述整個軟件系統。所以瀑布模型後期的維護工作相當繁重，而這些維護工作大多都是修正在需求分析階段引入的缺陷。這個問題是瀑布模型難以克服的。
-
其次，瀑布模型難以適應變化。在瀑布模型中精確地定義了每一個階段的活動和活動結果，而每一階段都緊密依賴於上一階段的結果。如果在軟件的後期出現了需求的變化，整個系統又要從頭開始。
-
再次，使用瀑布模型意味着當所有階段都結束才能最終交付軟件產品，所以在提出需求後需要相當長一段時間的等待才能夠看到最終結果，才能發現軟件產品究竟能不能夠滿足客戶的需求。
-
最後，文檔驅動型的瀑布模型除了製造出軟件產品外還將產生一大堆的文檔，大部分的文檔對客戶沒有任何意義，但完成這些對客戶沒有意義的文檔卻需要花費大量的人力。所以瀑布模型也是一種重載過程。
2.2 演化模型
瀑布模型看起來很好，隨着一個又一個階段的流過，軟件系統就被建立起來了。可是在應用軟件開發的過程中，人們發現很難一次性完全理解用戶的需求 、 設計出完美的架構，開發出可用的系統，這是由於人的認知本身就是一個過程，這個過程是漸進的 、 不斷深化的。對於複雜問題， “ 做兩次 ” 肯定能夠做得更好。那麼，對於軟件開發這個複雜而且與人的認知過程緊密相關的事也應該是一個漸進的過程。
演化模型正是基於這個觀點提出的。一般情況下，一個演化模型可以看做若干次瀑布模型的迭代，當完成一個瀑布模型後，重新進入下一個迭代週期，軟件在這樣的迭代過程中得以演化 、 完善。根據不同的迭代特點，演化模型可以演變爲螺旋模型 、 增量模型和原型法開發。
2.3 螺旋模型
螺旋模型將瀑布模型和演化模型結合起來，不僅體現了兩個模型的優點，而且還強調了其他模型均忽略了的風險分析。螺旋模型的每一週期都包括需求定義 、 風險分析 、 工程實現和評審4個階段，由這4個階段進行迭代，軟件開發過程每迭代一次，軟件開發就前進一個層次。採用螺旋模型的軟件過程如圖 3 所示。
螺旋模型的基本做法是在 “ 瀑布模型 ” 的每一個開發階段前，引入一個非常嚴格的風險識別 、 風險分析和風險控制。它把軟件項目分解成一個個小項目，每個小項目都標識一個或多個主要風險，直到所有的主要風險因素都被確定。
螺旋模型強調風險分析，使得開發人員和用戶對每個演化層出現的風險都有所瞭解，繼而做出應有的反應。因此，螺旋模型特別適用於龐大而複雜 、 具有高風險的系統，對於這些系統，風險是軟件開發潛在的 、 不可忽視的不利因素，它可能在不同程度上損害軟件開發過程，影響軟件產品的質量。減小軟件風險的目標是在造成危害之前，及時對風險進行識別 、 分析，決定採取何種對策，進而消除或減少風險的損害。
與瀑布模型相比，螺旋模型支持用戶需求的動態變化，爲用戶參與軟件開發的所有關鍵決策提供了方便，有助於提高目標軟件的適應能力，爲項目管理人員及時調整管理決策提供了便利，從而降低了軟件開發風險。
但是，不能說螺旋模型絕對比其他模型優越，事實上，螺旋模型也有其自身的缺點：
（1）採用螺旋模型，需要具有相當豐富的風險評估經驗和專業知識。在風險較大的項目開發中，如果未能及時標識風險，勢必會造成重大損失。
（2）過多的迭代次數會增加開發成本，延遲提交時間。
2.4 增量模型
演化模型的另一種形式是增量模型。在系統的技術架構成熟 、 風險較低的時候，可以採用增量的方式進行系統開發，這樣可以提前進行集成測試和系統測試，縮短初始版本的發佈週期，提高用戶對系統的可見度。
對於增量模型，通常有兩種策略。一是增量發佈的辦法。即首先做好系統的分析和設計工作，然後將系統劃分爲若干不同的版本，每一個版本都是一個完整的系統，後一版本以前一版本爲基礎進行開發，擴充前一版本的功能。在這種策略中，第一版本往往是系統的核心功能，可以滿足用戶最基本的需求，隨着增量的發佈，系統的功能逐步地豐富 、 完善起來。用戶在很短的時間內就可以得到系統的初始版本並進行試用。試用中的問題可以很快地反饋到後續開發中，從而降低了系統的風險。在應用增量模型中需要注意：
（1）每一個版本都是一個完整的版本。雖然最初的幾個增量不能完全地實現用戶需求，但這些版本都是完整的 、 可用的。
（2）版本間的增量要均勻，這一點是很重要的。如果第一個版本花費一個月的時間，而第二個版本需要花費6個月的時間，這種不均勻的分配會降低增量發佈的意義，需要重新調整。
另一種策略是原型法。同增量發佈不同，原型法的每一次迭代都經過一個完整的生命週期。當用戶需求很不明確或技術架構中存在很多不可知因素的時候，可以採用原型法。在初始的原型中，針對一般性的用戶需求進行快速實現，並不考慮算法的合理性或系統的穩定性。這個原型的主要目的是獲得精確的用戶需求，或驗證架構的可用性。一般情況下，會在後面的開發中拋棄這個原型，重新實現完整的系統。
2.5 構件組裝模型
隨着軟構件技術的發展，人們開始嘗試利用軟構件進行搭積木式的開發，即構件組裝模型。在構建組裝模型中，當經過需求分析定義出軟件功能後，將對構件的組裝結構進行設計，將系統劃分成一組構件的集合，明確構件之間的關係。在確定了系統構件後，則將獨立完成每一個構件，這時既可以開發軟件構件，也可以重用已有的構件，當然也可以購買或選用第三方的構件。構件是獨立的 、 自包容的，因此架構的開發也是獨立的，構件之間通過接口相互協作。
構件組裝模型的一般開發過程如圖 4 所示。
構件組裝模型的優點如下：
（1）構件的自包容性讓系統的擴展變得更加容易；
（2）設計良好的構件更容易被重用，降低軟件開發成本；
（3）構件的粒度較整個系統更小，因此安排開發任務更加靈活，可以將開發團隊分成若干組，並行地獨立開發構件。
魚與熊掌不可兼得，構件組裝模型也有明顯的缺點：
（1）對構件的設計需要經驗豐富的架構設計師，設計不良的構件難以實現構件的優點，降低構件組裝模型的重用度。
（2）在考慮軟件的重用度時，往往會對其他方面做出讓步，如性能等。
（3）使用構件組裝應用程序時，要求程序員熟練地掌握構件，增加了研發人員的學習成本。
（4）第三方構件庫的質量會最終影響到軟件的質量，而第三方構件庫的質量往往是開發團隊難以控制的。