软件工程-第十二章-软件质量课件复习过程

1、软件工程-第十二章-软件质量课件12.1 软件质量的概念软件质量的概念l12.1.1 软件质量的定义ANSI的标准把软件质量定义为：“软件质量是软件产品或服务的特性和特征的整体，它取决于满足给定需求的能力。” IEEE在ANSI的软件基础上，对有关软件质量标准进行了进一步的定义： l软件产品具备满足给定需求的特性及特征的总体的能力。l软件拥有所期望的各种属性组合的程度。l用户认为软件满足他们综合期望的程度。l软件组合特性可以满足用户预期需求的程度。l12.1.2 软件质量特性软件是一种具有特殊属性的产品，因此产品质量的定义完全适用于软件领域，对软件的质量保证工作具有重要的指导意义，尤其是面向用

2、户的“适用性”的观点，应该成为指导软件开发的座右铭。已有多种有关软件质量的模型。它们共同的特点是把软件质量特性定义成分层模型。下面是几个影响较大的软件质量模型。（1）McCall质量模型 McCall定义了一些评价准则，可用检查表的形式对软件的专门属性进行“分级”，范围从0（最低）到10（最高），定义如下： l可审计性：检查与标准是否符合额定难易程度。l准确性：计算和控制的精确程度。l通信共用性：使用标准接口、协议和宽带的程度。l完整性：所需功能实现的程度。l复杂性：程序结构化、模块化、简明、简洁、清洗和可理解的程度。l简明性：程序代码的紧密程度。 l一致性：在整个软件开发项目中使用统一的设计

3、和文档编制技术的程度。l数据共用性：在整个程序中使用标准数据结构和类型的程度。l容错性：当程序出错时，造成破坏的程度。l执行效率：程序的运行时间。l可扩充性：体系结构，数据或过程设计可扩充的程度l通用性：程度构成潜在的应用范围。 l硬件独立性：软件与运行它的硬件之间的相关程度。l工具性：程序监视自身运行和识别出错现象的程度。l模块性：程序各构件的功能独立性。l可操作性：程序操作的难易程度。l安全性：控制或保护程序和数据机制的有效性 l自描述性：源代码提供自身描述的程度。l简洁性：程序易于理解的程度。l软件独立性：程序与非标准编程语言性质、操作系统特性以及其他环境限制的无 关程度。l可跟踪性：沿

4、一个设计说明或一个实际程序构件返回到需求的能力。l可训练性：程序使新用户使用该系统的辅助程度。 pMcCall定义的软件质量模型McCall认为，软件质量要素是软件质量特征，软件质量属性是软件质量的评价标准，评价准则还需要定量的度量。质量要素、评价准则和度量构成了McCall的三层次质量度量模型。lMcCall质量度量模型框架在这个层次模型中，度量处于模型的最低层，它是由质量保证人员根据开发过程的特征，对质量准则作出的定量评价，遗憾的是该评价方法还不够成熟。 （2）ISO的软件质量评价模型ISO的三层结构来源于McCall等人的模型，其高层、中层和底层分别与McCall模型的质量因素组成，SQ

5、DC选用了23个评价准则。ISO认为，高层和中层应建立国际标准，以便在国际范围内推广应用SQM技术。而底层SQMC则可以有各使用单位根据实际情况制定。p ISO软件质量度量模型软件质量度量模型 l12.1.3 软件质量特性之间的竞争在软件的众多质量特性之间，质量特性与质量子特性之间存在着有利的影响和不利的影响，表12-2给出了各质量特性与质量子特性之间的关系，表12-3给出了质量特性之间的有利和不利影响，表12-4给出了表12-4 软件质量特性与质量子特性间的有利和不利影响。l表12-2各质量特性与质量子特性之间的关系l续上表l表12-3 质量特性间的有利和不利影响l表12-4 软件质量特性与

