Prototyping:雛型方法

The materials in this page are adopted from 季延平與郭鴻志,系統分析與設計, 華泰書局,1995。
Prototyping(雛型方法)是在1980年代初期興起的一種軟體發展模式,其動機是希 望能在限定期限內,以最經濟而快速的方法開發出系統的原型,以便即早澄清或驗證 不明確的系統需求。

雛型方法的優點有:

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

雛型方法的種類

雛型方法的種類:
  1. 腳本法(Scenario):依照使用者的使用腳本,利用傳統的非電腦媒體來模擬或 敘述系統的使用情形。
  2. 摹仿式(Mock-ups):指先製作系統的部份用戶界面,針對一些需求不確定的系統 功能,預先設定固定的輸入與輸出資料,然後以作假的方式來模擬該特定的系統功能。
  3. 示範式(Demonstration):指實際開發一部份的關鍵功能,並製作相當的完整的 用戶界面,讓使用者有限度的實際操作,並從實際演練的過程中去確定系統是否滿足 重要的功能需求。
  4. 遞增式(Incremental):將整個系統分為多個子系統,定義各個子系統之間的 界面關係,然後由最關鍵的子系統開始雛型的工作,在確定了該子系統的需求之後, 完成該子系統的開發,並先將該子系統交付客戶上線使用。隨後以同樣方法逐步開 發其他子系統,直到系統完整為止。
  5. 螺旋式(Spiral):是指由系統的核心功能開始,先製作系統的第一版本,交付 給客戶使用,並收集使用者之經驗及回饋,將原係統加以修改、擴充,為次一版本。每 個版本都是一完整系統,功能與品質逐漸趨於完整。
另一種分類方式:
  1. 丟棄式 (Throwaway):品質較佳
  2. 演進式 (Evolutionary):減短SDLC

開發雛型之步驟

依 Connell and Shafer(1989)之方法,開發雛型之步驟可分為三大步驟或七小驟。 前三個小步驟又稱為開發初始雛型;第四個到第六個小步驟也稱 示範評估雛型;最後一個小步驟稱為完善規格需求書 軟體工程師要心理建設: 第二個大步驟所需要進行的工作項目整理如下表:

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

管理上應注意的問題

雛型方法在管理上應注意的問題:
  1. 表面上,似乎增加了工作,可是實際上 Prototype 可減短 SDLC,提高系統正確性 與可用性,也因此降低了開發及維護成本。
  2. 人員組成約三至五位,及這些人員須兼具分析師與程式員的專長(這方面的人 員很少,專案經理須注重人才之培訓)
  3. User-Oriented,因此使用者之參與及其投入之時間須列入專案成本。

雛型之困難

雛型之困難:
  1. 缺乏prototyping之自動化工具。
  2. 雛型系統缺乏一個有效的評估準則。
  3. 雛型開發人在修改雛型的過程容易偏離目標。
  4. 雛型需要大量用戶的參與,易使客戶方面的管理人卻步。
  5. 專案經理人常有直接將雛型轉換成最終產品之傾向。
  6. 專案經理人常有直接將雛型轉換成最終產品之傾向,犧牲的產品品質。

雛型不適用之範圍

雛型不適用之範圍: