CMMI体系文件-OPD-标准软件过程裁剪指南

****信息系统有限公司

标准软件过程裁剪指南

文件编号：版本号：

编制：日期：

审核：日期：

批准：日期：

****信息系统有限公司

标准软件过程裁剪指南

文件编号：版本号：

编制：日期：

审核：日期：

批准：日期：

文件修订记录

目录

1目的 (1)

2适用范围 (1)

3资源和工具 (1)

4定义和缩写 (1)

5职责 (1)

6指南 (2)

6.1启动条件 (2)

6.2输入 (2)

6.3活动 (2)

6.3.1确定项目特点 (2)

6.3.2裁剪要求 (2)

6.3.2.1裁剪对象 (3)

6.3.2.2裁剪原则 (3)

6.3.2.3裁剪产物 (3)

6.3.3软件生命周期的裁剪指导 (3)

6.3.4过程裁剪指导 (4)

6.3.4.1概要裁剪 (4)

6.3.4.2详细裁剪 (4)

6.3.4.2.1需求开发与需求管理 (4)

6.3.4.2.2技术解决过程 (4)

6.3.4.2.3验证 (5)

6.3.4.2.3.1测试 (5)

6.3.4.2.3.2评审 (5)

6.3.4.2.4项目计划 (5)

6.3.4.2.5项目监控 (5)

6.3.4.2.6配置管理 (5)

6.3.4.2.7过程与产品质量保证 (6)

6.3.4.2.8度量与分析 (6)

6.3.4.2.9组织培训 (6)

6.3.5使用该裁剪范围以外的裁剪方法 (6)

6.3.6填写裁剪报告 (6)

6.3.7裁剪过程的收集和推广 (6)

6.4输出 (7)

6.5关闭标准 (7)

7审核 (7)

8度量 (7)

9培训 (7)

1 目的

本文件的目的是提供公司标准软件过程的裁剪方法，指导项目经理和QA根据项目特征，对公司的标准软件过程进行裁剪，制定项目的开发过程。

2 适用范围

本过程适用于公司的所有软件开发项目。

3 资源和工具

引用模型和标准：

Capability Maturity Model? Integration (CMMI SM), Version 1.1

GB 1526-89 《信息处理数据流程图、程序流程图、系统流程图、程序网络图和系统资源图的文件编制符号及约定》

工具：

Microsoft Word

Microsoft Excel

Microsoft Visio

Microsoft Visual SourceSafe

4 定义和缩写

表1定义和缩写表

5 职责

表2 角色职责表

6 指南

6.1 启动条件

《用户需求说明书》审批通过。

6.2 输入

无

6.3 活动

6.3.1确定项目特点

先根据项目规模、项目复杂度、项目关键性、项目组经验、需求明确性对项目进行分类。

6.3.2裁剪要求

下面给出了裁剪的具体要求，在项目进行裁剪时，必须首先认真阅读裁剪要求，之后才能进行裁剪报告的填写。

这里介绍一下豁免，豁免是指在组织允许的情况下，可以不执行组织级或项目级的必要任务，跳过整个过程或活动的一种特殊裁剪方式，对这种特殊裁剪称为豁免。

6.3.2.1 裁剪对象

裁剪对象是组织标准软件过程中的工程过程以及部分管理过程，裁剪一般包括过程的裁剪和工作产品裁剪。

6.3.2.2 裁剪原则

●应根据项目特点进行过程裁剪；

●裁剪不仅是减少过程，也可以根据质量或其它要求添加过程，以及对过

程进行修改，使其更符合项目的特点；

●项目经理和QA可以根据实际情况的需要，采用本指南中规定的裁剪方

法之外的方法对项目过程进行裁剪，但所采用的裁剪方法必须经EPG

同意。

6.3.2.3 裁剪产物

项目经理和QA根据项目特点，对标准组织过程进行裁剪，其裁剪结果就是项目实施的过程，作为项目计划的一部分进行评审。

工作产品的裁剪请参照《工作产品汇总表》中的裁剪说明，过程内容裁剪参看下面说明。

6.3.3软件生命周期的裁剪指导

每种软件生命周期都有其优点、缺点和其适于的项目环境。在裁剪中也应该考虑项目所选的软件生命周期模型的特点，进行合理裁剪。

当前只提供了一种软件生命周期供选择，即瀑布模型。此模型包括5个阶段：定义、设计、实现、测试、发布；包括7个里程碑：需求定义、需求分析、概要设计、详细设计、系统集成、系统测试、项目确认。

6.3.4过程裁剪指导

6.3.4.1 概要裁剪

6.3.4.2 详细裁剪

对应各个开发阶段，对过程中的活动依照以下要求进行裁剪，如果有些情况未被提及，则原过程的活动不应该被裁剪。

6.3.4.2.1需求开发与需求管理

该过程对需求明确性最为敏感，其次是项目规模。

6.3.4.2.2技术解决过程

6.3.4.2.3验证

6.3.4.2.3.1 测试

6.3.4.2.3.2 评审

6.3.4.2.4项目计划

6.3.4.2.5项目监控

6.3.4.2.6配置管理

6.3.4.2.7过程与产品质量保证

6.3.4.2.8度量与分析

6.3.4.2.9组织培训

6.3.5使用该裁剪范围以外的裁剪方法

若出现项目经理和QA必须使用该裁剪指南指定的裁剪方法以外的方法对项目过程进行裁剪，那项目经理和QA必须在裁剪时及时与EPG沟通，并获得EPG 的同意，并在项目计划评审时进行评审。

