软件工程 第十二章

《软件工程 第十二章》由会员分享，可在线阅读，更多相关《软件工程 第十二章（61页珍藏版）》请在金锄头文库上搜索。

1、第十二章 软件质量管理n从质量保证到质量认证n质量保证n软件可靠性n程序正确性证明nCMM软件能力成熟度模型nISO9000 国际标准n软件度量112.1从软件质量保证到质量认证 n质量管理的三个阶段n质量检验：测试与纠错n全面质量管理TQC n质量认证nCMM软件能力成熟度模型 nISO 9000国际标准 2质量是产品的生命，不论生产什么产品，质量都是 极端重要的。软件产品开发周期长，耗费巨大的人力和 物力，更必须特别注意保证质量。 一、软件质量软件质量就是“软件与明确地和隐含地定义的需求 相一致的程度”。更具体地说，软件质量是软件符合明 确地叙述的功能和性能需求、文档中明确描述的开发标 准

2、、以及所有专业开发的软件都应具有的隐含特征的程 度。上述定义强调了下述的三个要点。12.2质量保证3 软件需求是度量软件质量的基础，与需求不一致就是 质量不高。 指定的标准定义了一组指导软件开发的准则，如果没 有遵守这些准则，几乎肯定会导致质量不高。 通常，有一组没有显式描述的隐含需求(例如，期望软 件是容易维护的)。如果软件满足明确描述的需求，但却 不满足隐含的需求，那么软件的质量仍然是值得怀疑的 。4图14.1软件质量因素与产品活动的关系影响软件质量的主要因素从管理角度对软件质量的度量。可 以把这些质量因素划分成三组，它们分别反映用户在使用软件产 品时的三种不同倾向或观点。McCall 的

3、软件 质量要 素512.2.1 软件的质量属性612.2.2 质量保证的活动内容 复审：计划与开发方法：设计、编码控制：软件配置软件测试开发方法符 合“软件开发 规范”计划、开发 等各阶段均 需要复审确保各阶段要 产生完整、正 确的配置项71.验证与确认n验证：为了确定开发时期中某一阶段的 产品是否达到了前一阶段对它的需求，包含开发时期各个阶段进行的复审、复查 与测试活动；n确认：整个开发结束过程时对开发能否 满足软件需求的总评价，主要指测试阶段的确认测试和验收时的 系统测试等活动82.开发时期的配置管理n软件配置：生存周期中各个阶段产生的文档和 程序n配置管理中心思想：在软件开发过程中，开发

4、 者有权对本阶段的阶段产品进行更改，但一旦阶 段产品通过了复审，就应将它交给配置管理人员 去控制，任何人（包括编制这一文档的人员）需 要对它更改时，都要进行正式的批准手续92、基线基线是一个软件配置管理概念，它有助于我们在不严重 妨碍合理变化的前提下来控制变化。IEEE把基线定义为：已经通过了正式复审的规格说明或中间产品，它可以作 为进一步开发的基础，并且只有通过正式的变化控制过程才 能改变它。一、软件配置 （续）1012.3 软件可靠性一、基本概念1、软件可靠性的定义软件可靠性是程序在给定的时间间隔内， 按照规格说明书的规定成功地运行的概率。112、软件的可用性软件可用性的一个定义是：软件可

5、用性是程序在给定的时间点，按照规格说明 书的规定，成功地运行的概率。如果在一段时间内，软件系统故障停机时间分别为 td1，td2，正常运行时间分别为tu1，tu2，则系 统的稳态可用性为：其中Tup=tui，Tdown=tdi12如果引入系统平均无故障时间MTTF和平均维修时间MTTR 的概念，则前式可以变成平均维修时间MTTR是修复一个故障平均需要用的时间， 它取决于维护人员的技术水平和对系统的熟悉程度，也和系 统的可维护性有重要关系。平均无故障时间MTTF是系统按规 格说明书规定成功地运行的平均时间，它主要取决于系统中 潜伏的错误的数目，因此和测试的关系十分密切。软件的稳态可用性13可靠性

