現代軟件工程期末復習--基礎知識

1. 軟件工程師及軟件團隊

講解了一些軟件工程師的規范和團隊規范

沒啥看的，暫時忽略

2. 軟件及其過程

什么是軟件？

• 計算機軟件指計算機系統中的程序、數據及其相關文檔

• 程序：按照特定順序組織的計算機數據和指令的集合

• 數據：使程序能正常執行的數據結構

• 文檔：為了便于理解程序所需的與開發、維護和使用有關的資料

• 軟件=程序+文檔+數據，三要素

軟件的特點？

• 軟件是設計開發的，而不是傳統意義上生產制造的。

• q軟件不會“磨損”，但會退化。

• 大多數軟件還是用戶定制的

軟件的分類？

• 計算機軟件可分為七個大類：系統軟件

• 應用軟件
  工程/科學軟件
  嵌入式軟件
  人工智能軟件
  產品線軟件
  WebApp
  移動App

• 其中后三者為最近二十年出現的新形態

• 另外一種分類方式：是分為系統數據（位于計算機系統中最靠近硬件的一層，如操作系統、編譯程序）、支持軟件（支持軟件的開發和維護的軟件。如數據庫管理系統、網絡軟件、軟件開發環境等）、應用軟件（特定應用領域專用的軟件。如實時軟件、嵌入式軟件）

軟件技術的演化？

• 第一階段：程序設計階段 。個體手工方式（小程序）
• 第二階段：程序系統階段。小組化生產，出現軟件危機（軟件作坊）
• 第三階段：傳統軟件工程階段。工程化的思想引入，結構化方法的發展
• 第四階段：面向對象階段。面向對象方法

軟件危機

• 軟件危機(Software Crisis)：計算機軟件的開發和維護過程所遇到的一系列嚴重問題。（tip：反正什么開發問題都算作軟件問題就玩了）

• 原因：與軟件本身的特點有關 (難于維護, 邏輯復雜)
  與軟件開發與維護的方法不正確有關

什么是軟件工程？

• 軟件工程是：①把系統的、規范的、可度量的途徑應用于軟件開發、運行和維護過程，也就是把工程應用于軟件； ②研究①中提到的途徑
• 軟件工程是一種層次化的技術。任何工程方法必須構建在質量承諾的基礎上。
  軟件工程的基礎是過程。軟件過程將各個技術層次結合在一起，使得合理、及時地開發計算機軟件成為可能。
  軟件工程方法為構建軟件提供技術上的解決方法。
  軟件工程工具為過程和方法提供自動化或半自動化的支持
• 軟件工具是指能支持軟件生存周期中某一階段（如系統定義、需求分析、設計、編碼、測試或維護等）的需要而使用的軟件工具。
• 軟件生命周期模型：

• 軟件神話：關于軟件及其開發過程的一些說法被人盲目相信

3.軟件過程及其過程模型

• 什么是軟件過程？一個為創建高質量軟件所需要完成的活動、動作和任務的框架

軟件過程模型

• 軟件過程模型：也稱軟件開發模型 或 軟件生存周期模型。是軟件生存周期中一系列有序的軟件開發活動的流程，是軟件開發全部活動的結構框架

• 軟件過程模型有那些：
  1. 寫了再改模型Code-and-fix-----字面意思
  2. 瀑布模型-----將軟件生命周期劃分為軟件計劃、需求分析、設計、實現、測試、運行和維護等階段，規定了它們自上而下、相互銜接的固定次序，如同瀑布流水逐級下落。嚴格按照流程一步步來
  - 特點:階段間具有順序性和依賴性
  推遲實現的觀點
  質量保證的觀點
  - 優點：規范了
  - 缺點：1.難以應對需求變化
  2.過于理想：實際項目很少按照該模型給出的 順序進行；
  3.風險太大：用戶必須有耐心，等到系統開發完成才能見到軟件；
  4.阻塞狀態：開發者常常被不必要地耽擱。
  - 適用于需求穩定。外部干擾少

        3. 原型開發模型（快速原型）（演化過程模型的一種）
           - 最開始是一個原型版本發布，之后不斷對原型迭代
  

4. 增量模型

   • 增量模型以迭代的方式運用瀑布模型

   • 隨著時間的推移，發布一系列稱為增量的版本，隨著每個版本的交付，逐步為用戶提供更多的功能。

   • 就像游戲中的dlc，不斷迭代完善增加功能

   • 優點：提高對用戶需求的響應；人員分配靈活（一個個增量看情況投入人力）；可規避技術風險（不確定的功能后面開發）

   • 缺點：加入新增量時應簡單、方便；每個附加的增量并入現有的軟件時，必須不破壞原來已構造好的東西；仍然無法處理需求發生變更的情況;管理人員須有足夠的技術能力來協調好各增量之間的關系;難以確定所有版本共需的公用模塊

     5. 螺旋模型（演化過程模型的一種）

        • 風險驅動的軟件開發模型
          采用循環的方式，逐步加深系統定義和實現的深度
          確定一系列里程碑，確保stakeholders都支持系統解決方案
          第一圈一般開發出產品的規格說明，接下來開發產品的原型系統，并在每次迭代中逐步完善，開發不同的軟件版本
        • 結合了原型的迭代性質和瀑布模型的可控性、系統性特點
        • 優點：結合了原型的迭代性質與瀑布模型的系統性和可控性，是一種風險驅動型的過程模型；等
        • 缺點：螺旋模型依賴大量的風險評估專家來保證成功。如果有較大的風險沒有被發現和管理，肯定會發生問題；軟件開發人員應該擅長尋找可能的風險，準確的分析風險，否則將會帶來更大的風險。

     6. 專用過程模型：

        • 基于構件的開發—能夠使軟件復用
        • 形式化方法模型—注重需求的數學規格說明
        • 面向方面的軟件開發—為定義、說明、設計和構建方面提供過程和方法
        • 統一過程—一種“用例驅動、以構架為中心的迭代和增量”，軟件過程和統一建模語言(UML)緊密結合

