一、軟件工程概述

軟件工程的誕生

1968年北大西洋公約組織的計算機科學家在聯邦德國召開國際會議，討論軟件危機問題。在這次會議上正式提出并使用了“軟件工程”這個名詞，一門新興的工程學科就此誕生了。

軟件危機

① 對軟件開發成本和進度的估計常常很不準確。

② 用戶對“已完成的”軟件系統不滿意的現象經常發生。

③ 軟件產品的質量往往靠不住。

④ 軟件常常是不可維護的。

⑤ 軟件通常沒有適當的文檔資料。

⑥ 軟件成本在計算機系統總成本中所占的比例逐年上升。

⑦ 軟件開發生產率提高的速度，既跟不上硬件的發展速度，也遠遠跟不上計算機應用迅速普及深入的趨勢。

產生原因：一方面與軟件本身的特點有關，另一方面也和軟件開發與維護的方法不正確有關。

重要的原因之一：在軟件開發的不同階段進行修改需要付出的代價是很不相同的。在早期引入變動，涉及的面較少，因而代價也比較低；在開發的中期，軟件配置的許多成分已經完成，引入一個變動要對所有已完成的配置成分都做相應的修改，不僅工作量大，而且邏輯上也更復雜，因此付出的代價劇增；在軟件“已經完成”時再引入變動，當然需要付出更高的代價。

軟件是程序、數據及相關文檔的完整集合。

1983 年 IEEE（電氣和電子工程師協會）為軟件下的定義是：計算機程序、方法、規則、相關的文檔資料以及在計算機上運行程序時所必需的數據。

七條基本原理

①用分階段的生命周期計劃嚴格管理

②堅持進行階段評審

③實行嚴格的產品控制

④采用現代程序設計技術

⑤結果應能清楚地審查

⑥開發小組的人員應該少而精

⑦承認不斷改進軟件工程實踐的必要性

十大領域

①軟件需求（software requirements）

②軟件設計（software design）

③軟件構建（software construction）

④軟件測試（software testing）

⑤軟件維護（software maintenance）

⑥軟件配置管理（software configuration management）

⑦軟件工程管理（software engineering management）

⑧軟件工程過程（software engineering process）

⑨軟件工程工具和方法（software engineering tools and methods）

⑩軟件質量（software quality）

問題

一、什么是軟件？有何特點？

目前對軟件比較公認的解釋是：軟件是程序，支持程序運行的數據以及與程序有關的文檔的完整集合。

• 程序：按事先設計的功能和性能要求執行的指令序列
• 文檔：與程序開發，維護和使用有關的圖文材料
  • 文檔分為三大類：開發文檔、用戶文檔、管理文檔
  • 文檔的作用：記錄、通信和交流、管理和維護
• 數據：使程序能正常操縱信息的數據結構

軟件的特點：

• 軟件是邏輯的，而不是物理的產品
• 軟件是由開發化或者工程化形成的，沒有明顯的制造過程
• 軟件在運行和使用期間，不存在硬件那樣的磨損和老化問題，但存在退化問題，所以需要維護軟件
  • 軟件的故障率是由于軟件修改呈現鋸齒狀，因為軟件修改可能帶來新的錯誤
• 大多數軟件是自定的，軟件開發尚未完全擺脫手工的方式
• 軟件成本相當昂貴
• 軟件本身比較復雜

二、什么是軟件危機？如何解決？

軟件危機（Software Crisis），所謂軟件危機，就是指在軟件開發和軟件維護過程中所存在的一系列嚴重問題。

軟件危機的表現：

• 軟件開發沒有計劃性
• 對于軟件需求的獲取不充分
• 缺乏良好的軟件質量的評測手段
• 軟件的可復用性、可維護性不如人意
• 軟件開發過程沒有“規范化”
• 軟件開發的人力成本持續上升
• 缺乏自動化的軟件開發技術

解決軟件危機：

基于軟件危機產生的角度，應該從兩個方面來解決軟件危機：軟件工程技術和軟件工程管理

