# 軟體工程筆記

## 軟體專案計畫與管理
### 專案生命週期
- 初始 (Initial)
- 計畫 (Planning)
- 執行 (Execution)
- 結案 (Closure)

### 甘特圖里程碑
可採用SMART標準來定義里程碑，應該具備下列五項特色：
1. 具體性 (Specific)
2. 可測量性 (Measurable)
3. 可指定性 (Assignable)
4. 實際的 (Realistic)
5. 具備時間架構 (Time-Framed)

### 專案網路圖

- 箭頭圖示法(Arrow Diagramming Method， ADM)
- 或稱為活動箭頭圖示方法(Activity-on-Arrow， AOA)
- 箭頭代表各項工作間的關聯性

### 要徑分析法
Critical Path Method， **CPM**。
用來**預測整體專案期間**的專案網路分析技術

- 要徑
- 指一連串的活動，決定專案得以**完成的最早時間**。
- 專案網路圖中**最長**的一條路徑。
- 路徑中的**寬裕時間或是浮動時間最少**。

- 浮動時間 (Float) / 寬裕時間(Slack)
- 活動中**可能發生的延遲時間**。
- 對於整體專案的完成時間並不會造成實質上延遲的影響
- 分為
1. 總浮動時間 (Total Float)
不延遲專案結束的前提下，能延遲一項任務最早開始時間的時間量。
3. 自由浮動時間 (Free Float)
在不延遲下一項任務最早開始時間的前提下，能延遲一項任務開始的時間量。

### 專案要徑範例

路徑 1 `A-D-H-J`
長度 = 2 + 6 + 3 + 5 = 16天

路徑 2 `B-E-J`
長度 = 5 + 5 + 5 = 15天

路徑 3 `B-F-I-J`
長度 = 5 + 3 + 4 + 5 = 17天

路徑 4 `C-G-I-J`
長度 = 3 + 6 + 4 + 5 = 18天

所以此網路圖的要徑即為路徑4 (`C-G-I-J`)

### 縮短專案時程的技巧
減少在要徑上的活動所需要的時間

- 擠壓 (Crashing)
調整成本與時程的方式，在成本增加最小的情況下，將時程進行最大程度的壓縮。
- 快速追蹤 (Fast Tracking)
將平日可能採取順序執行的活動，改以平行執行的方式取代。

### 專案風險管理
- 風險
潛在的問題且足以阻礙專案進行

- 有效的風險管理
事先規劃一連串的程序以進行風險辨識、風險評估、風險分級等

- 與專案管理的關係
專案管理應制定風險計畫，研究風險解決方法，進行風險控制活動，並且不斷地進行風險監督直到專案結束

- 專案風險管理的困難
風險是針對未來的事件
風險的發生及造成的損失均不確定
風險一旦發生，將對專案造成重大或致命性的影響

---

風險包含**機率** (Probability) 與**損失** (Loss)二項變數


R 是風險
P_i 是第 i 項風險發生的機率
L_i 是第 i 項風險發生的損失
n 是風險數

- 螺旋式模型
1. 首次將風險分析因素加入軟體開發模式
2. 每一次的風險管理象限都會產生一個「做與不做」的決定，若專案的風險太大則必須中止軟體開發

### 風險管理架構圖

### 風險分析
- 風險辨識 (Risk Identification)
找出危害專案的風險事項

- 風險評估
估計風險項目發生的機率與風險發生後可能造成的損失

- 風險分級
設定風險參考水準(Risk Referent Level)以設定風險截斷線(Cutoff Line)

- 風險降低比 =(風險管理前之風險 - 風險管理後之風險)/風險降低時花費

## 軟體測試
廣義的軟體測試，包括軟體品質的分析與檢驗，即所謂的**驗證與確認**(Verification and Validation， V&V)。

### 靜態分析
不直接執行軟體系統，以人工或自動化方法評估軟體開發各階段的工作產品，檢查是否滿足所制訂的需求規格，並嘗試找出錯誤與及早修正。

