軟工導論復習筆記

軟工導論復習#

Chapter 0#

軟件工程提出時間：1968 年

1968 年北大西洋公約組織 (NATO) 的計
算機科學家在聯邦德國召開國際會議，
討論軟件危機問題，正式提出了 “軟件
工程”。

Chapter 1#

軟件的本質
開發 / 惡化 / 定制 / 複雜

Chapter 2#

軟件工程定義
1. 將系統化、紀律性、可量化的方法應用於軟件的開發、運行和維護；即將工程應用於軟件。
2. 研究如 (1) 中的方法。
軟件過程
- 為什麼：需要及時的反饋
- 過程框架
  - 框架活動
    - 溝通
    - 計劃
    - 建模
      1. 需求分析
      2. 設計
    - 建設
      1. 代碼
      2. 測試
    - 部署
  - 庇護活動（普適性活動）
    - 軟件項目跟蹤和控制
    - 風險管理
    - 軟件質量保證
    - 技術評審
    - 測量
    - 軟件配置管理
    - 可重用性管理
    - 工作產品準備和生產
軟件生命周期
- 軟件有一個孕育、誕生、成長、成熟、
  衰亡的生存過程。這個過程即為計算機
  軟件的生命周期 (生存周期)
- 為什麼需要
  - 從時間角度對軟件開發和維護的複雜問題進行分解，把軟件生存的漫長周期依次劃分為若干個階段，每個階段有相對獨立的任務，然後再逐步完成每個階段的任務。
  - 為軟件人提供一個公共的框架，以便軟件人的相互交流。

Chapter 4#

演化模型
- 原型
  - 類型
    - 探索型（exploratory prototyping）弄清需求
    - 實驗型（experimental prototyping）驗證方案
    - 演化型（evolutionary prototyping）
  - 特徵
    - 可實際運行
    - 它沒有固定的生存期。它可能被扔掉，或者作為最終產品的一部分。
    - 可為不同目標作原型
    - 快速、廉價
    - 是迭代過程的集成部分，即每次經用戶評價後修改、運行，不斷重複雙方認可。

Chapter 5#

敏捷宣言
- 個體和互動高於流程和工具
- 工作的軟件高於詳盡的文檔
- 客戶合作高於合同談判
- 響應變化高於遵循計劃

Chapter 7#

需求工程#

開端
引出
詳述
談判
規範
- 根據需求調查和需求分析的結果，進一步定義準確無誤的產品需求，產生《產品需求規格說明書》
驗證
需求管理

質量功能部署#

功能部署 —— 確定系統功能的價值
信息部署 —— 確定數據對象和事件
任務部署 —— 確定系統的行為
價值分析 —— 確定需求的優先級

非功能需求#

質量屬性
性能屬性
安全屬性
一般系統約束

圖表#

用例 / 類 / 狀態 / 活動

Chapter 11#

分析模型
- 專注於描述所需的數據、功能和行為

設計模型#

提供有關軟件數據結構、架構、接口和組件的詳細信息
4 種類型
- 數據 / 類設計 —— 將分析類轉換為實現類和數據結構
- 架構設計 —— 定義主要軟件結構元素之間的關係
- 接口設計 —— 定義軟件元素、硬件元素和最終用戶如何通信
- 組件級設計 —— 將結構元素轉換為軟件組件的過程描述

概念#

架構 - 軟件的整體結構
- 體現了系統的模塊化、抽象和信息隱藏、接口設計
- 舉例
  - 客戶 - 服務器架構（Client-Server Architecture）
  - 微服務架構（Microservices Architecture）
  - 事件驅動架構（Event-Driven Architecture）
  - 分層架構（Layered Architecture）
模式
- 模式的目標：易於重用。
- 類型：
  - 架構模式
    - B/S, C/S
  - 設計模式
  - 慣用法
    - 一種特定於編程語言的低級模式
功能獨立性
- 內聚
  - 模塊的相對功能強度的指示
  - 功能內聚分層內聚通信內聚順序內聚過程內聚時間內聚實用內聚（由高到低排列）
- 耦合
  - 模塊之間的相對相互依賴性的指示
  - 非直接耦合數據耦合標記耦合控制耦合外部耦合共用耦合內容耦合（由低到高排列）
- 目標：高內聚，低耦合

Chapter12 行為建模#

