概念: 使用性工程設計
本準則討論「使用性工程設計」。「使用性工程設計」(亦稱為「使用者導向設計」)旨在建立更優秀的系統,它的做法是更充分瞭解使用者,並讓使用者參與需求、使用者介面設計以及測試工作等。
主要說明
概念: 

簡介

「使用性工程設計」(亦稱為「使用者導向設計」)旨在建立更優秀的系統,它的做法是更充分瞭解使用者,並讓使用者參與需求、使用者介面設計以及測試工作等。基本概念會在概念:使用者導向設計 中說明,並且您在開始閱讀本概念之前,應該先閱讀該區段。此概念頁面說明 Rational Unified Process (RUP) 目前如何處理使用性工程設計技術。

角色

RUP 有一些角色會負責使用性方面的事項。系統分析師需求 規劃人員必須善於收集及分析有關使用者、使用者作業及其環境的資訊,並在需求中反映這些資訊。這項資料是由需求 審查人員審查。測試 者測試 分析師角色主要是負責使用性測試。使用者 介面設計師是負責使用者介面的設計和視覺化外觀。實作 者會負責選擇和/或開發使用者介面元件,以建構能發揮作用的使用者介面。

專案管理人員也會扮演關鍵的角色。他/她要讓使用者參與開發過程,並且確保開發組織具備必要技術的人員,可以參與建置可用的系統。其他角色,例如 部署管理人員 課程編撰員、和 技術元件撰寫人員們,也都有責任確保部署的系統確實可以使用。

規範

下列幾節就以使用性最重要的一些活動和構件,來說明 RUP 規範。

需求

從使用性的角度來看,「需求」規範會專注於:

  • 建立對使用者和他們的需求的瞭解
  • 指出對使用者幫助極大的使用案例。

特定的活動和構件如下所示。

活動 構件 和使用性相關的內容
引出關係人需求 關係人需求

此活動包括與使用者面談、問卷調查以及召開可研討會,以更充分瞭解使用者及使用者環境。這些包括:

構件範本:「關係人需求」會取得詳細的使用者設定檔,包括教育背景、電腦背景、經驗、現有環境、期望、目標等。其中也會包括問題說明以及 使用者希望的優先順序。「關係人需求」是用來產生 願景的原始資料。

開發願景 願景

「願景」範本的「使用者環境」區段會說明使用者的工作環境,或是 ISO 所說的「環境定義」[ISO 13407]。

「願景」範本的「使用者設定檔」區段會說明使用者的專長、技術背景、職務、成功準則、交付項目等等。ISO 將這個稱為「使用者環境定義」 [ISO 13407]。

尋找參與者和使用案例建立使用案例模型結構詳述使用案例 使用案例模型

「使用案例模型」說明使用者(人員參與者)所執行的作業(使用案例)。它會使用一般化關係,來擷取參與者間的共同點和關係。參與者會透過「這和康士坦丁的角色模型類似」,與使用案例相關聯 [CON99]。使用案例會透過通訊關聯併入一般化以及延伸等關係,建立結構以及和其他使用案例及參與者相關聯。

研討會是讓使用者參與的極佳方式。請參閱:使用案例研討會

 

參與者

人員參與者的特性,都會擷取作為參與者的屬性。這些包括:

  • 參與者的責任範圍。
  • 參與者在其中使用系統的實體環境。
  • 這個參與者所代表的使用者數目。
  • 參與者使用系統的頻率。
  • 參與者的領域知識層次。
  • 參與者的一般電腦經驗層次。
  • 參與者的一般特性,如專業層次(教育)、社會蘊涵(語言)和年齡。
 

使用案例

這些可以包括康士坦丁說明的必要使用案例 [CON99] (請參閱概念:使用者導向設計,取得必要使用案例的討論說明)。給定使用案例的特定使用性需求,可以擷取作為使用案例規格中的「特殊需求」。
詳述軟體需求

增補規格

「增補規格」會擷取使用案例中沒有指定的需求。這包括可能和使用性息息相關的 使用性及效能需求。這裡會擷取適用於多個使用案例的一般使用性需求,以及適用的法令和使用性標準 (請參閱概念:使用者導向設計,取得有關使用性的法令與標準詳細資料)。
 管理相依關係  需求屬性 找到使用案例和使用性需求時,也應該記下它們的重要性或優點。 這一點需要和使用者及其他關係人商議。此構件也可以擷取諸如使用案例的執行頻率之類的其他屬性。
審查需求 變更要求 以使用者為中心的開發作業,會盡量讓使用者參與所有需求審查。
收集通用詞彙 名詞解釋 擷取使用者的領域特有的通用詞彙,可以促進使用者和開發團隊的其餘成員之間的溝通和瞭解。

除了上述的「需求活動」外,也可能會有其他有用的技術存在。

  • 親緣圖解 [HOL96BEY98] 是一種將收集到的使用者及他們的作業資訊,放在貼紙上的技術。使用者需要和分析師分工合作,將相關的附註貼紙集中在概念群組或親緣關係中。此活動可以促進對問題、問題的相對重要性以及它們之間的關係之共同瞭解。
  • 排列卡片 [CON99] 也是類似的活動,此活動會將索引卡上的資訊區分成組。卡片也可以依重要性、頻率等排序。
  • 階層式作業模型 [MAY99CON99] 會分析使用者目前執行的作業,並將其區分為階層。階層應該反映出使用者目前對其作業組織的瞭解。

分析與設計

在此規範中的其他某些活動會專注於塑造及設計使用者介面的外形。它們是:

活動

構件

和使用性相關的內容

設計使用者介面

分鏡腳本

導覽圖

此活動建立的構件通常稱為「概念設計」[FER01]。這是使用者介面本身的初始抽象概念,會擷取向使用者呈現的主視窗和導覽路徑。 此活動會專注於導向使用者介面設計的使用案例。

導覽圖,請參閱 [CON99],提供互動空間(畫面、視窗與對話框)之間的概觀與導覽途徑。

建立使用者介面原型 使用者介面原型

您可以製作三種基本原型:

繪圖(在紙上)
點陣圖(繪圖工具)
可執行檔(互動式)
在大部分專案中,您都應該依上面列出的次序,使用所有這三種原型。

建立使用者介面原型的主要目的,是為了能在實際開始設計和開發之前,顯現和測試系統的功能和使用性。如此,可以確保建置正確的系統,避免在開發上浪費太多時間和資源。


下列技術也可以在設計使用者介面時用到:

  • 卡片排序 [CON99],如先前的說明,亦適用於設計使用者介面。每一個功能表項目或內容項目都會以一張卡片代表,再由使用者將卡片組織成邏輯群組。

除了上述活動外,下列「分析和設計」活動也可以補充使用者介面的設計工作:

活動

構件

和使用性相關的內容

使用案例分析 分析類別、
使用案例實現

另請參閱:

類別設計

此活動會使用使用者介面的設計和原型結果,並設計類別。和原型不同的是,這並不是會丟棄的概念式使用者介面工作,而是要用來代表所交付系統的設計。

另請參閱下列準則:

準則:使用 UML 建置 Web 應用程式


實作

使用者介面的實作方式會遵循一般的實作工作流程。請注意,使用者介面的實作方式,通常當作設計活動的一部分進行。

測試

使用性測試,包括與使用性相關的 效能測試,應該在一做好使用者介面的模型或可執行原型時,就開始進行。測試應該包括驗證增補規格中擷取的測試與效能需求,或使用案例中擷取 的「特殊需求」。

部署

使用者應該在 活動: 管理驗收測試期間,大量參與 活動: 外部測試產品以及最終的使用性 測試

 活動:開發輔助資料包括開發訓練教材以及系統輔助資料,以確保使用者能順利使用所交付的軟體產品。

專案管理

專案管理是在競爭目標、管理風險以及克服限制尋求平衡的一種藝術,以便能順利交付符合客戶(付帳的人)和使用者需求的產品。從使用性工程設計的觀點而言,最重要的活動是作業:定義專案組織與人員配置。此活動會定義組織結構、外部介面以及角色和職務。這包括定義使用者參與開發流程的範圍,以及決定開發人員是否應該具有使用性工程設計方法的經驗。

環境

環境規範包括專案或組織應該遵循的開發流程定義。 作業:製作開發案例 工作 成果:開發案例)定義要套用哪些使用性工程設計技術,以及要如何調整各種 RUP 構件和活動,以納入這些技術。

