CMMI基本概念

CMMI基本概念

ATM组成员：

参加评审文档及访谈，完成证据的记录和收集（包括文档证据和访谈证据），填写PIID，根据所收集的证据参与评估结果的讨论和认定。

需要熟悉CMMI模型（3级熟悉18个PA）、公司的标准过程以及SCAMPI A类评估方法。

CMMI过程模型，EPG是否由ATM组成？

EPG和ATM是两个不同的概念，

EPG指Engineering Process Group工程过程小组，是您企业实施过程改进工作的一组人员。负责文档的制定和实施。

ATM指Appraisal Team Member评估小组成员，是您企业需要进行CMMI评估时担任评估证据收集及分析的一组人员，ATM的成员因为受到一些公平性原则的限制在选择上是有约束的。

EPG的职责是什么？

全面改善开发流程，提高开发质量，减少开发成本，缩短开发周期，提升开发效率，形成组织级的开发模式。

EPG成员的要求EPG Leader

须由项目经理及以上的成员担任

熟知部门开发业务及相应的开发流程

对开发中心内部流程必须精通

对过程改进有强烈意愿。

EPG Member

须是资深工程师或以上的成员担任；

必须对系统分析、软件开发、问题解决、以及项目发展之流程改进具有高度兴趣；

有较好的沟通、协调能力。

成员退出和进入的机制

成员的退出和进入，需要经过EPG的测试，并报EPG Leader审核，最终由总经理或管理者代表进行批准，方可办理退出或进入手续。EPG需负责对新进入的成员进行培训相关CMMI的知识内容，并保留对新进员工的考核，通过者方能正式进入EPG小组。

任务的分工按照CMMI的过程域来划分各自的任务；

不同人员负责不同的过程域，主导并负责该过程域的所有事宜；

除主要负责的过程域内容，负责协助其他成员的结果review；

按照日常活动分工合作，以事件为主导原则。

CMMI认证里面PM是做什么?

