严重性评级可以用来分配最多的资源来解决最严重的问题,还可以提供对额外可用性工作需求的粗略估计。如果严重性评级表明接口中仍然存在一些灾难性的可用性问题,那么发布它可能是不可取的。但是,如果有几个可用性问题本质上都被认为是装饰性的,那么人们可能会决定继续发布一个系统。
可用性问题的严重性是由三个因素组成的:
- 的频率出现问题的原因:常见还是罕见?
- 的影响如果出现问题,用户会很容易还是很难克服?
- 的持久性这是用户知道后就能解决的一次性问题,还是用户会反复被这个问题困扰?
最后,当然,我们需要评估市场影响因为某些可用性问题可能会对产品的受欢迎程度产生毁灭性的影响,即使它们“客观上”很容易克服。尽管严重性有几个组成部分,但通常将严重性的所有方面结合在一个单一的严重性评级中,作为每个可用性问题的总体评估,以促进优先级和决策。
以下0 - 4等级量表可用于评估可用性问题的严重程度:
0=我不认为这是一个可用性问题
1=只是外观问题:不需要修复,除非项目上有额外的时间
2=次要的可用性问题:修复这个问题应该给予较低的优先级
3.=主要的可用性问题:需要修复的重要问题,因此应该给予较高的优先级
4=可用性灾难:必须在产品发布之前修复这个问题
启发式评估中的严重性评级
很难从评估者那里得到良好的严重程度评估启发式评估当他们更专注于发现新的可用性问题时。而且,每个评估者只会发现少量的可用性问题,因此仅对评估者发现的问题进行严重程度评级是不完整的。相反,在实际的评估会议之后,可以通过向评估人员发送问卷来收集严重性评级,列出已经发现的完整的可用性问题集,并要求他们对每个问题的严重性进行评级。由于每个评估者只确定了列表中包含的问题的一个子集,这些问题需要以合理的深度进行描述,可能使用屏幕图作为说明。这些描述可以由评估观察员根据发现每个问题的评估人员的评论聚合而成(或者,如果使用了书面评估报告,则可以从报告中的描述来合成描述)。这些描述允许评价者相当容易地评估各种问题,即使他们没有在自己的评估会议中找到它们。通常,评估者只需要花大约30分钟来提供他们的严重性评级。值得注意的是,每个评估者应该提供独立于其他评估者的个人严重性评级。
通常,评估人员在考虑各种可用性问题的严重性时,不会访问实际的系统。评估者可以通过重新访问运行界面的部分而不是依赖于他们的内存和书面的问题描述来获得额外的见解。与此同时,毫无疑问的是,如果评估人员可以选择与系统进一步互动,他们将会更慢地得出严重程度评级。此外,如果运行原型系统需要特殊的计算机资源,或者由于保密考虑,软件分发受到限制,调度问题有时会使每个人在方便的时候都能访问计算机变得困难。
我的经验表明,来自单一评估者的严重性评级太不可靠,不值得信任。当更多的评估者被要求判断可用性问题的严重性时,平均严重性评级的质量迅速增加,并且使用从三个评估者的一组评分的平均值在许多实际用途上是令人满意的。
分享这篇文章: