軟件開發方法是軟件開發方法學。

提供該方法的主要目的是提高軟件開發質量、降低軟件的成本。

系統學習軟件開發方法的步驟，主要有：

1、軟件生命周期

2、軟件開發模型

3、軟件重用技術

4、形式化開發方法。

軟件也有誕生和消亡，指軟件自開始構思與研發到不再使用消亡的過程。

對于軟件生命周期的劃分，不同的标準有不同的規定，如GB8566-88-軟件工程國家标準-計算機軟件開發規範将軟件分為了8個階段，具體如下：

l 可行性分析與計劃

通過可行性研究，來決定開發此軟件的必要性，可行性分析中确定軟件的目标、範圍、風險、開發成本等内容，從而制定初步的軟件研發計劃。

産出物《可行性分析報告》、《初步軟件研發計劃》

l 需求分析

确定軟件做成什麼樣

産出物《需求規格說明書》

l 概要設計

确定整個軟件的技術藍圖，根據需求内容從技術層面完成設計方案，主要确定系統的架構、子系統之間的關系、接口規約、數據庫模型、編碼規範等内容。

作為程序員的工作指南，共程序員了解系統的内部原理。

産出物《概要設計說明書》

l 詳細設計

從概要設計中進行細化。

産出物《詳細設計說明書》

l 研發實現

編碼和單元測試。

産出物源代碼。

l 集成測試

經過細心的組織，制訂集成測試計劃。

産出物《測試用例》、《測試報告》

l 确認測試

驗證軟件是否同需求一緻，是否達到了預期目标。

l 使用和維護

使用過程中會産生新的需求。同時軟件維護的過程會貫穿整個軟件的使用過程。

當使用和維護結束後，軟件系統也就自消亡，軟件系統的生命周期結束。

由于軟件進行大規模的開發時代，需要遵循一定的開發方法才能取得成功，這些模式化的方法稱之為開發模型。

核心思想：從一個特定的階段流向下一個階段。

該模型認為軟件開發是一個階段化的精确的過程。主要由需求分析、總體設計、詳細設計、編碼與調試、集成測試與系統測試，同時每個階段都會向上一個階段進行反饋缺陷，由上一個階段進行修正。

優點：分段明确，階段界限明确。

各個階段會産生完整的文檔，故也稱之後面向文檔的軟件開發模型。

當軟件需求明确、穩定時，可以采用瀑布模型按部就班地開發軟件，反之會暴露需求的缺陷、後期修改代價昂貴、難以控制開發的風險。

采用瀑布模型出現的缺陷無法避免，隻能争取在交付前發現更多的缺陷。所以測試成為了最關鍵的環節。【測試質量直接影響到時軟件的質量】，由此産生的瀑布V模型，提出更加強調測試。

1、完成需求分析之後進入總體設計外，還指向了系統測試，即将産生同軟件需求一緻的系統測試用例，同時軟件産品是否符合最初的需求将在系統測試階段得到驗證。

2、其它的以此類推。

瀑布V模型除了保持瀑布模式的階段文檔驅動的特點，而且更強調了軟件産品的驗證工作。

為若幹瀑布的叠代，根據不同的叠代特點可以深化為螺旋模型、增量模型和原型開發。

将瀑布模型與演化模型結果，不僅體現了兩個模型的優點，還強調了其他模型均忽略的風險分析。

螺旋模型包含4個階段：需求定義、風險分析、工程實現和評審，組成一次叠代。

基于瀑布模型的開發階段前，引入一個非常嚴格的風險識别、風險分析和風險控制，把項目拆解成一個一個的小項目，每個項目都标識一個或多個主要風險，直到所有的主要風險因素都被确定。

螺旋模型強調的是風險分析，适用于龐大而複雜、具有高風險的系統，及時地識别、分析、決定采取何種對策。

存在缺點：

1、需要具有相當豐富的風險評估經驗和專門知識，在風險較大的項目開發中，如果未能夠及時标識風險，勢必造成重大損失。

2、過多地叠代次數會增加開發成本，延遲提交時間。

主要用于系統的技術架構成熟、風險較低的時候，主要有兩種策略：

