|
UML软件工程组织 |
| 开发流程中的可用性 |
| Microsoft Corporation 2000年10月 |
摘要：本文讨论反复、周期性的设计过程，包括以用户为中心进行设计的四个原则、两种类型的产品设计过程，以及可用性活动如何渗透产品开发的各个阶段并为其带来益处。 目录 可用性测试为您带来的好处 简言之，如果将可用性测试从产品开发周期的一开始一直贯彻到项目的每一阶段中，将使您在最后的处理过程中省去重新开发这一环节。 本文首先讨论重复、周期性的设计过程。第一部分阐述了以用户为中心进行设计时的四个原则，这是由 Gould、Boies 和 Lewis 提出的。接下来介绍了两种类型的产品设计过程：“瀑布式”方法和“螺旋式”方法。本文的其余部分将简要介绍产品开发的各个阶段，并讨论可用性活动是如何渗透各个阶段并带来益处的。此处所述的开发阶段包括：构思、规划、开发、稳定化以及为下一版本做准备。 在您阅读各小节时，请注意用户将频繁地参与到各个过程中。用户对每个阶段的介入将会在项目的收尾阶段为您省去成本高昂的返工工作，而且这样开发出来的产品将使用户乐于使用、易于学习，并会长期使用。 反复、周期性的设计过程为以用户为中心进行的设计带来了极大的便利。以用户为中心的设计有四个重要原则，这些原则是由 Gould、Boies 和 Lewis 于 1991 年提出的：
多年来，“瀑布式”的产品设计过程是软件设计的标准。在这一方法中，项目开发通过分阶段发展的、按顺序的各个阶段进行。这种方法使用重大事件作为转变点和评估点，并认为在下一阶段开始前，前面的每一阶段均已结束。“瀑布式”的方法对于复杂的项目很有效。在复杂的项目中，多个供应商负责项目的各个方面（例如，一个供应商负责需求分析，另一个负责规范，等等）。但是，使用这种方法可能导致随着项目的进展，对项目进行更改越来越难。 相形之下，“螺旋式”的产品设计过程却是反复、周期性的 (Software Engineering Economics, Barry W. Boehm, 1981)。这一过程允许更大地发挥创造性，并且更易于随着项目的进展而对项目进行修改。在进行螺旋式的设计过程时，您会发现可在各个阶段对产品各方面的功能进行设计。这种方法可为以用户为中心的产品开发过程带来便利。 螺旋式的产品设计过程有六个阶段：构思、规划、建模、开发、稳定化以及为下一版本做准备。 产品开发的构思阶段是确定项目的目标和范围的阶段。此阶段要确立构思陈述、设计目标、风险评估以及项目构架。 在构思阶段，通常进行下列可用性活动： 环境研究 基于 Beyer 和 Hotzblatt 于 1997 年出版的 Contextual Design 一书中所述的方法，此类型的研究包括观察用户的所做所为，使您更为直观地了解用户行为。如果您尚未决定究竟要开发何种软件，但认为存在市场机会，就可使用环境研究来对活动进行研究。您可了解可为用户做些什么以及实现的难易程度。不是寻求具体的功能，而是寻求设计机会。 环境研究为项目提供工作的重心。如果项目是全新的项目，或是较全面的升级，这种方法最为适用。在进行较全面的升级或开展全新项目时，您无法全面了解用户在做什么、如何做、以及他们所面临的问题或困扰。而进行较小的升级时，您有可能从产品支持部门、先前的研究等处获得这些信息。在这种情况下，您基本上是对现有的设计加以完善，所以环境研究并不是不可或缺的。 环境研究在以下情况最为适合：项目组进行跨学科的环境研究，小组由可用性工程师带领。 竞争性测试 通过竞争性可用性测试，您可以为产品设置量化的可用性目标 — 任务完成的速度、每项任务出错的数目，等等。这种方法可对项目的成功与否进行量化的度量，即使所进行的竞争只是人工过程，而您将对此过程进行自动化。竞争性测试经常用于市场开发。当市场开发代表对竞争对手进行评估时，他们只比较产品的功能。可用性测试则更侧重于使用这些功能完成任务时的性能。 竞争性测试对仅用于公司内部的产品来说，似乎不大适用。但是，如果仔细考虑，从理论上而言，您也是在与产品的先前版本或前一个流程竞争。内部产品可能与人工过程进行竞争 — 产品必须比现有的进程更有效、更好。 进行竞争性测试的方法之一是开展研究，比较与其相竞争的产品的性能。例如，对其他人员的产品进行性能研究。在选择要测试的竞争产品时，要考虑到计算机之外的产品：如果产品涉及在线交易，则竞争性产品就可以是电子货币。从研究结果中您可以确定使用最频繁的、最重要的功能。 用户/受众分析 了解您的用户！尽可能采取各种方法来了解您的用户的特点。考虑一下如果您基于产品最终用户的特点来开发软件，可减少多少技术支持电话的数量。设想一下用户是否认为产品易于使用并且包含了他们所需的功能。问自己“对于我要创建的产品，哪些用户特点是与之相关的？”，例如：
您可以通过环境研究来获得一些此类信息。例如，您可对一些用户进行观察以得出一些假设，然后通过调研或取样来验证这些假设。您的人力资源部门或培训部门可能会具有一些相关的信息；例如每个新雇员要接受多少培训。市场研究人员也可能有此类信息。对于公司内部使用的应用程序而言，收集这些信息有时会比对外出售的应用程序简便，因为您的用户是具体的群体而不是普通大众。 规划阶段是进行首次实际设计的阶段。在此阶段中，有关用户界面的早期设想将初步成形，并着重于先前阶段未涉及的知识。原始模型可以是任何形式，如描述概念或功能的卡片、屏幕的简单描绘图纸、打印在纸上的屏幕位图图形，用 Macromedia Director 之类的程序创建的带有有限交互功能（也称为“点阅”）的联机版本，或是用 HTML 或 Microsoft Visual Basic® 创建的带有大量交互功能的联机版本。在大多数情况下，您会发现原型具有的仿真度越高，用户建议进行重大修改的可能性就越低。所以，用写在纸上的原型来开始着手测试是非常值得采取的做法。 根据您所设计的产品种类，您可能需要进行下述的一些或所有活动。如果您在规划阶段花时间来完成这些任务并使用原型，则在开发阶段碰到的可用性问题将会大为减少。 用户情况 创建您自己的用户情况概要，列出产品的典型用户能做什么，不能做什么。通过早期的环境研究和用户/受众分析，您做出一些较高级别的决策，基于这些决策进行软件设计。使用用户情节，您可创建一个有关用户使用您所设计的软件的“故事”。这些情况可以是情节串联图板、联机 Macromedia Director 电影、简单的流程图、或简单的叙述性文本。一种比较精致的用户情节模式是“日常生活”录像。这种录像把演员作为“用户”显示，这些用户在日常活动中与模拟的系统进行交互。通过用户情节可得出您在任务分析时要寻找的具体细节。 任务分析 任务分析决定了在新产品中执行任务的方式。在撰写规范之前，必须首先进行任务分析。用任务分析来确定您所规划的支持的任务是否确实能够反映现实，这一点是很重要的。对任务的逼真度进行分析。就产品的特性而言，任务的完整性如何？分析逼真度意味着观察用户完成一项任务所必须执行的所有操作；或进行表象的观察，了解用户完成所有任务或功能所需执行的所有操作。无需担心过于详尽 — 把重点放在实质内容上。 一些要考虑的问题和活动：
启发式评估 启发式评估涉及评估人员小组，这些评估人员查看界面并基于基本可用性原则来对其做出判断。启发式评估允许您在整个反复式设计过程中查找并更正可用性问题。如果您在工作进展的同时纠正问题，您将在收尾阶段节省大量工作。因为在收尾阶段，更改真实代码将更加困难而且成本更高。 如 Jakob Nielsen 在 Usability Engineering (1994) 中所述，启发式评估包括以下步骤：
在开发的早期阶段，启发式评估可能是发现可用性问题的非常有效的方法。 认知性遍历 认知性遍历的意思是，仔细检查界面要求用户执行多少步骤以及何种步骤后，才能完成某项任务，其中包含用户必须经过思考才能完成的那些步骤。您需要关注的是用户必须调用什么或用户必须进行的计算 — 认知性任务决定学习和使用您的产品的难易程度。认知性遍历可帮助您找出潜在的可用性问题，以及找出您制订的规范中的破绽！ 根据 Gregory Abowd 的 Performing a Cognitive Walkthrough，要进行认知性遍历活动，需要以下四个条件：
有了这些信息，评估人员可执行一遍上文第三项所列的操作，从而确定用户是否能够按预期要求合理执行这些步骤。 GOMS GOMS 是描述任务和用户执行该任务所需知识的方法，它是通过目标 (Goal)、操作符 (Operator)、方法 (Method) 以及选择规则 (Selection rule) 四个方面进行描述的。 Card、Moran 和 Newell 提出了原始的 GOMS 模式。他们还创建了一个简化的版本，即击键级别模型 (KLM)。Bonnie E. John 开发了并行活动版本 CPM-GOMS，而 David Kieras 则开发出定义更为严谨的版本：自然 GOMS 语言 (NGOMSL)。所有这些技术都基于同一 GOMS 概念。
GOMS 模型由对方法的描述组成，这些方法是达到目标所必需的。方法是一些步骤，这些步骤包括用户为达到目标所需执行的操作符。如果有一种以上的方法可以达到目标，则需使用选择规则来确定在此情况下哪种方法更为适用。 卡片排序 卡片排序是一种可用性技术，用于此阶段的早期，以了解用户关于信息的总体模型。卡片排序的基本任务是要让参与者按卡片上的说明对卡片进行组织，将属于同一类的项目堆放在一起。在创建好堆后，参与者还可为所创建的堆建立名称、标签或说明。 卡片排序用于：
反复可用性测试 对原型设计的反复可用性测试是另一种很有价值的方法，用于在产品周期的早期阶段确定界面是否易于用户使用。在此阶段进行更改比等到开发阶段开始后再进行更改要更容易些，并且成本更低。 您从可用性实验室可以收集的数据量取决于原型的强健性。对于纸上原型测试，可用性工程师就是计算机，并且在测试的过程中与用户在一起。 在许多种情况下，严谨的可用性测试是过犹不及的。在建模阶段，您仍可使用简化的方法进行有效的可用性测试，这些方法通常称为“打折扣的”可用性测试。 如 Jakob Nielsen 所述，反复的可用性测试包括：
开发阶段是将产品用实际的代码来实现的阶段。在此阶段中，您可以对实际产品的早期版次进行可用性测试。您仍有可能不时要用到原型，但随着时间的推移产品将逐渐完善。不是所有的功能都将在开发阶段同时完成，所以您有可能在原型和实际代码之间往复转换。 在理想条件下，您将可以把大部分时间用来进行推敲，在建模阶段就能够找出主要问题。 真实代码测试 让用户测试真实代码版本可能会有助于针对在计算机上使用产品发现问题。这些问题更有可能是设计问题而非概念问题。它们通常涉及相当低级的交互作用问题，如在屏幕上选择项目、拖放，以及仅在实际产品中才有的动态图形。对于产品的大多方面，真实代码不一定比设计上的原型或其它模型的真实度更高，所以不要拖延到有真实代码后再进行可用性测试。 可用性实验室测试 在开发阶段，您可进行可用性实验室测试，该测试类似于规划阶段的反复可用性测试。但是，由于产品的更多部分已趋于完善，您可测试更多任务。您仍可在 Director 中使用模型，或将稍做修改的版次用在可用性测试中。随着时间的推移，产品会越来越完善，原型就越来越不象一个模型了。但是，用“已完成”产品进行测试的问题在于，由于已进行了如此之多的工作，剩下的时间如此之少，您就不能指望对发现的问题做太多的修改了。 注意： 作为此任务的一部分，您还可能进行焦点组分析或群集分析，以对产品进行可用性测试。 当开发结束、错误已修正后，就进入了稳定化阶段。在此阶段中，要创建一个可发售的稳定的产品。在此阶段对可用性进行测试的重点是进行微调。新的功能以及代价高昂的可用性增强功能应被记录下来，以备下一版本使用。 基准测试 对可用性进行基准测试类似于“质量保证”中的综合测试。基准测试的目的是通过测试用户想要完成的所有顶级任务，就产品的可用性提供可靠的量化数据。这些测试的目标与其说是要找出问题（虽然找出问题是大多数可用性测试的目的），不如说是要评估产品可用性的状态。 要进行基准测试，请首先观察产品的功能，然后将这些功能按任务细分。在稳定化阶段，特别是对于复杂的产品，您将不能对用户界面进行可提高每个任务性能的修改。理想情况下，您可以确定哪些是顶级任务，并且确保大多数顶级任务都是可用的。低优先级的任务的可用性可以较低，可记录下来在将来的版本中再作改进。 将此阶段视为开始对过程进行回顾的阶段。您将全面考虑在构思阶段和规划阶段所进行的许多相同任务。例如，您将进行：
文献和书籍
|
|
版权所有：UML软件工程组织 |