軟件工程方法為目標計算機的軟件開發提供了一種有組織和系統的方法。有許多方法可供選擇，對于軟件工程師來說，為手頭的軟件開發任務選擇一種或幾種合適的方法是很重要的;這種選擇會對軟件項目的成功產生巨大的影響。使用這些軟件工程方法，加上具有適當技能集的人員和工具，使軟件工程師能夠可視化軟件的細節，并最終將表示轉換為代碼和數據的工作集。

下面將討論選定的軟件工程方法。主題區域被組織成啟發式方法、正式方法、原型方法和敏捷方法的討論。4.1啟發式方法

啟發式方法是那些基于經驗的軟件工程方法，它們已經在軟件行業中得到了相當廣泛的實踐。本主題包含三個廣泛的討論類別：結構化分析和設計方法、數據建模方法和面向對象的分析和設計方法。

結構化分析和設計方法：軟件模型主要從功能或行為的角度開發，從軟件的高級視圖（包括數據和控制要素）開始，然后通過越來越詳細的設計逐步分解或細化模型組件。詳細的設計最終集中于必須編碼（手工、自動生成或兩者同時生成）、構建、測試和驗證的軟件的非常具體的細節或規范。

數據建模方法：根據所使用的數據或信息的觀點構建數據模型。數據表和關系定義了數據模型。這種數據建模方法主要用于定義和分析支持數據庫設計或通常在業務軟件中發現的數據存儲庫的數據需求，在業務軟件中，數據作為業務系統資源或資產進行主動管理。

面向對象的分析和設計方法：面向對象模型表示為封裝數據和關系的對象集合，并通過方法與其他對象交互。對象可以是真實世界的項目，也可以是虛擬的項目。軟件模型是使用圖來構成軟件的選定視圖來構建的。軟件模型的逐步細化導致了詳細的設計。然后，詳細的設計要么通過連續的迭代進行演化，要么（使用某種機制）轉換為模型的實現視圖，其中表示最終軟件產品發布和部署的代碼和打包方法。

4.2正式的方法

形式方法是軟件工程方法，通過應用嚴格的基于數學的符號和語言來指定、開發和驗證軟件。通過使用規范語言，可以以系統的、自動化的或半自動化的方式檢查軟件模型的一致性（換句話說，缺少模糊性）、完整性和正確性。這個主題與軟件需求知識領域中的形式化分析部分有關。

本節討論規范語言、程序細化和派生、形式驗證和邏輯推理。

規范語言：規范語言為形式方法提供數學基礎;規范語言是在軟件規范、需求分析和/或設計階段用于描述特定輸入/輸出行為的正式的、高級的計算機語言（換句話說，不是經典的第三代語言（3GL）編程語言）。規范語言不是直接可執行的語言;它們通常由表示法和語法、使用表示法的語義和一組允許的對象關系組成。

程序優化和派生：程序優化是使用一系列轉換創建較低層面（或更詳細）規范的過程。軟件工程師是通過連續的轉換來獲得程序的可執行表示的?？梢约毣幏叮砑蛹毠?，直到模型可以用3GL編程語言或所選規范語言的可執行部分來表述。通過定義具有精確語義屬性的規范，可以實現規范的細化;規范不僅必須規定實體之間的關系，還必須規定這些關系和操作的確切運行時含義。

形式驗證：模型檢驗是一種形式驗證方法;它通常涉及執行狀態空間探索或可達性分析，以證明所表示的軟件設計具有或保留了某些感興趣的模型屬性。模型檢查的一個例子是在所有可能的事件或消息到達交叉情況下驗證正確的程序行為的分析。使用正式核證需要嚴格指定軟件模型及其運作環境;這個模型通常采用有限狀態機或其他正式定義的自動機的形式。

邏輯推理：邏輯推理是一種設計軟件的方法，它包括在設計的每個重要部分周圍指定前置條件和后置條件，并使用數學邏輯來證明這些前置條件和后置條件必須在所有輸入下都存在。這為軟件工程師在不執行軟件的情況下預測軟件行為提供了一種方法。一些集成開發環境（ide）包括在設計或代碼的同時表示這些證明的方法。

4.3原型化方法

