第16章软件质量保证.ppt

16.4 基于统计的质量保证 有经验的业界人士都同意下面的观点：大多数真正麻烦的缺陷都可以追溯到数量相对有限的根本原因上。对一段较长时间内发现的软件缺陷进行收集、统计，并利用统计规律对大量的缺陷数据进行深入的分析，有助于我们逐渐发现导致大部分缺陷的根本原因，从而能够将它们分离出来，集中力量予以解决。这样，就可以在SQA活动中做到“将时间集中用在真正重要的地方”，有针对性地进行质量保证活动。这种方法称之为“基于统计的质量保证”。 基于统计的SQA包括以下的步骤： (1) 收集软件缺陷信息并进行分类。 (2) 尝试对每个缺陷的成因进行追溯。 (3) 通过追溯，将少数最重要的缺陷成因分离出来。 (4)针对分离出的重要的缺陷成因，进行有针对性的改进活动。 假如一个软件开发组织在一年内利用复审、测试、用户反馈等途径搜集到了有关自身产品的错误 / 缺陷信息，尽管发现的错误 / 缺陷数以百计，但是经过归类，所有的错误/缺陷的原因都可以归为下列原因中的一个或几个： IES：说明不完整或说明错误； MCC：与客户通信中产生误解； IDS：故意与说明偏离； VPS：违犯编程标准； EDR：数据表示错误； IMI：模块接口不一致； EDL：设计逻辑有错； IET：不完整的或错误的测试； IID：不准确或不完整的文档； PLT：将设计翻译成预定语言时的错误； HCI：不清晰或不一致的人机界面； MIS：杂项。 设计一张表格，将各类错误/缺陷的统计数据和它们各自在所有错误/缺陷中所占的比例计算出来，以此数值为键值进行降序排序，造成所有错误/缺陷的重要原因就能够十分清晰地凸现出来。表16.3中显示IES、MCC和EDR是导致发生53%的错误/缺陷的“少数重要原因”。同时可以看出，如果我们将注意力集中到严重错误的成因上，那么应该将IES、EDR、PLT和EDL作为“少数重要原因”。 一旦确定了“少数重要原因”， 开发组织就可以采取改进行动。例如，为了改正MCC错误，开发者可以采用更便于理解的软件说明技术，提高和用户通信交流的质量。为了改正EDR导致的错误，可以使用CASE工具进行数据建模，并进行更加严格的数据设计复审。 当导致错误和缺陷的少数重要原因被识别、纠正后，一些原来不那么重要的原因会成为统计数据表中新的“少数重要原因”。 这样，SQA活动能够始终针对当前导致错误和缺陷的主要原因展开工作，取得事半功倍的效果。这也就是基于统计的质量保证活动价值之所在。 表16.3 统计SQA的数据收集与分类 错误 类别 错误总计 严重错误 一般错误 轻微错误 数量 百分比 数量 百分比 数量 百分比 数量 百分比 IES 205 22% 34 27% 68 18% 103 24% MCC 156 17% 12 9% 68 18% 76 17% IDS 48 5% 1 1% 24 6% 23 5% VPS 25 3% 0 0% 15 4% 10 2% EDR 130 14% 26 20% 68 18% 36 8 IMI 58 6% 9 7% 18 5% 31 7% EDL 45 5% 14 11% 12 3% 19 4% IET 95 10% 12 9% 35 9% 48 11% IID 36 4% 2 2% 20 5% 14 3% PLT 60 6% 15 12% 19 5% 26 6% HCI 28 3% 3 2% 17 4% 8 2% MIS 56 6% 0 0% 15 4% 41 9% 统计值 942 100% 128 100% 379 100% 435 100% 16.5 软 件 可 靠 性 16.5.1 可靠性和可用性 软件可靠性的含义是：“程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率”。在这个定义中包含的随机变量是“时间间隔”。显然随着运行时间的增加，运行时遇到程序故障的概率也将增加，即可靠性随着时间间隔的加大而减小。 除可靠性之外，用户也非常关心软件系统可以使用的程度。一般来说，对于任何一个可以修复的系统，都应当同时使用可靠性和可用性来衡量它的优劣。软件可用性的一个定义是：“程序在给定的时间点，按照规格说明书的规定成功地运行的概率”。 可靠性和可用性之间的主要差别在于：可靠性意味着在0～t这段时间间隔内系统没有失效；而可用性只是意味着在时刻t系统是正常运行的。因此，如果在时刻t系统是可用的，则包括下述种种可能：在0～t这段时间里，系统一直没有失效；在这段时间里失效了一次，但是又修复了；在这段时间里失效了两次、又修复了两次...... 如果在一段时间里，软件系统故障停机时间分别为td1，td