概念:
「使用性工程設計」(亦稱為「使用者導向設計」)旨在建立更優秀的系統,它的做法是更充分瞭解使用者,並讓使用者參與需求、使用者介面設計以及測試工作等。基本概念會在概念:使用者導向設計 中說明,並且您在開始閱讀本概念之前,應該先閱讀該區段。此概念頁面說明 Rational Unified Process (RUP)
目前如何處理使用性工程設計技術。
角色
RUP 有一些角色會負責使用性方面的事項。系統分析師和需求
規劃人員必須善於收集及分析有關使用者、使用者作業及其環境的資訊,並在需求中反映這些資訊。這項資料是由需求
審查人員審查。測試 者和測試
分析師角色主要是負責使用性測試。使用者
介面設計師是負責使用者介面的設計和視覺化外觀。實作 者會負責選擇和/或開發使用者介面元件,以建構能發揮作用的使用者介面。
專案管理人員也會扮演關鍵的角色。他/她要讓使用者參與開發過程,並且確保開發組織具備必要技術的人員,可以參與建置可用的系統。其他角色,例如 部署管理人員、 課程編撰員、和 技術元件撰寫人員們,也都有責任確保部署的系統確實可以使用。
規範
下列幾節就以使用性最重要的一些活動和構件,來說明 RUP 規範。
從使用性的角度來看,「需求」規範會專注於:
-
建立對使用者和他們的需求的瞭解
-
指出對使用者幫助極大的使用案例。
特定的活動和構件如下所示。
活動
|
構件
|
和使用性相關的內容
|
引出關係人需求
|
關係人需求
|
此活動包括與使用者面談、問卷調查以及召開可研討會,以更充分瞭解使用者及使用者環境。這些包括:
構件範本:「關係人需求」會取得詳細的使用者設定檔,包括教育背景、電腦背景、經驗、現有環境、期望、目標等。其中也會包括問題說明以及 使用者希望的優先順序。「關係人需求」是用來產生 願景的原始資料。
|
開發願景
|
願景
|
「願景」範本的「使用者環境」區段會說明使用者的工作環境,或是 ISO 所說的「環境定義」[ISO
13407]。
「願景」範本的「使用者設定檔」區段會說明使用者的專長、技術背景、職務、成功準則、交付項目等等。ISO 將這個稱為「使用者環境定義」 [ISO 13407]。
|
尋找參與者和使用案例、建立使用案例模型結構、詳述使用案例
|
使用案例模型
|
「使用案例模型」說明使用者(人員參與者)所執行的作業(使用案例)。它會使用一般化關係,來擷取參與者間的共同點和關係。參與者會透過「這和康士坦丁的角色模型類似」,與使用案例相關聯 [CON99]。使用案例會透過通訊關聯、併入、一般化以及延伸等關係,建立結構以及和其他使用案例及參與者相關聯。
研討會是讓使用者參與的極佳方式。請參閱:使用案例研討會
|
|
參與者
|
人員參與者的特性,都會擷取作為參與者的屬性。這些包括:
-
參與者的責任範圍。
-
參與者在其中使用系統的實體環境。
-
這個參與者所代表的使用者數目。
-
參與者使用系統的頻率。
-
參與者的領域知識層次。
-
參與者的一般電腦經驗層次。
-
參與者的一般特性,如專業層次(教育)、社會蘊涵(語言)和年齡。
|
|
使用案例
|
這些可以包括康士坦丁說明的必要使用案例 [CON99] (請參閱概念:使用者導向設計,取得必要使用案例的討論說明)。給定使用案例的特定使用性需求,可以擷取作為使用案例規格中的「特殊需求」。
|
詳述軟體需求
|
增補規格
|
「增補規格」會擷取使用案例中沒有指定的需求。這包括可能和使用性息息相關的 使用性及效能需求。這裡會擷取適用於多個使用案例的一般使用性需求,以及適用的法令和使用性標準 (請參閱概念:使用者導向設計,取得有關使用性的法令與標準詳細資料)。
|
管理相依關係
|
需求屬性
|
找到使用案例和使用性需求時,也應該記下它們的重要性或優點。 這一點需要和使用者及其他關係人商議。此構件也可以擷取諸如使用案例的執行頻率之類的其他屬性。
|
審查需求
|
變更要求
|
以使用者為中心的開發作業,會盡量讓使用者參與所有需求審查。
|
收集通用詞彙
|
名詞解釋
|
擷取使用者的領域特有的通用詞彙,可以促進使用者和開發團隊的其餘成員之間的溝通和瞭解。
|
除了上述的「需求活動」外,也可能會有其他有用的技術存在。
-
親緣圖解 [HOL96、BEY98]
是一種將收集到的使用者及他們的作業資訊,放在貼紙上的技術。使用者需要和分析師分工合作,將相關的附註貼紙集中在概念群組或親緣關係中。此活動可以促進對問題、問題的相對重要性以及它們之間的關係之共同瞭解。
-
排列卡片 [CON99] 也是類似的活動,此活動會將索引卡上的資訊區分成組。卡片也可以依重要性、頻率等排序。
-
階層式作業模型 [MAY99、CON99]
會分析使用者目前執行的作業,並將其區分為階層。階層應該反映出使用者目前對其作業組織的瞭解。
在此規範中的其他某些活動會專注於塑造及設計使用者介面的外形。它們是:
活動
|
構件
|
和使用性相關的內容
|
設計使用者介面
|
分鏡腳本
導覽圖
|
此活動建立的構件通常稱為「概念設計」[FER01]。這是使用者介面本身的初始抽象概念,會擷取向使用者呈現的主視窗和導覽路徑。
此活動會專注於導向使用者介面設計的使用案例。
導覽圖,請參閱 [CON99],提供互動空間(畫面、視窗與對話框)之間的概觀與導覽途徑。
|
建立使用者介面原型
|
使用者介面原型
|
您可以製作三種基本原型:
繪圖(在紙上)
點陣圖(繪圖工具)
可執行檔(互動式)
在大部分專案中,您都應該依上面列出的次序,使用所有這三種原型。
建立使用者介面原型的主要目的,是為了能在實際開始設計和開發之前,顯現和測試系統的功能和使用性。如此,可以確保建置正確的系統,避免在開發上浪費太多時間和資源。
|
下列技術也可以在設計使用者介面時用到:
-
卡片排序 [CON99],如先前的說明,亦適用於設計使用者介面。每一個功能表項目或內容項目都會以一張卡片代表,再由使用者將卡片組織成邏輯群組。
除了上述活動外,下列「分析和設計」活動也可以補充使用者介面的設計工作:
使用者介面的實作方式會遵循一般的實作工作流程。請注意,使用者介面的實作方式,通常當作設計活動的一部分進行。
使用性測試,包括與使用性相關的 效能測試,應該在一做好使用者介面的模型或可執行原型時,就開始進行。測試應該包括驗證增補規格中擷取的測試與效能需求,或使用案例中擷取
的「特殊需求」。
使用者應該在 活動: 管理驗收測試期間,大量參與 活動: 外部測試產品以及最終的使用性 測試。
活動:開發輔助資料包括開發訓練教材以及系統輔助資料,以確保使用者能順利使用所交付的軟體產品。
專案管理是在競爭目標、管理風險以及克服限制尋求平衡的一種藝術,以便能順利交付符合客戶(付帳的人)和使用者需求的產品。從使用性工程設計的觀點而言,最重要的活動是作業:定義專案組織與人員配置。此活動會定義組織結構、外部介面以及角色和職務。這包括定義使用者參與開發流程的範圍,以及決定開發人員是否應該具有使用性工程設計方法的經驗。
環境規範包括專案或組織應該遵循的開發流程定義。 作業:製作開發案例( 工作
成果:開發案例)定義要套用哪些使用性工程設計技術,以及要如何調整各種 RUP 構件和活動,以納入這些技術。
另一項重要的活動是 作業:開發專案特定的準則,此活動會建立 工作成果:專案準則,其中會包含使用者介面準則。這些準則可協助確保使用者介面的一致性,這會是對使用性的重要輔助。它們也會擷取應該遵循的使用性原則,例如捷徑準則、還原功能、可辨識的結束程式、無模型互動等。
RUP 的軟體生命週期會隨時間分解成 4 個循序階段,每個階段都會由一個重要里程碑畫下句點;每個階段基本上就是兩個重要里程碑之間的那一段時間。在每個階段尾聲時,都會執行一項評量 ( 作業:生命週期里程碑審查),判斷是否有達到該階段的目標。若評量結果令人滿意,就可以移往下一個階段。
在每個階段內,可能會發生數次反覆。反覆是指一個完整的開發迴圈,這會發行(內部或外部)可執行的產品,這是在進行開發的最終產品的一部分,這些會在每次反覆時不斷成長,到最後變成最終的系統。這種反覆式方法可為使用性帶來許多好處。這種方法可以讓使用者提早對使用性提出意見回饋,並可以避免一頭鑽入某個不符合使用者需求的路徑太深。
使用者應該參與每一次反覆作業,以進一步修正需求、評估設計概念,以及測試/評估概念實證原型 和進化中的系統之使用性。
下列幾節說明與使用性相關的階段完成準則,以及每個階段的主要活動。
初始階段的兩個核心目標是初始階段:
-
建立專案的軟體範圍與界限條件,包括作業願景、驗收準則以及產品中要包括和不要包括的東西。
-
區分系統的重要使用案例,這是驅動主要設計取捨的主要作業情境。
從使用性工程設計的觀點來看,這表示專注於和「需求」以及「商業模型」(如果有建立的話)相關的活動。
-
建立對使用者和他們的需求的瞭解
-
指出對使用者幫助極大的使用案例。
初始階段經常也是探索一些概念設計和「概念實證」原型的時候。 若主要專案風險是和使用者介面以及使用性顧慮相關時,更加重要。使用性測試,包括與使用性相關的 效能測試,應該在一做好使用者介面的模型或可執行原型時,就開始進行。
當 RUP 處於反覆流程期間時,將會和使用者一起重新察看和審查在「初始階段」建立的構件,以管理範圍並確保進化中的的系統確實符合使用者的需求。
在詳述階段時,重點在於軟體架構,這包括使用者介面的架構。這裡會定義概念性的使用者介面,並實作重要及/或帶有風險的使用者介面設計元素。與軟體架構相關的活動一般都適用於使用者介面,有些現成的產品必須做評估、重複使用考量、選擇機制與型樣等。
這個階段專注於使用者介面設計活動,以及「分析與設計」規範的支援活動。這裡也會包括「實作與測試」,因為若要完成「詳述」,就需要評估所建構的執行系統。
使用性測試以及與使用性相關的 效能測試應該專注於增補規格中擷取的任何風險需求,或使用案例中擷取的「特殊需求」。
在建構階段時,重點是在於實作更多使用案例。這包括新增東西至使用者介面時, 仍然維持使用者介面的概念模型 以及 專案 特定準則中擷取的使用者介面準則。在新增特性時,使用性測試仍然很重要。
要選擇在每一個反覆中放置什麼樣的功能,是取決於對使用者的價值而定。
轉換階段的重點會開始移往 部署規範。在以使用者為中心的開發作業中,您不應該等到「轉換」階段才讓使用者參與。不過,使用者繼續參與時,主要是提供意見回饋。若使用者全程參與整個開發過程,正式的外部測試和驗收測試通常就會大幅減少或甚至於不需要。因為在整個開發過程中,使用者已持續提供詳細的意見回饋和核准。
訓練教材和系統輔助資料的開發作業會在「轉換」階段底定,但此作業應該盡可能在較早的階段就開始進行,以便讓使用者提供意見。
在「轉換」時,就會有一個可運作的系統可供使用者使用。最好能在轉換期間至少安排幾次反覆,以便能更正和初次發行相關的問題,並納入關鍵使用者的意見。
|