《软件工程与开发技术》课件第19章.ppt

19.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活动能够始终针对当前导致错误和缺陷的主要原因展开工作，取得事半功倍的效果。这也就是基于统计的质量保证活动价值之所在。表19.3统计SQA的数据收集与分类错误类别错误总计严重错误一般错误轻微错误数量百分比数量百分比数量百分比数量百分比IES20522%3427%6818%10324%MCC15617%129%6818%7617%IDS485%11%246%235%VPS253%00%154%102%EDR13014%2620%6818%368IMI586%97%185%317%EDL455%1411%123%194%IET9510%129%359%4811%IID364%22%205%143%PLT606%1512%195%266%HCI283%32%174%82%MIS566%00%154%419%统计值942100%128100%379100%435100%19.5软件可靠性19.5.1可靠性和可用性软件可靠性的含义是：“程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率”。在这个定义中包含的随机变量是“时间间隔”。显然随着运行时间的增加，运行时遇到程序故障的概率也将增加，即可靠性随着时间间隔的加大而减小。除可靠性之外，用户也非常关心软件系统可以使用的程度。一般来说，对于任何一个可以修复的系统，都应当同时使用可靠性和可用性来衡量它的优劣。软件可用性的一个定义是：“程序在给定的时间点，按照规格说明书的规定成功地运行的概率”。可靠性和可用性之间的主要差别在于：可靠性意味着在0～t这段时间间隔内系统没有失效；而可用性只是意味着在时刻t系统是正常运行的。因此，如果在时刻t系统是可用的，则包括下述种种可能：在0～t这段时间里，系统一直没有失效；在这段时间里失效了一次，但是又修复了；在这段时间里失效了两次、又修复了两次......如果在一段时间里，软件系统故障停机时间分别为td1，td