6、质量子特性间的有利和不利影响l续上表l软件质量度量（SQM）技术，虽然经历了近20年的研究，但是目前仍然处于发展和完善阶段。根据ISO近年来讨论的趋势，逐渐向面向用户靠拢，这是因为，软件质量因素是在软件需求分析和定义阶段，由用户根据需求对所开发软件在软件质量上提出来的要求。12.2 软件质量的度量和评价软件质量的度量和评价l12.2.1 软件质量的度量软件质量的度量软件质量度量是对软件所具有的影响其属性所进行的定量测量。在软件质量度量时必须满足的质量标准： l客观性：如果不存在来自测试者对度量的主观影响，则度量是客观的。l可靠性：如果在重复度量中，在同样条件下达到相同的效果，则认为度量是可靠的

7、。l适用性：如果度量结果能够明确地说明质量特性时，则可以说度量是适用的。l标准化：标准化是指必须有一个可以明确表示度量结果的标度，当这个可比较的标度存在时，度量被认为是达到标准化的。l可比较性：当某项度量与其他度量相关时，则度量具有可比较性。 l经济性：当度量是在低成本下进行时，它是经济的。度量的经济与否取决于度量过程的自动化程度和度量的数据量，使用工具可以大大改善软件度量的自动化水平。l有效性：质量标准的有效形式最难证明的。但是不说明度量标准是有效时，就不能客观的评价软件质量。 l12.2.2 软件质量度量的分类软件质量度量的分类软件质量度量可以划分为过程度量和产品度量。l过程度量过程度量是

8、度量开发过程和维护过程或开发环境的定量属性。例如说明开发人员具有多少年的编程经验和开发过程的成本等。l产品度量 产品度量则是度量产品的定量属性。产品度量包括度量产品的大小，结构的复杂性，数据结构的复杂性。l12.2.3 软件质量评价软件质量评价软件质量评价采用软件复杂性度量。软件复杂性度量是软件质量度量中经常使用的度量方法，它属于产品度量的范畴。软件复杂性度量涉及到问题的复杂性、设计的复杂性、程序或产品的复杂性。复杂性度量包括静态度量和开发度量。静态度量是在给定时间内测量软件产品的质量，它可以分为：l软件产品的规模l软件产品程序控制结构的度量。l数据结构的度量l两个传统的软件复杂性度量法 1.

9、McCabe度量法McCabe复杂性度量也称环路度量。其基本思想是：McCabe认为程序的复杂性很大程度上取决于程序控制流的复杂性，单一的顺序程序结构最简单，循环和选择所构成的环路越多，程序就越复杂。 McCabe度量步骤如下：p画程序图首先画出程序图，这是一种“退化”的程序流程图，即将程序流程图中每个处理退化成一个点，而连接不同处理的箭头变成连接不同点的有向弧。l程序流程图afeibgcdhl程序图abdgefchil计算线性无关环路数根据图论理论，一个强连通的有向图中线性无关环路个数计算公式如下： V(G)=e-h+1 其中，V(G)：有向图G中的还数 e：G的弧的条数 n：G的节点数 如

10、果对于一个正常的程序来说，应该能够从程序图内的入口点到达任何一个节点，因此，如果从出口点加一条指向入口点的弧，那么，程序图一定是一个强连通图。 McCabe度量法的主要不足之处是他只考虑一个流程图，没有考虑独立指令的复杂性，特别是表达式的复杂性，也没有考虑嵌套指令的复杂性。 2. Halstead软件复杂性度量方法Halstead复杂性度量方法基本思路是根据程序中可执行代码行的操作符合操作数的数目来计算程序的复杂性，一般说来，操作符和操作数越大程序就越复杂。Halstead的度量法假设程序是由运算数和算符组成，每个符号或关键字标志着一个动作，即所谓的算符，如算术操作符+，-，*，/；关键字有W

11、HILE，FOR，READ等。特殊符号包括=、括号等；函数有EOF等。表示数据（包括变量、常数和标号等）的所有符号叫做运算数。 l下面是Halsteads度量法的基本度量值：ln1：程序中的特殊算符的数量ln2：程序中的特殊运算数的数量lN1：所有算符出现的总数lN2：所有运算数出现的总数ln=n1+n2：在程序种不同符号的数（或称程序的词汇标）lN=N1+N2：在程序中所有符号的总数（或称程序长度） 程序容量也成为程序能力，定义为 V=Nlog2nHalstead用D来说明程序度写时的难度系数： D=(n1*N2) / (2*n2)D是词汇表和运算数数量的函数，N2/n2是适用的运算数的平均

