第14章软件质量管理

1、1第十四章第十四章 软件质量管理软件质量管理n从质量保证到质量认证n质量保证n软件可靠性n程序正确性证明nCMM软件能力成熟度模型nISO9000 国际标准n软件度量2从软件质量保证到质量认证从软件质量保证到质量认证 n质量管理的三个阶段n质量检验n全面质量管理TQC n质量认证nCMM软件能力成熟度模型 nISO 9000国际标准 3 质量是产品的生命，不论生产什么产品，质量都是质量是产品的生命，不论生产什么产品，质量都是极端重要的。软件产品开发周期长，耗费巨大的人力和极端重要的。软件产品开发周期长，耗费巨大的人力和物力，更必须特别注意保证质量。物力，更必须特别注意保证质量。一、软件质量一、

2、软件质量 软件质量就是软件质量就是“软件与明确地和隐含地定义的需求软件与明确地和隐含地定义的需求相一致的程度相一致的程度”。更具体地说，。更具体地说，软件质量软件质量是软件符合明是软件符合明确地叙述的功能和性能需求、文档中明确描述的开发标确地叙述的功能和性能需求、文档中明确描述的开发标准、以及所有专业开发的软件都应具有的隐含特征的程准、以及所有专业开发的软件都应具有的隐含特征的程度度。上述定义强调了下述的三个要点。上述定义强调了下述的三个要点。14.1 质量保证4软件需求是度量软件质量的基础，与需求不一致就是质软件需求是度量软件质量的基础，与需求不一致就是质量不高。量不高。指定的标准定义了一组

3、指导软件开发的准则，如果没有指定的标准定义了一组指导软件开发的准则，如果没有遵守这些准则，几乎肯定会导致质量不高。遵守这些准则，几乎肯定会导致质量不高。通常，有一组没有显式描述的隐含需求通常，有一组没有显式描述的隐含需求( (例如，期望软例如，期望软件是容易维护的件是容易维护的) )。如果软件满足明确描述的需求，但却。如果软件满足明确描述的需求，但却不满足隐含的需求，那么软件的质量仍然是值得怀疑的。不满足隐含的需求，那么软件的质量仍然是值得怀疑的。5图图14.114.1软件质量因素与产品活动的关系软件质量因素与产品活动的关系 影响软件质量的主要因素影响软件质量的主要因素从管理角度对软件质量的度

4、量。可从管理角度对软件质量的度量。可以把这些质量因素划分成三组，它们分别以把这些质量因素划分成三组，它们分别反映用户在使用软件产反映用户在使用软件产品时的三种不同倾向或观点品时的三种不同倾向或观点。McCall的软件的软件质量要质量要素素6表表 1 14 4. .1 1 软件质量因素的定义软件质量因素的定义 质量因素 定义 正确性 系统满足规格说明和用户目标的程度，即，在预定环境下能正确地完成预期功能的程度 健壮性 在硬件发生故障、 输入的数据无效或操作错误等意外环境下，系统能做出适当响应的程度 效率 为了完成预定的功能，系统需要的计算资源的多少 完整性(安全性) 对未经授权的人使用软件或数据

5、的企图，系统能够控制(禁止)的程度 可用性 系统在完成预定应该完成的功能时令人满意的程度 风险 按预定的成本和进度把系统开发出来， 并且为用户所满意的概率 一、软件质量一、软件质量 （续）（续）7二、软件质量保证措施二、软件质量保证措施软件质量保证软件质量保证(Software Quality Assurance(Software Quality Assurance，SQA)SQA)的措施主的措施主要有：要有：基于非执行的测试基于非执行的测试( (也称为复审也称为复审) )：用于保证软件在编码之用于保证软件在编码之前各阶段产生的文档的质量前各阶段产生的文档的质量基于执行的测试：基于执行的测试：

6、在程序编写出来之后进行，是保证软件在程序编写出来之后进行，是保证软件质量的最后一道防线质量的最后一道防线程序正确性证明：程序正确性证明：用数学方法来严格验证程序是否与对它用数学方法来严格验证程序是否与对它的说明完全一致的说明完全一致14.1 质量保证8参加软件质量保证的人员参加软件质量保证的人员分为：分为：软件工程师：软件工程师：通过采用可靠的技术方法和度量、进行正通过采用可靠的技术方法和度量、进行正式的技术复审以及完成计划周密的测试保证软件质量式的技术复审以及完成计划周密的测试保证软件质量SQASQA小组：小组：辅助软件工程小组以获得高质量的软件产品，辅助软件工程小组以获得高质量的软件产品，

7、包括计划、监督、记录、分析和报告。包括计划、监督、记录、分析和报告。二、软件质量保证措施二、软件质量保证措施 （续）（续）9质量保证的活动内容 复审：计划与开发方法：设计、编码控制：软件配置软件测试开发方法符开发方法符合合“软件开软件开发规范发规范”计划、开发计划、开发等各阶段均等各阶段均需要复审需要复审确保各阶段要确保各阶段要产生完整、正产生完整、正确的配置项确的配置项101 1、技术复审的必要性、技术复审的必要性 正式技术复审正式技术复审的的明显优点是，能够较早地发现错误，明显优点是，能够较早地发现错误，防止错误被传播到软件过程的后续阶段。防止错误被传播到软件过程的后续阶段。 正式技术复审

