---
tags: 系統分析與設計, CH2
---

# 資訊系統開發模式

> 資訊系統開發模式是資訊系統開發活動的一系列步驟及執行程序。

[TOC]

---

## 學習目標

+ 資訊系統開發模式之演進與時代背景。
+ 目前有哪些常用之資訊系統開發模式。
+ 各種資訊系統開發模式之特色、應用程序及適用情況。
+ 資訊系統之特性及其適用的開發模式。
+ 如何選擇一個較適當的資訊系統開發模式 。

---

## 導論

+ 由於軟硬體技術精進、價格大幅降低，資訊系統的需求量、複雜度大幅提升，因此如何有效地開發系統是大家關心的議題。
+ <b>資訊系統開發模式(Information System Development model)</b>或稱為<b>軟體流程模式(Software Process Model)</b>是<u>資訊系統開發活動一系列的步驟及執行程序</u>。
+ 系統開發<u>依循系統化</u>、<u>邏輯化的步驟</u>進行時，<u>有利於標準</u>、<u>規範與政策</u>之推行和建立，開發的過程將更<u>有效率</u>、更能<u>確保品質</u>，也更<u>容易管理</u>。
+ 不同的資訊系統開發模式，適用於不同情況的系統開發。
+ 有的模式定義嚴謹的步驟與控制點，以處理明確需求。
+ 有的強調以快速的雛型開發，來處理不明確的需求。
+ 有的採漸增方式，以控制風險或縮短時程為主要目標。

---

### 資訊系統開發模式之演進


---

### 編碼與修正模式

+ Code-and-fix Model 是最早 (1956年之前) 使用之模式，該模式並無方法論可言。
+ 主要包含兩步驟：
+ 先寫部分程式
+ 再修正程式中之問題
+ 先編碼，再考慮需求、設計、測試與維護。
+ 主要之問題
+ 無規劃及設計，故經過幾次之修正後，程式碼的邏輯變得難以理解。
+ 過程中並無使用者需求分析與確認，軟體雖然設計得很好，但可能並不符合使用者的需求。

---

### 階段模式

+ <span style="color:red">Stagewise Model</span> 已具有方法論之雛型。
+ 強調系統開發前要<span style="color:red">有規劃</span>，程式編輯前要<span style="color:red">有分析與設計</span>，系統上線前要<span style="color:red">有測試</span>等。
+ 此模式有八個階段，每階段需依序執行。
+ 
+ 階段模式雖已改善了編碼與修正模式之缺點，但使用上仍衍生以下之問題：
+ 不論系統之大小或複雜程度均需經歷八階段。
+ 各階段之進行是循序的且階段間沒有回饋。
+ 各階段均需考量完整的系統範圍，不可僅考量部分系統。
+ 假設需求可完整且清楚地描述。

---

## 瀑布模式

+ 瀑布模式(Waterfall Model)是一種系統開發之方法。
+ 將系統開發的過程分成「幾」個階段，每個階段清楚定義要做哪些工作及交付哪些文件，各個階段循序執行且僅循環一次。
+ 當問題較小或較單純時，劃分的階段可能少至三個。
+ 例如分析、設計、實施等階段
+ 若面對較大或較複雜之問題時，其階段可能再被細分成更多個階段。
+ 例如可能擴充至十個階段
+ 瀑布模式除了在階段劃分上較有彈性外，也提供兩個主要的加強項目：
1. 若在各階段發現錯誤，可<u>允許階段間之回饋</u>，如此能儘早修正以減少系統修改或重做之成本。
2. 各階段<u>明確定義應做之工作</u>及須<u>交付之文件，</u>使系統開發之工作更明確及容易掌握。
+ 強調開發過程需有完整的規劃、分析、設計、測試及文件等管理與控制，因此能有效地確保系統品質，為業界大多數軟體開發標準。
+ 每階段結束可作為管理控制的里程碑
+ 產出都須經過<u>確認</u>(Validation)、<u>驗證</u>(Verification)或<u>測試</u>(Testing)。

---

### 三階段之瀑布模式


| 分析 | 設計 | 實施 |
| -------- | -------- | -------- |
| 1. 可行性分析<br>2. 需求分析<br>3. 系統分析 | 4. 概念性設計<br>5. 細部設計 | 6. 程式編輯與單元測試<br>7. 整合測試<br>8. 安裝與系統測試<br>9. 教育訓練<br>10. 操作與維護 |

---

### 十階段之瀑布模式


---

### 瀑布模式的系統開發程序


---

### 瀑布模式的問題

+ 在專案開始時，需求須完全且清楚地描述。
+ 所有需求在各階段均需同時考量，且系統開發須在一個週期內完成。
+ 在程式編輯前過於強調完整的分析與設計文件，故一旦需求變更，文件將需大幅修改。
+ 系統開發週期較長且過程中使用者參與不足。
+ 程式編輯於系統開發週期較後階段才開始，故風險較高，且失敗之成本亦高。

---

## 漸增模式

