CMM与软件产品规范

1、软件能力成熟度模型CMM与软件产品规范欧增桂切实可行的标准计算机软件开发商在其开发的产品过程中，为了保证：验证质量管理体系是否持续满足要求和有效运行及时发现问题并采取纠正和预防措施需要一种切实可行的标准来对细节进行严格的控制与把握。过程目标降低软件开发的风险，降低灾难性的错误的发生率。缩短开发时间，减少软件开发的人力物力成本。不断改进和完善其质量管理体系，推动企业的可持续发展，提高企业的竞争力。 引入CMM标准目前，国内的软件开发商为了发展的需要，纷纷在研发过程中引入CMM标准，并通过了该标准的不同级别的评估认证。CMM（软件能力成熟度模型）是CMU-SEI（美国卡内基梅隆大学软件工程研究所）

2、制订的一个软件能力评估体系。根据这一模型对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化，使企业能够更好的实现其商业目标。 CMM模型目前CMM模型已经成为国际上最流行的、最实用的软件生产过程和软件开发能力的评估标准，并且得到了大多数国家软件产业界的认可，成为当今企业从事规模软件生产不可缺少的一项内容，被誉为进入国际软件市场的通行证。 一、CMM软件能力成熟度模型简介 （1）CMM概述 CMM是Capability Maturity Model for Software的简称，中文译为“软件能力成熟度模型”。 CMM的核心是把软件开发视为一个过程，并对组织软件产品过程的能力进行描述

3、。它侧重于软件开发过程的管理及软件工程能力的改进与评估。 CMM可用于： 软件过程改进：组织策划、设计和实施对其软件过程的更改； 软件过程评估：经培训的软件专业人员组确定组织当前软件过程的状态、确定组织所面临的具有高优先级的软件过程，并获得组织上对软件过程改进的支持；软件能力评价：经培训的软件专业人员鉴别合格的能完成软件工作的承包商或监控现有软件工作中所用软件过程的状态CMM评估的目的是帮助软件企业对软件工程过程进行管理和改进，增强开发与改进能力，从而能按时地、不超预算地开发出高质量的软件。全面质量管理CMM关注的软件生产有如下特点：质量问题是第一位的、规模较大的软件项目。由此引入了“全面质量

4、管理”的思想，尤其侧重“全面质量管理”中的“过程方法”，引入了“统计过程控制”的概念，将这两个方面作为CMM的基础。CMM的发展过程1984年美国国防部为降低采购风险，委托CMU-SEI制定了软件过程改进、评估模型，也称为SEI SW-CMM。从1987年推出SWCMM框架开始，1991年推出CMM 1.0 版，1993年推出CMM 1.1 版，2000年推出CMMI-SE/SW 1.0版2004年，SEI公布了最新的CMMI标准，并宣布与2005年底开始实施。 评估标准如果我们考证一下历史的沿革，应当更加容易理解CMM的本质。CMM首先是作为一个“评估标准”出现的初期的主要评估对象是美国国防

5、部供应商的保证质量的能力。 中国软件行业我国也于2001年4月发布了SJ/T 11234-2001 软件过程能力评估模型和SJ/T 11235-2001 软件能力成熟度模型，希望通过这两个标准促进中国软件行业的发展。并采取了一系列措施，鼓励软件出口型企业通过ISO9001质量保证体系认证和CMM认证。 （2）CMM的能力成熟度级别与关键过程域KPA CMM吸取了质量工程的主要原理，形成了5级模型。提出了由第一级（低级）向第五级（高级）逐级发展的模式。模型的等级从低到高，可以预计的企业的开发风险越来越低，开发能力越来越高。 构成过程成熟度基础的基本概念 一个过程是“某物生产的操作体系能导致结束或

6、得到结果的一系列的活动、变更、或操作。”IEEE定义过程为“为实现给定目标所执行的一序列的步骤”IEEE-STD-610。一个软件过程可以定义为，人们用以开发和维护软件及其相关产品（例如，项目计划、设计文档、代码、测试用例、用户手册等等）的一组活动、方法、实践和变换。 构成过程成熟度基础的基本概念软件过程能力描述通过遵循软件过程能够实现预期结果的程度。一个组织的软件过程能力提供一种预测该组织承担下一个软件项目时最可能的预期结果的方法。软件过程成熟度软件过程成熟度是一个特定过程被明确地定义、管理、测量、控制、并且是有效的程度成熟度意味着能力上的增长潜力，并且表明一个组织软件过程的丰富性和在遍及组