• 管理層面上考慮：應當注意推廣和使用在實踐中總結出來的開發軟件的成功的技術和方法，并且探索更好的、更有效的技術和方法，注意積累軟件開發過程中的經驗數據財富，逐步消除在計算機系統早期發展階段形成的一些錯誤概念和做法
• 從技術角度考慮：應當開發和使用更好的軟件開發工具，提高軟件開發效率和開發工作過程的規范化程度
  • 目前廣為使用的統一建模語言(UML)、各種配置管理工具、缺陷管理工具和自動測試工具都在軟件工程活動中發揮了很好的作用

三、軟件工程是一門什么學科？

研究“大型”軟件開發和維護的技術、方法、工具、環境和管理的工程學科。

軟件工程是指導計算機軟件開發和維護的工程學科。它采用工程的概念、原理、技術和方法來開發與維護軟件，把經過時間考驗而證明是正確的管理技術和當前能夠得到的最好的技術方法結合起來，以經濟地開發出高質量的軟件并有效地維護它。

軟件工程三要素：工具、方法、過程

軟件工程的內容：軟件開發的技術、軟件開發的管理、軟件過程管理技術

四、什么是軟件工程方法學？

通常把在軟件生命周期全過程中使用的一整套技術方法的集合稱為方法學，也稱為范型

包括傳統方法、面向對象的方法、形式化方法

五、什么是軟件的生存期？

軟件產品從形成概念開始，經過開發、使用和維護，直到最后退役的全過程。

劃分軟件周期的目的：給每個階段賦予確定而有限的任務，能夠簡化每一步的工作內容，使軟件復雜性變得較易控制和管理

軟件生存期的三個階段、六個時期：

• 定義時期
  • 軟件計劃（可行性研究）
  • 需求分析
• 開發時期
  • 軟件設計
  • 實現（編碼）
  • 測試
• 使用和維護時期
  • 運行維護

六、軟件工具包含哪些？

軟件工具是指能支持軟件生存周期中的某一階段（如軟件計劃、需求分析、軟件設計、編碼、測試、運行維護等）的需要而使用的軟件工具。

一般按照軟件過程的活動來分類：①支持軟件開發過程的工具；②支持軟件維護過程的工具；③支持軟件管理過程和支持過程的工具

二、軟件過程

軟件工程過程是為了獲得高質量軟件所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。

當開發產品或構建系統時，遵循一系列可預測的步驟（路線圖）是非常重要的，它有助于及時交付高質量的產品；其中所遵循的路線圖就是軟件過程。

軟件過程的任務

• 軟件過程貫穿軟件開發的各階段，并建立階段里程碑 （Milestones）；
• 管理者在軟件工程過程中需要對軟件開發的質量、進度、 成本進行評估、管理和控制；
• 技術人員在軟件過程中需采用相應的方法和工具生成軟件工程產品，如模型、文檔、數據、報告、表格等

軟件過程的組成要素

軟件過程是工作產品構建時所執行的一系列活動、動作和任務的集合。

• 活動(activity)：實現寬泛的大目標
• 動作(action)：階段目標
• 任務(task)：關注小而明確的目標，產生實際產品

軟件生命周期的基本任務

軟件生命周期由軟件定義、軟件開發和運行維護3個時期組成，每個時期又可進一步劃分成若干個階段。

軟件定義：問題定義、需求分析、可行性研究

軟件開發：概要設計、詳細設計、編碼和單元測試、綜合測試

運行維護時期的主要任務是使軟件持久地滿足用戶的需要

問題定義階段必須回答的關鍵問題是：“要解決的問題是什么”。可行性研究階段要回答的關鍵問題是：“上一個階段所確定的問題是否有行得通的解決辦法”。需求分析的任務仍然不是具體地解決客戶的問題，而是準確地回答“目標系統必須做什么”這個問題。概要設計階段的基本任務是：概括地回答“怎樣實現目標系統？”概要設計又稱為初步設計、邏輯設計、高層設計或總體設計。詳細設計階段的任務就是把解法具體化，也就是回答“應該怎樣具體地實現這個系統”這個關鍵問題。編碼和單元測試階段的關鍵任務是寫出正確的，容易理解、容易維護的程序模塊。綜合測試階段的關鍵任務是通過各種類型的測試（及相應的調試）使軟件達到預定的要求。軟件維護階段的關鍵任務是，通過各種必要的維護活動使系統持久地滿足用戶的需要。

