###### tags: `Software Engineering`

# Ch01 - 軟體危機與流程

## Fredrick Brooks 所提出的軟體本質問題
- **複雜性**
- 軟體系統之複雜程度，往往隨著程式的大小及軟體元件個數以非線性的方式，甚至是等比級數的方式遞增。
- ex. 系統的狀態、程式碼大小、系統功能、程式靜態結構、系統動態行為等各層面。
- **易變性**
- 為了滿足客戶的需求，一套成功的軟體系統，從開發到完成、從產品交付到營運維護，隨時都有可能要做變更。
- **隱藏性**
- 軟體本身是看不到、摸不著的，導致需求容易存有誤解、疏忽的地方不容易被發現，而大大的妨礙了彼此溝通的進行。
- **一致性**
- 在大型的協作環境下發展軟體系統，介面跟介面間、模組跟模組間、系統跟系統間的介接，便都存有一致性的問題需要解決，因此需要透過各種方式來轉換或是介接不一致的地方。

## 基本的軟體開發活動
- **需求分析**
- **設計**
- **實作**
- **測試與維護**

### 軟體測試
- **單元測試**
- 測試單元模組功能是否正常運作
- **整合測試**
- 測試模組或子系統的介面整合是否正常運作
- **系統測試**
- 測試整體系統的效能、安全性、穩定度等非功能性需求是否如預期
- **接受測試**
- 測試系統的整體性運作是否符合使用者的需求

## 軟體流程模型
抽象的軟體流程樣板，提供組織定義軟體開發的流程指引。
- 常見的軟體流程模型:
- **瀑布式開發流程**
- **統合流程**
- **極限製成**

## ==瀑布式開發流程==
### 五個階段:
1. **需求定義**
- 主要目的是在了解顧客的需求或建立產品的功能需求。
- ex. 需求擷取、需求訪談、需求分析等。
- **產出軟體需求規格書**。
2. **系統設計**
- 依照上一階段所產出的軟體需求規格書進行設計。
- 包含架構設計與細部設計 (ex. 介面設計、資料庫設計等)。
- **產出系統設計規格書**。
3. **系統實作**
- 將系統設計規格書落實為可以執行的軟體測試碼，並**進行單元測試**。
- **產出程式碼與單元測試的結果**。
4. **系統整合與測試**
- 依據系統設計規格書的架構逐步整合各子系統或模組，並**進行整合測試**，以確定各子系統可以正確無誤地整合。
- 系統測試係針對整個系統進行整體性的測試，以確保其功能性、效能性都可以符合需求規格書的描述。
- **產出系統測試報告**。
5. **系統移交**
- 當系統測試無誤並進行移交後，此軟體系統也進入**維護階段**。
- 維護階段通常很長，主要在處理錯誤的修復以及功能的增強。
### 優點:
- 清楚的階段分割: 專案的控管更為容易。
- 明確的文件產出: 使得合約的簽訂、技術或管理的審查更為容易，也有利於後續專案的維護。

### 限制:
- 需求提供者沒有辦法正確及完整地表達需求。
- 使用者、系統分析師、系統設計師、程式設計師之間傳遞訊息上的誤解。
- 使用者的需求經常改變。

### 適用範圍:
瀑布式開發流程方式較適用於**大型專案**，且**需求變更幅度不大**的系統。

### V模型
- V模型可以呈現**軟體開發階段與軟體測試階段的對應關係**。
- V模型的**左半邊是軟體開發生命週期**，每個階段產生的工作產品(Work Product)都需要加以檢視與複審，以免錯誤遺留到下一個階段的工作產品。
- V模型的**右半邊是測試流程中的各階段**。
- 中間表示各個測試階段，需要以軟體開發生命週期中相對產生的工作產品做為測試依歸。

## 統合流程


統合流程強調三個要點**反覆(Iterative)**、**遞增(Incremental)**與**演進(Evolutionary):**
- **反覆:** 表示系統分析、設計、實作、測試與整合是反覆不斷進行的。
- **遞增:** 表示系統的需求是逐步漸增，並非一開始就必須全部收集完整。
- **演進:** 表示系統在開發過程中是不斷的演進，而非僅在後期建置。

主要兩大特色
- **使用者案例導向(User Case Driven)**
- 以使用者的角度去檢視與設計
- **以架構為中心(Architecture-Centric)**
- 儘早建立一個基礎原件為架構(Computer-Based Architecture)
- 強調以現有元件建立系統架構
### 兩個面向 **四個階段 六個工作流**

時間面向 : **四個階段**


**細部展開階段 $\Rightarrow$ 確定設計者與顧客對系統的共識 $\Rightarrow$ 展示雛形**

- 經過多個回合(Iteration)，每回合經歷**分析、設計、實作測試**及**產出可執行版本**，但只是為了與客戶**確定需求正確**，而非移交。
- 當確定度達90%進入建構階段，此時約完成20%-30%的系統建置

內容面向 : **六個工作流**(Workflow)
1. **企業模組化工作流 (Business Modeling Workflow)**
$\Rightarrow$ 使兩端建立溝通，了解客戶
- 讓開發端了解企業內部相關的 專業領域知識 與 專業用語
2. **需求工作流 (Requirements Workflow)**
$\Rightarrow$ 了解與確認該系統所需提供的功能
- 設計師訪談客戶與使用者，然後整理並記錄所蒐集到的系統需求文件
3. **分析與設計工作流 (Analysis & Design Workflow)**
$\Rightarrow$ 作為下階段實作的依據
- 對需求內容加以分析及設計，產生各個設計模組以實踐需求
4. **實作工作流 (Implementation Workflow)**
$\Rightarrow$ 將系統設計模組轉換為程式碼
- 包含對單元模組(函數 or 類別) 進行測試
- 由於 “統合流程” 強調反覆性，系統實作在先前的回合就會進行(建構階段之前) →及早發現設計錯誤與不可行的寄宿方案
5. **測試工作流 (Test Workflow)**
$\Rightarrow$ 確認 : 單元正確整合、介面相容、是否符合需求
6. **部署工作流 (Deployment Workflow)**
$\Rightarrow$ 釋出(Release) 提供使用者安裝部署並且執行版本
- 先前的回合(移交階段)就會進行部分的部署準備(準備硬體設備、系統的資源)

## Scrum

- 一種敏捷方法
- 最短時間內，提交最高優先權的部分

### 主要角色

- 產品擁有者
- Scrum 管理員
- 開發團隊

### 開發方法

- 衝刺規劃會議
- 每日站立會議
- 衝刺審查會議
- 衝刺回顧會議

### 產出

- 產品待辦清單
- 衝刺待辦清單
- 完成進度圖