6、分级表分级故障的后果开发工作量比例因子 甚低 低 正常 高 甚高工作略有不便 有损失但容易弥补 损失弥补比较困难 重大的经济损 失 危及人的生命0.75 0.88 1.00 1.15 1.401412.3.2 可靠性模型n可靠性模型：宏观模型和微观模型 宏观模型：建立在对程序语句和控制结构 详细分析的基础上的，在开发时期很难建 立 微观模型：忽略程序在结构方面的细节， 主要从程序中残留错误的角度来建立模型 ，并且用统计方法确定模型中的常数15程序的故障率与遗留错误的数量成正比根据程序中遗留的错误的多少，就可以预测程序可靠性1.正比于遗留故障数的宏观模型161、符号 在估算MTTF的过程中使用下

7、述符号表示有关的数量： ET测试之前程序中错误总数； IT程序长度(机器指令总数)； 测试(包括调试)时间； Ec()在0至期间改正的错误数。 Er()在时间时的遗留错误量；17因此 剩余的错误数为Er()=ET-Ec() 单位长度程序中剩余的错误数为r()=ET/Ir-Ec()/IT182、估算平均无故障时间经验表明，平均无故障时间与单位长度 程序中剩余的错误数成反比，即其中K为常数，它的值应该根据经验选取。美 国的一些统计数字表明，K的典型值是200。估算平均无故障时间的公式，可以评价 软件测试的进展情况。19此外，由前式可得因此，也可以根据对软件平均无故障时间的要求 ，估计需要改正多少个

8、错误之后，测试工作才能 结束。203、错误植入模型 使用这种估计方法，在测试之前由专人在程序中 随机地植入一些错误，测试之后，根据测试小组 发现的错误中原有的和植入的两种错误的比例， 来估计程序中原有错误的总数ET。21假设人为地植入的错误数为Ns，经过一段时间的测 试之后发现ns个植入的错误，此外还发现了n个原有的错 误。如果可以认为测试方案发现植入错误和发现原有错 误的能力相同，则能够估计出程序中原有错误的总数为其中N即是错误总数ET的估计值。错误植入模型22(2)分别测试法分别测试法使用两个测试员(或测试小组)， 彼此独立地测试同一个程序的两个副本，把其中 一个测试员发现的错误作为有标记

9、的错误。具体做法是，在测试过程的早期阶段，由测 试员甲和测试员乙分别测试同一个程序的两个副 本，由另一名分析员分析他们的测试结果。23用表示测试时间，假设 =0时错误总数为B0； =1时测试员甲发现的错误数为B1； =1时测试员乙发现的错误数为B2； =1时两个测试员发现的相同错误数为bc。如果认为测试员甲发现的错误是有标记的，即程序中 有标记的错误总数为B1，则测试员乙发现的B2个错误中有bc 个是有标记的。假定测试员乙发现有标记错误和发现无标 记错误的概率相同，则可以估计出测试前程序中的错误总 数为(2)分别测试法24=0时错误总数为B0； =1时测试员甲发现的错误数为B1； =1时测试员

10、乙发现的错误数为B2； =1时两个测试员发现的相同错误数为bc 。(2)分别测试法25使用分别测试法，在测试阶段的早期，每隔一段时 间分析员分析两名测试员的测试结果，并且用(5.8)式计 算B0。如果几次估算的结果相差不多，则可用B0的平均值 作为ET的估计值。此后一名测试员可以改做其他工作，由 余下的一名测试员继续完成测试工作，因为他可以继承 另一名测试员的测试结果，所以分别测试法增加的测试 成本并不太多。(2)分别测试法26三、软件容错技术n容错软件（有抗故障功能的软件）n屏蔽错误：屏蔽软件错误使之不致为害n修复错误：使软件从错误状态恢复到正常状态n减少影响：能在一定程度上使软件完成预定的

11、功能n冗余技术n结构冗余：设计备用模块，能进行模块切换n时间冗余：多花时间以检测并处理错误n信息冗余：采用校验码等冗余信息保证数据正确传 输27静态冗余结构和动态冗余结构M1M2M3VM1M2MnI U u1 u2 u3 I 主模块 备用 备用 28容错软件设计建立需求说明 ，设计软件的 非容错结构分析错误 类型确定 容错范围确定采用的 冗余技术， 修改结构评估容错效果用于容错的冗余分支一般应由不同的开发小组独 立进行设计和实现，以达到提高系统可靠性的目的。29容错软件设计n说明几点： 要选择好冗余单位 冗余单元较小的系统，其可靠性一般较大 强调容错软件中的各个冗余分支应由不同 的开发小组独立