该裁剪方法将在项目结束时进行评估，可以作为裁剪过程的补充，并由EPG 决定是否将此裁剪方法记录进入本指南。

6.3.6填写裁剪报告

QA指导和协助项目经理进行过程裁剪。项目经理根据《裁剪报告》模板，填写裁剪内容。《裁剪报告》应由质量管理部经理审批。

6.3.7裁剪过程的收集和推广

《裁剪报告》应被纳入项目的配置库。裁剪过程同时应被收集在组织过程财

富库中。

项目应对裁剪内容进行跟踪，在项目结束时应分析本次裁剪是否对项目造成了影响，影响有哪些方面。组织应对裁剪过程进行深入分析，检查是否应将裁剪内容加入标准软件过程。

6.4 输出

《裁剪报告》

组织过程财富库

6.5 关闭标准

《裁剪报告》通过审批。

7 审核

《裁剪报告》应由质量管理部经理审批。

8 度量

裁剪活动的工作量

9 培训

对项目经理和QA进行关于标准软件过程裁剪的培训。

cmmi软件生产过程标准

何谓CMM? CMM是由美国卡内基-梅隆大学的软件工程研究所(SEI)推出的评估软件能力与成熟度的一套模型。它侧重于软件过程开发的管理及软件工程能力的改进与评估，是目前国际上最流行、比较实用的一种软件生产过程标准，成为当今企业从事规模软件生产不可缺少的一项内容。CMM模型共分为五个级别：初始级、可重复级、定义级、管理级和优化级。 软件工程：什么是CMMI? CMMI全称是Capability Maturity Model Integration, 即软件能力成熟度模型集成模型，是由美国国防部与卡内基-梅隆大学和美国国防工业协会共同开发和研制的。CMMI是一套融合多学科的、可扩充的产品集合，其研制的初步动机是为了利用两个或多个单一学科的模型实现一个组织的集成化过程改进 CMMI分为五个等级，二十五个过程区域（PA）（如图所示）。 1．初始级软件过程是无序的，有时甚至是混乱的，对过程几乎没有定义，成功取决于个人努力。管理是反应式的。 2．已管理级建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的成功经验。 3．已定义级已将软件管理和工程两方面的过程文档化、标准化，并综合成该组织的标准软件过程。所有项目均使用经批准、剪裁的标准软件过程来开发和维护软件，软件产品的生产在整个软件过程是可见的。 4．量化管理级分析对软件过程和产品质量的详细度量数据，对软件过程和产品都有定量的理解与控制。管理有一个作出结论的客观依据，管理能够在定量的范围内预测性能。5．优化管理级过程的量化反馈和先进的新思想、新技术促使过程持续不断改进。 每个等级都被分解为过程域，特殊目标和特殊实践，通用目标、通用实践和共同特性： 每个等级都有几个过程区域组成，这几个过程域共同形成一种软件过程能力。每个过程域，都有一些特殊目标和通用目标，通过相应的特殊实践和通用实践来实现这些目标。当一个过程域的所有特殊实践和通用实践都按要求得到实施，就能实现该过程域的目标。 CMMI的原则、目标和方法 一、CMMI的原则： 1．强调高层管理者的支持。过程改进往往也是由高层管理者认识和提出的，大力度的、一致的支持是过程改进的关键。 2．仔细确定改进目标，首先应该对给定时间内的所能完成的改进目标进行正确的估计和定义并制定计划。选择能够达到的目标和能够看到对组织的效益。 3．选择最佳实践，应该基于组织现有的软件活动和过程财富，参考其他标准模型，取其精华去其糟粕，得到新的实践活动模型。 4．过程改进要与组织的商务目标一致，与发展战略紧密结合。 二、CMMI目标:

cmmi软件开发流程

软件开发流程软件项目生命周期模型

需求分析 需求分析流程图 过程描述 1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。

2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、 供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方 案。 关于自行开发和采购复用的分析， 如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用； 本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接 受范围内，可考虑采购； 否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。 9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。 10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。 11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。 12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。 13、PM、测试负责人与临时项目组确定项目关键参数。 工作量、工期、日程、人数 成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预 算的管理等同于计划工作量的管理。） 质量目标 14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。 15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。 16、PM、测试负责人编制项目计划书。 17、PM、测试负责人编制项目日程表。 18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。 19、PM指示配置管理员建立配置基线。 20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。

全套CMMi软件质量管理体系

XXXXX计算机软件有限公司 XX软件质量管理体系 V1.0 XX软件研发部 2010/12/1

目录 第一篇总则 (5) 一、《XX软件质量管理体系》的实施 (5) 二、目的 (5) 三、背景介绍 (5) 四、体系总体介绍 (7) 第二篇项目管理 (9) 一、立项管理 (9) 二、结项管理 (19) 三、项目计划 (24) 四、项目监控 (36) 五、风险管理 (44) 六、需求管理 (49) 第三篇技术实现过程 (57) 一、技术预研 (57) 二、SCRUM过程 (61) 三、用户验收 (70) 四、技术评审 (74) 第四篇支撑过程 (82) 一、配置管理 (82) 二、质量保证 (90) 三、培训管理 (99)

四、服务与维护 (106)