1、增量發布：首先做好分析和設計工作，然後将系統劃分為若幹不同的版本，每一個版本都是一個完整的系統。用戶可以在很短的時間内就可以得到系統的初始版本并試用，試用過程中進行反饋，降低項目風險，需要注意：

(1) 每一個版本都是完整的、可用的。

(2) 版本間增量要均勻，如一個月一次，不能存在一個版本為1個月，後一個片為4個月的情況。

2、原型法：每一次叠代都經過一次完整的生命周期，當用戶很不明确需求和技術架構時，存在很多不可知的因素，可采用原型法。

(1) 初始時針對一般用戶需求進行快速地實現，并不考慮算法的合理性或系統的穩定性。

(2) 主要目的是為了獲取精确的用戶需求，或驗證架構的可用性。

後期會抛棄原型法，重新實現完整的系統。

利用軟構建進行拱積木式的開發，即構件組裝模型。

定義軟件功能後，将對構件的組裝結構進行設計，将系統劃分成一組構件的集合，明确構建之間的關系。

構件是獨立的、自包容的，因此架構的開發也是獨立的，構件之間通過接口相互協作 。

優點：

1、構件的自包容性讓系統的擴展變得更加容易

2、設計良好的構件更容易被重用，降低軟件開發的成本。

3、粒度小時，可分為不同的若幹小組，獨立完成。

缺點：

1、對構件設計需要經驗豐富的架構師，設計不良的構件難以實現構件的優點

2、重用度時，性能會做出讓步

3、增加研發人員的學習成本

4、第三方構件的質量難以控制

統一開發過程（Unified Process, UP）是一種軟件過程，是一個優秀的軟件開發模型，提供了完整的開發過程解決方案，可以有效地降低軟件開發過程的風險。

UP是一個二維模型，時間主線就是橫軸的階段，主要經過初始、細化、構建和交付。

縱軸是按不同的階段進行的主要工作。

任何一個階段的工作都不是絕對的，都是相互交疊配合的，但每一個階段都有側重點：

初始階段：最重要的工作是界定系統範圍，明确系統目的，這一階段業務建模和需求工作成為重頭戲。

細化階段：開發者需要抽象出軟件的邏輯模型，設計出軟件的架構，這一階段分析工作是最主要的工程活動。

構件階段：開發者完成系統的構建，并進行測試和部署，這一階段實施和測試是最主要的活動。

交付階段：這一階段不可避免地要對軟件系統進行重構、修改、測試和部署。

