軟體工程/過程/方法論簡介

在軟體工程中，軟體開發方法論或系統開發方法論是一個用於構建、規劃和控制資訊系統開發過程的框架。

歷史

軟體開發方法論框架直到1960年代才出現。根據Elliott (2004)的說法，系統開發生命週期 (SDLC) 可以被認為是最古老的用於構建資訊系統的正式化方法論框架。SDLC 的主要思想是“以非常謹慎、結構化和有條理的方式追求資訊系統的開發，要求生命週期的每個階段，從想法的產生到最終系統的交付，都必須以嚴格和順序的方式執行”。在應用框架的上下文中。這種方法論框架在1960年代的主要目標是“在大型企業集團時代開發大型功能性業務系統。資訊系統活動圍繞著大量資料處理和數字運算例程”。

作為名詞

作為名詞，軟體開發方法論是一個用於構建、規劃和控制資訊系統開發過程的框架——這包括對專案團隊為開發或維護應用程式而建立和完成的特定交付成果和工件的預定義。

應用於軟體開發方法論框架的三種基本方法。

多年來，各種各樣的框架不斷發展，每個框架都有自己公認的優點和缺點。一個軟體開發方法論框架不一定適合所有專案使用。每個可用的方法論框架最適合特定型別的專案，這取決於各種技術、組織、專案和團隊方面的考慮。

這些軟體開發框架通常與某種組織繫結，該組織進一步開發、支援使用和推廣方法論框架。方法論框架通常在某種正式文件中定義。特定的軟體開發方法論框架（名詞）包括

• 自1998年以來的Rational Unified Process (RUP, IBM)。
• 自2005年以來由Scott Ambler提出的Agile Unified Process (AUP)。

作為動詞

作為動詞，軟體開發方法論是組織和專案團隊應用軟體開發方法論框架（名詞）的一種方法。特定的軟體開發方法論（動詞）包括

1970年代

• 自1969年以來的結構化程式設計
• Cap Gemini SDM，最初來自PANDATA，第一個英文翻譯版本於1974年出版。SDM代表系統開發方法論

1980年代

• 自1980年以來的結構化系統分析與設計方法論 (SSADM)
• 資訊需求分析/軟系統方法論

1990年代

• 面向物件程式設計 (OOP) 自1960年代初開始發展，並在1990年代中期發展成為一種主要的程式設計方法
• 自1991年以來的快速應用開發 (RAD)
• 自1990年代末以來的Scrum
• 由Watts Humphrey在SEI開發的團隊軟體過程
• 自1999年以來的極限程式設計

動詞方法

每個軟體開發方法論框架都作為應用特定方法來開發和維護軟體的基礎。自資訊科技起源以來，已經使用了多種軟體開發方法。這些方法包括：

• 瀑布模型：一種線性框架
• 原型設計：一種迭代框架
• 增量：一種組合的線性迭代框架
• 螺旋式：一種組合的線性迭代框架
• 快速應用開發 (RAD)：一種迭代框架
• 極限程式設計

瀑布式開發

瀑布模型是一種順序開發方法，其中開發被視為穩定地向下流動（像瀑布一樣）透過需求分析、設計、實現、測試（驗證）、整合和維護的階段。該方法的第一個正式描述通常被引用為 Winston W. Royce 於 1970 年發表的一篇文章 ，儘管 Royce 在這篇文章中沒有使用“瀑布”這個詞。

基本原理是：

• 專案被分成順序階段，在階段之間允許一些重疊和回溯。
• 重點在於規劃、時間表、目標日期、預算和一次性實施整個系統。
• 透過廣泛的書面文件、正式審查以及使用者和資訊科技管理部門在大多數階段結束前開始下一個階段之前進行的批准/簽署，對專案生命週期進行嚴格控制。

原型設計

軟體原型設計，是在軟體開發過程中進行活動的一種開發方法，即建立原型，即正在開發的軟體程式的未完成版本。

基本原理是：

• 不是獨立的完整開發方法論，而是一種處理更大、更傳統開發方法論（例如增量、螺旋式或快速應用開發 (RAD)）中選定部分的方法。
• 試圖透過將專案分解成更小的部分並在開發過程中提供更多易於更改的方式來降低固有的專案風險。
• 使用者在整個開發過程中都參與其中，這增加了使用者接受最終實施的可能性。
• 按照迭代修改過程開發系統的縮略模型，直到原型演變到滿足使用者的需求。
• 雖然大多數原型都是為了被丟棄而開發的，但在某些情況下，可以從原型演變到工作系統。
• 對基本業務問題的基本瞭解對於避免解決錯誤的問題是必要的。

增量開發