8、实际上是一类复审方法，包括正式技术复审实际上是一类复审方法，包括走查走查(Walkthrough)(Walkthrough)和和审查审查(Inspection)(Inspection)等具体方法。走查的等具体方法。走查的步骤比审查少，而且没有审查那样正规。步骤比审查少，而且没有审查那样正规。二、软件质量保证措施二、软件质量保证措施 （续）（续）112 2、走查、走查(1)(1)参与者驱动法参与者驱动法 参与者按照事先准备好的列表，提出他们不理解的术语和认为参与者按照事先准备好的列表，提出他们不理解的术语和认为不正确的术语。文档编写组的代表必须对每个质疑做出回答，要么不正确的术语。文档编写组的代

9、表必须对每个质疑做出回答，要么承认确实有错误，要么对质疑做出解释。承认确实有错误，要么对质疑做出解释。(2)(2)文档驱动法文档驱动法 文档编写者向走查组成员仔细解释文档。走查组成员在此过程文档编写者向走查组成员仔细解释文档。走查组成员在此过程中不时针对事先准备好的问题或解释过程中发现的问题提出质疑。中不时针对事先准备好的问题或解释过程中发现的问题提出质疑。这种方法可能比第一种方法更彻底，往往能检测出更多错误。经验这种方法可能比第一种方法更彻底，往往能检测出更多错误。经验表明，采用文档驱动法时许多错误是由文档讲解者自己发现的。表明，采用文档驱动法时许多错误是由文档讲解者自己发现的。二、软件质量

10、保证措施二、软件质量保证措施 （续）（续）123 3、审查、审查 审查的范围要比走查广泛得多，它的步骤也比较多。审查的范围要比走查广泛得多，它的步骤也比较多。一般来说，审查有一般来说，审查有5 5个基本步骤个基本步骤。 (1)(1)综述：综述：由负责编写文档的一名成员向审查组成员由负责编写文档的一名成员向审查组成员综述该文档。综述会议结束时把文档分发给每位与会者。综述该文档。综述会议结束时把文档分发给每位与会者。 (2)(2)准备：准备：评审员仔细阅读文档。最好列出在审查中评审员仔细阅读文档。最好列出在审查中发现的错误的类型，并按发生频率把错误类型分级，以发现的错误的类型，并按发生频率把错误类

11、型分级，以辅助审查工作的进行。这些列表有助于评审员们把注意辅助审查工作的进行。这些列表有助于评审员们把注意力集中到最常发生错误的区域。力集中到最常发生错误的区域。二、软件质量保证措施二、软件质量保证措施 （续）（续）13 (3)(3)审查：审查：评审组仔细走查整个文档。和走查一样，这一步评审组仔细走查整个文档。和走查一样，这一步的目的也是找出文档中的错误，而不是改正它们。审查组组长的目的也是找出文档中的错误，而不是改正它们。审查组组长必须在一天之内写出一份关于审查的报告。通常每次审查会不必须在一天之内写出一份关于审查的报告。通常每次审查会不超过超过9090分钟。分钟。 (4)(4)返工：返工：

12、文档的作者负责解决在书面报告中列出的所有错文档的作者负责解决在书面报告中列出的所有错误及问题。误及问题。 (5)(5)跟踪：跟踪：组长必须确保所提出的每个问题都得到了圆满的组长必须确保所提出的每个问题都得到了圆满的解决解决( (要么修正了文档，要么澄清了被误认为是错误的条目要么修正了文档，要么澄清了被误认为是错误的条目) )。必须检查对文档所做的每个修正，以确保没有引入新的错误。必须检查对文档所做的每个修正，以确保没有引入新的错误。如果在审查过程中返工量超过如果在审查过程中返工量超过5%5%，则应该召集审查组再对文档，则应该召集审查组再对文档全面地审查一遍。全面地审查一遍。3 3、审查、审查

13、（续）（续）14可用错误检验表辅助发现错误或对错误进行发分类。可用错误检验表辅助发现错误或对错误进行发分类。二、软件质量保证措施二、软件质量保证措施 （续）（续）数据引用错误 使用未赋值的变量，变量赋值后从不使用等 数据说明错误 变量未做说明，变量类型与初始化值不符等 数据计算错误 混合类型运算，用零作除等 数据比较错误 比较运算符和逻辑运算符使用不当，在不同类型变量间比较等 控制流程错误 多做或少做了一次循环，在循环体中对循环变量重新定义等 接口错误 实参和形参的类型、顺序、数量不符，全程变量在个模块中的定义不一致等 输入输出错误 忘记打开或关闭文件，I/O出错处理不正确等 154 4、程序

14、正确性证明、程序正确性证明 正确性证明的基本思想是证明程序能完成预定的功能。因此，正确性证明的基本思想是证明程序能完成预定的功能。因此，应该提供对程序功能的严格数学说明，然后根据程序代码证明程序应该提供对程序功能的严格数学说明，然后根据程序代码证明程序确实能实现它的功能说明。如果在程序的若干个点上，设计者可以确实能实现它的功能说明。如果在程序的若干个点上，设计者可以提出关于程序变量及它们的关系的断言，那么在每一点上的断言都提出关于程序变量及它们的关系的断言，那么在每一点上的断言都应该永远是真的。假设在程序的应该永远是真的。假设在程序的P1P1，P2P2，PnPn等点上的断言分别等点上的断言分别

15、是是a(1)a(1)，a(2)a(2)，a(n)a(n)，其中，其中a(1)a(1)必须是关于程序输入的断言，必须是关于程序输入的断言，a(n)a(n)必须是关于程序输出的断言。必须是关于程序输出的断言。 为了证明在点为了证明在点PiPi和和Pi+1Pi+1之间的程序语句是正确的，必须证明执之间的程序语句是正确的，必须证明执行这些语句之后将使断言行这些语句之后将使断言a(i)a(i)变成变成a(i+1)a(i+1)。如果对程序内所有相邻。如果对程序内所有相邻点都能完成上述证明过程，则证明了输入断言加上程序可以导出输点都能完成上述证明过程，则证明了输入断言加上程序可以导出输出断言。如果输入断言和

