软件质量管理课件.ppt

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

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

3、以把这些质量因素划分成三组，它们分别反映用户在使用软件产品时的三种不同倾向或观点。这三种倾向是：产品运行，产品修改和产品转移。 表 12.3 12.3 软件质量因素的定义 质量因素 定义 正确性 系统满足规格说明和用户目标的程度，即，在预定环境下能正确地完成预期功能的程度 健壮性 在硬件发生故障、 输入的数据无效或操作错误等意外环境下，系统能做出适当响应的程度 效率 为了完成预定的功能，系统需要的计算资源的多少 完整性(安全性) 对未经授权的人使用软件或数据的企图，系统能够控制(禁止)的程度 可用性 系统在完成预定应该完成的功能时令人满意的程度 风险 按预定的成本和进度把系统开发出来，并且为用

4、户所满意的概率 一、软件质量 （续） 二、软件质量保证措施 软件质量保证(Software Quality Assurance，SQA)的措施主要有： ?基于非执行的测试(也称为复审)：用于保证软件在编码之前各阶段产生的文档的质量 ?基于执行的测试：在程序编写出来之后进行，是保证软件质量的最后一道防线 ?程序正确性证明：用数学方法来严格验证程序是否与对它的说明完全一致 14.2 质量保证 参加软件质量保证的人员分为： ?软件工程师：软件工程师：通过采用可靠的技术方法和度量、进行正式的技术复审以及完成计划周密的测试保证软件质量 ?SQA小组：辅助软件工程小组以获得高质量的软件产品，包括计划、监督

5、、记录、分析和报告。 二、软件质量保证措施 （续） 1、技术复审的必要性 正式技术复审的明显优点是，能够较早地发现错误，防止错误被传播到软件过程的后续阶段。 正式技术复审实际上是一类复审方法，包括走查(Walkthrough)和审查(Inspection)等具体方法。走查的步骤比审查少，而且没有审查那样正规。 二、软件质量保证措施 （续） 2、走查 (1)参与者驱动法 参与者按照事先准备好的列表，提出他们不理解的术语和认为不正确的术语。文档编写组的代表必须对每个质疑做出回答，要么承认确实有错误，要么对质疑做出解释。 (2)文档驱动法 文档编写者向走查组成员仔细解释文档。走查组成员在此过程中不时

6、针对事先准备好的问题或解释过程中发现的问题提出质疑。这种方法可能比第一种方法更彻底，往往能检测出更多错误。经验表明，采用文档驱动法时许多错误是由文档讲解者自己发现的。 二、软件质量保证措施 （续） 3、审查 审查的范围要比走查广泛得多，它的步骤也比较多。一般来说，审查有5个基本步骤。 (1)综述：由负责编写文档的一名成员向审查组成员综述该文档。综述会议结束时把文档分发给每位与会者。 (2)准备：评审员仔细阅读文档。最好列出在审查中发现的错误的类型，并按发生频率把错误类型分级，以辅助审查工作的进行。这些列表有助于评审员们把注意力集中到最常发生错误的区域。 二、软件质量保证措施 （续） (3)审查

7、：评审组仔细走查整个文档。和走查一样，这一步的目的也是找出文档中的错误，而不是改正它们。审查组组长必须在一天之内写出一份关于审查的报告。通常每次审查会不超过90分钟。 (4)返工：文档的作者负责解决在书面报告中列出的所有错误及问题。 (5)跟踪：组长必须确保所提出的每个问题都得到了圆满的解决(要么修正了文档，要么澄清了被误认为是错误的条目)。必须检查对文档所做的每个修正，以确保没有引入新的错误。如果在审查过程中返工量超过5%，则应该召集审查组再对文档全面地审查一遍。 3、审查 （续） 可用错误检验表辅助发现错误或对错误进行发分类。可用错误检验表辅助发现错误或对错误进行发分类。 二、软件质量保证

8、措施 （续） 数据引用错误 使用未赋值的变量，变量赋值后从不使用等 数据说明错误 变量未做说明，变量类型与初始化值不符等 数据计算错误 混合类型运算，用零作除等 数据比较错误 比较运算符和逻辑运算符使用不当，在不同类型变量间比较等 控制流程错误 多做或少做了一次循环，在循环体中对循环变量重新定义等 接口错误 实参和形参的类型、顺序、数量不符，全程变量在个模块中的定义不一致等 输入输出错误 忘记打开或关闭文件，I/O 出错处理不正确等 4、程序正确性证明 正确性证明的基本思想是证明程序能完成预定的功能。因此，应该提供对程序功能的严格数学说明，然后根据程序代码证明程序确实能实现它的功能说明。如果在

