開發流程中的可用性

開發流程中的可用性

Microsoft Corporation
2000年10月

摘要：本文討論反復、周期性的設計過程，包括以用戶為中心進行設計的四個原則、兩種類型的產品設計過程，以及可用性活動如何滲透產品開發的各個階段并為其帶來益處。

目錄

• 簡介
• 使用反復、周期性的設計過程
• 構思階段
• 規劃階段
• 開發階段
• 穩定化階段
• 為下一版本做準備
• 參考文獻和資源

---

簡介

可用性測試為您帶來的好處

簡言之，如果將可用性測試從產品開發周期的一開始一直貫徹到項目的每一階段中，將使您在最后的處理過程中省去重新開發這一環節。

本文首先討論重復、周期性的設計過程。第一部分闡述了以用戶為中心進行設計時的四個原則，這是由 Gould、Boies 和 Lewis 提出的。接下來介紹了兩種類型的產品設計過程：“瀑布式”方法和“螺旋式”方法。本文的其余部分將簡要介紹產品開發的各個階段，并討論可用性活動是如何滲透各個階段并帶來益處的。此處所述的開發階段包括：構思、規劃、開發、穩定化以及為下一版本做準備。

在您閱讀各小節時，請注意用戶將頻繁地參與到各個過程中。用戶對每個階段的介入將會在項目的收尾階段為您省去成本高昂的返工工作，而且這樣開發出來的產品將使用戶樂于使用、易于學習，并會長期使用。

使用反復、周期性的設計過程

反復、周期性的設計過程為以用戶為中心進行的設計帶來了極大的便利。以用戶為中心的設計有四個重要原則，這些原則是由 Gould、Boies 和 Lewis 于 1991 年提出的：

• 及早以用戶為中心：設計人員應當在設計過程的早期就致力于了解用戶的需要。
• 綜合設計：設計的所有方面應當齊頭并進發展，而不是順次發展。使產品的內部設計與用戶界面的需要始終保持一致。
• 及早并持續性地進行測試：當前對軟件測試的唯一可行的方法是根據經驗總結出的方法，即若實際用戶認為設計是可行的，它就是可行的。通過在開發的全過程引入可用性測試，可以使用戶有機會在產品推出之前就設計提供反饋意見。
• 反復式設計：大問題往往會掩蓋小問題的存在。設計人員和開發人員應當在整個測試過程中反復對設計進行修改。

多年來，“瀑布式”的產品設計過程是軟件設計的標準。在這一方法中，項目開發通過分階段發展的、按順序的各個階段進行。這種方法使用重大事件作為轉變點和評估點，并認為在下一階段開始前，前面的每一階段均已結束?！捌俨际健钡姆椒▽τ趶碗s的項目很有效。在復雜的項目中，多個供應商負責項目的各個方面（例如，一個供應商負責需求分析，另一個負責規范，等等）。但是，使用這種方法可能導致隨著項目的進展，對項目進行更改越來越難。

相形之下，“螺旋式”的產品設計過程卻是反復、周期性的 (Software Engineering Economics, Barry W. Boehm, 1981)。這一過程允許更大地發揮創造性，并且更易于隨著項目的進展而對項目進行修改。在進行螺旋式的設計過程時，您會發現可在各個階段對產品各方面的功能進行設計。這種方法可為以用戶為中心的產品開發過程帶來便利。

螺旋式的產品設計過程有六個階段：構思、規劃、建模、開發、穩定化以及為下一版本做準備。

構思階段

產品開發的構思階段是確定項目的目標和范圍的階段。此階段要確立構思陳述、設計目標、風險評估以及項目構架。

在構思階段，通常進行下列可用性活動：

環境研究

基于 Beyer 和 Hotzblatt 于 1997 年出版的 Contextual Design 一書中所述的方法，此類型的研究包括觀察用戶的所做所為，使您更為直觀地了解用戶行為。如果您尚未決定究竟要開發何種軟件，但認為存在市場機會，就可使用環境研究來對活動進行研究。您可了解可為用戶做些什么以及實現的難易程度。不是尋求具體的功能，而是尋求設計機會。

環境研究為項目提供工作的重心。如果項目是全新的項目，或是較全面的升級，這種方法最為適用。在進行較全面的升級或開展全新項目時，您無法全面了解用戶在做什么、如何做、以及他們所面臨的問題或困擾。而進行較小的升級時，您有可能從產品支持部門、先前的研究等處獲得這些信息。在這種情況下，您基本上是對現有的設計加以完善，所以環境研究并不是不可或缺的。

環境研究在以下情況最為適合：項目組進行跨學科的環境研究，小組由可用性工程師帶領。