16、输出断言是正确的，而且程序确实是可以出断言。如果输入断言和输出断言是正确的，而且程序确实是可以终止的终止的( (不包含死循环不包含死循环) )，则上述过程就证明了程序的正确性。，则上述过程就证明了程序的正确性。二、软件质量保证措施二、软件质量保证措施 （续）（续）1614.2 配置管理 软件配置管理软件配置管理的的主要目的就是控制在软件开发过程主要目的就是控制在软件开发过程中的各种变化、修改的管理中的各种变化、修改的管理，从某种意义上是软件质量，从某种意义上是软件质量保证的一部分，但专注于软件各个成份的变化和修改的保证的一部分，但专注于软件各个成份的变化和修改的控制，从而保证各个成份之间的一致

17、性。控制，从而保证各个成份之间的一致性。 软件配置管理从总的来说包括识别软件变化、控制软件配置管理从总的来说包括识别软件变化、控制变化、保证变化正确进行以及向感兴趣的其他人员报告变化、保证变化正确进行以及向感兴趣的其他人员报告变化。变化。17软件配置管理活动，包括：软件配置管理活动，包括：识别软件成份识别软件成份，并具体确定软件配置管理的对象，并具体确定软件配置管理的对象软件成份的版本控制软件成份的版本控制(versioncontrol)(versioncontrol)，维持各个成份之，维持各个成份之间一致的版本间一致的版本变化控制变化控制(changecontol)(changecontol

18、)：以严格的过程控制软件成份的：以严格的过程控制软件成份的变化变化配置审核配置审核(configurationauditing)(configurationauditing)：保证所要进行的变：保证所要进行的变化正确地实现化正确地实现报告报告(reporting)(reporting)：向其他相关成员报告软件成份的变化：向其他相关成员报告软件成份的变化14.2 配置管理 （续）18 软件配置管理不同于软件维护。维护是在软件交付软件配置管理不同于软件维护。维护是在软件交付给用户使用后才发生的，而给用户使用后才发生的，而软件配置管理是在软件项目软件配置管理是在软件项目启动时就开始，并且一直持续到软

19、件退役后才终止的一启动时就开始，并且一直持续到软件退役后才终止的一组跟踪和控制活动。组跟踪和控制活动。 软件配置管理的软件配置管理的目标是，使变化更容易被适应，并目标是，使变化更容易被适应，并且在必须变化时减少所需花费的工作量且在必须变化时减少所需花费的工作量。14.2 配置管理 （续）19一、软件配置一、软件配置1 1、软件配置项、软件配置项 软件过程的输出信息可以分为三类：软件过程的输出信息可以分为三类：（1 1）计算机程序）计算机程序( (源代码和可执行程序源代码和可执行程序) )；（2 2）描述计算机程序的文档）描述计算机程序的文档( (供技术人员或用户使用供技术人员或用户使用) )；

20、（3 3）数据）数据( (程序内包含的或在程序外的程序内包含的或在程序外的) )。 上述这些项组成了在软件过程中产生的全部信息，我们上述这些项组成了在软件过程中产生的全部信息，我们把它们统称为软件配置，而这些项就是把它们统称为软件配置，而这些项就是软件配置项软件配置项。 可以把软件配置管理看作是应用于整个软件过程的软件可以把软件配置管理看作是应用于整个软件过程的软件质量保证活动，是专门质量保证活动，是专门用于管理变化的软件质量保证活动用于管理变化的软件质量保证活动。14.2 配置管理 （续）202 2、基线、基线 基线是一个软件配置管理概念，它有助于我们在不严重基线是一个软件配置管理概念，它有

21、助于我们在不严重妨碍合理变化的前提下来控制变化。妨碍合理变化的前提下来控制变化。 IEEEIEEE把基线定义为：把基线定义为： 已经通过了正式复审的规格说明或中间产品，它可以作已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。能改变它。一、软件配置一、软件配置 （续）（续）21 基线基线就是通过了正式复审的软件配置项就是通过了正式复审的软件配置项。在软件配在软件配置项变成基线之前，可以迅速而非正式地修改它。一旦置项变成基线之前，可以迅速而非正式地修改它。一旦建立了基线之后，虽然仍然可

22、以实现变化，但是，必须建立了基线之后，虽然仍然可以实现变化，但是，必须应用特定的、正式的过程应用特定的、正式的过程( (称为规程称为规程) )来评估、实现和验来评估、实现和验证每个变化证每个变化。 一、软件配置一、软件配置 （续）（续） 基线成分基线成分1、系统规格说明2、软件项目计划3、软件需求规格说明4、初步的用户手册5、设计规格说明6、源代码清单7、测试规格说明8、操作和安装手册9、可执行程序10、数据库描述11、联机用户手册12、维护文档13、软件工程的标准和规程22二、软件配置管理过程二、软件配置管理过程 软件配置管理是软件质量保证的重要一环，它的主软件配置管理是软件质量保证的重要一

23、环，它的主要任务是控制变化，同时也负责各个软件配置项和软件要任务是控制变化，同时也负责各个软件配置项和软件各种版本的标识、软件配置审计以及对软件配置发生的各种版本的标识、软件配置审计以及对软件配置发生的任何变化的报告。任何变化的报告。 具体来说，具体来说，软件配置管理主要有五项任务：标识、软件配置管理主要有五项任务：标识、版本控制、变化控制、配置审计和报告版本控制、变化控制、配置审计和报告。14.2 配置管理 （续）231 1、标识软件配置中的对象、标识软件配置中的对象 为了控制和管理软件配置项，为了控制和管理软件配置项，必须单独命名每个配必须单独命名每个配置项，然后用面向对象方法组织它们置项

