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 管理員
• 開發團隊

開發方法

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

產出

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