7、织的项目中运用它时的一致性。 关键过程域模型的每个等级由不同的关键过程域（Key Process Area）构成每个关键过程域又由若干个目标构成每个目标由各种执行约定和执行能力支持，并提出了对目标的测量和分析的内容以及验证实施的内容。Structure of the CMMMaturity LevelsKey Process AreasGoalsKey PracticesActivityCommitmentAbilityMeasurementVerificationCMM的模型级别划分如下：CMM 1初始级CMM 2可重复级，有6个关键过程域CMM 3已定义级，有7个关键过程域CMM 4定量管

8、理级，有2个关键过程域CMM 5持续优化级，有3个关键过程域 CMM Structure423515 Maturity LevelsAcAcAcAcAcCoAbMeVe316 Key PracticesG1G2G352 Goals & Institutionalization of 18 KPAsiiRMSPPSPTOSSMSQASCMOPFOPDTPISMSPEICPRQPMSQMDPTCMPCM18 Key Process Areas五个成熟度等级的行为特征1) 初始级软件过程的特点是无秩序的，偶尔甚至是混乱的。几乎没有什么过程是经过定义的，成功依赖于个人的努力。五个成熟度等级的行为特征2

9、) 可重复级用已建立基本的项目管理过程去跟踪成本、进度和功能性。必要的过程纪律已经就位，使具有类似应用的项目，能重复以前的成功。五个成熟度等级的行为特征3) 已定义级管理活动和工程活动两方面的软件过程均已文档化、标准化、并集成到组织的标准软件过程。全部项目均采用供开发和维护软件用的组织标准软件过程的一个经批准的剪裁版本。五个成熟度等级的行为特征4) 已管理级已采集详细的有关软件过程和产品质量的度量。无论软件过程还是产品均得到定量了解和控制。五个成熟度等级的行为特征5) 优化级利用来自过程和来自新思想、新技术的先导性试验的定量反馈信息，使持续过程改进成为可能。CMM 2可重复级的KPA软件需求管

10、理RM软件项目策划PP项目跟踪和监督PTO软件子合同管理SSM软件质量保证SQA软件配置管理SCM CMM 3 已定义级的KPA组织过程焦点OPF组织过程定义OPD组织培训大纲TP集成软件管理ISM软件产品工程SPE组间协调IC同行评审PR CMM 4 可管理级的KPA量化过程管理（QPM）软件质量管理（SQM） CMM 5 优化级的KPA过程变更管理PCM技术更新管理TCM缺陷预防DP图 3.1 CMM 结构成熟度等级过程能力目标关键过程域共同特点实施或规范化关键实践基础设施或活动阐述描述包含到达按组织指示包含目标和关键实践活动每个关键过程区域都有一个或多个目标Goals和多个关键实践Key

11、 Practice活动。各关键实践活动分别归属于五个不同的公共属性小组，它们分别是： 五个不同的公共属性小组执行约定CO，Commitment to Perform执行能力AB，Ability to Perform执行的活动AC，Activities Performed测量分析ME，Measurement and Analysis验证VE，Verifying Implementa tion4.1 解释关键实践制定关键实践的意图不是要求或者主张某个具体的软件生存周期模型，某种具体的组织机构、某种具体的职责划分或某种具体的用于开发的管理和技术方法，而是给出对有效软件过程的基本元素的描述。用关键实践

12、来传达基本原理，它们能适用于种类广泛的项目和组织，对许多典型的软件应用都正确，且随着时间的推移仍然有效。4.1 解释关键实践虽然关键实践不依靠任何具体的实施，但在叙述关键实践时必须一致地使用特定的术语和例子以提高文字的清晰度。描述CMM中对角色、职责、关系、产品和活动所用的约定术语。使用关键实践的组织应该了解这些约定术语，并在自己的组织、项目和经营环境中恰当地说明它们。4.2 解释共同特点在关键实践的每个共同特点中，为了在关键过程区域之间提供连续性和一致性，采用某些短语和约定术语。下面描述组织机构方面的主要的约定术语，按共同特点排列。 4.2.1 执行约定 方针陈述（Policy statem