什麼
系統的結構，包括軟件組件、這些組件的外部可見屬性以及它們之間的關係
架構的重要性
- 促進所有方（利益相關者）之間的溝通
- 突出早期設計決策
- 構成一個相對小的、智力可掌握的模式
架構有什麼用
- 分析設計在滿足其規定要求方面的有效性
- 在進行設計更改仍然相對而言的階段考慮架構替代方案容易
- 降低與軟件構建相關的風險

架構風格#

定義內容
- 一組執行系統所需功能的組件
- 一組連接器，可以實現 “通信、協調和組件之間的合作”
- 定義組件如何集成以形成系統的約束
- 語義模型，使設計人員能夠通過分析系統組成部分的已知特性來理解系統的整體屬性
種類
- 數據流架構 —— 批處理、管道和過濾器
- 調用和返回架構 —— 主程序 / 子程序、面向對象系統、分層系統
- 獨立組件架構 —— 事件系統、觸發器、監視器
- 虛擬機架構 —— 解釋器，基於規則的系統
- 倉庫架構 —— 數據庫系統，黑板系統等

Chapter13 組件級設計#

一個模塊化的、可部署的、可替換的系統部分，它封裝了實現並公開了一組接口。

基本設計原則#

開閉原則（OCP）—— 一個模塊 [組件] 應該對擴展開放但對修改關閉
里氏替換原則（LSP）—— “子類應該可以替代它們的基類。
依賴倒置原則（DIP）—— 依賴於抽象。不要依賴實體
- 高層模塊應該依賴於抽象（接口或抽象類）
- 抽象不應該依賴於具體實現，具體實現應該依賴於抽象
接口分離原則 (ISP)—— 許多專用的接口都比一個通用接口好
發布重用等效原則 (REP)—— 重用的粒度就是發布的粒度
共同閉合原則（CCP）—— 同時修改的類應該放在一起
共同重用原則（CRP）—— 不能同時復用的類不應該放在一起

Chapter14 用戶界面設計#

黃金規則
- 用戶控制操作
- 減少用戶記憶負擔
- 保持界面一致

Chapter 15-16 軟件質量#

什麼是軟件質量
一個有效的軟件過程，其應用方式創造了一個有用的產品，為生產它的人和使用它的人提供可衡量的價值
McCall 的質量三角
- 產品修改
- 產品轉移
- 產品運行
質量的成本
- 在測試和維護階段改正錯誤和缺陷的成本急劇增高
- 種類：
  1. 預防成本（COP）
  2. 評估成本（COA）
  3. 內部失敗成本
  4. 外部失敗成本

Chapter 17-19. 測試策略與技術#

驗證與驗證
- 驗證：確保軟件能實現特定功能 building the product right
- 驗證：確保軟件可追溯到客戶需求 building the right product
測試策略 —— 從小到大
- 單元測試
- 集成測試
- 系統測試
- 驗收測試
  - α 測試由最終用戶在開發人員站點進行
  - ß 測試在最終用戶站點進行

測試策略之單元測試#

內容：
- 接口
- 局部數據結構
- 邊界條件
- 獨立路徑
- 錯誤處理路徑
stub—— 代替底層
driver—— 代替頂層
- 提供了一個框架用於設置輸入參數，環境，執行單元

測試策略之集成測試#

自上而下集成
- 優勢
  - 程序的骨架版本可以早期存在並允許演示
  - 設計錯誤可能會更早被發現。
  - 減少對測試驅動程序的需求
  - 它傾向於使故障定位更容易
- 劣勢
  - stubs 可能很昂貴。
自下而上集成
- 優勢
  - 對對象和重用特別有用。
  - 不需要結構設計信息
- 劣勢
  - 整個程序在最後一個模塊添加之前不存在。
  - 需要測試驅動程序，而不是測試 stubs。

測試策略之系統測試 —— 充分運用基於計算機的系統#

目的：
- 在將要運行的真實環境中測試整個系統
- 確保系統滿足整體工作的要求
- 還要測試系統功能之外的方面
- 結果有時用於系統驗收
- 驗證軟件用戶手冊
- 估計可靠性和可維護性

測試方法#

黑盒測試（功能）
白盒測試（結構）

Chapter 21 軟件配置管理#

SCM 過程#

識別
變更控制
版本控制
配置審計
報告

軟件配置項

Chapter 22 項目管理概念#

4 p#

人員
產品
- 範圍
  1. 上下文
  2. 信息目標
  3. 功能和性能
