下载文档原格式
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)一章：需求管理(Requirements Management)人是会死的，需求是会变的。
CMMI基本流程CMMI，即能力成熟度模型集成，是一种软件工程和系统工程过程改进的综合框架。
它提供了一套用于评估和改进组织开发和维护过程能力的最佳实践。
CMMI包含了一系列的指南和建议，以帮助组织建立可靠和高质量的软件和系统。
CMMI1级：初级级别，目标是确保项目能够按时交付，并满足基本的质量标准。
该级别的主要活动包括计划项目、跟踪项目进展、管理配置和管理需求。
CMMI2级：可重复级别，目标是确保项目能够清晰地定义过程，并对这些过程进行管理和执行。
该级别的主要活动包括定义过程、建立项目计划、进行项目监控和度量，以及对项目执行进行评估。
CMMI3级：已定义级别，目标是确保项目过程得到完整和规范的定义，并具有标准化的执行过程。
该级别的主要活动包括过程及工作产品定义、培训人员以执行过程、执行定期审核和度量，并根据结果进行改进。
CMMI4级：管理定量的项目过程级别，目标是确保项目开发过程能够获得可预测和可控制的结果。
该级别的主要活动包括进行定量的项目过程管理和度量，以及根据结果进行过程改进。
CMMI的基本流程是通过评估和改进过程来提高组织的能力水平。
评估可以帮助组织确定当前过程的存在的问题和不足之处，改进则是为了解决这些问题并提高过程的效率和质量。
评估过程包括以下步骤：1.制定评估计划：确定评估的目标、范围和方法，编制评估计划。
2.进行评估：根据计划，收集、分析和评估组织的过程和资源，以确定组织的能力水平。
3.识别问题和机遇：根据评估结果，识别存在的问题和不足之处，以及可能的改进机会。
改进过程包括以下步骤：1.制定改进计划：根据评估结果，制定改进计划，明确改进目标和实施步骤。
2.实施改进：根据计划，实施改进措施，对过程进行调整和完善。
3.跟踪进展：对改进措施的实施进行跟踪和监控，确保改进目标的实现。
4.评估效果：对改进措施的效果进行评估，根据结果进行调整和改进。
通过评估和改进，组织可以逐步提高过程能力，从而提高软件和系统的质量和可靠性。
cmm二级关键过程域sqa的实施大纲CMM（Capability Maturity Model）二级是针对软件开发过程质量管理的标准，其中包含了SQA（Software Quality Assurance，软件质量保证）的实施要求。
SQA是确定并确保软件开发过程满足质量标准的一系列活动，其目的是保证软件最终的可靠性和稳定性。
以下是CMM二级关键过程域SQA的实施大纲：1.计划管理。
SQA计划应当是软件开发过程中的第一步，其目的是根据CMM二级要求制定一份可靠的SQA计划。
SQA计划中应当包括SQA活动的详细描述、SQA计划执行的流程，以及SQA员工的职责和培训要求。
2.要求管理。
要求管理是SQA的重要部分之一、在这个过程中，SQA团队必须审查、审核和分析用户的软件需求，以保证这些需求的可靠性和一致性。
3.设计确认。
设计确认是SQA过程中验证开发团队是否已经将用户需求转化为可行的软件设计，确保软件设计符合标准、可行、可维护，并且符合用户需求。
4.代码审查和测试。
代码审查和测试是确保软件开发过程中代码的正确性和可靠性的重要部分。
测试应包括系统测试、集成测试和单元测试。
SQA过程中必须要定义好测试方案和测试计划，确保软件的稳定性和可靠性。
5.文档管理。
文档管理是SQA过程中的重要一环。
通过定义好的文档管理程序，可以确保开发团队在软件开发过程中能够编写完整和规范的文档。
6.配置管理。
配置管理是针对软件开发中的各个版本、程序和资源进行管理的过程，包括版本控制、变更管理、版本比较和配置管理等方面。
SQA需要定义好一种配置管理策略和程序，确保软件开发过程中的版本管理和变更管理的准确性和可靠性。
7.缺陷和分析管理。
缺陷和分析管理是SQA过程中非常重要的一环。
其目的在于通过对软件开发过程中的缺陷进行跟踪和分析，找出缺陷的源头、分析缺陷的类型和原因，以避免缺陷的再次出现。
以上就是CMM二级关键过程域SQA的实施大纲。
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)一章：需求管理(Requirements Management)人是会死的，需求是会变的。
CMM Level 2 实战（一）作者：刘文威宁传成现在关于CMM的文章不在少数，但基本上都是概念性、理论性的。
为了使大家对CMM有更通俗、更直观的理解，作者根据实施CMM 多年积累的经验，结合实际项目的管理及应用，提出了一套可行的CMM2实施方案，以期能为同行提供有价值的参考。
一、前言CMM(软件能力成熟度模型：Software Capability Maturity Model)，是由美国卡内基梅隆大学(CMU)的软件工程研究所(SEI)制定的一种软件评估标准，主要用于软件开发过程和软件开发能力的评估和改进。
此标准自1991年提出以来，已在美国、印度、日本、欧洲等地成功应用，并成为软件行业的工业标准。
尽管CMM引起了软件行业充分的重视，但如何将CMM应用到企业或项目管理中，大多数企业仍然毫无头绪。
其实实施CMM的最大障碍通常不是技术问题，而是工程和经验方面的管理问题以及企业文化问题，这一点对于中小软件企业尤其突出。
本文将从CMM2的六个KPA入手，根据作者实施CMM多年积累的经验，具体介绍CMM2的实践及应用。
二、CMM2实践CMM 2（可重复级）就是建立了基本的项目级管理过程，可对项目的成本、进度进行跟踪和控制，生产的过程、标准、工作产品以及服务都是被严格定义和文档化的。
基于以往管理类似的项目的经验，计划和管理新项目，并可依据一定的标准重复利用类似的软件产品。
CMM 2的核心就是重复利用。
CMM2由6个关键过程域(KPA)组成：需求管理(RM)、软件项目计划(SPP)、软件项目跟踪与监控(SPTO)、软件子合同管理(SSM)（本文略）、软件质量保证(SQA)、软件配置管理(SCM)。
需求管理(Requirement Management)需求管理的目的是为了在客户和处理客户需求的软件项目之间建立共识。
这是软件项目规划(SPP)和管理(SPTO)的基础，需求变更依赖于配置管理(SCM)的变更控制流程。
CMMI简介及CMMI2级的实施⽅案设计（DOC）CMMI简介及CMMI2级的实施⽅案设计第⼀部分 CMMI简介：CMMI 全称是Capability Maturity Model Integration,，即软件能⼒成熟度模型集成模型，是由美国国防部与卡内基-梅隆⼤学和美国国防⼯业协会共同开发和研制的。
CMMI （CMMI-SE/SW/IPPD）1.02 版本在部分国家和地区被SEI 开始推⼴和试⽤，主要应⽤于软件业项⽬，帮助提升对软件项⽬的管理能⼒。
随着模型本⾝的发展与应⽤的推⼴，CMMI 逐渐演变成为了⼀种被⼴泛采⽤的综合性模型。
在业界⼴泛使⽤的传统软件研发流程会带来⼀个严重的问题：存在于设计阶段的⼀个微⼩缺陷可能会直到后期的测试阶段才能被发现，⽽整个公司可能会花费数⼗倍甚⾄百倍的代价来改正这个缺陷。
为此，⼈⼒资源管理、软件采购、集成产品和过程开发、以及系统⼯程等等，多元化覆盖范围越来越⼴的能⼒成熟度模型应运⽽⽣。
1.1 CMMI 的作⽤软件能⼒成熟度集成模型（CMMI）经过长期积累和不断地优化，已经成功地发展并被认可为软件研发领域的标准过程体系，通过CMMI 可以增强企业核⼼竞争⼒、有效地提⾼软件企业产品质量，国内乃⾄国际上的⼴⼤软件⼚商都已经见证了CMMI 为企业带来的成功。
⽬前众多业界的软件企业纷纷试图使⽤CMMI 来达到过程改进的趋势，怎样才能将过程改进有效地实施，使其能实质地对软件研发过程起到优化效果，并带来⾏之有效地经济价值，已经逐渐成为了软件企业的决策者们最为关⼼的问题。
由最新SEI 评估报告中的数据显⽰，在进⾏了CMMI 的评估的企业中，⼤部分都是商业组织，并且其中近⼀半的企业⼈员规模都是在100 ⼈以下。
种种迹象均表明，CMMI 评估已经不仅仅吸引了⼤型IT 企业的注意⼒，同样存在⼤量的中⼩型企业也对此抱有浓厚的兴趣。
对软件企业来讲，CMMI 可以主要应⽤在两个地⽅：企业软件过程的改进和企业软件过程能⼒的评估。
CMMI是什么东西？CMMI英文全称是Capability Maturity Model Integration，直接翻译就是能力成熟度模型，直接看这几个中文字，你还是没有办法搞清楚CMMI是什么东西的。
大家可能在网上见过很多《成功人士的七个习惯》（可能还有很多类似的名字）的文章吧？有人总结了成功人士的成功的原因，总结出他们的习惯，如果我们也能具备这些习惯，那么我们也很可能成为成功人士。
类似的，CMMI可以看作是成功企业如何做好软件的一些习惯、做法、准则等的集合，是如何做好软件的最佳实践的集合。
如果企业也能按照CMMI的要求做好，那么企业就很可能成为成功的企业。
CMMI里面所有的要求，都是来自于成功企业的最佳实践的，她的先进性我们不必怀疑，如果我们没有做好，那不是CMMI本身的问题，而是我们自己没有理解好或者是没有执行好的原因。
说到CMMI，就不可避免会提到另外3个字母SEI，SEI全称是Software Engineering Institute 的全称，直译就是软件工程学院，是美国的一所大学，CMMI标准就是他们搞出来的。
CMMI目前最新版本是V1.2，如果你是现在才开始了解CMMI的，那么你完全没有必要去搞清楚V1.1与V1.2的差别，更加没有必要去比较CMM与CMMI的差别，直接了解CMMI V1.2就可以了，你只需要知道CMM是CMMI的前身，而CMMI V1.1虽然比CMM要新很多，但现在已经不用了。
现在在互联网上还有很多比较CMM与CMMI的文章的，除非你很想了解或者你有很多时间，建议不必去看这些内容。
连续式vs阶段式CMMI有两种表述方式：连续式与阶段式，两种方式只是从不同的角度来阐述CMMI，其实质上表达的内容是一致的。
就好像我们做数据库设计的时候，可能会设计不同的视图来查看相同数据表的数据，只是角度不一样。
大家可能会问，好好的CMMI，为什么要搞两种表达方式呢？不怕把大家搞糊涂吗？确实这两种方式把不少人给搞糊涂了，这是SEI的一个败笔。
CMMI的5个级别和25个过程域CMMI (Capability Maturity Model Integration)是一个结构化的过程改进方法，用于评估和提升组织的软件工程能力。
CMMI分为五个不同的成熟度级别，每个级别都有一组相关的过程域。
本文将详细介绍CMMI的五个级别和25个过程域。
1. 初始级别 (Level 1 - Initial)初始级别指的是一个组织在软件开发方面缺乏组织化和预测性的过程。
在这个级别上，软件开发过程通常是不可控制的，且无法重复使用。
这意味着项目结果无法预测和控制，导致成本和进度的不确定性。
2. 执行级别 (Level 2 - Managed)执行级别指的是一个组织开始建立和管理自己的软件开发过程。
在这个级别上，组织已经建立了一些基本的软件开发过程，并能够在不同的项目中重复使用这些过程。
然而，这些过程还没有得到完全的规范和标准化。
2.1 需求管理 (Requirements Management)需求管理是确保正确、一致和可追踪需求的过程。
它涉及定义、确认和维护需求，以确保项目能够满足用户的期望。
2.2 项目计划与监控 (Project Planning and Monitoring)项目计划与监控是制定和监控项目时间表、成本和资源的过程。
它确保项目能够按计划进行，并能够做出合适的调整以达到预期的目标。
2.3 供应商协商 (Supplier Agreement Management)供应商协商是与供应商建立和维护合作关系的过程。
它确保与供应商的交付和管理能够满足项目的需求。
2.4 产品质量保证 (Product Quality Assurance)产品质量保证是确保项目交付的产品符合质量标准和用户期望的过程。
它涉及质量计划、质量审查和质量度量等活动。
2.5 配置管理 (Configuration Management)配置管理是管理项目的配置项（包括软件、硬件和文档等）的过程。
组织标准过程
撰写时间：
撰写人（签字）：
审批人（签字）：
审批日期：
变更记录
修改点说明的内容有如下几种：创建、修改（+修改说明）、删除（+删除说明）
前言
组织标准过程是基于组织的基本过程（指导在组织中建立一个针对所有项目的公用的过程）的可操作的定义，是项目定义过程的基础。
其中包括所有项目公用的过程元素及其及这些过程元素间的关系（即体系结构）。
它保证组织过程活动的连续性，且是组合所用过程的测量和长期改进的依据。
根据公司所研发产品和开发项目特性的多样性，组织定义了组织标准过程的详细裁剪指南，以便于项目能够从自身特性出发。
确保在公司范围内开发活动的规范性、一致性，以提高开发过程的稳定性和能力成熟度。
目录
一、目的 (1)
二、适用范围 (1)
三、术语、缩写词 (1)
四、概述 (2)
五、组织标准过程 (3)
5.1组织标准过程全貌 (3)
5.2项目管理类、工程类对照 (4)
5.3过程管理类文档对照 (8)
5.4支持类文档对照 (4)
一、目的
组织标准过程是所有开发项目公用的过程，是项目过程定义的基础。
不仅保证了组织项目过程活动的连续性，也是组织过程测量和长期开发实践持续改进的依据。
二、二、适用范围
适用于组织内所有开发类项目。
三、三、术语、缩写词
CMMI：Capability Maturity Model Integration组织能力成熟度模型
PA：Process Area过程域
EPG：Engineer Process Group过程改进小组
OPD：Organizational Process Definition (process area)组织过程定义（过程域）OPF：Organizational Process Focus (process area)组织过程焦点（过程域）
OT：Organizational Training (process area)组织培训（过程域）
PP：Project Planning (process area)项目策划（过程域）
RD：Requirements Development (process area)需求开发（过程域）
REQM：Requirements Management (process area)需求管理（过程域）
RSK:Risk Management (process area)风险管理（过程域）
TS:Technical Solution (process area)技术解决方案（过程域）
VAL:Validation (process area)确认（过程域）
VER:Verification (process area)验证（过程域）
PI:Product Integration (process area)产品集成（过程域）
PMC:Project Monitoring and Control (process area)项目监督和控制（过程域）PPQA:Process and Product Quality Assurance (process area)过程和产品的质量保证（过程域）
IPM:Integrated Project Management (process area)集成项目管理（过程域）
DAR:Decision Analysis and Resolution (process area)决策分析与决定（过程域）CM:Configuration Management (process area)配置管理（过程域）
MA：Measurement and Analysis(process area)度量和分析（过程域）
四、四、概述
组织标准过程结合组织过程数据库、过程相关文档库、生命周期模型以及组织标准过程的裁剪指南，构成了组织过程财富库，作为项目用于开发、裁剪、管理和实施过程的基础。
本公司所使用的过程框架如下图所示：
图4-1组织过程资产库
说明：
1.框架的核心是“制定项目定义过程”，即项目经理针对其项目特点设计出合理又符合规
范的项目管理过程和软件开发过程；
2.“组织过程财富库”为项目经理定义其项目的过程提供了参照依据和可对比的相关数
据；
3.各种项目在实践中产生出新的度量数据、文档模板、经验，对组织过程财富又起到了积
累、改进、完善的作用。
五、组织标准过程
5.1. 组织标准过程全貌
结合组织现有项目开发过程的实际情况，并基于CMMI项目管理知识以及改进开发流程的需要，软件中心自定义组织标准过程如下图所示：
5.2. 组织管理过程文档对照
5.3. 支持过程文档对照
天津开发区先特网络系统有限公司第 4 页共 7 页
天津开发区先特网络系统有限公司第 5 页共 7 页
5.4. 项目管理过程文档对照
天津开发区先特网络系统有限公司第 6 页共 7 页
天津开发区先特网络系统有限公司第 7 页共 7 页
5.5. 工程过程文档对照
天津开发区先特网络系统有限公司第 8 页共 7 页
天津开发区先特网络系统有限公司第 9 页共 7 页。
