經驗雛型法(Prototyping)

Prototyping：經驗雛型

基本理論

Prototyping（經驗雛型方法）是在1980年代初期興起的一種軟體發展模式，其動機是希 望能在限定期限內，以最經濟而快速的方法開發出系統的原型，以便即早澄清或驗證 不明確的系統需求。

雛型方法的種類

1. 腳本法(Scenario)：

依照使用者的使用腳本，利用傳統的非電腦媒體來模擬或 敘述系統的使用情形。

2. 摹仿式(Mock-ups)：指先製作系統的部份用戶界面，針對一些需求不確定的系統 功能，預先設定固定的輸入與輸出資料，然後以作假的方式來模擬該特定的系統功能。

3. 示範式(Demonstration)：指實際開發一部份的關鍵功能，並製作相當的完整的 用戶界面，讓使用者有限度的實際操作，並從實際演練的過程中去確定系統是否滿足 重要的功能需求。

4. 遞增式(Incremental)：將整個系統分為多個子系統，定義各個子系統之間的 界面關係，然後由最關鍵的子系統開始雛型的工作，在確定了該子系統的需求之後， 完成該子系統的開發，並先將該子系統交付客戶上線使用。隨後以同樣方法逐步開 發其他子系統，直到系統完整為止。

5. 螺旋式(Spiral)：是指由系統的核心功能開始，先製作系統的第一版本，交付 給客戶使用，並收集使用者之經驗及回饋，將原係統加以修改、擴充，為次一版本。每 個版本都是一完整系統，功能與品質逐漸趨於完整。

雛型方法的優點有

1.增進用戶與分析師之間的溝通－document is hard to read2. user-oriented (用戶互導) analysis and design3. identify 衍生式之用戶需求－大部份時間，使用者並清楚他要的是什麼4. 降低風險

另一種分類方式

1. 丟棄式 (Throwaway)：品質較佳2. 演進式 (Evolutionary)：減短SDLC

開發雛型之步驟

依 Connell and Shafer(1989)之方法，開發雛型之步驟可分為三大步驟或七小驟。 前三個小步驟又稱為開發初始雛型；第四個到第六個小步驟也稱 示範評估雛型；最後一個小步驟稱為完善規格需求書。

• Step1：快速規劃 (Rapid Planning)

  產生物為「雛型計劃書」(prototype statement) 雖不列入正式的系統文件，但去是整個雛型過程的依據，大約5頁，而抱括以下項目：

1. 雛型目的：必要性及目標

2. 雛型範圍：系統功能的範圍及原因

3. 使用方法：方法及原因

4. 使用工具：工具及原因

5. 用戶責任：明確規定用戶在參與人員、資料提供與溝通之責任與義務

6. 交付項目：工作完成後必須交付之項目，通常抱括雛型本身，評估意見彙整，使用手冊初稿以及修正後之需求規格書 (software requirement specification)

7. 時程規劃：GANTT chart

• Step2：快速分析 (Rapid Analysis)

  在幾天或幾星期內，完成功能分析，資料模式分析，與用戶界面分析

• Step3：快速開發 (Rapid Development)

  一般在兩週內完成。由於時間壓力，對結構化及文件的要求不高，通常會使用非常 高階的軟體工具（因此工具的使用與選擇非常重要，其要求為高速且易於修改）。 開發的步驟分為：

1. 建立資料結構庫：統一規定共用資料的結構

2. 製作用戶界面：

§  界面的風格與佈局

§  重要的選單內容、按鈕

§  重要信息提示

§  基本錯誤信息

3. 撰寫功能程式：開發關鍵部分，並與 (1)、(2) 銜接起來

4. 整合與測試

雛型的開發工具：

5. user-interface management system (用戶界面管理系統) Visual Basic, Powerbuilder, ToolBook 與 Java & HTML 之 FORM

6. 第四代語言：dBase

7. 資料庫系統：Access

8. 可執行之高階語言 (Executable Specification Languages)

• Step4：示範與評估 (Demonstration & Evaluation)

  由於雛型方法的目標是要即早確定不確定性，因此這個步驟和 下一個步驟（Prototype Revision）是雛型發展最重要的步驟。

• Step5：雛型修改 (Prototype Revision)

  針對step4的結果，進行修改

• Step6：確定需求 (Requirement Approval)

  將 step 5 之成果再次給使用者確認「是否已將上次的缺點與問題解決了」，若發現 新問題，需不斷進行修改，直到滿意為止。 （分析師需特別注意，前一次被接受的功能，是不是在修改過程中被破壞了？？）

• Step7：完善規格需求書

軟體工程師要心理建設

• 不習慣與使用者一起工作
• 與使用者非敵對的，認認需求

第二個大步驟所需要進行的工作項目整理如下表

步驟	工作項目	備註
1.準備雛型示範	1.       辨認不同使用者角色 2.       募集示範對象 3.       選定示範的範圍 4.       準備示範腳本與講義
2.示範趨型	1.       描述示範的目的 2.       解釋示範內容及範圍 3.       開始示範 1.       開發者示範 2.       用戶自由操作
3.收集與分析使用者回饋	1.       收集使用者回饋 2.       記錄並分類回饋信息 3.       分析 i. 區分主要與次要需求 ii. 解決有衝突之需求(避免現場解決）	主要的四項問題 1. 那些功能不符需求？ 2. 還缺那些功能？ 3. 上次的問題是否修改？ 4. 修改後，是否產生新問題？
4.修改雛型	1.       決定修改範圍 2.       修改雛型 3.       適時停止遞迴	應有預估時間，以避免無止境的繼續下去
5.核定需求	1.       使用者逐步核定系統需求 2.       完成正式之需求規格書

管理上應注意的問題

雛型方法在管理上應注意的問題：

1. 表面上，似乎增加了工作，可是實際上 Prototype 可減短 SDLC，提高系統正確性 與可用性，也因此降低了開發及維護成本。

2. 人員組成約三至五位，及這些人員須兼具分析師與程式員的專長（這方面的人 員很少，專案經理須注重人才之培訓）

3. User-Oriented，因此使用者之參與及其投入之時間須列入專案成本。

4. 雛型之困難

雛型之困難

1. 缺乏prototyping之自動化工具。

2. 雛型系統缺乏一個有效的評估準則。

3. 雛型開發人在修改雛型的過程容易偏離目標。

4. 雛型需要大量用戶的參與，易使客戶方面的管理人卻步。

5. 專案經理人常有直接將雛型轉換成最終產品之傾向。

6. 專案經理人常有直接將雛型轉換成最終產品之傾向，犧牲的產品品質。

7. 雛型不適用之範圍

雛型不適用之範圍

• 系統軟體 (OS or DB) 因無特定之使用群
• 即時性控制系統 (realtime control system) (如捷運控制系統及航空控制系統)
• Embeded System (嵌入式系統) 因沒有直接的用戶界面 (AWT,PACKAGE,API)