各種方法都可以接受，用於組合線性系統和迭代系統開發方法論，每個方法的主要目標都是透過將專案分解成更小的部分並在開發過程中提供更多易於更改的方式來降低固有的專案風險。

基本原理是：

• 執行一系列迷你瀑布，其中系統的某個小部分完成了瀑布的所有階段，然後繼續到下一個增量，或者
• 在進行系統的單個增量的演化式、小型瀑布式開發之前，將定義總體需求，或者
• 透過瀑布式方法定義初始軟體概念、需求分析以及架構和系統核心設計，然後進行迭代式原型設計，最終安裝最終原型，即一個可工作的系統。

螺旋式開發

螺旋模型。

螺旋模型是一種軟體開發過程，它結合了設計和分階段原型設計的元素，旨在結合自頂向下和自底向上概念的優勢。

基本原理是：

• 重點是風險評估，透過將專案分解成更小的部分並在開發過程中提供更高的易變性來最大程度地降低專案風險，同時提供機會評估風險並在整個生命週期中權衡專案持續的考慮因素。
• “每個週期都涉及透過相同的步驟序列進行進展，對於產品的每個部分及其每個精細程度，從整體操作概念文件到每個單獨程式的編碼”。
• 繞螺旋的每次迴圈都會遍歷四個基本象限：(1)確定迭代的目標、備選方案和約束；(2)評估備選方案；識別和解決風險；(3)開發和驗證迭代的可交付成果；以及(4)計劃下一次迭代。
• 每個週期都以識別利益相關者及其成功條件開始，並在每個週期結束時進行審查和承諾。

快速應用開發

快速應用開發 (RAD) 是一種軟體開發方法，它涉及迭代開發和原型構建。快速應用開發是最初用來描述詹姆斯·馬丁在 1991 年引入的一種軟體開發過程的術語。

基本原理是：

• 主要目標是以相對較低的投資成本快速開發和交付高質量系統。
• 試圖透過將專案分解成更小的部分並在開發過程中提供更多易於更改的方式來降低固有的專案風險。
• 旨在快速生產高質量系統，主要透過迭代式原型設計（在開發的任何階段）、積極的使用者參與和計算機化開發工具。這些工具可能包括圖形使用者介面 (GUI) 構建器、計算機輔助軟體工程 (CASE) 工具、資料庫管理系統 (DBMS)、第四代程式語言、程式碼生成器和麵向物件技術。
• 重點是滿足業務需求，而技術或工程卓越性則不那麼重要。
• 專案控制涉及優先考慮開發並定義交付期限或“時間箱”。如果專案開始出現問題，重點是減少需求以適應時間箱，而不是延長期限。
• 通常包括聯合應用設計 (JAD)，其中使用者透過結構化研討會或電子協作來積極參與系統設計，達成共識。
• 積極的使用者參與至關重要。
• 迭代地生成生產軟體，而不是一次性原型。
• 生成必要的文件以促進未來的開發和維護。
• 標準系統分析和設計方法可以融入到這個框架中。

其他實踐

其他方法實踐包括

• 面向物件開發方法，例如格雷迪·布奇的面向物件設計 (OOD)，也稱為面向物件分析和設計 (OOAD)。布奇模型包括六個圖：類圖、物件圖、狀態轉換圖、互動圖、模組圖和過程圖。
• 自頂向下程式設計：由 IBM 研究員哈蘭·米爾斯（和尼克勞斯·維爾特）在 20 世紀 70 年代發展起來的結構化程式設計。
• 統一過程 (UP) 是一種迭代軟體開發方法框架，基於統一建模語言 (UML)。UP 將軟體的開發組織成四個階段，每個階段包含一個或多個在該開發階段可執行的軟體迭代：初始階段、細化階段、構建階段和指導階段。許多工具和產品存在於促進 UP 實施。UP 的一個更流行的版本是 Rational Unified Process (RUP)。
• 敏捷軟體開發是指一組基於迭代開發的軟體開發方法，其中需求和解決方案透過自組織的跨職能團隊之間的協作來發展。該術語是在 2001 年制定敏捷宣言時創造的。
• 整合軟體開發是指一個基於可交付成果的軟體開發框架，使用三種主要的 IT（專案管理、軟體開發、軟體測試）生命週期，這些生命週期可以使用多種（迭代式、瀑布式、螺旋式、敏捷式）軟體開發方法，其中需求和解決方案透過自組織的跨職能團隊之間的協作來發展。

軟體開發過程發展各種處理因此，軟體開發不是一項容易的任務，它涉及各種處理。根據 IBM 研究：”軟體開發是指專門用於該過程的一組計算機科學活動。

建立 設計 部署 支援 軟體

子主題

檢視模型

TEAF 檢視和視角矩陣。