縱軸而言，主要的工作流是：業務建模、需求、分析設計、實施、測試、部署、配置與變更管理、項目管理、環境稱為UP的核心工作流。可分為工程活動與管理活動，業務建模、需求、分析設計、實施、測試、部署為工程活動，配置與變更管理、項目管理、環境稱為管理活動。(其中環境，也稱環境管理，主要用于定義必需的工具、活動的指南、活動的流程規範、工作産品的模闆、基本的開發設施等 。

生命周期與時間主線階段一一對應，共有4個裡程碑：

1、目标裡程碑，對應先啟階段的結束，明确系統的目标和範圍即到達該裡程碑；

2、架構裡程碑，開發者需要确定穩定的系統架構；

3、能力裡程碑，已經足夠穩定和成熟，并完成Alpha測試；

4、發布裡程碑，需要完成系統的Beta測試、完成系統發布和用戶培訓等工作。

1、每一個階段都可以進行需求、設計等活動；

2、采用不同的叠代方式，可以演變為演化模型或增量模型；

3、更容易控制軟件開發的風險；

4、未經裁剪的UP是一個重載過程；

5、實際應用中，可根據具體問題對UP進行裁剪，從而使其可以适應各種規模的軟件和開發團隊。

1、建立系統架構模型

2、同需求人員和項目管理人員密切協作

3、細化軟件架構

4、保持整個架構的概念完整性

還需要定義設計方法、設計指南、編碼指南、評審設計等 工作，也有人稱UP是一個以架構師為中心的開發模型。

2001年2月發表《敏捷軟件開發宣言》，指出

1、盡早地、持續地向客戶交付有價值的軟件對開發人員來說最重要的；

2、擁抱變化

3、經常交付可工作的軟件

4、業務人員和開發人員緊密合作

5、滿足團隊人員的需求，并給予足夠的信任

6、面對面溝通

7、進度的度量方式

8、可持續的開發

9、不斷追求優秀的技術和良好的設計

10、最簡單，盡可能減少工作量

11、最好的架構、需求和設計 都來自于一個自我組織的團隊

12、團隊要定期的總結如何能夠更有效率，然後相應的自我調整

基于以上宣言，市場上共提出11種開發方法，如AD、AM、ASD、Crystal、FDD、DSDM、LSD、Scrum、TDD、XBreed、XP。

最常用的是XP（極限編程）。

XP為最成熟的一種，XP是一種輕量、高效、低風險、柔性、可預測、科學而且充滿樂趣的軟件開發方式。

1、在更短時間内，更早地提供具體、持續的反饋信息；

2、叠代地進行計劃編制，最開始迅速生成一個總體計劃

3、依賴自動測試程序來監控開發進度

4、依賴口頭交流、測試和源程序進行溝通

5、倡導持續的演化式的設計

6、依賴于開發團隊内部的緊密協作

7、盡可能達到程序員短期的利益和項目長期利益的平衡

由價值觀、原則、實踐和行為4部分組成。

一、四大價值觀

XP的核心是其總結溝通、簡單、反饋、勇氣4大價值觀。

1、溝通：項目中許多問題就出在缺乏溝通的開發人員身上，所以要求小組成員之間做到時持續的、無間斷的交流。鼓勵大家口頭交流、通過交流解決問題，提高效率。

2、簡單：提倡夠用就行，也就是盡量簡單化。

3、反饋：開發人員要注重反饋，通過持續、明确的反饋來暴露軟件狀态的問題。

4、勇氣：需要有勇氣面對快速開發，面對可能的重新開發。

二、12個最佳實踐

XP中集成了12個最佳實踐。

1、計劃遊戲：先快速的制定一個概要設計，随着細化不斷的清晰，再逐步完善這份計劃，産生的結果是一套用戶故事及後續的一兩次叠代的概要設計；

2、小型發布：“持續集成、小步快跑”，每一次發布的版本應該盡可能的小，前提條件是每個小版本有足夠的商業價值，值得發布。

3、隐喻：尋求共識、發明共享詞彙、創新的武器、描述架構。

4、簡單設計：認為設計不應該在編碼之前一次性完成。

5、測試先行

6、重構：一種對代碼進行改進，而不影響功能的實現技術；

7、結對編程：團隊協作、知識交流與共享

8、集體代碼所有制

9、持續集成

10、每周工作40小時

11、現場客戶

12、編碼标準

FDD方法也是一個叠代的開發模型，FDD的每一步強調質量，不斷地交付可運行的軟件，并以很小的開發提供精确的項目進度報告和狀态信息。

一、FDD的角色定義

三要素：人、過程和技術，6種關鍵性角色：

1、項目經理：

2、首席架構設計師

3、開發經理

4、主程序員

5、程序員

6、領域專家

二、核心過程

1、開發整體對象模型：業務建模的階段，強調全系統的完整的面向對象建模，需要領域專家和首席架構師相互配合，完成整體對象模型；

2、構造特征列表：所謂特征指的是一個小的、對客戶有價值的功能，采用動作、結果和目标來描述特征，特征的粒度最好把握在兩周之内，可以整理出系統的需求。

3、計劃特征開發：項目經理構造出特征列表、特征間的依賴關系進行計劃，安排開發任務；

4、特征設計：主程序員帶着特征小組特征進行詳細設計，為後面的構建做準備；

5、構建特征：實現

三、最佳實踐

組成FDD的最佳實踐包含：領域對象建模、根據特征進行開發、類的個體所有、組成特征小組、審查、定期構造、配置管理、結果的可見性。

利用已存在的軟件元素建立新的軟件系統，可以是軟件産品、源程序、也可以是文檔，甚至是領域知識。軟件重用可以提高軟件的開發效率、降低軟件的開發成本、縮短軟件的開發周期、提高軟件質量。

重用主要包含：源代碼重用、架構重用、應用框架的重用、業務建構的重用、文檔及過程的重用、軟構件的重用、軟件服務的重用。

兩個重要的特征：自包容和可重用。

指采用嚴格的數學方法，使用形式化規約語言來精确定義軟件系統。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!