【IT168 技术文章】

    前几天前把“软件可用性的概念”发出去后，老纳就在想一个问题，后面的文章怎么写？正而八经把本人研究过的材料一篇篇推荐出来，显然无趣得紧，老纳得想个招用一条主线将软件可用性的方方面面贯穿起来，让大家一点点走进来。不追求全面性、学术性，更多从老纳个人理解的角度，把软件可用性的外衣一层层剥去，从粉面桃腮，进一步看花红霓裳，再往里剥露出蕙质兰心。阿弥驼佛，善哉，善哉！

    主线是什么？软件可用性可以什么都是，因为大家开发产品就是为了满足用户需求，用户觉得好用了，可用性就好了，所以软件可用性涉及产品研发方方面面，所以它什么都是。因为什么都是，所以它又什么都不是。老纳想了一下，不妨先写几篇“软件可用性简介”，从几个不同角度，或不同侧面讲讲可用性是什么，然后搞一张树状图，为“软件可用性”做个家谱，把涉及可用性的各方属性定义到树状图中，这个树状图完全可以用XML一个节点、一个节点的描述出来。在这之后就可以海阔天空，很随意的去写了，每篇博客都只讲“家谱图”中的某个点，撇开枯燥理论，争取以案例为中心展开。这是白加黑结构，前面是白片，后面是黑片。老纳这不是在搞可用性吗？做博客就像做产品，希望自己的文章篇篇像iPhone，让人看着舒心，白天服白片不瞌睡，晚上服黑片睡得香。

    这一篇先讲软件可用性的工程方法。

    软件可用性工程的生命周期过程如下图：

    强调几点：第一，软件可用性工程应该是严谨、有明确定义的系统过程，它始终在UCD计划的规划与引导之下进行；第二，软件可用性工程是一个不断改进的循环过程，它的出口是“软件符合业务和可用性目标”，通俗一点讲，软件可用性完事，是在你交付东西给客户，客户检验后很高兴，要请你吃乌江活鱼的时候。第三，软件可用性重点工作的在研发前期。

    软件可用性在V开发模式中的位置：

    软件可用性工作集中在软件需求、概要设计（或称高层设计）、系统测试、验收测试这4个阶段，按大类可分为“可用性设计”与“可用性测试”两大类。

    多数UCD过程都符合ISO13407的通用纲要，即：在交互系统中以人为中心的设计过程。他们主要以一个发现过程开始，然后在研究--设计/原型--评估步骤中循环直到项目完成。整个项目创建出一个设计步骤，并且测试确保任务的结构和组织是正确的。然后每一个功能的设计用同样的迭代进行分析、设计和评估，直到所有的功能都被集成到整个设计架构。最后可用性测试提供了软件发布前的最后结果的检查。

    按通俗方式理解一下，软件可用性是产品的一项属性，同样经历需求提出、分解分配、设计、验证等环节，有点类似于产品的性能属性，在需求阶段确定总目标，形成总框架方案，然后落实到各功能环节，以及设计各个阶段，最后还得逐步合回来验证。但软件可用性更软，它涉及面更广，可用性影响产品操作方法，影响软件的功能设计。

    因为软件可用性具有“软”的特性，文献资料往往对它有多种描述，通常为讲清软件可用性，要给它定义几个维度，如雅可伯.尼尔森（Jakob Nielsen）给出一个产品的五个属性：易学性、效率、可记忆性、容错（低错误，容易恢复）和满意度。ISO924-11中对可用性的正式定义是：可用性是某个特定产品在特定使用环境下为特定用户完成特定用途时所具有的有效性（effectiveness）、效率（efficiency）和用户主观满意度（satisfaction）。另外，Whitney Quesenbery将软件可用性归纳为5E（参见http://www.wqusability.com/），即：

?   有效性（Effective）

?   效率（Efficient）

?   吸引的（Engaging）

?   容错（Error tolerant）