檢視模型是一個框架，它提供了關於系統及其環境的觀點，用於軟體開發過程。它是一種圖形表示，代表了檢視的底層語義。

觀點和檢視的目的是使人類工程師能夠理解非常複雜的系統，並將問題和解決方案的元素組織到專業領域。在對物理密集型系統進行工程設計時，觀點通常對應於工程組織內的能力和職責。

大多數複雜的系統規範都非常廣泛，以至於沒有一個人能夠完全理解規範的所有方面。此外，我們每個人對特定系統都有不同的興趣，以及檢查系統規範的不同原因。企業高管提出的系統構成問題與系統實施者提出的問題不同。因此，觀點框架的概念是為了提供對特定複雜系統的規範的不同觀點。這些觀點都滿足了對系統某些方面感興趣的受眾。與每個觀點相關聯的是一種觀點語言，它優化了該觀點受眾的詞彙和表示。

業務流程和資料建模

當前資訊狀態的圖形表示為使用者和系統開發人員提供了一種非常有效的資訊呈現方式。

業務流程和資料模型之間互動的示例。

• 業務模型說明了與所建模業務流程相關的功能以及執行這些功能的組織。透過描繪活動和資訊流，可以建立基礎來視覺化、定義、理解和驗證流程的性質。
• 資料模型提供了要儲存的資訊的詳細資訊，在最終產品是為應用程式生成計算機軟體程式碼或準備功能規範以幫助計算機軟體做出製造或購買決策時，主要使用資料模型。有關業務流程和資料模型之間互動的示例，請參見右側的圖。

通常，在進行稱為業務分析的訪談後建立模型。訪談包括主持人提出一系列問題，旨在提取描述流程所需的資訊。面試官被稱為主持人，以強調資訊是由參與者提供的。主持人應該對感興趣的流程有一定的瞭解，但這不像擁有一個結構化的提問方法來詢問流程專家那樣重要。方法很重要，因為通常有一組主持人正在收集整個設施的資訊，並且一旦完成，所有面試官的資訊結果必須相互匹配。

模型的開發用於定義流程的當前狀態，在這種情況下，最終產品稱為“現狀”快照模型，或者是一組關於流程應該包含哪些內容的想法的集合，從而形成一個“可能是什麼”模型。流程和資料模型的生成可用於確定現有的流程和資訊系統是否健全，只需要進行一些小的修改或增強，或者是否需要進行重新設計作為糾正措施。建立業務模型不僅僅是一種檢視或自動化資訊流程的方式。分析可以用來從根本上改變您的企業或組織開展業務的方式。^[9]

計算機輔助軟體工程

計算機輔助軟體工程 (CASE)，在軟體工程領域，是指將一套工具和方法科學地應用於軟體，從而產生高質量、無缺陷且可維護的軟體產品。^[10] 它也指開發資訊系統的方法以及可以在軟體開發過程中使用的自動化工具。^[11] 術語“計算機輔助軟體工程”(CASE) 可以指用於自動化開發系統軟體（即計算機程式碼）的軟體。CASE 功能包括分析、設計和程式設計。CASE 工具自動化了在所需程式語言中設計、記錄和生成結構化計算機程式碼的方法。^[12]

計算機輔助軟體系統工程 (CASE) 的兩個關鍵理念是：^[13]

• 在軟體開發和/或軟體維護過程中促進計算機輔助，以及
• 對軟體開發和/或維護的工程化方法。

典型的 CASE 工具用於配置管理、資料建模、模型轉換、重構、原始碼生成和統一建模語言。

整合開發環境

Anjuta，一個用於 GNOME 環境的 C 和 C++ IDE

整合開發環境 (IDE) 也稱為整合設計環境或整合除錯環境，是一種軟體應用程式，為計算機程式設計師提供全面的軟體開發設施。IDE 通常由以下部分組成：

• 原始碼編輯器，
• 編譯器和/或直譯器，
• 構建自動化工具，以及
• 偵錯程式（通常）。

IDE 的設計目的是透過提供緊密結合的元件（具有相似的使用者介面）來最大限度地提高程式設計師的生產力。通常，IDE 專注於特定程式語言，以便提供最符合該語言程式設計正規化的功能集。

建模語言

建模語言是指任何可以用它來表達資訊或知識或系統的人工語言，其結構由一組一致的規則定義。這些規則用於解釋結構中元件的含義。建模語言可以是圖形化的或文字化的。^[14] 圖形建模語言使用帶有名稱的符號來表示概念，使用連線符號的線來表示關係，以及各種其他圖形註釋來表示約束。文字建模語言通常使用標準化關鍵字以及引數來建立可由計算機解釋的表示式。

軟體工程領域中圖形建模語言的示例包括