13、ent） 当采用方针陈述时，它们一般指的是项目遵循书面的、用于那个关键过程区域的实践的组织上的方针。这是为了强调在组织上的约定和实际正进行工作的项目之间的连结。执行约定 方针陈述的子实践通常概述以后将被包括在关键过程区域中并特别适合于通过书面方针加以规范化的活动。在某些关键过程区域（例如组织过程焦点）中，关键过程区域的活动的焦点是组织，而不是项目。这种情况下方针陈述要改写，并且指的是组织遵循书面方针。执行约定 领导（Leadership） 在某些关键过程区域，执行约定约定包含一个阐述任命一个领导角色（例如项目软件经理）的语句，或者一个描述特别资助活动的语句，这些是成功地规范化该关键过程区域所必

14、须的。4.2.2 执行能力资源和投资（Resources and fundin ） 大多数关键过程区域包含一个反映关键过程区域的活动对适当的资源和投资要求的关键实践。由子实践描述的资源及投资一般分成三类： 能利用的特别的技能、足够的投资和能利用的工具，作为例子，列出在执行关键过程区域活动中可能利用的工具。 执行能力培训（training）培训大纲这个关键过程区域描述与这些培训办法有关的具体实践。在等级2使用短语“接受培训”，在等级3以上使用短语“接受所要求的培训”。定向培训（orientation） 在某些关键过程区域，能找到描述定向培训的关键实践。执行能力先决条款（Prerequisite

15、Items） 某些关键过程区域包括描述要求先决条款的关键实践；例如，软件开发计划是软件项目跟踪和监督的先决条款。在某些情况下，这些先决条款可能为另一个关键过程区域活动的输出。在另一些情况下，它们是预期能从软件项目范围之外获得的条款（例如，分配给软件的系统需求是需求管理的先决条款）。4.2.3 执行的活动在所有的共同特点中，执行的活动显示出最多的结构可变性，因为关键过程区域的实施活动在细节层次上、组织方面的焦点（例如，项目或组织）上，和对策划及文档化的要求上各不相同。下面突出阐述某些一般的概念。执行的活动计划的类型 （Types of plans） 在关键实践中所描述的两个主要的类型是：正式计划

16、（例如：软件开发计划、软件质量保证计划和软件配置管理计划）及非正式计划（例如同行评审计划、风险管理计划和技术管理计划）。执行的活动非正式计划一般编写为正式计划的一部分（例如，同行评审计划可以作为软件开发计划的一部分）或者作为正式计划的附件（例如，同行评审进度表可以是软件开发计划中的一节）。执行的活动正式计划（Formal plans） 通常有两个关键实践专门描述策划活动：一、要求按照已文档化的规程制定和修改计划。二、要求关键过程区域的活动基于计划。涉及已文档化的规程的子实践的内容包括：计划的输入所必须有的内容和为了获得计划所要求的约定和支持预计需采取的步骤。执行的活动非正式计划（Informa

17、l plans） 通常非正式计划由单个关键实践描述。其子实践包括有关计划内容的信息和用于制定或修定计划的规程。按照文档化的规程（According to a documented Procedure） 文档化规程的形式和细节层次可能变化很大，从手写的个人的桌面规程到正式的组织的标准操作规程。执行的活动分配给软件的系统需求（System require- ments allocated to software）在CMM中分配给软件的系统需求通常称为“分配需求”，它是系统需求中将用系统的软件成分实现的子集。分配需求是软件开发计划的主要输入。执行的活动将系统需求分配给硬件、软件等是整个系统设计的一部

18、分，一般由系统工程组完成“分配需求”，既包括技术需求（功能性、性能等等），也包括非技术需求（交付日期、成本等等）。顾客供应商关系（Customer-Supplier relationship） 顾客可以是组织内部的、也可以是组织外部的。执行的活动按管理要求进行跟踪和采取纠正措施(Tracking and Taking corrective action versus managing)等级2在软件项目跟踪和监督关键过程区域中的许多关键实践采用短语“跟踪，必要时采取纠正措施。” 在等级3的集成软件管理中的许多类似的关键实践采用短语“进行管理”。在等级3上项目有一个完全定义的软件过程。执行的活动经