我國國家標準《計算機軟件開發規范》（GB8566——88）也把軟件生命周期劃分成8個階段，這些階段是：可行性研究與計劃，需求分析，概要設計，詳細設計，實現，組裝測試，確認測試，使用和維護。其中，實現階段即是編碼與單元測試階段，組裝測試即是集成測試，確認測試即是驗收測試。

問題

一、軟件過程的含義？

• 當開發產品或構建系統時，遵循一系列可預測的步驟（路線圖）是非常重要的，它有助于及時交付高質量的產品；其中所遵循的路線圖就是軟件過程

二、軟件過程中有哪些共同的、基本的活動？

• 一個通用的軟件工程過程框架通常會包含以下5個基本的框架活動：
  • 溝通：在技術工作開始前，先和利益相關者進行溝通與協作，以理解項目目標，并收集需求
  • 策劃：制定項目計劃，包括需要執行的技術任務、可 能的風險、資源需求、工作產品、工作進度計劃等
  • 建模：構思軟件的體系結構、構件如何結合等
  • 構建：包括編碼和測試
  • 部署：交付全部軟件或部分增量，由用戶使用并反饋 意見。

三、如何建立過程模型？什么是過程模式？

• 軟件過程常使用“過程模型”來表述
  • 一個通用的軟件過程模型，包括以下工作：
  • 選擇一種過程流。
  • 定義框架活動：針對給定的問題、開發人員和利益相 關者，制定每個框架活動中需要完成哪些動作。
    • 例如在溝通活動中，可能包括啟動、需求獲取、需求系統、 談判、規格說明、確認等動作。
  • 明確任務集：為每個動作制定所需要的任務集
    • 任務集由工作任務、相關工作產品、質量保證點和項目里程 碑等部分組成
    • 對于不同的軟件項目，即便是相同的動作，確定的任務集也可能不一樣。
  • 編寫或查找過程模式。
• 開發團隊在軟件過程里會遇到很多問題，如果團隊能得到已有的經過驗證的解決方案，將有助于快速地分析和解決問題。
• 因此在軟件過程中，最好能將遇到的過程問題、問題環境、解決方案等記錄下來，形成過程模式(process pattern)。

四、 慣用（傳統）過程模型

• 軟件工程發展到現在，已經出現了很多不同的過程模 型，其中有一些可歸屬為“傳統過程模型”

• 傳統過程模型以秩序和一致性作為主要問題，規定了 一整套的過程元素，包括：過程流、框架活動、軟件 工程動作、任務、工作產品、質量保證、變更控制機制等。

• 常見的幾種傳統過程模型：瀑布模型、V模型、增量過程模型、原型開發模型、螺旋模型、協同模型

• 瀑布模型：前提：需求穩定而明確、由文檔驅動、前一階段的結果是后一階段的輸入、推遲了軟件實現、現實開發中添加反饋機制、階段評審和文檔控制

  • （1）階段間具有順序性和依賴性

    這個特點有兩重含義：①必須等前一階段的工作完成之后，才能開始后一階段的工作；②前一階段的輸出文檔就是后一階段的輸入文檔。

    （2）推遲實現的觀點

    （3）質量保證的觀點

  • V模型、W模型

• 增量模型：該模型先對系統最核心或最清晰的需求進行分析、設計、實現、測試，再按優先級逐步對后續需求進行上述工作，并集成到系統中，逐步形成一個完整系統

  • 綜合了線性、并行、演化的特征；每一個增量都提交一個可以運行的產品；適用于人手不足的情況；客戶的需求可以逐步提出來；可以規避技術風險；增量粒度難以選擇

• 原型開發：原型：模擬某種產品的原始模型（“樣機”）。在獲得一組基本需求后， 可以先通過快速地分析和設計，構造出一個小型的 軟件系統原型。用戶使用原型系統，開發人員根據用戶反饋修改或重建系統。

  • 僅包含主要功能以及重要接口，不包括系統的細節
  • 強調快速，不建議過多地采用新技術
  • 原型可作為一種技術，用于其它過程模型中