第一篇总则 一、《XX软件质量管理体系》的实施 XX计算机软件有限公司依据CMMi（软件能力成熟度模型集成）框架，结合公司多年来实施“敏捷开发”的开发方法的经验，以及公司的实际情况，编写的《XX软件质量管理体系》V1.0版已经编写完成。 本体系文档是公司质量管理体系法规性文件，是指导公司建立并实施质量管理体系的行动准则。公司全体员工必须遵照执行。 二、目的 本文档的目的在于： 通过建立软件过程管理体系，提高企业的软件过程能力，保证软件质量，保证商 务目标的实现。 基于精简的CMMi 3级管理体系，结合企业实际情况和经验积累，结合敏捷开发 的SCRUM方法。开发适合XX软件有限公司发展的软件过程管理体系。 使得XX软件的软件开发过程管理基本满足CMMi 3级要求。 三、背景介绍 CMMI-DEV CMMI是个了不起的规范，但是仍然有很多不足之处。CMMI对于项目管理很有指导价值，但是它对技术开发过程的论述却不够深入。对于大多数软件项目而言，技术开发占总工作量的70％以上，而项目管理占总工作量的30％以下。对大多数企业而言，技术开发过程的规范化比项目管理过程的规范化尤为重要与迫切。 软件开发是如此的灵活，如果没有规范来指导与制约，就容易因无序而导致混乱。但

cmmi软件开发流程

c m m i软件开发流程 Prepare d on 24 November 2020

软件开发流程软件项目生命周期模型

需求分析 需求分析流程图 过程描述 1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。

2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 ?对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨论表决的方法选择并确定最终的技术方案。 ?关于自行开发和采购复用的分析， ?如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、测试用例等)，一般应进行复用； ?本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本在项目可接受范围内，可考虑采购； ?否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。 9、PM召集临时项目组、测试负责人等技术骨干评审架构设计书和需求规格书。 10、PM组织临时项目组与客户沟通、说明需求，必要时编制系统原型向客户展示，直到临时项目组、客户就需求的真实含义达成共识、客户书面确认需求规格书为止。 11、临时项目组确定项目目标的范围，明确系统边界，建立系统的模块分解结构。 12、PM与测试负责人遵循《项目估算流程》组织人员进行项目估算。 13、PM、测试负责人与临时项目组确定项目关键参数。 ?工作量、工期、日程、人数 ?成本/预算（由于本公司的项目的绝大部分成本是人力成本，对估计成本的管理等同于估计工作量的管理，对实际成本的管理等同于实际工作量的管理，对预算的管理等同于计划工作量的 管理。） ?质量目标 14、PM、测试负责人与部门经理协调人员及资源、计划知识技能、协调相关干系人的参与。 15、项目组基于公司环境标准，结合项目实际情况建立适合的工作环境。 16、PM、测试负责人编制项目计划书。 17、PM、测试负责人编制项目日程表。 18、临时项目组、研发部、QA评审项目计划书，评审通过后正式生效。 19、PM指示配置管理员建立配置基线。 20、PM编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。

研发过程如何进行裁剪

研发过程如何进行裁剪 项目特点是裁剪依据和出发点。裁剪指南应包括以下的内容： 明确可裁剪的对象：可裁剪对象确定了裁剪的范围，可裁剪对象不仅限于过程元素和活动，还包括标准、方法和工具、输出的工作产品及模板等。 确定裁剪所考虑的要素：对于某个裁剪对象，其范围、频度、正式度等都是裁剪要素。 如，对于已有类似开发经验的项目，可以适当减少过程培训、业务培训等活动；对于开发周期较短的项目，可以适当合并一些评审活动，如概要设计和详细设计评审合并进行。 项目在进行裁剪时，由于裁剪指南很难枚举所有的裁剪情况，因此有时还是需要项目经理和QA依据经验进行判断和决定，这时，最根本的依据就是项目的质量要求和对风险的考虑。首先要分析如果一旦裁剪掉某些活动，是否会给项目带来风险，带来多大的风险，以及是否影响项目质量目标的达成。然后综合考虑后才能决定是否裁剪，如何裁剪。另一方面，企业建立标准过程的目的不是为了“为了规范而规范”，而是为了提高过程和技术的重用。 因此，如果项目在裁剪时有很大的灵活度，每个项目定义的过程都很随意或者项目过程之间相似的内容很少，那么重用的目的就很难实现了。所以，规范度和灵活度是项目裁剪时需要平衡的另外两个要素。 概括之，过程裁剪的原则是：质量与风险并重，规范与灵活的平衡。 一、企业在应用过程裁剪时的常见问题 不论企业实施了ISO9001、CMMI、六西格玛，或是其它任何类型的质量管理体系，通常都会形成完整的公司级标准过程体系。但当项目经理需要在项目中使用这个已定义好的过程体系文件时，面对厚厚的过程文件往往无从下手，心中也充满疑虑：

1. 我的项目开发周期只有3个月，团队4、5个人，难道要完全按照公司定义的标准过程执行吗？如果必须执行所有的过程和子过程，生成所有要求的技术和管理文档，那项目的开发周期恐怕不是3个月，而是4、5个月了。那我的项目还能成功吗？ 2. 我听说过“裁剪”这个词，不过到底是“裁剪”还是“裁减”，我还没有弄明白。即便弄明白了应该是“裁剪”，是Tailoring，而非“裁减”，可具体该怎么操作？我可以随心所欲将自己认为不必要的或者很费时费事的过程裁剪掉吗？ 3. 如果公司有QA，也有《裁剪指南》，那就好办了，我可以在QA的帮助下使用《裁剪指南》裁剪得到项目的过程，执行就是了。但如果公司没有QA 的角色，我就只能自己进行裁剪了。可是，裁减的结果需要有人批准吗？ 在这里，我们假定完整的公司级标准过程体系是包括了企业的方针、过程、指南、模板和表单等一整套的体系。那么，项目经理该如何是好？ 二、过程裁剪的目的和作用 建立裁剪指南的目的是用来指导项目对组织标准过程（Organizational Standard Process, OSP）进行裁剪，以形成符合项目特点的项目定义过程（Process Defined Process, PDP）。 组织标准过程是在企业的层面上描述的，它包括了开发一个完整产品/项目的全过程，以及相应的支撑过程，它是一个企业运作的过程的全集。因此，每个特定的项目都可能无法直接使用组织标准过程。比如，组织标准过程描述了开发一个系统级产品的完整过程，开发过程中包括了软件、硬件、结构、工业设计等开发过程。而某个特定项目仅仅包括纯软件的开发工作，在这种情况下，该项目无法也不应该盲目遵照执行完整的过程。或者，某个特定项目，项目的成功标准是按时交付，而客户要求的项目交付期特别短。为了达成这个目标，项目也不得不对过程进行裁剪以满足客户的需要。裁剪指南就是来帮助项目裁剪组织标准过程，以形成项目定义过程，使用项目定义过程来管理项目，实现项目的目标。