19、过评审和经过同行评审的比较(Reviewed versus undergoes peer reviews) 在评审中，将一个软件工作产品或一组工作产品提交给经理、顾客、最终用户、或其它有兴趣的个人，以得到他们的评论或批准。评审一般出现在作业结束时。在同等评审中，将一个软件工作产品或一组工作产品提交给生产者的同事们以识别出缺陷。同行评审是作业过程中不可缺少的部分。执行的活动置于配置管理之下与进行管理和控制相比较（Placed under configuration management versus managed and controlled） 某些软件工作产品，例如软件设计和代码，应在预先确

20、定的点上建立基线这些基线经过正式评审和认同，作为进一步开发工作的基础。对已基线化的配置项施加严格的更改控制过程。执行的活动在与顾客打交道时，这些基线提供控制和稳定性。有时称此为基线配置管理。短语“置于配置管理之下”用于此类软件工作产品。当配置控制由开发者实施时，通常称之为开发配置管理。在预先确定的开发中的某些点上，开发配置管理下的某些项可置于基线配置管理之下。执行的活动某些软件工作产品，例如估计或软件开发计划，不是基线的一部分，因此不用置于配置管理之下，但它们必须受控以使得项目按一种有纪律的方式进行工作。短语“进行管理和控制”用于对标识和定义这种软件工作产品的过程进行特征描述。在给定时间（过去

21、或现在）使用的工作产品的版本是已知的（即版本控制），并且更改以一种受控的方式引入（即更改控制）。4.2.4 测量和分析测量和分析中的关键实践描述基本的测量实践，对确定与关键实践的执行的活动这一共同特点有关的状态来说，这些测量实践是必不可少的。有些测量是关键过程区域中活动的固有部分，这些测量则被列在执行的活动这一共同特点之下。所建议的测量例子都表示为补充信息，因为项目环境的可变性可以导致不同的测量。 4.2.5 验证实施验证实施这个共同特点一般包含与高级管理者和项目管理者的监督有关的关键实践，以及某些专门的验证活动，后者预期由质量保证组成其它组执行，以证实关键实践正在恰当地进行。验证实施高级管理

22、者的定期监督 (Senior management oversight on a periodic basis) 高级管理者作定期评审的主要目的是在合适的抽象层次上和以及时的方式了解和洞察软件过程活动。评审间隔应满足组织的需要，只要已存在有报告例外情况的合适机制，间隔可以长。验证实施项目管理者既定期地也事件驱动地监督project management oversight on both a periodic and eventdriven basis项目管理者应保持对软件工作状态的不断了解，并在软件项目出现重大事件时收到报告例如，项目管理者参加诸如关键设计评审那样的正式评审，和围绕过程问题的

23、评审。例如，有关过程改进规划的状态和过程不符合问题的解决等的评审。验证实施软件质量保证活动（Software quality assurance activities） 用一个关键实践描述那些据信适宜于软件质量保证（SQA）组作评审和（或）审计的特定活动。但存在一些特殊情况，在那里SQA验证活动未被描述，例如在培训大纲和组间协调关键过程区域中。（3）CMM的评估目前针对CMM开发出许多的评估方法，其中公认评估方法有两个：一是用于内部过程改进的CMM评估称为CBA-IPI二是用于选择和监控分承包方的CMM评估，称为SCE方法。这两种方法基于不同的目的，但评估的结果应一致。 CBA-IPI评估包括

24、三个阶段：准备阶段、现场阶段和报告阶段。现场阶段采用问卷调查的方式，按照各个KPA所规定的内容，直接向参与软件开发的各部分人员提问，并根据回答问题的情况，审查各阶段的文档，形成评价。最后汇总成评估报告。 二、软件产品的规范与模板 （1）软件产品的规范CMMI提供了19个关键过程域的过程规范规范中给出了在软件产品过程中，各个KPA所必须进行的活动以及活动的内容、要求和规程。规范并不是某一个具体的项目的软件产品，但是要求按照规范生产软件产品文档。 （2）软件产品的模板CMMI在提供过程规范的同时，还提供了60个相对应的软件产品文档模板。模板与规范是相对应的，模板的名字就是规范中规定的该过程应输出的