• 業務流程建模符號 (BPMN) 以及 XML 格式的 BPML 是流程建模語言的一個例子。
• EXPRESS 和 EXPRESS-G (ISO 10303-11) 是國際標準通用資料建模語言。
• 擴充套件企業建模語言 (EEML) 通常用於跨層業務流程建模。
• 流程圖是演算法或逐步過程的示意性表示，
• 基本建模概念 (FMC) 用於軟體密集型系統的建模語言。
• IDEF 是一系列建模語言，其中最著名的是 IDEF0 用於功能建模，IDEF1X 用於資訊建模，IDEF5 用於本體建模。
• LePUS3 是一種面向物件的視覺設計描述語言和正式規範語言，主要適用於大型面向物件（Java、C++、C#）程式和設計模式的建模。
• 規範和描述語言 (SDL) 是一種規範語言，針對的是對反應式和分散式系統的行為進行明確的規範和描述。
• 統一建模語言 (UML) 是一種通用建模語言，是用於規範軟體密集型系統的行業標準。UML 2.0 是當前版本，支援 13 種不同的圖表技術，並且擁有廣泛的工具支援。

並非所有建模語言都是可執行的，對於那些可執行的語言來說，使用它們並不一定意味著程式設計師不再需要了。相反，可執行建模語言旨在提高熟練程式設計師的生產力，以便他們能夠解決更困難的問題，例如平行計算和分散式系統。

程式設計正規化

程式設計正規化是計算機程式設計的基本風格，與軟體工程方法論形成對比，軟體工程方法論是解決特定軟體工程問題的風格。正規化在用於表示程式元素（如物件、函式、變數、約束……）的概念和抽象以及構成計算的步驟（賦值、求值、延續、資料流……）方面有所不同。

一種程式語言可以支援多種正規化。例如，用 C++ 或 Object Pascal 編寫的程式可以是純粹的過程式的，也可以是純粹的面向物件的，或者包含兩種正規化的元素。軟體設計師和程式設計師決定如何使用這些正規化元素。在面向物件程式設計中，程式設計師可以將程式視為相互互動的物件的集合，而在函數語言程式設計中，程式可以被認為是一系列無狀態函式求值。在對具有多個處理器的計算機或系統進行程式設計時，面向過程的程式設計允許程式設計師將應用程式視為一組作用於邏輯上共享的資料結構的併發程序。

正如軟體工程中不同的群體提倡不同的方法論一樣，不同的程式語言也提倡不同的程式設計正規化。有些語言是為了支援一種正規化而設計的（Smalltalk 支援面向物件程式設計，Haskell 支援函數語言程式設計），而其他程式語言則支援多種正規化（例如 Object Pascal、C++、C#、Visual Basic、Common Lisp、Scheme、Python、Ruby 和 Oz）。

許多程式設計正規化因其禁止的方法而聞名，就像因其允許的方法而聞名一樣。例如，純函數語言程式設計禁止使用副作用；結構化程式設計禁止使用 goto 語句。部分由於這個原因，習慣於早期風格的人往往將新的正規化視為教條主義或過於僵化。^{citation needed} 避免使用某些方法可以更容易地證明關於程式正確性的定理，或者只是更容易理解程式的行為。

軟體框架

軟體框架是軟體系統或子系統的可重用設計。軟體框架可能包括支援程式、程式碼庫、指令碼語言或其他軟體，以幫助開發和粘合軟體專案的不同元件。框架的各個部分可以透過 API 公開。

軟體開發流程

軟體開發流程是強加於軟體產品開發的框架。同義詞包括軟體生命週期和軟體流程。有幾種這樣的流程模型，每種模型都描述了在流程過程中進行的各種任務或活動的方法。

越來越多的軟體開發組織實施流程方法論。其中許多組織來自國防行業，在美國，國防行業需要根據“流程模型”進行評級才能獲得合同。描述選擇、實施和監控軟體生命週期的國際標準是 ISO 12207。

一個長期的目標是找到可重複、可預測的流程，以提高生產力和質量。一些人試圖將編寫軟體的看似雜亂無章的任務系統化或形式化。另一些人則將專案管理方法應用於編寫軟體。如果沒有專案管理，軟體專案很容易延期或超支。由於大量軟體專案在功能、成本或交付進度方面沒有達到預期，有效的專案管理似乎是缺失的。

另請參閱

列表

• 軟體工程主題列表
• 軟體開發理念列表

相關主題

• 領域特定建模
• 輕量級方法論
• 物件建模語言
• 結構化程式設計
• 整合 IT 方法論

外部連結

• 選擇開發方法 在 cms.gov。
• 軟體方法論書籍評論 一套關於軟體方法論和流程的廣泛書籍評論