+ <b>漸增模式(Incremental Model)</b>是一種系統開發之方法。
+ 將需求分成「幾」個部分，然後依漸增開發計畫將每個「部分需求」之開發訂為一個開發週期，每一週期可依序或平行開發。
+ 每一週期之階段<u>清楚定義要做哪些工作</u>及<u>交付哪些文件</u>，每一階段循序進行且僅循環一次。
+ 瀑布模式的擴充，強調需求可被分成幾個<u>漸增部份</u>(<u>Increments</u>)，且漸增部份可依瀑布模式原則開發。
+ 須先經歷需求分析以完全掌握需求，接著再進行漸增開發的規劃。
+ 對系統的分析與設計採「由上而下」方式，將需求切割成若干部份或功能，並進行上層規格描述。
+ 漸增發展是每次都在系統上增加新功能、模組、元件或子系統等。
+ 漸增模式與瀑布模式大致相同，但仍有一些地方不同，例如：
1. 系統被分成幾個子系統或功能，各子系統可獨立依序開發；而瀑布模式則是各個子系統需同時開發。
2. 系統開發可由多個週期完成，每週期表示不同版本之系統，因為每週期均有程式編輯及上線實施，使用者均有參與，故漸增模式之風險較低。
+ 漸增模式**適用時機**
1. 組織的目標與需求可完全且清楚地描述。
2. 預算須分期編列，將系統做整體規劃，往後再分期執行。
3. 當組織需要時間來熟悉與接受新科技時，應用漸增模式有充裕的時間來學習與轉移技術。

---

### 漸增模式之系統開發程序


---

## 雛型模式

+ 使用者：
+ 請幫忙開發一系統能產生目前公司所用的報表。
+ 一段時間後某些報表欄位可能需調整，也可能有新報表。
+ <b>雛型模式(Prototyping Model)</b>是一種系統開發方法。
+ 先針對使用者需求較清楚的部分或資訊人員較能掌握之部分，依分析、設計與實施等步驟快速開發雛型。
+ 開發過程中，強調盡早以雛型作為使用者與資訊人員需求溝通與學習之工具，雙方透過雛型之操作與回饋，釐清、修改及擴充需求，並藉以修改與擴充雛型。上述步驟反覆進行，直到系統符合雙方約定為止。
+ <b>雛型模式之主要特性與原則</b>：
1. 強調雛型之<u>快速開發</u>及<u>使用者高度參與</u>。
2. 強調以雛型作為<u>使用者及系統開發者之需求溝通與學習機制</u>。
3. 從需求最清楚的部分著手開發雛型，並透過使用者對雛型之操作與回饋，反覆修改與擴充，每次反覆時間間隔 (週期) 要盡可能縮短。
+ <b>雛型模式的潛在問題</b>：
1. 因強調以「雛型演進」代替完整之分析與設計，故<u>系統文件較不完備</u>，<u>程式亦可能較難維護</u>。短期而言，可能較能滿足使用者需求；但對長期而言，系統較易失敗。
2. 因缺乏整體之規劃、分析與設計，故較<u>不適用於大型及多人參與之系統開發專案</u>。
+ <b>雛型模式有兩種常見之應用策略</b>：
+ 演進式雛型策略
+ 用後丟棄式雛型策略

---

### 雛型模式之系統開發程序及參與人員


---

### 演進式雛型策略

+ <b>演進式雛型策略</b> (Evolutionary Prototyping or Evolutionary Development Strategy)
+ 將所有需求看成一個整體，從需求最清楚的部分先快速經歷一系統開發週期(分析、設計與實施)，以完成初版雛型系統之開發。
+ 再利用該雛型與使用者溝通，以確定、修改和擴充需求，並藉以作為下一週期雛型演進之依據。
+ 該週期不斷地反覆進行，直到雛型系統符合雙方約定為止。

---

#### 演進式雛型策略之系統開發程序


---

### 用後丟棄式雛型策略

+ <b>用後丟棄式雛型策略</b> (Rapid Throwaway Prototyping Strategy)
+ 以一種快而粗糙的方式建立雛型
+ 以促使使用者能夠盡快藉由與雛型之互動來<u>決定需求項目</u>。
+ 或允許資訊人員<u>藉以研發問題之解決方法與資訊科技之應用</u>等。
+ 這種雛型因為用後即丟，所以<u>不需要考慮雛型系統之運用效率與可維護性</u>，也不需要考慮<u>容錯的能力</u>。
+ 用後丟棄式雛型策略若用於具高困難度之技術或設計的專案，可以藉由快速的雛型開發與檢討，<u>探索出問題之解決方法或資訊科技應用的可行性</u>。
+ 用後丟棄雛型策略<u>僅實施在風險程度最高的地方</u>。
+ 例如，在使用者需求或解決問題之知識、概念與資訊科技整合最不清楚的情況。
+ 而其他情況則盡可能地採用演進式雛型策略，因為雛型之丟棄也意謂著成本的浪費。

---

## 螺旋模式