軟件原型是一個活動，通常創建不完整或最低限度功能版本的軟件應用程序，通常為特定的新特性，征求反饋軟件需求或用戶接口，進一步探索軟件需求，軟件設計，或實現選項，和/或獲得其他一些有用的洞察軟件。軟件工程師首先選擇一種原型方法來理解軟件中最不被理解的方面或組件;這種方法與其他軟件工程方法形成對比，后者通常首先從最容易理解的部分開始開發。通常，如果不進行大量的開發重做或重構，原型產品不會成為最終的軟件產品。

本節簡要討論原型風格、目標和評估技術。原型風格：這解決了開發原型的各種方法。原型可以被開發為一次性代碼或紙制品，作為工作設計的演變，或作為可執行的規范。每種風格通常使用不同的原型生命周期過程。選擇的風格基于項目需要的結果類型、需要的結果的質量和結果的緊迫性。

原型目標：原型活動的目標是原型工作所服務的特定產品。原型化目標的例子包括需求規范、架構設計要素或組件、算法或人機用戶接口。

原型評估技術：一個原型可以由軟件工程師或其他項目利益攸關方以多種方式使用或評估，主要是由最初導致原型開發的潛在原因驅動的。原型可以根據實際實現的軟件或一組目標需求（例如，一個需求原型）來評估或測試;原型還可以作為未來軟件開發工作的模型（例如，在用戶接口規范中）。

4.4敏捷方法

敏捷方法誕生于20世紀90年代，當時人們需要減少大型軟件開發項目中使用的重量級的、基于計劃的方法所帶來的巨大開銷。敏捷方法被認為是輕量級的方法，因為它們的特點是短的、迭代的開發周期、自組織的團隊、更簡單的設計、代碼重構、測試驅動開發、頻繁的客戶參與，以及強調在每個開發周期中創建可演示的工作產品。

文獻中有許多敏捷方法;這里簡要討論一些比較流行的方法，包括快速應用程序開發（RAD）、極限編程（XP）、SCRum和功能驅動開發（FDD）。

RAD：快速軟件開發方法主要用于數據密集型的業務系統應用程序開發。RAD方法通過軟件工程師使用的專用數據庫開發工具來實現，這些工具用于快速開發、測試和部署新的或修改過的業務應用程序。

XP：這種方法使用需求的事例或場景，首先開發測試，讓客戶直接參與到團隊中（通常定義驗收測試），使用成對編程，并提供持續的代碼重構和集成。故事被分解為任務、劃分優先級、評估、開發和測試。軟件的每一個增量都通過自動化和手工測試進行測試;一個增量可能會被頻繁地釋放，比如每隔幾周左右。

SCRum：這種敏捷方法比其他方法對項目管理更友好。SCRum管理員管理項目增量中的活動;每個增量稱為沖刺，持續時間不超過30天。產品待辦事項列表（PBI）是根據任務來確定、定義、排序和評估的。在每個增量中測試并發布軟件的工作版本。每日SCRum會議確保工作按照計劃進行。

FDD：這是一種模型驅動的、短的、迭代的軟件開發方法，使用一個五階段過程：

（1） 開發一個產品模型來擴大領域的范圍，

（2） 創建需求或功能列表，

（3） 構建功能開發計劃，

（4）開發針對特定于迭代的功能的設計，以及

（5）代碼、測試、功能集成。

FDD類似于增量式軟件開發方法;它也類似于XP，除了代碼所有權被分配給個人而不是團隊。FDD強調軟件的整體架構方法，它促進在第一次就正確地構建特性，而不是強調持續的重構。

在文獻和實踐中還有許多敏捷方法的變體。請注意，重量級的、基于計劃的軟件工程方法和敏捷方法一樣都有一席之地。有一些新方法是從敏捷方法和基于計劃的方法的組合中產生的，從業者正在定義新的方法，這些方法主要基于當前的組織業務需求來平衡重量級和輕量級方法所需的特性。這些業務需求，通常由一些項目利益攸關方所代表，應該并且確實推動選擇使用一種軟件工程方法而不是另一種，或者從軟件工程方法組合的最佳特性中構建一種新方法。

責任編輯：haq