CMMI 复习总结

CMMI 复习总结
通用目标与通用实践
过程域
PPT 中问题整理

过程改进

过程的定义

IEEE: Sequence of steps performed for a given purpose
PALL: Logical organization of people, materials, energy, equipment, and procedures into work activities designed to produce a SP ecified end result
CMMI GLOSSARY: A set of interrelated activities, which transform inputs into outputs, to achieve a given purpose (These activities can be mapped to one or more practices in CMMI process areas to allow a model to be useful for process improvement and process appraisal.)

如上图所示，将这三个重要方面结合到一起的是组织中所使用的过程。

过程改进的好处

过程使您能够了解正在发生的事情。
通过定义，测量和控制过程，改进将更加成功和持久。
成功引入适当的技术，技巧和工具的可能性增加。
人们可以更加充分地发挥潜力，更加有效。

软件过程和生命周期模型的区别

软件过程和生命周期模型的区别

生命周期模型：一个软件产品或者系统要经历孕育、诞生、成熟、衰亡等阶段，一般称为软件生命周期（软件生存周期）。软件生命周期模型是指人们为开发更好的软件而归纳总结的软件生命周期的典型实践参考。

软件过程：为了实现一个或者多个事先定义的目标而建立起来的一组实践的集合。这组实践之间往往有一定的先后顺序，作为一个整体来实现事先定义的一个或者多个目标。一个软件过程既可以覆盖从需求到交付的完整生命周期, 也可以仅仅包括某些特定开发阶段。

区别：1、生命周期模型是对一个软件开发过程的人为划分.同样的软件开发过程, 因为目的不一样, 可能会被划分和命名成不同的生命周期模型。反过来，同样的生命周期模型，可能软件过程完全不同 2、生命周期模型是软件开发过程的主框架, 是对软件开发过程的一种粗粒度划分。3、生命周期模型中往往只定义管理实践，不包括技术实践

软件项目管理和软件过程管理在管理对象、实现目标和参考模型三个角度的区别

软件项目管理是应用方法、工具、技术以及人员能力来完成软件项目，实现项目目标的过程，其管理的对象是各类软件项目。实现目标：成本、质量、工期（管理三大要素：目标、状态、纠偏）。

参考模型：软件项目管理需要借鉴一些本领域或者其他领域的经验教训, 由此产生了一些用来描述这些经验和教训的概念, 例如软件过程、生命周期模型等。管理视角：成功是否可以复制。

软件过程管理：管理对象是软件过程，管理的目的是为了让软件过程在开发效率、质量等方面有着更好性能绩效.

参考模型：流水线设计管理。软件项目管理通常关注于一个项目，软件过程管理通常关注不止一个项目。软件项目管理（SCRUM,XP）类似于产品生产管理，软件过程管理（CMMI,SPICE）对应流水线的升级、建设、优化、维护、升级改造。软件过程管理参考模型 CMM/CMMI, SPICE 等软件过程改进参考模型 PDCA，IDEAL，软件过程管理与软件过程改进意思相近。

过程改进的底线

过程改进必须要服务于商业目标，不能为了改进而改进。
- 比如为了一张证书而改进就是为了改进而改进。
- 评估应该是改进的起点而不是终点。
过程改进对不同的企业或行业来说，含义是不一样的。
- 比如 Google 和 Microsoft 什么级别都没有，但是没有人会之一它们的研发能力。
- 在招标这种场景下，可以认为企业的能力是能够比较的。

连续式表示法与阶段式表示法

CMMI 支持两种使用级别的改进路径。一条路径使组织能够逐步改进其选定的单个过程域(或一组过程域)所对应的过程。另一条路径使组织能够以增量方式应对层次相继的过程域集合来改进相关的过程集。连续式表示法的关注点在于由能力等级度量的过程域能力，而阶段式表示法的关注点在于由成熟度级别度量的总体成熟度。

随着组织达成某一成熟度级别中一系列过程域的通用目标和特定目标，组织在提升组织级成熟度的同时也收获了过程改进带来的收益。由于每一成熟度级别都为下一级别打下必要的基础，因此，在成熟度级别上的跳级尝试往往会导致反效果。

同时，需要认识到的是，过程改进活动应该关注于以组织的业务环境为背景的组织需要上，并认识到更高的成熟度级别中的过程域可以应对组织或项目的当前的与未来的需要。例如虽然过程组并非成熟度级别 2 级组织的必要特征，但是它可以成为组织达成成熟度级别 2 级途径中的有用部分。

大多数组织对其所选的过程域，至少会选择能力等级 1 级作为目标，这要求达成所有选定过程域的特定目标。然而，将目标定于高于能力等级 1 级的组织会通过实施通用目标与通用实践，来专注于组织内所选过程的制度化。适用于每个过程域的通用目标也已预设完成。通用目标 2 适用于成熟度级别 2 级，通用目标 3 适用于成熟度级别 3 级到 5 级。

成熟度越高，返工的风险就越低，而不是业务的风险降低（所以“收益越大，风险越大”对此并不成立，这句话的对象是做什么事情，而不是做事的方式）。

等价阶段式定级

这张图的作用：一方面快速的知道每一个过程域的具体名称和缩写的对应。另一方面也能够帮助理解能力等级和成熟度等级的区别。

关于 CMMI 模型的一系列理解

能力成熟度模型(Capability Maturity Model，CMM)，包括 CMMI，都是对现实世界的简化表述，它涵盖了开发产品与服务的活动。CMMI 开发模型是一个参考模型，是实践的结构化集合，描述了有效过程的特征。CMMI 开发模型并不规定项目或组织必须遵循特定的过程顺序，或每天必须开发出一定数量的产品，或必须达成特定的绩效指标。模型所规定的是项目或组织应该具备应对开发相关实践的过程。项目或组织可将其过程映射至本模型中的过程域，以确定这些过程是否具备。

为什么要有标准过程

标准过程并不是教条主义，而是为了让项目小组更好地识别其他团队的优秀做法，促进共享。

如何使用过程模型

帮助设定过程改进目标和优先级; 帮助确保稳定，有能力且成熟的过程;作为改善项目和组织过程的指南;通过评估方法来诊断组织当前的实践状态

为什么过程模型很重要

过程模型提供一个开始改进的地方;社区先前经验的好处;共同的语言和共同的愿景;优先行动的框架

对 CMMI 模型的一些误解

CMMI 模型的有关误解:所谓 CMMI 模型，是指 CMMI 刻画了软件团队/组织从不成熟到成熟的每个阶段的特征——即所谓的路线图。与实际的开发模型没关系。这个路线图其实也是 CMMI 模型最为精华的部分，甚至都可以在很多其他的领域借鉴。

推论一: CMMI 模型需要适当裁剪以适应公司的实际情况

CMMI 模型不需要裁剪，模型本身仅仅刻画成熟度路线图上不同阶段的特征。大部分公司都不具备能力来裁剪这个模型，真要裁剪，也是应该由 CMMI 的模型的提出方和维护方 SEI 干。真正需要裁剪的是公司内部定义的组织级开发流程和开发规范，这个需要裁剪以适应具体的项目场景，与 CMMI 模型的裁剪是完全不同的概念。

推论二:CMMI 模型太重了，不适合互联网时代的轻量级开发

这个说法的错误之处在于，不一定是 CMMI 重或者轻，而是，CMMI 根本就不是开发模型

推论三:CMMI 模型只适合大公司,大项目，不适合小项目

首先没人检验过;其次，项目的大小衡量本身也缺乏值得信赖的参考依据;最后，接受这种说法的人还是把 CMMI 当成是一种特殊的开发模型

推论四:CMMI 模型只适合需求不变或者很少变化的场合，不适合需求不确定，变化很多的场合

CMMI 不是开发模型，与需求变化与否无关，谈不上适应或者不适应。