<ul>
<li>螺旋模式(Spiral Model)之軟體開發程序是基於瀑布模式應用於政府大型軟體專案之經驗，經多次修改而成。</li>
<li>其執行由三個步驟形成一週期：</li>
<ol>
<li>找出系統的目標、可行之實施方案與限制。</li>
<li>依目標與限制評估方案。</li>
<li>由剩下之相關風險決定下一步驟該如何進行。</li>
</ol>
<li>此週期反覆進行，直到系統開發完成為止。</li>
<li><b>步驟一：找出系統的目標、可行之實施方案與限制</b></li>
<ol>
<li><span style="color:red">找出系統的目標</span></li>
<ul>
<li>系統目標之評核因素很多，例如系統的績效、功能與容忍改變之能力等。</li>
</ul>
<li><span style="color:red">找出系統之實施方案</span></li>
<ul>
<li>系統實施方案會因問題而異，例如找出之實施方案有設計方案A、設計方案B、重用、購買等。</li>
</ul>
<li><span style="color:red">實施方案之限制</span></li>
<ul>
<li>實施方案之限制可能為專案之成本、時程、系統介面等。</li>
</ul>
</ol>
<li><b>步驟二：依目標與限制評估方案</b></li>
<ul>
<li>主要是找出各方案之不確定處並設法解決，其步驟如下：</li>
</ul>
<ol>
<li><span style="color:red">找出不確定的部分</span>，也就是專案風險之重要來源。</li>
<li><span style="color:red">解決風險來源</span>。</li>
<ul>
<li>可用雛型、模擬、<b>標竿(Benchmarking)</b>、<b>參考點檢查(Reference Checking)</b>、問卷、分析模式、上述方式之綜合或其他技術以解決風險。</li>
<li>選擇風險解決方法時，應考慮成本效益。</li>
</ul>
</ol>
<li><b>步驟三：由剩下之相關風險決定下一步驟</b></li>
<ul>
<li>若績效或使用者介面風險將強力影響程式開發或內部介面控制，則下一步驟可能是採取演進式雛型策略。</li>
<li>若該雛型使用性佳且夠強韌 (Robust)，足以當作未來系統發展之基礎，則往後的步驟將是一系列的雛型演進。</li>
<li>假如先前之雛型已解決所有的績效或使用者介面之風險，且程式開發及介面控制之風險獲得掌控，則下一步將遵循基本的瀑布模式，亦可適當地修飾以整合漸增模式。</li>
</ul>
<li>螺旋模式之特色與應用原則：</li>
<ul>
<li>在高風險部分之設計尚未穩定前，規格之發展不需要一致、詳盡或正式，以避免不必要之設計修改。</li>
<li>在開發之任一階段，螺旋模式可選擇整合雛型模式以降低風險。</li>
<li>當找到更吸引人之方案或需解決新風險時，螺旋模式可整合重做或回到前面之階段。</li>
</ul>
<li>螺旋模式包容了現有軟體流程模式之大部分優點，且其風險導向之方法解決了許多系統開發模式所存在之問題。</li>
<li>在某些條件下，螺旋模式相當於某一現有之流程模式。例如：</li>
<ul>
<li>若專案在使用者介面或綜合績效需求方面屬於低風險，且在預算及時程控制方面屬於高風險，則這些風險之考量會使螺旋模式之執行相當於瀑布模式或漸增模式。</li>
<li>若專案在預算及時程控制、大型系統之整合或需求變動方面之風險較低，且在使用者介面或使用者決策支援需求方面之風險較高，則這些風險之考量會使螺旋模式之執行類似於雛型模式。</li>
</ul>
</ul>

---

### 螺旋模式之開發程序


---

## 同步模式

+ <b>同步模式(Concurrent Model)</b>源自於製造業的<b>同步工程</b>。
+ 目的在縮短開發時間、加速版本之更新。
+ 同步模式是基於三個主要的構想來達到縮短時程的目標：
1. <span style="color:red">多個團隊同時開發</span>。這種多組人同時工作的方式稱為<b>活動同步 (Activity Concurrency)</b>。
2. <span style="color:red">資訊同步</span>。不同團隊的資訊互相交流與共享，稱為<b>資訊同步 (Information Concurrency)</b>。 資訊同步有三個技巧：
1. 向前傳遞 (Front Loading)
2. 向後傳遞 (Flying)
3. 建立一個有效的資訊交換網路及支援群體工作的環境
3. <span style="color:red">整合性的管理系統</span>。同步模式的管理比一般的開 發模式複雜，必須開發一個管理系統以協調人員、資源、過程及產品間複雜的互動關係。
+ 同步模式的發展主要是為了因應商業套裝軟體的<u>市場競爭</u>。
+ 其優點是開發時間的縮短可提高產品的競爭力。
+ 其缺點則是緊湊的步驟及資訊溝通的頻繁，使得專案管理的複雜度大幅提高，人力成本也相對提高，若沒有輔以良好的工具及管理方法，則不易達成目標。
+ 比較<u>適用於商業套裝軟體的開發</u>，而客製化軟體使用同步模式的迫切性則較低。

---

### 同步模式之開發程序


---

### 同步開發與循序開發方法比較


---

### 同步開發模式


---

## Rational 統一流程模式

+ <b>RUP (Rational Unified Process)模式</b>
+ Rational Approach + Objectory Process => Rational 物件流程
+ 1998年 Jacobson 等人發展成 RUP 模式。
+ Rational Software 公司研發和維護，整合一系列軟體開發工具，提供研發團隊一嚴謹方法，以部署與管理軟體開發工作與責任。
+ 該模式<u>結合螺旋模式的概念</u>，以<u>反覆與漸增的軟體開發</u>原理進行軟體發展，且每一次的反覆後需產出一個可運作的系統版本，並在每一個反覆週期中評估風險，以盡早發現問題。
+ <b>反覆開發</b> (Iterative Development) 是反覆用相同的一系列操作或步驟進行軟體開發。
+ <b>漸增開發</b> (Incremental Development) 是每次都在軟體產品上增加新功能、 模組、 元件或子系統等。
+ RUP 模式可由動態與靜態兩構面來說明系統開發專案之實施階段與核心工作

---

### RUP 實施階段與核心工作


---

### RUP 動態面與靜態面結構

+ RUP 模式的動態面 (水平軸) 把軟體開發依序分成四主要階段：
+ <span style="color:red">初始</span>、<span style="color:red">詳述</span>、<span style="color:red">建構</span>與<span style="color:red">轉移</span>。
+ 此四階段構成一週期，週期可反覆進行，每週期內之各階段也可視情況反覆進行。
+ RUP 模式的靜態面結構 (垂直軸) 主要處理依邏輯順序將軟體開發與管理支援工作表達成九個核心工作流程：
+ <span style="color:blue"><u>軟體工程</u></span>工作：<span style="color:blue"><u>企業塑模</u></span>、<span style="color:blue"><u>需求</u></span>、<span style="color:blue"><u>分析與設計</u></span>、<span style="color:blue"><u>實作</u></span>、<span style="color:blue"><u>測試</u></span>、<span style="color:blue"><u>部署</u></span>。
+ <span style="color:green"><u>管理支援</u></span>工作：<span style="color:green"><u>組態管理與變更管理</u></span>、<span style="color:green"><u>專案管理</u></span>、<span style="color:green"><u>環境</u></span>。
+ 水平軸與垂直軸交叉格上的圖形面積代表其所對應工作之估計工作量或比率。

---

### RUP - 動態面

+ <span style="color:red">初始階段</span>：
+ 建立系統需求與範圍、接受準則並評估整體風險、構想企業個案，取得參與人員認同。
+ <span style="color:red">詳述階段</span>：
+ 處理主要的技術工作與探討技術風險。
+ <span style="color:red">建構階段</span>：
+ 建構一初步可運作的系統版本，並演化為具有完整功能的系統版本。
+ <span style="color:red">轉移階段</span>：
+ 依使用者回饋調整後，將系統産品移交客戶使用。


---

### RUP 生命週期階段、目標與里程碑


---

### RUP - 靜態面


---

### RUP - 靜態面之企業塑模

+ <b>企業塑模 (Business Modeling)</b>工作流程
+ 目的是為了瞭解系統要部署的目標組織 (Target Organization)之未來結構 (Structure) 與動態 (Dynamics) 。
+ 瞭解其目前問題與找出可能的改善方式，確保客戶、終端使用者與開發者對目標組織有共同的瞭解。
+ 及導出系統需求以支援目標組織等，並產出企業模型。
+ 為達該目的，企業模型需描述如何發展目標組織的願景，基於該願景訂定目標組織的企業模型之流程、角色與責任；該企業模型由企業使用個案模式與企業物件模式所組成。

---

### RUP - 靜態面之需求

+ <b>需求 (Requirement)</b>工作流程
+ 目的是建立與維護客戶及其他參與者對系統<u>應做什麼</u> (What) 與為何做 (Why) 之認同，提供系統開發者較好理解的系統需求；
+ 定義系統範圍，提供基準以供規劃反覆發展的技術內容；
+ 提供基準以供估算系統開發之成本與時程，及針對使用者之需求與目標定義系統之使用者介面等。
+ 為達該目的，需求必須描述如何定義系統的願景，再將願景轉換成使用個案模式，定義系統之細部軟體需求，描述如何應用需求屬性以幫助管理系統的範圍與需求變更等。

---

### RUP -- 靜態面之分析與設計

+ <b>分析與設計 (Analysis and Design)</b>工作流程
+ 目的是將需求轉換成如何<u>實作系統之規格</u>。
+ 為達到該目的，分析與設計須描述對需求之瞭解，及如何藉由選擇最佳的實施策略將需求轉換成系統設計。
+ 在專案初期須建立強韌的系統結構，以供設計一個容易瞭解、建立與演化的系統，接著調整設計以符合實作環境及績效、強韌性、可擴充性、測試性與其他品質之要求等。

---

### RUP - 靜態面之實作

+ <b>實作 (Implementation)</b> 工作流程
+ 目的是以子系統之組織階層 (Layers) 定義程式碼之組織。
+ 以元件實作類別與物件，對各元件進行單元測試。
+ 將個別實作者或團隊之成果整合成可執行的系統等。
+ 實作僅侷限於個別元件之單元測試，而系統測試與整合測試是屬於測試之工作範圍。

