第二章 文獻探討
第一節 軟體工程
第二章 文獻探討
第一節 軟體工程
一、 傳統軟體開發方式 1. 瀑布模式
由 W.W.Royce 在 1970 年提出 Waterfall 模型，他認為開發需按照需求分析，設 計，實作，測試，上線及維護純線性進行。
圖 2-1 瀑布模式
資料來源：Royce, W. W. “Managing the development of large software systems”, Proc. Westcon, IEEE CS
Press,1970, pp. 328-339.
瀑布模型（Waterfall Model）又稱為系統發展生命週期，強調系統開發應有定 義清楚的階段，且必須完整的經歷週期之每一開發階段，在每一階段結束後產生大 量文件，為一種線性化的系統開發方式。
8
2. 漸增模式
漸增模式(Mills 1971)為瀑布模式的擴充，漸增模式是將系統劃分成數個子系統 或功能，每個子系統或功能可獨立開發，直到系統完整為止。在開發過程中每次只 交付某個子系統或功能。
3. 螺旋形模式
美國軟體工程師 Barry Boehm 於 1988 年提出螺旋模型。
圖 2-2 螺旋形模式
資料來源：Boehm, B. W. “A Spiral Model of Software Development and Enhancement,” IEEE Computer (21:5), 1988, pp. 61-72.
螺旋模型加入了其他模型沒有的風險分析，由以下的步驟構成：
(1) 確定軟體的目標，決定實施方案以及備選方案並弄清楚開發限制條件。
(2) 分析評估所選方案，辨別所存在的風險以及思考如何降低消除風險。
(3) 在可接受的風險範圍內，進行軟體開發。
(4) 由客戶評價此階段開發工作，並對下一階段進行計劃與部署。
9
4. 統一開發過程(俞君翰 2002)
1999 年 RUP 集合了各種方法論，由 UML 的三位創始人 Grady Booch 、 James Rumbaugh 及 Ivar Jacobson 共同合作提出，它所定義的是：「在軟體專案進 行當中，應有哪些參與人員，而他們誰應在何時、如何做哪些工作，以共同完成軟 體系統的開發。」
圖 2-3 RUP 模式
資料來源：俞君翰，2002，應用設計樣式於元件式系統開發之研究--以會計總帳系統為例，國立政
治大學資訊管理研究所碩士論文。
RUP 主要開發流程可分為四階段：
(1) 初始階段
此階段目標是替所要開發系統進行可行性分析，定義專案大小及涵蓋範 圍，評估專案所需的時間、經費及所需投入的人力。
(2) 精製階段
精製階段的目標是分析問題領域，擬定專案計畫，確認商業模型，透過系 統分析與設計獲知所需要的功能及非功能性需求，建立健全的系統架構，準備
10 及稽核等線性化流程的瀑布模式(Waterfall Model)(Royce 1970)，之後的漸增模式
(Incremental Model)、螺旋模式(Spiral Model)(Boehm1988)、Rational 統一開發過程 (Rational Unified Process, RUP)(Kruchten2004)，都具有固定的流程以及大量的文件產 出，在面對現今多變的商業環境，經常性需求變更的挑戰越來越高，加上使用者與開發
(The Manifesto of the Agile Alliance)，並提出了敏捷軟體開發之 12 原則(Beck et al. 2001)。
在「敏捷軟體開發宣言」中，包含了四項宣言，分別為個人及互動勝於流程與工具、
可用的軟體勝於詳盡的文件、與客戶合作勝於合約談判以及回應變更勝於墨守計畫。而 敏捷軟體開發 12 個原則如下所述：
11
Scrum 為敏捷開發方式的其中一種。Schwaber (2007)指出 Scrum 為一種反覆漸 增式軟體開發過程，和傳統增量式開發不同的地方是由一個稱為產品負責人的角色
12
表 2-1 Scrum 角色與負責工作
角色 工作
產品負責人 (Product Owner)
決定產品的功能性需求，並定義產品的交付時間、完成 的定義。
Scrum 教練 (Scrum Master)
消除團隊執行 Scrum 時的障礙，負責團隊成員間的協調 與溝通，並設法改善 Scrum 的流程。
開發團隊成員 (Team Members)
人數約 5~9 人，團隊成員熟悉產品開發所需的各項技術。 (Release Planning Meeting)
由產品負責人和客戶討論系統所需要的功能性需求，並 依需求找尋所需的開發團隊成員，組成開發團隊小組。
衝刺規劃會議 (Sprint Planning Meeting)
決定下一個衝刺期間所需完成的故事。
每日 Scrum 會議 (Daily Scrum Meeting)
每天利用 15 分鐘來進行，由 Scrum Master 詢問每個開發 (Sprint Review Meeting)
用以展示所完成的工作項目。
衝刺回顧會議 (Sprint Retrospective
Meeting)
檢討此次的衝刺該如何做改善，並對下一次的衝刺 做適當的調整，另外此次尚未做完的故事或任務都將加 回產品待辦清單中，由下一次衝刺執行。
資料來源：Sutherland, J., Schwaber, K. “The Scrum Papers: Nuts, Bolts, and Origins of an Agile
Process.,” Draft, 2007 (available online at http://scrumtraininginstitute.com/).
13
下表顯示 Scrum 過程中的各項產出:
表 2-3 Scrum 產出物
產出物名稱 產出物內容
產品待辦清單 (Product Backlog)
包含客戶所需要的功能性需求，非功能性需求則以技術故事 的方式加入產品待辦清單中。
衝刺待辦清單 (Sprint Backlog)
在每次衝刺規劃會議所決定要執行的項目紀錄。
燃盡圖 (Burndown Chart)
呈現一個時間區段中，所剩餘的工作量，使 Scrum Master 以及產品負責人可對專案工作進行有所掌握。
資料來源：Sutherland, J., Schwaber, K. “The Scrum Papers: Nuts, Bolts, and Origins of an Agile
Process.,” Draft, 2007 (available online at http://scrumtraininginstitute.com/).
Scrum 流程如下圖:
圖 2-4 Scrum 流程圖
資料來源: Sutherland, J., Schwaber, K. “The Scrum Papers: Nuts, Bolts, and Origins of an Agile Process.,” Draft, 2007 (available online at http://scrumtraininginstitute.com/).
產品負責人和客戶討論後，將初步功能性需求寫在產品待辦清單中。再和開發
14 (Rising and Janoff 2000)。
Scrum 方面可以依自己團隊情形做調整的項目如下：
Scrum 在結合最佳實務的情形下，可以提升管理效率以及產品品質(Williams et al. 2011)，但結合最佳實務並不是一次全部就加入所有最佳實務，應該是以循序的 方式，逐漸讓開發團隊熟悉再逐步導入(張嘉琪，2010)。
15
下圖為 Scrum 結合各種最佳實務:
圖 2-5 Scrum 結合各種最佳實務
資料來源：ezScrum，2011，http://scrum.tw/index.php/tw/home
下表為本研究透過 ezScrum 網站，以及研究文獻 Scrum+ Engineering Practices:
Experiences of Three Microsoft Teams (Williams et al. 2011)、一個以 Scrum 為基礎的 軟體工程實務導入方法(張嘉琪，2010)以及 JCIS:支援平台相依性建構之 Java 持續 整合系統(吳家豪 et al. 2007)所彙整出的最佳實務定義以及範例表格：
表 2-4 最佳實務的定義及範例
名稱 定義(資料來源) 實際應用例子 工具
建構管理 (Configuration
Management)
軟體產出物與釋出的 儲存到一個 Source Control System 中，使每個開發者 都可以檢視程式碼。只有 管理者可以整合到最主要 的枝幹(main branch)。存取 權限也必須控管，使得某
SVN、
CVS、
Collabnet Subversion Edge
16 (Issue tracking)
軟體生命週期中，軟 Scrum Master 輸入進議題 追蹤系統，此方式也可以 Skype 工具取代，減少輸 入進議題追蹤系統的時間 浪費。
Mantis、
BugTracker
自動化 單元測試 (Automatic unit
testing)
自動化單元測試的目
CPPUnit
程式碼檢閱 (Code review)
一個檢測程式碼的程 序，用來檢驗程式碼中是
透過資深的開發者來 檢閱程式碼和設計架構。
Jupiter、JCR
17
否有隱藏的問題，或是可 能出錯的地方，例如記憶 體洩漏(memory leak)、緩 衝區滿溢(buffer overflow）
等；同時也可以檢閱有沒 (Test-Driven Development)
在開發過程中，程式 (Refactoring)
以不影響功能的方式 改變程式的原有架構或設 計的作法，目的為提升程 式碼(code)的品質。
利用設計樣式(Design Pattern)或框架方式來為原 (Continuous
Integration)
一種透過自動化的方
JavaCIS
18 (Exception
handling)
程式執行中遭遇預期
EpiDefactor
資料來源：本研究彙整
19 (Waterfall Model)
1. 標準的發展程序，有完整的規 (Incremental
Model) (Spiral Model)
1. 利用雛型確定開發時的明確方
20
任。
Scrum 模式 (Scrum Model)
1. 專案進度非常透明化。
2. 定期的反省會議，不斷改良做 法。
3. 對於需求的改變，可快速回應。
4. 增量的開發方式，可使客戶安 心，並且確定開發方向。
1. 只提供管理的建議，缺少 開發技術上的意見。
2. 關於 backlog 如何製作管理 的文件過少。
3. 團隊成員需具備應付專案 所有面向的技術能力。
資料來源：本研究整理
21