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