---

### RUP - 靜態面之測試

+ <b>測試 (Test)</b>工作流程
+ 目的是發現與紀錄軟體產品的瑕疵與問題。
+ 向管理者報告軟體品質，經由具體的系統展示評估在設計與需求規格所做的假設。
+ 驗證軟體是否能依設計運作，驗證需求是否有被適當的實作等。
+ 測試與其他RUP 模式之工作流程有一些有趣的差異，例如需求、分析與設計、實作等三項工作流程主要針對軟體產品之完整性、一致性與正確性，而測試工作流程主要針對軟體產品是否有哪些遺漏、不正確或不一致的情況。

---

### RUP - 靜態面之配置

+ <b>部署 (Deployment)</b> 工作流程
+ 目的是測試軟體在最終作業環境之運作 ( 測試) 。
+ 包裝軟體以便交付、配送軟體、安裝軟體、訓練終端使用者與銷售人員、移轉 (Migrating) 現有軟體或轉換 (Converting) 資料庫等。
+ 這些活動之實行會因不同的產業、專案規模大小、交付方式、企業環境，而有差異。

---

### RUP - 靜態面之組態管理與變更管理

+ <b>組態管理與變更管理 (Configuration and Change Management)</b>工作流程
+ 目的是追蹤與維護專案資產在演進過程之完整性 (Integrity)。
+ 在軟體發展生命週期中，會製作許多有價值的產出，這些是重要的投資，也是重要的資產，因此必須被安全地看管，且隨時可以被重用。
+ 這些產出在反覆發展過程中會被一再更新，因此版本必須被妥善管理，包括每個版本之存放位址、如何存取、為何被修改、目前之狀態與負責管理之人員等。

---

### RUP - 靜態面之專案管理

+ <b>專案管理 (Project Management)</b>工作流程
+ 目的是提供管理軟體專案的架構，提供實務準則以供規劃、人員訓練、執行與監督專案，提供管理風險的架構。
+ RUP 模式並不含括所有專案管理之議題，例如不包括人員、預算、合約管理等；而針對反覆發展之方面，例如規劃整個專案生命週期的反覆與某一個特定的反覆、風險管理、監督專案反覆與衡量之進展等。

---

### RUP - 靜態面之環境

+ <b>環境 (Environment)</b> 工作流程
+ 目的是以一些流程與工具支援軟體開發之組織。
+ 包括選擇與取得工具、裝配與配置工具以適合組織、處理組態與改善技術服務以支援流程等。

---

### RUP - 塑模元件

+ 一項核心工作流程之元素主要描述由誰做什麼、如何做、及何時做。
+ RUP 模式用四種塑模元件來描述每個核心流程工作：
+ 工作人員、活動、工作流程與產出。

1. <span style="color:red">工作人員(Worker)</span>
+ 參與專案的人在專案中所扮演的角色 (Role)
+ 例如系統分析師、專案經理等
+ 它定義每位參與者在專案中所做之流程工作、應具備的才能與應負的責任。
+ 一位參與者可以扮演一或多個角色，且不同的人可能扮演相同的角色。
2. <span style="color:red">活動 (Activity)</span>
+ 一位特定工作人員在其角色上所執行的一個工作單元。
+ 活動有清楚的目標，通常會產生或更新工作產出 (例如模式、類別或計畫)。
+ 每個活動至少會分配給一位工作人員，且須定義工作人員所應執行的工作，及活動完成後對專案會產生哪些有意義的結果，例如有哪些產出等。
3. <span style="color:red">工作流程 (Workflow)</span>
+ 是一連串活動的組合，而且這些活動會產生有價值或有意義的結果。
+ 工作流程通常會描述活動之順序，顯示工作人員所參與之活動及彼此間之互動，而且這些活動有順序地組合能產生有價值或有意義的產出。
4. <span style="color:red">產出 (Artifact)</span>
+ 經由活動或工作流程所製造、修改或使用的一件資訊。
+ 產出是專案的實際產品，也就是在產生最終產品的過程中，專案所產生或使用的東西，它可以是工作人員在執行活動時的輸入資訊，也可能是輸出資訊或結果。
+ 工作產出可能是<b>企業個案 (Business Case)</b> 或<b>軟體結構文件 (Software Architecture Document)</b> 等。
+ 產出可以用多種方式表達，包括語言、圖形、模式、多媒體等。

---

### RUP 優點

+ 清楚地定義系統發展的階段與核心工作流程。
+ 強調在各階段可反覆進行以儘早處理風險問題，並快速開發出一系統的最初版本。完成一週期後，再依相同概念進行下一週期之漸增發展。
+ 不假設在專案的起始階段需有清楚且完整的需求，而允許隨著專案的演化不斷詳述需求。
+ 可根據團隊的需求調整或擴充各階段之實施、目標與里程碑。

---

## 敏捷軟體開發