?   易学（Easy to learn）

    五个单词首字母都是E，比较容易记忆。

    老纳倾向于推荐采用Whitney Quesenbery的5E提法，文献《Balancing the 5Es: Usability》中对这五个E描述如下：

    有效性：

    表明软件是可用的，而且帮助用户准确地实现他们的目标。如果用户不能实际完成他们准备做的事情（或做了不必要的事情），无论体验是短是长，容易还是不容易，它可能都没有意义。最后他们没有完成任务或达到他们的目标。如果我们能够测量有效性，我们可以理解人们如何定义成功或有用，而且这个相对容易明白或更微妙。

    效率：

    效率是所做工作的速度（与精确性要求相关）。效率可以被详细地定义；例如，在一个呼叫中心，衡量客服人员一天能处理的呼叫数量。或者它是一个主观的判断，当一个任务执行“太长”或需要“太多的点击”。

    吸引的：

    关于这个的简单定义就是一个要用界面所带来的愉快、满意或兴趣程度。所有的软件都会给用户带来情绪上的影响，但这个维度的重要性随着程序的类型会发生变化。在一个工作应用中，一个吸引人的界面可以使人投入工作，帮助他在工作中建立信心，或在表达信息方式上特别容易阅读。这个可视的表示和风格或交互的质量都会使软件吸引人，或放弃。

    容错：

    容错包含产品防止错误的程度和帮助用户从错误出现中恢复。一般都被称为“错误无关”或“防止错误”，虽然错误和事故和误解。轻触鼠标就会点击一下。如果你错读了一个连接，需要按原路返回，或输入相关内容。实际测试是在错误产生时了解软件如何进行帮助的。

    易学：

    易学和产品如何支持首次引导和更深度的学习相关。一个产品可以被使用一次，或一会儿，或一天。它可以用于支持一个容易的或复杂的任务，和任务中的用户是一个专家或新手。但每一次使用，界面必须被记忆或重新学习，而且过一段时间产品可能被开发新的特性。

    Whitney Quesenbery还特别提到5E的平衡问题，可用性的每个要素对用户并非同等重要的，而且，同一产品对两类不同用户，可用性各要素的重要性也不尽相同。比如一个利润管理业务的两类用户：一个雇员和一个利润专家，就有不同的需要。对于两个用户，有效性都需要，但利润专家的需求更多地放在效率上，而对于雇员，效率与易学、容错和软件吸引人的程度相比，要被放在一个次要的地位上。所以，可用性需要以细化的方式，结合价值考虑，这要比简单的理解用户如何使用走得更远。

    再举一个例子，一个软件覆盖率测试工具，易学性与效率同等重要，而这两者有时是矛盾的，为了易学，某些测试工具只提供图形界面方式来设计测试用例，所有测试设计操作都在GUI界面点鼠标完成，很易学很易用，而事实上这类工具往往很初级，做不了多少复杂的事情，了，或者能做一些复杂事情，要不停点击鼠标，设计用例的效率很低，远没有写直接脚本来得快。但是，写脚本又附带一个问题，学习成本增加了，影响了“易学”这个维度上的可用性得分。

    根据老纳的经验，把一个产品的可用性设计好，关键在于如何恰当的权衡可用性各维度要素，分配恰当权重，以恰当方式为不同类型用户提供最合适的方案，这便是最体现可用性设计价值的地方。随便提一句，本文讲软件可用性工程方法，老纳没讲可用性设计常用方法，比如竞争产品研究、原型法、满意度调查、用户访谈、可用性测试、专家评估、认知走查等，因为在老纳看来，这些方法并不重要，都是操作层面上的事，原理层面我们先理解好，或许是个捷径。

    可用性做得好坏当然会给产品带来巨大影响，某些产品可用性改善后，可能完全脱胎换骨成另一个东西了，VcTester从V1到V2，再到V3，每个大版本在使用方式上都有大飞跃，以至于有客户骂我们：这鬼东西用法怎么又变了呢？嘿嘿！为了改善可用性附带出可用性问题了，全是老纳的功劳，谁让老纳伴随VcTester一块成长呢？如果三年前老纳就现在水平，保准VcTester很少有变化，尽量一步到位。所以，切记！千万别在产品快结束的时候才分析可用性。