cmmi软件开发流程

c m m i软件开发流程 公司内部编号：（GOOD-TMMT-MMUT-UUPTY-UUYY-DTTI-

软件开发流程软件项目生命周期模型

需求分析需求分析流程图

过程描述

1、由部门经理组建临时项目组，并指定PM、开发人员、测试人员、QA，人数根据项目规模确定。 2、PM制定需求阶段日程表，该表须通过研发经理审核。 3、PM指示配置管理员建立配置库。 4、由PM与测试负责人提出裁剪申请，QA指导临时项目组人员对项目进行裁剪，形成项目裁剪表。 5、EPG和部门经理对裁剪结果进行审批，审批通过项目裁剪表正式生效。 6、PM与测试负责人确定项目管理机制，内容包括组织结构、沟通、跟踪、报告、风险管理、问题管理、QA、CM等。 7、项目组人员与客户进行沟通，编写需求清单列表。 8、PM组织临时项目组成员确定系统架构，编写架构设计书和需求规格书。架构设计过程中的重要的技术方案选择、开发/采购/复用分析等内容要明确体现在架构设计书中。 对技术方案选择(例如，系统结构、开发平台、数据库等的选择)，要事 先建立评价准则(例如，满足系统需求的能力(例如，功能、性能、可靠 性等)、技术的发展前景、供应商资质与实力等)及相对优先级，采用讨 论表决的方法选择并确定最终的技术方案。 关于自行开发和采购复用的分析， 如果公司有基本满足系统需要的可复用组件(包括其分析、设计、代码、 测试用例等)，一般应进行复用； 本公司没有能力开发或没有必要开发的非核心技术部分，如果采购成本 在项目可接受范围内，可考虑采购； 否则，由项目组自行开发。 架构设计的总体候选方案选择和供应商选择要使用正式的方法做决策。

CMMI过程文件(整理)

过程 ....\CM(配置管理)过程文档 ....\....................\JZ-SPI-S-CM-P01(配置管理过程文件).doc ....\....................\JZ-SPI-S-CM-P02(配置项命名规则).doc ....\....................\JZ-SPI-S-CM-P03(配置管理系统访问控制规程).doc ....\....................\JZ-SPI-S-CM-T01(配置项状态表).xls ....\....................\JZ-SPI-S-CM-T02(配置管理计划).doc ....\....................\JZ-SPI-S-CM-T04(配置项变更申请表).xls ....\....................\JZ-SPI-S-CM-T05(变更请求管理表).xls ....\....................\JZ-SPI-S-CM-T06(基线发布通知).xls ....\....................\JZ-SPI-S-CM-T07(配置库备份记录).xls ....\....................\JZ-SPI-S-CM-T08(配置审计记录).xls ....\....................\JZ-SPI-S-CM-T09(变更通知).xls ....\....................\JZ-SPI-S-CM-T11(配置库结构和权限表).xls ....\....................\配置库案例.rar ....\DAR(决策分析)过程文档 ....\.....................\JZ-SPI-S-DAR-P01(决策分析过程文件).doc ....\.....................\JZ-SPI-S-DAR-P02(决策分析指南).doc ....\.....................\JZ-SPI-S-DAR-T01(决策分析报告).xls ....\.....................\JZ-SPI-S-DAR-T01(决策分析报告模板).xls ....\IPM(集成项目管理)过程文档 ....\.........................\JZ-SPI-P-IPM-P01(集成项目管理过程文件).doc ....\.........................\JZ-SPI-P-IPM-T01(改进建议表).xls ....\.........................\JZ-SPI-P-IPM-T02(项目过程定义书) (2).xls ....\.........................\JZ-SPI-P-IPM-T02(项目过程定义书).xls ....\MA(度量与分析)过程文档 ....\......................\XX-SPI-S-MA-P01(度量分析过程文件).doc ....\......................\XX-SPI-S-MA-P02(度量方法指南).doc ....\......................\XX-SPI-S-MA-P03(分析方法指南).doc

软件项目估算指南

项目估算指南 Version 1.1 文档名称：CMMI5-项目估算指南-V1.1.doc

修订历史记录

目录 1目的 (4) 2范围 (4) 3术语、缩写词 (4) 4估算过程 (4) 4.1简要说明 (4) 4.2流程图 (5) 4.2.1自顶向下的方法 (5) 4.2.2自底向上的方法 (6) 4.3估算规程 (6) 4.4裁剪指南 (7) 5估算方法 (7) 5.1UCP估算算法 (7) 5.1.1估算UUCP (8) 5.1.2估算TCF调整因子 (8) 5.1.3估算EF调整因子 (9) 5.1.4估算UCP (10) 5.1.5估算工作量 (10) 5.1.6估算进度 (10) 5.1.7估算成本 (10) 6附录 (11) 6.1生产率数据来源 (11) 6.2进度估算数据来源 (11)