推论五:CMMI 是官僚、重文档的

CMMI评估方法获取证据有两种方法：验证式：提前准备好所有材料，评估团队根据材料看是否能支持实现目标；就评估团队而言，验证式更省时间（更多公司采用这种方式，导致了误解）发现式：事先不需要准备好证据，由评估团队在开发现场访谈、自己发现证据

推论六:CMMI 与敏捷是对立的

这种说法是错的。最根本的原因是 CMMI 不是开发过程，而大部分敏捷则是具体的开发过程。两者根本就是风马牛不相及的事物，不具备冲突的基础。所以不存在两者之间的权衡和借鉴。

那么 CMMI 和敏捷到底有没有差异呢？首先，前者不是开发过程，而后者是开发过程，这是最直接最根本的差异。其次，CMMI 存在所谓的标准化，不管是评估方法还是实施办法都有标准化的趋势。而敏捷往往拒绝标准(追求灵活)。再次，作用，即让不熟悉的第三方认可上有差异。尽管 CMMI 目前的现状不乐观，但是，毕竟这种方式提供了一些有价值的线索来了解某个软件组织的能力和成熟度的可能。而这一点敏捷过程还无法提供。有一种说法，CMMI 是主要是组织级过程，而敏捷是项目小组的过程。应该说这种说法有一定的问题，敏捷也可以是组织过程， CMMI 也可以只是关注在小组级别(2 级)。

推论七: CMMI 其不足是过于抽象

所有的模型都是抽象的，抽象恰恰是模型的本质特征之一。模型通过抽象来强化特征与目标之间的关系，这才能帮助我们理解其内在机理，指导具体实践。

关于 CMMI 模型的一系列知识点

CMMIv1.2分为哪三个集群

面向开发的CMMI(CMMI-DEV)

面向采购的CMMI(CMMI-ACQ)

面向服务的CMMI(CMMI-SVC)

CMMI来源于那三个模型，研究机构

软件工程 sw-cmm

系统工程 EIA/IS

集成化产品和过程开发 IPD-CMM

评估方法简述，评估三种类型、评估的主要依据、评估的结果

SCAMPI评估方法是用于过程改进的标准CMMI评估方法

SCAMPI评估方法有三种类型:

Class A:凡是按体系要求的项目都需要按体系要求做，评估的时候采取抽样评估；

Class B:评估试点项目与体系文档、CMMI模型的符合度；

Class C:评估完成的过程体系与CMMI模型的差距；

目标下的全部实践被全部实施或者被大部分实施，所有缺点不会影响目标的达成。

通用目标与通用实践

对制度化的理解

制度化是过程改进中的一个重要概念。当制度化在通用目标与通用实践的描述中被提及时，就意味着该过程已根植于工作的执行方式中，并且具有过程履行(即执行)的承诺与一致性。已制度化的过程在有压力的情况下更可能得到保持。

说人话就是“主动的、习惯成自然”。接下来引出通用目标和通用实践，这两个东西就是帮助制度化的工具。

对通用实践的理解

通用实践之所以被称为“通用”，是因为相同的实践适用于多个过程域。与通用目标相关联的通用实践描述了一些活动，这些活动被认为对通用目标的达成具有重要意义，并且有助于过程域所关联过程的制度化。通用实践是可以应用于所有过程域的组件。要将通用实践视为提醒。其目的在于提醒你正确地做事，属于期望的模型组件。

通用实践和过程域的关系

如果说通用目标与通用实践是直接应对过程在组织范围内制度化的模型组件，那么很多过程域则通过支持通用实践的实施来应对制度化。此类过程域含有一个或多个特定实践，当其被实施时，某一通用实践也能得到完全的实施，或产生工作产品用于某一通用实践的实施。

已执行、已管理、已定义之间的区别

已执行的过程是指完成了所需工作而满足过程域的特定目标的过程。

已执行与已管理之间的关键区别在于过程得到管理的程度。已管理的过程得到了计划(该计划可以是一份更全面的计划的一部分)，并且过程的执行依据计划得到了管理。当实际结果与执行情况显著偏离计划时，会采取纠正措施。已管理的过程能达成该计划的目标，并得到了制度化以实现执行上的一致。

已管理与已定义之间的关键区别在于过程描述、标准与规程的适用范围。对于已管理的过程，其过程描述、标准与规程适用于特定的项目、组或组织级功能。因此，同一组织内的两个项目，其已管理的过程可能并不相同。

另一项关键区别在于，相比已管理的过程，已定义的过程描述更为详细，执行更为严格。这一区别意味着改进信息更容易被理解、分析并使用。最后，已定义过程的管理建立在更为深入的理解之上，包括在过程活动的相互关系方面的理解，以及在过程、过程工作产品与过程服务的详细度量项方面的理解。

说人话就是已执行就是把工作做完了; 已管理在这个基础之上关注了管理的三大要素:时间、质量、成本; 而已定义则是各方面都更加熟练的管理，翻车几率更小

过程之间的关系

GG1 就相当于所有的 SG 的总和。

达成过程域的 GG1，就等于说你达成了该过程域的特定目标。

达成过程域的 GG2，就等于说你管理了与该过程域相关联的过程的执行。过程就如同任何项目或支持活动那样得到了计划与监督。

达成过程域的 GG3，就等于说存在组织级标准过程，能够对其进行裁剪(按标准原样执行也是一种裁剪)得到你将要使用的过程。

通用目标与通用实践

GG1 达成特定目标

过程域的特定目标得到过程的支持，过程的支持通过将可识别的输入工作产品转换为可识别的输出工作产品来实现。

通用实践	描述
GP 1.1 执行特定实践	执行过程域的特定实践，以开发工作产品并提供服务来达成过程域的特定目标。

GG2 制度化为已管理的过程

过程得到制度化为已管理的过程。

通用实践	描述
GP 2.1 建立组织级方针	建立并维护组织级方针，以计划并执行过程。
GP 2.2 计划过程	建立并维护计划，以执行过程。
GP 2.3 提供资源	提供充分的资源，以执行过程、开发工作产品并提供过程的服务。
GP 2.4 分派职责	分派职责与职权，以执行过程、开发工作产品并提供过程的服务。
GP 2.5 培训人员	必要时，培训过程的执行或支持人员。
GP 2.6 控制工作产品	将所选择的过程工作产品置于适当的控制级别。
GP 2.7 识别相关干系人，并使之参与	识别过程的相关干系人，并使之按计划参与。
GP 2.8 监督并控制过程	对照执行过程的计划，监督并控制过程，并采取适当的纠正措施。
GP 2.9 客观评价遵守程度	对照过程描述、标准与规程，对过程与所选工作产品的遵守程度进行客观评价，并处理不符合的情况。
GP 2.10 与上级管理层一起进行状态评审	与上级管理层一起对过程的活动、状态与结果进行评审，并解决问题。

GG3 制度化为已定义的过程

过程得到制度化为已定义的过程

通用实践	描述
GP 3.1 建立已定义的过程	建立并维护已定义过程的描述。
GP 3.2 收集与过程相关的经验	收集源于过程的计划与执行的、与过程相关的经验，以支持组织过程与过程资产未来的使用与改进。

说人话版本

GG 2
- GP 2.1 Establish an Organizational Policy
  - 比如一个项目是质量优先还是工期优先。
  - 比如组织级培训（Organizational Training）的 Policy 就可以是内部的讲师优先（内部的人员变成讲师）或者外部的讲师优先。
  - 定义了我们优先期望的是什么，在做一件事情的时候，按照一个指导思想去开展。
