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