### 動態分析
程式撰寫完成後才能進行動態測試，執行軟體程式碼。

---

### 白箱測試
根據**程式碼產生測試案例與測試資料**的技術，也是種強迫檢視程式碼的做法，但成本比較高。

根據虛擬碼或原始程式碼的**可能執行路徑**來設計測試案例，可以發現65%的模組測試階段錯誤，能夠有效地測試程式細節，對程式碼的控制結構相關錯誤較有效。

白箱測試方法對以下錯誤不完全有效：
1. 完全錯誤或遺漏的功能
2. 介面的錯誤
3. 資料結構與範圍的錯誤
4. 起始值設定的錯誤

### 白箱測試原則
白箱測試根據**程式碼的內部構造**，測試是否依照設計規格正確運行，其測試原則為：
1. 保證模組中每條獨立路徑在執行時至少都通過一次。
2. 所有包含邏輯判斷的語句都要確實執行。
3. 所有迴圈的邊際條件及內部操作都得檢驗。
4. 檢驗所有內部資料結構的正確性。

### 白箱測試主要技術
- 基本路徑測試
- 邏輯條件測試
- 資料流測試
- 迴圈測試

---

### 黑箱測試
將測試的元件模組或系統，當作一個黑色的箱子，只**依照產品表現在外的功能效果**，測試是否正確地達成任務，因而著重於功能與性能的需求、介面、初始與結束正確性的測試。

黑箱測試的優點為：
1. 測試案例設計成本低。
2. 從規格及使用者角度考慮問題，對程式外部功能有很好的效果。
3. 不容易受到程式影響而產生偏見。

黑箱測試的缺點為：
1. 不容易測到程式細節，需要長時間而大量的測試案例以確保穩定性。
2. 若設計的測試案例太少則測試的效果較差。若設計大量測試案例或以不同方法設計測試案例則容易造成重複設計與浪費測試時間。

### 黑箱測試主要技術
- 等價分類法
- 邊界值分析法
- 因果圖

---

### 測試覆蓋性
透過「覆蓋率」(Coverage Rate) 的分析，可以進一步了解所使用的測試方法或是所設計的測試案例，對於所要測試的標的能測試的範圍、程度到何種等級。

---

### 單元測試
- 由軟體開發人員親自對軟體內部結構執行最小規模的測試。

- 受測程式可以是單獨或僅提供某項功能的程式。

- 此類測試的目的在確保其功能可單獨且正確地運作，每個單元必須能獨立測試而不受其他元件的影響，是屬於所有測試策略中**最低層次的測試**。

- 主要使用**白箱測試**方法，並配合黑箱測試方法，來設計測試案例，以檢驗每個單獨的模組是否正確的執行其預期功能。

---

### 整合測試
- 整合測試(Integration Testing)是指在元件通過單元測試之後。

- 整合測試的目的在於找出系統整合時的錯誤。

- 最佳的整合測試是先使用**由上而下的整合測試**，並在確定較具關鍵性的綜合模組後，再進行由下而上的整合測試。

---

### 軟體測試 V 模型

---

## Junit

以計算兩個值相加為例

public class Calculator {

    public int add(int number1, int number2) {
        return number1 + number2;
    }
}

測試

public class CalculatorTest {

    @Test
    public void add_5_and_10_return_15() {
        // 1. Arrange
        Calculator calculator = new Calculator();
        int number1 = 5;
        int number2 = 10;
        int excepted = 15;

        // 2. Act
        int actual = calculator.add(number1, number2);

        // 3. Assert
        assertThat(actual).isEqualTo(excepted);
    }
}

- `assertEquals(基本型別 expected, 基本型別 actual) `
檢查兩者是否相同，如果是物件比較只看value (Call by value)
- `assertNotEquals(Object expected, Object actual)`
檢查兩者是否不相同
- `assertSame(Object expected, Object actual)`
檢查兩者是否相同，會多看使否只到相同記憶體位置 (Call by reference)
- `assertFalse(boolean condition)`
是否為false
- `assertTrue(boolean condition)`
是否為true

## 題目