25、文档。 关键过程域的规范及文档模板1.立项管理过程规范 立项调查报告 立项建议书 立项可行性分析报告 立项评审报告 结项、项目规划2. 结项管理过程规范 结项申请书 结项评审报告 3.项目规划过程规范 项目估计表 项目计划 项目计划变更控制报告 需求管理、需求开发6. 需求管理过程规范 需求变更控制报告 需求跟踪报告7.需求开发过程规范 产品需求规格说明书 用户需求说明书 技术预研、系统设计8. 技术预研过程规范 XXX技术预研计划 XXX技术预研报告 9.系统设计过程规范 体系结构设计报告 模块设计报告 数据库设计报告 用户界面设计报告 实现与测试、系统测试10. 实现与测试过程规范 实现与

26、测试计划 XXX编程文档 11.系统测试过程规范 系统测试计划 测试报告标题 测试用例标题 Beta测试、客户验收12. Beta测试过程规范 Beta测试协议 Beta测试报告13.客户验收过程规范 客户验收计划 客户验收报告 技术评审、配置管理14. 技术评审过程规范 技术评审计划 技术评审检查表 XXX技术评审通知 XXX技术评审报告15.配置管理过程规范 配置管理计划 配置库管理报告 配置项变更控制报告 质量保证16. 质量保证过程规范 质量保证计划 质量保证计划检查表 质量问题跟踪表 第N份质量保证报告 外包与采购17. 外包与采购管理过程规范采购合同采购竞标邀请书 采购物品验收报告

27、供应商评估报告承包商评估报告外包开发合同外包开发竞标邀请书外包开发监控报告外包开发成果验收报告 培训、服务与维护18. 培训管理过程规范 培训计划 培训通知 培训评估报告19.服务与维护过程规范 客户服务计划 客户服务报告 产品维护计划 产品维护报告 CMMI与软件质量管理SQA （1）对软件产品过程的认识我们都知道一个项目的主要内容是：成本、进度、质量；良好的项目管理就是综合三方面的因素，平衡三方面的目标，最终依照目标完成任务。 SQA而影响软件项目进度、成本、质量的因素主要是“人、过程、技术”。项目的三个方面和三个因素是相互制约和影响的，对这些方面的平衡策略成为一个企业级的要求，决定了企业

28、的行为。所以质量保证的SQA工作也应当立足于企业的战略目标，形成对SQA的理论认识。 过程质量与产品质量过程质量与产品质量存在某种程度的因果关系，通常“好的过程”产生“好的产品”，而“差的过程”将产生“差的产品”。人们销售的是产品而不是过程，用户关心的是最终产品的质量，而开发者既要关心过程质量又要关心产品质量。 （2）由SQA保证软件产品过程如果将一个软件生产类比于一个工厂的生产。那么生产线就是过程，产品按照生产线的规定过程进行生产。SQA的职责就是保证过程的执行，也就是保证生产线的正常执行。 SEPG、QC、QA人员SEPG、QC、QA人员的基本职责如下：SEPG：制定过程，实施过程改进；Q

29、C：检验产品的质量，保证产品符合客户的需求；是产品质量检查者；QA：审计过程的质量，保证过程被正确执行；是过程质量审计者。 （3）SQA和其它CMM的KPASQA工作往往和其它工作组合在一起，这样就与其它的KPA有着不可分割的关系。按照工作重点不同来分，基本有三种SQA：过程改进型、配置管理型、测试型。 过程改进型应用CMM的KPA指导软件产品过程，并对这一过程进行改进，利用规范和模板产生高质量的软件产品。即通过完善过程质量提高软件产品质量。 Beta测试Beta测试：是指在产品正式销售之前，开发方将产品交付给一些潜在的客户免费试用，请他们对产品进行测试，并获取他们对产品的建议。 配置管理3. 配置管理：项目研发和管理过程中会产生多种工作成果，例如文档、程序和数据等，应当将这些文件分门别类、有条理地被保存起来，以便查阅和修改。当然这种保存不应该仅仅是保存在计算机里。 配置项凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item, CI）配置项主要有两大类：属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。项目管理和机构支撑过程域产