4. 敏捷過程

什么是敏捷？

是一種從90年代開始逐漸引起廣泛關注的一些新型軟件開發方法。如極限編程（xp） ( Extreme Programming )和Scrum用到了敏捷

• 2001~今，正在流行

敏捷宣言

• 在瀑布模型還是主流的時代一些軟件開發人員一起宣布了“反叛宣言”，制定并簽署了行業歷史上最重要的文件之一:敏捷宣言。
• 內容：個人和他們之間的交流勝過開發過程和工具
  可運行的軟件勝過寬泛的文檔
  客戶合作勝過合同談判
  對變更的良好響應勝過按部就班地遵循計劃

什么是敏捷過程？

基于敏捷原則進行的軟件開發過程，視為敏捷過程

敏捷過程模型有：極限編程、Scrum等

極限編程XP（Extreme Programming）

• 采用迭代的交付方式，每個迭代很短（1-3周時間）。在每個迭代結束的時候，團隊交付可運行的，經過測試的功能，這些功能可以馬上投入使用。
• 極限編程的主要目標在于降低因需求變更而帶來的成本

Scrum

• 英語意為爭球
• 采用短周期迭代交付方式
• Scrum 流程包括：
  3個角色
  3個工件
  5個活動

5. 軟件需求

什么是軟件需求？

軟件需求的三個層次：業務需求
用戶需求
功能需求

• 業務需求反映了組織機構或客戶對系統、產品高層次的目標要求。描述了為什么要開發系統（why）
• 用戶需求描述了用戶使用產品必須要完成的任務。描述了用戶能使用系統來做些什么（what）
• 功能需求是需求的主體，它描述的是開發人員如何設計具體的解決方案來實現這些用戶需求（how），其數量往往比用戶需求高一個數量級。

軟件需求的分類

• 功能需求和非功能需求。
• 功能需求描述系統預期提供的功能或服務
• 非功能需求：不直接與系統具體功能相關的需求。如產品需求/機構需求、外部需求

需求工程

應用已證實有效的技術、方法進行需求分析，確定客戶需求，幫助分析人員理解問題并定義目標系統的所有外部特征的一門學科。

需求獲取技術

包括：面談
調查
觀察實際業務過程
原型法
頭腦風暴
場景技術等

需求規格說明書

沒啥說的，應該考不了

6.需求建模

基于場景的建模

你可以理解基于用例。主要步驟就是傳統的步驟包括：識別參與者、識別用例、繪制用例圖、編寫用例描述

用例圖怎么畫才學過應該不會忘吧，

編寫用例描述類下：

基于數據流的建模

• 一種面向數據流的傳統軟件開發方法

• 以數據流為中心構建軟件的分析模型和設計模型

• 分為：
  結構化分析(Structured Analysis 簡稱SA)
  結構化設計(Structuresd Design 簡稱SD)
  結構化程序設計(Structured Programmin 簡稱SP)

• 畫數據流圖：畫頂層圖（人員，系統）、1層圖（系統分解成各種功能）、2層圖（再細分功能，如處理事務分解為處理入庫、加工入庫等）

頂層圖（第0層）只有代表整個軟件系統的1個加工，描述了軟件系統與外界之間的數據流
頂層圖中的加工經分解后的圖稱為第1層圖(只有1張)
中間層圖中至少有一個加工(也可以有多個)在下層圖中分解成一張子圖
處于最底層的圖稱為底層圖，其中所有的加工不再分解成新的子圖

一層圖：

二層加工：

描寫數據流圖條目：

面向數據的建模方法

• 是按照用戶的觀點對數據建立的模型。它描述了從用戶角度看到的數據，反映了用戶的現實環境，而且與在軟件系統中的實現方法無關。
• 數據模型中包含3種相互關聯的信息：數據對象（實體）、數據對象的屬性及數據對象彼此間相互連接的關系。
• 表現圖形就是：實體-聯系圖（ER圖）

7.軟件設計

軟件設計概念

軟件的設計是將需求轉變為軟件陳述（表達）的過程。這種陳述是一個對軟件的全局觀點。系統通過逐步求精使得設計陳述逐漸接近程序代碼。