24、，然后用面向对象方法组织它们。可以标识出两类。可以标识出两类对象：对象：基本对象基本对象和和聚集对象聚集对象( (可以把聚集对象作为代表软可以把聚集对象作为代表软件配置完整版本的一种机制件配置完整版本的一种机制) )。 每个对象都有一组能惟一地标识它的特征：名字、每个对象都有一组能惟一地标识它的特征：名字、描述、资源表和描述、资源表和“实现实现”。其中，对象名是无二义性地。其中，对象名是无二义性地标识该对象的一个字符串。标识该对象的一个字符串。二、软件配置管理过程二、软件配置管理过程 （续）（续）242 2、版本控制、版本控制 版本控制版本控制联合使用规程和工具，以管理在软件工程联合使用规程和

25、工具，以管理在软件工程过程中所创建的配置对象的不同版本。借助于版本控制过程中所创建的配置对象的不同版本。借助于版本控制技术，用户能够通过选择适当的版本来指定软件系统的技术，用户能够通过选择适当的版本来指定软件系统的配置。配置。实现这个目标的方法是，把实现这个目标的方法是，把属性属性和软件的每个版和软件的每个版本关联起来，然后通过描述一组所期望的属性来指定和本关联起来，然后通过描述一组所期望的属性来指定和构造所需要的配置构造所需要的配置。二、软件配置管理过程二、软件配置管理过程 （续）（续）25图14.2 演化图2 2、版本控制、版本控制 （续）（续）26 上面提到的上面提到的“属性属性”，既可

26、以简单到仅是赋给每个既可以简单到仅是赋给每个对象的特定版本号，也可以复杂到是一个布尔变量串对象的特定版本号，也可以复杂到是一个布尔变量串( (开开关关) )，该布尔变量串指明了施加到系统上的功能变化的特，该布尔变量串指明了施加到系统上的功能变化的特定类型定类型。 为构造一个程序的给定版本的适当变体，可以赋给为构造一个程序的给定版本的适当变体，可以赋给每个构件一个每个构件一个“属性元组属性元组”。所谓。所谓“属性元组属性元组”实际上实际上是一个特征表，当构造软件某版本的特定变体时，该特是一个特征表，当构造软件某版本的特定变体时，该特征表将指出是否应该使用这个构件。为每个变体都赋上征表将指出是否应

27、该使用这个构件。为每个变体都赋上一个或多个属性一个或多个属性。2 2、版本控制、版本控制 （续）（续）27图图14.3 14.3 版本和变体版本和变体2 2、版本控制、版本控制 （续）（续）黑白彩色283 3、变化控制、变化控制 对于大型软件开发项目来说，无控制的变化将迅速对于大型软件开发项目来说，无控制的变化将迅速导致混乱。变化控制把人的规程和自动工具结合起来，导致混乱。变化控制把人的规程和自动工具结合起来，以提供一个控制变化的机制。以提供一个控制变化的机制。 需建立统一的变化控制授权需建立统一的变化控制授权(change ontrol (change ontrol authority)au

28、thority)机构，由该机构机构，由该机构负责控制进入基线后的所有负责控制进入基线后的所有软件成份的变化。软件成份的变化。二、软件配置管理过程二、软件配置管理过程 （续）（续）29 变化控制过程：变化控制过程：识别变化识别变化提交变化报告提交变化报告变化控变化控制授权机构审查制授权机构审查审查通过，将变化要求插入到工程变化审查通过，将变化要求插入到工程变化序列序列当处理这个变化时确定该变化所涉及的软件配置管当处理这个变化时确定该变化所涉及的软件配置管理对象理对象将这些软件配置管理对象退出基线将这些软件配置管理对象退出基线实施真正实施真正的变化的变化测试和评审变化被正确实现测试和评审变化被正确

29、实现将变化后的软件将变化后的软件配置管理对象加入基线配置管理对象加入基线建立软件配置管理对象的新的版建立软件配置管理对象的新的版本本评估这种变化对其他软件配置管理对象的影响评估这种变化对其他软件配置管理对象的影响建建立整个软件新的版本立整个软件新的版本发布软件新的版本发布软件新的版本3 3、变化控制、变化控制 （续）（续）30 变化控制过程如图变化控制过程如图14.414.4所示，所示，访问和同步控制访问和同步控制如下图如下图所示。所示。21314 4、配置审计、配置审计 为确保适当地实现了所需要的变化，我们从两方面为确保适当地实现了所需要的变化，我们从两方面采用措施：采用措施：正式的技术复审

30、；正式的技术复审；软件配置审计。软件配置审计。 正式的技术复审正式的技术复审( (见见14.2.214.2.2节节) )关注被修改后的配置关注被修改后的配置对象的技术正确性。复审者评估该配置对象以确定它与对象的技术正确性。复审者评估该配置对象以确定它与其他软件配置项的一致性，并检查是否有遗漏或副作用。其他软件配置项的一致性，并检查是否有遗漏或副作用。 软件配置审计软件配置审计通过评估配置对象的那些通常不在复通过评估配置对象的那些通常不在复审过程中考虑的特征，而成为对正式技术复审的补充审过程中考虑的特征，而成为对正式技术复审的补充二、软件配置管理过程二、软件配置管理过程 （续）（续）325 5、

