第13章 软件质量管理.ppt

1,第13章软件质量管理,从质量保证到质量认证质量保证软件可靠性程序正确性证明CMM软件能力成熟度模型ISO9000软件度量,2,从软件质量保证到质量认证,质量管理的三个阶段质量检验全面质量管理TQC质量认证CMM软件能力成熟度模型ISO9000国际标准,3,质量是产品的生命，不论生产什么产品，质量都是极端重要的。软件产品开发周期长，耗费巨大的人力和物力，更必须特别注意保证质量。一、软件质量软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。更具体地说，软件质量是软件符合明确地叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程度。上述定义强调了下述的三个要点。,13.1质量保证,4,软件需求是度量软件质量的基础，与需求不一致就是质量不高。指定的标准定义了一组指导软件开发的准则，如果没有遵守这些准则，几乎肯定会导致质量不高。通常，有一组没有显式描述的隐含需求(例如，期望软件是容易维护的)。如果软件满足明确描述的需求，但却不满足隐含的需求，那么软件的质量仍然是值得怀疑的。,5,图13.1软件质量因素与产品活动的关系,影响软件质量的主要因素从管理角度对软件质量的度量。可以把这些质量因素划分成三组，它们分别反映用户在使用软件产品时的三种不同倾向或观点。,McCall的软件质量要素,6,一、软件质量（续）,7,二、软件质量保证措施软件质量保证(SoftwareQualityAssurance，SQA)的措施主要有：基于非执行的测试(也称为复审)：用于保证软件在编码之前各阶段产生的文档的质量基于执行的测试：在程序编写出来之后进行，是保证软件质量的最后一道防线程序正确性证明：用数学方法来严格验证程序是否与对它的说明完全一致,13.1质量保证,8,参加软件质量保证的人员分为：软件工程师：通过采用可靠的技术方法和度量、进行正式的技术复审以及完成计划周密的测试保证软件质量SQA小组：辅助软件工程小组以获得高质量的软件产品，包括计划、监督、记录、分析和报告。,二、软件质量保证措施（续）,9,质量保证的活动内容,复审：计划与开发,方法：设计、编码,控制：软件配置,软件测试,开发方法符合“软件开发规范”,计划、开发等各阶段均需要复审,确保各阶段要产生完整、正确的配置项,10,1、技术复审的必要性正式技术复审的明显优点是，能够较早地发现错误，防止错误被传播到软件过程的后续阶段。正式技术复审实际上是一类复审方法，包括走查(Walkthrough)和审查(Inspection)等具体方法。走查的步骤比审查少，而且没有审查那样正规。,二、软件质量保证措施（续）,11,2、走查(1)参与者驱动法参与者按照事先准备好的列表，提出他们不理解的术语和认为不正确的术语。文档编写组的代表必须对每个质疑做出回答，要么承认确实有错误，要么对质疑做出解释。(2)文档驱动法文档编写者向走查组成员仔细解释文档。走查组成员在此过程中不时针对事先准备好的问题或解释过程中发现的问题提出质疑。这种方法可能比第一种方法更彻底，往往能检测出更多错误。经验表明，采用文档驱动法时许多错误是由文档讲解者自己发现的。,二、软件质量保证措施（续）,12,3、审查审查的范围要比走查广泛得多，它的步骤也比较多。一般来说，审查有5个基本步骤。(1)综述：由负责编写文档的一名成员向审查组成员综述该文档。综述会议结束时把文档分发给每位与会者。(2)准备：评审员仔细阅读文档。最好列出在审查中发现的错误的类型，并按发生频率把错误类型分级，以辅助审查工作的进行。这些列表有助于评审员们把注意力集中到最常发生错误的区域。,二、软件质量保证措施（续）,13,(3)审查：评审组仔细走查整个文档。和走查一样，这一步的目的也是找出文档中的错误，而不是改正它们。审查组组长必须在一天之内写出一份关于审查的报告。通常每次审查会不超过90分钟。(4)返工：文档的作者负责解决在书面报告中列出的所有错误及问题。(5)跟踪：组长必须确保所提出的每个问题都得到了圆满的解决(要么修正了文档，要么澄清了被误认为是错误的条目)。必须检查对文档所做的每个修正，以确保没有引入新的错误。如果在审查过程中返工量超过5%，则应该召集审查组再对文档全面地审查一遍。,3、审查（续）,14,可用错误检验表辅助发现错误或对错误进行发分类。,二、软件质量保证措施（续）,15,4、程序正确性证明正确性证明的基本思想是证明程序能完成预定的功能。因此，应该提供对程序功能的严格数学说明，然后根据程序代码证明程序确实能实现它的功能说明。如果在程序的若干个点上，设计者可以提出关于程序变量及它们的关系的断言，那么在每一点上的断言都应该永远是真的。假设在程序的P1，P2，Pn等点上的断言分别是a(1)，a(2)，a(n)，其中a(1)必须是关于程序输入的断言，a(n)必须是关于程序输出的断言。为了证明在点Pi和Pi+1之间的程序语句是正确的，必须证明执行这些语句之后将使断言a(i)变成a(i+1)。如果对程序内所有相邻点都能完成上述证明过程，则证明了输入断言加上程序可以导出输出断言。如果输入断言和输出断言是正确的，而且程序确实是可以终止的(不包含死循环)，则上述过程就证明了程序的正确性。,二、软件质量保证措施（续）,16,13.2配置管理,软件配置管理的主要目的就是控制在软件开发过程中的各种变化、修改的管理，从某种意义上是软件质量保证的一部分，但专注于软件各个成份的变化和修改的控制，从而保证各个成份之间的一致性。软件配置管理从总的来说包括识别软件变化、控制变化、保证变化正确进行以及向感兴趣的其他人员报告变化。,17,软件配置管理活动，包括：识别软件成份，并具体确定软件配置管理的对象软件成份的版本控制(versioncontrol)，维持各个成份之间一致的版本变化控制(changecontol)：以严格的过程控制软件成份的变化配置审核(configurationauditing)：保证所要进行的变化正确地实现报告(reporting)：向其他相关成员报告软件成份的变化,13.2配置管理（续）,18,软件配置管理不同于软件维护。维护是在软件交付给用户使用后才发生的，而软件配置管理是在软件项目启动时就开始，并且一直持续到软件退役后才终止的一组跟踪和控制活动。软件配置管理的目标是，使变化更容易被适应，并且在必须变化时减少所需花费的工作量。,13.2配置管理（续）,19,一、软件配置1、软件配置项软件过程的输出信息可以分为三类：（1）计算机程序(源代码和可执行程序)；（2）描述计算机程序的文档(供技术人员或用户使用)；（3）数据(程序内包含的或在程序外的)。上述这些项组成了在软件过程中产生的全部信息，我们把它们统称为软件配置，而这些项就是软件配置项。可以把软件配置管理看作是应用于整个软件过程的软件质量保证活动，是专门用于管理变化的软件质量保证活动。,13.2配置管理（续）,20,2、基线基线是一个软件配置管理概念，它有助于我们在不严重妨碍合理变化的前提下来控制变化。IEEE把基线定义为：已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。,一、软件配置（续）,21,基线就是通过了正式复审的软件配置项。在软件配置项变成基线之前，可以迅速而非正式地修改它。一旦建立了基线之后，虽然仍然可以实现变化，但是，必须应用特定的、正式的过程(称为规程)来评估、实现和验证每个变化。,一、软件配置（续）,基线成分1、系统规格说明2、软件项目计划3、软件需求规格说明4、初步的用户手册5、设计规格说明6、源代码清单,7、测试规格说明8、操作和安装手册9、可执行程序10、数据库描述11、联机用户手册12、维护文档13、软件工程的标准和规程,22,二、软件配置管理过程软件配置管理是软件质量保证的重要一环，它的主要任务是控制变化，同时也负责各个软件配置项和软件各种版本的标识、软件配置审计以及对软件配置发生的任何变化的报告。具体来说，软件配置管理主要有五项任务：标识、版本控制、变化控制、配置审计和报告。,13.2配置管理（续）,23,1、标识软件配置中的对象为了控制和管理软件配置项，必须单独命名每个配置项，然后用面向对象方法组织它们。可以标识出两类对象：基本对象和聚集对象(可以把聚集对象作为代表软件配置完整版本的一种机制)。每个对象都有一组能惟一地标识它的特征：名字、描述、资源表和“实现”。其中，对象名是无二义性地标识该对象的一个字符串。,二、软件配置管理过程（续）,24,2、版本控制版本控制联合使用规程和工具，以管理在软件工程过程中所创建的配置对象的不同版本。借助于版本控制技术，用户能够通过选择适当的版本来指定软件系统的配置。实现这个目标的方法是，把属性和软件的每个版本关联起来，然后通过描述一组所期望的属性来指定和构造所需要的配置。,二、软件配置管理过程（续）,25,图13.2演化图,2、版本控制（续）,26,3、变化控制对于大型软件开发项目来说，无控制的变化将迅速导致混乱。变化控制把人的规程和自动工具结合起来，以提供一个控制变化的机制。需建立统一的变化控制授权(changeontrolauthority)机构，由该机构负责控制进入基线后的所有软件成份的变化。,二、软件配置管理过程（续）,27,变化控制过程：识别变化提交变化报告变化控制授权机构审查审查通过，将变化要求插入到工程变化序列当处理这个变化时确定该变化所涉及的软件配置管理对象将这些软件配置管理对象退出基线实施真正的变化测试和评审变化被正确实现将变化后的软件配置管理对象加入基线建立软件配置管理对象的新的版本评估这种变化对其他软件配置管理对象的影响建立整个软件新的版本发布软件新的版本,3、变化控制（续）,28,13.3软件可靠性,一、基本概念1、软件可靠性的定义软件可靠性是程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。,29,可靠性,1.R(t)=e-t=故障率，即单位时间内程序运行失败的次数。T=程序运行时间2.直接计算系统的平均无故障时间MTTF，在故障率为常量的情况下，MTTF=1/3.sys=s+h+opMTTPSYS=1/(1/MTTFS+1/MTTFH+1/MTTFOP),30,可靠性分级表,31,软件的平均无故障时间MTTF是一个重要的质量指标，往往作为对软件的一项要求，由用户提出来。为了估算MTTF，首先引入一些有关的量。,二、估算平均无故障时间的方法,32,1、符号在估算MTTF的过程中使用下述符号表示有关的数量：ET测试之前程序中错误总数；IT程序长度(机器指令总数)；测试(包括调试)时间；Ed()在0至期间发现的错误数；Ec()在0至期间改正的错误数。,二、估算平均无故障时间的方法(续),33,2、基本假定根据经验数据，可以作出下述假定。在类似的程序中，单位长度里的错误数ET/IT近似为常数。美国的一些统计数字表明，通常0.510-2ET/IT210-2，也就是说，在测试之前每1000条指令中大约有520个错误。失效率正比于软件中剩余的(潜藏的)错误数，而平均无故障时间MTTF与剩余的错误数成反比。,二、估算平均无故障时间的方法(续),34,为了简化讨论，假设发现的每一个错误都立即正确地改正了(即，调试过程没有引入新的错误)。因此Ec()=Ed()剩余的错误数为Er()=ET-Ec()单位长度程序中剩余的错误数为r()=ET/Ir-Ec()/IT,二、估算平均无故障时间的方法(续),35,3、估算平均无故障时间经验表明，平均无故障时间与单位长度程序中剩余的错误数成反比，即其中K为常数，它的值应该根据经验选取。美国的一些统计数字表明，K的典型值是200。估算平均无故障时间的公式，可以评价软件测试的进展情况。,二、估算平均无故障时间的方法(续),36,此外，由前式可得因此，也可以根据对软件平均无故障时间的要求，估计需要改正多少个错误之后，测试工作才能结束。,二、估算平均无故障时间的方法(续),37,4、估计错误总数的方法(1)植入错误法使用这种估计方法，在测试之前由专人在程序中随机地植入一些错误，测试之后，根据测试小组发现的错误中原有的和植入的两种错误的比例，来估计程序中原有错误的总数ET。,二、估算平均无故障时间的方法(续),38,假设人为地植入的错误数为Ns，经过一段时间的测试之后发现ns个植入的错误，此外还发现了n个原有的错误。如果可以认为测试方案发现植入错误和发现原有错误的能力相同，则能够估计出程序中原有错误的总数为其中N即是错误总数ET的估计值。,(1)植入错误法,39,(2)分别测试法分别测试法使用两个测试员(或测试小组)，彼此独立地测试同一个程序的两个副本，把其中一个测试员发现的错误作为有标记的错误。具体做法是，在测试过程的早期阶段，由测试员甲和测试员乙分别测试同一个程序的两个副本，由另一名分析员分析他们的测试结果。,二、估算平均无故障时间的方法(续),40,用表示测试时间，假设=0时错误总数为B0；=1时测试员甲发现的错误数为B1；=1时测试员乙发现的错误数为B2；=1时两个测试员发现的相同错误数为bc。如果认为测试员甲发现的错误是有标记的，即程序中有标记的错误总数为B1，则测试员乙发现的B2个错误中有bc个是有标记的。假定测试员乙发现有标记错误和发现无标记错误的概率相同，则可以估计出测试前程序中的错误总数为,(2)分别测试法,41,=0时错误总数为B0；=1时测试员甲发现的错误数为B1；=1时测试员乙发现的错误数为B2；=1时两个测试员发现的相同错误数为bc。,(2)分别测试法,42,使用分别测试法，在测试阶段的早期，每隔一段时间分析员分析两名测试员的测试结果，并且用(5.8)式计算B0。如果几次估算的结果相差不多，则可用B0的平均值作为ET的估计值。此后一名测试员可以改做其他工作，由余下的一名测试员继续完成测试工作，因为他可以继承另一名测试员的测试结果，所以分别测试法增加的测试成本并不太多。,(2)分别测试法,43,三、软件容错技术,容错软件（有抗故障功能的软件）屏蔽错误：屏蔽软件错误使之不致为害修复错误：使软件从错误状态恢复到正常状态减少影响：能在一定程度上使软件完成预定的功能冗余技术结构冗余：设计备用模块，能进行模块切换时间冗余：多花时间以检测并处理错误信息冗余：采用校验码等冗余信息保证数据正确传输,44,静态冗余结构和动态冗余结构,I,U,u1,u2,u3,I,主模块,备用,备用,45,容错软件设计,用于容错的冗余分支一般应由不同的开发小组独立进行设计和实现，以达到提高系统可靠性的目的。,46,13.4能力成熟度模型,能力成熟度模型的基本思想是，因为问题是由我们管理软件过程的方法不当引起的，所以新软件技术的运用并不会自动提高生产率和软件质量。能力成熟度模型有助于软件开发组织建立一个有规律的、成熟的软件过程。改进后的过程将开发出质量更好的软件，使更多的软件项目免受时间和费用超支之苦。,47,软件过程包括各种活动、技术和工具，因此，它实际上既包括了软件生产的技术方面又包括了管理方面。CMM策略力图改进软件过程的管理，而在技术方面的改进是其必然的结果。必须记住，对软件过程的改进不可能在一夜之间完成，CMM是以增量方式逐步引入变化的。CMM明确地定义了5个不同的成熟度等级，一个软件开发组织可用一系列小的改良性步骤向更高的成熟度等级迈进。,13.4能力成熟度模型（续）,48,能力成熟度模型包括以下的组成成分。(1)成熟度等级(MaturityLevels)：一个成熟度等级是在朝着实现成熟软件过程进化途中的一个妥善定义的平台。五个成熟度等级构成了CMM的顶层结构。(2)过程能力(ProcessCapability)：软件过程能力描述，通过遵循软件过程能实现预期结果的程度。一个组织的软件过程能力提供一种“预测该组织承担下一个软件项目时，预期最可能得到的结果”的方法。,13.4能力成熟度模型（续）,49,(3)关键过程域(KeyProcessAreas，KPA)：每个成熟度等级由若干关键过程域组成。每个关键过程域都标识出一串相关的活动，对比这些活动都完成时所达到的一组目标，对建立该过程成熟度等级是至关重要的。关键过程域分别定义在各个成熟度等级之中，并与之关联在一起。例如，等级2的一个关键过程域是软件项目计划。,13.4能力成熟度模型（续）,50,(4)目标(Goals)：目标概括了关键过程域中的关键实践，并可用于确定一个组织或项目是否已有效地实施了该关键过程域。目标表示每个关键过程域的范围、边界和意图，例如，关键过程域“软件项目计划”的一个目标是，“软件估算已经文档化，供计划和跟踪软件项目使用。”,13.4能力成熟度模型（续）,51,(5)公共特性(CommonFeatures)：CMM把关键实践分别归入下列五个公共特性之中：执行约定、执行能力、执行的活动、测量和分析以及验证实施。公共特性是一种属性，它能指示一个关键过程域的实施和规范化是否是有效的、可重复的和持久的。,13.4能力成熟度模型（续）,52,(6)关键实践(KeyPractices)：每个关键过程域都用若干关键实践描述，实施关键实践有助于实现相应的关键过程域的目标。关键实践描述对关键过程域的有效实施和规范化贡献最大的基础设施和活动。例如，在关键过程域“软件项目计划”中，一个关键实践是“按照已文档化的规程制定项目的软件开发计划”。,13.4能力成熟度模型（续）,53,CMM的结构,54,CMM通过定义能力成熟度的五个等级，引导软件开发组织不断识别出其软件过程的缺陷，并指出应该做哪些改进，但是，它并不提供做这些改进的具体措施。能力成熟度的五个等级从低到高是：初始级、可重复级、已定义级、已管理级和优化级。,13.4能力成熟度模型（续）,55,(1)初始级软件过程的特征是无序的，有时甚至是混乱的。几乎没有什么过程是经过定义的，项目能否成功完全取决于个人能力。(2)可重复级建立了基本的项目管理过程，以追踪成本、进度和功能性。必要的过程规范已经建立起来了，使得可以重复以前类似项目所取得的成功。关键过程域如下：软件配置管理软件质量保证软件子合同管理软件项目跟踪和监督软件项目计划需求管理,能力成熟度的五个等级(续),56,(3)已定义级用于管理和工程活动的软件过程已经文档化和标准化，并且已经集成到整个