- GP 2.2 Plan the Process
  - 建立和维护一个实施过程的计划。
  - 有一个过程域是 Project Planning（这里的 Planning 是一个动词），那么这时 GP 2.2 应该怎么理解？
    - 简单来说就是“计划的计划”，直接解释就是为了策划整个项目而做一个计划。
    - 有必要吗？制定一个项目计划的大致步骤有：沟通需求、消化需求、估算、人员分配、开会讨论、计划评审等步骤，而这些步骤是无法短时间内一个人就能完成的，涉及到的人员有多个，所以是有必要制定一个计划来制定项目计划。
- GP 2.3 Provide Resources
- GP 2.4 Assign Responsibility
  - 角色或职责的分配。
  - 可以结合 GP 2.7 理解。在一个过程实施的过程中，一定是有不同的角色和不同的职责。
- GP 2.5 Train People
  - 对人员进行培训，让他们具有足够的技能来完成这样工作。
  - 对于组织级培训（OT）应该怎么理解？
    - 对培训人员进行培训是否有必要？有必要的，比如对讲师的培训可以包括怎样准备素材，怎样去把握节奏等内容。
- GP 2.6 Control Work Products
  - 什么是工作产物：比如开了一个周会，产生了一个报告，那么这个报告就是一个 Work Product。
  - 会议记录和需求文档的变更控制力度是不一样的。
  - 很像是进行配置管理，但是配置管理本身是一个过程域，那么对于配置管理，这个目标应该怎么理解？
    - 配置管理的工作产品有：配置计划、基线发布计划（不能随意更改）、变更请求、配置审计报告（保存即可）。这些工作产品也应该用不同的管控水平去进行管控。
- GP 2.8 Monitor and Control the Process
  - 呼应 GP 2.2。就是看一份计划的实施情况。
  - 但并不是所有的计划都是按照日程进行的，比如需求管理变更，我们没有办法知道需求变更会在什么时候提出。
  - 对于 PMC （项目监控）这个过程应该怎么理解？
    - 一个项目组往往会开周例会，例会往往会对进度进行一些监控等工作，但是开会这件事本身是需要监控的，防止开着开着就不开了。
    - 纠正偏差的措施不能只是停留在周会上，需要让他产生作用，也是需要进行监控的。
- GP 2.9 Objectively Evaluate Adherence
  - 确保大家按照流程和规范做事。
  - QA 相当于过程的警察。不制定规范，但是要执行规范。QA 的 QA 则是执法过程本身也是需要确保合法的。
- GP 2.10 Review Status with Higher Level Management
GG 3 已定义的过程
- GP 3.1 过程定义本身需要遵循一定的流程。
- GP 3.2 收集资料这个过程本身也有资料需要进行收集，需要明确定义。
如何应用 GP？
- GP/GG 对应的是“好坏”问题，即 Capability Level，而 SP/SG 对应的是“有无”的问题，即 Maturity Level。
- GP 和 GG 确保了 SP 和 SG 的可持续性。

过程域

过程域的定义

某个领域中的一系列相关实践，如果共同实施，则可以满足一系列目标，这些目标对于该领域的改进至关重要

过程管理类

理解上面这张图可以从 OPD 开始，首先 OPD的目的和作用是帮助我们正确理解 CMMI。它不是开发方法，而是建立组织级开发流程，用来指导每个项目组开发。简单来说就是在进行了一段时间的软件开发之后，发现了实践过程中可以改进的地方，OPD 可以根据这些建议为自己这个组织定义了新的过程。

而这些建议也会被 OPF 所获得，而 OPF 的执行过程中比较直观地（不够客观度量）总计了当下过程的优缺点，并且计划、实施并部署了这些改进。给了 OPD 更多的信息。同时 OPD 还综合考虑了业务目标进行新的定义。在有了新的过程之后，必须通过 OT，也就是培训来让相关技术人员掌握新的过程。所有这上面的过程域都是针对过程本身的，最重要的目的就是希望整个组织在一次次项目过程中不断改进自己的过程实践。而因为这些过程域都只是3级的，相对而言比较粗糙、不够客观。

理解上面这张图首先从搞清楚名词开始。 OPP 组织级过程性能: 结合术语表和过程域自身的描述，过程性能实际上是完成了这个过程之后，某些组织、客户所关心的属性达成了什么样的指标，例如工作量、周期、缺陷排除有效性，OPP关心的是一个结果。而它的一系列的子实践就是在选定我关心什么、怎么度量我所关心的东西、我需要其他过程域至少给我提供哪些东西（基线）、使用什么模型来计算。值得注意的是 OPP 中所用的方法都是量化的方法，这是它和之前低级的过程域的一个显著区别。

显然，如果只有一个目标是无法实现的，因此，OPP 需要和 OPM 配合。

OPM 组织级绩效管理: 绩效的含义是项目在项目计划执行方面的达成情况，包括工作量、成本、进度以及技术性能。简单来说，OPM 的作用就是来主动监管 OPP 以及其他过程域中的目标是否被完成，没有完成就试图找到办法去弥补。OPM是一个5级的过程域，其实和 OPF 是一回事，所以我们通常说OPM是一个增强版本的 OPF，体现在管理从定性到定量。

Lv3组织级过程定义(OPD)

目的: 建立并维护一套可用的组织级过程资产、工作环境标准以及团队规则与指南。

概要

SG 1 建立组织级过程资产

SP 1.1 建立标准过程

SP 1.2 建立生命周期模型描述

不同客户不同场景下用什么生命周期模型

SP 1.3 建立裁剪准则与指南

防止乱用

SP 1.4 建立组织的度量库

SP 1.5 建立组织的过程资产库

保存通用的度量项和数据，用来支持其他过程，见p163

SP 1.6 建立工作环境标准

SP 1.7 建立团队的规则与指南

Lv3组织级过程关注(OPF)

目的: 基于对组织过程与过程资产当前的强项与弱项的透彻理解，计划、实施并部署组织级过程改进。

概要

SG 1 确定过程改进机会

SP 1.1 建立组织级过程需要

对过程改进提出需求，希望做到什么地步，也就有了强弱的概念

SP 1.2 评估组织的过程

SP 1.3 识别组织的过程改进

看哪些过程可以改进，排优先级，然后文档化

SG 2 计划并实施过程行动

SP 2.1 建立过程行动计划

计划怎么改

SP 2.2 实施过程行动计划

前期工作 + 试点

SG 3 部署组织级过程资产并纳入经验

SP 3.1 部署组织级过程资产

比如规格约定了sonarqube能用，必须用，3.1就是部署sonarqube，让它真正能使用

SP 3.2 部署标准过程

相当于定期git pull进行版本更新，把新的经验和教训再应用到项目中

SP 3.3 监督实施

SP 3.4 将经验纳入到组织级过程资产中

Lv3组织级培训(OT)

目的: 发展人员的技能与知识，使其能够有效且高效地执行他们的角色。

概要

SG 1 建立组织级培训能力

SP 1.1 建立战略培训需要 (组织未来二至五年内有什么大的计划，因此需要什么人才)

SP 1.2 确定哪些培训需要属于组织的职责

SP 1.3 建立组织级培训的战术计划 (做计划)

SP 1.4 建立培训能力 (找老师，找资料)

SG 2 提供培训

SP 2.1 交付培训

SP 2.2 建立培训记录

SP 2.3 评估培训的有效性

Lv4组织级过程性能(OPP)

目的: 建立并维护对组织标准过程集中所选定过程性能的量化理解，以支持达成质量与过程性能目标，并提供过程性能数据、基线与模型，以量化管理组织的项目。

概要

SG 1 建立性能基线与模型

SP 1.1 建立质量与过程性能目标

度量过程之后的目的，希望为业务目标做什么贡献

SP 1.2 选择过程

哪些过程适合度量

SP 1.3 建立过程性能度量项

被选择的过程中哪些属性会影响目标的实现

SP 1.4 分析过程性能并建立过程性能基线