31、状态报告、状态报告 配置状态报告是软件配置管理的一项任务，它配置状态报告是软件配置管理的一项任务，它回答回答下述问题：下述问题：(1)(1)发生了什么事发生了什么事? ?(2)(2)谁做的这件事谁做的这件事? ?(3)(3)这件事是什么时候发生的这件事是什么时候发生的? ?(4)(4)它将影响哪些其他事物它将影响哪些其他事物? ?二、软件配置管理过程二、软件配置管理过程 （续）（续）3314.3 14.3 软件可靠性软件可靠性一、基本概念一、基本概念1 1、软件可靠性的定义、软件可靠性的定义 软件可靠性软件可靠性是程序在给定的时间间隔内，是程序在给定的时间间隔内，按照规格说明书的规定成功地运行

32、的概率。按照规格说明书的规定成功地运行的概率。34可靠性分级表可靠性分级表分级故障的后果开发工作量比例因子甚低低正常高甚高工作略有不便有损失但容易弥补损失弥补比较困难重大的经济损失危及人的生命0.750.881.001.151.40352 2、软件的可用性、软件的可用性 软件可用性的一个定义是：软件可用性的一个定义是： 软件可用性软件可用性是程序在给定的时间点，按照规格说明是程序在给定的时间点，按照规格说明书的规定，成功地运行的概率。书的规定，成功地运行的概率。 如果在一段时间内，软件系统故障停机时间分别为如果在一段时间内，软件系统故障停机时间分别为td1td1，td2td2，正常运行时间分别

33、为，正常运行时间分别为tu1tu1，tu2tu2，则系，则系统的稳态可用性为：统的稳态可用性为：其中其中T Tupup=tui=tui，T Tdowndown=tdi=tdidownupupssTTTA36 如果引入系统平均无故障时间如果引入系统平均无故障时间MTTFMTTF和平均维修时间和平均维修时间MTTRMTTR的概念，则前式可以变成的概念，则前式可以变成 平均维修时间平均维修时间MTTRMTTR是修复一个故障平均需要用的时间，是修复一个故障平均需要用的时间，它取决于维护人员的技术水平和对系统的熟悉程度，也和系它取决于维护人员的技术水平和对系统的熟悉程度，也和系统的可维护性有重要关系。统

34、的可维护性有重要关系。平均无故障时间平均无故障时间MTTFMTTF是系统按规是系统按规格说明书规定成功地运行的平均时间，它主要取决于系统中格说明书规定成功地运行的平均时间，它主要取决于系统中潜伏的错误的数目，因此和测试的关系十分密切。潜伏的错误的数目，因此和测试的关系十分密切。MTTRMTTFMTTFAss软件的稳态可用性软件的稳态可用性37 软件的平均无故障时间软件的平均无故障时间MTTFMTTF是一个重要的质量是一个重要的质量指标，往往作为对软件的一项要求，由用户提出来。指标，往往作为对软件的一项要求，由用户提出来。为了估算为了估算MTTFMTTF，首先引入一些有关的量。，首先引入一些有关

35、的量。二、估算平均无故障时间的方法二、估算平均无故障时间的方法381 1、符号、符号在估算在估算MTTFMTTF的过程中使用下述符号表示有关的数量：的过程中使用下述符号表示有关的数量：E ET T测试之前程序中测试之前程序中错误总数错误总数；I IT T程序长度程序长度( (机器指令总数机器指令总数) )；测试测试( (包括调试包括调试) )时间时间；E Ed d()()在在0 0至至期间期间发现的错误数发现的错误数；E Ec c()()在在0 0至至期间期间改正的错误数改正的错误数。二、估算平均无故障时间的方法二、估算平均无故障时间的方法 ( (续续) )392 2、基本假定、基本假定 根据

36、经验数据，可以作出下述假定。根据经验数据，可以作出下述假定。 在类似的程序中，单位长度里的错误数在类似的程序中，单位长度里的错误数E ET T/I/IT T近似为常数。近似为常数。美国的一些统计数字表明，通常美国的一些统计数字表明，通常0.50.51010-2-2EET T/I/IT T221010-2-2，也就是说，也就是说，在测试之前每在测试之前每10001000条指令中大约有条指令中大约有5 52020个错误个错误。 失效率正比于软件中剩余的失效率正比于软件中剩余的( (潜藏的潜藏的) )错误数，而平均无故错误数，而平均无故障时间障时间MTTFMTTF与剩余的错误数成反比与剩余的错误数成