競爭性測試

通過競爭性可用性測試，您可以為產品設置量化的可用性目標 — 任務完成的速度、每項任務出錯的數目，等等。這種方法可對項目的成功與否進行量化的度量，即使所進行的競爭只是人工過程，而您將對此過程進行自動化。競爭性測試經常用于市場開發。當市場開發代表對競爭對手進行評估時，他們只比較產品的功能?？捎眯詼y試則更側重于使用這些功能完成任務時的性能。

競爭性測試對僅用于公司內部的產品來說，似乎不大適用。但是，如果仔細考慮，從理論上而言，您也是在與產品的先前版本或前一個流程競爭。內部產品可能與人工過程進行競爭 — 產品必須比現有的進程更有效、更好。

進行競爭性測試的方法之一是開展研究，比較與其相競爭的產品的性能。例如，對其他人員的產品進行性能研究。在選擇要測試的競爭產品時，要考慮到計算機之外的產品：如果產品涉及在線交易，則競爭性產品就可以是電子貨幣。從研究結果中您可以確定使用最頻繁的、最重要的功能。

用戶/受眾分析

了解您的用戶！盡可能采取各種方法來了解您的用戶的特點?？紤]一下如果您基于產品最終用戶的特點來開發軟件，可減少多少技術支持電話的數量。設想一下用戶是否認為產品易于使用并且包含了他們所需的功能。問自己“對于我要創建的產品，哪些用戶特點是與之相關的？”，例如：

• 計算機使用經驗
• 年齡
• 接受培訓的程度
• 用戶群之間的社會關系
• 特殊要求（可訪問性）

您可以通過環境研究來獲得一些此類信息。例如，您可對一些用戶進行觀察以得出一些假設，然后通過調研或取樣來驗證這些假設。您的人力資源部門或培訓部門可能會具有一些相關的信息；例如每個新雇員要接受多少培訓。市場研究人員也可能有此類信息。對于公司內部使用的應用程序而言，收集這些信息有時會比對外出售的應用程序簡便，因為您的用戶是具體的群體而不是普通大眾。

規劃階段

規劃階段是進行首次實際設計的階段。在此階段中，有關用戶界面的早期設想將初步成形，并著重于先前階段未涉及的知識。原始模型可以是任何形式，如描述概念或功能的卡片、屏幕的簡單描繪圖紙、打印在紙上的屏幕位圖圖形，用 Macromedia Director 之類的程序創建的帶有有限交互功能（也稱為“點閱”）的聯機版本，或是用 HTML 或 Microsoft Visual Basic® 創建的帶有大量交互功能的聯機版本。在大多數情況下，您會發現原型具有的仿真度越高，用戶建議進行重大修改的可能性就越低。所以，用寫在紙上的原型來開始著手測試是非常值得采取的做法。

根據您所設計的產品種類，您可能需要進行下述的一些或所有活動。如果您在規劃階段花時間來完成這些任務并使用原型，則在開發階段碰到的可用性問題將會大為減少。

用戶情況

創建您自己的用戶情況概要，列出產品的典型用戶能做什么，不能做什么。通過早期的環境研究和用戶/受眾分析，您做出一些較高級別的決策，基于這些決策進行軟件設計。使用用戶情節，您可創建一個有關用戶使用您所設計的軟件的“故事”。這些情況可以是情節串聯圖板、聯機 Macromedia Director 電影、簡單的流程圖、或簡單的敘述性文本。一種比較精致的用戶情節模式是“日常生活”錄像。這種錄像把演員作為“用戶”顯示，這些用戶在日?；顒又信c模擬的系統進行交互。通過用戶情節可得出您在任務分析時要尋找的具體細節。

任務分析

任務分析決定了在新產品中執行任務的方式。在撰寫規范之前，必須首先進行任務分析。用任務分析來確定您所規劃的支持的任務是否確實能夠反映現實，這一點是很重要的。對任務的逼真度進行分析。就產品的特性而言，任務的完整性如何？分析逼真度意味著觀察用戶完成一項任務所必須執行的所有操作；或進行表象的觀察，了解用戶完成所有任務或功能所需執行的所有操作。無需擔心過于詳盡 — 把重點放在實質內容上。

一些要考慮的問題和活動：

• 此環境中的任務是什么？環境研究應能幫助您找出并描述用戶所執行的任務。
• 創建順序圖，描述用戶執行的任務之間、用戶和產品之間的相互作用。
• 在構思階段確定功能的作用領域。提出問題：“我們要支持的具體任務是什么？”
• 與產品設計者一起創建情節串聯圖板或順序簡圖。

啟發式評估