分析这些属性，设立一个期待达成的目标

SP 1.5 建立过程性能模型

建模，根据以前的、现在的数据预测能否达成这个目标

x.y.z代表着什么

首先 x.y.z 这样的目标表示主要出现在4-5级的过程域中，因为只有到这个级别的过程域才会量化的考虑目标。

z通常用来表示整个项目的目标，比如最终上线的时候每一千行缺陷不超过一个
要做到z这个目标那么就需要把之前的上游的一些东西管控起来比如单元测试的质量，这就是y
但是单元测试是没办法管控的，所以依赖于更底层的x，例如对人员的技能有要求

理解 OPP 的目的

以下为原文
基于项目与组织的需要，可以适当在组织的不同级别，包括个别项目或相关项目的组合，进行数据的收集和分析并进行过程性能基线和模型的创建。
期望的过程性能可用于建立项目的质量与过程性能目标，并且可用于实际项目绩效的比较基线，这个信息可以用来量化的管理项目。
过程性能模型用来表示过去和当前的过程性能，并且用来预测过程将来的结果。

Lv5组织级绩效管理(OPM)

目的: 主动地管理组织的绩效以满足其业务目标。

概要

SG 1 管理业务绩效

SP 1.1 维护业务目标 (看看实际效果和目标是否一致，不一致可能需要改变目标)

SP 1.2 分析过程性能数据

SP 1.3 识别潜在改进领域

SG 2 选择改进

SP 2.1 挖掘所建议的改进

SP 2.2 分析所建议的改进

SP 2.3 确认改进

SP 2.4 选择并实施将要部署的改进

SG 3 部署改进

SP 3.1 计划部署

SP 3.2 管理部署

SP 3.3 评价改进效果

项目管理类

要理解这部分最好先看工程类和支持类过程域都有哪些东西。从 PP 讲起， PP 主要是和工程类的进行交互，例如 RD ，首先知道需要客户想要什么，然后 PP 会告诉工程类的过程域让他们做什么，告诉支持类的需要什么样的度量，告诉 PMC 需要监督什么。

接着是 PMC，PMC 从 MA 和 PPQA 那里拿到了真实的过程执行状态和评价，它会根据这个结果来进行纠偏。这个纠偏包括了项目内部的(反馈给工程类过程域)，也包括了对供方的纠偏。

这里的供方举例比较好理解，例如项目开发需要 IDE，需要购买服务器测试，而这些服务、产品的提供者就是供方，SAM 可能在大项目大组织中比较重要，在小规模的时候作用似乎不明显。

REQM 的存在是为了保护程序员的身心健康，虽然说敏捷中是拥抱变化的，但其实没有人真的愿意一直面对不停变更的需求。

从前面低等级的过程域里可以看到一个项目已经基本被管理起来了，内部是比较协调的。但是除了内部的不稳定因素，项目外也伴随巨大的风险，比如客户的需求变更。因此 RSKM 提出了进一步的需求（3级建立在2级基础之上，前面过程域2级居多）。RSKM 是比较有预见性的，结合敏捷里学过的知识，很多实践其实也和敏捷有关，例如让客户陪你一起受苦，尽早把原型做出来给他们看。

但是风险管理这件事情也不能随便就制定下来，它还需要其他的过程域的一些支持，例如 IPM。

IPM 应用的范围是一个项目，它其实使用了 OPD 的产出。OPD 的产出是一个组织级的标准过程的集合，也是从CMMI标准中筛选出适合自身组织的内容的。而 IPM 就是在这个基础之上把这些过程具体在某个项目上进行运用。这样做的好处是同一个组织内项目之间的差异性会被降低。各项目可以比较容易的分享经验和教训，以及发现的风险和一些好的数据。IPM 是 RSKM 的一个输入。IPM 这个过程域的执行也会同时反馈出一些经验、产出一些数据给其他的过程域，处于一个比较中心的位置。

而随着成熟度的进一步提高，QPM 能够通过量化的方式优化 IPM 所做的事情，例如图中可以看到的“风险暴露值”。QPM 的实现也能让 IPM 的输入来源更多，这意味着得到的结果可以更加精准。

Lv2项目监督与控制(PMC)

目的: 提供对项目进展的了解，以便在项目绩效显著偏离计划时可采取适当的纠正措施。

概要

SG 1 对照计划监督项目

SP 1.1 监督项目计划参数

SP 1.2 监督承诺

SP 1.3 监督项目风险

SP 1.4 监督数据管理

SP 1.5 监督干系人的参与

SP 1.6 进行进展评审

SP 1.7 进行里程碑评审

SG 2 管理纠正措施直至关闭

SP 2.1 分析问题

SP 2.2 采取纠正措施

SP 2.3 管理纠正措施

项目监控点选择的原则？原因

A.重要的里程碑       
原因:项目阶段重要的完成标志，通过才能证明这一阶段任务完成，才能满足干系人的期望
B. 时间间隔比较合理  
原因:假如时间太长不能在合适的时期对偏差进行纠偏行动，会延误项目进展，时间太短不起作用，没法监控到项目的具体指标

SG2中的相关实践约定，需要采取纠偏措施的问题来源

来自于项目监控过程域，PPQA收集问题:项目监控、验证、确认；项目监控过程域中的问题列表管理

纠偏行动的先决条件

有偏离问题列表，在偏差界限达到15%或20%时，进行纠正

管理的三要素
目标、状态、纠偏

Lv2项目计划(PP)

目的: 建立并维护定义项目活动的计划。

概要

SG 1 建立估算

SP 1.1 估算项目范围

SP 1.2 建立对工作产品与任务属性的估算

SP 1.3 定义项目生命周期阶段

SP 1.4 估算工作量与成本

SG 2 制订项目计划

SP 2.1 建立预算与进度

SP 2.2 识别项目风险

SP 2.3 计划数据管理

SP 2.4 计划项目资源

SP 2.5 计划所需的知识与技能

SP 2.6 计划干系人的参与

SP 2.7 建立项目计划

SG 3 获得对计划的承诺

SP 3.1 评审影响项目的各项计划

SP 3.2 协调工作与资源水平

SP 3.3 获得对计划的承诺

PP过程域在项目中的作用域

项目启动阶段后开始，一直到验收阶段开始一段时间到管理收尾

计划制定的原则？

产品计划的制订是由上往下制订，由下往上修改的过程

一般的估算方法有哪几个？区别

1)Delphi(德尔菲)估计，PERT Sizing 估算
2)区别:Delphi适用于项目资金多的时候，项目前期做估计(大项目)
PERT Sizing适用于时间短，资金少的时候，适用于后期比较明朗，紧迫的项目或项目中后期的重估计的时候(小项目)
两种方法比较:PERT Sizing估算花的时间短，资金用的少，精确度不高。Delphi成本高，时间长，精确度高。

什么是承诺管理？承诺的分类

承诺管理是对干系人承诺进行管理、保证，并兑现干系人的承诺。分为3类:结盟和协议、促进合作、允许变更

PP中“建立”和“维护”两个活动的解释？

建立:把项目文档写好并发布出去
维护:项目实施过程中，发现项目的进展和计划发生偏差的时候进行调整

估算目标: 不是尽可能客观描述代码行/工作量（永远不可能实现估算），而是得到一个数字数字对不对不重要，重要的是大家认可

Lv2需求管理(REQM)

目的: 管理项目的产品与产品组件需求，并确保那些需求与项目计划和工作产品间的协调一致。

概要

SG 1 管理需求

SP 1.1 理解需求

SP 1.2 获得对需求的承诺

SP 1.3 管理需求变更

SP 1.4 维护需求的双向可追溯性

SP 1.5 确保项目工作与需求间的协调一致

(需求跟踪的方法) 需求跟踪矩阵的使用