项目估算指南 1目的 本文用于估算软件项目的规模、进度、工作量、成本，以指导项目作出合理的估算。 2范围 本文件包括软件项目估算的各个方面，包括规模、进度、工作量、成本，并包括其在项目的中的分布估算。本文件适用于公司所有项目。 3术语、缩写词 UCP Use Case Point，用例点 4估算过程 4.1简要说明 准确的估算是最大可能加快开发速度的基础，没有准确的进度估算，再有效的进度计划也无从谈起。不切实际的估算、不正确的期望是带来项目问题的主要原因。 估算是一个不断改进的过程，只有当详细地理解了每个功能，你才有可能准确估算出软件开发的进度和成本。因此，能够提前做出的决策越多，估算的精确度就越高。 准确的估算可以更好的控制项目的规模、进度、成本。工作量和进度估算通常在提交建议书及制定项目计划时进行，在项目实施过程中，也可能要对工作量和进度重新估计。 对于软件规模的估算主要有三种方法：代码行，功能点，用例点。本公司现在主要使用用例点方法。 对于工作量的估计，主要有两种方法： ?自顶向下的方法（Top-down approach），用一个简单的方程从估计的规模求出估计的总工 作量，各阶段的工作量可以根据它们占总工作量的百分比而得到。在需求不太明确时，规 模估计比较困难，这时估算的误差会比较大。 ?自底向上的方法（Bottom-up approach），首先获得项目各部分估计的规模，然后得到整个 项目估计的规模。在这种方法主要依据WBS来估算，首先将项目进行分解，列出主要工 作，然后估计每件工作的工作量，汇总就可以得到整个项目的工作量。 对以上两种方法比较如下：

软件项目总体裁剪指南-模板

总体裁剪指南 文档编号： 文档信息：总体裁剪指南 文档名称：总体裁剪指南 文档类别：项目管理文件 密级：机密 建立日期： 创建人： 审核者： 批准人： 批准日期： 保管人： 编辑软件：Microsoft Office XP 中文版

*变化状态：A——增加，M——修改，D——删除

主要内容 1 简介 (4) 1.1 文档目的 (4) 1.2 适用范围 (4) 1.3 引用文件 (4) 1.4 术语 (4) 1.5 参考资料 (4) 2 过程总体描述 (4) 2.1 过程概述 (4) 2.2 过程结构描述 (4) 图索引： 图 1 流程图 (4)

1简介 1.1文档目的 为软件项目对组织标准软件过程进行详细裁剪时，提供框架和总体指导方针。 1.2适用范围 适用于本组织范围内的软件项目。 1.3引用文件 《组织过程定义过程》文件编号： 1.4术语 无 1.5参考资料 无 2过程总体描述 2.1过程概述 本指南根据本公司项目的实际情况编写而成。 2.2过程结构描述 2.2.1裁剪步骤 确定项目类别—>根据指南选择SDLC－>根据裁剪指南选择－>裁剪SDLC－>根据裁剪指南选择支持过程－>根据裁剪指南选择组织过程－>形成裁剪报告，进行评审－>批准后制定项目定义的标准过程－>开展项目活动。 2.2.2裁剪原则 基于项目特征：项目特征式裁剪工作的出发点，包括项目规模、项目类型、技术难度、产品类型、项目周期等要素。 明确裁剪的对象：不仅限于过程元素和活动，还包括参照标准、方法和工具、输出产品

及模板等。 确定裁剪所要考虑的要素：裁剪要素决定了裁剪的方向和尺度。例如：范围、频度、正 式度等都是裁剪要素。 裁剪的决定要基于风险分析进行考虑。 2.2.3项目分类及详细裁剪指南 2.2. 3.1 软件项目分类 为了以最佳的费效比开发符合需求的软件，在实施软件工程时，必须针对不同需求区别对待。组织定义软件类别和级别按如下分类管理： 软件规模非嵌入式软件源代码行数 巨n>500000 大50000

CMMI 22个PA缩写及主要内容

CMMI 22个PA缩写及主要内容 CMMI 22个PA缩写 EPG：工程过程组（Engineering Process Group） MSG：管理指导组/高层管理组（Management Steering Group）SPI：软件过程改进（Software Process Improvement） PAT：过程行动组（Process Action Team） PA：过程域（Process Area） PP：项目策划（Project Planning） PMC：项目监控（Project Monitoring and Control） IPM：集成的项目管理（Integrated Project Management） RSKM：风险管理（Risk Management） CM：配置管理（Configuration Management） PPQA：过程和产品质量保证（Process and Product Quality Assurance）MA：度量和分析（Measurement and Analysis） DAR：决策分析和解决方案（Decision Analysis and Resolution）REQM：需求管理（Requirements Management） RD：需求开发（Requirements Development） TS：技术解决方案（Technical Solution） PI：产品集成（Product Integration） Ver：验证（Verification） Val：确认（Validation）

