CMMI 附录G-1 用户需求说明书
{ 项目名称} 用户需求说明书
机构公开信息
版本历史
目录
0. 文档介绍 (4)
0.1文档目的 (4)
0.2文档范围 (4)
0.3读者对象 (4)
0.4参考文档 (4)
0.5术语与缩写解释 (4)
1. 产品介绍 (5)
2. 产品面向的用户群体 (5)
3. 产品应当遵循的标准或规范 (5)
4. 产品的功能性需求 (5)
4.0功能性需求分类 (5)
4.M F EATURE M (6)
4.m.n Function M.N (6)
5. 产品的非功能性需求 (6)
5.1用户界面需求 (6)
5.2软硬件环境需求 (6)
5.3产品质量需求 (6)
5.N 其他需求 (7)
附录A：用户需求调查报告 (8)
A.1需求标题1 (8)
A.N 需求标题N (8)
0. 文档介绍
0.1 文档目的
0.2 文档范围
0.3 读者对象
0.4 参考文档
提示：列出本文档的所有参考文献（可以是非正式出版物），格式如下：[标识符] 作者，文献名称，出版单位（或归属单位），日期
例如：
[SPP-PROC-PP] SEPG，需求开发规范，机构名称，日期
0.5 术语与缩写解释
1. 产品介绍
提示：
（1）说明产品是什么，什么用途。
（2）介绍产品的开发背景。
2. 产品面向的用户群体
提示：
（1）描述本产品面向的用户（客户、最终用户）的特征，
（2）说明本产品将给他们带来什么好处？他们选择本产品的可能性有多大？
3. 产品应当遵循的标准或规范
提示：阐述本产品应当遵循什么标准、规范或业务规则（Business Rules），违反标准、规范或业务规则的产品通常不太可能被接受。
4. 产品的功能性需求
4.0 功能性需求分类
提示：将功能性需求先粗分再细分，下表中的Feature A, Function A.1等符号应当被替换成有含义的名称。
4.m Feature M
提示：此处写一些承上启下的文字。
4.m.n Function M.N
功能描述：
……
5. 产品的非功能性需求5.1 用户界面需求
5.2 软硬件环境需求
5.3 产品质量需求
5.n 其他需求
附录A：用户需求调查报告
常见需求调查方式有：
?与用户交谈，向用户提问题。
?参观用户的工作流程，观察用户的操作。
?向用户群体发调查问卷。
?与同行、专家交谈，听取他们的意见。
?分析已经存在的同类软件产品，提取需求。
?从行业标准、规则中提取需求。
?从Internet上搜查相关资料。
A.1 需求标题1
A.n 需求标题
N
CMMI 过程域 - 实践
过程管理的CMMI模型的过程域、特定目标、特定实践 目录 1 概述 (1) 2 通用目标和实践 (1) 3 成熟度等级与过程域 (2) 4 过程域的特定目标和特定实践 (3) 4.1 项目管理类 (3) 4.2 组织过程类 (5) 4.3 工程类 (7) 4.4 支持类 (9) 1 概述 在企业管理中，研发软件的质量由三要素决定：人、技术、过程。其中，研发软件的过程是影响软件质量的最大因素。所以，提高软件研发水平的一个有力措施就是提高企业的过程管理和改进水平，CMMI的阶段式是衡量软件企业总体过程管理水平的一个通用模型，共分5级，称作能力成熟度，分别称为： 1)初始化 2)项目管理 3)过程管理 4)定量管理 5)过程优化 要达到一定的能力成熟度等级，就要完成它以及以下的所有成熟度等级所对应的所有过程域。要完成一个过程域，就必须完成它的所有特定目标和通用目标。通用目标衡量企业的过程制度化水平，共有三个，分别是：GG1（Achieve Specific Goals，实现特定目标）、GG2（Institutionalize a Managed Process，制度化已管理过程）、 GG3（Institutionalize a Defined Process，制度化已定义过程），对应的通用实践如下： 2 通用目标和实践 GG 1 实现特定目标(适用于连续式) GP 1.1 执行特定实践 GG 2 制度化管理进程 GP2.1 建立组织方针 GP2.2 计划过程 GP 2.3 提供资源
GP 2.4 分配责任 GP 2.5 培养人 GP 2.6 控制工作产品 GP 2.7 识别和使共利益者介入 GP 2.8 监视和控制过程 GP2.9 客观评价一致性 GP 2.10 跟高层一起审查状况 GG 3 制度化已定义的过程 GP 3.1 建立定义流程 GP 3.2 收集过程相关工作经验 按照所要实现的能力成熟度等级，过程域的特定目标和实践要结合通用目标和实践完成。 3 成熟度等级与过程域 5个成熟度等级共有22个过程域，对应的过程域如下表：
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过程域的四个种类
本文从CSDN转载 CMMI过程域的四个种类 §过程管理 §项目管理 §工程 §支持 1. 过程域之过程管理类 下面这些都是CMMI里的过程管理PA： 1. 机构过程聚焦； 2. 机构过程定义； 3. 机构的培训； 4. 机构过程执行； 5. 机构创新与部署 过程管理PA包含着一些涉及定义、计划、资源支持、配置、实施、监测、控制、评估、量化以及过程改进相关的cross-project行为。 特别注意：机构综合环境(Organizational Environment for Integration)将被IPPD所覆盖。 过程管理过程PA的理解： The process management Pas apply across the organization as a whole and provide details that support the Capability Level 3 Generic Goal. 对于已选择的PAs，企业必须有一套标准的过程，个体的项目都须符合该过程的需要。 定义在Capability Level2制度中的PAs，提供了project level stablility，过程管理PAs可以利用起来。如，策划、计划、资源、职责、培训、执行过程、配置管理、监控、目标验证、管理回顾。 基本过程管理过程域，如下图
高级过程管理过程域，如下图 2. 过程域之项目管理 下面这些都是CMMI项目管理PA： 项目计划(PP)。项目监控(PMC)。供应商协议管理(SAM)。项目集成管理(IPM)。风险管理(RSKM)。Quantitative Project Management(QPM) 特别注意：Integrated Teaming(IT) and IPM(IPPD)将被IPPD覆盖。集成供应商管理将被SS覆盖。 基本项目管理过程，如下图：
全套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％以下。对大多数企业而言，技术开发过程的规范化比项目管理过程的规范化尤为重要与迫切。 软件开发是如此的灵活，如果没有规范来指导与制约，就容易因无序而导致混乱。但
CMMI3级18个过程域
CMMI3级过程域一共有18个PA，分别是： 过程管理 1、OPD：（Organizational Process Definition）组织级过程定义。建立和维护有用的组织过程资产。 2、OPF：（Organizational Process Focus）组织级过程焦点。在理解现有过程强项和弱项的基础上计划和实施组织过程改善。 3、OT：（Organizational Training）组织培训管理。增加开发人员的技能和知识，使他们能有效地执行他们的任务。 项目管理： 4、PP：（Project Plan）项目计划。保证在正确的时间有正确的资源可用。为每个人员分配任务。协调人员。根据实际情况，调整项目。 5、PMC：（Project Monitoring and Control）项目监督与控制。通过项目的跟踪与监控活动，及时反映项目的进度、费用、风险、规模、关键计算机资源及工作量等情况，通过对跟踪结果的分析，依据跟踪与监控策略采取有效的行动，使项目组能在既定的时间、费用、质量要求等情况下完成项目。 6、SAM：（Supplier Agreement Management）供应商协议管理。旨在对以正式协定的形式从项目之外的供方采办的产品和服务实施管理。 7、IPM：（Integrated Project Management）集成项目管理。根据从组织标准过程剪裁而来的集成的、定义的过程对项目和利益相关者的介入进行管理。 8、RSKM：（Risk Management）风险管理。识别潜在的问题，以便策划应对风险的活动和必要时在整个项目生存周期中实施这些活动，缓解不利的影响，实现目标。 工程管理：
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编制阶段总结报告（项目总结报告中的度量分析页面），召开阶段会议。
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模型过程域系列学习中文版
【CMMI学习】量化项目管理：CMMI模型过程域系列学习中文版 QUANTITATIVE PROJECT MANAGEMENT 量化项目管理 Purpose 目的 量化项目管理（简称QPM）的目的是量化地管理项目的已定义过程，以达到项目既定的质量和过程性能目标。 Introductory Notes 简介 上述被识别的质量和过程性能目标、度量和基线，是由组织过程性能过程域相关内容开发而来。随后，实施与量化项目管理过程域相关过程的结果（如度量定义和度量数据），将成为组织过程性能过程域所指的组织过程资产库的一部分。 为有效实施本过程域的的特定实践，组织应已建立一组标准过程和相关的组织过程资产，例如已用于各项目建立其已定义过程的组织度量库和组织过程资产库。项目的已定义过程是由一组集成的和一致的项目生命周期下的子过程构成。其中一部分是通过选择和裁剪组织标准过程而来。 项目还应确保可以获得供应商工作的度量和进度数据。要成功的完成本过程域的特定实践必须与供应商建立有效的关系。 过程性能是实际过程性能结果的度量指标。过程性能由两方面组成，包括过程度量（如投入、周期时间、缺陷去除效率）和产品度量（如可靠度、缺陷密度、反应时间）。 子过程是更高级已定义过程的已定义的模块。例如，典型的组织的开发过程，由需求开发、设计、构建、测试和同行评审等子过程构成。这些子过程本身也可适时的进一步分解为其他子过程或过程元素。 量化管理的一个基本要素是对估计要有信心（应可以预测满足项目质量和过程性能目标的程度）。基于识别出来的可预测性能的需要，选定将被统计化管理的子过程。 量化管理的另一个基本要素是要了解实际过程性能变化的本质和程度，并了解在何时项目的实际性能将无法达成项目质量和过程性能的目标。 统计管理化涉及统计思想和正确使用各种统计技术，如执行图、控制图、置信区间、预测区间、假设验证等。量化管理使用统计管理得到的数据，以帮助该项目预测是否将能够实现其质量和过程性能的目标，并识别应采取的纠正措施。 本过程域用于管理项目，但相关概念也可用于管理其他组或功能组。运用相关概念管理其他组或功能组未必有助于实现组织的业务目标，但可以帮助这些组或功能组控制自己的过程。
(完整版)CMMI过程域总结v2.0,推荐文档
CMMI 基本介绍V2.0 目录 1组织成熟度级别和类别 (2) 2通用目标和通用实践 (3) 3RD 需求开发REQUIREMENTS DEVELOPMENT (4) 4REQM 需求管理REQUIREMENTS MANAGEMENT (5) 5PP 项目策划PROJECT PLANNING (6) 6PMC 项目监督和控制PROJECT MONITORING AND CONTROL (7) 7RSKM 风险管理RISK MANAGEMENT (8) 8SAM 供应商协议管理SUPPLIER AGREEMENT MANAGEMENT (9) 9CM 配置管理CONFIGURATION MANAGEMENT (10) 10PPQA 过程和产品质量保证PROCESS AND PRODUCT QUALITY ASSURANCE (11) 11MA 度量和分析MEASUREMENT AND ANALYSIS (12) 12DAR 决策分析和解决DECISION ANALYSIS AND RESOLUTION (13) 13TS 技术解决方案TECHNICAL SOLUTION (14) 14PI 产品集成PRODUCT INTEGRATION (15) 15VER 验证VERIFICATION (16) 16VAL 确认VALIDATION (17) 17OPF 组织过程聚焦ORGANIZATIONAL PROCESS FOCUS (18) 18OPD 组织过程定义ORGANIZATIONAL PROCESS DEFINITION (19) 19OT 组织培训ORGANIZATIONAL TRAINING (20) 20IPM 集成项目管理INTEGRATED PROJECT MANAGEMENT (21) 21OPP 组织过程性能ORGANIZATIONAL PROCESS PERFORMANCE (22) 22QPM 量化项目管理QUANTITATIVE PROJECT MANAGEMENT (23) 23CAR 因果分析和解决CAUSAL ANALYSIS AND RESOLUTION (24) 24OPM 组织性能管理ORGANIZATIONAL PERFORMANCE MANAGEMENT (25)
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的软件过程度量
摘要：CMMI为软件产品及软件过程提供了一套定量的表示和分析，即软件度量的模型。有效的软件度量过程能促进组织的软件过程能力的改进。文章结合国内应用特点，介绍了基于CMMI的多层架构软件产品的度量模型，并着重讨论了基于CMMI的软件过程度量，总结了软件过程度量的工作方法和思路，提出了解决国内软件度量的一般性方法，为软件过程改进提供了可行的方法和实践。 关键词：CMMI；软件度量；软件过程能力；度量项；门限值 0引言 软件度量的目的是为项目管理提供项目的执行情况的充分可见性，并使项目管理者了解项目实际进展与项目计划之间的偏差，以便采取纠正行动，保证项目的顺利进行。有效的软件度量过程促进组织的软件过程能力的改进。软件度量是软件特性的定量表示和分析方法；软件度量可分为软件产品度量和软件过程度量两类。软件产品度量(定量表示和分析软件产品特性)是独立于产品生产过程的度量；软件过程度量(定量表示和分析软件过程特性)是为管理者提供产品生产过程的状态信息和指导依据。 软件产品度量的要素为质量要素、评价准则、度量元。这里软件过程度量主要通过需求度量、规模度量、进度度量、工作量度量、风险管理度量、质量保证度量来分析。 1三层架构软件产品度量 1．1质量要素 软件质量可分解成六个要素，这六个要素是软件的基本特征。功能性：软件所实现的功能满足用户需求的程度；可靠性：在规定的时间和条件下，软件所能维持其性能水平的程度；易用性：对于一个软件，用户学习、操作、准备输入和理解输出时所做努力的程度；效率：在指定的条件下，软件实现某种功能使用计算机资源(包括时间)的有效程度；可维修性：为了满足用户需求、环境改变或发生软件错误时，对软件进行相应修改所需的努力程度；可移植性：软件从一个计算机系统或环境转移到另一个计算机系统或环境的难易程度。 1．2评价准则 评价准则包括：精确性、健壮性、安全性、通信有效性、处理有效性、设备有效性、可操作性、培训性、完备性、一致性、可追踪性、可见性、硬件系统无关性、软件系统无关性、可扩充性、公用性、模块性、清晰性、自描述性、简单性、结构性、产品文件完备性。 1．3度量元 根据软件的需求分析、概要设计、详细设计、实现、组装测试、确认测试和维护与使用七个阶段，制定针对每一个阶段的度量元。 2基于CMMI软件过程度量 从软件企业的观点出发，软件度量(software Measurement)是通过各种不同的量度对软件生命周期中的各个元素进行度量(Measure)，为项目管理者提供有关项目的各种重要信息，也是进行软件评估活动的基础。 Carnegie Mellon大学的SEI提出了以下的一个软件度量过程体系结构图：
CMMI-DEV_V1.2过程域简要
CMMI-DEV 1.2的22个过程域
CMMI特定目标（SG）和特定实践（SP）汇总 CMMI 2级过程域：项目策划Project Planning SG1 Establish Estimates 建立估算 SP 1.1 Estimate the Scope of the Project 估算项目的范围 SP 1.2 Establish Estimates of Work Product and Task Attributes 估算工作产品和任务属性SP 1.3 Define Project Lifecycle 定义项目生命周期 SP 1.4 Determine Estimates of Effort and Cost 估算工作量和成本 SG2 Develop a Project Plan 开发项目计划 SP 2.1 Establish the Budget and Schedule 编制预算和进度 SP 2.2 Identify Project Risks识别项目风险 SP 2.3 Plan for Data Management 计划数据管理 SP 2.4 Plan for Project Resources 计划项目资源 SP 2.5 Plan for Needed Knowledge and Skills 计划所需的知识和技能 SP 2.6 Plan Stakeholder Involvement 计划干系人的参与 SP 2.7 Establish the Project Plan 建立项目计划 SG3 Obtain Commitment to the Plan 获得对计划的承诺 SP 3.1 Review Plans That Affect the Project 审查影响项目的计划 SP 3.2 Reconcile Work and Resource Levels调整工作与资源水平 SP 3.3 Obtain Plan Commitment 获得计划承诺 CMMI 2级过程域：项目监控Project Monitoring and Control SG1 Monitor Project Against Plan 依据计划监督项目 SP 1.1 Monitor Project Planning Parameters 监督项目计划的参数 SP 1.2 Monitor Commitments 监督承诺 SP 1.3 Monitor Project Risks 监督项目风险 SP 1.4 Monitor Data Management 监督数据管理 SP 1.5 Monitor Stakeholder Involvement 监督干系人的介入 SP 1.6 Conduct Progress Reviews 项目进展审查 SP 1.7 Conduct Milestone Reviews 里程碑审查 SG2 Manage Corrective Action to Closure 管理纠正措施 SP 2.1 Analyze Issues 分析问题 SP 2.2 Take Corrective Action 采取纠正措施 SP 2.3 Manage Corrective Action 管理纠正措施 CMMI 2级过程域：供应商协议管理Supplier Agreement Management SG1 Establish Supplier Agreements 签定供应商协议 SP 1.1 Determine Acquisition Type 确定采购方式 SP 1.2 Select Suppliers 选择供应商 SP 1.3 Establish Supplier Agreements 签定供应商协议 SG2 Satisfy Supplier Agreements 满足供应商协议 SP 2.1 Execute the Supplier Agreement 执行供应商协议 SP 2.2 Monitor Selected Supplier Processes 监督选定的供应过程 SP 2.3 Evaluate Selected Supplier Work Products 评价供应商产品
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过程域总结
CMMI基本介绍 目录 1 2 3 4 5 6 7 8 9 组织成熟度级别和类别........................................ 错误!未定义书签。通用目标和通用实践......................................... 错误!未定义书签。RD 需求开发REQUIREMENTS DEVELOPMENT ........................ 错误!未定义书签。REQM需求管理REQUIREMENTS MANAGEMENT ........................ 错误!未定义书签。PP项目策划PROJECT PLANNING ................................. 错误!未定义书签。PMC项目监督和控制PROJECT MONITORING AND CONTROL ............ 错误!未定义书签。RSKM风险管理RISK MANAGEMENT ................................ 错误!未定义书签。SAM供应商协议管理SUPPLIER AGREEMENT MANAGEMENT ............. 错误!未定义书签。CM配置管理CONFIGURATION MANAGEMENT ......................... 错误!未定义书签。10 PPQA过程和产品质量保证PROCESS AND PRODUCT QUALITY ASSURANCE 错误!未定义书签。11 MA度量和分析MEASUREMENT AND ANALYSIS ....................... 错误!未定义书签。12 DAR决策分析和解决DECISION ANALYSIS AND RESOLUTION .......... 错误!未定义书签。 13 TS技术解决方案TECHNICAL SOLUTION ........................... 错误!未定义书签。14 PI产品集成PRODUCT INTEGRATION .............................. 错误!未定义书签。15 VER验证VERIFICATION ....................................... 错误!未定义书签。16 VAL确认VALIDATION ......................................... 错
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+L2标准体系详解
CMMI L2标准体系详解 序： 一个处于“无序化”生产的软件公司，要进行过程改进，首要是改进什么呢？ 做任何事情都需要计划，做软件开发这样复杂的工作更加需要计划，所以2级中有项目计划(PP)以及项目计划跟踪与控制(PMC)两个PA，分别对指定计划以及计划的执行给出了详细的标准。 人是会死的，需求是会变的。需求变更是每个软件公司最头疼的问题，需求变更也是导致项目进度拖延、成本高涨的主要原因。如何管理好需求呢？需求管理(RM)给出了详细的指引。 软件生产越来越复杂，有时候我们需要采购一些组件，用于项目中。另外一个方面，纯软件的项目比例也慢慢缩小，很多软件是基于一定的硬件的，而不少硬件也是需要采购的。如何采购到合适的软硬件，如何保证采购工作不影响项目成功呢？供应商协议管理(SAM)会给你一个解答。 软件是比较难进行量化管理的，但作为公司的管理者，总会想知道成本、进度、缺陷方面的一些数据，以了解项目的情况。CMMI2级，已经对度量提出了要求，详细情况见度量(MA)这个PA。 如何保证软件生产过程中各类工作产品协调一致，配置管理(CM)会给出指导。 如何保证每个工作产品以及生产工作产品的过程是遵照规定执行的呢？产品与过程质量保证(PPQA)有明确的指引。 CMMI L2级一共有以下PA： 1)项目计划(PP) 2)项目计划跟踪与控制(PMC) 3)需求管理(RM) 4)供应商协议管理(SAM) 5)度量(MA) 6)配置管理(CM) 7)产品与过程质量保证(PPQA) 每个PA有什么乾坤呢？我们会详细向大家阐述。 目录 一章：需求管理(Requirements Management) (2) 二章：项目计划(Project Planning) (4) 三章：项目跟踪和控制(Project Monitoring and Control) (6) 四章：供应商协议(Supplier Agreement Management) (8) 五章：过程与产品质量保证(Process and Product Quality Assurance) (9) 六章：配置管理(Configuration Management) (10) 七章：度量(Measurement and Analysis) (13)
CMMI二级过程域
CMMI二级过程域 1、需求管理（REQM） SG1：管理需求 SP1.1：理解需求 SP1.2：获取需求 SP1.3：管理需求变更 SP1.4：维护需求的双向追溯性 SP1.5：确保项目工作与需求的一致性 2、项目策划（PP） SG1：建立估算值 SP1.1：估计项目的范围 SP1.2：建立工作产品与任务属性的估算值 SP1.3：定义项目点生命周期 SP1.4：估计工作量和成本SG2：开发项目计划 SP2.1：建立预算和进度 SP2.2：识别项目风险 SP2.3：对数据管理进行计划 SP2.4：策划项目的资源SP2.5：策划项目过程所需的知识和技能 SP2.6：策划干系人的参与SP2.7：建立和完成项目计划 SG3：获取对项目计划的承诺 SP3.1：评审影响项目的各种计划 SP3.2：调整工作和资源水平 SP3.3：获得对计划的承诺 3、项目监控（PMC）
SG1：按计划监控项目 SP1.1监控项目计划的各项参数 SP1.2监控承诺事项 SP1.3监控项目风险 SP1.4监控数据管理 SP1.5监控干系人的参与 SP1.6进行进度审计 SP1.7进行里程碑审查 SG2：管理纠正措施，直至关闭 SP2.1分析问题 SP2.2采取纠正措施 SP2.3管理纠正措施 4、配置管理（CM） SG1：建立基线 SP1.1：识别配置项 SP1.2：建立配置管理系统 SP1.3：建立或发布基线 SG2：跟踪和控制变更 SP2.1：跟踪变更请求 SP2.2：控制配置项 SG3：建立完整性 SP1.1：建立配置管理记录 SP1.2：执行配置审计5、度量分析（MA） SG1：安排度量与分析活动 SP1.1：建立度量目标 SP1.2：确定度量项 SP1.3：确定数据收集和存储流程 SP1.4：确定分析流程SG2：提供度量结果
CMMI过程域之：OPP组织过程性能
CMMI过程域之：OPP组织过程性能 2008-12-17 作者：人月神话来源：https://www.wendangku.net/doc/707449803.html, 过程性能是对遵循某各过程后所达到的实际结果的度量。注意过程性能的度量包括了两方面的内容，一方面是对过程的度量(工作量，评审效率，缺陷移除等),一方面是对产品质量的度量(故障数，缺陷密度)等。虽然过程性能包含了质量，单是为了强调质量在过程域里面我们常用的词仍然是质量和过程性能目标，该目标覆盖了产品质量，服务质量和过程性能。 组织预期的过程性能可以用来建立项目的过程性能目标，也是和项目过程性能实际数据进行比较的重要基准。这些信息是项目定量管理的基础，同时执行了定量管理的项目又为组织的过程性能基线提供改进数据。 一旦组织有了关键产品和过程特性的度量值、数据和相应的分析技术，就可以做以下工作： ?确定过程的行为是否一致，过程本身是否稳定（即可预测） ?识别各个过程实施小组之间按照一致的性质范围执行的那些过程 ?建立准则，识别某个过程或过程单元是否要实施统计管理 ?如果要进行统计管理，确定用于统计管理的度量项和统计方法工具 ?识别那些显示出无用的（例如零散的或不可预料的）行为的过程 ?识别组织的标准过程集合中可以加以改进的过程 ?识别那些可能是最佳惯例的过程实施 SG1建立性能基线(PPB)和模型(PPM)。建立并维护用于表征组织标准过程集合的预期过程性能的基线和模型。 ?SP1.1 选择过程 ?SP1.2 建立过程性能度量值
?SP1.3 建立质量和过程性能目标 ?SP1.4 建立过程性能基线 ?SP1.5 建立过程性能模型 组织的过程由一套标准过程组成，每个过程又包括相应的子过程和过程单元。这些过程不可能都实现定量管理，因此选择过程就是要根据业务目标和组织的过程改进目标来选择哪些过程和子过程要进行定量管理。 选择了过程后，就是要对过程的性能进行度量，需要选择那些能够很好的对过程性能进行评价的度量指标。度量值的选择标准是可用的，客观的，能够很好的反映和组织业务目标的关系，能够客观的评价过程的性能。基于以上考虑，可以采用目标问题矩阵这个方法来选择合适的度量值。最终选择的度量值要纳入组织的通用度量值集合。 注意OPP中建立质量和过程性能目标是组织级的，QPM中建立的质量和过程性能目标是考虑了项目本身的业务目标后得出的项目级的。注意了在OPP中的SP1.1和SP1.2会对可能需要定量管理的过程都列出来，给出每个过程的度量值和度量方法。SP1.3是建立组织过程性能目标，根据该目标再来分析对于组织级来讲哪些子过程是需要进行定量管理的。 组织的过程性能目标是以组织的业务目标和组织中项目的历史数据为依据制定的。性能目标包括了过程度量值和质量度量值两方面的内容。性能目标建立后还需要对目标进行优先级排序，当组织业务目标变更了还需要对组织性能目标进行相应的修改。 PPB和PPM的建立 过程性能基线是基于过程度量项或产品的度量项来定义组织级的一个基准，基准包括了均值和允许的上下限范围。比如缺陷密度组织级的过程性能基线是均值在8.3个/Kloc代码。下限是4.8个/Kloc代码，上限是11.8个/Kloc代码。过程性能模型是y=f(x1,x2,x3)，是指对应一个过程性能度量项，我们是通过其它过程或产品度量项来评价的，通过建立这种模型在x都已知的情况下我们就能够预测y的性能。四级量化管理的一个重点就是除了要求过程稳定外，还要求过程本身是可预测的。可预测这点就是通过建立过程性能模型PPM来实现的。 OPP过程的输入