啟發式評估涉及評估人員小組，這些評估人員查看界面并基于基本可用性原則來對其做出判斷。啟發式評估允許您在整個反復式設計過程中查找并更正可用性問題。如果您在工作進展的同時糾正問題，您將在收尾階段節省大量工作。因為在收尾階段，更改真實代碼將更加困難而且成本更高。

如 Jakob Nielsen 在 Usability Engineering (1994) 中所述，啟發式評估包括以下步驟：

1. 每個評估人員都瀏覽數遍界面，檢查各種對話框元素，然后將其與一些已知的可用性原則相比較。
2. 評估人員相互合作，將結果合并到列表中，列出用戶界面中的可用性問題，并注明設計方案中違反的相關可用性原則。
3. 一旦每個評估人員都分別執行了啟發式評估后，他們就集中起來將其評估結果合并在一起。

在開發的早期階段，啟發式評估可能是發現可用性問題的非常有效的方法。

認知性遍歷

認知性遍歷的意思是，仔細檢查界面要求用戶執行多少步驟以及何種步驟后，才能完成某項任務，其中包含用戶必須經過思考才能完成的那些步驟。您需要關注的是用戶必須調用什么或用戶必須進行的計算 — 認知性任務決定學習和使用您的產品的難易程度。認知性遍歷可幫助您找出潛在的可用性問題，以及找出您制訂的規范中的破綻！

根據 Gregory Abowd 的 Performing a Cognitive Walkthrough，要進行認知性遍歷活動，需要以下四個條件：

1. 對系統原型的詳盡描述，例如初級規范可提供什么樣的系統。這種描述不一定是完整的，但要相當詳盡。諸如菜單的位置或措辭這樣的細節也可能導致相當大的差異。
2. 對用戶在系統中要完成的任務的描述。該任務應當是大多數用戶將要執行的有代表性的任務。
3. 一個完整的、書面的操作清單，列出使用給定原型完成任務所需執行的操作。
4. 指出用戶的身份，以及評估人員能夠假定這些用戶已具有哪一類別的知識和經驗。

有了這些信息，評估人員可執行一遍上文第三項所列的操作，從而確定用戶是否能夠按預期要求合理執行這些步驟。

GOMS

GOMS 是描述任務和用戶執行該任務所需知識的方法，它是通過目標 (Goal)、操作符 (Operator)、方法 (Method) 以及選擇規則 (Selection rule) 四個方面進行描述的。

Card、Moran 和 Newell 提出了原始的 GOMS 模式。他們還創建了一個簡化的版本，即擊鍵級別模型 (KLM)。Bonnie E. John 開發了并行活動版本 CPM-GOMS，而 David Kieras 則開發出定義更為嚴謹的版本：自然 GOMS 語言 (NGOMSL)。所有這些技術都基于同一 GOMS 概念。

• 不言自明，目標就是指用戶的目標。用戶使用軟件要達到什么目的？在下一天、下幾分鐘、下幾秒鐘？
• 操作符是指軟件允許用戶采取的操作。
• 方法是子目標和操作符經仔細設計后得出的序列，可用來實現諸如剪切和粘貼等目標。
• 選擇規則是用戶要遵守的判定規則，以確定在特定環境下要使用的方法。

GOMS 模型由對方法的描述組成，這些方法是達到目標所必需的。方法是一些步驟，這些步驟包括用戶為達到目標所需執行的操作符。如果有一種以上的方法可以達到目標，則需使用選擇規則來確定在此情況下哪種方法更為適用。

卡片排序

卡片排序是一種可用性技術，用于此階段的早期，以了解用戶關于信息的總體模型?？ㄆ判虻幕救蝿帐且寘⑴c者按卡片上的說明對卡片進行組織，將屬于同一類的項目堆放在一起。在創建好堆后，參與者還可為所創建的堆建立名稱、標簽或說明。

卡片排序用于：

• 展示用戶對于任務范圍的總體模型。
• 展示用戶如何對項目進行分組或分類的。
• 展示用戶對項目之間的關系和相似性的看法。
• 將用戶的概念模型轉換為設計。

反復可用性測試

對原型設計的反復可用性測試是另一種很有價值的方法，用于在產品周期的早期階段確定界面是否易于用戶使用。在此階段進行更改比等到開發階段開始后再進行更改要更容易些，并且成本更低。

您從可用性實驗室可以收集的數據量取決于原型的強健性。對于紙上原型測試，可用性工程師就是計算機，并且在測試的過程中與用戶在一起。

在許多種情況下，嚴謹的可用性測試是過猶不及的。在建模階段，您仍可使用簡化的方法進行有效的可用性測試，這些方法通常稱為“打折扣的”可用性測試。