是需求跟踪矩阵的一个规程。在改写相关的产品的时候，相关的工作产品也要跟着去改。(比如:现在我在写代码，要去改设计文件，相关的产品设计文档和代码都需要修改。)

(获得需求承诺) 应该获得那些人的承诺

需求相关干系人:项目组内部:项目经理，需求分析师，设计人员，企业高层; 外部:供应商，客户

识别需求不一致性的最有效方法
需求评审
敏捷对于需求的态度是拥抱变更，但这是不正确的，大部分开发人员还是希望能够close开发
Scrum对于需求的态度是不响应一个SP rint中的需求变更(目标不变)，只是记录到backlog，可能会在下一个迭代响应变更

理解双向可跟踪

双向可追踪关注的是需求之间的关系。术语表上的定义是“两个或更多逻辑实体间可从任一方向（即至某一实体或自某一实体）认识的关联”，这里的两个实体指的是高层次的需求和低层次的需求。
这两种需求往往是多对多的关系，但是在有频繁变更的时候，管理的代价比较高昂。例如一个需求变化了，会导致其他和他相关的需求、设计、代码等等都会发生变化。

一个比较极端的做法是以文档作为最小的颗粒度，一对一的去联系这两个实体，这么做虽然管理代价变低，但是每个需求变更的影响评估也就没有办法实施了。

因此在实际中的做法是在一个比较小粒度的层次上（例如功能点）找到一个平衡，在这个层次上去做双向可跟踪。

先做计划还是先做需求

应该先做计划，再做需求。可以先大致的讨论需求的范围得到一个初步的需求，当大家认为到了可以进行估算的程度时，就开始进行计划。

Lv2供方协议管理(SAM)

目的: 管理从供方采购产品与服务的活动。

概要

SG 1 建立供方协议

SP 1.1 确定采购类型

SP 1.2 选择供方

SP 1.3 建立供方协议

SG 2 履行供方协议

SP 2.1 执行供方协议

SP 2.2 接受采购的产品

SP 2.3 确保产品移交

Lv3风险管理(RSKM)

目的: 在项目潜在的问题发生前对其进行识别，以便在整个产品或项目生命期中，计划并在需要时启动风险的处理行动，从而降低这些潜在问题对达成目标产生的不利影响。

概要

SG 1 准备风险管理

SP 1.1 确定风险来源与类别

SP 1.2 定义风险参数

SP 1.3 建立风险管理策略

SG 2 识别并分析风险

SP 2.1 识别风险

SP 2.2 评价、分类风险并划分风险优先级

SG 3 缓解风险

SP 3.1 制订风险缓解计划

SP 3.2 实施风险缓解计划

风险参数包括

风险的可能性
风险发生时的影响和其严重性
触发管理活动的阈值

Lv3集成项目管理(IPM)

目的: 从组织的标准过程集中裁剪得到集成的已定义过程，并以此为依据建立并管理项目以及相关干系人的参与。

概要

SG 1 使用项目已定义的过程

SP 1.1 建立项目已定义的过程

根据组织里的规定，把组织需要的过程应用在某个项目上

SP 1.2 使用组织级过程资产计划项目活动

按组织统一规定的文档要求、度量要求来估算项目

SP 1.3 建立项目工作环境

让工具、人员都到位，满足规定的开发要求

SP 1.4 集成各类计划

SP 1.5 使用集成的计划管理项目

根据和计划规定完成相关过程，做该做的事并好好做

SP 1.6 建立团队

SP 1.7 为组织级过程资产做出贡献

好的坏的经验都上报组织

SG 2 与相关干系人协调并协作

SP 2.1 管理干系人的参与

SP 2.2 管理依赖

SP 2.3 解决协调问题

Lv4量化项目管理(QPM)

目的: 量化地管理项目，以达成项目已建立的质量与过程性能目标。

概要

SG 1 准备量化管理

SP 1.1 建立项目的目标

SP 1.2 组成已定义的过程

SP 1.3 选择子过程与属性

SP 1.4 选择度量项与分析技术

SG 2 量化地管理项目

SP 2.1 监督所选定子过程的性能

SP 2.2 管理项目绩效

SP 2.3 执行根本原因分析

OPP 和 QPM 的关联

QPM 确保了 OPP 建立的基线能够被完成（OPP是一个组织的要求，QPM面对的是一个项目）
QPM 通过使用 OPP 建立用于实现高成熟度的组织级过程资产，包括质量与过程性能目标、所选过程、度量项、基线和模型。
并且使用这些东西来量化的管理（一个项目内的）过程。
QPM 可以根据项目的特点来对这些目标进行调整。

QPM SP1.2 和之前过程定义的区别（和 IPM 的区别）

Lv2 Lv3的过程域主要定义的是步骤，而 QPM 中需要用到一些统计的量化的手段来定义这个过程。
这些手段用来告诉执行者需要做到什么程度。
QPM 通过为项目评价备选过程或子过程， 并选择那些最可能达成质量与性能目标的过程或子过程

QPM 和 OPM 的关系

简单的从成熟度级别上看，QPM 是4级，而 OPM 是5级，说明至少 OPM 一定程度上依赖 QPM。QPM 关注的是项目，而 OPM 关注的是组织，显然后者的范围更大。
文档中的描述“本过程域适用于管理项目。应用这些概念来管理其他组与职能有助于将组织绩效的不同方面关联起来，从而提供一个基础，来平衡并协调存在竞争的优先级关系，以应对更广泛的业务目标集合。” 

说人话就是把组织的每个项目都量化管理好了，那么也就有可能在组织的层面把量化管理能力提高上去，达成 OPM 的目标。

理解QPM

量化管理的一个基本要素是对预测有信心，即能够准确的预测项目在多大程度上满足质量和过程性能目标的能力。
另一个基本要素是理解在过程性能中遇到的偏差本质和程度，并且察觉项目的实际绩效何时可能不足以达成项目的质量与过程性能目标。

工程类

工程类的非常好理解，就是日常开发所经历的流程，这里不赘述了。

Lv3需求开发 (RD)

目的: 挖掘、分析并建立客户需求、产品需求与产品组件需求。

概要

SG 1 开发客户需求

SP 1.1 挖掘需要

SP 1.2 将干系人的需要转换为客户需求

SG 2 开发产品需求

SP 2.1 建立产品与产品组件需求

SP 2.2 分配产品组件需求

SP 2.3 识别接口需求

SG 3 分析并确认需求

SP 3.1 建立操作概念与场景

SP 3.2 建立必需的功能与质量属性的定义

SP 3.3 分析需求

SP 3.4 分析需求以达到平衡

SP 3.5 确认需求

Lv3技术解决方案(TS)

目的: 选择、设计并实现对需求的解决方案。解决方案、设计与实现包括单独的或以适当形式组合的产品、产品组件以及与产品相关的生命周期过程。

概要

SG 1 选择产品组件解决方案

SP 1.1 开发备选解决方案与选择准则

SP 1.2 选择产品组件解决方案

SG 2 开发设计

SP 2.1 设计产品或产品组件

SP 2.2 建立技术数据包

SP 2.3 使用准则设计接口

SP 2.4 执行自制、购买或复用分析

SG 3 实现产品设计

SP 3.1 实现设计

SP 3.2 开发产品支持文档

DAR 和 TS 的关联和区别

TS 与 DAR 的区别：TS 要求进行技术方案的选择，其实际就是一个 DAR 的过程，从这点上来看两者是一致的，但是 DAR 的范围更加广阔，不仅仅局限于技术方面，比如说版本发布，过程推行等都可以考虑使用 DAR。

DAR 的适用场景

DAR 建立一个 Guildline 来指明什么场景下需要 DAR，什么场景下不需要。不是所有的活动都要走 DAR 的过程。

Lv3产品集成(PI)