OPF：组织过程焦点（Organization Process Focus） OPD：组织过程定义（Organization Process Definition） OT：组织培训（Organizational Training） 22个PA的主要内容有： 1．CM：（Configuration Management）软件配置管理。建立和维护在项目的整个软件生存周期中软件项目产品的完整性。 2．DAR：（Decision Analysis and Resolution）。应用正式的评估过程依据指标评估候选方案，在此基础上进行决策。 3．IPM：（Integrated Project Management）集成项目管理。根据从组织标准过程剪裁而来的集成的、定义的过程对项目和利益相关者的介入进行管理。 4．Life Cycle：（Software Life Cycle Model）项目管理的生命周期。关注的是项目的过程管理。 5．MA：（Measurement & Analysis）。开发并持续发展度量能力以满足项目管理的信息需求。 6．Milestone Review：（Milestone Review）阶段评审。在阶段结束时评审项目的状态并确定项目是否应该进入下一阶段。 7．OPD：（Organizational Process Definition）组织级过程定义。建立和维护有用的组织过程资产。 8．OPF：（Organizational Process Focus）组织级过程焦点。在理解现有过程强项和弱项的基础上计划和实施组织过程改善。 9．OT：（Organizational Training）培训管理。增加开发人员的技能和知识，使他们能有效地执行他们的任务。

基于CMMI的软件过程度量

摘要：CMMI为软件产品及软件过程提供了一套定量的表示和分析，即软件度量的模型。有效的软件度量过程能促进组织的软件过程能力的改进。文章结合国内应用特点，介绍了基于CMMI的多层架构软件产品的度量模型，并着重讨论了基于CMMI的软件过程度量，总结了软件过程度量的工作方法和思路，提出了解决国内软件度量的一般性方法，为软件过程改进提供了可行的方法和实践。 关键词：CMMI；软件度量；软件过程能力；度量项；门限值 0引言 软件度量的目的是为项目管理提供项目的执行情况的充分可见性，并使项目管理者了解项目实际进展与项目计划之间的偏差，以便采取纠正行动，保证项目的顺利进行。有效的软件度量过程促进组织的软件过程能力的改进。软件度量是软件特性的定量表示和分析方法；软件度量可分为软件产品度量和软件过程度量两类。软件产品度量(定量表示和分析软件产品特性)是独立于产品生产过程的度量；软件过程度量(定量表示和分析软件过程特性)是为管理者提供产品生产过程的状态信息和指导依据。 软件产品度量的要素为质量要素、评价准则、度量元。这里软件过程度量主要通过需求度量、规模度量、进度度量、工作量度量、风险管理度量、质量保证度量来分析。 1三层架构软件产品度量 1．1质量要素 软件质量可分解成六个要素，这六个要素是软件的基本特征。功能性：软件所实现的功能满足用户需求的程度；可靠性：在规定的时间和条件下，软件所能维持其性能水平的程度；易用性：对于一个软件，用户学习、操作、准备输入和理解输出时所做努力的程度；效率：在指定的条件下，软件实现某种功能使用计算机资源(包括时间)的有效程度；可维修性：为了满足用户需求、环境改变或发生软件错误时，对软件进行相应修改所需的努力程度；可移植性：软件从一个计算机系统或环境转移到另一个计算机系统或环境的难易程度。 1．2评价准则 评价准则包括：精确性、健壮性、安全性、通信有效性、处理有效性、设备有效性、可操作性、培训性、完备性、一致性、可追踪性、可见性、硬件系统无关性、软件系统无关性、可扩充性、公用性、模块性、清晰性、自描述性、简单性、结构性、产品文件完备性。 1．3度量元 根据软件的需求分析、概要设计、详细设计、实现、组装测试、确认测试和维护与使用七个阶段，制定针对每一个阶段的度量元。 2基于CMMI软件过程度量 从软件企业的观点出发，软件度量(software Measurement)是通过各种不同的量度对软件生命周期中的各个元素进行度量(Measure)，为项目管理者提供有关项目的各种重要信息，也是进行软件评估活动的基础。 Carnegie Mellon大学的SEI提出了以下的一个软件度量过程体系结构图：

CMMI体系简介及软件工作流程

CMMI体系简介及软件工作流程 质量管理部 2009年03 月 华丽娜主题 第一部分:CMMI基础知识 CMMI是什么 CMMI发展和厉史 CMMI模型组件概述 第二部分:公司质量体系文件综述 公司软件过程概述 公司过程文件概述 公司体系文件导读 CMMI是什么？ ◆Capability Maturity Model Integration(能力成熟度模型综合) 它综合了以下几方面: System engineering Software engineering Integrated Product and Process Development Supplier Sourcing ◆该模型提供一套可供公众使用的准则；这些准则描述那些成功地 实施了过程改进的组织的特性。

◆该模型用“软件能力成熟度”来衡量这种软件综合能力 CMMI是什么？ ?美国卡内塞一梅隆大学软件工程研究所(SEI)研制。 ?CMMI的前身是SW-CMM和SE-CMM ?CMMI有专门认证评估方法一SCAMPI 发展简史 草案于1997年制定(未广泛应用)。 到2000年，CMM演化成为 Software Engineering)于2002年1月正式推出。 CMMI的诞生（1） 版，经历了十多年，在这期间，IT产业有了长足的发展，相应的工 业标准或规范必然要不断地改进。 不再局限于纯粹软件的范崎。虽然人们了解和应用CMMI需要一定的 时间，但走CMMI将取代CMM这走必然的趋势。 CMMI的诞生（2） ◆CMMI为工业界和政府部门提供了一个集成的产品集，其主要目的 是消除不同模型之间的不一致和重复，降低基于模型改善的成本。 CMMI将以更加系统和一致的框架来指导组织改善软件过程，提高产品和服务的开发、获取和维护能力。 CMMI模型组件概述 CMMI分级（阶段）模型 CMMI阶段式模型的结构

CMMI体系文件项目计划过程文件

文件修订记录