PM是项目管理(project management）的缩写，所谓项目管理，美国最早的曼哈顿计划开始的名称，后由华罗庚教授50年代引进中国(由于历史原因叫统筹法和优选法)，现在的台湾省叫项目专案。就是项目的管理者，在有限的资源约束下，运用系统的观点、方法和理论，对项目涉及的全部工作进行有效地管理。即从项目的投资决策开始到项目结束的全过程进行计划、组织、指挥、协调、控制和评价，以实现项目的目标。近年来，PM认证和PM教育都已经正常化、经常化、普及化，不再称为统筹法。在工程管理以及其他管理对象有显著的开始和结束期限的管理领域，属于关键管理工具或技能。

PA中CM是做什么?

配置管理(Configuration Management，CM)是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。

配置管理过程是对处于不断演化、完善过程中的软件产品的管理过程。其最终目标是实现软件产品的完整性、一致性、可控性，使产品极大程度地与用户需求相吻合。它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理功能。

随着软件系统的日益复杂化和用户需求、软件更新的频繁化，配置管理逐渐成为软件生命周期中的重要控制过程，在软件开发过程中扮演着越来越来重要的角色。

软件配置管理的最终目标是管理软件产品。由于软件产品是在用户不断变化的需求

驱动下不断变化，为了保证对产品有效地进行控制和追踪，配置管理过程不能仅仅对静态的、成形的产品进行管理，而必须对动态的、成长的产品进行管理。由此可见，配置管理同软件开发过程紧密相关。

配置管理必须紧扣软件开发过程的各个环节：管理用户所提出的需求，监控其实施，确保用户需求最终落实到产品的各个版本中去，并在产品发行和用户支持等方面提供帮助，响应用户新的需求，推动新的开发周期。通过配置管理过程的控制，用户对软件产品的需求如同普通产品的订单一样，遵循一个严格的流程，经过一条受控的生产流水线，最后形成产品，发售给相应用户。从另一个角度看，在产品开发的不同阶段通常有不同的任务，由不同的角色担当，各个角色职责明确，泾渭分明，但同时又前后衔接，相互协调。

好的配置管理过程有助于规范各个角色的行为，同时又为角色之间的任务传递提供无缝的接合，使整个开发团队象一个交响乐队一样和谐而又错杂地行进。正因为配置管理过程直接连接产品开发过程、开发人员和最终产品，这些都是项目主管人员所关注的重点，因此配置管理系统在软件项目管理中也起着重要。配置管理过程演化出的控制、报告功能可帮助项目经理更好地了解项目的进度、开发人员的负荷、工作效率和产品质量状况、交付日期等信息。同时配置管理过程所规范的工作流程和明确的分工有利于管理者应付开发人员流动的困境，使新的成员可以快速实现任务交接，尽量减少因人员流动而造成的损失。

CC是什么岗位？职责是什么？

Configuration Controller

配置管理员是在软件项目开发过程中进行配置管理的人员。负责制定配置管理计划，针对项目进行配置库的规划；搭建配置管理环境，建立和维护配置库，保证配置库稳定运行等

CI是什么？

Configuration Item

1．配置项（Software Configuration Item，SCI）识别

Pressman对于SCI给出了一个比较简单的定义：“软件过程的输出信息可以分为三

个主要类别：（1）计算机程序（源代码和可执行程序），（2）描述计算机程序的文档（针对技术开发者和用户），以及（3）数据（包含在程序内部或外部）。这些项包含了所有在软件过程中产生的信息，总称为软件配置项。”

由此可见，配置项的识别是配置管理活动的基础，也是制定配置管理计划的重要内容。

软件配置项分类软件的开发过程是一个不断变化着的过程，为了在不严重阻碍合理变化的情况下来控制变化，软件配置管理引入了“基线（Base Line）”这一概念。IEEE 对基线的定义是这样的：“已经正式通过复审核批准的某规约或产品，它因此可作为进一步开发的基础，并且只能通过正式的变化控制过程改变。”

所以，根据这个定义，我们在软件的开发流程中把所有需加以控制的配置项分为基线配置项和非基线配置项两类，例如：基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。

配置项的标识和控制

所有配置项都都应按照相关规定统一编号，按照相应的模板生成，并在文档中的规定章节（部分）记录对象的标识信息。在引入软件配置管理工具进行管理后，这些配置项都应以一定的目录结构保存在配置库中。

所有配置项的操作权限应由CMO严格管理，基本原则是：基线配置项向软件开发人员开放读取得权限；非基线配置项向PM、CCB及相关人员开放。

PA中DAR指什么?

Decision Analysis and Resolution

DAR的目的：运用结构化方法按照所建立的准则对所标识的候选解决方案进行决策。

DAR要点：

1、“决策分析和决定”过程域涉及：

- 建立指南来确定哪些问题需要运用正式的评价过程

- 运用正式的评价过程评价这些问题

2、正式的评价过程是按照已制定的准则评价候选解决方案的结构化过程，它用于确定推荐的解决

方案来处理问题

3、正式的评估过程包括以下活动：

- 建立评价候选解决方案的准则

- 标识候选解决方案

- 选择评价候选解决方案的方法

- 使用已制定的准则和方法评价候选解决方案

- 基于评价准则从候选解决方案中选择推荐的解决方案

4、结构化决策过程可以减少决策中的主观影响，能够以比较高的概率选择出能满足有关的相关人员的多种需求的解决方案

5、尽管“决策分析和解决方案”过程域主要运用于技术问题，但正式的评价过程也适用于许多非技术论题，特别是项目正在策划中

6、拥有多项候选解决方案和相应评价准则的非技术论题本身也适宜于结构化决策

7、设备或软件的贸易研究就是结构化决策的一个典型例子

特定目标和共性目标

SG 1 评价候选解决方案：运用所拟订的准则评价候选方案，为决策奠定基础

GG 2 制度化一个已管理过程：将该过程制度化为一个已管理过程

GG 3 制度化一个已定义过程：将该过程制度化为一个已定义过程

PA中DR指什么?

Derived Requirement

派生需求是由阿弗里德·马歇尔在其《经济学原理》一书中首次提出的经济概念，是指对生产要素的需求，意味着它是由对该要素参与生产的产品的需求派生出来的，又称“引致需求”。

对一种生产要素的需求来自（派生自）对另一种产品的需求。其中该生产要素对这一最终产品会作贡献，如对轮胎的需求派生自对汽车运输的需求。

派生需求强调的是企业要用一种观念、一种倡导培养出目标市场对某种产品或服务的需求，并使目标市场很乐意地去交换和购买。企业也理所当然地将产品或服务转移到目标市场，并取得利润回报。派生需求为引导，以“找”、“看”、“想”、“算”的心理跟进刺激，引发消费者的购买欲望，需求是可以派生的，这也是企业引导消费的体现，也就

是说企业应深入分析市场需求及潜在需求，整理、判断并在需求上创新，从而做到差异性竞争，用展望法去预测，开拓新产品、开发新市场、赢得利润、赢得市场。

（符合度待考证）

PA中MA指什么？

Measurement and Analysis

Purpose 目的

度量与分析（简称MA）的目的，是开发与维持度量能力，用以支持管理信息的需求。

Introductory Notes 简介

度量与分析过程域包括：

* 指定度量与分析的目标，并使其符合已识别的信息需要与目标

* 指定度量指标、分析技术，以及数据收集、数据存储、报告与反馈的机制

* 实施数据的收集、存储、分析与报告

* 提供客观的结果，据此做出有根据的决策，并采取适当的纠正措施

将度量与分析活动集成到项目过程中，可支持以下活动：

* 客观的策划与评估

* 依据已建立的计划与目标，跟踪实际性能

* 识别并解决与过程相关的问题

* 提供将度量纳入未来增加过程的基础

执行度量能力的员工，未必有一个独立的的组织层面的计划来招聘，度量能力可能集成到单个的项目，或其他组织功能（如质量保证）。

度量活动最初的重点是在项目级别，而度量能力在处理组织和（或）企业范围的信息需求时，或许被证明有用。为支持这种功能，度量活动应在多种级别上支持信息需求，包括商业、组织单位、项目，从而在组织成熟时能够降低返工。

项目可选择在一个项目特定的存储库中，存储项目特定数据与结果。当数据需要在项目间广泛共享时，可存放在组织度量库中。

对供应商提供的产品组件进行度量与分析，对于有效管理项目的质量与成本是必要的。通过对供应商协议严谨的管理，可以对支持供应商性能分析的数据有深入的了解。

PA中OPD指什么？

PA中OPF指什么？

Organizational Process focus

组织过程焦点（简称OPF）的目的是在充分了解当前组织的过程和过程资产的强项与弱项的基础上，策划、执行与部署组织级过程改进活动。

Introductory Notes 简介

组织过程包括组织及其项目所使用的所有过程。组织过程与过程资产的备选改进方案，可从多种来源获取，包括过程的度量、执行过程的心得体会、过程评估的结果、产品评估活动的结果、与其他组织过程作基准比较的结果，以及组织中其他改进构想的建议方案。

过程改进源于组织的范围需要，并用以实现组织的目标。组织鼓励那些即将执行过程的人员，参与过程改进活动。推动与管理组织过程改进活动的责任，包括协调其他资源的参与，通常是指派过程组负责。组织为该组提供长期的承诺和资源以确保过程改进活动能够有效并及时地展开。

为确保整个组织过程改进的投入，能够充分地管理与执行，必须要有详细的策划。组织过程改进策划的成果为过程改进计划。

组织过程改进计划将说明评估计划、过程改进计划、试用计划与部署计划。评估计划描述了评估的时间与进度、评估的范围、实施评估所需的资源、实施评估所参考的模型，以及评估的后勤保障等。

过程改进计划通常由评估结果导出，并且以评估时所发现的弱项为目标，制定如何实施特定改进的文件。如果过程改进计划中所描述的改进，在整个组织部署前，决定先要在小组进行测试，则会制定试用计划。

最后，采用部署计划部署改进。该计划描述了整个组织何时以及如何部署改进。

组织过程资产用于描述、执行与改进组织过程。

PA中PPQA指什么？

Process and Product Quality Assurance

过程与产品质量保证（PPQA）的目的在于使项目成员与管理层客观地了解过程及相关的工作产品。

Introductory Notes 简介

过程与产品质量保证过程域包含以下内容：

* 依据适用的过程描述、标准和程序，对已执行的过程、工作产品和服务进行客观评估

* 识别和记录不符合问题

* 将质量保证活动的结果反馈给项目成员及管理者

* 确保不符合问题已经处理

过程与产品质量保证过程域，为项目成员与各级管理者提供能适当的了解和反馈，项目生命周期中的各个过程及相关工作产品，以支持交付高质量的产品与服务。

过程与产品质量保证过程域的各项实践，确保已策划的过程被执行，而验证过程域的各项实践，确保特定的需求得到满足。这两个过程域有时可能从不同的角度关注同样的工作产品。项目在继续保持从各自的角度看问题时，也应利用两种角度的重叠之处，以降低重复的工作量。

过程与产品质量保证评估的客观性，是项目成功的关键。客观性通过独立评估及使用评估标准来实现。通常由那些不生产工作产品的人，依据标准，采用多种方法相结合进行评估。可使用较不正式的方法进行广泛的日常评估；使用较正式的方法进行定期评估，以确保客观性。

一般情况下，独立于项目之外的质量保证组可以保证这种客观性。然而，对某些组织而言，在并非独立的情况下实施过程与产品质量保证，可能也很合适。例如，在一些具有开放性、质量导向文化的组织中，过程与产品质量保证的角色由组织成员部分或全部来执行，而且质量保证功能可能植根于过程之中。对一些小型组织而言，这可能是最可行的方法。

PA中REQM指什么？

Requirements Management

需求管理（REQM）的目的是，管理项目产品与产品组件的需求，并识别这些需求与项目计划和工作产品之间的差异。

Introductory Notes 简介

需求管理过程指的是，管理项目所接收或产生的全部需求，包括技术性和非技术性需求，以及收集的组织对项目的需求。特别指出，一旦实施需求开发过程域，该过程就会产生产品与产品组件需求，这些也要纳入需求管理过程的管理。在整个过程域中，用到术语“产品与产品组件”时，含义也包括服务及其组件的意思。在实施需求管理、需求开发、技术解决方案过程域时，它们的相关过程可能紧密联系在一起，并同步执行。

项目采取适当的步骤，确保被认可的需求集得到管理，以支持项目计划与实施的各项需要。当项目从已批准的需求提供者那里收到需求时，应同需求提供者一起评审该需求，以便在需求纳入项目计划之前，解决有关问题并避免产生误解。一旦需求提供者与需求接收者达成共识，就应获得项目参与者对需求的承诺。随着项目的推进，项目应管理需求的变更，并识别出存在于计划、工作产品与需求之间的差异。

需求管理的一部分内容是指，记录需求变更及其理由，并维持对原始需求、所有产品与产品组件需求二者间的双向跟踪性。

所有的开发项目都有需求。如果一个项目专注于活动的维护，在这种情况下，产品或产品组件需求的变更，是以现有需求、设计或实现为基础的。若需求出现变更，可能记录在客户或用户需求变更中，或者属于从需求开发过程中收到新的需求。不论是何种来源或形式，因需求变更而引起的维护活动，应因此进行相应的管理。

PA中VAL指什么？

Validation

确认（简称V AL）的目的是展示完全置于预期环境中的产品或产品组件可以满足预期的使用需求。

Introductory Notes 简介

所有的产品都可在其预期环境中实施确认活动,例如：操作、培训、制造、维护及支持服务。用于工作产品的确认方法，也能使用在产品和产品组件上（在所有过程域中，产品和产品组件的含义包括服务和其组件）。工作产品﹙例如：需求、设计、原型﹚，被选择的基础是何种指标能衡量产品与产品组件可以满足使用者需求的程度；因此在整个产品生命周期，应及早并逐步实施确认。

确认环境应可代表产品和产品组件的预期环境，同时也适用于工作产品确认活动的

预期环境。

确认证明所提供的产品符合预期的使用需求，而验证说明工作产品是否正确反映了特定需求。也就是说，验证确保“你正确地做了”，而确认确保“你做了正确的事”。确认活动使用与验证类似的方法，例如：测试、分析、检查、示范或模拟。通常，确认活动包含了最终用户和其他相关干系人。确认与验证活动经常同时实施，且可能使用部分相同的环境。

若有可能，实施确认应将产品或产品组件置于其预期环境中运行。确认可能使用全部或部分的预期环境，使用工作产品实施确认，可让问题在项目生命周期中通过相关干系人的参与及早被发现。服务的确认活动可应用于工作产品，例如建议书、服务目录、工作描述和服务记录。

当确认时,问题被识别出来，需要参考需求开发、技术解决方案或项目监控过程域的实践来解决。

本过程域的特定实践建立于如下情况：

* “选择确认的产品”特定实践识别需要确认的产品或产品组件，与用来实施确认的方法。

* “建立确认环境”特定实践确定用来实施确认的环境。

* “建立确认程序与标准”特定实践依照所选产品的特性、客户在确认上的约束、方法与确认环境来制订确认程序与标准。

* “实施确认”特定实践依照方法、程序及标准来实施确认。

PA中VER指什么？

PA中RSKM指什么？

RISK MANAGEMENT 风险管理

Purpose 目的

风险管理（简称RSKM）的目的在于，在风险发生之前识别潜在的问题，从而策划风险处理活动，必要时在整个产品或项目生命周期中加以实施，以缓解对实现目标的不利影响。

Introductory Notes 简介

风险管理是一个持续性、前瞻性的过程，是管理的一个重要组成部分。风险管理应该处理那些可能危及关键目标实现的问题。应用持续的风险管理方法，可以有效地预测和缓解对项目有重要影响的风险。

有效的风险管理，应按照项目策划过程域所强调的干系人参与计划的描述，通过与相关干系人的合作和参与，尽早并积极地识别风险。为建立自由、开放的讨论与揭示风险的环境，需要所有的相关干系人具有强有力的领导能力。

风险管理必须从内部和外部两个方面考虑成本、进度、性能风险及其他风险。尽早并积极地发现风险相当重要，因为相比在项目的后期而言，在早期进行变更或采取的措施，往往更加容易、成本较低、破坏性较少。

风险管理可以分为三个部分：定义风险管理策略、识别与分析风险，以及处理已识别的风险，包括在必要时执行风险缓解计划。

如同“项目策划”与“项目监控”过程域所述，组织最初可能只是关注风险的识别，在风险发生后才做出反应。风险管理过程域描述的是这些特定实践的发展演变，为了将风险对项目的影响降到最低，进行系统的策划、预测并缓解风险。

尽管风险管理过程域主要强调的是项目风险，但这种概念同样适用于管理组织风险。

RTM是什么？

PA中IPM指什么？

Integrated Project Management

集成的项目管理包含以下内容：

* 在项目启动初期，通过裁剪组织的标准过程集建立项目已定义过程

* 使用项目已定义过程来管理项目

* 依据组织的工作环境标准，建立项目的工作环境

* 使用组织过程资产，并积累组织过程资产

* 在产品开发的过程中，使相关干系人的意见均被识别、考虑，并进行适当处理* 确保相关干系人能够及时协调工作量和按时完成任务：（1）处理产品与产品组件

需求、计划、目标、问题及风险；（2）履行他们的承诺；（3）识别、追踪和解决问题从组织标准过程集裁剪而来的集成的已定义过程，称为项目已定义过程。

项目工作量、成本、进度安排、人员、风险及其他因素的管理，与项目已定义过程的任务紧密相关。对项目已定义过程的实施与管理，在项目计划中已进行了典型描述，而某些活动可能包含于影响项目的其他计划中，诸如品质保证计划、风险管理策略、配置管理计划。

因为每个项目的已定义过程，都是从组织标准过程集裁剪而来，项目间的差异通常会减少，而且项目可以更容易分享过程资产、数据和经验教训。

本过程域也处理了与项目相关的所有活动的协调，包括以下内容：

* 开发活动，例如：需求开发、设计、验证

* 服务活动，例如：交付、服务台、运营、客户关系

* 采购活动，例如：招标、合同监控、迁移至运营

* 支持活动，例如：配置管理、文档化、市场营销、培训

项目内部或外部的相关干系人之间的工作接口及相互关系，都需要进行策划与管理，以确保整体产品的质量与完整性。制定项目已定义过程及项目计划时，相关干系人可以适当的参与。与相关干系人定期地进行评审与交换意见，确保每位项目参与者能够适当地了解项目的状态、计划及活动，也确保该项目的协调问题得到适当关注。在制定项目已定义过程时，按需要建立正式的接口，以确保适当的协调与合作。

本过程域适用于任何组织结构，诸如包括垂直领导组织、矩阵组织或集成团队。该术语应该在适当的组织结构中，加以适当的解释。

PA中CAR指什么？

Causal Analysis and Resolution

Purpose 目的

原因分析与解决（简称CAR）的目的是识别缺陷和其他问题的原因，并采取措施以防止这些问题在将来再次发生。

Introductory Notes 简介

原因分析与解决过程域包括下列活动：

* 识别并分析造成缺陷和其他问题的原因

* 采取具体措施，消除这些问题的原因并且防止这类缺陷和问题将来再次发生原因分析与解决通过避免将缺陷引入产品，以改进质量和生产力。在缺陷发生后再进行侦测，是不符合成本效益的。更有效的方式是，将原因分析与解决的活动，集成到项目的每个阶段，以避免缺陷的发生。

既然缺陷和问题可能发生于先前的其它项目或现有项目的较早阶段，原因分析与解决活动可以作为各项目间分享经验教训的沟通机制。

分析所发生的缺陷和其它问题的类型，以识别其趋势。依据对已定义过程和如何实施的理解，来判断缺陷的根本原因，以及未来可能发生的地方。

原因分析也可以运用在与缺陷无关的问题上。例如，原因分析可用来改进质量属性，如周期时间。这种分析可由改进建议、模拟、动态系统模型、工程分析、新的商业指示，或其它可能启动这种分析的项目所启动。

当然，对所有的缺陷进行原因分析并不实际。在这种情况下，必须在估计的投资与预期的质量、生产力、周期时间、所选择的缺陷目标的回报之间做权衡。

度量过程应已经准备就绪。虽然在某些情况下，也许需要新的度量指标来分析过程变更的影响，但应使用已定义的度量指标。

原因分析与解决活动提供给项目一个机制，以便在项目层次评估其过程，并寻找可实施的改进措施。

当改进措施在项目层次的实施，被认定为有效，这些信息可扩充到组织层次。

本过程域的详细资料，具有此假设：这些特定实践适用于量化管理过程。在不考虑此假设的情况下，本过程域的特定实践也可适用，不过会降低所产生的价值。

CMMI基本概念

CMMI基本概念 ATM组成员： 参加评审文档及访谈，完成证据的记录和收集（包括文档证据和访谈证据），填写PIID，根据所收集的证据参与评估结果的讨论和认定。 需要熟悉CMMI模型（3级熟悉18个PA）、公司的标准过程以及SCAMPI A类评估方法。 CMMI过程模型，EPG是否由ATM组成？ EPG和ATM是两个不同的概念， EPG指Engineering Process Group工程过程小组，是您企业实施过程改进工作的一组人员。负责文档的制定和实施。 ATM指Appraisal Team Member评估小组成员，是您企业需要进行CMMI评估时担任评估证据收集及分析的一组人员，ATM的成员因为受到一些公平性原则的限制在选择上是有约束的。 EPG的职责是什么？ 全面改善开发流程，提高开发质量，减少开发成本，缩短开发周期，提升开发效率，形成组织级的开发模式。 EPG成员的要求EPG Leader 须由项目经理及以上的成员担任 熟知部门开发业务及相应的开发流程 对开发中心内部流程必须精通 对过程改进有强烈意愿。 EPG Member 须是资深工程师或以上的成员担任； 必须对系统分析、软件开发、问题解决、以及项目发展之流程改进具有高度兴趣； 有较好的沟通、协调能力。 成员退出和进入的机制

成员的退出和进入，需要经过EPG的测试，并报EPG Leader审核，最终由总经理或管理者代表进行批准，方可办理退出或进入手续。EPG需负责对新进入的成员进行培训相关CMMI的知识内容，并保留对新进员工的考核，通过者方能正式进入EPG小组。 任务的分工按照CMMI的过程域来划分各自的任务； 不同人员负责不同的过程域，主导并负责该过程域的所有事宜； 除主要负责的过程域内容，负责协助其他成员的结果review； 按照日常活动分工合作，以事件为主导原则。 CMMI认证里面PM是做什么? PM是项目管理(project management）的缩写，所谓项目管理，美国最早的曼哈顿计划开始的名称，后由华罗庚教授50年代引进中国(由于历史原因叫统筹法和优选法)，现在的台湾省叫项目专案。就是项目的管理者，在有限的资源约束下，运用系统的观点、方法和理论，对项目涉及的全部工作进行有效地管理。即从项目的投资决策开始到项目结束的全过程进行计划、组织、指挥、协调、控制和评价，以实现项目的目标。近年来，PM认证和PM教育都已经正常化、经常化、普及化，不再称为统筹法。在工程管理以及其他管理对象有显著的开始和结束期限的管理领域，属于关键管理工具或技能。 PA中CM是做什么? 配置管理(Configuration Management，CM)是通过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程，确保软件开发者在软件生命周期中各个阶段都能得到精确的产品配置。 配置管理过程是对处于不断演化、完善过程中的软件产品的管理过程。其最终目标是实现软件产品的完整性、一致性、可控性，使产品极大程度地与用户需求相吻合。它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理功能。 随着软件系统的日益复杂化和用户需求、软件更新的频繁化，配置管理逐渐成为软件生命周期中的重要控制过程，在软件开发过程中扮演着越来越来重要的角色。 软件配置管理的最终目标是管理软件产品。由于软件产品是在用户不断变化的需求

CMMI5文档之配置项状态报告模板

配置项状态报告 文档编号：FHI_CMMI_CM_TEM_LOG 文档信息：配置项状态报告 文档名称：配置项状态报告 文档类别：CMMI模板 密级：内部秘密 版本信息：1.1 建立日期：2016-1-19 创建人：EPG 批准人：李庆林 批准日期：2016-2-25 存放位置：集成公司组织资产库/组织标准过程 编辑软件：Microsoft Office 2003 中文版

文档修订记录 *变化状态：C――创建，A——增加，M——修改，D——删除

目录 1 基线域 (4) 1.1 需求RMBL (4) 1.2 设计SDBL (4) 1.3 运行PRBL (5) 2 受控域 (5) 2.1 需求开发计划 (5) 2.2 项目计划 (6) 2.3 项目监控 (6) 2.4 沟通管理 (6) 2.5 需求管理 (6) 2.6 产品集成 (6) 2.7 测试 (6) 2.8 配置管理 (6) 2.9 质量保证 (7) 2.10 项目评审 (7) 2.11 项目培训 (7) 2.12 决策分析 (7) 2.13 用户资料 (7) 2.14 项目验收 (7)

1基线域 VSS工具 ***************** Version 1 ***************** User: Admin Date: 08-12-04 Time: 9:50 Created 01基线域 SVN工具 Revision: 1 Author: liuhy Date: 16:43:15, 2008年11月19日 Message: ---- Added : /项目名称/Trunk/Documents/01基线域 1.1需求RMBL ***************** Version 2 ***************** User: Admin Date: 08-12-04 Time: 9:50 Created 01需求RMBL ***************** 01需求RMBL ***************** User: Admin Date: 08-12-04 Time: 9:50 Added项目名称用户需求说明书.doc ***************** 01需求RMBL ***************** User: Admin Date: 08-05-16 Time: 17:10 Added 项目名称软件需求规格说明书.doc ***************** 项目名称用户需求说明书.doc ***************** User: Admin Date: 08-12-04 Time: 9:54 Checked in $/项目名称/02基线域/01需求RMBL Comment:根据变更申请表进行修改。 ***************** 项目名称软件需求规格说明书.doc ***************** User: Admin Date: 08-12-04 Time: 9:54 Checked in $/项目名称/02基线域/01需求RMBL Comment:根据变更申请表进行修改。 1.2设计SDBL ***************** Version 3 ***************** User: Admin Date: 08-12-04 Time: 9:50

CMMI3访谈问题及答案--配置管理

配置管理访谈 1. 可否请你描述一下：你是如何确定你的项目的配置项的访 问控制的？ 我们在项目启动时，会编写项目配置管理计划，明确配置项以及相应的责任人，并设立每个配置项的访问权限，比如：项目计划的修改权只有计划的责任人拥有。 再次，对于配置项，我们实施变更控制：对于基线化了的配置项，配置管理员会锁定，如果有人要修改，要提交变更申请，得到CCB授权同意后，配置管理员才会将配置项的修改权限放给变更申请人。 2. 可否请你描述一下：在你的项目中是如何发起变更请求， 如何审核变更请求，如何报告变更状况的(如何记录的)？ 对于基线化了的配置项，我们如果要修改，需要提交变更请求，即起草变更请求表； 对于变更请求，项目CCB会进行影响分析，在变更请求表中填写影响范围、工作量等信息，同时会做出是否同意变更的决定，如果决定变更，会制定修改方案，安排相关人员明确影响范围，实施变更； 变更实施完成，要提交CCB验证，验证通过后，变更请求才被关闭； 3. 可否请你描述一下：怎样计划配置审计的(怎样制定配置 审计计划)？ 配置审计计划一般参考项目配置管理计划制定审计计划，从功能审计和物理审计方面考虑具体审计时机。 功能审计，比如我们项目一般会在配置系统建立结束时作一次审计，以检查配置系统能够满足本项目的实施需要，配置项管理方法是否正确，是否完整；

再则，我们根据基线建立计划以及阶段结束时间制订物理审计和功能审计的时机，以确保所有的配置项如在 CM 计划中期望的那样放在配置管理系统(也称配置库)下，确保团队有一个机制来知道给定配置管理项的最新状态，确保配置管理项的状态与基线信息一致，识别团队的配置管理培训需求等 4. 可否请你描述一下：怎样审核和授权软件基线的变更的？ 软件基线的变更需要获得CCB的审核和授权 5. 可否请你描述一下：CCB由哪些人员组成？ 就由项目经理，配置管理员、技术骨干组成。 CCB主任一般由项目经理担当。 6. 可否请你描述一下：在你的项目中，那些工作产品进行配 置管理？为什么？（或者问题方式可能是：配置项是如何识别的？） 根据组织级定义的配置管理过程，所有工作产品都实施配置管理，包括来自客户的各种资料，要交付给客户的成果物，项目计划等。在配置管理计划中识别出所有的工作产品和需要基线的配置项。 7. 可否请你描述一下：基线是怎么建立的？ 对于客户提供的资料以及重要阶段的工作产品制定基线计划，我们在项目配置管理计划中制定了基线计划，明确了基线建立的时机以及包含哪些配置项； 基线的配置项通过评审后，项目经理通知配置管理员建立基线，更新基线发布状态表以及配置项状态表，同时告诉所有人员。 8. 可否请你描述一下：配置管理是怎么做的？ 项目经理在项目启动阶段就会申请配置管理员，配置管理员识别配置项，制

CMMI 配置管理

CMMI之配置管理 2008-01-11 作者：张瑾来源：希赛网 在笔者进行CMMI咨询时，当问及软件技术人员什么是”配置管理”的时候，很多人的回答就是“版本管理”，而且很多人都会说出各种各样的版本管理工具，例如：VSS、TFS、CVS或SVN等等。但这样的回答是不正确、不全面的。版本管理只是软件配置管理的一个小的部分，在CMMI中配置管理分为“配置项和基线的管理”、“变更控制管理”和“基线的完整性”三个部分。 凡是提到软件“配置管理”（Configuration Management），我会先给它下个定义：“它是软件工程的核心部分，是CMMI中最基础的PA”。为什么它会如此重要呢？首先配置管理的工作就是确保软件项目时时保持条理清晰，随时想要任何工作产品都可以迅速找到，并且工作产品的内容不会出错，这也就是大家常讲的可回溯性、完整性和正确性；其次软件配置管理活动始终贯穿整个软件项目的生命周期。因此说软件配置管理是最基础、最核心的管理工作一点都不夸张。 (一) 软件配置项 在CMMI的“配置管理”过程域CM中SP1.1首先提到的就是“配置项”的概念，在大家开展配置管理工作前应该先识别哪些是本项目的配置项。“配置项”就是配置管理的对象，简单来讲它符合以下任意一个特点： 1、它会被两个或两个以上的项目成员共同使用。 2、它会随着项目的开展而发生变化。 3、对项目重要的工作产品。 4、一些工作产品之间的关系非常紧密，一个变化其他的就会受到影响。 通过以上定义大家会发现项目中的很多东西都属于配置项，例如：各种需求文档、设计文档等都会经常变更；程序的代码是大家共享的，而且代码文件之间又有较高的相互依赖性。 那大家也许会发现还有一些工作产品不符合以上定义，例如：各种周报、会议记录等。这些也是配置项

CMMI3级软件过程 第17章 配置管理

第17章配置管理 配置管理(Configuration Management,CM)的目的是通过执行版本控制、变更控制等规程，以及使用配置管理软件，来保证所有配置项的完整性和可跟踪性，配置管理是对工作成果的一种有效保护。 ☆制定配置管理计划[SPP-PROC-CM-PLANNING]。 ☆配置库管理[SPP－PROC－CM-LIB]。 ☆配置项版本控制[SPP-PROC－CM－VERSION]。 ☆配置项变更控制[SPP－PROC－CM－CHANGE]。 上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。 本规范适用于国内IT企业的软件研发项目。建议用户根据自身情况（如商业目标、研发实力等）适当地修改规范，然后推广使用。 17.1 介绍 项目研发和管理过程中会产生许许多多地工作成果。例如文档、程序和数据等，它们都应当背保存起来，以便查阅和修改。如果把所有文件一股脑地塞进计算机里，那么使用起来肯定很麻烦。毫无疑问，人们应当将文件分类、有条理地保存起来。 凡是纳入配置管理范畴的工作成果统称为配置项（Configuration Item，CI），配置项主要有两大类： ●属于产品组成部分的工作成果，例如需求文档、设计文档、源代码、测试用例等。 ●项目管理和机构支撑过程域产生的文档。这些文档虽然不是产品的组成部分，但是 是值得保存。 每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存再配置库里，确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 基线(BaseLine)由一组配置组成，这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改（见变更控制规程）。基线通常对应开发过程中的里程碑(Milestone),一个产品可以有多个基线，也可以只有一个基线。基线的主要属性有：名称、标识符、版本、日期等。通常将交付给用户的基线称为一个“Release”，为内部开发用的基线则称为一个“Build”。 所有的项目成员都要使用配置管理软件来保护自己的工作成果。机构应当采用统一的配置管理软件，常见的配置管理软件有Microsoft的Visual SourceSafe和Rational的ClearCase 等。为提高配置管理的效率和安全性，结构应当有专门的配置管理员（角色）。配置管理员为每个项目制定《配置管理计划》，创建和维护配置库。 鉴于配置管理的重要性和复杂性，机构还应当设立配置控制委员会（Configuration Control Board，CBB）。CBB是个虚拟小组，对配置管理各项活动拥有决策权（例如审批计划，审批变更请求等）。对于配置管理管理而言，CBB是决策者，而配置管理员是执行者。 如果机构的各个项目的配置管理拥有决策权。如果机构的各个项目相对独立，那么每个项目可以设立各自的CBB。CBB的决策采用“少数服从多数”的原则。 配置管理的流程如图17－1所示。

CMMI3访谈问题及答案--配置管理

配置管理访谈 1.可否请你描述一下：你是如何确定你的项目的配置项的访 问控制的？ 我们在项目启动时，会编写项目配置管理计划，明确配置项以及相应的责任人，并设立每个配置项的访问权限，比如：项目计划的修改权只有计划的责任人拥有。 再次，对于配置项，我们实施变更控制：对于基线化了的配置项，配置管理员会锁定，如果有人要修改，要提交变更申请，得到CCB授权同意后，配置管理员才会将配置项的修改权限放给变更申请人。 2.可否请你描述一下：在你的项目中是如何发起变更请求， 如何审核变更请求，如何报告变更状况的(如何记录的)？ 对于基线化了的配置项，我们如果要修改，需要提交变更请求，即起草变更请求表； 对于变更请求，项目CCB会进行影响分析，在变更请求表中填写影响范围、工作量等信息，同时会做出是否同意变更的决定，如果决定变更，会制定修改方案，安排相关人员明确影响范围，实施变更； 变更实施完成，要提交CCB验证，验证通过后，变更请求才被关闭； 3.可否请你描述一下：怎样计划配置审计的(怎样制定配置 审计计划)？ 配置审计计划一般参考项目配置管理计划制定审计计划，从功能审计和物理审计方面考虑具体审计时机。 功能审计，比如我们项目一般会在配置系统建立结束时作一次审计，以检查配置系统能够满足本项目的实施需要，配置项管理方法是否正确，是否完整；

再则，我们根据基线建立计划以及阶段结束时间制订物理审计和功能审计的时机，以确保所有的配置项如在 CM 计划中期望的那样放在配置管理系统(也称配置库)下，确保团队有一个机制来知道给定配置管理项的最新状态，确保配置管理项的状态与基线信息一致，识别团队的配置管理培训需求等 4.可否请你描述一下：怎样审核和授权软件基线的变更的？ 软件基线的变更需要获得CCB的审核和授权 5.可否请你描述一下：CCB由哪些人员组成？ 就由项目经理，配置管理员、技术骨干组成。 CCB主任一般由项目经理担当。 6.可否请你描述一下：在你的项目中，那些工作产品进行配 置管理？为什么？（或者问题方式可能是：配置项是如何识别的？） 根据组织级定义的配置管理过程，所有工作产品都实施配置管理，包括来自客户的各种资料，要交付给客户的成果物，项目计划等。在配置管理计划中识别出所有的工作产品和需要基线的配置项。 7.可否请你描述一下：基线是怎么建立的？ 对于客户提供的资料以及重要阶段的工作产品制定基线计划，我们在项目配置管理计划中制定了基线计划，明确了基线建立的时机以及包含哪些配置项； 基线的配置项通过评审后，项目经理通知配置管理员建立基线，更新基线发布状态表以及配置项状态表，同时告诉所有人员。 8.可否请你描述一下：配置管理是怎么做的？ 项目经理在项目启动阶段就会申请配置管理员，配置管理员识别配置项，制

CMMI 3 CM配置管理员 提问问题单

FAR Questions Configuration Management(CM) 配置人员访谈 CM SP 1.什么是配置项？请叙述您如何识项目的配置项? (SP1.1) 2.请叙述您项目的配置管理系统如何建立? (SP1.2) 3.请叙述您如何及何时将工作产品设立基线?如何发布基线？(SP1.3) 4.变更管理流程？请叙述您的变更需求追溯过程? (SP2.1) 5.您如何管理配置项的变更? (SP2.2) 6.您会产出那些配置管理纪录?这些记录会被如何使用与管理？(SP3.1,GP2.6) 7.你是如何进行配置审计的？ (sp3.2) 8.如何构建以前的版本? (SP3.1) CM GP 1.提供两个您使用的历史项目的任何形式的文档资料并放入组织财富库。提供两条与您工作有关的过程改进建议并提供给EPG。提供两条您参与的 风险有关的事情。提供两条QA检查的问题。提供两条与项目经理或其它人讨论的项目管理方面的问题（如资源冲突协调）。提供两条与您工作有关的评审问题。提供两条测试发现您的缺陷记录。 2.公司是否有组织方针，请叙述组织的方针?哪些与你的工作有关,你是否了解其中有什么内容？GP2.1 3.谁策划你的工作, 如何策划,你对策划有什么意见,你确认了计划吗？(GP2.2) 4.谁策划你的活动需要的工具及资源,如何策划这些工具和资源,有哪些工具和资源,你觉得这些资源充分吗? 你了解公司组织过程财富库中有哪些内 容吗？你是如何访问和使用？(GP2.3) 5.你在工作中的职责是什么?你是如何知道你的职责的?(GP2.4) 6.你参加过哪方面的培训?你是如何了解公司的培训安排? 你培训后是否填写过培训反馈表？你知道有免培规程吗？(GP2.5) 7.你有哪些工作产品？每个工作产品的主要内容是什么？目录结构是什么？你的工作产品是如何进行管理的?你了解到几种资料管理级别?( GP2.6) 8.你的工作与那些干系人有关?你如何和他们协调沟通?沟通效果如何? 沟通中有什么问题？(GP2.7) 9.有哪些日常性的监控活动与你的工作有关？项目中从头到尾你参与了哪些活动？哪些度量项与你的工作有关？如何收集度量数据？如何使用这些 数据？ (GP2.8) 10.QA如何客观地评价您的工作？QA参照什么标准检查你工作？有哪些检查项？发现了哪些不符合项？(GP 2.9) 11.高层管理者如何来审查和了解你的工作？(GP2.10) 12.您的工作活动遵循什么标准过程,有没有裁剪？(GP3.1) 13.您工作中有什么工作产品,工作相关的度量数据, 经验教训,过程改进建议提交给组织财富库?(GP 3.2)你通过哪些途径了解公司过程改进的进展情 况？ 1

CMMI-3CM-GP22-配置管理计划模板

CM计划 1 前言 1.1 目的 本计划是XXX项目计划的组成部分，它规定了在信贷管理系统项目中如何开展配置管理工作，以便在项目的整个生存周期中，建立和维护工作产品的完整性和一致性。 1.2术语定义和缩写词 CCB（Configuration Control Board）：配置控制委员会 Baseline：基线，是开发规程中标识出的里程碑所交付的一个或多个配置项，它有以下三个特征： ?已经通过正式的评审和批准； ?作为项目扩展和产品升级的基础； ?其变更必须遵循《配置管理规程》的约定。 1.3 参考文献 《配置管理规程》 项目计划初稿 2 角色、职责与培训 2.1 角色与职责

2.2 CCB组成 3 配置管理活动 3.1 基线和配置项的标识 本项目的配置项和基线的名称和编号参见《配置项状态报告》。 项目初期，需要确定项目的配置项并对其进行标识。当新增或修改配置项时，同样需要对配置项进行标识。 本项目的配置项和基线的标识详见《配置项标识和状态列表》（基线的变更标识依照《配置管理规程》执行），该表包括配置项和基线清单及预计创建时间。 3.2 配置库结构和权限 3.2.1 配置管理库描述 本配置管理库作为CVS中的一个独立的源代码仓库（Repository），分成四个物理上互相独立的存储空间：产品空间、基线空间、组工作空间和个人空间，每个空间作为一个独立

的目录（用module实现）。产品空间属于产品库，基线空间、组工作空间的内容均属于受控库，个人空间的内容属于开发库。 产品空间：存放提交给用户的产品； 基线空间：存放所有基线内容。 组工作空间：存放经过评审的文档和所有不放入基线库的工作产品， 个人空间：项目组成员存放个人任何信息，文档的开发和修改均在个人空间进行。 从个人空间向组工作空间的提升由项目经理批准，从组工作空间向基线空间的提升由CCB评审批准，均由CM工程师执行。提升后删除原空间的配置项。 产品空间用Tag的方式标识不同版本的产品。 例如，软件需求规格说明书在编写或修改时，放到作者的个人空间进行管理，经过评审后，提升到相应的“211 需求规格说明书”目录中，形成基线后，再提升到“110 需求规格说明书”。 对于正在开发或修改的文档和代码，作者应至少每天做一次检入（commit）/检出（update）。SCM工程师进行组工作空间和基线空间的维护，每周做一次配置库的备份。要修改组工作空间和基线空间中的文档和基线时，变更申请人根据《变更控制规程》先向项目经理提交《变更请求报告》，由项目经理协调变更活动的执行。 表1. 库结构

CMMI中CM配置管理访谈的相关问题集锦

CM访谈 1．是否有独立的配置管理组？有组织级的配置管理员吗？ 有独立的配置管理组，有组织级的配置管理员 2．你是如何知道自己是项目中的配置管理员的？ 在项目立项会议上，由项目经理告诉我的。 3．什么是配置项？ 1、凡是纳入配置管理范畴的工作成果都是配置项。 2、配置项主要有两大类： （1）属于产品组成部分的工作成果； （2）项目中产生的管理类和支撑类文档。 3、每个配置项的主要属性有：名称、标识符文件状态、版本、作者、日期等。 4．项目中识别了哪些配置项？ 在项目立项后，我会根据《NT-CM-GUIDE-配置库目录结构及权限指南》来建立配置库，项目级的

项目文档经过审批后，进入基线库 6．每个项目都有CCB吗？通常由哪些角色组成？他们的职责有哪些？ 1、是的，每个项目都有CCB。 2、通常由客户、高层、项目经理、技术专家组成，质量保证人员也会参加。 3、主要职责是决定是否执行变更。 7．你是如何制定配置管理计划的？在什么时间？权限设置、目录结构设置？ 1、我和项目经理配合，分步定制出项目配置管理计划， 2、一般在立项之后，在项目计划制同时制定配置管理计划， 3、识别配置项，进而形成配置项管理计划 4、配置库结构，权限划分 5、编制基线管理计划（哪些基线，基线包括哪些基线项，什么时候创建） 6、配置审计计划 7、命名规约，版本控制，版本号规约，备份计划（灾难恢复计划） 8、制定完配置管理计划后，将这个计划交给项目经理审核。 权限设置、目录结构设置见第5题。 8．你参加过哪些方面的培训，是否给项目组、相关组做过配置管理方面培训？ 1、我参加过过程体系中配置管理过程培训、SVN工具的高级培训、沟通技巧等。 2、同时，我给公司所有人员做过SVN工具使用的培训，并且每个新进员工，我都会讲解如何使用 SVN工具进行版本控制。 9．配置管理计划包括哪些方面内容？是否发生过计划变更？如何进行变更？ 1、配置管理计划里主要包括角色和职责，用于配置管理的软硬件资源，配置库结构与权限，配置 项管理计划，基线管理计划，配置库备份计划等内容， 2、发生过计划变更 3、见第13题。 10．你是如何进行配置审计的，配置项状态有哪些？ 配置项审计主要包括1、物理审计：CPU占用率，内存占用率，硬盘占用率，网络利用率，备份日志是有异常等。2、功能审计，主要包括配置项命名审计，配置库目录结构审计，不恰当配置项审计，配置库权限审计，修订历史记录审计。3、基线审计，主要包括基线是否按照计划创建，已经创建的基线配置项是否齐全，一致，基线是否稳定，基线对应的变更是否关闭。 每两周定期的审计基线库中的所有配置项，每次基线发布前进行配置项目配置审计。配置项的状态为基线化，变更，新建 11．项目中建立多少条基线，在那里进行了描述？ NTOA：建立了9条基线，分别是需求基线，计划基线，需求基线2，设计基线，实现基线，实

基于CMM和CMMI的配置管理(一)

基于CMM和CMMI的配置管理（一） 1 配置管理内容的逻辑关系 在CMM和CMMI中，将配置管理的目的定义为“建立和维护产品的完整性”，这个目标没有提到对项目管理的支持，也就是说，它定义的配置管理的目标比当前业界对配置管理的认识有些缩小。但是，仔细分析可以发现“建立和维护产品的完整性”是其他配置管理目标的基础。下面就从这个目标出发进行分析。逻辑关系见下图： 配置完整性（对标准的理解） 1. 产品完整性：就是项目提交的工作成果是“产品集合完整、子产品的正确”的 2. 产品集合完整：产品包含的子产品（配置项）是完整的 3. 子产品的正确：子产品（配置项）达到了需求要求，满足标准、规程的要求

逻辑关系分析 1. “基线管理”支持“产品集合完整”，明确产品的“子产品”（配置项）集合，并进行管理和控制 2. “配置项管理”，提供了了对子产品（配置项）的控制管理，支持“子产品的正确” 3. “变更管理”，同时支持“产品集合完整、子产品的正确”，用于控制子产品（配置项）和产品（基线）的变更 4. “配置标示”，建立对配置项（子产品）的识别、命名，支持“配置项管理” 5. “版本控制”，控制配置项（子产品）生命历程，保留配置项（子产品）演进历史 6. “过程管理”，就是对配置项、基线的建立、变更的状态标示、过程控制，保证产品（或子产品）按照规定的流程进行了操作；例如“配置项”进入“基线”的过程包括：配置项标示、产品验证、进入配置、配置审计等 7. “配置计划”、“配置库管理”、“配置审计”、“配置报告”等是整个配置管理得支持系统。提供了配置管理“可视性”和监督管理 2 配置和配置项 在配置管理中，“配置”和“配置项”是重要的概念，“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性，其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素，相对与硬件类配置，软件产品的“配置”包括更多的内容并具有易变性。 受控软件经常被划分为各类配置项（Configuraion items, CIs），这类划分是进行软件配置管理的基础和前提，CIs是逻辑上组成软件系统的各组成部分。比如一个软件产品包括几个程序模块，每个程序模块及其相关文档和支撑数据可能被命名为一个CI。一个系统包

如何开展配置管理

如何开展配置管理--工具和方法漫述 收藏 文/谷雨霖 在CMMI和IEEE关于配置管理的正式定义是：软件配置管理是软件工程中的一项规程，包括相关工具和应用技术（过程或方法），公司用它来管理软件资产变更。 一般的来说，配置管理的主要目的是进行工作产品管理，其中包括各类文档、代码、版本、纪要、bug等等。但不要简单理解为，配置管理就是版本管理，配置管理是所有工作产品的管理。 如果一个组织缺乏配置管理，会有哪些问题？【以下8点描述，部分摘录互联网相关内容】 1、组织的知识和过程财富流失 现代的社会竞争激烈，人员流动频繁，如果由于没有必要的配置管理流程和工具，大量的文档和代码等知识财富必然缺乏统一的管理，可能随意地保存在项目经理和软件工程师各自的机器里，往往会因为硬盘的故障或人员的离职而永远的消失，软件组织的数字财富就这样因为缺乏必要的配置管理而白白的流失。 2、不能及时了解项目的进展状况 现代软件工程思想认为越早发现缺陷和风险，采取相应措施的代价越小。CMM /CMMI的一个重要作用就是要提高软件开发过程中的可视性，使得问题能够被及时的发现。然而由于缺乏配置管理的流程和工具的支持，部门主管无法确切得知项目的进展情况，即便是项目经理也不知道各个开发人员的具体工作，项目进展随意性很大。所有的问题往往都会集中到项目里程碑时一起出现，这必然会造成巨大的开销，其结果往往是容忍部分缺陷存在或者延误开发周期。所有问题只能寄希望于最终实施时再解决，项目的实施工作因此变成了无法汇报、无法理清、无休止的维护。 3、缺乏实现并行开发的手段 在日常的开发工作中，经常会出现并行开发的需求，比如：对于一个项目可能要在开发新版本的同时继续对先前的版本进行必要的维护，或者针对某个特定的版本需要针对不同的客户同时进行客户化的修改等等。在并行模式下，不同开发人员可以同时编辑修改某一文件，并行开发有可能产生冲突，但是却能够提高开发效率。如果没有配置管理工具的支持，进行并行开发将十分困难，单单通过人工操作，往往会造成修改过的bug 重复出现或者几个人进行相同的工作，产生不必要的浪费。 4、软件复用率低下 软件复用是现代软件工程中的重要思想，是提高软件产品生产效率和质量的重要手段。软件产品是一个公司的宝贵财富，代码的可重用性是相当高的，如何建好知识库，用好知识库将对公司优质高效开发产品产生重大的影响。但如果没有良好的配置管理流程，软件复用的效率将大打折扣，比如对于复用的代码进行了必要的修改或改进，却只能通过手工的方式将发生的变更传递给所有复用该软件的项目，效率如何可想而知。另外由于缺乏进行沟通的必要手段，各个开

(完整版)CMMI-支持-CM-配置库管理规程-V2.0

广州润衡软件连锁有限公司配置库管理规程 配置库管理规程 文档编号：GZCY_CMRMG_PRS-V1.0 文档信息： 文档名称： 文档类别：CMMI模板 密级：机密 版本信息：V1.0 建立日期： 创建人： 审核者： 批准人： 批准日期： 保管人： 存放位置： 编辑软件：Microsoft Office 2003 英文版 CONFIDENTIAL

文档修订记录 文档审批信息

前言 配置库是存储软件配置项和配置管理信息的仓库，本文详细介绍了配置库的组成和结构，以及SCM人员应如何分配各个区域的权限和初始化工作，保证置于配置库中的工作产品的得到有效控制。

目录 第一章简介 (1) 1.1 目的 (1) 1.2 适用范围 (1) 1.3 术语表 (1) 1.4 参考资料 (1) 第二章配置库的构成 (2) 2.1 各区域构造规则 (2) 2.1.1 基线区域目录结构 (2) 2.1.2 开发区域目录结构 (4) 2.1.3 管理区域目录结构 (5) 2.1.4 测试区域目录结构 (5) 2.1.5 发布区域目录结构 (5) 第三章配置库管理方法 (7) 3.1 SCM人员职责 (7) 3.2 基线区域管理 (7) 3.2.1 更改权威 (7) 3.2.2 变更流程 (7) 3.3 管理区域管理 (7) 3.3.1 基线管理区域 (7) 3.3.2 项目管理区域 (8) 3.4 测试区域 (8) 3.5 发布区域 (8) 第四章配置项标识命名规则 (9) 4.1 语法 (9) 4.2 语法注释 (9)

4.3 基线标识表 (9) 4.4 补充基线标识............................................................................. 错误!未定义书签。 4.5 举例 (10) 第五章版本标识 (11) 5.1 文件版本标识 (11) 5.2 配置项版本标识 (11) 5.3 基线版本标识 (11) 第六章配置库的备份 (13)

cmmi3访谈问题列表forcm

CM访谈 1．是否有独立的配置管理组有组织级的配置管理员吗 是的，我既是组织级，又是项目级的配置管理人员。 （林芳即是组织级又是项目级的配置管理员、汪倩媛是项目级配置管理员） 2．你是如何知道自己是项目中的配置管理员的 在项目启动会上，由项目经理告诉我的。 3．什么是配置项 配置项是项目中一些重要的工作产品，当需求开发完成后，由我和项目经理共同识别项目中配置项，主要判断标准是：（1）需要两个或两个以上的人共同参考的数据，例如《配置管理计划》《质量保证计划》《测试计划》等；（2）当变更发生时，这些数据的变更可能会影响项目中的成本，进度或质量的数据，例如《需求规格说明书》、《概要设计说明书》等。 4．项目中识别了哪些配置项 项目中识别的配置项有： 5．你是如何建立配置库的及如何分配权限 在项目立项后，我会根据《配置管理计划》来建立配置库，项目级的配置库目录结构如下图：

注：记下这个图，在访谈的时候到这个目录结构讲出来 第一级是项目名称，二级目录分为五个库，分别是：01-编辑区，02-测试区，03-基线区04-管理区05发布区，他们的作用分别是： 1、01-编辑区中主要由存放项目中工程过程的数据（包括需求、设计、编码、测试）； 2、04-管理区主要存放项目过程中管理类的文档（包括周报、周例会、里程碑报告、配置管理、质量保证等），01和 04目录这里所有项目组的人都有读，删，写的权限； 3、03-基线区主要是将评审通过后的配置项，由配置管理人员纳入到基线库；基线区主要是存放一些项目中重要的工 作产品的稳定版本，相当于在公司内部的一个数据发布，这里配置管理人员与高层有进行读，删，写,项目组成员只读权限， 4、02-测试区是存放一些内部测试的版本，只有测试人员、配置管理人员有进行读，删，写的权限，其它人员，没有。 5、05-发布区是存放一些对外发布的产品，“05-发布区”只有配置管理人员有进行读，删，写的权限，其它人员，没 有。 需了解“配置管理计划与状态报告”中的“Sheet: 权限说明”，了解目录结构以及权限说明。 6．每个项目都有CCB吗通常由哪些角色组成他们的职责有哪些 是的，CCB通常由客户、高层和项目经理组成，主要职责是决定是否执行变更。 7．你是如何制定配置管理计划的在什么时间权限设置、目录结构设置 是的，在项目计划制定时，我同时也制定了配置管理计划，主要是识别配置项，建立配置库，分配权限，制定基线计划等工作。制定完配置管理计划后，将这个计划交给项目经理审核 8．你参加过哪些方面的培训，是否给项目组、相关组做过配置管理方面培训 我参加过组织级提供的组织标准过程(OSSP)体系、配置过程培训、SVN工具的培训、配置计划制定的培训、沟通技巧等。培训效果最好的是SVN工具的培训。同时，我给公司所有人员做过SVN工具使用的培训，并且每个新进员工，我都会讲解如何使用SVN工具进行版本控制。 9．配置管理计划包括哪些方面内容是否发生过计划变更如何进行变更 配置管理计划里主要包括识别配置项，建立配置库，分配权限，制定基线计划等工作。当需求或配置项发生变更时，由项目经理进行变更分析，当因变更而引起的配置项修改时，我们会重新评审修改的配置项，增加版本号，然后发布，最后将这些配置项重新入基线库。 10．你是如何进行配置审计的，配置项状态有哪些 每次基线发布前进行配置项目配置审计和状态统计，定期审计基线库中的所有配置项，审计的主要内容是配置项的版本，配置项的入库时间，配置项的存放路径，及发现的问题描述；状态统计主要是统计基组库中所有配置项目版本，配置项的状态，配置项的变更次数等等。配置项的状态为首次纳入基线、变更、此次基线未变更 11．项目中建立多少条基线，在那里进行了描述 项目共建立了9条基线，分别是计划基线，需求基线，概要设计基线，详细设计基线，编码基线，单元测试基线，集成测试基线，系统测试基线，上线发布基线。在《配置管理计划与状态报告》、项目的基线区中对基线进行描述。 其中： 项目1：在概要设计阶段发生需求变更，因此另外建立需求基线变更 项目2：在编码阶段发生需求变更，因此分别建立需求基线变更、概要设计基线变更、详细设计基线变更 项目3：在编码阶段发生需求变更，因此分别建立需求基线变更、概要设计基线变更、详细设计基线变更 12．如何建立基线，发布基线报告通过哪几种方式告知相关组 我根据基线建立申请在项目的每个阶段来建立基线，建立一条基线后，我会将基线库中所有的配置项及版本，入库时间等信息统计到《基线建立通知单》中，然后用EMAIL的形式发给项目组所有人员。