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

《软件工程-第十二章-软件质量课件复习过程.ppt》由会员分享，可在线阅读，更多相关《软件工程-第十二章-软件质量课件复习过程.ppt（80页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

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模型的质量因素组成，SQDC选用了23

5、个评价准则。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可靠性：如果在重复度量中，在同样条件下达到相同的效果，则认为度量是可靠的。l适用性：如果

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

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

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

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

11、数据（包括变量、常数和标号等）的所有符号叫做运算数。l下面是Halsteads度量法的基本度量值：ln1：程序中的特殊算符的数量ln2：程序中的特殊运算数的数量lN1：所有算符出现的总数lN2：所有运算数出现的总数ln=n1+n2：在程序种不同符号的数（或称程序的词汇标）lN=N1+N2：在程序中所有符号的总数（或称程序长度）程序容量也成为程序能力，定义为 V=Nlog2nHalstead用D来说明程序度写时的难度系数：D=(n1*N2)/(2*n2)D是词汇表和运算数数量的函数，N2/n2是适用的运算数的平均数。从公式中可以看出，由于有些语言中使用大量的算符,例如汇编语言，使D值变得很大，说

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

13、中，会出现许多变型。12.3 软件质量保证软件质量保证l12.3.1 软件质量保证的概述软件质量保证的概述1.软件质量保证（SQA）软件质量保证是一个复杂的系统，他采用一定的技术、方法和工具，来处理和调正软件产品满足需求时的相互关系，以确保软件产品满足或超过在该产品的开发过程中所规定的标准。2.质量保证系统（QAS）质量保证系统提供质量保证措施和策略的总框架，包括机构的建立和发行过程，职责的分配及选择执行质量保证的工具。3.质量保证计划质量保证计划是计划和检查质量保证的核心方法，包括为软件项目精确选择的所有质量保证措施，因此他是质量控制的书面保证。l12.3.2 软件质量保证原则软件质量保证原

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

15、 标准、规范和约定评审和审计软件配置管理存在的问题及修改的报告软件工程编码控制 lIEEE标准的不足之处是：首先，没有说明关于人员的需求和执行计划的其他资源，也没有提到对产品或项目的管理风险的评价，以及与开发产品有关的方法、手段和项目成果。并且没有列出在质量保证措施中的质量成本。l12.3.4 软件质量保证的措施软件质量保证的措施为使软件项目或软件产品符合已确定的技术需求，提供足够的确信度，必须采取有计划的和有系统的措施和方法。制定计划和管理方面的质量保证措施建设性的质量保证措施分析的质量保证措施心理学方面的质量保证措施。l12.3.5 软件质量管理小组（软件质量管理小组（SQWC）软件质量管

16、理小组（SQWC），是一种软件开发组织形式。它可以是主程序员领导下的结构化小组，也可以是民主制的开发组。在软件工程过程中提倡它是基于以下几个原因：（1）最适合提高个人能力和小组力量。（2）能够在工程上比硬件更好地提高质量。（3）关系到提高积极性。但是，小组工作成果的质量受到很多因素的影响，如公司的文化、交流方式、管理情况等。影响小组工作的关键因素是：每个人了解他们工作的功能和原理的程度。小组要创造条件使每个人都能够喜欢他们的工作。每个小组成员希望得到回报及给予他们相当的权力的愿望能否实现。小组工作人员一般不超过5个人。工作地点必需配置非正式的和正式的通信设备。12.4 技术评审与审查技术评审与

17、审查人的认识不可能100%符合客观实际，因此在软件生存期每个阶段的工作中都可能引入人为的错误。实践证明，提交给测试阶段的程序中包含的错误越多，经过同样时间的测试后，程序中仍然潜伏的错误也越多。在这一项目中，必须制订评审和审查的规程，规定评审和审查的内容，组织形式，进度安排以及评审组织和任务承办单位的职责。评审是由有关专业人员或用户通过正式会议，评价和批准软件需求、设计、管理等文档。审查是由小组或专业人员检查程序。文档是否符合有关技术规程或约定。应按照规程准备并实施评审和审查，确保软件开发各阶段的工作满足软件需求说明的全部要求。在软件开发过程中至少应当进行以下的评审与审查：软件需求评审软件概要设