• 螺旋模型：螺旋模型結合了原型的迭代性質和瀑布模型的系統性和可控性特點，能快速開發軟件的增量版本。

  • 是一種風險驅動的過程模型
  • 螺旋模型沿著螺線順時針由內而外每旋轉一圈便開發出一個新的版本
  • 螺旋模型并不要求每一個螺旋的產品都是可以運行的程序
  • 螺旋模型不是當軟件交付后就結束過程，而是應用在軟件的整個生命周期中。
  • 適用于大型系統和軟件開發；把軟件質量作為一個重要目標；把維護也看做是一種開發

• 噴泉模型：噴泉模型主要用于面向對象的軟件項目，軟件的某個部分通常被重復多次，相關對象在每次迭代中隨之加入漸進的軟件成分。各活動之間無明顯邊界，例如設計和實現之間沒有明顯的邊界，這也稱為“噴泉模型的無間隙性”。

  • 較容易地實現活動的迭代和無間隙
  • 各個階段沒有明顯的界限，開發人員可以同步進行開發
  • 開發過程中需要大量的開發人員，因此不利于項目的管理

五、統一過程

• RUP： Rational Unified Process
• RUP是一個面向對象的基于web的程序開發方法論， 它建立了迭代、增量的過程流，提供了演進的特性。RUP從傳統軟件過程中挖掘了最好的特征和性質，也可用敏捷軟件開發中的許多最好的原則來實現。RUP既是一種軟件過程模型，又是一種支持面向對象軟件開發的工具，它將軟件開發過程要素和軟件工件要素整合在統一的框架中。RUP實際上是一種重量級過程，描述得非常完善和具體，特別適用于大型軟件團隊開發大型項目，實際應用時也可進行裁剪簡化
• 五個階段：起始、細化、 構建、轉換、生產
• 特點：用例驅動，以架構為核心，迭代且增量

六、敏捷軟件開發

• 敏捷開發方法保留了軟件過程中基本的框架活動：溝通、策劃、建模、構建和部署，但將其縮減到一個推動項目組朝著構建和交付發展的最小任務集。因此敏捷方法也被稱為輕量級方法、精簡方法
• 敏捷開發強調：
  • 開發人員和客戶之間主動和持續的溝通
  • 小而高度自主的項目團隊
  • 讓客戶滿意和軟件的早期增量發布
  • 超越分析和設計（但不排斥這類活動）的發布
  • 整體精簡開發，并使用最小化的軟件工程工作產品

七、軟件能力成熟度的五個階段：CMM1 → CMM5，從低到高

三、需求獲取與結構化分析方法

軟件需求的類別

• 功能：軟件應該具有的功能
• 質量：軟件應該具備的質量要求
• 約束：成本、進度、技術選型、標準和規范等要求

需求分析的目標：精確化、一致化、完全化、無冗余

需求分析任務

需求分析過程

確定利益相關者

獲取和理解軟件需求

描述和分析軟件需求

文檔化和評審需求

需求獲取的主要方法基于交流

需求技術

需求導出、建模和分析

需求建模技術：問題分解、抽象、多視點、快速原型、建模語言（數據流圖、統一建模語言UML）

需求描述

軟件需求規格說明書SRS

需求評審

目的、要求和結果

需求評審是為了減少和避免需求分析的結果可能存在的問題以及缺陷，以及他們可能帶來的嚴重后果

如何進行需求評審？評審的對象就是需求模型以及軟件需求規格說明書

結構化分析方法

傳統的分析建模方法稱為結構化分析（ structured analysis，SA）方法

最有代表性的是一種面向數據流進行需求分析的方法，最初于20世紀70年代由D.Ross提出，后 來又經過擴充，形成了今天的結構化分析方法的框架。

結構化分析方法是一種建模技術

功能建模

功能建模的思想就是用抽象模型的概念，按照軟件內部數據傳遞、變換的關系，自頂向下逐層分解，直到找到滿足功能要求的所有可實現的軟件為止。

數據流圖

功能模型用數據流圖來描述。

數據流圖的基本圖形符號

數據流圖的多個數據流之間的關系

環境圖

環境圖（context diagram）也稱為頂層數據流圖（或0層數據流圖），它僅包括一個數據處理過程，也就是要開發的目標系統。