另一項重要的活動是 作業:開發專案特定的準則,此活動會建立 工作成果:專案準則,其中會包含使用者介面準則。這些準則可協助確保使用者介面的一致性,這會是對使用性的重要輔助。它們也會擷取應該遵循的使用性原則,例如捷徑準則、還原功能、可辨識的結束程式、無模型互動等。

反覆式開發與階段

RUP 的軟體生命週期會隨時間分解成 4 個循序階段,每個階段都會由一個重要里程碑畫下句點;每個階段基本上就是兩個重要里程碑之間的那一段時間。在每個階段尾聲時,都會執行一項評量 ( 作業:生命週期里程碑審查),判斷是否有達到該階段的目標。若評量結果令人滿意,就可以移往下一個階段。

在每個階段內,可能會發生數次反覆。反覆是指一個完整的開發迴圈,這會發行(內部或外部)可執行的產品,這是在進行開發的最終產品的一部分,這些會在每次反覆時不斷成長,到最後變成最終的系統。這種反覆式方法可為使用性帶來許多好處。這種方法可以讓使用者提早對使用性提出意見回饋,並可以避免一頭鑽入某個不符合使用者需求的路徑太深。

使用者應該參與每一次反覆作業,以進一步修正需求、評估設計概念,以及測試/評估概念實證原型 和進化中的系統之使用性。

下列幾節說明與使用性相關的階段完成準則,以及每個階段的主要活動。

初始階段

初始階段的兩個核心目標是初始階段

  • 建立專案的軟體範圍與界限條件,包括作業願景、驗收準則以及產品中要包括和不要包括的東西。
  • 區分系統的重要使用案例,這是驅動主要設計取捨的主要作業情境。

從使用性工程設計的觀點來看,這表示專注於和「需求」以及「商業模型」(如果有建立的話)相關的活動。

  • 建立對使用者和他們的需求的瞭解
  • 指出對使用者幫助極大的使用案例。

初始階段經常也是探索一些概念設計和「概念實證」原型的時候。 若主要專案風險是和使用者介面以及使用性顧慮相關時,更加重要。使用性測試,包括與使用性相關的 效能測試,應該在一做好使用者介面的模型或可執行原型時,就開始進行。

詳述階段

當 RUP 處於反覆流程期間時,將會和使用者一起重新察看和審查在「初始階段」建立的構件,以管理範圍並確保進化中的的系統確實符合使用者的需求。

詳述階段時,重點在於軟體架構,這包括使用者介面的架構。這裡會定義概念性的使用者介面,並實作重要及/或帶有風險的使用者介面設計元素。與軟體架構相關的活動一般都適用於使用者介面,有些現成的產品必須做評估、重複使用考量、選擇機制與型樣等。

這個階段專注於使用者介面設計活動,以及「分析與設計」規範的支援活動。這裡也會包括「實作與測試」,因為若要完成「詳述」,就需要評估所建構的執行系統。

使用性測試以及與使用性相關的 效能測試應該專注於增補規格中擷取的任何風險需求,或使用案例中擷取的「特殊需求」。

建構階段

建構階段時,重點是在於實作更多使用案例。這包括新增東西至使用者介面時, 仍然維持使用者介面的概念模型 以及 專案 特定準則中擷取的使用者介面準則。在新增特性時,使用性測試仍然很重要。

要選擇在每一個反覆中放置什麼樣的功能,是取決於對使用者的價值而定。

轉換階段

轉換階段的重點會開始移往 部署規範。在以使用者為中心的開發作業中,您不應該等到「轉換」階段才讓使用者參與。不過,使用者繼續參與時,主要是提供意見回饋。若使用者全程參與整個開發過程,正式的外部測試和驗收測試通常就會大幅減少或甚至於不需要。因為在整個開發過程中,使用者已持續提供詳細的意見回饋和核准。

訓練教材和系統輔助資料的開發作業會在「轉換」階段底定,但此作業應該盡可能在較早的階段就開始進行,以便讓使用者提供意見。

在「轉換」時,就會有一個可運作的系統可供使用者使用。最好能在轉換期間至少安排幾次反覆,以便能更正和初次發行相關的問題,並納入關鍵使用者的意見。