9、程序的若干个点上，设计者可以提出关于程序变量及它们的关系的断言，那么在每一点上的断言都应该永远是真的。假设在程序的P1，P2，Pn等点上的断言分别是a(1)，a(2)，a(n)，其中a(1)必须是关于程序输入的断言，a(n)必须是关于程序输出的断言。 为了证明在点Pi和Pi+1之间的程序语句是正确的，必须证明执行这些语句之后将使断言a(i)变成a(i+1)。如果对程序内所有相邻点都能完成上述证明过程，则证明了输入断言加上程序可以导出输出断言。如果输入断言和输出断言是正确的，而且程序确实是可以终止的(不包含死循环)，则上述过程就证明了程序的正确性。 二、软件质量保证措施 （续） 14.3 软件可

10、靠性 ? ?1. ?对于软件可靠性有许多不同的定义，其中多数人承认 ?软件可靠性是程序在给定的时间间隔内，按照规格说 ?2. ? 通常用户也很关注软件系统可以使用的程度。一般来说，对于任何其故障是可以修复的系统，都应该同时 ? ? 软件可用性是程序在给定的时间点，按照规格说明 ? 如果在一段时间内，软件系统故障停机时间分别为td1，td2，正常运行时间分别为tu1，tu2，则系统 ? ?其中 Tup = tui Tdown = tdi ? 如果引入系统平均无故障时间MTTF和平均维修时间MTTR的概念，则(5.1)式可以变成 ? ? 平均维修时间MTTR是修复一个故障平均需要用的时间，它取决于

11、维护人员的技术水平和对系统的熟悉程度，也和系统的可维护性有重要关系。平均无故障时间MTTF是系统按规格说明书规定成功地运行的平均时间，它主要取决于系统中潜伏的错误的数目，因此和测试的关系十分密切。 ? downupupssTTTA?MTTRMTTFMTTFAss?3. ? 软件的平均无故障时间MTTF是一个重要的质量指 ?标，往往作为对软件的一项要求，由用户提出来。为 ?了估算MTTF ?(1). ? 在估算MTTF的过程中使用下述符号表示有关的数量： ET测试之前程序中错误总数 ? IT程序长度(机器指令总数) ? 测试(包括调试) ? Ed( )在0至 ? Ec( )在0至 ?(2). ?

12、 ? 在类似的程序中，单位长度里的错误数ET/IT近似为常 ? 0.5 10-2 ET/IT210-2 ?也就是说，在测试之前每1000条指令中大约有520个错 ? 失效率正比于软件中剩余的(潜藏的)错误数，而平均无故障时间MTTF ? 此外，为了简化讨论，假设发现的每一个错误都立即正确地改正了(即，调试过程没有引入新的错误)。因 ? Ec()=Ed() ? 剩余的错误数为 ? Er()=ET-Ec() ? ? r()=ET/Ir-Ec()/IT ?(3). 经验表明，平均无故障时间与单位长度程序中剩余 的错误数成反比，即 其中K为常数，它的值应该根据经验选取。美国的一些统 计数字表明，K的典