目的: 将产品组件装配成产品，确保产品作为一个整体正确地运行，即具有所要求的功能与质量属性，并交付产品。(不只是集成测试，PI 也包括了交付的步骤)

概要

SG 1 准备产品集成

SP 1.1 建立集成策略 (怎么集成、怎么评价集成结果)

SP 1.2 建立产品集成环境

SP 1.3 建立产品集成规程与准则 (SP1.1 的细节内容，例如单元测试)

SG 2 确保接口兼容性

SP 2.1 评审接口描述的完整性

SP 2.2 管理接口

SG 3 装配产品组件并交付产品

SP 3.1 确定需集成的产品组件准备就绪

SP 3.2 装配产品组件

SP 3.3 评价装配后的产品组件

SP 3.4 打包并交付产品或产品组件

假设你是产品集成的负责人，拒绝那些不合格的产品组件。定义哪些验收标准

1. 确保产品组件已经进入配置库里面
2. 待集成的产品组件必须经过单元测试（部分集成测试），提供测试报告
3. 完整的接口描述文档
4. 和生命周期有关的过程证据（质量角度考虑）例如评审报告、QA检查报告

Lv3确认(VAL)

目的: 证明产品或产品组件被置于预期环境中时满足其预期用途。

概要

SG 1 准备确认

SP 1.1 选择需要确认的产品

SP 1.2 建立确认环境

SP 1.3 建立确认规程与准则

SG 2 确认产品或产品组件

SP 2.1 执行确认

SP 2.2 分析确认结果

Lv3验证 (VER)

目的: 确保选定的工作产品满足其规定的需求。

概要

SG 1 准备验证

SP 1.1 选择需要验证的工作产品

SP 1.2 建立验证环境

SP 1.3 建立验证规程与准则

SG 2 执行同级评审

SP 2.1 准备同级评审

SP 2.2 进行同级评审

SP 2.3 分析同级评审数据

SG 3 验证选定的工作产品

SP 3.1 执行验证

SP 3.2 分析验证结果

VAL 和 VER的关键区别

VER 选择的是工作产品，即过程中自然的产物，VER 确定工作产品适当地反映了其规定的需求。而 VAL 选择的是产品。VAL 确定提供的（或将要提供的）产品或服务将满足其预期的用途解决方案，关注是否真的帮客户解决问题。

另外：产品一定是工作产品，工作产品不一定是产品；交付给用户的才是产品；在不同场景中，交付给用户的产品可能不同

支持类

支持类的普遍比较好理解，MA 为所有的东西规定了度量和分析的准则，是高成熟度过程域量化的前提。PPQA 则是提供了对过程执行的客观评价和度量，提供了改进的建议和基础。是后续OPD OPF 等过程域的基础。而 CM 管理了配置项的变动，让复杂的过程执行得到控制，不会因为版本或不一致的问题带来巨大的灾难，保证了其他过程域的正常执行。

CAR 是5级成熟度的过程域，它建立在其他所有的过程域都能够良好执行的基础上。CAR 其实贯穿于组织和项目的始终，只是在不同成熟度的时候它的能力也有所不同。具体来说就是从只能排除具体原因到排除真正根源上的原因，它为组织的过程改进提供了方向和思路。而 DAR 是一个3级成熟度过程域，3 级是一个比较有特点的级别，在它之前是已管理，也就是说不管做的怎么样，反正先把项目做出来。而 3 级要求已定义，则是建立各种规章制度。比如 DAR 解决的问题就是到底该如何做决定，整个组织是遵循同一个标准做决策的。最直接的体现就是后续高成熟度的过程域都是带有预见性质的，也就是说需要在某些时刻作出正确且一致认可的决定。

Lv2度量与分析(MA)

目的: 开发并保持用于支持管理信息需要的度量能力。

概要

SG 1 使度量与分析活动协调一致

SP 1.1 建立度量目标

确定为什么要做度量，意义是什么，能帮助做什么决策。一般这个是为了满足组织和项目的业务目标而服务的

SP 1.2 明确说明度量项

需要度量哪些东西

SP 1.3 明确说明数据收集与存储的规程

SP 1.4 明确说明分析规程

SG 2 提供度量结果

SP 2.1 获得度量数据

SP 2.2 分析度量数据

SP 2.3 存储数据与结果

SP 2.4 沟通结果

反馈结果并让他们理解结果

度量分析的作用体现在哪些方面？(从项目和组织两个角度分析)

项目组:提供了信息，为管理者提供决策信息，(告诉管理者项目所处在什么阶段，将来应该进行相应的项目管理决策。)
组织:为组织及过程改进，提供决策信息。(要知道组织过程处于什么阶段，将来的改进方向)

MA 和 PMC 的区别

MA 中的度量信息类型可以包括进度、进展、工作量、规模、稳定性和质量。
MA 针对的是状态而不是进度，与 PMC 有区别，目的是帮助我们了解目标的状态与实际的状态之间的差异。
PMC 进行的是纠偏，而 MA 可以识别度量目标预期的行为变化，作为实施度量与分析活动的结果。

下面这些题目应该是往年的资料，不一定是CMMI1.3的内容，至少我没有在文档中和ppt中找到相关的描述，请自行斟酌

度量的目的要支持质量的目标

与产品质量有关:测试覆盖率、缺陷数量；一次性测试通过率；关键重要特性合格率；
与成本有关:开发成本、维护成本、管理成本、现场服务时间；
与产品交付有关:准时交付率；交付完整性、产品错发次数；延期交付率；一次准时交付率；
与客户有关:顾客满意率；客户投诉次数；处理投诉时间；
与人员及设备有关:员工满意率；设备利用率；设备完好率；设备故障率；培训效果；

如何满足度量的可追踪性(哪些工作产品可以满足)
用度量数据库，例如项目度量表

Lv2配置管理(CM)

目的: 使用配置识别、配置控制、配置状态记录与报告以及配置审计(也就是配置管理的四项主要工作)，来建立并维护工作产品的完整性。

概要

SG 1 建立基线

SP 1.1 识别配置项

识别哪些是需要被管理起来的东西

SP 1.2 建立配置管理系统

例如对代码用git，例如对变更请求本身也创建数据库

SP 1.3 创建或发布基线

在某个时间点，赋予特定版本的工作产品的集合一个标识符

SG 2 跟踪并控制变更

SP 2.1 跟踪变更请求

分析并评估这些请求，一直关注这些请求直到处理结束

SP 2.2 控制配置项

有了请求的变更之后，配置项也会有变化，基线也可能会发生变化。控制和跟踪这些变化

SG 3 建立完整性

SP 3.1 建立配置管理记录

把 2.1 2.2 的过程文档化并及时更新

SP 3.2 执行配置审计

确保配置符合需求并且这些信息是准确完备一致的

一个软件开发过程中会产生很多工作产品artifacts/work product，但是并不是所有产品都是值得管理的，要去掉一些不那么重要的产品，确保重要的（为了让交付有完整性的）工作产品被管理。其实就是为了减少工作量。而除了管理项目的配置，该过程域也适用于组织级的工作产品，如标准、规程和其他的一些资源的配置管理。

因为往届的资料里有大量的关于CCB的问题，但是CMMI1.3文档中只是提到了几句，这里特别整理一下

CCB

根据wiki 上面的定义: Change Control Board (CCB) is a committee that consists of Subject Matter Experts (SME, e.g. software engineers, testing experts, etc.) and Managers (e.g. Quality Assurance managers), who decide whether to implement proposed changes to a project.

简单来说 CCB 就是一群有权利控制变更的人。
人员:项目经理，配置管理员，质量保证人员，开发人员代表，客户代表
性质:为了控制项目基线的变更进行审批授权的临时性质的组织。