如 Jakob Nielsen 所述，反復的可用性測試包括：

1. 用戶和任務觀察 — 觀察用戶，保持安靜，讓用戶做一切通常情況下會做的操作。
2. 情況 — 使用一種可以減少功能數量、降低功能級別的建模方法。
3. 簡化的對談式測試 — 一次安排一個用戶完成一組任務，并要求用戶“發現問題就直接告知測試人員”。
4. 啟發式評估 — 基于基本可用性原則來評價界面。

開發階段

開發階段是將產品用實際的代碼來實現的階段。在此階段中，您可以對實際產品的早期版次進行可用性測試。您仍有可能不時要用到原型，但隨著時間的推移產品將逐漸完善。不是所有的功能都將在開發階段同時完成，所以您有可能在原型和實際代碼之間往復轉換。

在理想條件下，您將可以把大部分時間用來進行推敲，在建模階段就能夠找出主要問題。

真實代碼測試

讓用戶測試真實代碼版本可能會有助于針對在計算機上使用產品發現問題。這些問題更有可能是設計問題而非概念問題。它們通常涉及相當低級的交互作用問題，如在屏幕上選擇項目、拖放，以及僅在實際產品中才有的動態圖形。對于產品的大多方面，真實代碼不一定比設計上的原型或其它模型的真實度更高，所以不要拖延到有真實代碼后再進行可用性測試。

可用性實驗室測試

在開發階段，您可進行可用性實驗室測試，該測試類似于規劃階段的反復可用性測試。但是，由于產品的更多部分已趨于完善，您可測試更多任務。您仍可在 Director 中使用模型，或將稍做修改的版次用在可用性測試中。隨著時間的推移，產品會越來越完善，原型就越來越不象一個模型了。但是，用“已完成”產品進行測試的問題在于，由于已進行了如此之多的工作，剩下的時間如此之少，您就不能指望對發現的問題做太多的修改了。

注意：   作為此任務的一部分，您還可能進行焦點組分析或群集分析，以對產品進行可用性測試。

穩定化階段

當開發結束、錯誤已修正后，就進入了穩定化階段。在此階段中，要創建一個可發售的穩定的產品。在此階段對可用性進行測試的重點是進行微調。新的功能以及代價高昂的可用性增強功能應被記錄下來，以備下一版本使用。

基準測試

對可用性進行基準測試類似于“質量保證”中的綜合測試?；鶞蕼y試的目的是通過測試用戶想要完成的所有頂級任務，就產品的可用性提供可靠的量化數據。這些測試的目標與其說是要找出問題（雖然找出問題是大多數可用性測試的目的），不如說是要評估產品可用性的狀態。

要進行基準測試，請首先觀察產品的功能，然后將這些功能按任務細分。在穩定化階段，特別是對于復雜的產品，您將不能對用戶界面進行可提高每個任務性能的修改。理想情況下，您可以確定哪些是頂級任務，并且確保大多數頂級任務都是可用的。低優先級的任務的可用性可以較低，可記錄下來在將來的版本中再作改進。

為下一版本做準備

將此階段視為開始對過程進行回顧的階段。您將全面考慮在構思階段和規劃階段所進行的許多相同任務。例如，您將進行：

• 競爭性測試 — 在穩定化階段，這種測試是對自己的產品進行測試，以將其與先前收集的有關競爭產品的數據作比較。
• 現場研究 — 類似于環境研究（該研究是要了解“我們要做什么軟件？”），使用您已構建的軟件來找出存在哪些問題，可在下一版本加以解決。
• 關于事件的工具化版本研究 — 軟件的工具化版本基本上用來觀測軟件自身并在發生事件時記錄數據。您在大量會話和用戶的基礎上對產品進行測量以找到使用趨勢。

參考文獻和資源

文獻和書籍

• Boehm、Barry W.Software Engineering Economics. NY: Prentice Hall, 1981.(ISBN: 0138221227)
• Dumas、Joseph S. and Janice C. Redish.A Practical Guide to Usability Testing. London: Intellect Books, 1999. (ISBN: 1841500208)
• Helander、Martin、Thomas K. Landauer and Prasad V. Prabhu, eds.Handbook of Human-Computer Interaction. North-Holland, 1997. (ISBN: 0444818766)
• John, B. E. "Why GOMS?" ACM Interactions, vol. 2, no. 4 (1995): 80-89.
• Microsoft Site Server Development Guide
• Nielsen, Jakob. Usability Engineering. Boston: AP Professional, 1994。(ISBN: 0125184069)

原文轉自：http://www.kjueaiud.com