12、进行设计3012.4 程序正确性证明n基本思想：就是通过数学的方法，证明程序 具有某些需要的性质n方法与技术：输入-输出断言法、最弱前置条 件法、结构归纳法31程序正确性证明n输入-输出断言法基本做法：在源程序的入口、出口和中间 各点分别设置断言，为了证明在两个相邻 点之间的程序段是正确的，只需证明在这 一程序段执行后，能够使在它之前的断言 变成其后一点的断言就可以了3212.5 CMM软件能力成熟度模型nCMM：软件过程能力成熟度模型nCMM框架：软件能力成熟度模型、系统 工程能力成熟度模型、软件采购成熟度模 型、继承产品和过程开发3312.5.1 CMM的基本概念软件过程包括各种活动、技术

13、和工具，因此，它实 际上既包括了软件生产的技术方面又包括了管理方面。 CMM策略力图改进软件过程的管理，而在技术方面的 改进是其必然的结果。必须记住，对软件过程的改进不可能在一夜之间完 成，CMM是以增量方式逐步引入变化的。CMM明确地定义 了5个不同的成熟度等级，一个软件开发组织可用一系列 小的改良性步骤向更高的成熟度等级迈进。34能力成熟度模型包括以下的组成成分。(1)成熟度等级(MaturityLevels)：一个成熟度等级是 在朝着实现成熟软件过程进化途中的一个妥善定义的平台。 五个成熟度等级构成了CMM的顶层结构。(2)过程能力(ProcessCapability)：软件过程能力描述

14、 ，通过遵循软件过程能实现预期结果的程度。一个组织的软 件过程能力提供一种“预测该组织承担下一个软件项目时， 预期最可能得到的结果”的方法。35(3)关键过程域(KeyProcessAreas，KPA)：每个成熟 度等级由若干关键过程域组成。每个关键过程域都标识出一串相关的活动，对比这 些活动都完成时所达到的一组目标，对建立该过程成熟 度等级是至关重要的。关键过程域分别定义在各个成熟 度等级之中，并与之关联在一起。例如，等级2的一个关键过程域是软件项目计划。36(4)目标(Goals)：目标概括了关键过程域中的关键 实践，并可用于确定一个组织或项目是否已有效地实施 了该关键过程域。目标表示每个

15、关键过程域的范围、边 界和意图，例如，关键过程域“软件项目计划”的一个目标是 ，“软件估算已经文档化，供计划和跟踪软件项目使用 。”37(5)公共特性(CommonFeatures)：CMM把关键实践分 别归入下列五个公共特性之中：执行约定、执行能力、 执行的活动、测量和分析以及验证实施。公共特性是一种属性，它能指示一个关键过程域的 实施和规范化是否是有效的、可重复的和持久的。14.8 能力成熟度模型 （续）38(6)关键实践(KeyPractices)：每个关键过程域都用 若干关键实践描述，实施关键实践有助于实现相应的关 键过程域的目标。关键实践描述对关键过程域的有效实施和规范化贡 献最大的

16、基础设施和活动。例如，在关键过程域“软件项目计划”中，一个关 键实践是“按照已文档化的规程制定项目的软件开发计 划”。14.8 能力成熟度模型 （续）39CMM的结构40CMM通过定义能力成熟度的五个等级，引导软件开发 组织不断识别出其软件过程的缺陷，并指出应该做哪些 改进，但是，它并不提供做这些改进的具体措施。能力成熟度的五个等级从低到高是：初始级、可重 复级、已定义级、已管理级和优化级。12.5.2 软件能力成熟度等级41(1)初始级软件过程的特征是无序的，有时甚至是混乱的。几乎没有什么过程 是经过定义的，项目能否成功完全取决于个人能力。 (2)可重复级建立了基本的项目管理过程，以追踪成本、进度和功能性。必要的 过程规范已经建立起来了，使得可以重复以前类似项目所取得的成功。关键过程域如下： n软件配置管理 n软件质量保证 n软件子合同管理 n软件项目跟踪和监督 n软件项目计划 n需求管理能力成熟度的五个等级42(3)已定义级用于管理和工程活动的软件过程已经文档化和标准化，