過程
- 考慮項目特徵
- 確定所需的嚴謹程度
- 為每個軟件工程活動定義任務集
項目
1. 從正確的基礎上開始工作 —— 首先通過努力理解要解決的問題，然後設定現實的目標和期望來實現的
2. 保持動力 —— 項目經理必須提供激勵措施，將人員流動率控制在最低限度，團隊應在其執行的每項任務中強調質量，高級管理人員應盡一切可能遠離團隊
3. 跟蹤進度 —— 作為質量保證活動的一部分，隨著工作產品（例如模型、源代碼、測試用例集）的生成和批准（使用正式的技術評審），進度會被跟蹤。
4. 做出明智的決定 —— 項目經理和軟件團隊的決定應該是 “保持簡單”
5. 進行事後分析 —— 建立一個一致的機制來提取每個項目的經驗教訓

W5HH#

為什麼要開發這個系統？—— 為什麼
會做什麼？ —— 做什麼
何時完成？—— 什麼時候做
誰負責？—— 誰負責
他們在組織上位於何處？—— 其他人的組織機構位於何處
如何完成技術工作和管理工作？—— 如何完成技術工作和管理工作
每種資源（例如，人員、軟件、工具、數據庫）需要多少？—— 每種資源需要多少

任務集 =#

軟件工程任務
工作產品
質量保證點
里程碑

軟件工程活動#

需求分析
設計
軟件開發
軟件部署
軟件維護
項目管理
質量保證
配置管理
文檔編寫

Chapter 23 過程和項目度量#

意義
1. 評估正在進行的項目的狀態
2. 跟蹤潛在風險
3. 在問題造成不良影響前發現風險
4. 調整工作流程或任務
5. 評估項目團隊控制軟件工作產品質量的能力

過程測量#

根據過程中獲得的一系列數據或軟件工程任務的特性來進行測量。
軟件過程改進 (SPI)
5 個度量
- 與質量相關
- 與生產力相關
- 統計 SQA 數據
- 缺陷移除效率
- 重用數據

項目度量#

三個方面
- 如期
- 質量
- 成本

Chapter 24-25 項目估算與排程#

範圍#

範圍指的是創建項目產品所涉及的所有工作以及用於創建它們的過程。它定義了什麼是或不是要做的
項目範圍的內容
- 交付給最終用戶的功能和特性
- 輸入和輸出的數據
- 由於使用軟件而呈現給用戶的 “內容”
- 性能、約束、接口、和約束系統的可靠性

工作分解結構 (WBS)#

進行 WBS 的五種方法
1. 使用指南：一些組織提供的指南
2. 類比方法：審查類似項目的 WBS，並根據我們的項目進行定制。
3. 自上而下的方法：從項目中最大的項目開始，並將它們分解
4. 自下而上的方法：從詳細的任務開始，並將它們匯總
5. 思維導圖方法：以非線性格式寫下任務，然後創建 WBS 結構

估算方法#

基於代碼行的估算
- 優點：易於測量、容易自動化
- 缺點：僅限於代碼不能用於設計、依賴於語言、沒有考慮功能的複雜性、與設計的好壞掛鉤
基於功能點的估算
- 優點：
  1. 可用於最早的需求階段
  2. 獨立於編程語言、產品設計或開發風格
  3. 用戶視圖，而不是實現視圖
  4. 可用於衡量非編碼活動
  5. 存在大量歷史數據
  6. 有據可查
- 缺點：
  1. 無法直接計算現有產品（源代碼）的 FP 內容
  2. 難以自動化
  3. FP 不反映語言、設計或風格差異
  4. FP 設計用於估算商業數據處理應用
  5. 主觀計數

項目排程#

項目為什麼會延期
不切實際的截止日期
需求的變化
低估工作量
不可預測的風險
技術難題
人為困難
溝通不暢
未能認識到項目落後於計劃或缺乏糾正問題的行動
排程的原則
划分 —— 定義多個不同的任務
相互依賴性 —— 明確任務的相互關係
工作量確認 —— 確保人力資源可用
確定責任 —— 明確責任承擔者
明確輸出結果 —— 確定活動產生的結果
確定里程碑 —— 進行質量審查
排程的步驟
1. 定義任務集 ——WBS
2. 安排活動
3. 繪製項目網絡圖
4. 關鍵路徑分析
5. 使用甘特圖進行排程
6. 進度跟蹤

Chapter 26 風險管理#

被動風險管理
主動風險管理
- 進行正式的風險分析
- 修正風險的根本原因
風險管理範式
1. 風險識別
2. 風險分析
3. 風險規劃
4. 風險監控
RMMM
- 減輕
- 監控
- 管理

常用圖#

用例圖
類圖
活動圖
- 變形：泳道圖
順序圖