13、型值是200 估算平均无故障时间的公式，可以评价软件测试的进 展情况。此外，由(5.5) 因此，也可以根据对软件平均无故障时间的要求，估 计需要改正多少个错误之后，测试工作才能结束。 )/ )(/(1TCTIEIEKMTTFT?MTTFKIEETTC?(4). a. 使用这种估计方法，在测试之前由专人在程序中随 机地植入一些错误，测试之后，根据测试小组发现的错 误中原有的和植入的两种错误的比例，来估计程序中原 有错误的总数ET 假设人为地植入的错误数为Ns，经过一段时间的测试 之后发现ns个植入的错误，此外还发现了n个原有的错 误。如果可以认为测试方案发现植入错误和发现原有错 误的能力相同，则

14、能够估计出程序中原有错误的总数为 Nt = *Ns 其中Nt即是错误总数ET的估计值。 snn b. 为了随机地给一部分错误加标记，分别测试法使用两个测试员(或测试小组)，彼此独立地测试同一个程序的两个副本，把其中一个测试员发现的错误作为有标记的错误。具体做法是，在测试过程的早期阶段，由测试员甲和测试员乙分别测试同一个程序的两个副本，由另一名分析员分析他们的测试结果。用 表示测试时间，假设: ? =0时错误总数为B0 ? = 1时测试员甲发现的错误数为B1 1 ? = 1时测试员乙发现的错误数为B2 2 ? = 1时两个测试员发现的相同错误数为bc c ? 如果认为测试员甲发现的错误是有标记的

15、，即程序中有标记的错误总数为B1，则测试员乙发现的B2个错误中有bc个是有标记的。假定测试员乙发现有标记错误和发现无标记错误的概率相同，则可以估计出测试 ? ? ? ? 使用分别测试法，在测试阶段的早期，每隔一段时间分析员分析两名测试员的测试结果，并且用(5.8)式计算B0。如果几次估算的结果相差不多，则可用B0的平均值作为ET的估计值。此后一名测试员可以改做其他工作，由余下的一名测试员继续完成测试工作，因为他可以继承另一名测试员的测试结果，所以分别 120BbBBC?14.4 配置管理 软件配置管理的主要目的就是控制在软件开发过程中的各种变化、修改的管理，从某种意义上是软件质量保证的一部分，

16、但专注于软件各个成份的变化和修改的控制，从而保证各个成份之间的一致性。 软件配置管理从总的来说包括识别软件变化、控制变化、保证变化正确进行以及向感兴趣的其他人员报告变化。 软件配置管理活动，包括： ?识别软件成份，并具体确定软件配置管理的对象 ?软件成份的版本控制(version control)，维持各个成份之间一致的版本 ?变化控制(change control)：以严格的过程控制软件成份的变化 ?配置审核(configuration auditing)：保证所要进行的变化正确地实现 ?报告(reporting)：向其他相关成员报告软件成份的变化 14.4 配置管理 （续） 软件配置管理不

17、同于软件维护。维护是在软件交付给用户使用后才发生的，而给用户使用后才发生的，而软件配置管理是在软件项目启动时就开始，并且一直持续到软件退役后才终止的一组跟踪和控制活动。 软件配置管理的软件配置管理的目标是，使变化更容易被适应，并且在必须变化时减少所需花费的工作量。 14.4 配置管理 （续） 一、软件配置 1、软件配置项 软件过程的输出信息可以分为三类： （1）计算机程序(源代码和可执行程序)； （2）描述计算机程序的文档(供技术人员或用户使用)； （3）数据(程序内包含的或在程序外的)。 上述这些项组成了在软件过程中产生的全部信息，我们把它们统称为软件配置，而这些项就是软件配置项。 可以把软

18、件配置管理看作是应用于整个软件过程的软件质量保证活动，是专门用于管理变化的软件质量保证活动。 导致软件配置项发生变化的原因：书 P257-258 共5点 14.4 配置管理 （续） 2、基线 基线是一个软件配置管理概念，它有助于我们在不严重妨碍合理变化的前提下来控制变化。 IEEE把基线定义为： 已经通过了正式复审的规格说明或中间产品，它可以作为进一步开发的基础，并且只有通过正式的变化控制过程才能改变它。 一、软件配置 （续） 基线就是通过了正式复审的软件配置项。在软件配置项变成基线之前，可以迅速而非正式地修改它。一旦建立了基线之后，虽然仍然可以实现变化，但是，必须应用特定的、正式的过程(称为

19、规程)来评估、实现和验证每个变化。 书例：软件配置项与基线，P258-259共13点 一、软件配置 （续） 二、软件配置管理过程 软件配置管理是软件质量保证的重要一环，它的主要任务是控制变化，同时也负责各个软件配置项和软件各种版本的标识、软件配置审计以及对软件配置发生的任何变化的报告。 具体来说，软件配置管理主要有五项任务：标识、版本控制、变化控制、配置审计和报告。 14.4 配置管理 （续） 1、标识软件配置中的对象 为了控制和管理软件配置项，必须单独命名每个配置项，然后用面向对象方法组织它们。可以标识出两类对象：基本对象和聚集对象(可以把聚集对象作为代表软件配置完整版本的一种机制)。 每个

20、对象都有一组能惟一地标识它的特征：名字、描述、资源表和“实现”。其中，对象名是无二义性地标识该对象的一个字符串。 二、软件配置管理过程 （续） 2、版本控制 版本控制联合使用规程和工具，以管理在软件工程过程中所创建的配置对象的不同版本。借助于版本控制技术，用户能够通过选择适当的版本来指定软件系统的配置。实现这个目标的方法是，把属性和软件的每个版本关联起来，然后通过描述一组所期望的属性来指定和构造所需要的配置。 二、软件配置管理过程 （续） 图14.2 演化图 2、版本控制 （续） 上面提到的“属性”，既可以简单到仅是赋给每个对象的特定版本号，也可以复杂到是一个布尔变量串(开关)，该布尔变量串指

21、明了施加到系统上的功能变化的特定类型。 为构造一个程序的给定版本的适当变体，可以赋给每个构件一个“属性元组”。所谓“属性元组”实际上是一个特征表，当构造软件某版本的特定变体时，该特征表将指出是否应该使用这个构件。为每个变体都赋上一个或多个属性。 2、版本控制 （续） 图14.3 版本和变体 2、版本控制 （续） 黑白 彩色 3、变化控制 对于大型软件开发项目来说，无控制的变化将迅速导致混乱。变化控制把人的规程和自动工具结合起来，以提供一个控制变化的机制。 需建立统一的变化控制授权(change ontrol authority)机构，由该机构负责控制进入基线后的所有软件成份的变化。 二、软件配

22、置管理过程 （续） 变化控制过程：识别变化提交变化报告变化控制授权机构审查审查通过，将变化要求插入到工程变化序列当处理这个变化时确定该变化所涉及的软件配置管理对象将这些软件配置管理对象退出基线实施真正的变化测试和评审变化被正确实现将变化后的软件配置管理对象加入基线建立软件配置管理对象的新的版本评估这种变化对其他软件配置管理对象的影响建立整个软件新的版本发布软件新的版本 3、变化控制 （续） 变化控制过程如图14.4(书P262)所示，访问和同步控制如下图所示。 2 1 4、配置审计 为确保适当地实现了所需要的变化，我们从两方面采用措施：正式的技术复审；软件配置审计。 正式的技术复审(见14.2

23、.2节)关注被修改后的配置对象的技术正确性。复审者评估该配置对象以确定它与其他软件配置项的一致性，并检查是否有遗漏或副作用。 软件配置审计通过评估配置对象的那些通常不在复审过程中考虑的特征，而成为对正式技术复审的补充 二、软件配置管理过程 （续） 5、状态报告 配置状态报告是软件配置管理的一项任务，它回答下述问题： (1)发生了什么事? (2)谁做的这件事? (3)这件事是什么时候发生的? (4)它将影响哪些其他事物? 二、软件配置管理过程 （续） 14.5 IEEE1058.1 软件项目管理计划标准 一个软件项目管理计划主要由三部分组成：要做的一个软件项目管理计划主要由三部分组成：要做的工作

24、，要用的资源，要花的经费。工作，要用的资源，要花的经费。 软件开发需要各种资源，主要资源有：开发软件的：开发软件的人员，运行软件所需要的硬件和支持软件( (例如，操作系统和版本控制软件) ) 对资源的使用将随着时间变化。在大型项目中，资在大型项目中，资源消耗RcRc随时间t t的变化可以用的变化可以用RayleighRayleigh分布近似表示：分布近似表示： 图13.1 资源消耗随时间变化 当时间t=kt=k时，所需要的资源量达到峰值。 管理工作分成两类。一类工作贯穿于项目全过程，不与软件开发的特定阶段相关联，这类工作称为项目职责，例如，项目管理和质量控制。另一类工作与产品开发的特定阶段相联

25、系，这类工作称为活动或任务。 一个活动是一个大的工作单元，有它的开始时间和结束时间；它消耗资源，例如消耗计算机时间和人力；它产生工作产品， 例如预算、进度表、设计文档、源代码或用户手册。一项活动又包含一系列任务，一个任务是应该管理的最小工作单元。 因此，在项目管理中有三种工作，分别是项目职责、活动(大工作单元)和任务(小工作作单元)。项目管理将贯穿于整个项目开发的始终。 14.5 IEEE1058.1 软件项目管理计划标准 (续) 计划中的关键内容涉及工作产品的完成情况。工作产品预定完成的日期称为作产品预定完成的日期称为“里程碑”。 为了确定一件工作产品是否真正到达了一个里程为了确定一件工作产

26、品是否真正到达了一个里程碑，必须通过一系列由开发组成员、管理部门和客户代表进行的审查。一个典型的里程碑是完成概要设计并且通过了审查的日期。一旦一个工作产品经过审查并被一致通过，它就成为一个基线。只有经过12.3.2中描述的正式过程才能修改基线。 14.5 IEEE1058.1 软件项目管理计划标准 (续) 一个工作包不仅定义了工作产品，而且定义了人员需求、开发期限、资源、负责人姓名和验收该工作产品的标准 资金当然是软件项目计划的一个关键组成部分，必须拟定出详细的资金预算和资金分配方案。资金分配应该针对每个项目职责和活动，它是时间的函数 14.5 IEEE1058.1 软件项目管理计划标准 (续

27、) IEEEIEEE软件项目管理计划内容： 1引言 2项目组织 3 3管理过程 4技术过程 5工作包、进度和预算 6 6附加部分 14.5 IEEE1058.1 软件项目管理计划标准 (续) 1. 这部分由5个小部分组成，描述了要开发的项目和产品的概况。 (1) 简要地描述项目目标、要交付的产品、有关活动及其工作产品。此外，还要列出里程碑、所需的资源、主要的进度以及主要 (2) IEEE软件项目管理计划内容 (3) 没有什么计划能一成不变地执行。软件项目管理计划和其他计划一样，必须随着经验的积累以及客户方与开发方的变化而变 (4) (5) 这些信息确保每个人都能以同样方式理解软件项目管理计划。

28、 1. 引言 (续) 2. 这部分中的4个小部分，从软件过程的角度和开发者的组织结 (1) 根据活动(例如，产品设计或产品测试)和项目职责(例如，项目管理或配置管理)来确定过程模型。过程模型的关键内容有里 (2) 描述开发组织的管理结构。在组织中划定权限和明确责任是 (3) IEEE软件项目管理计划内容 （续） 没有一个项目是在真空中完成的，项目组成员必须与客户和本组织内的其他成员打交道。此外，在大型项目中还可能牵涉到转包商。必须制定出项目本身与其他实体之间在行政上和管理上的界线。在许多软件组织内部包含两种类型的组织：完成特定开发项目的开发组和起支持作用的支持组(例如配置管理组和SQA组)。如

29、果本项目有支持组介入，则项目组和支持组之间的行政、管理界线也必须清楚地定义。 (4) 针对每个项目职责(例如SQA) 和每项活动(例如产品测试)，必须明确地指定好个人的责任。 2. 项目组织 （续） 3. 这部分的5个小部分描述怎样对软件项目进行管理。 (1) 描述管理的原理、目标和优先级。本部分的内容可能包括提交报告的频率和机制、不同需求的相对优先关系、项目的进度和资金预算，以及风险管理过程。 (2) 假设、依赖性和约束 列出在规格说明文档及其他文档中包含的所有假设、依赖性 IEEE软件项目管理计划内容 （续） (3) 在本小节中列出项目中存在的多种风险因素和跟踪风险的机制。 (4) 详细地

30、描述项目报告机制，包括复查和审计机制。 (5) 项目中的有关人员是重要的资源。在这一小节中列出所需人员的 3. 3. 管理过程 （续） 4. 本部分包括3个小部分，指明该项目的技术方面。 (1) 详细地描述有关软件和硬件的技术方面，应该覆盖的内容包括：开发产品所用的计算机系统(硬件、操作系统和软件)，以及产品运行的目标系统。其他需要描述的内容有：所用的开发技术、测试技术、开发小组的结构、编程语言和CASE工具。此外，也应该包括技术标准，比如文档标准和编码标准，以及可能参考的其 IEEE软件项目管理计划内容 （续） (2) 描述文档需求，即文档编制标准、里程碑、基线 (3) 给出关于支持功能(例

31、如，配置管理和质量保证) 4. 4. 技术过程技术过程 5. 本部分包含5个小部分，着重描述工作包、它们之间的相互联系、 (1) 详细说明工作包，并把与之相关的工作产品分解为活动和任务。 (2) 模块编码是在设计之后，集成测试之前进行的。一般来说，工作包之间有相互依赖性，并且依赖于外部事件。这一小节着重说明依赖关 (3) 完成项目需要各种各样的资源，一般来说，应该把资源需求表示为 IEEE软件项目管理计划内容 （续） (4) (5) 对项目的各个部分都制定一个详细的进度表，然后确定主计 6. 对于特定的项目，可能需要在项目计划中再增加一些内容。根据IEEE结构框架，把这些附加的内容列在一个计划

32、的最后。附加的部分可能包括转包商管理计划、安全计划、测试计划、培训计划、硬件采购计划、安装计划和产品维护计划等。 5. 5. 14.6 ISO 9000质量标准 ISO 9000的基本思想主要体现在下述几个方面。 (1)质量并不是在产品检验中得到的，而是在生产的全过程中形成的。 ISO 9000-3阐述了供方和需方应该怎样进行有组织的质量管理活动，才能得到较为满意的软件产品；规定了从双方签订开发合同到设计、实现和维护的整个软件生命周期中应该实施的质量管理活动，但是，并没有规定具体的质量管理和质量检验的方法和步骤。 (2)为确保产品质量，ISO 9000要求“在生产的全过程中，影响产品质量的所有

33、因素都要始终处于受控状态”。 为使软件产品达到质量要求，ISO 9000-3ISO 9000-3要求软件开发机构建立质量管理体系。首先要求明确供需双方的职责，针对所有可能影响软件质量的因素，都要做出如何加强管理和控制的决定。 14.6 ISO 9000质量标准 （续） (3)可以用ISO 9000标准证实“企业具有持续地提供符合要求的产品的能力”。 如果产品质量能达到标准提出的要求，则可由不依赖于供、需双方的第三方权威机构对生产厂家审查认证后，出具合格证明。 14.6 ISO 9000质量标准 （续） (4) (4)还可以用ISO 9000ISO 9000标准来“持续地改进质量”。 实施ISO

34、9000标准是企业加强质量管理、提高产品质量的过程。通常，认证的有效期为半年，取得认证之后每年还需要接受1 12 2次定期检查，以保证该企业的质量管理体系持续地符合ISO9000标准，并促使企业不断地提高质量。 14.6 ISO 9000质量标准 （续） ISO 9000-3的全称是“质量管理和质量保证标准第三部分：在软件开发、供应和维护中的使用指南”。 ISO 9000-3是一个与软件生命周期相关的、对开发过程各阶段提供质量保证的质量管理体系，由质量管理体系框架、质量管理体系的生命周期活动、质量管理体系的支持活动等部分组成。标准中规定的各项质量活动都要求以文档作为各阶段活动的结果，文档在标准

35、中占有十分重要的地位，可以说ISO9000-3标准是文档驱动的。 14.6 ISO 9000质量标准 （续） 1 1、质量管理体系框架 在这部分中规定了供需双方的管理职责，并要求供方建立一个用文件规定的质量管理体系，该体系应该是一个贯穿于整个软件生命周期的综合过程，以便在软件开发过程中保证质量，而不是在开发过程结束时才发现质量问题。标准强调，应该防止发生质量问题，而不是在发生了质量问题之后依靠纠正措施来解决问题。标准中还包括，内部质量审核步骤和纠正措施等内容。 14.6 ISO 9000质量标准 （续） 2、质量管理体系的生命周期活动 通常，一个软件开发项目按照某种生命周期模型进行组织，并根据

36、所采用的生命周期模型的特点来计划和实施与质量保证有关的活动。这部分按照软件生命周期过程描述了有关的质量管理活动，其中包括合同评审、需方的需求规格说明、开发计划、质量管理计划、设计与实现、测试和确认、验收、复制/交付和安装、维护等。 14.6 ISO 9000质量标准 （续） 3 3、质量管理体系的支持活动 在标准中规定的支持活动有：配置管理；文档控制；度量；规则、惯例和约定；工具和技术；采购；配套的培训等活动。 14.6 ISO 9000质量标准 （续） 14.6 ISO/IEC12207软件生命周期过程标准 这是指导软件过程实施的一个标准，它从多个角度阐述了软件生命周期各个过程中的活动，对规

37、范软件开发过程，协调各类人员之间的关系，都具有指导作用。 本标准建立了一个最高层次的软件生命周期体系结构。生命周期从一个设想或需求开始，直至软件被废弃(退役)时终止。体系结构由一组相互关联的过程集组成，所有过程都遵守了两条基本原则：模块化和责任。所谓模块化是指，标准中规定的过程都是模块化的，它们具有较高内聚性和较低耦合性，通常一个具体的过程完成一个独立的功能。所谓责任是指，在软件生命周期中，一个过程的执行被认为是一个部门的责任，也就是说，项目中的每个部门都承担着某种责任。责任是在整个软件生命周期中进行质量管理的一条关键原则。 14.6 ISO/IEC12207软件生命周期过程标准 （续） 标准

38、中的过程被分成三大类：主要过程，支持过程和组织过程。 主要过程是生命周期中的原动力，它们是：获取、供应、开发、运行和维护。 支持过程包括：文档、配置管理、质量保证、验证、确认、联合评审、审计和问题解决。在其他过程中可以使用支持过程。 组织过程有：管理、基础设施、改进和培训。一个组织可以使用组织过程来建立、控制和改进生命周期过程。 14.6 ISO/IEC12207软件生命周期过程标准 （续） 标准中的一个过程被进一步细化为一系列活动，而每个活动则被分解为一系列任务，任务是基本的原子行为。 14.6 ISO/IEC12207软件生命周期过程标准 （续） 1 1、主要过程 标准中描述了一个主要过程

39、集，它们为完成软件获取、供应、开发、运行和维护等任务的部门服务。 (1)获取过程：在这个过程中，标准定义了获取方通过合同的形式获取软件产品或服务时，应该完成的活动及任务。 (2)供应过程：这个过程包括了软件供应方应完成的活动和任务。 14.6 ISO/IEC12207软件生命周期过程标准 （续） (3)开发过程：在这个过程中定义了软件开发者应该完成的活动和任务，它是包含内容最多的一个过程。开发过程既可以用于开发一个新软件，也可以用于修改已有的软件。 开发过程由过程实现、系统需求分析、系统体系结构设计、软件需求分析、软件体系结构设计、软件详细设计、软件编码和测试、软件集成、软件质量测试、系统集成

40、、系统质量测试、软件安装以及软件验收等活动组成。 (4)运行过程：这个过程规定了软件系统的运行者应该完成的活动和任务。 (5)维护过程：维护过程包括了软件维护者应该完成的活动和任务。 1 1、主要过程 （续） 2 2、支持过程、支持过程 本标准定义了8 8个支持过程。一个支持过程可以被获取、供应、开发、运行和维护等主要过程调用，也可以被其他支持过程调用，以保证项目成功和项目质量提高。 (1)文档过程 (2)配置管理过程 (3)质量保证过程 (4)验证过程 (5)确认过程 (6)联合评审过程 (7)审计过程 (8)问题解决过程 14.6 ISO/IEC12207软件生命周期过程标准 （续） 3

41、3、组织过程 本标准包括4个组织过程。一个组织可以使用组织过程来实施组织内的、合作的、位于项目之上的或跨项目的功能。一个组织过程也可以支持其他过程，这些组织过程用于帮助创建、控制和改进其他过程。 (1)管理过程 (2)基础设施过程 (3)改进过程 (4)培训过程 14.6 ISO/IEC12207软件生命周期过程标准 （续） 14.8 ISO/IECTR15504软件过程评估标准 ISO/IECTR15504为软件过程评估提供了一个框架，并为实施评估以确保各种级别的一致性和可重复性提出了一个最小需求。该需求有助于保持评估结果前后一致，并提供证据证明其级别、验证与需求相符。 过程评估活动可以在过

42、程改进活动中执行，也可以作为能力确定过程的一部分执行。 ISO/IECTR15504标准具有两维结构：一个是过程维，另一个是能力维。 1、过程维 过程维是评估的基础。在ISO/IECTR15504-2中描述的各个软件过程如下。 (1)客户-供应者(Customer-Supplier)过程：这类过程有获取、供应、需求导出和操作等4个过程。 (2)工程(Engineering)过程：这类过程包括开发、系统与软件维护等2个过程。 (3)支持(Support)过程：这类过程包括文档、配置管理、质量保证、验证、确认、联合复审、审计和问题解决等8个过程。 (4)管理(Management)过程：这类过程有

43、管理、项目管理、质量管理和风险管理等4个过程。 (5)组织(Organization)过程：这类过程包括组织调整、改进、人力资源管理、基础设施、测量和重用等6个过程。 14.8 ISO/IECTR15504软件过程评估标准 (续) 2、能力维 在标准的第2部分所定义的能力等级，是一组过程和管理的属性，它们作为一个整体为软件供应者提供了改进过程实施能力的建议。每个等级都提供改进过程实施能力的建议，各个级别都制定了改进过程能力的合理的方法。 在参考模型中定义了6个能力级别，下面按从低到高的顺序介绍这6个级别的特点。 14.8 ISO/IECTR15504软件过程评估标准 (续) (1)第0级不完全

44、级：过程不完整，而且一片混乱。 (2)第1级可实施级：过程是依据直觉来实施的，有一定的工作产品。 (3)第2级有管理级：责任明确，过程和过程的中间产品可管理。 (4)第3级可创建级：可以为不同目的定制预定义的过程，过程资源可管理。 (5)第4级可预测级：各种度量使得过程的实施及实施结果可控制。 (6)第5级优化级：用于过程改进的定量度量。 在本标准中融合进了与下节将介绍的能力成熟度模型(CMM)类似的能力等级。用户可以通过不断提高能力等级的方法，提高自己的软件过程能力。 2 2、能力维 （续） 14.9 能力成熟度模型 能力成熟度模型的基本思想是，因为问题是由我们管理软件过程的方法不当引起的，

45、所以新软件技术的运用并不会自动提高生产率和软件质量。 能力成熟度模型有助于软件开发组织建立一个有规律的、成熟的软件过程。改进后的过程将开发出质量更好的软件，使更多的软件项目免受时间和费用超支之苦。 软件过程包括各种活动、技术和工具，因此，它实际上既包括了软件生产的技术方面又包括了管理方面。 CMM策略力图改进软件过程的管理，而在技术方面的改进是其必然的结果。 必须记住，对软件过程的改进不可能在一夜之间完成，CMM是以增量方式逐步引入变化的。CMM明确地定义了5个不同的成熟度等级，一个软件开发组织可用一系列小的改良性步骤向更高的成熟度等级迈进。 14.9 能力成熟度模型 （续） 能力成熟度模型包

46、括以下的组成成分。 (1)成熟度等级(Maturity Levels)：一个成熟度等级 是在朝着实现成熟软件过程进化途中的一个妥善定义的平台。五个成熟度等级构成了CMM的顶层结构。 (2)过程能力(Process Capability)：软件过程能力描述，通过遵循软件过程能实现预期结果的程度。一个组织的软件过程能力提供一种“预测该组织承担下一个软件项目时，预期最可能得到的结果”的方法。 14.9 能力成熟度模型 （续） (3)关键过程域(Key Process Areas，KPA)：每个成熟度等级由若干关键过程域组成。 每个关键过程域都标识出一串相关的活动，对比这些活动都完成时所达到的一组目标

47、，对建立该过程成熟度等级是至关重要的。关键过程域分别定义在各个成熟度等级之中，并与之关联在一起。 例如，等级2的一个关键过程域是软件项目计划。 14.9 能力成熟度模型 （续） (4)目标(Goals)：目标概括了关键过程域中的关键实践，并可用于确定一个组织或项目是否已有效地实施了该关键过程域。目标表示每个关键过程域的范围、边界和意图， 例如，关键过程域“软件项目计划”的一个目标是，“软件估算已经文档化，供计划和跟踪软件项目使用。” 14.9 能力成熟度模型 （续） (5)公共特性(Common Features)：CMM把关键实践分别归入别归入下列五个公共特性之中：执行约定、执行能力、之中：

48、执行约定、执行能力、执行的活动、测量和分析以及验证实施。执行的活动、测量和分析以及验证实施。 公共特性是一种属性，它能指示一个关键过程域的实施和规范化是否是有效的、可重复的和持久的。实施和规范化是否是有效的、可重复的和持久的。 14.9 能力成熟度模型 （续） (6)关键实践(Key Practices)：每个关键过程域都用若干关键实践描述，实施关键实践有助于实现相应的关键过程域的目标。 关键实践描述对关键过程域的有效实施和规范化贡献最大的基础设施和活动。 例如，在关键过程域“软件项目计划”中，一个关键实践是“按照已文档化的规程制定项目的软件开发计划”。 14.9 能力成熟度模型 （续） 图1

49、3.4(右图)描绘了CMM的结构。 CMM通过定义能力成熟度的五个等级，引导软件开发组织不断识别出其软件过程的缺陷，并指出应该做哪些改进，但是，它并不提供做这些改进的具体措施。 能力成熟度的五个等级从低到高是：初始级、可重复级、已定义级、已管理级和优化级。 14.9 能力成熟度模型 （续） (1)初始级 软件过程的特征是无序的，有时甚至是混乱的。几乎没有什么过程是经过定义的，项目能否成功完全取决于个人能力。 (2)可重复级 建立了基本的项目管理过程，以追踪成本、进度和功能性。必要的过程规范已经建立起来了，使得可以重复以前类似项目所取得的成功。 关键过程域如下： ? 软件配置管理 ? 软件质量保

50、证 ? 软件子合同管理 ? 软件项目跟踪和监督 ? 软件项目计划 ? 需求管理 能力成熟度的五个等级 (续) (3)已定义级 用于管理和工程活动的软件过程已经文档化和标准化，并且已经集成到整个组织的软件过程中。所有项目都使用文档化的、组织批准的过程来开发和维护软件。这一级包含了第2级的所有特征。 关键过程域如下： ? 同事复审 ? 组间协作 ? 软件产品工程 ? 集成的软件管理 ? 培训计划 ? 组织过程定义 ? 组织过程焦点 能力成熟度的五个等级 (续) (4)已管理级 已收集了软件过程和产品质量的详细度量数据，使用这些详细的度量数据，能够定量地理解和控制软件过程和产品。这一级包含了第3级的