他们的职责:
确保变更被分类以及被评估
评审和批准变更
解决关于变更请求的争议
做出关于变更的最终决策
决定需要实施的变更的优先级
确保只有被批准的变更得到实施

配置管理员的主要职责

制定配置管理计划；
识别配置项；
定义基线；
定义配置库结构；
管理、备份配置库；
控制变更；
生成配置管理状态报告；
对项目成员进行配置管理培训

配置项标示的规则，什么情况下改写Vx.y.z中的x和y？什么说情况下改写z？规则是怎样的

级别不同，修改不同。处于开发阶段只能改z，如果过了评审则由配置管理员改x，y。如果是比较小的变更处在一条基线上的话只改y，如果进行大规模的变更的话改x

配置管理系统的等级？三个概念库如何体现配置库的等级？配置库需要注意什么

通过对不同库的配置项设置不同权限体现
三个概念库:开发库，基线库，产品库。
开发库:由项目组内部人员进行控制，可以随意的根据自己的需要进行修改，不需要变更申请。
基线库:由项目的配置人员进行变更，要通过变更控制流程进行修改。
产品库:由公司的配置管理员进行修改，发布的必须由公司的配置管理员进行发布。

注意点：
配置库应该包括采购的组件
配置库中只需要保存关键性版本不需要全部版本保存

基线的定义和特点

经过正式评审并取得共识的规格说明与工作产品的集合，该集 合成为之后进一步开发的基础，并且只能通过变更控制规程才 能进行变更。

Lv2过程与产品质量保证(PPQA)

目的: 向员工与管理层提供对过程及其相关工作产品的客观洞察。

概要

SG 1 客观评价过程与工作产品

SP 1.1 客观评价过程

SP 1.2 客观评价工作产品

SG 2 提供客观洞察

SP 2.1 沟通并解决不符合问题

SP 2.2 建立记录

软件项目质量的分类

内部、外部、使用质量，过程和产品，但绝不是绝对的过程和绝对的产品，过程质量影响产品质量，产品质量取决于过程质量，互相影响。

QA行使的角色

三类:警察、医生和老师 简要说明QA工作在项目全过程的三种角色体现
老师的角色在项目前期，QA辅助项目经理制定项目计划，包括根据质量体系中的标准过程裁剪得到项目定义的过程，帮助项目进行估算，设定质量目标等；对项目成员进行过程和规范的培训以及在过程中进行指导等。
警察的角色在项目过程中，QA有选择性地参加项目的技术评审，定期对项目的工作产品和过程进行审计和评审。
医生的角色在项目过程中，QA也可以承担收集、统计、分析度量数据的工作，用于支持管理决策。

关注的是产品的质量吗？QA并不对最终产品的质量负责，除非质量出现问题的原因来自流程和方法。QA 只关注方法流程是否正确，并不关注测试。QA 不应是测试人员，但是许多企业都把 QA 当作测试人员。

解释 PPQA QA SQA NC QC OE

PPQA:产品过程质量保证过程域
QA:质量保证专员，质量保证学科
SQA:软件的质量保证专员，软件质量保证
NC:不符合项
QC:质量控制
OE:客观评价

QA 和 QC差别？

QA 是质量保证，QC是质量控制 
质量控制是质量保证的重要手段，质量控制是质量保证的一个部分，但是质量控制是发现问题的时候要去纠正的重要手段。

执行PPQA的工具方法

评审、审计、checklist、因果图、饼图

简述评审一般过程、审计一般过程

(1)评审一般过程:
1.前期准备:提前发资料，提前预审并提出问题!
2.执行评审，怎么执行:采用检查单,不迟到，要签到。跑题不要太远
3.评审过程怎么进行:进行度量、统计效率
4.评审结束:记录表现
(2)执行过程审计一般过程
准备:选PA，检查单，计划，评审
执行:审计，初步沟通，建议
评审和审计活动以检查工作产品和访谈作为主要工作来源，估算过程，进行访谈，访谈步骤，检查文档结果
后期:最终报告，跟踪NC，提供建议

QA人员以及PPQA过程的质量保证如何实现

QA要形成质量记录，由QA的经理来进行审查
PPQA过程也要形成记录

保证客观性。QA 人员往往是独立于开发部门的，以此来确保 QA 人员敢于指出问题。
尽可能把审查做成检查表，以此来消除主观性。

如何评价"测试驱动开发TDD可以显著提升质量"这一说法

TDD不应该能给质量带来显著提升，如果这个提升十分显著，那么就说明之前的单元测试做的是有问题的。

PPQA 的关注点

PPQA 关注做的与规定的流程是否是否一致，不是最终产品的质量

Lv3决策分析与解决(DAR)

目的: 使用正式的评价过程，遵循已建立的准则，对已识别的多个备选方案进行评价，以分析可能的决策。

概要

SG 1 评价备选方案

SP 1.1 建立决策分析指南

SP 1.2 建立评价准则

SP 1.3 识别备选解决方案

SP 1.4 选择评价方法

SP 1.5 评价备选解决方案

SP 1.6 选择解决方案

DAR 适用于哪些场景

具有多种备选方案并具有评价准则的各类问题均适合采用正式评价过程

选择备选方案的时候还需要注意什么

选择解决方案包括对备选方案的评价结果进行权衡考虑。应评估实施解决方案的关联风险。

Lv5原因分析与解决(CAR)

目的: 识别所选结果的原因并采取行动，以改进过程性能。

概要

SG 1 确定所选结果的原因

SP 1.1 选择需要加以分析的结果

SP 1.2 分析原因

SG 2 处理所选结果的原因

SP 2.1 实施行动提议

SP 2.2 评价已实施行动的效果

SP 2.3 记录原因分析的数据

CAR 在本质上做的是什么

CAR 认为不犯错比犯了错再改正更好。
当有问题出现的时候找到问题的根本原因，并且预防这些问题的再次发生。
CAR 是具有前瞻性质的，它可以主动分析以前的数据识别潜在问题并预防其发生。
并且在文档中提到，CAR 发生在项目的每个阶段是更为有效的做法。
除此之外 CAR 还可以将成功的原因纳入过程，将这些经验在组织内进行传递，以改进将来的过程性能。

CAR 在4级和5级的不同

4级主要排除因为特殊原因引起的问题，5级排除真正普适的根因

CAR 为什么需要和 OPM 配合

因为5级的CAR不能做非常粗糙的改进，而是需要细化的改进，OPM 可以量化这个过程

PPT 中问题整理

Requirements Management

Which of the following examples of requirements traceability are adequate?

1. Customer requirements to system requirements and vice versa, but no other traceability

2. System requirements to software and hardware requirements and vice versa, but no other traceability

3. Software and hardware requirements to design components and test cases and vice versa, but no other traceability

此处系统需求等同于产品需求，软、硬件需求等同于产品组件需求。和项目的上下文、粒度综合起来看，没有标准答案

Project Planing

PASS is planning their resources. What project resources should be included?

• Tools
• Budget and funding
• Staff
• Project plans
• Facilities

项目计划不是资源，其余都是。因为资源需要被安排到计划中

Project Management and Control

Project Problems
1) People are not showing up at peer review meetings.
2) Actual costs continually exceed planned costs.
3) People are delinquent on their action items.
4) Management does not know PASS status.
5) People are not meeting schedules.

PMC SPs
a) SP 1.1 Monitor Project Planning Parameters
b) SP 1.2 Monitor Commitments
c) SP 1.5 Monitor Stakeholder Involvement
d) SP 1.6 Conduct Progress Reviews
e) SP 2.3 Manage Corrective Action

1-c 2-a 3-e 4-d 5-b

Risk Management

1. PASS identified risks associated with their suppliers.
2. Risks were grouped by likelihood of occurrence and impact.
3. PASS identified risks associated with innovative technology.
4. Impact can be high, medium, or low.
5. At the risk management meeting, the status of some risks were changed to retired, mitigated, or closed.

