软件可用性的基础知识

软件开发者的可用性基础知识XavierFerreandNataliaJuristo,UniversidadPolitecnicadeMadridHelmutWindl,SiemensAG,GermanyLarryConstantine,Constantine&Lockwood近几年来越来越多的组织开始关注可用t软件系统的可用性已经取得了可喜的进步不幸的是大部分的开发者还没接受这种新的观，所以软件产品的可用性水平并没有提高与一些人所认为的不一样，可用性并不只是用户界面的外观.可用性与系统如何与用户相互影响有关，它包括五个基本特征:学习能力，效率，用户保持时间，错误率和满意度.在这里，我们介绍一下为建立一个对可用性有要求水平的系统的一般的可用性过程.大部分的可用性从业者应用这个过程是都会做些微小的变化,而此过程是由设计-估计-重设计这种循环组成.开业者从分析指定的用户以及用户所要执行的任务开始这个过程.澄清的可用性概念ISO9241的第11个部分指出，在使用的特定的语境中，一个产品能被特定的用户使用并达到的、特定的目的，以及此目的的效力,效率,满足所能达到的程度•，这就是可用性.这个定义把系统的可用性与具体的条件，需求，用户联系起来,它要求建立基于五种特征的某种水平的可用性.可用性工程预先规定了可用性所要达到的水平，从而保证软件开发达到该水平..期间被铸造反映一些可用性专家的工程方式.也就是一个可用性特征被具体说明的过程，数量上和早期的过程,贯穿标准的过程.我们可以从各种各样的观点中找出关于可用性的话题，这就是为什么很多学科都开始解决它的原因，比如说心理学，计算机科学，和社会学等.但是这也导致了标准术语的缺乏.事实上可用性工程的术语并不是全球同用的，它不象其他的术语包含中心用法设计，前后关系设计，共享设计以及直接目的设计.所有这些体系都在一定范围内涉及到可用性工程问题的中心：从发展的第一个阶段的用户开始评估可用性.可用性特征我们不能把可用性定义为系统的具体的一个方面.它随着发展着的系统的用处而有所差异.比如说一个博物馆亭子的软件系统用起来应该对练习的要求是最低的，因为大多数人一生可能只会用到一次.可用性的某些方面:象效率（每小时的任务数）与这种系统没多大关系，但学习是很关键的.可是，一个银行收银员的系统就需要一定的训练而且要求高效率从而才能缩短用户的排队时间.由于可用性对直接学习来说过于抽象，它常被划分为文章开头提到的那五个特征.•学习能力:学习主要系统的功能并掌握得熟练一完成工作有多容易当用户完成某项工作比专家完成同样的工作所用的时间还要少时，用户花在系统上的时间常常是我们评估系统是否易掌握的依据.这个特征对新的用户很重要.•效率:用户在使用系统时单位时间所能操作的任务数.我们追求用户执行任务的最快速度.系统的可用性越高，用户就能更快的执行任务并完成工作.用户保持时间:这对间歇使用的用户很重要，它可以不必让用户又回到刚开始学的那个阶段.这个特征反映了用户在不使用一段时间后对系统如何工作的记忆的深度•错误率:这对可用性有消极的影响.它不涉及系统的错误.相反，它体现的是用户执行任务时所犯的错误的数量.良好的可用性意味着低的错误率.错误降低了效率和用户的满意度，可以说是与用户交流做事情的正确方法的一个失败之处.•满意度:这体现了用户对系统的主观印象.这些特征有是相互冲突的，这是可用性存在的一个问题.比如说，学习能力和效率经常消极得互相影响.如果既要求学习能力有要效率的话，那么系统就应该要仔细的设计.举例来说，使用加速器（执行频繁的任务的许多关键的结合）经常可以解决这些问题.重要的是系统的可用性不只是这些特征值的总和，而是没个特征都能达到一定的水平.我们还可以进一步将这些特征精确地划分成我们最感兴趣的可用性的一方面比如说，正常使用时的操作和高级功能的使用都是效率的内在特征，而第一影响则是满意度的内在特征.因此，当分析一个特殊系统的可用性时我们要把最重要的可用性特征分解到具体的级别可用性不仅与软件的交互性有关.帮助功能，用户文档，以及安装向导都与之有关.可用性和用户界面我们区别用户界面的可视部分（按扭，下拉菜单,校验盒，背景色等）和系统的交互部分来理解系统可用性的深度和广度.（通过交互作用，我们希望用户和系统间的信息交换达到和谐）仔细考虑交互性是很重要的，不只是在设计用户界面的可视化部分，设计系统的其它部分也要考虑到这些。比如说，如果一个系统必须提供持续的反馈给用户，开发者在设计耗时系统的操作时就要考虑到交互性。他们应该依此设计系统，这样就可以不断的发信息给用户界面，保证用户知晓当前的操作状态。象一些软件安装系统，系统能显示百分比进度条信息。不辛的是，经常有开发团队认为可以设计这种系统，更找不到“可用性团队”使设计一组好用的控件，添加合适的颜色结合和字体成为可能。这种想法明显是不对的。从开发过程的开始阶段，开发者就必须考虑与用户的交互性。他们对交互性的理解会最终影响到产品的可用性。软件开发的可用性提升用户的效率，满意度从而增强生产力是开发软件系统时应用可用性技术的主要原因。因此可用性技术可以通过帮助用户执行任务使软件达到它的目标。对那些计算机知识贫乏的用户或是那些没办法花很长时间来学习系统如何工作的用户，良好的可用性正变得重要起来。可用性对用户系统的可接受性来说是很关键的：如果用户认为系统无法帮助他们执行任务，他们就很可能不接受该系统。用户可能根本不使用或是接受系统后无法有效使用它。如果我们不适当的支持用户的任务，我们就满足不了用户的需求，也达不到建立一个软件系统的主要目标。对于一个在竞争性的市场中运作的软件开发组织来说，如果竞争者发布了具有更高可用性的产品而这个组织没有的话，那将导致市场分额的下降。同样，有着更好可用性的软件产品能减少维护费用（来自热线，用户支持服务等）。即使一个系统正被使用，也不必定意味着有高水平的可用性。软件的其它方面象价格，选择的可能性或事先的训练都能使它得到广泛的使用。另外在人机交互作用的过程中由于人类比计算机更机智，所以常常是人去适应计算机。然而我们不能强迫用户去适应可用性很糟的软件，因为这种适应回消极地影响效率，效力和满意度。可用性是一个软件产品成功的关键因素。可用性过程象我们提及的那样，一个系统的可用性依赖交互性的设计。因此，在整个开发的过程中，我们必须处理好系统的可用性问题。单独的可用性测试对一个高度可用的产品是不够的，因为可用性测试只是揭露而不是解决设计的问题。而且可用性测试被看成和软件的其它形式的质量保证测试是相似的，所以看法者通常会在开发周期的后期应用这种技术，这时候解决可用性问题通常变得很昂贵，如果可能的话才会去用这种技术。因此，在开发过程就估计各种结果是很重要的，这将导致一个反复的开发过程。软件开发的单纯的反复是介绍可用性技术变得几乎不可能。所有的软件应用都是帮助用户完成某种任务。在我们能够建立可用的软件根据或者说设计一个用户界面前，我们要得到使用这些工具的人群的一些信息：•谁是系统的使用者？•他们要完成的是什么？•完成这些他们需要从系统得到些什么？•系统如何提供给用户所需要的？可用性过程有助于设计者在分析阶段回答这些问题并使用户在设计阶段支持这种设计（见图1）。（图1，可用性过程）很多的可用性方法本质上都基于相同的可用性过程，所以我们从之前提及的不同可用性方法中抽象出了一个一般的可用性过程。我们希望这能让用户更简单的理解我们将要描述的不同的可用性技术。可用性分析阶段首先，我们必须知道用户及用户的需求，期望，兴趣，行为，责任。所有这些都表现了他们与系统的关系。用户分柝有很多种收集关于用户信息的方法，这取决于各种正在开发的系统以及所要付出的努力或是这个阶段的时间上的约束。主要的方法有：场所调查，中心团组，视察概观和导出数据。用户信息的主要来源是场所调查。开发者观察在那些还在使用即将被淘汰掉的系统或是没有现成的工具而只能手工完成工作的工作环境下的使用者。另外，开发者还接见用户来了解他们行为背后的动机和策略。进行用户分析和任务分析的一个众所周知的方法是前后脉络调查。这种方法提供了一种结构式的方法来收集和组织信息。一个中心团组是和一组选定的用户的有组织的讨论。目标是在某个主题上收集关于用户的观点和体会。同个话题收集多种的观点是很适当的，比如说有一个特别的软件产品用来讨论，将会得到用户对日常系统使用的更深刻的见解。调查中信息的质量取决于问题的质量。调查是单向的来源，因为与用户进行核对通常是很困难甚至是不可能的。DonA.Dillman’的著作《MailandInternetSurveys^提供了一个结构性的方法来计划，设计和指导调查。导出数据包括：热线记录，用户投诉信等等。它可能是可用含义的很好来源，但通常都很难去解释清楚。最重要的限制是这种来源是单方面的。他们记录的只是问题却没说任何关于用户喜欢的功能或是被激活的有效的使用方法。用户分析最重要的是记录，结构和组织发现的事物。任务分柝任务分析描述的是人们完成工作所用的一组技术。任务的概念类似于基于对象的软件开发中的一个事件；任务对用户来说是有意义的行为。用户分析被看做是任务分析的输入，有时两者是一起执行的。我们分析任务是因为我们能够在整个产品的开发周期过程中用本地任务来驱动和测试用户界面设计。集中于一小组任务有助于开发结果的合理化。所以我们建议通过任务的重要性很频繁度来区分任务的优先次序从而得到一小组任务。这种方法能保证你建立的系统有最重要的功能性而且产品的功用也很好。这些任务应该成为开发系统的出发点。任务分析的一种方法是以中心设计用法的方法来建立一个任务模型，通过模型驱动来设计具有高度可用性的软件应用程序，这里的任务就是我们前面说的基本使用事件，也是一个优秀的结构过程和驱动用户界面设计的基础。当我们估计出被发现的任务组，这些任务和用户能够最和谐的统一起来时，任务分析也就结束了。当用户正在执行一组任务时，我们在用户分析阶段来执行任务分析是为了了解用户经常执行的任务以及用户是如何感知这些任务的。在可选择的第一个分析之后，我们依据用户学习所要达到的目标来鉴别系统能够支持的任务。然后，我们把任务分成给用户执行的子任务和特殊的行为块，并且把鉴别出来的任务作为建立可用性规格的基础。然后我们把上述的任务例示成现实的例子并且作为可用性测试的一个参与者。可用性基准我们把可用性基准设定成定量的可用性目标，这是在系统设计开始前定义的。这些是以可用性的五个基本特征以及子特征为基础的。如果我们要为一个正在开发的系统评估可用性特征的价值就需要这些可用性基准，一组在实际操作中规定的可用性基准。我们通过为每个被评估的可用性特征建立一组基准来建立可用性基准，也就是说我们对每个可用性特征都要予以重视和考虑。我们定义这种基准是一定要用一种方法来是他们在可用性测试和用户满意情况的问卷调查时可以计算出来。表格1显示了可用性规格表的格式。（“观察结果”一列填的是在可用性测试是得到的数据。）UsabilityattributePerformanceinnormaluseMeasuringinstrument"Answerrequest'task.ValuetohemeasuredLengthoftimetakentosuccessfullyperformthetaskiminutesandseconds)Currentlevel2min,53secWorstaoceptahlelevel2min,53secPlannedtargetlevel1min,30secBestpossiblelevel50secObservedresultsFirstimpressionQuestionnaireAveragescore(range-2to2)012（表格1）我们把任务分析看成是这种行为的输入，因为大部分的可用性基准是和任务分析中的特定任务相连接的。可用性设计一旦我们分析了系统将要支持的任务，我们就可以在用户界面的概念化设计上做第一个尝试，我们将要评估这种实际并可能在下一次反复时取得进步。概念化设计在概念化设计阶段，我们定义基本的用户系统交互作用和用户界面的对象以及交互作用所发生的上下文环境。用户分析和任务分析所发现的结果是概念化设计的基础。这个阶段可交付的是典型的纸张原稿，如铅绘图画，屏幕拓印以及用户界面行为所描述的规格。概念化设计是整个过程中最重要的阶段，因为它定义了整个系统的基础。可是，设计是一个非常有创造性的过程，不可能有方法能够自动的完成。对某种设计问题我们必须创造性的适应一些设计原理和规则。（对任何设计者一不只是软件设计者《ThedesignofEverydayThings》都是一本好的读物，它通过列举日常对象的设计展现了一般的设计规则。）用户界面设计的主要规则包括：反馈，再使用，简易，结构化，容许量和用户界面的可视化。掌握可用性设计的规则是做好设计的基础。将此与成人绘画班比较，通过课程不是每个人都能成为毕加索，但是学生如果使用他们所学的规则就能画出较好的图画。提高设计能力的另一个方法是考查用户界面设计。分析你能进入的每个软件应用程序的用户界面是很有帮助的，而且有时会成为发现全新的，可选择的解决办法的灵感来源。概念化设计阶段也是一评估结果作为结束的。测试纸张原稿而不是任务组来来检查所有的可区分优先次序的任务能够被制定是个很好的主意。这个阶段的最后的测试是和用户一起进行可用性测试或是对纸张原稿的可用性的观察。可视化设让完成了概念化设计后就是这个过程的最后一步：可视化设计，这一步定义了用户界面的外观。这函概了很多细节，包括屏幕的布局，对话框组件和颜色的使用，图片和图标的设计。可视化设计也是有规则和原理的，象颜色，文本，屏幕布局，组件使用，图标设计等。这个阶段尤其需要一个专业的屏幕设计师。关于可视化和概念化设计的推荐的读物是《AboutFace》和《SoftwareforUse》，两者都介绍了许多设计的技巧°《DesigningVisualInterfaces》一书在用户界面那节主要介绍了屏幕设计和图形设计，也包括那些可视化设计的根本的原理。这个阶段可交付使用的是一定要被测试的原稿，也就是用户界面外观的具体规格，以及必须开发的行为加规格的新的组件。原型化原型不是用户界面设计单独部分，在早期的开发阶段它对执行可用性是很有价值的。当我们想要让用户在设计过程更多的参与---也就是让用户更切实的理解系统原型，抽象的技术规格不是一个好的和用户交流的途径，为此我们需要建立原型。一些原型化技术有助与执行可用性测试，而且只需要一点点的执行尝试。我们建立原型让用户通过可用性评估技术来测试可用性。软件开发对原型化技术通常都不熟悉。■纸张模型：在设计的开始阶段，设计创建纸张原稿----通常是铅笔画的或是屏幕设计的打印输出----为用户准备的。设计者会象计算机那样给用户展现在绘画元件间发生转变时将要出现的下一个元件。■奇特的OZ技术：在用户不知道的情况下，人类专家象系统那样行动回答用户的请求。用户不需使用软件只要坐在屏幕前，开发者坐在另一太计算机的前面（和用户的计算机是连网的）回答询问。这样用户就获得了使用一个真实软件的印象，这种方法比执行一个真实的软件原型来的要便宜。■特定情节，情节图版和快照：一个特定情节描述了在特殊条件下用户和系统交互作用的一个虚构的故事；快照是在一个情节里交互作用发生时被捕捉的可视的图画；情节图版是在可能的条件下快照中主要动作的集合。他们使设计队伍会考虑到为具体使用上下文时设计的适当性，使设计过程以用户为中心。可用性评估可用性评估是可用性过程的中心行为。它决定了当前可用性的水平和设计是否成功。可用性测试术语可用性测试描述的是在实验室和一组用户执行可用性测试并记录为进一步分析使用的结果的行为。不和真正的用户进行测试我们就不能预言软件系统的可用性。首先，我们须决定用来测试系统的用户组以及每组中有多少人被招募来做为测试的参与者。然后，我们要设计让参与者执行的测试任务。我们常把他们从任务的行为分析的结果中取出并应用到假象的现实生活的条件中去。一些测试的特征是需要考虑的，比如以下几点：■参与者能否向求值程序求助；■两个参与者能否共同执行各自的测试任务来观测在测试过程中交换的注释；■参与者在测试前能得到有关系统的哪些信息；■在完成预定的任务后是否要增加一个只有评估系统的时间来得到用户对系统的大体印象。在准备测试和召集测试参与者后我们开始测试，随意的记录他们的视频照相和声频录音并记录用户的在系统中的行为以备进一步分析使用（也是随意的）。一旦我们执行完所有的任务，我们就开始发现数据记录结果，为下一个循环体使用。大胆想象格式化的评估是为了寻求交互作用的那个具体方面是好的以及这样提高交互设计。这和累积性评定相反，累积性评定是在开发的最后阶段也就是系统建立好后才进行的。累积性评定的结果对产品的成行没有任何帮助。大胆想象有助于在可用性测试是进行格式化评估。在可用性测试时我们要求参与者大胆的想象，并描述他或她的行为，这样我们就能收集他们的评论。举例来讲，一个参与者可能会说：“首先，我打开文件，我在文件的图标上点了一下。但什么都么发生。我不知道这为何和网页的操作不一样。我按了回车键，它却打开了。现在我想要改变标签的颜色，我在工具菜单栏里找但是我找不到任何我想要的功能。”用户在可用性测试是的评论能够给设计最佳的系统交互提供重要的见解。具体到他们的精神过程，测试参与者能揭露隐藏着的可用性问题。格式化评估是可用性过程的经常使用的评估形式，把从用户那收集来的定性的和定量的数据结合从而来检测先前定义的可用性基准。启发式评住一个可用性专家能够执行系统的启发式评估是一些开发周期缩短以及在一个开发过程执行更多的反复体。专家会根据他或她的交互设计的体验以及大部分能接受的可用性指导方针做出批评，比如BenShneiderman和JakobNielsen做出的可用性指导方针。通过可用性测试，专家提供的反馈和用户是不同的。专家对修改提出的意见通常都是可用的，对潜在的可用性问题更为精确，比如象少牢固性和糟糕的指导性这些问题。从另一方面来说，可用性测试一定要让真实的用户执行来验证具体的可用性问题。启发式评估能够补充而不是取代可用性测试。协作的可用性观察对最终的系统，设计或来自用户观点的原型的体系考查就是协作的可用性观察。一组开发者，用户，应用程序或该领域的专家，可用性专家一起合作执行复查。协作的可用性观察（CUIs）使用启发式评估，兼职的可用性预排和专家评估的技术和功能，它比可用性测试来得快也便宜。在这些技术的背后是一组严厉的规则，这些规则是为了避免末期的用户和开发者，设计者一起讨论工作时产生的问题。CUIs比可用性测试揭露了更多的但不同的可用性缺点（每小时达100个缺点）。除效率外，有一个优点是有着不同观点和专门技术的人考查了测试的对象。另一个优点是一起参与开发的开发者们掌握了技术并知道如何是软件更容易使用。管理和组织的问题当介绍可用性时，一个组织要先依据可用性过程的意见来进行管理，并确保自身的利益。他们要接受一些最新的概念，包括在开发的最初阶段创建概念化设计和开发过程贯穿的可用性评估。<<CostJustifyingUsability^了成本效益分析的争论，它赞成执行可用性练习，当要试着取得管理义务是可用性练习是很有用的。另一个能确保管理权的是：用最近开发的或是正在被开发的系统跟一些和系统有关的用户进行录象式的可用性测试。将测试结果交给管理者，开发团队可能会对可用性测试改变态度，因为结果可能会说明系统并不象所期望的可用性那样好。把UI设计者和开发团队结合一起通常是没那么容易的，尤其是在同一段时间他们被分配了多个工程时。在一些工程中应用可用性技术的一种途径是从每个开发团队中选举出可用性方面的带头人，类似与工作过程中的模范人员。可用性的带头人学习基本的可用性技术，他们与用户交互的设计者是并列的。然后与用户交互的设计者在许多工程中扮演顾问的角色也能和每组的可用性的带头人进行交互。刚开始不要尝试全面的可用性过程。你可以先对最显著的任务中一个简单任务进行分析，然后对这些分析设定一小组可用性规格；也可以从纸张原稿的概念化设计开始；也可从和一小组用户展开的简单的可用性测试开始。你还可以扮演可用性专家的角色使用我们提过的指导方针（Shneiderman1和Nielsen5制定的）对系统进行启发式评估。从一开始就能很谦虚对你努力后获得成功是很重要的。除了增加在软件开发组织的可用性方面的知识外，在软件开发中应用可用性技术也是不简单的。软件工程师和可用性工程师对软件开发的概念是不一样的，由于术语和手续的不同两者就会发生冲突。为了创建可一让人接受的可用性概念，软件工程组织一定要在软件工程的过程中结合可用性技术，让各个领域都能接受。使用情形提供了一个好的出发点，因为是软件工程为软件开发创建了更为可用的方法。参考书L.TrennerandJ.Bawa,ThePoliticsofUsability,Springer-Verlag,London,1998.ErgonomicRequirementsforOfficeWorkwithVisualDisplayTerminals,ISO9241-11,ISO,Geneva,1998.M.Goodetal.,—User-DerivedImpactAnalysisasaToolforUsabilityEngineering,"Proc.CHIConf.HumanHumanFactorsinComputingSystems,ACMPress,NewYork,1986,pp.241-246.D.HixandH.R.Hartson,DevelopingUserInterfaces:EnsuringUsabilityThroughProductandProcess,JohnWiley&Sons,NewYork,1993.J.Nielsen,UsabilityEngineering,APProfessional,Boston,Mass.,1993.H.BeyerandK.Holtzblatt,ContextualDesign:ACustomerCenteredApproachtoSystemsDesign,MorganKaufmann,SanFrancisco,1997.D.A.Dillman,MailandIntern