軟體工程
 |
一位華夏公益教科書使用者認為此頁面應該拆分為更小的頁面，內容更窄。 您可以透過將此大頁面拆分為更小的頁面來提供幫助。請務必遵循命名策略。將書籍分成更小的部分可以提供更多的關注度，並允許每個部分專注於一件事，這對每個人都有利。 |
與其他書籍重疊：軟體工程導論
這本書的目的是將不同軟體工程主題的不同專案結合在一起。目前唯一連結的書籍是計算機程式設計。其他主題應該隨著時間的推移而被新增。
正如計算機程式設計書中所寫，編碼只是軟體工程的一小部分。本書旨在作為軟體工程領域的入門介紹。
一種系統的方法，用於分析、設計、實現和維護軟體。
軟體工程是開發軟體的工程學科。通常，這個過程包括找出客戶想要什麼，將其整理成一份需求清單，設計能夠支援所有需求的架構，設計、編碼、測試和整合各個部分，測試整體，部署和維護軟體。程式設計只是軟體工程的一小部分。
作為工程學科，該學科仍處於起步階段（增長/發展早期階段）。我們還沒有足夠的經驗，也沒有收集到足夠多的經驗資料來系統地理解和預測軟體專案的生命週期。
軟體工程知識體系（SWEBOK）將軟體工程分為10個知識領域
- 軟體需求
- 軟體設計
- 軟體構建
- 軟體測試
- 軟體維護
- 軟體配置管理
- 軟體工程管理
- 軟體工程過程
- 軟體工程工具和方法
- 軟體質量
注意：以下總結最初來自維基百科。這些只是暫時在這裡。標題不是最終的，此頁面上的任何內容都不是最終的（甚至接近最終的）。
在企業或工業部門中，軟體工程的實踐始於業務，並以業務結束。雖然計算機、程式語言和創造性問題解決是工程師對該領域感興趣的原因，但如果沒有服務和賦能使用者，這種練習將毫無意義。因此，任何軟體工程過程的第一階段都是願景和範圍文件，或一些類似的會議。
使用者或產品負責人描述了要構建的系統的願景。它將服務於的業務環境被描述。列出了主要利益相關者，包括他們的利益、風險等。列出了成功條件，以便了解將完成什麼以及如何衡量成功。
討論了商業機會，以證明為什麼要將程式設計師、測試人員、專案經理和專案經理的血汗和眼淚投入到這個專案中。專案的範圍變得清晰，如果它要分階段進行，則高層次地列出了每個階段的範圍。記錄了專案的優先順序。
瞭解了企業的願景後，工程師開始提問。
提取所需軟體產品的需求是建立它的第一步。這個過程被稱為需求獲取。雖然客戶可能認為他們知道軟體應該做什麼，但它可能需要軟體工程方面的技能和經驗來識別不完整、模稜兩可或矛盾的需求。
加劇這個問題的是正式抽象的缺乏。土木工程師、機械工程師有平面圖、立面圖、剖面圖可以參考，這些圖對這些抽象的作者和讀者都有意義。然而，雖然（E-R）或物件圖、流程圖、資料流圖是已被使用和構建的抽象，但其中許多並不被普遍使用或實踐。
此外，大量的精力用於修復和增強現有系統。這裡所需的工程是逆向工程和正向工程的混合，因為需求定義指的是一組已經存在的情況，而這些情況必須以明確的術語陳述。
也許，缺乏普遍接受的抽象使得軟體工程師的生活變得困難，有些人甚至認為軟體生產過程更接近藝術而不是工程！
最近，人們開始在不同程度的工作中使用原型。螢幕截圖和報表佈局是非工作原型，構成了原型製作的基本級別，並在可能的情況下內建了越來越高的複雜性。製作原型總是比不製作更費時。因此，這種做法並不總是被使用。
分析師的角色通常可以由三種類型的人來扮演。技術專案經理、軟體工程師或專門的分析師。在某些組織中，工程師認為他們會擔任分析師的角色是不可想象的，因為他們是“技術性的”，並且認為直接與客戶打交道是不可想象的。這純粹是一種文化立場，在公司和組織之間有所不同。軟體工程師與專案相關的業務人員和客戶密切合作也很常見，而這種程式設計師/分析師角色對專案的成功率非常有利。
在收集需求時，可以對它們進行分析。所討論的需求是否與其他需求衝突？它的優先順序是什麼？它從哪裡來？它是否需要進一步澄清？
分析是指從需求中推斷出結論，並以結構化的方式進行表示。結構本身可能根據分析物件的差異而有所不同。分析與需求收集之間很難劃清界限，因為它們在很多時候都使用相同的抽象概念。
有人可能會認為，分析會產生資料儲存結構和工作流程結構等等。然而，人們會認為這些並非是分析的唯一產出。
常見的技巧是，軟體需求分析從兩個或多個參與者之間的溝通開始。軟體開發人員和客戶都參與對軟體需求規格說明的評審。由於規格說明為設計和後續軟體工程活動奠定了基礎，因此在進行評審時應格外謹慎。評審首先在宏觀層面進行。在這個層面上，評審人員試圖確保規格說明完整、一致和準確。一旦評審完成，軟體需求規格說明就會由“客戶和開發人員雙方”簽署。
在需求分析階段，會遇到一些問題。這些問題被識別、定義並列在這裡。• 問題出在較小的系統中存在的問題，導致對開發軟體所涉及的活動優先順序重新定義。• 在需求階段的開始，客戶的需求存在於客戶組織中不同人員的腦海中。• 問題陳述的主要作用是客戶存在一個可能需要計算機解決方案來解決的問題。開發人員響應客戶的幫助請求。這裡還有一個問題是，從溝通到理解的路徑往往充滿了困難。
上述案例研究/問題是在“系統工程”中需求分析階段確定的。此頁面很快就會得到改進。--Ananthakumar Selvaraj (討論 • 貢獻) 2013年3月18日 (UTC) 13:02
一旦工程專案的願景和範圍確定，需求收集過程就開始了。用例集是客戶、分析師、開發人員和測試人員之間溝通的工具之一。用例通常具有名稱、簡短描述，以及使用者完成任務所需的步驟集。用例有時會分組在UML或其他形式的圖表中，描繪使用者、系統、外部實體和特定用例。
用例通常是粗粒度的，不會深入到系統的每個細節和功能需求。業務人員或軟體工程師應該能夠閱讀所有用例，並瞭解專案將交付的整個範圍。
敏捷驅動的專案可能會跳過這些用例，或者至少只記錄上面討論的屬性。計劃驅動的 методология 可能會為用例新增其他屬性，例如在涵蓋主要步驟後的備選路徑、將用例涵蓋的需求追溯到其來源，以及為每個用例提供錯誤處理部分。
分析階段
分析通常分兩個階段進行。第一階段，業務分析包括深入分析客戶當前的業務或製造流程和程式，著眼於如何透過自動化改進這些流程和程式。第二階段，系統分析包括對擬議改進進行審查，並就最適合完成這些改進的計算機環境和軟體技術提出建議。
業務分析階段
從對客戶當前環境的深入理解出發，業務分析師會建立一套“業務用例”，它們是簡要描述每個業務“參與者”在每個流程或程式中所扮演角色的描述。例如，餐廳的服務員可能有一個用例，如下所示：“A. 服務員走到顧客的桌子旁，自我介紹並背誦當天特價菜的介紹。B. 服務員遞送飲料選單，詢問顧客是否要點飲料。C. 如果是，服務員將每個顧客的訂單寫在飲料標籤上，然後前往酒吧區。D. 服務員將標籤遞給酒吧招待員，並在心中記下在正常時間內回頭檢視飲料訂單是否已經完成。E. 如果不是，服務員遞送晚餐選單，並幫助顧客進行選擇。當每個新的顧客就座時，服務員重複上述步驟，從步驟A開始。” 藉助像上面這樣的原始用例集，業務分析師可以與客戶協作，檢查每個用例如何實現自動化，並由此定義一個正式的系統需求，這個需求將成為定義未來軟體應用程式的數百個需求之一。可以推測，有效的業務分析師不僅要擁有豐富的商業世界經驗和知識，還要精通現代軟體系統提供的潛力，以及這些系統如何對映到商業世界的現實。
系統分析階段
分析過程的第二階段，系統分析從業務分析師奠定的基礎開始。從業務用例集及其產生的軟體需求出發，系統分析師會就最適合完成這些需求的軟體技術提出建議。在某些情況下，硬體環境會限制軟體技術的選擇。例如，在上面的餐廳場景中，客戶可能堅決要求為服務員提供手持裝置，以取代飲料標籤，並在飲料訂單準備好之前，無需跑到酒吧區。在這種情況下，系統分析師可能被迫使用僅在首選手持裝置上支援的作業系統和API。
一旦確定了程式設計和執行時環境，系統分析師就可以開始將業務用例和需求轉換成“系統用例”集，這些用例描述了參與者如何與擬議的系統互動。這些系統用例共同構成了軟體架構師用來開始佈局類或其他軟體模組的實際藍圖，這些模組將定義軟體編碼和開發過程的路線圖，該過程將緊隨其後。
規格說明是精確描述要編寫的軟體的任務，以數學上嚴格的方式進行描述。實際上，大多數成功的規格說明都是為了理解和微調已經開發得很好的應用程式而編寫的。對於必須保持穩定的外部介面，規格說明是最重要的。
一旦您收集了需求，並將它們捕獲到規格說明中，並且客戶同意該規格說明，就可以對專案需求進行快照或基線。這樣就可以管理現有需求並處理新需求。規格說明被置於配置管理下，例如像CVS這樣的工具，以便可以對需求進行版本控制和跟蹤。
拒絕不符合以下條件的需求非常重要：
- 不符合專案範圍
- 無法顯示投資回報率
- 不會使系統具有競爭力
- 技術上不可行
被拒絕的需求不需要進一步分析、實施、記錄或測試。每個需求都會給公司帶來成本，必須經過深思熟慮。
無論您的方法是敏捷還是計劃驅動，您都應該建立某種形式的變更控制來處理新的需求。如果未能做到這一點，可能會導致專案因範圍蔓延、專案超支、質量低下或成本過高而失敗。變更控制可以像開發經理審查規範一樣簡單，也可以像一個複雜的工具支援流程一樣複雜，該流程包含表格和具有變更控制權的委員會。
缺乏關於規範變更的溝通會導致開發人員、測試人員或分析人員浪費大量成本。在規範中更改一項需求所需的時間，其成本可能是實現該決定的工作時間的 100 倍。
設計與架構是指定軟體如何實際工作的活動。此階段通常被描述為分為兩個主要階段，可以描述為“業務設計”和“技術設計”。業務設計通常指定系統的“為什麼”，說明如何使用資料以及資料的流向。技術設計通常指定系統的“如何”，即其元件如何排列、其功能是什麼以及系統需要什麼樣的硬體。這兩個階段通常可以大致同時進行，業務設計通常先開始，技術設計最後結束。
在所有階段中，設計階段通常會佔用最多時間，許多工程師認為它是最重要的階段。即使在專案構建階段花費大量資源後，設計不良也會導致專案失敗。對於系統的設計和架構，必須做到足夠完整，以便可以對其進行驗證，然後將其用於開發系統。
將設計轉換為程式碼可能是軟體工程過程中最明顯的步驟，但它不一定是最大的部分。事實上，許多軟體工程師只參與分析和設計過程，然後將編碼工作交給計算機程式設計師來實現。這種趨勢在許多公司中越來越明顯，這些公司在國內僱傭軟體工程師，然後將實施工作外包給程式設計勞動力成本更低的國家。儘管有這種趨勢，許多軟體工程師仍然會經歷整個過程，並進行編碼以及設計。
測試的目的是不僅要證明程式碼按設計規範執行，還要證明程式碼在遇到未定義輸入時不會失敗。
有幾種型別的測試。單元測試測試一個程式碼模組的正確輸入、輸出和功能。系統測試測試軟體系統的所有模組。使用者驗收測試是一種系統測試形式，用於檢視系統不僅是否正常工作，還是否滿足業務使用者的需求。迴歸測試是在系統更改後進行的測試，以確保所有系統功能在更改後仍然存在。
為了執行系統和驗證測試，開發了用例。這些用例描述了使用者操作或系統的特定功能。這些用例在系統的構建階段非常有用，通常被指定為設計階段的可交付成果。用例通常被收集到測試指令碼中，這些指令碼以可複製的方式描述測試活動。這些指令碼可以由測試人員手動執行，也可以由自動測試軟體執行。
一般來說，行業慣例是系統測試和驗證由獨立的人員、團隊或部門，或者在某些情況下，由外部實體進行。測試被認為是一項專業技能，其技能組合與系統開發大不相同。通常認為，軟體開發人員測試自己的系統是一種不好的做法，因為他們可能會形成不全面測試系統的習慣，並且他們經常會繞過系統故障進行測試。
有不同型別的測試，例如白盒測試或黑盒測試。
一項重要的（而且經常被忽視的）任務是記錄軟體的內部設計和外部功能，以便於將來的維護和增強。
軟體文件非常重要。沒有文件，軟體將無法使用，因為終端使用者不知道如何操作程式。沒有文件，應用程式可能無法正確安裝在伺服器上，導致元件故障。文件對於外部介面最為重要。
軟體可以透過多種方式進行記錄，包括流程圖、部署指南、使用者手冊和維護手冊。
開發團隊成員可以編寫自己的文件，或者專業的技術作家可以編寫或編輯文件以提高可讀性和風格。
需要注意的是，測試應該在每個階段的結束時或期間進行。如果沒有做到這一點，傳遞到下一階段的輸入可能不完整。文件也可能不完整或不存在。
維護和增強軟體以應對新發現的問題或新需求，可能比最初開發軟體花費的時間要長得多。不僅可能需要新增不符合原始設計的程式碼，而且在軟體完成後的某個時刻確定軟體是如何工作的，可能需要軟體工程師付出相當大的努力。大約 2/3 的軟體工程工作是維護，但這一統計資料可能會產生誤導。其中一小部分是修復錯誤。大多數維護都是擴充套件系統以執行新功能，從許多方面來說，這可以被視為新工作。同樣，大約 2/3 的土木工程、建築和施工工作也是以類似的方式進行維護。
軟體工程過程因軟體型別而異。構建文字處理器與構建 3D 第一人稱射擊遊戲有不同的需求和設計方法。這些部分涵蓋了不同軟體型別的差異和獨特屬性。
伺服器軟體的軟體工程比臺式計算機的開發更加複雜。伺服器比普通消費系統更加複雜，具有更多需求和功能。伺服器軟體可以具有客戶端-伺服器架構以及集中式架構。伺服器軟體的開發和測試也與臺式軟體的開發和測試不同。並非每種程式語言都適合用於伺服器軟體的實現。總之，伺服器軟體中的 SE 需要特殊的
伺服器軟體比普通軟體更復雜的主要原因是，兩臺計算機（伺服器和客戶端）之間的通訊本身比同一臺計算機上執行的程式的各個部分之間的通訊更復雜且更容易出現故障。
為遊戲模擬設計軟體可能頗具挑戰，因為它需要軟體領域的豐富背景。例如，遊戲設計師可能需要編寫模擬物理的軟體，以及渲染三維影像的軟體。然而，遊戲行業的許多軟體工程師能夠使用第三方引擎，這使得他們的工作變得更加容易。儘管如此，他們必須嚴格遵循軟體工程流程，因為軟體中微小的錯誤可能會導致產品在消費者市場上失敗。為遊戲編寫軟體是一個高風險行業，只有少部分遊戲在經濟上取得成功。
與嵌入式計算機系統打交道的軟體工程師需要比大多數軟體工程師更瞭解硬體，因為與遊戲 PC 相比，嵌入式系統通常對記憶體可用性和處理能力有更多限制。為嵌入式系統設計軟體確實可能具有挑戰性，因為大多數嵌入式處理器無法處理編譯高階語言產生的開銷。這經常迫使軟體工程師至少部分地在組合語言中實現嵌入式軟體。