+ 一群不同軟體開發方法的領域代表於2001年共同推出<b>敏捷宣言 (Agile Manifesto)</b>。
+ 其主要目的為提出一套較傳統軟體開發方式更為簡捷且快速的軟體開發概念，此即<b>敏捷軟體開發 (Agile Software Development)</b>。
+ 敏捷軟體開發的主要開發理念和價值觀如下(Beck et al., 2001)：
1. <span style="color:red">個體與互動</span>勝於<span style="color:red">流程與工具</span>。
2. <span style="color:red">可運作的軟體</span>勝於<span style="color:red">全面性的文件</span>。
3. <span style="color:red">與客戶的協同合作</span>勝於<span style="color:red">契約談判</span>。
4. <span style="color:red">因應變化</span>勝於<span style="color:red">遵循計畫</span>。
+ 以敏捷軟體開發概念為基礎的軟體開發方法。
+ 動態系統開發方法 (Dynamic Systems Development Method, DSDM)
+ Scrum
+ 精實軟體開發 (Lean Software Development)
+ 極限編程 (Extreme Programming, XP)
+ 調適性軟體開發 (Adaptive Software Development)、水晶方法 (Crystal Method)、特色驅動開發 (Feature Driven Development)

---

### 動態系統開發方法

<ul>
<li>動態系統開發方法(Dynamic Systems Development Method, DSDM)</li>
<ul>
<li>開發過程主要以反覆與漸增的方式進行。</li>
<li>並強調使用者在開發過程中的參與。</li>
</ul>
<li>在開發過程中，動態系統開發方法會隨需求改變而反覆調整，目的在於準時且於預算內將軟體開發完成。</li>
<li>主要應用於時程緊湊且預算有限之專案。</li>
<li>動態系統開發方法實施的過程分為：<b>專案前 (Pre-Project)</b>、<b>專案生命週期 (Project Life-Cycle)</b> 和<b>專案後 (Post-Project)</b> 三個階段。</li>
<li><span style="color:red">專案生命週期</span>之主要工作可分為五個階段：</li>
<ol>
<li><b>可行性研究 (Feasibility Study)</b></li>
<ul>
<li>評估專案的型態、組織與成員是否適用於動態系統開發法。</li>
</ul>
<li><b>企業研究 (Business Study)</b></li>
<ul>
<li>分析該企業之需求與技術能力。</li>
</ul>
<li><b>反覆功能建模 (Functional Model Iteration, FMI)</b></li>
<ul>
<li>為一反覆地開發階段，最後依所定之功能模型產出功能雛型系統 (Functional Prototype) 。</li>
</ul>
<li><b>反覆設計與建置 (Design and Build Iteration, DBI)</b></li>
<ul>
<li>考量功能性與非功能性需求後，精煉前階段的雛型系統，並釋出依設計雛型 (Design prototype) 以供使用者使用與測試。</li>
</ul>
<li><b>實施 (Implementation)</b></li>
<ul>
<li>將完成的系統建置於使用者的環境中。</li>
</ul>
</ol>
</ul>

---

#### 動態系統開發方法之實施流程


---

### Scrum軟體開發

<ul>
<li>Scrum強調反覆地短期發展、檢討與調整、以自我組織與管理的目標來建立開發團隊，主張以若干個固定時間長度的衝刺 (Sprint)進行開發工作，並在每一個衝刺結束時需展示個別完成的功能。</li>
<li>軟體開發就像開發新產品，無法一開始就能清楚地定義最終產品樣式，開發過程須經歷研發、創意、嘗試錯誤等，因此沒有一種固定的流程可保證專案成功。</li>
<li>Scrum軟體開發</li>
<ul>
<li>藉由反覆地短期開發、有效控制資源、開發團隊的高度自主權及緊密地溝通合作。</li>
<li>並持續檢視成果，使團隊的開發活動變得透明、有效率且可控制。</li>
</ul>
<li>Scrum的實施流程可分為兩階段：</li>
<ul>
<li>衝刺準備階段：Scrum團隊建立、需求擷取與需求轉換。</li>
<li>衝刺進行階段：衝刺規劃、執行、成果檢視與評估。</li>
</ul>
</ul>
<ol>
<li><span style="color:red">衝刺準備階段</span></li>
<ol>
<li><b>建立Scrum團隊</b></li>
<ul>
<li>選出產品負責人、Scrum專家、開發團隊。</li>
<li>產品負責人：負責訪談客戶，定義產品需求，並承擔產品成敗責任。</li>
<li>Scrum專家：領導開發團隊依循Scrum精神來開發產品，並確定Scrum流程內的活動依正確步驟進行。</li>
<li>開發團隊：由6~10人組成的跨職能團隊，有高度的自主權，成員需具備能完成不同專案的技能。</li>
</ul>
<li><b>需求擷取</b></li>
<ul>
<li>客戶提出需求或藉由訪談客戶從訪談內容中擷取出產品需求。</li>
</ul>
<li><b>需求轉換</b></li>
<ul>
<li>將該專案之使用者需求轉換成許多個故事，這些故事的集合稱為產品清單(Product Backlog)，且此清單中之故事需要依重要性排列出執行的優先順序。</li>
</ul>
</ol>
<li><span style="color:red">衝刺進行階段</span></li>
<ol start="4">
<li><b>衝刺規劃</b></li>
<ul>
<li>產品負責人從產品清單挑選這一次衝刺所要開發的需求(故事或任務)，將每一個故事細分為若干個工作項目，並估算完成每一個工作項目所需的時間，確定每次衝刺內需要完成的工作項目、標註工作項目的優先等級，並分配給每位開發成員等。</li>
</ul>
<li><b>衝刺執行</b></li>
<ul>
<li>依衝刺清單，進行衝刺開發週期，為期1~4週的開發活動，其工作內容包含設計、編碼、整合、測試等。</li>
<li>每天召開站立會議(15分鐘)：昨天完成哪些項目、今天預計完成項目、遇到問題與阻礙。</li>
</ul>
<li><b>衝刺成果檢視</b></li>
<ul>
<li>整個Sprint週期結束，召開衝刺檢視會議 ，將成果展示給產品負責人。</li>
</ul>
<li><b>衝刺評估</b></li>
<ul>
<li>產品負責人召開自省，此會議主要目的為檢討與改善此專案的軟體開發流程，並提出改善方案。</li>
<li>Scrum專家撰寫衝刺總結報告：本次衝刺完成功能的簡述、完成多少故事、良好的及有待改善的項目、改善計畫。</li>
</ul>
<li><b>反覆</b></li>
<ul>
<li>依照同樣的步驟反覆進行每一衝刺，直到完成產品清單的所有故事。</li>
</ul>
</ol>
</ol>