37、反比。二、估算平均无故障时间的方法二、估算平均无故障时间的方法 ( (续续) )40 为了简化讨论，假设发现的每一个错误都立即正确为了简化讨论，假设发现的每一个错误都立即正确地改正了地改正了( (即，调试过程没有引入新的错误即，调试过程没有引入新的错误) )。因此。因此 E Ec c()=E()=Ed d()()剩余的错误数为剩余的错误数为 E Er r()=E()=ET T-E-Ec c()()单位长度程序中剩余的错误数为单位长度程序中剩余的错误数为 r r()=E()=ET T/I/Ir r-E-Ec c()/I()/IT T二、估算平均无故障时间的方法二、估算平均无故障时间的方法 ( (

38、续续) )413 3、估算平均无故障时间、估算平均无故障时间 经验表明，平均无故障时间与单位长度程序中剩余经验表明，平均无故障时间与单位长度程序中剩余的错误数成反比，即的错误数成反比，即其中其中K K为常数，它的值应该根据经验选取。美国的一些统为常数，它的值应该根据经验选取。美国的一些统计数字表明，计数字表明，K K的典型值是的典型值是200200。 估算平均无故障时间的公式，可以评价软件测试的估算平均无故障时间的公式，可以评价软件测试的进展情况。进展情况。)/ )(/(1TCTIEIEKMTTFT二、估算平均无故障时间的方法二、估算平均无故障时间的方法 ( (续续) )42此外，由前式可得此

39、外，由前式可得因此，也可以根据对软件平均无故障时间的要求，因此，也可以根据对软件平均无故障时间的要求，估计需要改正多少个错误之后，测试工作才能结估计需要改正多少个错误之后，测试工作才能结束。束。MTTFKIEETTC二、估算平均无故障时间的方法二、估算平均无故障时间的方法 ( (续续) )434 4、估计错误总数估计错误总数的方法的方法(1)(1)植入错误法植入错误法 使用这种估计方法，在测试之前由专人在程使用这种估计方法，在测试之前由专人在程序中随机地植入一些错误，测试之后，根据测试序中随机地植入一些错误，测试之后，根据测试小组发现的错误中原有的和植入的两种错误的比小组发现的错误中原有的和植

40、入的两种错误的比例，来估计程序中原有错误的总数例，来估计程序中原有错误的总数E ET T。二、估算平均无故障时间的方法二、估算平均无故障时间的方法 ( (续续) )44 假设人为地假设人为地植入的错误数为植入的错误数为NsNs，经过一段时间的测，经过一段时间的测试之后试之后发现发现nsns个植入的错误个植入的错误，此外还发现了，此外还发现了n n个原有的错个原有的错误误。如果可以认为测试方案发现植入错误和发现原有错如果可以认为测试方案发现植入错误和发现原有错误的能力相同误的能力相同，则能够，则能够估计出程序中原有错误的总数为估计出程序中原有错误的总数为其中其中N N即是错误总数即是错误总数E

41、ET T的估计值。的估计值。ssnNNn(1)(1)植入错误法植入错误法45(2)(2)分别测试法分别测试法 分别测试法使用两个测试员分别测试法使用两个测试员( (或测试小组或测试小组) )，彼此独立地测试同一个程序的两个副本，把其中彼此独立地测试同一个程序的两个副本，把其中一个测试员发现的错误作为有标记的错误。一个测试员发现的错误作为有标记的错误。 具体做法是，在测试过程的早期阶段，由测具体做法是，在测试过程的早期阶段，由测试员甲和测试员乙分别测试同一个程序的两个副试员甲和测试员乙分别测试同一个程序的两个副本，由另一名分析员分析他们的测试结果。本，由另一名分析员分析他们的测试结果。二、估算平

42、均无故障时间的方法二、估算平均无故障时间的方法 ( (续续) )46用用表示测试时间，假设表示测试时间，假设=0=0时错误总数为时错误总数为B B0 0；=1 1时时测试员甲发现的错误数为测试员甲发现的错误数为B B1 1；=1 1时测试员乙发现的错误数为时测试员乙发现的错误数为B B2 2；=1 1时两个测试员发现的相同错误数为时两个测试员发现的相同错误数为b bc c。 如果认为测试员甲发现的错误是有标记的，即程序中如果认为测试员甲发现的错误是有标记的，即程序中有标记的错误总数为有标记的错误总数为B B1 1，则测试员乙发现的，则测试员乙发现的B B2 2个错误中有个错误中有b bc c个

43、是有标记的。假定测试员乙发现有标记错误和发现无标个是有标记的。假定测试员乙发现有标记错误和发现无标记错误的概率相同，则可以估计出测试前程序中的错误总记错误的概率相同，则可以估计出测试前程序中的错误总数为数为(2)(2)分别测试法分别测试法47201cBBBb=0=0时错误总数为时错误总数为B B0 0；=1 1时时测试员甲发现的错误数为测试员甲发现的错误数为B B1 1；=1 1时测试员乙发现的错误数为时测试员乙发现的错误数为B B2 2；=1 1时两个测试员发现的相同错误数为时两个测试员发现的相同错误数为b bc c。(2)(2)分别测试法分别测试法48 使用分别测试法，在测试阶段的早期，每

44、隔一段时使用分别测试法，在测试阶段的早期，每隔一段时间分析员分析两名测试员的测试结果，并且用间分析员分析两名测试员的测试结果，并且用(5.8)(5.8)式计式计算算B B0 0。如果几次估算的结果相差不多，则可用。如果几次估算的结果相差不多，则可用B B0 0的平均值的平均值作为作为E ET T的估计值。的估计值。此后一名测试员可以改做其他工作，此后一名测试员可以改做其他工作，由余下的一名测试员继续完成测试工作，因为他可以继由余下的一名测试员继续完成测试工作，因为他可以继承另一名测试员的测试结果，所以分别测试法增加的测承另一名测试员的测试结果，所以分别测试法增加的测试成本并不太多试成本并不太多

45、。(2)(2)分别测试法分别测试法49三、软件容错技术n容错软件（有抗故障功能的软件）容错软件（有抗故障功能的软件）n屏蔽错误：屏蔽软件错误使之不致为害屏蔽错误：屏蔽软件错误使之不致为害n修复错误：使软件从错误状态恢复到正常状态修复错误：使软件从错误状态恢复到正常状态n减少影响：能在一定程度上使软件完成预定的功能减少影响：能在一定程度上使软件完成预定的功能n冗余技术冗余技术n结构冗余：设计备用模块，能进行模块切换结构冗余：设计备用模块，能进行模块切换n时间冗余：多花时间以检测并处理错误时间冗余：多花时间以检测并处理错误n信息冗余：采用校验码等冗余信息保证数据正确传输信息冗余：采用校验码等冗余信

46、息保证数据正确传输50静态冗余结构和动态冗余结构M1M2M3VM1M2MnI U u1 u2 u3 I 主模块 备用 备用 51容错软件设计建立需求说明建立需求说明，设计软件的，设计软件的非容错结构非容错结构分 析 错 误分 析 错 误类 型 确 定类 型 确 定容错范围容错范围确定采用的确定采用的冗余技术，冗余技术，修改结构修改结构评估容错效果评估容错效果 用于容错的冗余分支一般应由不同的开发小组独用于容错的冗余分支一般应由不同的开发小组独立进行设计和实现，以达到提高系统可靠性的目的。立进行设计和实现，以达到提高系统可靠性的目的。5214.4 IEEE1058.1 软件项目管理计划标准 一个

47、软件项目管理计划主要由三部分组成：要做的一个软件项目管理计划主要由三部分组成：要做的工作，要用的资源，要花的经费。工作，要用的资源，要花的经费。 软件开发需要各种资源，软件开发需要各种资源，主要资源有主要资源有：开发软件的：开发软件的人员，运行软件所需要的硬件和支持软件人员，运行软件所需要的硬件和支持软件( (例如，操作系例如，操作系统和版本控制软件统和版本控制软件) )。 对资源的使用将随着时间变化。对资源的使用将随着时间变化。在大型项目中，资在大型项目中，资源消耗源消耗RcRc随时间随时间t t的变化可以用的变化可以用RayleighRayleigh分布近似表示：分布近似表示：53图图14

48、.5 14.5 资源消耗随时间变资源消耗随时间变化化当时间当时间t=kt=k时，所需要时，所需要的资源量的资源量达到峰值。达到峰值。54 管理工作分成两类。管理工作分成两类。一类工作贯穿于项目全过程，不与软件开一类工作贯穿于项目全过程，不与软件开发的特定阶段相关联，这类工作称为发的特定阶段相关联，这类工作称为项目职责项目职责，例如，项目管理和，例如，项目管理和质量控制。质量控制。另一类工作与产品开发的特定阶段相联系，这类工作称另一类工作与产品开发的特定阶段相联系，这类工作称为为活动或任务活动或任务。 一个活动是一个大的工作单元，有它的开始时间和结束时间；一个活动是一个大的工作单元，有它的开始时

49、间和结束时间；它消耗资源，例如消耗计算机时间和人力；它产生工作产品，它消耗资源，例如消耗计算机时间和人力；它产生工作产品，例如例如预算、进度表、设计文档、源代码或用户手册。预算、进度表、设计文档、源代码或用户手册。一项活动又包含一一项活动又包含一系列任务，一个任务是应该管理的最小工作单元系列任务，一个任务是应该管理的最小工作单元。 因此，因此，在项目管理中有三种工作在项目管理中有三种工作，分别是项目职责、活动，分别是项目职责、活动( (大工大工作单元作单元) )和任务和任务( (小工作作单元小工作作单元) )。项目管理将贯穿于整个项目开发的。项目管理将贯穿于整个项目开发的始终。始终。14.4

50、IEEE1058.1 软件项目管理计划标准 (续)55 计划中的关键内容涉及工作产品的完成情况。工计划中的关键内容涉及工作产品的完成情况。工作产品预定完成的日期称为作产品预定完成的日期称为“里程碑里程碑”。 为了确定一件工作产品是否真正到达了一个里程为了确定一件工作产品是否真正到达了一个里程碑，必须通过一系列由开发组成员、管理部门和客户碑，必须通过一系列由开发组成员、管理部门和客户代表进行的审查。一个典型的里程碑是完成概要设计代表进行的审查。一个典型的里程碑是完成概要设计并且通过了审查的日期。并且通过了审查的日期。一旦一个工作产品经过审查一旦一个工作产品经过审查并被一致通过，它就成为一个基线并

51、被一致通过，它就成为一个基线。只有经过。只有经过12.3.212.3.2中描述的正式过程才能修改基线。中描述的正式过程才能修改基线。14.4 IEEE1058.1 软件项目管理计划标准 (续)56 一个一个工作包工作包不仅定义了工作产品，而且定义了人员不仅定义了工作产品，而且定义了人员需求、开发期限、资源、负责人姓名和验收该工作产品需求、开发期限、资源、负责人姓名和验收该工作产品的标准的标准 资金资金当然是软件项目计划的一个关键组成部分，必当然是软件项目计划的一个关键组成部分，必须拟定出详细的资金预算和资金分配方案。须拟定出详细的资金预算和资金分配方案。资金分配应资金分配应该针对每个项目职责和

52、活动，它是时间的函数该针对每个项目职责和活动，它是时间的函数。14.4 IEEE1058.1 软件项目管理计划标准 (续)57IEEEIEEE软件项目管理计划内容：软件项目管理计划内容：1 1引言引言2 2项目组织项目组织3 3管理过程管理过程4 4技术过程技术过程5 5工作包、进度和预算工作包、进度和预算6 6附加部分附加部分14.4 IEEE1058.1 软件项目管理计划标准 (续)58 1. 1. 引言引言 这部分由这部分由5 5个小部分组成，描述了要开发的项目和产品的概况。个小部分组成，描述了要开发的项目和产品的概况。 (1) (1) 项目概览项目概览 简要地描述项目目标、要交付的产品

53、、有关活动及其工作产简要地描述项目目标、要交付的产品、有关活动及其工作产品。此外，还要列出里程碑、所需的资源、主要的进度以及主要品。此外，还要列出里程碑、所需的资源、主要的进度以及主要预算。预算。 (2) (2) 项目交付项目交付 列出所有要交付给客户的软件配置项和交付的日期。列出所有要交付给客户的软件配置项和交付的日期。IEEEIEEE软件项目管理计划内容软件项目管理计划内容59 (3) (3) 软件项目管理计划的演变软件项目管理计划的演变 没有什么计划能一成不变地执行。软件项目管理计划和其他没有什么计划能一成不变地执行。软件项目管理计划和其他计划一样，必须随着经验的积累以及客户方与开发方的

54、变化而变计划一样，必须随着经验的积累以及客户方与开发方的变化而变化。在这部分描述改变计划的正式规程和机制。化。在这部分描述改变计划的正式规程和机制。 (4) (4) 参考资料参考资料 在这部分列出软件项目管理计划引用的所有参考文档。在这部分列出软件项目管理计划引用的所有参考文档。 (5) (5) 术语定义和缩写词术语定义和缩写词 这些信息确保每个人都能以同样方式理解软件项目管理计划。这些信息确保每个人都能以同样方式理解软件项目管理计划。 1. 1. 引言引言 ( (续续) )60 2. 2. 项目组织项目组织 这部分中的这部分中的4 4个小部分，从软件过程的角度和开发者的组织结个小部分，从软件

55、过程的角度和开发者的组织结构的角度，说明了产品是怎样开发的。构的角度，说明了产品是怎样开发的。 (1) (1) 过程模型过程模型 根据活动根据活动( (例如，产品设计或产品测试例如，产品设计或产品测试) )和项目职责和项目职责( (例如，项例如，项目管理或配置管理目管理或配置管理) )来确定过程模型。过程模型的关键内容有里来确定过程模型。过程模型的关键内容有里程碑、基线、评审、工作产品以及可交付性。程碑、基线、评审、工作产品以及可交付性。 (2) (2) 组织结构组织结构 描述开发组织的管理结构。在组织中划定权限和明确责任是描述开发组织的管理结构。在组织中划定权限和明确责任是很重要的。很重要的

56、。 (3) (3) 组织的边界和界面组织的边界和界面IEEEIEEE软件项目管理计划内容软件项目管理计划内容 （续）（续）61 没有一个项目是在真空中完成的，项目组成员必须与客户和没有一个项目是在真空中完成的，项目组成员必须与客户和本组织内的其他成员打交道。此外，在大型项目中还可能牵涉到本组织内的其他成员打交道。此外，在大型项目中还可能牵涉到转包商。转包商。必须制定出项目本身与其他实体之间在行政上和管理上必须制定出项目本身与其他实体之间在行政上和管理上的界线。的界线。在许多软件组织内部包含两种类型的组织：完成特定开在许多软件组织内部包含两种类型的组织：完成特定开发项目的开发组和起支持作用的支持

57、组发项目的开发组和起支持作用的支持组( (例如配置管理组和例如配置管理组和SQASQA组组) )。如果本项目有支持组介入，则项目组和支持组之间的行政、如果本项目有支持组介入，则项目组和支持组之间的行政、管理界线也必须清楚地定义。管理界线也必须清楚地定义。 (4) (4) 项目责任项目责任 针对每个项目职责针对每个项目职责(例如例如SQA)和每项活动和每项活动(例如产品测试例如产品测试)，必须明确地指定好个人的责任。必须明确地指定好个人的责任。 2. 2. 项目组织项目组织 （续）（续）62 3. 3. 管理过程管理过程 这部分的这部分的5 5个小部分描述怎样对软件项目进行管理。个小部分描述怎样

58、对软件项目进行管理。 (1) (1) 管理的目标和优先级管理的目标和优先级 描述管理的原理、目标和优先级。本部分的内容可能包括提描述管理的原理、目标和优先级。本部分的内容可能包括提交报告的频率和机制、不同需求的相对优先关系、项目的进度和交报告的频率和机制、不同需求的相对优先关系、项目的进度和资金预算，以及风险管理过程。资金预算，以及风险管理过程。 (2) (2) 假设、依赖性和约束假设、依赖性和约束 列出在规格说明文档及其他文档中包含的所有假设、依赖性列出在规格说明文档及其他文档中包含的所有假设、依赖性和约束。和约束。IEEEIEEE软件项目管理计划内容软件项目管理计划内容 （续）（续）63

59、(3) (3) 风险管理风险管理 在本小节中列出项目中存在的多种风险因素和跟踪风险的机制。在本小节中列出项目中存在的多种风险因素和跟踪风险的机制。 (4) (4) 监督和控制机制监督和控制机制 详细地描述项目报告机制，包括复查和审计机制。详细地描述项目报告机制，包括复查和审计机制。 (5) (5) 人员计划人员计划 项目中的有关人员是重要的资源。在这一小节中列出所需人员的项目中的有关人员是重要的资源。在这一小节中列出所需人员的类型和数量，并且指明需要他们参与工作的时间。类型和数量，并且指明需要他们参与工作的时间。 3. 3. 管理过程管理过程 （续）（续）64 4. 4. 技术过程技术过程 本

60、部分包括本部分包括3 3个小部分，指明该项目的技术方面。个小部分，指明该项目的技术方面。 (1) (1) 方法、工具和技术方法、工具和技术 详细地描述有关软件和硬件的技术方面，应该覆盖的内容包详细地描述有关软件和硬件的技术方面，应该覆盖的内容包括：开发产品所用的计算机系统括：开发产品所用的计算机系统( (硬件、操作系统和软件硬件、操作系统和软件) )，以及，以及产品运行的目标系统。其他需要描述的内容有：所用的开发技术、产品运行的目标系统。其他需要描述的内容有：所用的开发技术、测试技术、开发小组的结构、编程语言和测试技术、开发小组的结构、编程语言和CASECASE工具。此外，也应工具。此外，也应