18、计评审软件详细设计评审软件验证与确认的评审功能审查物理审查综合审查管理评审l12.4.1 评审过程p首先由一个独立的主席制定评审计划，规定测试目标和公开评审标准，并规定对评审对象进行测试的指标。在评审计划中，评审过程计划的使用时间是一个很重要的指标。p评审前要举行协商会，使参加评审的人员对测试对象有一个总的概念和了解。p协商会议后，紧接着的是，参加评审人员进行个人评审准备，在评审的完整文档中填写提问清单。p评审会议中，首先由主席介绍搜集的所谓形式的错误记录，然后，由软件开发者报告评审对象的概况。p正式进行评审时，参加评审的人员在文档作者指导下阅读文档。评审会议限定为2小时，在会议期间，只辨认错

19、误不作修改。参加评审的人员只提出建设性的和切实的批评和建议。p评审会议结束时，参加人员提出评审结论。p接下去的工作是返工阶段。主席必须监督评审对象的错误修改，写出错误报告摘要，并提供修改执行表。p最后要进行评价，目标是确定是否完成了所有的修改。l12.4.2 选择参加评审的成员成员数目根据评审的对象不同而不同，建议做规范评审时为5-8人；做总体设计评审时为6人；做详细设计评审时为5人；做编码评审时，只需要4人。l12.4.3 评审的管理和组织由于软件项目负责人和管理者也对他们的产品质量评审感兴趣，因此，在评审中有两种不同模式的组织形式：第一种是软件项目管理者参加的评审，管理者负责制订评审计划，

20、召集评审小组开会，审查参加成员的资格，最后有他们决定评审对象是否通过。第二种模式是文档的作者主持评审，邀请评审小组成员和主席。由评审小组来确定评审对象是否通过。最后由主席起草报告，说明结果。l12.4.4 评审的方法通常采用的评审方法有：评审概述评审准备评审错误表评审错误报告摘要管理报告l12.4.5 走查和审查走查和审查走查是评审过程中采用的一种方法。走查时，软件设计者或程序开发人员指导一名或多名其他参加评审的成员，通读已书写的设计文档或编码，其他成员负责提出问题，并对有关技术、风格、可能的错误、是否有违背评审标准的地方进行评论。审查是一种正式的评定技术。由除被审查对象的作者之外的某人或某一

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

22、误是十分有用的。在评审中必须测试需求规范的以下质量特征是否满足：抗矛盾性完整性可执行性和可处理性精确性和可测试性综合性 3.设计的评审根据设计的类型，可以分为总体设计评审和详细审计评审。设计评审的目标是确定和评价设计的各种状态以及发现错误的矛盾。4.编码检验编码检验的目的一方面是改善软件质量，另一方面是为了提高程序员的生产率。5.测试评审测试检验主要用来检验测试活动是否成功，测试检验一般在测试执行后进行。l12.4.7 对评审的综合评价优点评审复杂情况时的分析、识别、评价和测试等方面充分发挥人们的思维能力。评审不仅适用于检验正式的文档，如程序清单，也适用于非正式的文档，如口头的设计说明等用评审

23、方式检查程序是具有很高的成功率的 缺点评审的成功完全依赖于参加评审的人员，他们的原则性是至关重要的。交流的气氛对于发挥人们的思考和分析能力是很重要的。解决问题可能占用有价值的评审时间，以至于不能发现更多的错误。存在着评价工作人员的可能，这将使检查过程的有效性降低。评审对开发过程的重要性往往被低估了。12.5 软件的可靠性软件的可靠性软件可靠性是重要的软件特性。通常用它衡量在规定的条件和时间内，软件完成规定功能的能力。IEEE把软件可靠性定一如下：在规定的条件下，在规定的时间内，软件不引起系统失败的概率，该概率是系统输入和系统使用的函数，也是软件中存在的错误的函数。系统输入将确定是否会遇到已存在的错误。在规定的时间周期内，在所述条件下程序执行所要求的功能的能力。谢谢此课件下载可自行编辑修改，仅供参考！此课件下载可自行编辑修改，仅供参考！感谢您的支持，我们努力做得更好！谢谢感谢您的支持，我们努力做得更好！谢谢