关键字：用户 软件工程 可用性
“究竟用户的需要是什么？”如果Fred作为一个程序员而不是一个心理学家时他可能会提出这样一个问题。用户们通常需要更多，而开发人员似乎看上去并不能很好的领会并更好的满足他们。对于我们而言，写出可靠的代码以及为系统加载一些功能看上去似乎是不够的。那么，他们需要什么呢？ 用户真正需要的是一个好的工具。所有的软件系统，从操作系统和语言到数据输入和决策支持应用程序，都是正确的工具。终端用户希望能从我们为其设计的工具当中获取得更多，这与我们希望从我们所使用的工具所获取得更多是一样的。他们希望系统易学易用而且能有助于他们的工作。他们希望软件不要使他们的工作放慢，不能欺骗或是迷惑他们，更不能容易出错或是难以完成任务。
标准操作过程
用户界面标准和可用性方针常由于对最好的用户界面的过高期望而造成极大负担。Microsoft，Sun，IBM以及Apple都已经公布了他们的用户界面标准，而且很多公司也纷纷制定出公司自己的内部使用手册来支持已发布的标准。那么这样起了多大作用呢？ 位于Massachusetts的用户界面工程学会的Jerrold Spool的发现，现有的标准和方针仅能覆盖现实项目中的10％的问题，定制的内部手册也仅解决了另外的10％。尽管如此，在这些标准不能够解答开发者所面临的大多数难题。
有一些标准甚至是与可用性相抵触的。假设获悉男性中有十二分之一是具有不同程度的色盲，那么由此简单的规定要所有的用户界面不能有颜色。这样简单的规定有效地使有操作障碍的人得到平等对待，但也限定了用户界面是难辨认且是灰蒙蒙的。
一些过去的错误中的遗留物永存于标准中，因而促成了一些 构想笨拙的控件，例如滚动栏（见1994年8月的Windows Tech Journal中的“图形导航”）。或在Win3.X中想出10种关闭标准应用程序的方法。和标准一致固然好，但是武断的一致或是错误的一致并不能制造出更有用的软件。
这不是个容易的任务。你知道这是很难的，主要的商务软件包经常由于一些显而易见的可用性上的不足而变得费解。甚至最大的软件开发商看上去也是更多地把精力投放在艰难的实现快速变化的特性而不是交付一份有简明的可用性的产品。
并不是行业中认为可用性不重要。新的用户界面窗口小部件和GUI开发工具的广告充斥了商业杂志。关于用户界面设计的书在书店里的书柜中排列成行。所有的软件公司都详细地描述他们在昂贵的可用性试验支持下的用户界面测试程序。我们过多的关注用户界面设计--对于一些项目而言几乎是预算的三分之二--但仍然与项目的目标谬之千里。肯定在某些地方出了问题。
我们可能已经论证过我们生产肥件(fat ware)的能力，但不是我们生产出更有价值产品的能力。我们在项目重压之下作出的很多好的程序代码也许会因为大多数用户今后仅使用我们费尽心思做出的产品的极小一部份而宣告浪费。奇怪的是很多这样的功能在一堆控件，菜单，对话框之中根本不可能找得到。我们结束对那些将来没有用的特性的咒骂，并且留下有用的部分。我们也由于将简单的任务复杂化而遭到谩骂。
我们的一些为改进这种状况的所作的努力可能仅仅是使事情更糟。我们急切的使用最新的3D直观模型，却只得到不领情的用户的埋怨。他们读不懂我们的一个个灰色的对话框。我们用密密麻麻的带图标的工具条来告诉他们这里有很多功能，但是他们觉得这很难理解。可能当我们在第一步做了一个简单的界面之后我们会设计出改进了的界面向导来使复杂的界面易于使用。
一个不漂亮的事实是可用性并不是基于这些吸引人的图形、改进了的可视化控件或是活动的Agent(译注：可能是指MS-Office里的Agent)之上。你不能从3D直观图，彩色图标或是浮动工具条中获取可用性。这不仅仅涉及你使用了什么窗体控件，还包括你如何使用这些控件，以及这些控件如何整合在一起工作。
最终，可用性来自于用户界面的体系结构迎合了用户所希望的实现。这意味着你不得不通过了解用户的工作来使你的软件迎合要求。这也意味着你必须设计出整个用户界面的体系结构。这包括了用于支持这个工作的所有的结构细节以及动态行为。
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