環境圖的作用是確定系統在其環境中的位置，通過確定系統的輸入和輸出與外部實體的關系確定其邊界。

典型的環境圖

[外鏈圖片轉存失敗,源站可能有防盜鏈機制,建議將圖片保存下來直接上傳(img-mNoPkQfy-1653638581743)(https://fastly.jsdelivr.net/gh/RealBeBetter/image/img/202205271600686.png)]

E-R圖

關聯數量的表示：一對一、一對多、多對多

關系的屬性

行為建模

狀態轉換圖（簡稱狀態圖）通過描繪系統的狀態及引起系統狀態轉換的事件，來表示系統的行為。

狀態圖中使用的主要符號

數據字典

數據字典定義中的符號

加工規格說明

決策表

四、結構化設計方法

軟件設計的概念及原則

一、分而治之

• 分而治之是人們解決大型復雜問題時通常采用的策略。將大型復雜的問題分解為許多容易解決的小問題，原來的問題也就容易解決了
• 軟件的體系結構設計、模塊化設計都是分而治之策略的具體表現

二、模塊獨立性

• 定義: 是指軟件系統中每個模塊只涉及軟件要求的具體的子功能, 而和軟件系統中其它模塊的接口是簡單的。
• 有效的模塊化使軟件便于分工協作開發。
• 獨立的模塊比較容易測試和維護

模塊獨立性的度量準則

• 耦合：是模塊之間的互相連接的緊密程度的度量
• 內聚：是模塊功能強度(一個模塊內部各個元素彼此結合的緊密程度)的度量
• 模塊獨立性比較強的模塊應是高內聚低耦合的模塊

耦合度排序

• 非直接耦合：兩個模塊之間沒有直接關系，它們之間的聯系完全是通過主模塊的控制和調用來實現的；非直接耦合的模塊獨立性最強。
• 數據耦合：一個模塊訪問另一個模塊時，彼此之間是通過簡單數據參數 (不是控制參數、公共數據結構或外部變量) 來交換輸入、輸出信息的。也是較理想的耦合。
• 控制耦合：如果一個模塊通過傳送開關、標志、名字等控制信息，明顯地控制選擇另一模塊的功能，就是控制耦合。
• 公共耦合（Common Coupling）：若一組模塊都訪問同一個公共數據環境，則它們之間的耦合就稱為公共耦合。公共的數據環境可以是全局數據結構、共享的通信區、內存的公共覆蓋區等。
• 內容耦合 (Content Coupling)
  • 一個模塊直接訪問另一個模塊的內部數據。
  • 一個模塊不通過正常入口轉到另一模塊內部。
  • 兩個模塊有一部分程序代碼重迭。 (只可能出現在匯編語言中）
  • 一個模塊有多個入口。

設計原則

• 盡量使用數據耦合
• 少用控制耦合
• 限制使用公共耦合（除非傳遞大量數據）
• 完全不用內容耦合

內聚度排序

• 偶然內聚（Coincidental Cohesion）：當模塊內各部分之間沒有聯系，或者即使有聯系，這種聯系也很松散，則稱這種模塊為偶然內聚模塊，內聚程度最低。
• 邏輯內聚（Logical Cohesion）：把幾種相關的功能組合在一起，每次被調用時，由傳送給模塊的判定參數來確定該模塊應執行哪個功能。
• 時間內聚（Classical Cohesion）：時間內聚模塊大多為多功能模塊，但模塊的各個功能的執行與時間有關，通常要求所有功能必須在同一時間段內執行。
• 過程內聚（Procedural Cohesion）：如果一個模塊內的處理是相關的，而且必須以特定次序執行，則是過程內聚。
• 順序內聚：一個模塊中的處理元素和同一功能密切相關，而且這些處理必須順序執行，而且一個成分的輸出作為另一個成分的輸入，則稱為順序內聚。
• 功能內聚 (Functional Cohesion)：一個模塊中各個部分都是完成某一具體功能必不可少的組成部分，或者說該模塊中所有部分都是為了完成一項具體功能而協同工作，緊密聯系，不可分割的。則稱該模塊為功能內聚模塊。模塊的所有成分對于完成單一的功能都是必須的。

總結

以上是生活随笔為你收集整理的【软件工程】重要知识点的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。