• 第一步是概要設計，關注于怎么將需求轉換成數據和軟件框架。
• 第二步是詳細設計，關注于將框架逐步求精細化為具體的數據結構和軟件的算法表達。

設計概念：

抽象——數據，過程，控制
體系結構——軟件的整體結構
模式——傳遞已驗證設計方案的精髓
關注點分離——任何復雜問題在被分解為若干塊后將更易處理
模塊化——數據和功能的分割
（信息）隱蔽——控制接口
功能獨立——單一功能和低耦合
求精——細化所有抽象的細節
方面——理解全局需求如何影響設計的機制
重構——簡化設計的重組技術
面向對象的設計概念—。。。。繼承、多態、類等

體系結構設計

• 兩種方法：

  • 結構化設計
    數據流模型->軟件結構圖
  • 面向對象設計
    用例模型->分析類圖->設計類圖->構件圖

• 結構化設計：兩級分解：

  • 第一級分解是將數據流圖映射成變換型的程序結構：

    主控模塊：完成整個系統的功能

    輸入流控制模塊：接收所有輸入數據

    變換流控制模塊：對內部形式的數據進行加工處理，實現輸入到輸出的變換

    輸出流控制模塊：產生所有輸出數據

• 第二級分解：
  1. 輸入流控制模塊的分解：
     從變換中心的邊界開始，沿著輸入通路向外移動，把輸入通路上的每個加工映射成程序結構中輸入流控制模塊的一個低層模快
  2. 輸出流控制模塊的分解：
     從變換中心的邊界開始，沿著輸出通路向外移動，把輸出通路上的每個加工映射成程序結構中輸出流控制模塊的一個低層模快
  3. 變換流控制模塊的分解：
     把變換中心的每個加工映射成受變換控制模塊控制的一個低層模塊

構件設計

基本原則：高內聚，低耦合

處理邏輯的表示工具：活動圖、流程圖

界面設計

• 黃金規則：
  1. 把控制權交給用戶
  2. 減少用戶的記憶負擔
  3. 保持界面一致

8.軟件測試

軟件測試描述

• 廣義：在規定的條件下對程序進行操作，以發現程序錯誤，衡量軟件質量，并對其是否能滿足設計要求進行評估的過程。
• 測試是為了證明程序中有錯誤，而不是證明程序中無錯誤
• 一個好的測試用例指的是它可能發現至今尚未發現的缺陷
• 一次成功的測試指的是發現了新的軟件缺陷的測試
• 設計測試用例要設計盡可能少的測試用例來發現盡可能多的錯誤
• 白盒測試（又稱為結構測試）把測試對象看作一個透明的盒子，測試人員根據程序內部的邏輯結構及有關信息設計測試用例，檢查程序中所有邏輯路徑是否都按預定的要求正確地工作,白盒測試主要用于對模塊的測試.
• 黑盒測試（又稱行為測試）把測試對象看做一個黑盒子，測試人員完全不考慮程序內部的邏輯結構和內部特性，只依據程序的需求規格說明書，檢查程序的功能是否符合它的功能需求,黑盒測試可用于各種測試
• 之后是n種測試方法，什么冒煙測試。回歸測試等等
• 白盒測試是有選擇地執行（或覆蓋）程序中某些最有代表性路徑的測試方法，所以也稱為邏輯覆蓋測試

黑盒測試技術

• 黑盒測試是根據程序組件的規格說明測試軟件功能的方法，所以也稱為功能測試
  被測對象作為一個黑盒子，它的功能行為只能通過研究其輸入和輸出來確定，所以又稱為軟件輸入/輸出接口測試
  黑盒測試注重于功能和數據信息域的測試

• 第一步：等價類的劃分：

  • 等價類的劃分有兩種不同的情況：
    有效等價類：合理的，有意義的輸入數據集合。
    無效等價類：不合理的，無意義的輸入數據集合。

  • 不好描述直接舉例吧：

• 第二步：設計測試用例：

  • 怎么說呢？有效等價類只需要被測試用例覆蓋過就夠了

    ? 但是無效等價類則需要控制變量每個單獨有 測試用例單獨覆蓋

    例：

?

9.軟件項目管理

軟件質量保證(SQA)

• 提高軟件質量最好的辦法是：在開發過程中有效地防止工作成果產生缺陷，將高質量內建于開發過程之中。主要措施是“不斷地提高技術水平，不斷地提高規范化水平”，其實就是練內功，通稱為“軟件過程改進”。
• 軟件質量：應用有效的軟件過程，創造有用的產品，為生產者和使用者提供明顯的價值。

風險管理

具有負面后果、人們不希望發生的事件。

風險策略：

• 被動風險策略：對風險不聞不問，直至出現問題。這時，項目團隊趕緊采取行動，試圖迅速解決問題

• 主動風險策略：在技術工作開始之前，就開始識別出潛在的風險，評估它們發生的概率及影響，并按重要性排序。然后，制定一個計劃來管理風險

  好像這一章都沒啥說的

最后，本篇只包括一些基礎知識，具體題目和一些重點拓展需要作者去做些題再來總結一下。