12、数。 从公式中可以看出，由于有些语言中使用大量的算符,例如汇编语言，使D值变得很大，说明程序很难读。 Halstead还提出了一个作为容量V和难度系数D的函数编程结果E:E的度量单位是智力鉴别力.Halstead把E看成执行编程任务过程中智力的体现,并提出这是编程人员必须通过的逻辑智力测试步骤. Halstead也考虑了用公式来计算编程中出现的错误数: W=V/3000Halstead从经验得出,人脑中进行了3000次基本操作后,会在软件中出现一次编程错误。Halstead复杂性度量方法是一种较科学的方法，但是它同样也存在一些问题，诸如没有考虑数据类型的差异没有注意调用深度、没有区别不同类型的

13、运算符等，这些都是会使预测的精确度受到一些影响。与McCabe复杂度度量方法一样，在实际应用中，会出现许多变型。12.3 软件质量保证软件质量保证l12.3.1 软件质量保证的概述软件质量保证的概述l软件质量保证（SQA）软件质量保证是一个复杂的系统，他采用一定的技术、方法和工具，来处理和调正软件产品满足需求时的相互关系，以确保软件产品满足或超过在该产品的开发过程中所规定的标准。 l质量保证系统（QAS）质量保证系统提供质量保证措施和策略的总框架，包括机构的建立和发行过程，职责的分配及选择执行质量保证的工具。 3. 质量保证计划质量保证计划是计划和检查质量保证的核心方法，包括为软件项目精确选择

14、的所有质量保证措施，因此他是质量控制的书面保证。 l12.3.2 软件质量保证原则软件质量保证原则目标是提高生产率，为了达到这些目标，必须遵循软件工程确定的通用原则和软件质量的保证的原则。下面列出目前通用的有关软件质量保证的原则：l实用的质量特征首先，尽可能做到质量特征的具体化及量化，其次，要找出每个阶段的具体的质量特征。 l针对具体产品和相应项目制定质量计划l检查质量测试结果l进行各种质量评审l优化的建设性的质量保证 l尽早发现并改正错误和缺陷l集中进行质量保证l独立的质量测试l对所应用的软件质量保证措施的评价 l12.3.3 软件质量保证计划软件质量保证计划在IEEE标准730-1984中

15、，国际公认的关于质量保证计划的基本概念包括一下内容： l软件质量保证计划的用途l参考文件l软件质量保证计划的管理软件质量文档 l标准、规范和约定l评审和审计l软件配置管理l存在的问题及修改的报告l软件工程l编码控制 lIEEE标准的不足之处是：首先，没有说明关于人员的需求和执行计划的其他资源，也没有提到对产品或项目的管理风险的评价，以及与开发产品有关的方法、手段和项目成果。并且没有列出在质量保证措施中的质量成本。 l12.3.4 软件质量保证的措施软件质量保证的措施为使软件项目或软件产品符合已确定的技术需求，提供足够的确信度，必须采取有计划的和有系统的措施和方法。 l制定计划和管理方面的质量保

16、证措施l建设性的质量保证措施l分析的质量保证措施心理学方面的质量保证措施。 l12.3.5 软件质量管理小组（软件质量管理小组（SQWC）软件质量管理小组（SQWC），是一种软件开发组织形式。它可以是主程序员领导下的结构化小组，也可以是民主制的开发组。在软件工程过程中提倡它是基于以下几个原因：（1）最适合提高个人能力和小组力量。（2）能够在工程上比硬件更好地提高质量。（3）关系到提高积极性。 但是，小组工作成果的质量受到很多因素的影响，如公司的文化、交流方式、管理情况等。影响小组工作的关键因素是： l每个人了解他们工作的功能和原理的程度。l小组要创造条件使每个人都能够喜欢他们的工作。l每个小组