a) Risk source
b) Risk category
c) Risk parameter

13-a 2-b 45-c

Supplier Agreement Management

PASS uses a supplier for motion sensors. Match PASS sample activities to SAM SPs.

Sample Activities
1) PASS wrote a contract with DetectEx.
2) Supplier motion sensors were sent to integration and testing.
3) A trade study conducted by PASS selected DetectEx for motion sensors.
4) The motion sensors passed acceptance criteria.
5) COTS were used for the keypad; sensors were secured from suppliers; and the controller consists of re-used PASS in-house software.

SAM SPs
a) SP 1.1 Determine Acquisition Type
b) SP 1.2 Select Suppliers
c) SP 1.3 Establish Supplier Agreements
d) SP 2.2 Accept the Acquired Product
e) SP 2.3 Ensure Transition of Products

1-c 2-e 3-b 4-d 5-a

Configuration Management

Which CM SPs could have prevented the problem?

PASS delivered updated software to SaveAll. SaveAll wanted to know what changed, but PASS wasn’t sure because change request records were incomplete.

1. SP 1.1 Identify Configuration Items
2. SP 1.2 Establish a Configuration Management System
3. SP 1.3 Create or Release Baselines
4. SP 2.1 Track Change Requests
5. SP 2.2 Control Configuration Items
6. SP 3.1 Establish Configuration Management Records
7. SP 3.2 Perform Configuration Audits

全都是

Process and Product Quality Assurance

Which are process evaluations? Which are product evaluations?
1. QA attends a peer review and mentions there should be an attendance sheet.
2. QA watches the engineers assemble a security system and notices a component was put in the wrong place.
3. QA reviews the requirements and notices a missing requirement.
4. QA reviews the design and notices some engineering drawings are missing.
5. QA notices that the test group does not always fill out problem reports.

正确答案是1，2，3，4，5，过程和产品都是有可能的

Verification

Which of the following are adequate for verification procedures and criteria?

1. Peer review criteria that says, “Ensure products are complete, consistent, and correct.”
2. Checklists for peer reviews
3. A test procedure that lists test steps and how to judge whether each test step passed or failed
4. A procedure on how to do the verification process
5. A procedure on how to do peer reviews

没有一个标准答案，主要是依据项目的情况来看的。例如第二点，对一个大的项目，有很多专家来进行评审，一个检查表反而可能产生疏漏

Validation

Which are verification and which are validation?

1. PASS conducts a formal design review with SaveAll.
2. PASS has a peer review with the systems engineers, software engineers, and QA.
3. PASS demonstrates a prototype to SaveAll to get their feedback.
4. PASS formally tests the product prior to delivery with both SaveAll and QA witnessing the test.
5. PASS integrates the components and tests the system.

都有可能。5在大多数情况下是VER，如果考虑环境因素VAL。需要看在哪个阶段，大部分的时候集成了之后还有下一次迭代，这个时候是工作产品，所以是VER。而如果没有下一个迭代直接交给用户这个时候就是交产品，所以是VAL。

Organizational Process Focus

Which of the following show incorporating experiences?

1. PASS Process Group (PG) updates a policy based on feedback from projects at a monthly meeting.
2. PASS PG notices a process step was poorly written and corrects it.
3. PASS PG looks at how projects are using the templates and updates the templates.
4. PASS PG improves the standard processes after analyzing appraisal metrics.
5. PASS PG updates a process because of information found on the internet.

属于:1 3 4

不属于:2 5

2:如果是因为项目团队用了觉得写的不清晰:属于。大部分情况:不属于

3:根据别人使用的结果做修正、更新

Integrated Project Management

Which PASS scenarios align with IPM?

1. All PASS projects follow the standard process exactly as is.
2. Projects can use their own processes and trace them to the PASS standard process.
3. PASS provides a standard process and rules for tailoring.
4. Once projects tailor the PASS standard process, it is called the projects’ standard process.
5. If the customer says eliminate QA, but the standard process requires QA with no tailoring, it’s okay for PASS projects to tailor out QA to satisfy the customer.

234

1 是可以定制化的

5 某个SP中规定必须要有QA，所以QA必须有

Organizational Process Definition

Match sample artifacts with OPD SPs.

Sample Artifacts

1) Instructions for when a process step can be deleted or modified
2) Website for tools, templates, project examples, etc.
3) Standard software that comes with all company computers
4) Spiral lifecycle description
5) Requirements process

OPD SPs

a) SP 1.1 Establish Standard Processes
b) SP 1.2 Establish Lifecycle Model Descriptions
c) SP 1.3 Establish Tailoring Criteria and Guidelines
d) SP 1.5 Establish the Organization’s Process Assets Library
e) SP 1.6 Establish Work Environment Standards

1-c 2-d 3-e 4-b 5-a

Organizational Training

Match sample artifacts with OT SPs.

Sample Artifacts

1) Training classrooms
2) Plan for 3-5 years in the future
3) Analysis of course evaluations
4) Plan that states PASS, not projects, will provide risk tool training
5) Plan for the next year

OT SPs

a) SP 1.1 Establish Strategic Training Needs
b) SP 1.2 Determine Which Training Needs are the Responsibility of the Organization
c) SP 1.3 Establish an Organizational Training Tactical Plan
d) SP 1.4 Establish a Training Capability
e) SP 2.3 Assess Training Effectiveness

1-d 2-a 3-e 4-b 5-c

量化的过程性能目标包括了质量，然而，为强调质量在CMMI产品套件中的重要性，在CMMI中使用“质量与过程性能目标”一词。在哪个地方也出现了其实不是并列关系，实际上是包含关系，仅仅是因为比较重要，所以拿出来说的情况

VER SG2 SG3:SG3包含SG2

同行评审只是一种验证的手段，但是太过重要所以放到了标准流程里面

持续集成 vs 大爆炸集成

大爆炸

问题：定位错误、查找错误困难

好处：如果模块质量高，这是最有效的集成方式

持续集成：

好处：定位错误简单

问题：代价较高（同一个测试用例会反复测试）

通过自动化手段缓解代价较高的问题

部分测试无法自动化实现，所以不可能持续集成完直接上线（持续集成无法代替集成测试）

CMMI 复习总结

过程改进

连续式表示法与阶段式表示法

等价阶段式定级

关于 CMMI 模型的一系列理解

为什么要有标准过程

如何使用过程模型

为什么过程模型很重要

对 CMMI 模型的一些误解

关于 CMMI 模型的一系列知识点

通用目标与通用实践

对制度化的理解

对通用实践的理解

通用实践和过程域的关系

已执行、已管理、已定义之间的区别

过程之间的关系

通用目标与通用实践

GG1 达成特定目标

GG2 制度化为已管理的过程

GG3 制度化为已定义的过程

说人话版本

相关问题

过程域

过程域的定义

过程管理类

Lv3组织级过程定义(OPD)

Lv3组织级过程关注(OPF)

Lv3组织级培训(OT)

Lv4组织级过程性能(OPP)

Lv5组织级绩效管理(OPM)

项目管理类

Lv2项目监督与控制(PMC)

Lv2项目计划(PP)

Lv2需求管理(REQM)

Lv2供方协议管理(SAM)

Lv3风险管理(RSKM)

Lv3集成项目管理(IPM)

Lv4量化项目管理(QPM)

工程类

Lv3需求开发 (RD)

Lv3技术解决方案(TS)

Lv3产品集成(PI)

Lv3确认(VAL)

Lv3验证 (VER)

支持类

Lv2度量与分析(MA)

Lv2配置管理(CM)

Lv2过程与产品质量保证(PPQA)

Lv3决策分析与解决(DAR)

Lv5原因分析与解决(CAR)

PPT 中问题整理