目录 1目的 (1) 2适用范围 (1) 3资源和工具 (1) 4定义和缩写 (1) 5职责 (1) 6过程 (2) 6.1项目总计划 (2) 6.1.1启动条件 (2) 6.1.2输入 (2) 6.1.3活动 (2) 6.1.4输出 (2) 6.1.5关闭标准 (2) 6.2项目计划 (3) 6.2.1过程流程图 (3) 6.2.2启动条件 (3) 6.2.3输入 (3) 6.2.4活动 (4) 6.2.4.1确定项目目标和范围 (4) 6.2.4.2确定项目组织 (4) 6.2.4.3确定项目的技术方法 (5) 6.2.4.4确定项目目标和范围 (6) 6.2.4.5确项目生命周期模型 (6) 6.2.4.6项目过程及活动的裁剪 (6) 6.2.4.7项目估算 (6) 6.2.4.8确定项目里程碑 (7) 6.2.4.9制定项目进度计划 (7) 6.2.4.10制定项目监控计划 (8)

6.2.4.11制定项目风险计划 (8) 6.2.4.12制定数据管理计划 (8) 6.2.4.13制定软硬件资源计划 (8) 6.2.4.14制定人力资源计划 (9) 6.2.4.15制定干系人介入计划 (9) 6.2.4.16制定评审计划 (9) 6.2.4.17制定决策计划 (10) 6.2.4.18制定培训计划 (10) 6.2.4.19制定验收计划 (10) 6.2.4.20确定下属计划 (10) 6.2.4.21编写项目计划 (10) 项目经理汇总上面的信息后整理出《项目计划》并提交评审。参见《项目计划》模板。 (10) 6.2.4.22评审项目计划 (10) 6.2.5输出 (12) 6.2.6关闭标准 (12) 7验证 (12) 8度量 (12) 9培训 (12)

CMMI_3级软件过程改进方法与规范

内容提要 软件过程改进是目前IT 企业研发管理的重点与难点。为了提高软件过程能力，企业首先要研制软件过程规范，这是有一定难度并且费时费力的工作。 本文论述的是一套通用的CMMI 3级软件过程改进方法与规范，称为“精简并行过程”（SPP）。SPP 2.0共有19个关键过程域，分为项目管理过程、技术开发过程和支撑过程三大类： ?项目管理过程有7个关键过程域，分别为立项管理、结项管理、项目计划、项 目跟踪、风险管理、外包管理和需求管理。 ?技术开发过程有8个关键过程域，分别为需求开发、技术预研、系统设计、实 现与测试、系统测试、用户验收、产品维护和技术评审。 ?支撑过程有4个关键过程域，分别为配置管理、质量保证、采购管理和培训管 理。 SPP 2.0文档总数约500余页，包含了众多的过程规范和模板。采用SPP，用户可以在最短的时间内建立适合于本企业的软件过程规范，大大降低用户研制规范的代价和风险。 一、背景介绍 在国内，绝大多数大中型IT企业几乎都面临着“研发管理混乱”的难题。“研发管理混乱”必将导致“产品质量低下”、“进度延误”、“费用超支”等问题。IT企业谋求发展，研发管理必须规范化，这是大中型IT企业的迫切需求。软件过程改进（Software Process Improvement, SPI）是目前国内大中型IT企业研发管理的重点与难点。 CMM（Capability Maturity Model）是用于衡量软件过程能力的事实上的标准，同时也是目前软件过程改进最好的参考标准。CMM是由美国卡内基-梅隆大学（Carnegie-Mellon）软件工程研究所（Software Engineering Institute, SEI）研制的，其发展简史如下： ?CMM 1.0于1991年制定。 ?CMM 1.1于1993发布，该版本应用最广泛。 ?CMM 2.0草案于1997年制定（未广泛应用）。 ?到2000年，CMM演化成为CMMI（Capability Maturity Model Integration），CMM 2.0成为CMMI 1.0的主要组成部分。 ?CMMI-SE/SW 1.1（CMMI for System Engineering and Software Engineering）于 2002年1月正式推出。 CMM将软件过程能力分为5个级别，最低为1级，最高为5级。目前国内只有几家IT企业达到了CMM 2级或CMM 3级。鉴于CMM 已经被美国、印度软件业广为采纳，并且取得了卓著成效，近两年来国内兴起了CMM 热潮。CMM受欢迎的程度远远超过了ISO同类标准。 国内IT企业采用CMM的目的大体有两种： （1）主要想提高企业的软件过程能力，但并不关心CMM评估。

汽车电子CMMI软件开发流程

汽车电子软件开发流程 ——CMMI篇 作者:朱忠安 版本: 1.0 状态:草版

1历史记录

2索引 1历史记录 (2) 2索引 (3) 3概要 (4) 4一般嵌入式系统开发简介 (5) 4.1嵌入式系统定义 (5) 4.2嵌入式系统的开发组织架构 (5) 4.3嵌入式系统软件开发流程图 (6) 4.4流程图简介 (7) 5CMMI软件团队解析 (8) 5.1CMMI软件开发流程标准 (8) 5.2软件研发组织架构解析 (9) 5.3软件项目开发过程 (9) 5.4系统测试组织结构 (9) 6CMMI软件项目变更管理 (10) 6.1软件变更控制工具介绍 (10) 6.2软件变更控制流程 (10) 7软件开发知识简介 (11) 7.1软件开发的特点 (11) 7.2如何做好软件开发 (11) 7.2.1客户角度 (11) 7.2.2供应商角度 (11)

3概要 本着为客户服务的宗旨，让更多的想进入汽车研发团队的工程师们了解和熟悉的软件开发流程，减少项目开发过程中不必要的误解，故做此介绍抛砖引玉。