<hr>

+ 故事(Story)是Scrum的一基本分析單位。
+ 以使用者觀點定義出的一些特色、一條執行路徑、或一情節(Scenario)。
+ 每一故事的長度大小必須可在一次衝刺(Sprint)中完成。
+ 故事的表達方式：
<span style="color:blue">身為【</span><span style="color:red">角色</span><span style="color:blue">】，我可以做【</span><span style="color:red">什麼行為</span><span style="color:blue">】，以達到【</span><span style="color:red">什麼目地</span><span style="color:blue">】</span>
<br><big>以遊戲軟體為例，故事表達方式</big><br>
身為【一位法師】，
我可以【對我選取範圍內的所有敵人施行流星與法術】，
使得【這些敵人受到500點傷害】。

---

#### Scrum 實施流程


---

### 精實軟體開發

+ <b>精實軟體開發 (Lean Software Development)</b>
+ 將豐田生產系統 (Toyota Productive System, TPS) 提出之<b>精實生產 (Lean Manufacturing)</b> 原則與方法，應用於軟體開發領域。
+ 包括七項原則概念：
+ 消除浪費 (Eliminate Waste)
+ 增進學習 (Amplify Learning)
+ 延遲決定 (Delay Commitment)
+ 快速遞送 (Deliver Fast)
+ 團隊授權 (Empower the Team)
+ 建置完整 (Build Integrity In)
+ 全盤檢視 (See the Whole)

---

### 極限編程

+ 極限編程 (Extreme Programming, XP)
+ 為Kent Beck 於1996年提出之軟體開發方法。
+ 著重於開發流程是否對使用者或企業產生價值，強調以有效率且富彈性 (反覆與漸增) 之方式，開發高品質之軟體系統。
+ 四項軟體開發基本行為：
1. <b>編碼 (Coding)</b>：系統開發過程中最重要的產出為可運作的程式碼，程式碼有助於找出適當的解決方案。
2. <b>測試 (Testing)</b>：若藉由小部分的測試可減少某些多餘的流程，則藉由許多的測試過程將可減少更多累贅的流程。
3. <b>傾聽 (Listening)</b>：系統開發人員必須傾聽使用者希望系統為其達成的需求，並以技術的觀點回饋使用者。
4. <b>設計 (Design)</b>：系統開發過程若不經由設計可能無法釐清系統開發的範圍，亦導致系統內協同運作的元件過度相依，即修改部分元件會影響其他運作的元件。

---

## MDA 發展生命週期

+ <b>模式驅動結構 (Model Driven Architecture, MDA)</b>
+ OMG (Object Management Group) 定義的一種軟體開發架構。
+ 關鍵是軟體開發過程中每個階段 (或步驟) 的產出均須建構出模式，且該模式之產出為下一階段的輸入。
+ MDA 與其他系統開發模式 (例如瀑布模式或RUP 模式)
+ 發展生命週期沒差別
+ 需求、分析、低階設計、程式編輯、測試與部署。
+ 主要的差別是在發展過程中步驟之產出，強調該產出是由電腦可理解的正規模式 (Formal Model) 表達。