17、成员希望得到回报及给予他们相当的权力的愿望能否实现。l小组工作人员一般不超过5个人。工作地点必需配置非正式的和正式的通信设备。12.4 技术评审与审查技术评审与审查人的认识不可能100%符合客观实际，因此在软件生存期每个阶段的工作中都可能引入人为的错误。实践证明，提交给测试阶段的程序中包含的错误越多，经过同样时间的测试后，程序中仍然潜伏的错误也越多。在这一项目中，必须制订评审和审查的规程，规定评审和审查的内容，组织形式，进度安排以及评审组织和任务承办单位的职责。评审是由有关专业人员或用户通过正式会议，评价和批准软件需求、设计、管理等文档。 审查是由小组或专业人员检查程序。文档是否符合有关技术规

18、程或约定。应按照规程准备并实施评审和审查，确保软件开发各阶段的工作满足软件需求说明的全部要求。 在软件开发过程中至少应当进行以下的评审与审查：l软件需求评审l软件概要设计评审l软件详细设计评审l软件验证与确认的评审l功能审查l物理审查l综合审查管理评审l12.4.1 评审过程p首先由一个独立的主席制定评审计划，规定测试目标和公开评审标准，并规定对评审对象进行测试的指标。在评审计划中，评审过程计划的使用时间是一个很重要的指标。p评审前要举行协商会，使参加评审的人员对测试对象有一个总的概念和了解。p协商会议后，紧接着的是，参加评审人员进行个人评审准备，在评审的完整文档中填写提问清单。p评审会议中，

19、首先由主席介绍搜集的所谓形式的错误记录，然后，由软件开发者报告评审对象的概况。p正式进行评审时，参加评审的人员在文档作者指导下阅读文档。评审会议限定为2小时，在会议期间，只辨认错误不作修改。参加评审的人员只提出建设性的和切实的批评和建议。p评审会议结束时，参加人员提出评审结论。 p接下去的工作是返工阶段。主席必须监督评审对象的错误修改，写出错误报告摘要，并提供修改执行表。p最后要进行评价，目标是确定是否完成了所有的修改。 l12.4.2 选择参加评审的成员成员数目根据评审的对象不同而不同，建议做规范评审时为5-8人；做总体设计评审时为6人；做详细设计评审时为5人；做编码评审时，只需要4人。l1

20、2.4.3 评审的管理和组织由于软件项目负责人和管理者也对他们的产品质量评审感兴趣，因此，在评审中有两种不同模式的组织形式：第一种是软件项目管理者参加的评审，管理者负责制订评审计划，召集评审小组开会，审查参加成员的资格，最后有他们决定评审对象是否通过。第二种模式是文档的作者主持评审，邀请评审小组成员和主席。由评审小组来确定评审对象是否通过。最后由主席起草报告，说明结果。l12.4.4 评审的方法通常采用的评审方法有：评审概述评审准备评审错误表评审错误报告摘要管理报告l12.4.5 走查和审查走查和审查走查是评审过程中采用的一种方法。走查时，软件设计者或程序开发人员指导一名或多名其他参加评审的成

21、员，通读已书写的设计文档或编码，其他成员负责提出问题，并对有关技术、风格、可能的错误、是否有违背评审标准的地方进行评论。 审查是一种正式的评定技术。由除被审查对象的作者之外的某人或某一小组仔细检查软件需求、设计或编码，以找出故障、违反开发标准之外和其他一些问题。l12.4.6 开发过程的评审开发过程的评审在面向技术的评审中，软件产品根据其形式和内容进行测试和评价。其测试对象包括规范、设计、编码、测试计划、测试案例、测试结果和用户手册。1.项目评审项目评审是从管理者的角度，对开发过程中的特定部分进行评价。项目评审成功的标准：l项目成果是可以评审的，即可读和可理解的项目计划的制定和执行由一个确定的小组来负责，该单位是很容易进行评审的。l具有确定目标的结构清晰的开发计划，用它来评价项目进度l具有已经在技术评审中评价了的具备清晰文档的项目成果2.需求规范的评审需求规范的评审对于早期发现