4一般嵌入式系统开发简介 4.1嵌入式系统定义 对于嵌入式系统，一般教科书上面有这样定义：以应用为中心，以计算机技术为基础，软硬件可裁剪，系统对功能、可靠性、成本、体积、耗电量和应用环境，有特殊要求的专用计算机系统，是将应用程序、操作系统和计算机硬件集成在一起的系统。 其实这句话不难理解，概括起来只有两点： <1>计算机系统 任何一个嵌入式系统必定是一个计算机系统,而最基本的计算机系统无外乎CPU,内存,输入设备,输出设备;嵌入式系统也是如此. 谈到这里,就必须要说到两个概念:微处理器和微控制器. 所谓微处理器很容易理解,就是中央处理器CPU,比如所ARM9,它的为处理器就是ARM920T.换句话说就是嵌入式系统的核心控制单元. 所谓微控制器,其实也不难理解;我们现在大部分的电子产品所使用的都是集成芯片,也就是一块芯片中不仅仅包含的是CPU,还把许多的外围设配都集成在一块芯片中,比如把PWM控制器，把flash，把音频处理器，把内存，把输入输出设备等都集成在一块芯片中，这样的一块集成多功能的芯片就是微控制器。基本上一块IC就是一个小型的嵌入式系统。这样的做的好处也是显而易见的：<1>可以减少嵌入式系统设计的复杂度；<2>节省成本,因为一块集成多功能的IC,比你去用一块CPU搭建外围设备的成本要少的多。 <2>特定应用 对于嵌入式产品的开发，一般都是具有特定的应用；根据特定的需求去定制的。比如仪表，一套完整的仪表系统，都是只适合与特定款型的车。因为电子产品的性质各有不同，嵌入式系统的开发也很难有一套统一的标准，没有一个国际标准组织或学术单位，规定嵌入式系统一定要用什么CPU，用什么开发语言，一定要用什么操作系统，一定要用哪一套开发工具。只会根据特定的需求去定制。 4.2嵌入式系统的开发组织架构 一般的研发团队都有很严谨漂亮的组织架构，嵌入式系统的研发团队也是如是；至少应该有以下小组。 <1>项目管理组 <2>硬件组 <3>产品外观和结构设计组 <4>软件组 1）软件项目管理组 2）固件组 3）系统组

软件标准过程定义指南

文件编号：BJZR-WI3-4.1-01-V1.0 文件类别：作业指导类 密级：内部 软件标准过程定义指南 北京中软信息系统工程有限公司 2011年2月

文件更改历史记录记录编号：BJZR-R-110225-陆颖秋

目录 1 概要 (4) 2 文档目的 (4) 3 术语定义 (4) 4 目标读者 (4) 5 角色和职责 (4) 6 指南描述 (5) 6.1 建立并维护软件过程资产库 (5) 6.2 建立并维护软件标准过程库 (5) 6.3 建立并维护软件生命周期模型 (6) 6.4 建立并维护软件标准过程裁剪指南 (6) 6.5 建立软件工作环境标准 (7) 6.6 建立软件项目DBS结构 (7) 6.7 建立并维护软件度量库 (7) 7 其他 (7) 7.1 相关评审指南 (8) 7.2 裁剪指南 (8) 7.3 相关培训建议 (8)

1 概要 本指南依据《过程管理程序文件》，针对北京中软的软件工程的过程定义进行详细的描述。 2 文档目的 为EPG开展软件类的标准过程定义提供依据和指导框架。 3 术语定义 EPG：Engineering Process Group 工程过程组； OSSP：Organization Standard Software Process 组织标准软件过程 4 目标读者 ●EPG组所有成员 ●对软件类标准过程定义感兴趣的人员 5 角色和职责 第4页/共 8页

6 指南描述 软件类过程定义的目的是结合GJB9001B和CMMI的特点，建立和维护一套符合公司业务特点的软件类过程标准集以及过程数据库，规范软件类项目的过程定义的活动，使其输出满足软件工程部门的要求，并为软件工程项目积累性的长期得益以及软件科研任务打下基础。 6.1 建立并维护软件过程资产库 软件过程资产库是公司的过程财富。软件过程资产库的内容包含： ?软件标准过程库；（后续章节6.2详细描述） ?软件度量库；（后续章节6.7详细描述） ?软件最佳实践库；(包含好的文档样例、好的案例集和软件复用代码集) ?软件知识库。 对过程资产库的维护和管理，详细参见《软件过程资产库维护指南》。 6.2 建立并维护软件标准过程库 参照CMMI阶段表示法中的各个过程域，结合公司的战略目标和业务特点，EPG组要定义整个软件类的公司级的标准过程，具体活动包括： ?对照GJB9001B和CMMI，分析两者的共性及差异； ?评估公司的过程现状，依据CMMI改进模型实施差距分析； ?结合差距分析及公司战略目标与业务特点，规划软件类标准过程结构； ?在原有的公司级标准过程库的基础上，新编或修订程序文件、模板、指南 规范、检查表等，形成一套适用的软件类标准过程库； ?建立适用公司业务特点的软件生命周期模型，用于指导项目经理实施软件 生命周期选择；（后续章节6.3详细描述） ?建立适用的可行的项目过程裁剪指南，用于指导项目经理实施项目过程定 义；(后续章节6.4详细描述) ?建立适用的软件工作环境标准；（后续章节6.5详细描述） ?建立适用的软件项目DBS结构；（后续章节6.6详细描述） 第5页/共 8页