SCMS软件配置管理过程
C M M文件软件配置管理过程
XXXXXXXXXXXX
(版权所有,翻版必究)
文档变更请求(DCR)
文档变更记录
目录
1 概述 (1)
1.1 目的 (1)
1.2 范围 (1)
1.3 术语与定义 (1)
1.4 参考文档 (1)
1.5 引用文档 (2)
2 过程目标 (2)
3 过程定义 (2)
3.1 责任人 (2)
3.2 输入 (3)
3.3 入口准则 (3)
3.4 过程活动 (3)
3.5 出口准则 (6)
3.6 输出 (6)
附录 A ：软件配置项/产品包标识 (8)
A.1 文档的编号 (8)
A.2 程序的名称 (9)
A.3 软件产品包的标识 (9)
A.4 系统、数据库、开发与支持软件工具的编号 (9)
附录 B ：配置项状态报告 (10)
B.1 系统软件、数据库、开发与支持软件工具列表 (10)
B.2 软件基线/配置项状态报告 (10)
B.3 软件基线软件基线变更报告 (10)
附录 C ：软件配置管理测量报告 (11)
1概述
1.1目的
软件配置管理（简写为SCM）是维护项目软件整个生命周期产品完整性的重要活动，本文档明确规定了公司软件配置管理活动的目标和过程定义，为公司软件配置管理提供所遵循的过程、程序和指导方针。
1.2范围
本文档适用于管理公司所有软件项目在各阶段标识的软件配置。软件配置管理的大部分活动用“软件配置管理工具”实现。
1.3术语与定义
1.3.1软件工作产品：作为定义、维护或应用软件过程的一部分所生成的任何人工制品，包括过程描述、
计划、规程、计算机程序和相关文档，这些可能交付也可能不交付给顾客或最终用户。
1.3.2软件基线：软件配置项经软件验证、确认、评审和认定后，形成了软件基线，也就成了该阶段的一
个基准。下一个阶段只能在这个基准上进行开发活动。
1.3.3软件配置项：是指一个软件产品在软件生存周期各个阶段所产生或应用的各种形式（机器可读或人
工可读）和各种版本的文档、程序及其数据。
1.3.4SCCB：软件配置管理委员会（Software Configuration Control Board）（关于责任，参见“责任
人”）。
1.3.5SCM：软件配置管理(Software Configuration Management) 包括了标识软件工作产品、控制对
软件工作产品的更改、和维护在整个软件生存周期中的软件工作产品的完整性和可跟踪性。
1.4参考文档
1.4.1Mark C. Paulk，Bill Curtis，Mary Beth Chrissis，Charles V. Weber，Capability Maturity Model for
Software （Version 1.1）
1.4.2Roger S. Pressman，Software Engineering –A Practitioner’s Approach (Fourth Edition)
1.4.3《计算机软件配置管理计划规范》GB/T 12505-90
1.4.4《变更请求处理规程》(CMM-SCM-DU1)
1.4.5《软件质量保证过程》(CMM-SQA-SS)
1.4.6《软件工程管理方法》
1.4.7《文件管理制度》
1.4.8模板汇编
2过程目标
需求管理目的是建立和维护在项目的整个软件生命周期中软件项目产品的完整性，其主要目标是：
●软件配置管理活动是有计划的；
●所选定的软件工作产品是已标识的、受控的和适用的；
●对已标识的软件工作产品的更改是受控的；
●受影响的组和个人得到软件基线的状态和内容的通知。
3过程定义
3.1责任人
3.1.1SCCB分两个层次——项目层与管理层；
3.1.1.1成员包括：
●项目层：项目经理、技术成员、分析成员、测试成员等；
●管理层：总经理室成员（如有必要）、事业部总经理/经理、客户经理、市场分析部成员
等。
3.1.1.2文档内所描述的SCCB评审是指项目层的SCCB 的评审。如有项目层的SCCB 所不能决定
的事情，再通过管理层SCCB 评审。SCCB 负责：
1)代表项目经理和所有可能受到软件基线更改影响的组的利益；
2)审定软件基线的建立和配置项的标识；
3)评审和审定对软件基线的更改；
4)审定由软件基线制造的产品的生成。
3.1.2项目SCM 经理：负责项目中的SCM 活动：
1)制定、维护和散发“软件配置管理计划”、SCM 标准与规程；
2)标识将置于SCM 之下的软件工作产品；
3)记录SCM 的活动；
4)生成和散发SCM 报告；
5)管理与操作软件基线与软件配置管理库的日常工作；
6)周期性地审核项目的软件基线以验证他们与定义是否一致。
软件配置项，如：
●对外可交付的软件工作产品；
●指定的内部软件工作产品；
●指定在项目内部使用的系统、数据库、开发与支持软件工具。
3.3入口准则
3.3.1已经确立SCCB与项目SCM 经理；
3.3.2有支持软件配置管理的设施；
3.3.3准备受控的配置项已经通过相应的审批；
3.3.4项目SCM 经理、软件项目组和其它软件有关组的成员受到培训，以便完成软件配置管理活动。
3.4过程活动
3.4.1配置管理计划
3.4.1.1项目SCM 经理按照“软件配置管理计划模板”制定项目的“软件配置管理计划”。“软件
开发计划”可包含此计划，不必有单独的软件配置管理计划。
3.4.1.2“软件配置管理计划”必须通过软件项目组、SCCB 与SQA 的评审。
3.4.1.3项目SCM 经理按照此文档中“3.4.5 软件基线”，把经过审批的“软件配置管理计划”
纳入分配基线。
3.4.1.4项目SCM 经理依据“软件配置管理计划”执行项目中的软件配置管理活动。
3.4.2软件配置项标识
3.4.2.1《软件工程管理方法》文档中具体描述
●置于配置管理之下的的软件工作产品；
●配置项的特征；
●制作或管理配置项的负责人。
3.4.2.2项目SCM经理确保软件项目组按照“附录 A：软件配置项/产品包标识”给每个配置项唯
一的标识符。如软件配置项的标识不按照此文档，软件配置项的标识必须通过SCCB 的审
定。
3.4.3配置项的状态
3.4.3.1项目SCM经理应记录和维护在项目内使用的系统、数据库、开发、支持软件工具和产生的
文档与其它配置项（参见附录B：配置项状态报告）。
3.4.3.2项目SCM经理可使用“配置管理工具”记录配置管理行动，能清楚的理解每个配置项的状
态（如：最新版本），而且能恢复以前的版本。
3.4.4.1按照“变更请求处理规程”记录、评审、批准和跟踪所有配置项的变更请求和问题报告。
3.4.4.2配置项的变更历史必须记录在配置项内，包括日期、版本号、变更请求号、修改人和变更内
容。
3.4.5软件基线
3.4.5.1下面是软件基线的定义与所属的配置项：
3.4.5.2项目SCM 经理可使用“软件配置管理工具”建立软件配置管理库，管理软件基线。
3.4.5.3软件基线必须先通过SCCB 与项目SCM 经理的评审和审定，再保存到软件配置管理库。
3.4.6.1当软件基线内的配置项有所变更，项目经理应决定是否需要进行回归测试，以保证更改不会
对基线造成未料到的影响。
3.4.6.2相关的软件基线必须通过SCCB与项目SCM 经理的评审和审定，重新建立软件基线。
3.4.7软件配置项与基线版本
3.4.7.1用下列表定义软件配置项与基线的版本号：
3.4.8由软件基线制造的产品包
3.4.8.1产品包是指提供给最终用户的文档资料与可执行程序等。
3.4.8.2从产品基线中创建的产品包必须经过SCCB 的审批。
3.4.8.3项目SCM 经理将根据产品基线中的内容建立产品包，按照“附录A：软件配置项/产品包
标识”给产品包唯一的标识符。如产品包的标识不按照此文档，则必须通过SCCB 的批准。
3.4.9软件基线审计
3.4.9.1项目SCM经理可以“软件配置管理计划”为基础，用“软件基线审计表格”在软件基线建
立或变更后，对软件基线进行审计，以验证软件基线的配置项是否与定义一致。
3.4.9.2项目SCM经理应向软件项目经理或相关人员报告审计结果，并跟踪来自审计的措施条款直
至结束。
3.4.10软件配置管理库
3.4.10.1软件配置管理库必须设置权限。只有项目组、项目SCM经理、SCCB、SQA与项目SCM经
理认定的相关成员能访问软件配置管理库，进行相应的操作。
3.4.10.2软件配置管理库分为三个库：
●开发库：供开发使用的工具库，由项目组管理与维护；
●受控库：保存应被审定的软件配置项，由项目SCM经理管理与维护；
●产品库：保存可以发行的软件产品的各个发布版本，由项目SCM经理管理与维护。
3.4.11软件配置管理活动的报告
3.4.11.1项目SCM经理应编制以下的软件配置管理活动的报告，并通报给相关成员，如：软件项目
组、SCCB和SQA。
3.4.12测量
3.4.12.1项目SCM经理应编制测量报告（参见附录C），内容包括：
●SCM 活动的完成情况与计划比较；
●SCM 活动中完成的工作，花费的工作量及消耗的资金。
3.4.13评审
3.4.13.1项目经理与高级管理者可用“管理评审表格”定期评审软件配置管理活动，高级管理者还可
通过项目经理提交的“项目周报”进行评审。
3.4.13.2SQA对需求管理活动与工作产品的评审，参见《软件质量保证过程》。
3.5出口准则
软件工作产品已经置于软件配置管理库。
3.6输出
软件配置管理
软件配置管理（Software configuration management，SCM） 目录 软件配置管理 (1) 什么是软件配置管理 (2) 配置管理的任务 (2) 实施软件配置管理的优点 (2) 配置软件管理实施的流程 (3) 软件配置管理与CMMI (4) 软件配置管理案例分析 (4) 案例：配置管理在软件企业中的应用 (4)
软件配置管理(SCM)是一种标识、组织和控制修改的技术。软件配置管理应用于整个软件工程过程。SCM活动的目标就是为了配置管理是对产品进行标识、存储和控制，以维护其完整性、可追溯性以及正确性的学科。目的是使错误降为最小并最有效地提高生产效率。 1.维护和编制公司配置管理规划、流程和策略。 2.负责日常运行维护及系统优化，负责配置管理工作，包括权限分配、基线管理、版本管理、变更管理、配置审计等;负责配置管理报告的编写和分析。 3.监督和审核项目过程中配置管理规范的实施情况,为项目组提供配置管理流程、工具方面的咨询、培训和支持，参与公司产品及体系认证与维护工作 4.负责建立和优化公司配置管理的相关规范和流程并进行相关推广。 不断优化公司配置管理方法和工具 (1)定义配置项：软件配置项(SCI)即软件配置管理的对象。软件开发过程中产生的所有信息构成软件配置，它们是：代码(源代码、目标代码)以及数据结构(内部数据、外部数据)、文档(技术文档、管理文档、需方文档)、报告，其中每一项称为 (2)标识配置项：正确标识软件配置项对整个管理活动非常重要，对软件开发过程中的所有软件项目赋予唯一的标识符，便于对其进行状态控制和管理。 (3)定义基线：基线标志着软件开发过程一个阶段的结束，任一软件配置项，一旦形成文档并审议通过，即成为基线。基本的作用在于把各阶段的工作划分得更明确，使本来连续的工作在这些点上断开，以便检验和肯定阶段成果。 (4)定义软件配置库：软件配置库内容涵盖开发的全过程. 实施软件配置管理的优点 ?节约费用：缩短开发周期、减少施工费用 ?利于知识库的建立：代码对象库、业务及经验库 ?规范管理：量化工作量考核、规范测试、加强协调与沟通。
ITIL实战之配置管理解决方案
ITIL实战之配置管理解决方案 作者:破子这里就不对配置管理的一些基本知识做解释了，类似的文章挺多，这里直面配置管理深入一些的内容，我在这家公司工作了三年，很少象这样需要开动所有脑力去思考一件工作，配置是一个很重要的基础，同时也是让我耗费脑力最多的一块，所以先把它写下来。先介绍一下我们的业务情况，我们公司的运维项目较多，有网络、系统的、桌面的、软件的，而且这些项目用到的设备都存在共用的情况，比如一个段线路，会属于多个项目使用，一台客户的电脑，也可能装有多个管理软件，同时它又是属于桌面运维的，这些我们的IT组件一是数量多（光是需要桌面运维的电脑台数在5000台以上），二是相互的关系复杂。 我现在所讲的，是经过很多思考与折腾后，所整理出来的，我对配置管理的出发点，是从软件实现方面考虑的，这可能与其它的公司有一些不一样，一开始，在思考整个配置的模型，也是CMDB的业务层面逻辑，很长一段时间，在CI的结构与关系方面，我一直无法理清楚，因为当CI的结构是怎样，关系是怎样不确定前，整个模型根本无从建立。最开始首先确定的是，我决定把CI的结构与关系分离，即结构是结构，关系是关系，两者不互为影响，作用也各自不同，这个想法应该是比较大胆的，而且这是在我对ITIL不熟悉的情况做出的决定，如果这个做法错误，后续的很多工作都会受到影响。 决定后，剩下来就是攻破结构与关系了。在那段时间的思考中，CI的结构是首先想通的，可能是因为以前是做ERP实施的关系，也可能是因为客户是汽车制造商的关系，最终我发现将CI组装时，它的呈现很象ERP中的BOM结构，这是个父子结构，它可展开任意的节点，这种结构具有很大的扩展空间，也解决了配置管理颗粒度大小变化的问题，经过几天的思考后，我已非常确定这个思路可以解决我们的CI结构问题。 剩下的关系是花的时间比较久的，查了不少资料，我一直想确定到底CI之间有哪几种关系，这本身我一直觉得这个ITIL的推广组织本身需要制定或想通的，而不应该由我来思考，我也看了常态下象IBM他们的做法，但他们关系与结构是互为一体的，而且他们对关系的定义简单了些，所以最后没有采用。在思考CI的关系时，我甚至上升到哲学的层面，去思考人与人之间的关系有哪一些，事物与事物之间的关系有哪一些，看是否能对得出CI之间的关系有一些启发作用，也在网上查了很多关于事物关系的说明，可惜没有找到有用的说明资料。 最终找到一个解决方法，是一个周五下午快下班的时候，当时正在画一个示意图，想向领导表达，日后如果我们完成配置的结构与关系构建后，呈现给我们的是一个怎样的东西，当时只把CI抽象成几个集合，CI是用一个圆圈图示代替，在画了几个图示后，突然有一点灵光闪过，我发现当把几十万个CI用这样方式串联起来时，象一个个灯泡一样，有的亮有的不亮，通过关系将这数量庞大的灯泡连接起来时，这种情况好像电路图，每一个CI位于一个
软件配置管理过程指导说明书(超级实用)
软件配置管理过程指导说明书
目录 1 前言 (2) 1.1 目的 (2) 1.2 适用范围 (2) 1.3 术语名词解释 (2) 2 角色和职责说明 (3) 3 输入 (4) 4 入口准则 (4) 5 配置管理实施 (4) 5.1 配置库结构 (4) 5.1.1 配置库 (4) 5.1.2 配置管理库系统 (6) 5.2 配置管理流程 (6) 5.2.1 配置管理流程图 (6) 5.2.2 配置变更流程图 (7) 5.3 配置标识 (8) 5.3.1 配置库划分 (8) 5.3.2 配置库结构 (8) 5.3.3 配置项命名 (11) 5.3.4 版本编号规范 (11) 5.4 配置管理活动 (12) 5.4.1 制定配置管理计划 (12) 5.4.2 建立配置库 (12) 5.4.3 建立配置项 (12) 5.4.4 基线建立及发布过程 (12) 5.4.5 配置变更 (13) 5.4.6 配置审计 (15) 5.4.7 备份 (16) 6 输出 (16) 7 出口准则 (16) 8 本过程裁剪规定 (16)
1 前言 1.1 目的 用于描述配置管理作用和过程，规范配置管理的实施过程、活动和操作。 1.2 适用范围 适用于在软件生命周期中对各类软件项目的配置管理活动。 1.3 术语名词解释 CCB：Configuration Control Board，配置管理委员会，每个项目组需要建立项目级的CCB作为变更控制权威。CCB由质量工程师、项目经理、测试经理、配置管理员构成，有时也可以包括客户代表、上级质量部门主管。CCB组长可以是质量工程师或质量部领导，但不能是项目经理。 软件配置项：是指软件工程过程中所生产或使用的任何元素，或者是纳入软件产品的元素。它可以是说明书、计算机程序、数据结构或者开发软件产品所使用的工具等，包括：项目文档，源代码，执行程序，相关设备及资料。 软件配置管理：对软件配置项的管理称为软件配置管理。软件配置管理的目的是建立和维护软件项目整个生命周期中工作产品的完整性和可追溯性。 软件工作产品：由定义、维护和使用一个软件过程所产生的任何人工制品，包括过程描述、计划、规程、计算机程序和相关文档，无论是否打算将它们交给客户或最终用户。 软件产品：可交付给客户或最终用户的软件工作产品的子集称作软件产品 基线：基线，是开发过程中标识出的里程碑所交付的一个或多个配置项，也即指一个（或一组）配置项在项目生命周期的不同时间点上通过正式评审而进入正式受控的一种状态它有如下特征：（1）已经过正式的评审和批准；（2）作为项目发展和产品升级的基础。（3）基线变更必须经过CCB审批。 变更控制：对配置项的更改进行评价、协调、认可或不认可以及执行更改的过程。 版本发布：指从项目的配置库中将需交付给客户的所有配置项组装成一个完整的软件产品。即交付给客户的一个包括可执行程序和文档的发布基线称为发布（release）。 配置审计：可以分为物理审计和功能审计。物理审计审查配置项的外在特征的正确性与一致性，主要考查软件受控库的结构、内容及其它相关信息，以验证基线和描述它的文档的一致性；功能审计审查配置项内容的正确性与一致性，主要考核配置项在实现功能上的一致性，功能审计主要通过评审和测试报告体现。 物理审计的内容包括： ? 确认配置项标识的正确性； ? 确认已受控配置项的更改是受到控制的； ? 验证配置库内容与相应记录之间的一致性； ? 验证配置管理活动与相应记录之间的一致性； ? 验证配置管理工作是否符合适用的标准和规程； ? 验证配置管理系统与系统备份的有效性、一致性等。 功能审计的内容包括： ? 验证当前基线所含配置项对前一基线所含配置项的追溯性； ? 确认当前基线所含配置项均正确反映了项目需求； ? 评估基线的完整性； ? 验证当前基线和各基线间所含配置项的一致性； 验证配置库内容的完备性和正确性等。
软件开发项目配置管理工具的选择
软件开发项目配置管理工具的选择 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报…… 每一个软件项目，无论是工程类项目，还是产品类项目，都必须经历需求分析、系统设计、编码实现、集成测试、部署、交付、维护和支持的过程。在这个过程中，将生成各种各样不同的工件，包括文档、源程序、可执行代码、支持库。更可怕的是，频繁出现的变更是不可避免的，因此面向如此庞大且不断变动的信息集，如何使其有序、高效地存放、查找和利用就成为了一个突出的问题。 针对这一问题，最早的开发人员尝试过的解决办法是通过手工来实现： 1)文档：每次修改时都另存为一个新的文件，然后通过文件名进行区分，例如"XXX 软件需求说明书V1.0，XXX软件需求说明书V1.1，XXX 软件需求说明书V2.0."，并且在文件中注明每次版本变化的内容； 2) 源代码：每次要修改时就将整个工程目录复制一份，将原来的文件夹进行改名，例如"XX 项目V1.0、XX 项目1.01、."，然后在新的目录中进行修改； 但是这种方法，不仅十分繁琐，容易出错，而且会带来大量的垃圾数据。如果是团队协同开发或者是项目规模较大时，还是会造成很大的混乱。很显然，这样简陋的方法是无法应对这一问题的。后来，有人尝试从制造工业领域引入了"配置管理"这一概念，通过不懈的研究与实践，最终形成了一套管理办法和活动原则，这也就是软件配置管理。 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报。 常见的配置管理工具 正如前面所述，由于软件配置管理过程十分繁杂，管理对象错综复杂，如果是采用人工的办法不仅费时费力，还容易出错，产生大量的废品。因此，引入一些自动化工具是十分有裨益的，这也是做好配置管理的必要条件。 正是因为如此，市场上出现了大量的自动化配置管理工具，这些工具的实现原理与基本机制
软件配置管理计划模板
卷号DEPLOY 卷内编号DEPLOY005 密级组内 HD20090917SR005 通用型行政审批服务协同管理平台 配置管理计划 1.2 项目承担部门：java第四组 撰写人（签名）：区允文 完成日期：2010年8月4日 本文档使用部门：■主管领导■项目组 □客户（市场）□维护人员□用户 评审负责人（签名）：江威龙 评审日期：2010/8/4
目录 1.简介4 1.1目的4 1.2范围4 1.3定义、首字母缩写词和缩略语4 1.4参考资料4 1.5概述4 2.项目配置4 2.1组织结构4 2.2职责和接口5 2.3工具、环境和基础设施5 3.配置管理活动6
3.1配置库6 3.1.1配置库架构6 3.1.2权限分配7 3.1.3配置库层次及开发活动说明：8 3.2配置标识9 3.2.1标识方法9 3.2.2项目基线10 3.3配置项11 3.4配置和变更控制11 3.4.1变更请求的处理和审批11 3.4.2变更控制委员会 (CCB)11 3.4.3变更过程中的活动11 3.4.4变更过程中的变更请求状态12 3.4.5保存变更历史记录13 3.4.6变更请求中受影响配置项的变更13 3.5配置状态统计14 3.5.1项目介质存储和发布进程14 3.5.2报告和审计14 4.里程碑15 5.培训和资源15 6.分包商和厂商软件控制15 7.附录15
配置管理计划 1.简介 1.1目的 为了使项目相关的各种资源便于查看，修改，不至于凌乱；为了让各个开发人员方便高效地协同合作；为了项目的版本便于管理，作出此配置管理计划。 1.2范围 项目进行中所得出的所有工件都要遵守此计划，包括文档以及源代码，以及硬件。 1.3定义、首字母缩写词和缩略语 CM：配置管理。 CCB：变更控制委员会。 CI：配置项。包含文档、程序。 Baseline：基线。 CR：变更请求。 PCA：物理审计。 FCA：功能审计。 1.4参考资料 《华南农业大学软件学院实训讲义》 《华南农业大学项目阶段评审工件》 1.5概述 此文档对项目开发过程中的配置方面作出约束，开发以及变更都要按照要求来做。 2.项目配置 2.1组织结构
软件配置管理流程
配置管理流程规定 (Ver1.0) 拟制：___________________ 审核：___________________ 签发：___________________
目录 1.配置管理流程 (3) 1.1概述 (3) 1.2总体流程图 (3) 1.3软件需求分析阶段 (4) 1.4软件设计阶段 (4) 1.5制定配置管理计划 (4) 1.6配置库管理 (4) 1.6.1相关人员分配权限 (4) 1.6.2配置项 (5) 1.7版本控制 (6) 1.8变更控制 (6) 1.9配置审计 (8) 1.9.1配置审核的类别 (8) 1.9.2配置审核执行的时机 (8) 1.9.3不符合项的处理 (8) 2.0.0配置状态报告 (8) 2.0.1配置状态报告的目的 (8) 2.0.2配置状态报告记录的内容 (8) 2.0.3配置状态报告的生成 (9) 2.1.0发行管理 (9) 2.1.1交付管理 (9) 2.软件基线化规范 (10) 2.1正常开发期 (10) 2.2版本发布期 (11) 2.3项目发布期 (13) 3.Jira配置管理 (14)
1.配置管理流程 1.1概述 规范配置管理活动，确保配置项正确地唯一标识并易于存取，保证基准配置项的更改受控，明确基线状态，在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2总体流程图
1.3软件需求分析阶段 参加需求分析会议，配置管理负责人记录，有关文档提交归档。如《需求分析》。 1.4软件设计阶段 参加设计阶段，为了详细制定配置管理计划。针对需求分析报告进行系统设计，配置时应说明系统设计的版本与需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。 1.5制定配置管理计划 配置管理员制定配置管理计划，主要内容包括配置管理软硬件资源、配置项计划、备份计划等，审批该计划。 1.6配置库管理 配置管理员为项目创建配置库，并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 1.6.1相关人员分配权限 项目经理： 1)与(有关负责人员)协商确定项目起始基线 2)接受配置管理计划，并按相关规定贯彻执行； 3)接受配置控制委员会的报告。 4)提出配置管理计划的修改要求； 5)提出管理管理的建议和要求。 配置管理员 1)编制配置管理计划； 2)执行配置项管理； 3)执行版本控制和变更控制方案； 4)编制配置状态报告； 5)配置库的建立和权限分配； 6)配置管理工具的日常管理与维护； 7)配置库的日常操作和维护 开发人员
福师《软件过程管理》练习题及标准答案
软件过程与软件管理课程复习题 (一)解释相关概念或术语 1)软件工程 ●是指导软件开发和维护的工程类学科，它以计算机科学理论及其他相关学科的理论为指导，采用工程化的概 念、原理、方法和技术，进行软件的开发和维护，并与经过时间证明正确的管理方法与措施相结合，以较少的代价获取高质量的软件。 ●The IEEE Computer Society：是(1) 将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过 程，即将工程化应用于软件中。(2) 对(1)中所述方法的研究。 2)软件过程 ●软件过程是指软件开发人员开发和维护软件及相关产品（如项目计划、设计文档、代码、测试用例、用户手 册等）的一套行为、方法、实践及变换过程 ●根据IEEE对软件过程概念的解释，软件过程涵盖了软件采购、软件开发、软件维护、软件运行、软件获取、 软件管理、软件支持等7大类的软件活动 ●ISO12207分别将这些活动归结为基本过程、支持过程和组织过程等3大类 3)软件过程工程 为建造软件过程所进行的一系列工程化活动，包含如下基本活动：过程定义、过程例化、过程模拟、过程运作。 现代软件工程=软件项目工程+软件过程工程，这标志着软件过程的时代的到来。 4)软件配置管理 SCM是标识和确定系统中配置项的过程，在系统整个生命周期内控制这些项的投放和变动，记录并报告配置的状态和变动要求，验证配置项的完整性和正确性（GB/T11457-1995软件工程术语）。 针对SCM在软件生命周期各阶段所起的作用，一个完整的SCM环境要求具有版本控制、变更管理、状态统计、和配置审计的功能。 5)CMM CMM是指“能力成熟度模型”，其英文全称为Capability Maturity Model for Software，英文缩写为SW-CMM，简称CMM。它是对于软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。CMM 的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化、使企业能够更好地实现商业目标。 6)CMM中的关键过程域 每个软件能力成熟度等级包含若干个对该成熟度等级至关重要的过程方面，它们的实施对达到该成熟度等级的目标起到保证作用。这些过程域就称为该成熟度等级的关键过程域。 ●确定了实现一个成熟度级别所必须解决的问题 ●处于级别3的机构，必须解决级别2和级别3的所有关键过程域中的问题 ●每个关键过程域都确定了一套相应的活动，完成了这些活动，就达到了被认为是对改进过程非常重要的一组 目标 ●目标说明了每个关键过程域的范围、界限和意义 ●对于满足关键过程域的机构，一个关键过程域的所有目标都必须实现 ●每个关键过程域的目标总结了它的关键实践 7)CMM中的关键实践 是指关键过程域种的一些主要实践活动。每个关键过程域最终由关键实践所组成，通过实现这些关键实践达到关
软件开发管理制度
软件开发管理制度 为加强对公司软件研发部门工作管理，缩短开发周期，提高软件开发质量，降低开发成本，提高开发效率，特制定软件研发部管理制度。 第一章、总则 为保证日常工作正常有序的进行，让开发中各个环节更紧凑，更可控，需要尽可能实现软件研发部项目管理的正规化，工作过程的流程化，以便提高软件质量和开发效率，达到项目能按质按量按期交付的目标。 1、软件开发总体遵循项目管理和软件工程的基本原则。 2、项目管理涉及项目立项、项目计划和监控、配置管理。 3、软件工程涉及需求分析、系统设计、软件实现、系统测试、用户测试、试运行、系统验收、系统上线和数据迁移、产品维护。 第二章、阶段成果 根据软件工程的过程理论并结合公司目前的实际情况，制定以下工作流程，并规定了各个重要环节需要提交的交付物。 1、立项：市场需求分析（或者合同）、项目立项申请表、项目风险分析清单。 2、需求分析：软件需求报告或设计方案、需求规格说明书。 3、总体设计：概要设计说明书或功能模块描述。 4、详细设计：详细设计说明书，包括软件接口说明、单元测试计划。 5、软件实现：软件功能说明、源代码、源代码说明或者注释 6、产品测试：测试报告 7、产品发布：产品说明书、使用手册 8、产品维护：问题反馈记录 9、项目总结：提交客户方的项目总结和公司项目汇报的PPT。 软件过程成果表：
第三章、岗位设置 根据公司目前的开发过程主要分为分析、开发、测试三个阶段。分析阶段完成用户需求文档的编写，系统总体设计的编写；开发阶段完成设计文档的编写，代码的编写、代码的维护。测试阶段完成系统的测试，测试文档及其他材料。通过逐渐的调整岗位，明确工作职责，逐步实现项目经理，需求分析工程师，高级软件开发工程师，软件开发工程师，测试工程师的岗位设置。
软件项目配置管理计划
中国广东核电集团 CHINA GUANGDONG NUCLEAR POWER GROUP 记录文件 项目编号 项目名称 CGN-IT-C3-A12-01 软件项目配置管理计划 版本编写审核审定批准生效时间A/0 注：如无受控文件标识（蓝色印章）则为非有效版本，以受控文件规定为准。 此文件属中国广东核电集团有限公司所有，未经许可，不得以任何方式外传。
修改记录页
目录 (一)基本信息错误!未定义书签。 (二)角色与职责错误!未定义书签。 (三)配置管理资源错误!未定义书签。 (四)权限分配错误!未定义书签。 (五)配置项计划错误!未定义书签。 (六)配置库基线错误!未定义书签。 (七)配置库备份计划错误!未定义书签。 (八)配置库状态报告错误!未定义书签。 (九)配置审核错误!未定义书签。 (十)审批意见错误!未定义书签。
配置管理计划 基本信息 项目名称： 项目代号： 立项时间： 预计主要项目阶段有： 配置项目命名规则依据： 角色与职责 配置管理资源 本项目使用配置管理工具对各配置项进行存储、版本管理，并提供更新、检索和历史版本的恢复。 提示： （1）配置管理员确定本项目的配置管理软件。例如采用Microsoft公司的TFS或者IBM公司的clearecase。
（2）配置管理员根据所采用的配置管理软件，确定计算机资源（考虑内存、外存、CPU等）。 预计建库申请日期： 预计建库日期： 预计工作库需空间： 权限分配 项目成员访问配置库的ID及PASSWORD默认设置为与域帐号的设置相同。 若个人要求另行设置的，由项目组配置管理员负责汇总后，提交给高级配置管理员调整设置。
实验六 软件配置管理
实验六软件配置管理 一、实验目的 1.了解配置管理的基本概念和相关技术。 2.初步掌握项目管理软件Microsoft SourceSafe的操作界面和基本操作。 3.学习Microsoft Visual SourceSafe工具的代码版本控制、配置管理、权 限管理、历史记录跟踪等的使用方法 二、实验内容与步骤 1)如图1所示，登录到数据库管理工具Visual SourceSafe 6.0 Admin， 单击User菜单，单击Add User…添加用户，并设置该用户的密码，（本 人的姓名作为用户名）单击OK。可重复此步骤添加其他所有用户。
图 1 1.1主界面介绍 打开Microsoft Visual SourceSafe 6.0，并用已添加的用户登录，界面如图 1所示。该图是一个示意图，其中已经建立了一些Project并添加了一些文件。事实上，当第一次打开VSS时，应该是完全空白的。在左侧，是Project树，此处的Project可简单地理解为与硬盘上的文件夹相当。在右侧显示了该Project 下所属的所有文件。下方是输出窗口，会显示一些相关信息。 图 1 VSS Explorer
1.2基本使用 （1）创建Project并添加文件 VSS中的Project可以类比视为操作系统中的文件夹。VSS就是负责在其自身的系统中按照Project来维护、保存文件。要新建Project，可以按照如下步骤执行： 1)选中根节点（$/）或某一个已存在Project（绿色文件夹图标），单击File 菜单，单击Create Project...， 并在Project文本框中指定名称，就可以在当前选中的Project下新建一个新的Project。 例如选中HR System，单击File菜单，单击Create Project...，在出现的对话框中输入Project Documents（如图 2所示），单击OK后就可以看到，在HR System下出现了一个新的Project，名称为Project Documents。 图 2 新建Project
SCMS软件配置管理过程
C M M文件软件配置管理过程 XXXXXXXXXXXX (版权所有,翻版必究)
文档变更请求(DCR)
文档变更记录
目录 1 概述 (1) 1.1 目的 (1) 1.2 范围 (1) 1.3 术语与定义 (1) 1.4 参考文档 (1) 1.5 引用文档 (2) 2 过程目标 (2) 3 过程定义 (2) 3.1 责任人 (2) 3.2 输入 (3) 3.3 入口准则 (3) 3.4 过程活动 (3) 3.5 出口准则 (6) 3.6 输出 (6) 附录 A ：软件配置项/产品包标识 (8) A.1 文档的编号 (8) A.2 程序的名称 (9) A.3 软件产品包的标识 (9) A.4 系统、数据库、开发与支持软件工具的编号 (9) 附录 B ：配置项状态报告 (10) B.1 系统软件、数据库、开发与支持软件工具列表 (10) B.2 软件基线/配置项状态报告 (10) B.3 软件基线软件基线变更报告 (10) 附录 C ：软件配置管理测量报告 (11)
1概述 1.1目的 软件配置管理（简写为SCM）是维护项目软件整个生命周期产品完整性的重要活动，本文档明确规定了公司软件配置管理活动的目标和过程定义，为公司软件配置管理提供所遵循的过程、程序和指导方针。 1.2范围 本文档适用于管理公司所有软件项目在各阶段标识的软件配置。软件配置管理的大部分活动用“软件配置管理工具”实现。 1.3术语与定义 1.3.1软件工作产品：作为定义、维护或应用软件过程的一部分所生成的任何人工制品，包括过程描述、 计划、规程、计算机程序和相关文档，这些可能交付也可能不交付给顾客或最终用户。 1.3.2软件基线：软件配置项经软件验证、确认、评审和认定后，形成了软件基线，也就成了该阶段的一 个基准。下一个阶段只能在这个基准上进行开发活动。 1.3.3软件配置项：是指一个软件产品在软件生存周期各个阶段所产生或应用的各种形式（机器可读或人 工可读）和各种版本的文档、程序及其数据。 1.3.4SCCB：软件配置管理委员会（Software Configuration Control Board）（关于责任，参见“责任 人”）。 1.3.5SCM：软件配置管理(Software Configuration Management) 包括了标识软件工作产品、控制对 软件工作产品的更改、和维护在整个软件生存周期中的软件工作产品的完整性和可跟踪性。 1.4参考文档 1.4.1Mark C. Paulk，Bill Curtis，Mary Beth Chrissis，Charles V. Weber，Capability Maturity Model for Software （Version 1.1） 1.4.2Roger S. Pressman，Software Engineering –A Practitioner’s Approach (Fourth Edition) 1.4.3《计算机软件配置管理计划规范》GB/T 12505-90
软件配置管理控制程序
配置管理控制程序 历史记录
目录
1.引言 1.1目的 本程序文件定义了本组织的配置管理的过程，目的是规范公司的软件配置管理活动，使公司的所有软件开发项目的软件配置管理活动都能按照统一的要求进行。 1.2 使用范围 本文件适用于公司的所有软件项目。 1.3 名词和缩写 CM(Configuration Management) 配置管理 SCCB (Software Configuration Control Board) 软件配置管理控制委员会 CC (Configuration Controller) 配置管理员 工作产品（Work Products）：项目技术开发和管理工作中产生的有价值的成果，例如源代码、数据和各种文档。 配置项（Configuration Item, CI）：纳入到配置管理范畴作为单个实体对待的工作产品称为配置项[IEEE Std 610.12 - 1990 ]；配置项包括：项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入软件配置管理。 基线（Baseline）：一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。基线一经放行，就可以作为从配置管理系统检索源代码文卷（配置项）和生成可执行文卷的工具。 2角色与职责 2.1软件配置管理组（CM） CM组是项目里的一个小组，根据项目大小，可以由一个人，或者多人组成,小组的成员称为配置管理员(CC),通常由公司的质量保证组安排，加入到项目组，由项目经理领导。
CM组建立并管理配置管理库系统。 CM组负责组织相关部门和人员进行有关CM活动的培训。 项目组的CM组负责在该项目的整个生命周期中进行配置管理活动。 2.2软件配置管理控制委员会(SCCB) SCCB建立在项目级，通常由项目经理、该项目的技术经理、软件开发工程师、资深工程师、测试经理/测试工程师以及CC组成。SCCB在项目策划阶段由项目经理负责筹建。 配置管理控制委员会负责审批软件配置管理计划； 配置管理控制委员会负责审批软件基线的建立； 配置管理控制委员会负责审批对软件基线配置项的变更； 配置管理控制委员会负责审核和批准产品发布。 2.3 SCCB负责人 SCCB负责人通常由项目经理担任，代表SCCB在有关文件上签署意见。 2.4 项目经理 定期或事件驱动地评审或审核CM活动。 2.5 测试组 负责审核《配置管理计划》任务列表中与测试有关的内容 2.6 开发组 负责审核《配置管理计划》任务列表中与开发有关的内容 2.7 QA组 负责审核《配置管理计划》任务列表中与QA有关的内容
软件项目配置管理系统计划清单指导应用清单
中国核电集团 CHINA GUANGDONG NUCLEAR POWER GROUP 记录文件 项目编号 项目名称 CGN-IT-C3-A12-01 软件项目配置管理计划 版本编写审核审定批准生效时间A/0 注：如无受控文件标识（蓝色印章）则为非有效版本，以受控文件规定为准。 此文件属中国核电集团所有，未经许可，不得以任何方式外传。
修改记录页
目录 (一)基本信息 (4) (二)角色与职责 (4) (三)配置管理资源 (5) (四)权限分配 (5) (五)配置项计划 (6) (六)配置库基线 (7) (七)配置库备份计划 (8) (八)配置库状态报告 (8) (九)配置审核 (9) (十)审批意见 (9)
配置管理计划(一)基本信息 项目名称： 项目代号： 立项时间： 预计主要项目阶段有： 配置项目命名规则依据： (二)角色与职责
(三)配置管理资源 本项目使用配置管理工具对各配置项进行存储、版本管理，并提供更新、检索和历史版本的恢复。 提示： （1）配置管理员确定本项目的配置管理软件。例如采用Microsoft公司的TFS或者IBM公司的clearecase。 （2）配置管理员根据所采用的配置管理软件，确定计算机资源（考虑存、外存、CPU等）。 预计建库申请日期： 预计建库日期： 预计工作库需空间： (四)权限分配 项目成员访问配置库的ID及PASSWORD默认设置为与域的设置相同。 若个人要求另行设置的，由项目组配置管理员负责汇总后，提交给高级配置管理员调整设置。
(五)配置项计划 填写上面表格过程中，需要对照成果物列表逐项填写。
软件配置管理解决方案
软件配置管理解决方案 目的: ● 通过使用配置管理软件,遵守版本控制、变更控制等规程,保证所有配置项的完整性和可跟踪性。 范围: ● 适用于公司的软件开发项目,它规定了软件配置管理活动的具体规程及其工作产品。 角色与职责: ● 配置管理员:编制项目配置管理计划；创建并维护配置库。 ● 配置变更控制委员会(SCCB):审批配置变更申请。 ● 软件开发组成员:在权限内使用配置管理工具操作配置库。 ● 项目SQA人员:审计配置管理活动的规范性。 进入准则: ● 项目计划已制定。 ● 项目软件过程已定义
● 配置管理员和SCCB人员已确定。 输入: ● 项目计划 ● 项目软件过程 结束准则: ● 对项目配置库的操作和管理持续到项目结束。 ● 只要存在用户使用配置管理就要进行。 输出: ● 配置管理计划 ● 产品配置库 ● 软件基线审计报告 主要活动: 1 在项目早期(在项目计划初稿后,并与项目计划一起评审)编制项目配置管理计划。 ● 确定项目配置管理员。 ● 项目经理和项目配置管理员共同指定项目组的SCCB。 ● 项目经理与项目配置管理员按确定的软件生命周期,识别出项目要进行控制的软件配置项和纳入配 置管理的日期。 ● 项目经理与项目配置管理员依据项目定义软件过程,共同确定项目的基线,并标识每个基线的配置项。 ● 项目经理确认由项目配置管理员制定的在软件生命周期各个阶段配置项的使用权限清单。 ● 项目配置管理员按照《配置管理计划模板》制定项目的SCM计划。 ● 项目配置管理员根据项目所使用的开发工具确定项目使用的配置管理工具。 ● 项目配置管理员根据项目计划的变动,适时调整项目的SCM计划。具体规程见《项目跟踪与监控过程》计划变更相关步骤。 ● 由项目主管主持,项目经理、公司配置管理主管、项目配置管理员、软件工程组、软件相关组参加对配置管理计划书的评 审。具体规程参见《同行评审过程》。 2 按照配置管理计划,进行项目的配置库管理。 ● 项目配置管理员规划、建立项目的目录结构。该结构支持对配置项的存储和检索功能。 ● 项目配置管理员根据项目的规模,规划和配置管理工具相关的配置库结构。 ● 项目配置管理员依据经项目经理确认的权限清单对目录结构进行权限分配,以达到在相关组之间或 配置库内部之间进行共
软件配置管理流程
软件配置管理流程
目录 1.配置管理流程 (3) 1.1 概述 (3) 1.2 总体流程图 (3) 1.3 软件需求分析阶段 (4) 1.4 软件设计阶段 (4) 1.5 制定配置管理计划 (4) 1.6 配置库管理 (4) 1.6.1 相关人员分配权限 (4) 1.6.2 配置项 (5) 1.7 版本控制 (6) 1.8 变更控制 (6) 1.9 配置审计 (7) 1.9.1 配置审核的类别 (7) 1.9.2 配置审核执行的时机 (7) 1.9.3 不符合项的处理 (7) 2.0.0 配置状态报告 (7) 2.0.1 配置状态报告的目的 (7) 2.0.2 配置状态报告记录的内容 (7) 2.0.3 配置状态报告的生成 (7) 2.1.0 发行管理 (8) 2.1.1 交付管理 (8) 2.1.1 软件配置管理员的处理规范 (8) 2.1.1.1 现阶段使用的版本配置服务器 (8) 2.1.1.2 主要操作流程 (8) 2.1.1.3 版本规范化处理 (8) 2.1.1.4 客户反馈问题处理 (8) 2.软件基线化规范 (9) 2.1 正常开发期 (9) 2.2 版本发布期 (9) 2.3 项目发布期 (9) 2.4 项目维护期 (9)
1.配置管理流程 概述 规范配置管理活动,明确配置项正确的唯一标识并易于存取,保证基准配置项的更改受控,明确基线状态,在贯穿整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 总体流程图
软件需求分析阶段 参加需求分析会议,配置管理负责人记录,有关文档提交归档。如《需求分析》。 软件设计阶段 参加涉及阶段,为了详细制定配置管理计划。针对需求分析报告进行系统设计，配置时应说明系统设计的版本于需求分析报告版本的对应关系。设计书评审通过后，建立设计基线。 制定配置管理计划 配置管理员制定配置管理计划,主要内容包括配置管理软硬件资源、配置项计划、备份计划等,审批该计划。 配置库管理 配置管理员为项目创建配置库,并给每个项目成员分配权限。各项目成员根据自己的权限操作配置库。 相关人员分配权限 项目经理： 1）与（有关负责人员）协商确定项目起始基线； 2）接受配置管理计划，并按相关规定贯彻执行； 3）接受配置控制委员会的报告； 4）提出配置管理计划的修改要求； 5）提出管理的建议和要求。 配置管理员 1）编制配置管理计划； 2）执行配置项管理； 3）执行版本控制和变更控制方案； 4）编制配置状态报告； 5）配置库的建立和权限分配； 6）配置管理工具的日常管理与维护； 7）配置库的日常操作和维护； 开发人员 1）根据确定的配置管理计划和相关规定，提交配置项
CMMI3级过程域(PA)
被访谈角色问题说明 -CMMI3 1）高层经理： 高层经理Sheet页内容； 2）EPG人员： 公共实践、OPD、OPF sheet页内容；3）培训管理员： 公共实践、OT sheet页内容。 4）项目经理： 公共实践、立项与结项、PP、PMC、 IPM、RSKM、MA、REQM、VER、DAR sheet页内容。 5）需求人员： 公共实践、RD、REQM、VER、DAR sheet 页内容； 6）设计开发人员： 公共实践、TS、VER、DAR、PI sheet 页内容； 7）测试人员： 公共实践、VAL、VER sheet页内容；8）配置管理员： 公共实践、CM、VER sheet页内容；9）QA人员： 公共实践、PPQA、VER sheet页内容。CMMI3级过程域(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）风险管理。 识别潜在的问题，以便策划应对风险 的活动和必要时在整个项目生存周期 中实施这些活动，缓解不利的影响， 实现目标。 工程管理 9、REQM：（Requirements Management） 需求管理。需求管理的目的是在客户 和软件项目之间就需要满足的需求建 立和维护一致的约定。 10、RD：（Requirement Development） 需求开发。需求开发的目的在于定义 系统的边界和功能、非功能需求，以 便涉众（客户、最终用户）和项目组 对所开发的内容达成一致。 11、TS：（Technical Solution）技术解 决方案。在开发、设计和实现满足需 求的解决方案。解决方案的设计和实 现等都围绕产品、产品组件和与过程 有关的产品。 12、PI：（Product Integration）产品集 成。从产品组件组装产品，确保集成 产品功能正确并交付产品。 13、VER：（Verification）验证。验证 确保选定的工作产品满足需求规格。 14、VAL：（Validation）确认。确认证 明产品或产品部件在实际应用下满足 应用要求。 支持管理： 15、CM：（Configuration Management） 配置管理。建立和维护在项目的整个 软件生存周期中软件项目产品的完整 性。 16、PPQA：（Process and Product Quality Assurance）过程和产品质量保 证。为项目组和管理层提供项目过程 和相关工作产品的客观信息。 17、MA：（Measurement and Analysis） 测量与分析。开发和维持度量的能力， 以便支持对管理信息的需要，作为改 进、了解、控制决策。 18、DAR：（Decision Analysis and Resolution）决策分析与解决。应用正 式的评估过程依据指标评估候选方案， 在此基础上进行决策。 总结CMMI3级的几个重要特点： 1) 明确规定了需求开发、设计、编码、 测试、集成等软件开发各过程的要求。 2) 对项目管理提出了更高的要求，要利 用组织级的数据来管理项目。 3) 出现了专门针对组织级的PA，要求有 专门的组织来负责过程改进的工作。 4) 提供了一个做出最佳决策的指导，而 这个方法可以用于软件工程，也可以用于 组织级过程改进。 注意：本次评估中只包含除SAM（Supplier Agreement Management）供应商协议管理 外的17个过程域。 SG：特定目标 SP：特定实践 立项管理文档立项管理（Project Initialization Management,PIM）的目的是：（1）采纳符合 机构最大利益的立项建议被采纳，避免浪费机构 的人力资源、资金、时间等。 【√设计】TS-技术解决方案 【√设计】DAR-决策分析与解决 【√设计、开发】VER(同行评审)-验证 【√开发】PI-产品集成
软件配置管理计划示例
软件配置管理计划示例 作者：赵文锋计划名CADCSC软件配置管理计划 项目名中国控制系统CAD工程化软件系统 项目委托单位 代表签名年月日 项目承办单位 代表签名年月日 1 引言 1．1 目的 本计划的目的在于对所开发的CADCSC软件规定各种必要的配置管理条款，以保证所交付的CADCSC软件能够满足项目委托书中规定的各种原则需求，能够满足本项目总体组制定的且经领导小组批准的软件系统需求规格说明书中规定的各项具体需求。 软件开发单位在开发本项目所属的各子系统（其中包括为本项目研制或选用的各种支持软件）时，都应该执行本计划中的有关规定，但可以根据各自的情况对本计划作适当的剪裁，以满足特定的配置管理需求。剪裁后的计划必须经总体组批准。 1．2 定义 本计划中用到的一些术语的定义按GB/T 11457 和GB/T 12504。 1．3 参考资料
◆GB/T 11457 软件工程术语 ◆GB 8566 计算机软件开发规范 ◆GB 8567 计算机软件产品开发文件编制指南 ◆GB/T 12504 计算机软件质量保证计划规范 ◆GB/T 12505 计算机软件配置管理计划规范 ◆CADCSC 软件质量保证计划 2 管理 2．1 机构 在本软件系统整个开发期间，必须成立软件配置管理小组负责配置管理工作。软件配置管理小组属项目总体组领导，由总体组代表、软件工程小组代表、项目的专职配置管理人员、项目的专职质量保证人员以及各个子系统软件配置管理人员等方面的人员组成，由总体组代表任组长。各子系统的软件配置管理人员在业务上受软件配置管理小组领导，在行政上受子系统负责人领导。软件配置管理小组和软件配置管理人员必须检查和督促本计划的实施。各子系统的软件配置管理人员有权直接向软件配置管理小组报告子项目的软件配置管理情况。各子系统的软件配置管理人员应该根据对子项目的具体要求，制订必要的规程和规定，以确保完全遵守本计划规定的所有要求。 2．2 任务 在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开