+ MDA 有三個核心模式：
+ PIM (Platform Independent Model)
+ PSM (Platform Specific Model)
+ Code
+ <b>平台獨立模式 (PIM)</b>
+ PIM 是一種高階抽象模式，該模式與開發技術獨立。
+ PIM 是分析與設計結果的重要產出，主要根據需求塑模的結果。
+ 從如何支援企業運作的觀點描述一個軟體系統，並不涉及描述系統開發與運作之平台。
+ PIM 必須以有完整定義 (Well-Defined) 的語言來描述。
+ 一個具有完整定義的語言具有完整定義的<b>語法 (Syntax)</b> 與<b>語意 (Semantics)</b>，且適合用電腦來<b>自動解譯 (Automated Interpretation)</b>。
+ 因此，以 UML 來描述PIM 是目前最好的選擇。
+ <b>特定平台模式 (PSM)</b>
+ PSM 是一種特定平台的模式，也就是該模式相依於軟體開發技術。對某一種PSM 而言，可能僅具有該特定平台知識的開發者才能理解。
+ 一個PIM 可被轉成一至多個PSM，因為一個系統可能由數種技術開發而成，對每一個特定的技術平台需產生一個與其他技術分開的PSM，而PSM 間可藉由<b>溝通橋樑 (Communication Bridge)</b> 的機制來互動。
+ <b>程式模式 (Code)</b>
+ 每一個PSM 都需被轉成程式模式 (簡稱程式碼)，因為一個PSM 相依於其開發技術，因此PSM 轉成程式碼之步驟非常直接。
+ 若有多個PSM 則會轉出多種的程式碼，不同的程式碼間也須藉由溝通橋樑的機制來互動。
+ MDA 的每一個轉換（例如PIM→PSM，PSM→Code）須有清楚的轉換定義，且該轉換的工作是藉由CASE Tool 來執行，也就是PIM 可藉由CASE Tool 轉換成PSM，再轉換成Code。
+ MDA 之三個主要模式與轉換步驟
+ 

---

### PIM 轉PSM 轉code

+ <b>MDA 轉換程序</b>
+ 

---

## 結論

+ 系統開發模式之發展依其被提出之時間順序，依序是瀑布模式、漸增模式、雛型模式、螺旋模式、同步模式、RUP 模式、敏捷軟體開發與 MDA 模式。
+ 由於被提出之先後順序不同，後來提出的模式大多針對前面模式之問題提出修正。
+ 系統開發模式之比較，說明本章介紹之八種系統開發模式的基本假設或適用情況及其主要特徵。

---

### 系統開發模式之比較

| 模式 | 年代 | 基本假設／適用情況 | 主要特徵 |
| -------- | -------- | -------- | -------- |
| 瀑<br>布<br>模<br>式 | 1970 | 1. 使用者需求可完整且清楚地描述。<br>2. 解決問題之知識(例如模式或方法)可以得到。<br>3. 軟硬體之技術與支援沒問題。 | 1. 開發階段有清楚的定義，每階段均需考量完整的系統範圍，且各階段僅循環一次。<br>2. 強調先有完整的設計與規劃，再進行編碼。<br>3. 重視設計與規劃之文件。<br>4. 一階段的完成需經驗證通過，才能進入下一階段。 |
| 漸<br>增<br>模<br>式 | 1972 | 同上。 | 1. 開發階段有清楚的定義，把整個系統範圍分解成若干個子系統，各子系統之開發可依序以瀑布模式進行，亦可平行進行再整合。<br>2. 強調先有完整的設計與規劃，再進行編碼。<br>3. 開發週期反覆的進行。 |
| 雛<br>型<br>模<br>式 | 1977 | 1. 使用者需求無法完整且清楚地描述。<br>2. 解決問題之模式或方法無法立即得到。<br>3. 軟硬體之技術與支援不確定。 | 1. 系統開發階段無清楚之分野，且開發週期反覆地進行。<br>2. 不強調先有完整的設計與規劃再進行編碼。<br>3. 強調快速完成雛型且盡早使用，以作為雙方需求溝通與學習的工具。 |
| 螺<br>旋<br>模<br>式 | 1986 | 適用於上述各情況。| 1. 綜合上述各情況。<br>2. 強調各開發週期之規劃與風險評估。 |
| 同<br>步<br>模<br>式 | 1993 | 1. 需求可明確與完整的描述。<br>2. 有足夠的人力參與。<br>3. 團隊間有良好的溝通、資訊交換與專案管理。 | 1. 將開發工作分割並同時進行。<br>2. 系統測試不可分割，且各功能組都要執行。 |
| RUP<br>模<br>式 | 1999 | 適用於上述各情況。 | 1. 綜合上述各情況。<br>2. 強調反覆與漸增地開發，及各開發週期之規劃與風險評估。<br>3. 強調流程、工作產出與專案管理。 |
| 敏<br>捷<br>軟<br>體<br>開<br>發 | 2001 | 1. 使用者需求於開發過程中不斷變化。<br>2. 開發團隊與使用者需有良好溝通和互動的機制。 | 1. 強調開發團隊與使用者間協同合作。<br>2. 強調反覆與漸增的開發方式。<br>3. 強調隨時因應變化。 |
| MDA<br>模<br>式 | 2001 | 適用於上述各情況。 | 1. 綜合上述各情況。<br>2. 每個階段的產出均須建構模式，且該模式是下一個階段的輸入。<br>3. 各階段之產出是由電腦可理解的正規模式表達。 |