第13章 软件质量管理.ppt

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