(项目管理)项目配置管理规范
卷号卷内编号密级
分类:
<规范>
使用者:
<项目组、项目
管理部>
文档编号：
?托普信息（iTOP）集团,2002软件配置管理规范
Version 2.1
技术委员会
目录
1.简介 (1)
1.1目的 (1)
1.2范围 (1)
1.3文档结构 (1)
1.4词汇表 (1)
1.5参考信息 (2)
1.5.1可追溯性 (2)
1.5.2方针 (2)
1.5.3过程/规范 (2)
1.5.4指南 (2)
1.5.5模板 (2)
1.5.6检查表 (2)
1.5.7培训 (2)
1.5.8工具 (2)
1.6参考网站 (3)
2.配置管理规范 (3)
2.1配置管理流程图 (3)
2.2角色 (3)
2.3进入准则 (4)
2.4输入 (4)
2.5活动 (4)
2.6输出 (5)
2.7验证与确认 (5)
2.8退出准则 (6)
2.9度量 (6)
3.变更控制规范 (7)
3.1变更控制流程图 (7)
3.2角色 (8)
3.3进入准则 (8)
3.4输入 (8)
3.5活动 (8)
3.6输出 (8)
3.7验证与确认 (9)
3.8退出准则 (9)
3.9度量 (9)
4.参考文献 (9)
附录 A –流程框图符号 (10)
附录B文档命名指南 (11)
1. 简介
软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。
1.1 目的
本文档指导项目开展配置管理活动。
1.2 范围
本文档适用于托普信息（iTOP）集团技术委员会批准立项的软件项目。
1.3 文档结构
第一部分：
简介，包括本规范的目的、范围、词汇以及所涉及到的参考信息。
第二部分：
配置管理工作规范的正文，包括活动的流程图、进入以及退出准则、所涉及的角色、相关活动
的阐述、验证与确认以及度量。
第三部分：
变更控制工作规范的正文，包括活动的流程图、进入以及退出准则、所涉及的角色、相关活动
的阐述、验证与确认以及度量。
第四部分：
参考文献，列出了编写本规范所参考的相关的文献资料。
第五部分：
附录，本文中流程图的标准符号定义。
1.4 词汇表
CM（Configuration management）
配置管理。
CCB（Change control board）
变更控制委员会。
CI（Configuration item）
配置项，包含文档、程序。
CR（Change Request）
变更请求，对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息是有
关当前问题、提议解决方案及其成本的起源和影响的信息。
PCA（Physical Configuration Audit）
物理审计，在配置管理系统中建立基线的工件是否为“正确”版本。
FCA（Functional Configuration Audit）
功能审计，核实软件配置项的实际性能是否符合它的需求。
基线（Baseline）
已通过复审和批准的工件发布版，由此构成进一步演进或开发的公认基础，并且只能通过
正式程序，例如变更管理和配置控制才能进行更改。
1
配置管理库（Configuration Management Library）
存储项目工件的所有版本，即存储项目的定义的配置项。
版本（Version）
某个工件的变体，工件的后期版本一般是在初期版本的基础上进行的扩展。
1.5 参考信息
1.5.1 可追溯性
CMU/SEI-93-TR-024 Capability Maturity Model SM for Software, Version 1.1
1.5.2 方针
托普信息（iTOP）集团项目开发与管理工作方针
1.5.3 过程/规范
项目计划与控制规范
1.5.4 指南
配置管理计划指南
基线策略指南
配置状态报告编制指南
配置审计工作活动指南
配置管理工具指南
VSS使用手册
组织管理配置库使用指南
软件开发文档命名约定
1.5.5 模板
配置管理计划
配置状态报告
配置审计报告
文档变更请求
1.5.6 检查表
无
1.5.7 培训
《软件配置管理教材》
《软件变更控制管理教材》
《Clear Case配置管理培训教材》
1.5.8 工具
Clear Case
Visual SourceSafe
Office 95/97/2000/XP
2
1.6 参考网站
http://cdweboa/app/jswy.nsf/
2. 配置管理规范
2.1 配置管理流程图
2.2 角色
本文档在组织中实施所涉及的角色
3
2.3 进入准则
2.4 输入
2.5 活动
4
2.6 输出
2.7 验证与确认
5
2.8 退出准则
2.9 度量
6
3. 变更控制规范
3.1 变更控制流程图
7
3.2 角色
3.3 进入准则
3.4 输入
3.5 活动
3.6 输出
8
3.7 验证与确认
3.8 退出准则
3.9 度量
.
4. 参考文献
[BUC93]
Implementing Configuration Management, Hardware, Software and Firmware. Los Alamitos, CA: IEEE Computer Science Press, J. Buckley 1993.
[Rational 2001]
Rational Unified Process, Version2001, Rational Software Corporation, 2001.
9
附录
附录 A –流程框图符号
Parallelograms represent inputs and
outputs to or from a process/procedure.
Rectangles represent individual
process/procedure activities.
Diamonds represent important decision
points in the process/procedure.
Lines with arrowheads connect symbols to
show the progression or direction of the
activities.
Circles represent connectors when a
process/procedure flowchart continues on the
next page.
10
附录B文档命名指南
根据公司的需要及软件工程文档命名规则GB8567中的建议，文挡命名采用以下规则：
文挡命名由两部分构成，格式如下：
project_filename.XXX
其中解释如下：
Project代表是项目名称的简写，一般不超过６个字符。
Filename.XXX是文件名称。
Version代表版本号。
例如:
JDM_SCMPlan.doc表示的意义如下：JDM项目组的软件配置计划。
11
6汽车设计过程中的项目管理
汽车设计公司的项目管理 随着汽车市场竞争的不断加剧，产品更新换代周期的缩短，这就要求各汽车公司迅速、及时地推出新产品以满足用户需求。汽车设计公司做为主机厂的技术服务商，也将面临越来越严峻的设计进度和设计质量的挑战，汽车设计公司的项目管理就显得非常重要。 由于汽车产品开发是一项复杂的工程，它需要面对动态多变的市场竞争环境，需要跨部门、跨职能乃至跨文化沟通与解决问题，需要通过团队的合作实现目标，需要对众多的活动进行有机的整合。因此，科学合理的汽车产品开发的项目管理就显得十分重要。 1汽车设计公司与项目管理流程概述 进入20世纪90年代，国内涌现了一批独立的汽车设计公司，为新兴的主机厂提供设计技术服务，打破了国外设计公司长期对中国汽车厂家的设计垄断。汽车设计公司的兴起和发展，为中国汽车自主品牌的设计能力带来飞速发展和技术积累。 项目管理应用于汽车产品开发过程，形成了新的产品开发工作流程，并在其中广泛采用了同步工程方法。项目管理所涉及的知识领域中蕴涵着同步工程的概念及方法。如项目时间管理中的关键路径法，通过对项目各活动之间逻辑关系的分析，找出项目关键路径，力求将项目所需时间缩至最短；同时也体现了并行工作的思路。在制定项目进度计划方面，甘特图法在汽车产品设计中得到了普遍应用。 2汽车设计公司的项目管理发展方向 国内汽车设计公司的项目管理经过近些年的发展，从刚开始的探索期逐渐走向成熟。早期的国内汽车产品设计大多是直接找一个标杆车来进行拆解逆向，在逆向的基础上进行改造型设计甚至全盘照抄，项目管理流程更是直接照搬国外汽车厂家的流程，这导致国产车大
多被打上山寨标记，市场竞争力不足。近些年，随着消费者对汽车产品的造型和产品性能越来越高，拥有自主创新意识和设计能力的汽车产品更受消费者喜爱，主机厂和汽车设计公司都在向自主研发方向转变。国内汽车设计公司在与主机厂的合作中项目管理水平得到极大提升。 2.1现状与问题 设计公司的产品开发体制和管理机制正经历着深刻的变革，项目管理的重要性正在为管理者及设计人员所认识。但由于一些企业内部的观念尚未发生根本转变，项目管理并没有很好地开展。 2.1.1开展项目管理的层次较低 由于一些公司内部对项目管理的必要性认识不足，项目管理只是在较低层面和局部开展。比如产品开发的项目管理，仅在产品研发部门或制造部门孤立地开展，并且这种管理缺乏系统的、程序化的工作模式，往往基于项目负责人个人对项目管理的理解和认识进行。 众所周知，产品开发不仅仅是产品研发部门的事，如果一个产品开发项目的项目管理不在公司层面进行，就难以使制造、采购、质量管理、销售等诸多部门有效地参加项目，也就难以达到项目管理的目的。 2.1.2项目管理组织结构不健全，项目推进主要依靠职能部门 一些企业内部尚未形成项目管理的概念，项目推进依然主要依靠职能部门。项目负责人未被赋予推进项目所需的权利，因而难以有效地推动项目。项目组织与职能组织的责任与功能不明确。这种项目管理方式在效率方面甚至不如职能式的组织结构。 2.1.3缺乏规范的、与产品开发合理周期相关的产品开发工作流程
软件配置管理规定
软件配置管理规定? 为进一步加强软件配置管理工作,明确软件配置原则,规范软件配置流程，制定本规定。 一、配置原则? 1、软件配置遵循安全性、适用性、 2、单经济性与正版化得原则，不得配置非正版软件。? 位使用得商业软件、OEM软件、免费软件均需纳入配置管理，不得配置与工作无关得各类软件。?3、优先采用场地授权(许可)方式配置软件。 二、配置流程 1、软件使用部门根据本部门各岗位工作需要，编制岗位软件需求清单，填写《软件使用需求申请表》（附件1)。 ２、信息化部门统计、汇总软件使用部门报送得《软件使用需求申请表》,对软件使用部门需要得相关软件进行统一测试与试用，综合考虑软件得价格、兼容性、安全性与售后服务等因素,确定软件选型,明确软件名称与版本.涉及使用免费软件得,更新《可使用免费软件清单》(附件2）。 3、信息化部门依据单位软件使用管理台账,梳理单位软件需求与现有软件许可得差异。单位软件许可不足得，编制《软件采购计划表》（附件3）。 4、财务部门要将软件采购纳入单位年度预算。财务、资产管理部门指导信息化部门完成软件采购。软件采购合同要明确软件名称、版本、授权方式、许可数量、使用年
限、兼容性与售后服务等要求。?5、财务、资产管理部门指导信息化部门做好软件采购相关资料管理工作，重点就是软件采购合同、软件授权证书、软件安装序列号等资料得管理工作。? 6、信息化部门负责软件使用管理日常工作。?7、单位采购得软件,因以下情况申请报废得，需经过信息化部门鉴定,严格履行资产处置报批手续：?(１）已经达到规定得最低使用年限,且无法继续使用得.?（２）未达到规定得最低使用年限,因技术进步等原因无法继续使用得。?（3）未达到规定得最低使用年限,因计算机硬件报废，且无法迁移到其她计算机上继续使用得. ８、信息化部门在单位新采购软件、报废软件与调整可使用免费软件清单后，更新《软件使用情况汇总表》（附件4)。
软件开发项目配置管理工具的选择
软件开发项目配置管理工具的选择 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报…… 每一个软件项目，无论是工程类项目，还是产品类项目，都必须经历需求分析、系统设计、编码实现、集成测试、部署、交付、维护和支持的过程。在这个过程中，将生成各种各样不同的工件，包括文档、源程序、可执行代码、支持库。更可怕的是，频繁出现的变更是不可避免的，因此面向如此庞大且不断变动的信息集，如何使其有序、高效地存放、查找和利用就成为了一个突出的问题。 针对这一问题，最早的开发人员尝试过的解决办法是通过手工来实现： 1)文档：每次修改时都另存为一个新的文件，然后通过文件名进行区分，例如"XXX 软件需求说明书V1.0，XXX软件需求说明书V1.1，XXX 软件需求说明书V2.0."，并且在文件中注明每次版本变化的内容； 2) 源代码：每次要修改时就将整个工程目录复制一份，将原来的文件夹进行改名，例如"XX 项目V1.0、XX 项目1.01、."，然后在新的目录中进行修改； 但是这种方法，不仅十分繁琐，容易出错，而且会带来大量的垃圾数据。如果是团队协同开发或者是项目规模较大时，还是会造成很大的混乱。很显然，这样简陋的方法是无法应对这一问题的。后来，有人尝试从制造工业领域引入了"配置管理"这一概念，通过不懈的研究与实践，最终形成了一套管理办法和活动原则，这也就是软件配置管理。 通过软件配置管理，将对软件系统中的多重版本实施系统的管理；全面记载系统开发的历史过程，包括为什么修改，谁作了修改，修改了什么；管理和追踪开发过程中危害软件质量以及影响开发周期的缺陷和变化。并对开发过程进行有效地管理和控制，完整、明确地记载开发过程中的历史变更，形成规范化的文档，不仅使日后的维护和升级得到保证，而且更重要的是，这还会保护宝贵的代码资源，积累软件财富，提高软件重用率，加快投资回报。 常见的配置管理工具 正如前面所述，由于软件配置管理过程十分繁杂，管理对象错综复杂，如果是采用人工的办法不仅费时费力，还容易出错，产生大量的废品。因此，引入一些自动化工具是十分有裨益的，这也是做好配置管理的必要条件。 正是因为如此，市场上出现了大量的自动化配置管理工具，这些工具的实现原理与基本机制
软件项目配置管理系统计划清单指导应用清单
中国核电集团 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默认设置为与域的设置相同。 若个人要求另行设置的，由项目组配置管理员负责汇总后，提交给高级配置管理员调整设置。
(五)配置项计划 填写上面表格过程中，需要对照成果物列表逐项填写。
《项目管理》设计管理控制程序
COP7.5-2项目设计管理控制程序—————————————————————————————————版号：B 编制：日期： 批准：日期：
COP7.5-2项目设计管理控制程序B/0 1/5 —————————————————————————————————1．0 目的 确保项目的各项设计工作及设计工作的各个环节处于受控状态，保证设计成果的质量 及设计工作进度符合预期要求，同时在此基础上保证设计师的创造性得以体现。 2．0 适用范围 本程序适用于工程项目设计各阶段工作的监控与管理，其他各专项设计的监控与管理 参照此程序进行调整简化。 3．0 职责 3．1 公司总工程师负责所有项目设计管理工作中的技术性工作。 3．2 设计部经理负责设计项目的管理工作; 内部、外部的协调工作及项目设计管理工作中的组织性工作。 3．3 设计部不同专业技术人员，具体负责项目各分项设计工作的监控与管理。 4．0 程序内容 4．1 项目设计前期准备 4．1．1 总工程师组织各部门有关人员对项目的基本资料进行收集整理，其中包括营销部门提供项目市场分析、项目定位、基本营销策略、项目描述；开发部提供用地资料、规划 红线、用地指标、规划设计要点等限制性条件；以及水、电、热、通信等市政配套资 料等。 4．2 《设计任务书》编制 4．2．1 设计部经理负责根据营销中心在《项目建议书》中提供的资料和项目的总体定位要求编制项目《设计任务书》，提出对设计工作的具体要求，主要包括：工程地点、规模、 功能要求，建设标准、设计阶段进度要求以及设计工作所必须的基本资料等。4．2．2 《设计任务书》由总工程师审阅后提交总经理办公会议审核，并按审核意见修改定案后，作为设计工作的主要依据。 4．3 方案设计阶段设计单位选择 4．3．1 根据现有设计市场情况及其他途径，对有合作意向的设计单位进行调查、联络、填写《设计单位信息表》。 4．3．2 根据信息表对设计单位进行考察，提交相应的考察报告和参加方案设计单位初步排名，
软件版本管理规范标准[详]
软件版本管理规 第一章目的 本规详细规定软件项目版本管理的对象、存储目录、分支、权限、维护等容，使软件项目版本管理流程化并规化，确保在系统开发和实施过程中项目的完整性和一致性。 1.第二章适用围 所有系统开发及实施项目的软件项目都应进行版本管理。项目中所有正式文档和代码都应纳入配置库（可使用工具建立配置库，本文所述使用的是SVN）进行版本管理。 2.第三章职责 配置库管理员：负责配置库的日常维护和管理；监督开发及测试部门及时提交版本管理对象（即配置项）。 此岗位可由开发或测试人员兼任。 3.第四章容 4.1. 版本管理对象 包括但不限于： 项目总体计划 可行性研究报告 开发计划 需求说明书 需求设计原型 设计说明书 系统开发变更申请单 系统管理手册 用户操作手册 培训计划 培训记录 源程序 支持系统运行的配置文件 存储过程脚本 测试计划 测试用例 测试脚本 测试报告 上线计划
上线申请 版本维护日志 4.2. 配置库的目录结构 每个项目在配置库中应拥有唯一的项目名称。配置库目录结构与项目部的目录结构建议按下列格式创建。 配置库目录结构规划： ┠tags(发布) ┃├v1.0.0_T1_2016909 ┃├v1.0.0.33899_T1_20161009 ┃├v1.0.0_R1_20161109 ┃├v1.1.0_T1_20170109 ┃└v1.1.0_R1_20170209 ┠trunk(主版本) ┃└projectA ┃├src ┃├MY_MOOC ┃├doc ┃├tool ┃├。。。 ┖branches(分支) ├SY_ABC ├TJ_ABC ├WH_MOOC 其中，项目部的目录结构： |–projectA |–src （保存该项目的源程序） |–doc （保存项目相关文档） |–000.项目管理（保存项目过程管理相关文档） |–010.项目计划（保存项目计划相关文档） |–020.项目需求（保存项目需求相关文档） |–030.系统设计（保存项目设计相关文档） |–030.系统测试（保存项目代码测试相关文档） |–040.系统实施（保存项目部署实施相关文档） |–050.系统运维（保存项目运维文档，包括培训、用户手册等） |–060.技术资料（保存项目技术文档，包括第三方技术资料等）
配置管理岗位职责
配置管理员岗位职责 摘自：软件配置管理论坛 一、配置经理的基本技能与资格 资格： 能够重视配置管理工作； 能够按规范实施配置管理工作； 积极支持部门的配置管理方面的工作； 能够积极支持与帮助其他人员； 为部门的配置管理能力的提高贡献力量； 熟悉公司配置流程以及其他相关的流程； 为增进项目管理，对于项目内的困难和关键问题，能够及时反映到部门； 基本技能： 能够独立规划项目的配置管理工作； 熟练掌握配置管理的相关概念； 能够了解配置的相关工具，熟练使用技术工程部配置所使用的工具； 具有基本的与人沟通的技巧； 能够了解项目管理过程中的主要环节； 初步了解项目管理过程中的质量保证的各个方面； 了解部分系统和应用工具，如数据库ORACLE，前台开发工具DEPHI等； 二、配置经理的职责 作为一名配置人员，配置经理的职责就是能够与质量人员、测试人员等共同保证项目的质量。如：作为质量保证的成员之一，能够为整个技术工程部规范化管理的推进作贡献，如宣传规范化管理的知识，陈述规范化管理的利弊等；能够在项目进行的整个生命过程中，不断的与项目经理、QA、SCCB及项目成员进行配置管理规范化的沟通，为项目配置管理的规范化作出努力. 具体表现为： ?项目进行初期或首次进入项目中时，能够首先与项目经理、QA、SCCB及项目成员就项目的未来配置管理工作进行沟通，取得项目经理、QA、SCCB及项目全体成员对配置工作的认可与支持； ?积极了解项目情况，项目各阶段的进展，为更好的进行配置管理作努力； ?熟练并充分的利用配置管理工具的各方面的功能，提高配置管理的效率； ?为项目控制好版本，保证项目各阶段所使用的版本正确； ?及时发现项目问题，把问题及时反馈给项目经理、QA或SCCB，并积极协助解决； ?与项目内其他组成员，如开发组、测试组等协调工作，并能够很好的沟通； ?能够在项目中不断总结、分析，为项目内配置管理工作的进一步优化作贡献；
【项目管理知识】从项目管理角度看软件配置管理
从项目管理角度看软件配置管理 项目的目地是为了创造一项产品或服务，因此，产品本身的生产工艺必然会成为项目管理过程的核心内容。无论在哪一种软件工程方法中，软件配置管理都是一项不可或缺的重要管理内容，特别是对于服务企业内部的信息技术部门来说，从产品生命周期出发，同时支持服务产品和软件产品，同时负责开发与运行，其管理复杂度很高，要想理顺各项工作的内部关系、理清各项工作之间的配合关系，都离不开配置管理这个基本手段，它是许多管理工作的“落地”部分。其实，配置管理并不是一个时髦的概念，在许多传统行业（例如制造业）中早已有之，软件行业只是在软件工程方法中继续延用了这一概念，它是一流软件开发企业所必备的基础设施。 在项目管理中，配置管理是一种重要的管理手段。在PMI的PMBOK中对于配置管理系统是这样描述的： 由此可见，配置管理是一个非常宽泛的概念，项目中只要是需要进行管理的任何特性，都可以纳入配置管理。配置管理不只是操作层面的问题，更是管理理念、管理方法的问题，是一个系统。 项目范围管理需要配置管理来落实 在项目范围管理中，需要识别和控制项目的交付成果，要描述交付物应有的各种特性。这些交付物及其特性，就是配置管理中的配置项。从项目管理的角度，WBS只需要分解到可管理（Manageable）的程度，而配置管理则要求分解到终可操作的程度，管理的粒度更为精细。因此，良好的配置管理机制，是项目范围管理得到终落实的保证。 在许多软件开发项目中，项目范围管理涉及三个方面：业务需求、技术结构、投产服务。编写哪些程序模块，实现哪些功能，部署到哪些地点，这其实
都是项目范围管理所要关注的内容，在配置管理中对应了产品的物理属性和功能属性以及服务的属性，都可以通过配置管理来识别、记录和跟踪。只有做好软件配置管理，才能真正把项目的范围管理做实。 业务需求决定了软件产品的功能特性，对软件产品的配置管理，首先就是对业务需求的管理。在业务需求中，要求软件产品所提供的各种功能和特性，包括界面风格、操作方式、处理流程、业务规则、数据逻辑等，也都是软件产品的配置项，这种对业务需求的分解、管理的过程，就是对业务需求中的配置项的管理过程。当项目中业务需求发生变更时，其实就是对这些配置项的变更管理。因此，在软件工程过程中，配置管理是需求管理的基本手段，通过科学、严谨的配置管理方法，对业务需求进行识别、分解、跟踪、控制，直接决定了对业务需求的管理能力。许多公司目前在需求管理方面还处于粗放型的管理，虽然基本能够满足项目管理的需要，但对于软件工程过程来说，管理粒度还比较粗，而且缺乏明确的配置项的定义，缺少有效的跟踪控制手段，还需要更精细的管理。 技术结构是软件产品的物理属性，软件产品的配置管理，也是对软件内部技术结构的管理。从技术方案到软件产品、再到产品内部结构，这也是项目范围不断分解、细化的过程。为了实现业务需求、满足产品外部特征的要求，软件产品应如何设计其内部结构，划分内部模块、定义模块接口、确定有多少个程序等等，产品分解到后，每一个程序都作为一个单独的配置项进行管理，在开发过程中对于程序的修改都纳入配置管理，跟踪程序变化过程。这种对软件产品从技术角度的不断分解和定义，就是基于技术结构的配置项管理，是与软件结构设计相对应的，配置项的划分是否合理，使用起来是否灵活、方便，哪些可以成为公共组件（Component），其实反映的都是软件设计的思想。在有的软件企业中，配置管理不只是程序员的操作工具，它已经成为工程技术管理的
(项目管理)项目设计管理
生效日期:2004/01/01 1 总则 1.1 项目设计管理是实现顾客价值、达到公司经营目标的关键环节，涉及项目规划、建筑方案设计、施工图设计（初步设计）、景观设计等。 1.2 全面优化、规范设计管理活动流程和操作规范，确保项目设计管理和设计过程在受控状态下进行，是项目开发过程中保证设计质量、进度，促进销售、控制成本的重要途径。 2 项目设计管理过程一般规定 2.1 项目设计管理内容 2.1.1 各级设计管理部门负责对项目设计工作进行全过程监管，各设计阶段的管理要求包括，但不限于： a)编制、审查各阶段设计指引及设计任务书； b)选择符合资格要求的设计单位； c)配合成本控制、实施限额设计； d)参与设计过程（或事后检查）重要阶段的评审； e)组织技术专家评审和确认各主要阶段的设计成果； f)组织各设计阶段的衔接、协调； g)明确设计更改控制程序，并保证设计更改按规定的程序进行； h)项目完成后的设计总结、资料备案。 2.1.2 各设计阶段的监管工作安排，由管理责任部门负责具体制定，阶段设计工作的监管计划必须明确设计过程中监管内容、责任和具体措施。 2.1.3 项目设计过程中与设计单位或其他单位的组织与技术接口要求，设计管理责任部门在委托设计时必须以书面形式明确，确保各方按规定的要求进行设计信息交流和资料提供、设计成果审查及确认等。 2.2 设计要求 2.2.1 设计管理部门必须按管理公司规定作业流程和指引文件，在各阶段设计开始
生效日期:2004/01/01 前以书面文件形式明确设计要求，形成各阶段的设计任务书。 2.2.2 所有应由开发商提供的项目设计依据，以及设计技术标准都必须作为设计任务书的附件一并提交设计单位，并与设计单位进行确认。 2.2.3 为保证各阶段设计要求的准确、完整，并符合相关法规要求和管理公司规定，设计管理部门负责组织实施必要的设计要求审查。 2.3 设计过程跟进 2.3.1 设计管理部门应按设计监管工作安排，依据设计委托合同对设计过程进行连续监督检查，以保证设计工作进度符合规定要求。 2.3.2 设计过程中，所有对设计进度和设计成果有影响的交流意见均必须形成书面文件，设计管理部门应负责跟进检查落实情况。 2.3.3 设计过程中，所有甲方提出或确认的意见和要求均必须形成书面文件，并存档备案。 2.4 设计成果 2.4.1 设计管理部门与设计单位订立的设计委托合同，或其附件中，必须明确规定对设计成果提交的具体形式和审查要求，确保设计单位提交的设计文件完整性和设计深度。 2.4.2 根据项目的规模和具体情况的需要，可委托有资格的技术专家对设计单位提交的设计成果进行审查。 2.4.3 各阶段设计成果审查均必须包括经济性的审查，规划方案设计及扩初设计须进行成本估算或概算，施工图设计须进行成本预算，确保在项目总成本的控制范围内。 2.4.4 审查中发现的问题，设计管理部门必须以书面文件方式通知设计单位，责成设计单位进行修改，并跟踪记录。 3 规划、建筑、景观方案设计 3.1 规划设计指引必须按照《项目经营策划书》的相关内容及《规划设计指引编制要点》进行编制，作为编制规划设计任务书的主要依据。规划设计任务书由管理公
软件配置管理规范.doc
软件配置管理规范1 1．简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的 本文档指导项目开展配置管理活动。 1.2 范围 本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构 第一部分： 简介，包括本规范的目的、范围、词汇以及所涉及到的参考信息。 第二部分： 配置管理工作规范的正文，包括活动的流程图、进入能及退出的准则、所涉及的角色、相 关活动的阐述、验证与确认能及度量。 第三部分： 变更控制工作规范的正文，包括活动的流程图、进入能及退
出准则、所涉及的角色、相关 活动的阐述、验证与确认能及度量。 第四部分： 参考文献，列出了编写本规范所参考的相关的文献资料。 第五部分： 附录，本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项，包含文档、程序。 CR (Change Request) 变更请求，对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息 是有关当前问题、提议解决方案及其成本的起源和影响的信息。
PCA (Physical Configuration Audit) 物理审计，在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit) 功能审计，核心软件配置项的实际性能是否符合它的需求。 基线(Baseline) 己通过复审和批准的工件发布版，由此构成进一步演进或开发的公认基础，并且只能 通过正式程序，例如变更管理和配置控制才能进行更改。 CML (Configuration Management Library) 配置客理库，存储项目工件的所有版本，即存储项目的定义的配置项。 版本(Version) 某个工件的变体，工件的后期版本一般是在初期版本的基础上进行的扩展。 1.5参考信息 1.5.1 可追溯性 CMU/ SET-93-TR-024 Capability Maturity Model SM for Software, Version 1.1
软件配置管理计划示例
软件配置管理计划示例 作者：赵文锋计划名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 任务 在软件工程化生产的各个阶段中，与本阶段的阶段产品有关的全部信息在软件开发库存放，与前面各个阶段的阶段产品有关的信息则在软件受控库存放。在研制与开发阶段的阶段产品的过程中，开发者和开发小组长有权对本阶段的阶段产品作必要的修改；但是如果开发者或开发小组长认为有必要个性前面有关阶段的阶段产品时，就必须通过项目的配置管理小组办理正规的审批手续。因此，软件开发库属开发这个阶段产品的开发者管理，而软件受控库由项目的配置管理小组管理。软件经过组装与系统测试后，应该送入软件产品库，如欲对其修改，必须经软件配置管理小组研究同意，然后报项目总体组组长批准。关于软件配置要进行修改时的具体审批手续，将在第条中详细规定。 2．3 职责 在软件配置管理小组中，各类人员要互相配合、分工协作，共同担负起整个项目的软件配置管理工作。其中各类人员的分工如下： A．组长是总体组代表，他对有关软件配置管理的各项工作全面负责，特别要对更改建议的审批和评审负责； B．软件工程小组组长负责监督在软件配置管理工作中认真执行软件工程规范； C．项目的专职配置管理人员检查在作配置更改时的质量保证措施； D．各子系统的配置管理人员具体负责实施各自的配置管理工作，并参与各子系统的功能配置检查和物理配置检查；
设计阶段的项目管理
第8章设计阶段的项目管理 学习目标： 1．掌握设计前的准备工作、项目管理规划的类型、组织和项目实施的合同结构。 2．掌握设计过程特点、设计阶段的项目管理类型、设计项目管理工作内容。 3．了解设计竞赛、设计协调的内涵、设计文件的分类与编码和设计文件管理。 4．掌握设计任务的委托方式及合同结构、设计合同的签订、设计阶段合同管理任务、设计合同索赔管理、设计阶段投资控制、进度控制、质量控 制、设计协调的方法和设计阶段信息管理任务， 重点难点： 1、设计阶段的项目管理类型 2、设计委托的合同结构 3、设计阶段的目标控制 4、设计文件的分类与编码 课程内容： 设计过程是项目实施阶段的重要环节，项目管理的“三控三管一协调”六大基本职能也贯穿于整个设计过程的始终，成为设计阶段的项目管理的核心任务。此外，设计过程自身的独特性，则决定了设计阶段的六大基本项目管理职能的特殊性。与实现其它阶段的项目管理职能不同，它们具有一套特殊的管理措施和方法。本章内容包括设计阶段的项目管理概述、设计任务的委托及设计合同的管理、设计阶段的目标控制、设计协调、设计阶段信息管理。 8.1设计阶段的项目管理概述 建设项目设计是集社会、经济、技术和管理为一体的复杂的特殊的系统性生产过程，它不单是设计单位的个体创造，而是业主、设计单位、政府主管部门和其它项目参与方共同参与和协作的成果。而设计阶段项目管理的核心并不是对设计单位工作进行监督，而是通过建立一套沟通、交流与协作的系统化管理制度，帮助业主和设计方去解决设计阶段中，设计单位与业主（建设单位）、政府有关建设主管部门、承包商以及其它项目参与方的组织、沟通和协作问题，实现建设项目建设的艺术、经济、技术和社会效益的平衡。 8.1.1 设计过程特点 要进行设计阶段的项目管理工作，先必须对设计过程的特点有所了解。与施工过程相比，设计过程具有三个方面的特点： 1)创造性 设计过程是一个创造过程，它是一个“无中生有”、从粗到细、从轮廓到清晰的过程。应当注意的是，在工程设计中，设计的原始构思就是一种创造，应最大限度地发挥建筑师的创造性思维。但是在整个设计过程中又并非所有的设计工作都是无中生有的，每个阶段的设计都应当是在上一阶段的设计成果及相关文件依据下而进行的，后阶段设计的重点应该是把设计的原始构思在优化的基础上进
软件配置管理规范流程模板
软件配置管理规范 流程 1 概述 1.1 目的 本文档主要目的在于规范项目配置管理活动, 确保配置项正确地唯一标识而且易于存取, 保证基线配置项的更改受控, 明确基线状态, 在整个软件生命周期中建立和维护项目产品的完整性和可追溯性。 1.2 适用范围本文档适用于不同类别的软件产品和软件项目开发工程的配置管理活动, 针对项目不同在流程上作适当的删减。配置管理可采用各种工具及手工办法, 本文件以CVS( 并行版本系统) 配置管理工具为例, 规定公司的配置管理办法, 使用其它工具时也可对应本文件
的要求参照执行。 1.3 术语和缩略语 1.3.1 软件配置管理( Software Configuration Management, SCM) 软件配置管理是对软件修改进行标识、组织和控制的技术, 用来协调和控制整个过程。是经过技术或行政手段对软件产品及其开发过程和生命周期进行控制、规范的一系列措施。配置管理的目标是记录软件产品的演化过程, 确保软件开发者在软件生命周期中各个阶段都能得到精确的不同版本的产品配置。 1.3.2 配置项( Configuration Item, CI) 凡是纳入配置管理范畴的工 作成果统称为配置项, 配置项逻辑上组成软件系统的各组成部分, 一般是能够单独进行设计、实施和测试的。 每个配置项的主要属性有: 名称、标签、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里, 确保不会混淆、丢失。配置项及其历史记录反映了软件的演化过程。 1.3.3 基线( Baseline) 在配置管理系统中, 基线就是一个配置项或一组配置项在其生命周期的不同时间点上经过正式评审而进入正式受控的一种状态这些配置项构成了一个相对稳定的逻辑实体, 而这个过程被称为基线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了元素( 配置项) 的一个版本, 且只确定一个版本。一般情况下, 基线一般在指定的里程碑处创立, 并与项目中的里程碑保持同步。每个基线都将接受配置管理的严格控制, 基线中的配置项被冻结”了, 不能再
校务通管理系统软件项目配置管理计划案例
软件项目配置管理计划案例 本案例选自《软件项目管理案例教程》（韩万江，机械工业出版社）一书，项目案例为《校务通管理系统》，该项目的配置管理计划如下： 1. 引言 包括目的、缩写词和参考资料，具体内容略。 2．组织及职责 配置管理的角色和职责见表1。 表1：配置管理角色职责表 3.配置管理环境 由于本项目属于中小型项目，工期也不很长，而且项目组人员对Visual SourceSafe也比较熟悉，所以采用Visual SourceSafe作为配置管理工具。 3.1配置库目录结构
3.2用户及权限 4．配置管理活动 4.1 配置项标志 4.1.1 命名规范 本项目配置项命名规范由5个字段组成，从左到右依次为：公司、项目、类型、编号和版本号，如图1所示。这些字段用一横线（-）分隔。
图1：配置项命名规范 4.1.2 主要配置项 QTD-School –RM –SRS-v1.0 公司：3个字符 项目：最长10个字符 类型：最长5个字符 编号：最长8位数字/字符 版本号：V m.n
4.1.3 项目基线 在Visual SourceSafe中基线由LABLE标志，字母必须为大写。基线管理由项目执行负责人确认、SCCB授权，由配置管理员执行。 表5 4.1.4 配置项的版本管理 配置项可能包含的分支从逻辑上可以划分成4个不同功能的分支：主干分支、私有分支、小组分支、集成分支。让它们分别对应4类工作空间。 这四类工作空间（分支）由项目执行负责人统一管理，根据各开发阶段的实际情况定制相应的版本选取规则，来保证开发活动的正常运作。在变更发生时，应及时做好基线的推进。 对配置项的版本管理在不同分支具有不同的策略： （1）主干分支 系统默认自动建立的物理分支——主干分支（/main）,基线均以LABLE方式出现在主干分支上。 （2）私有分支 如果多个开发工程师维护一个配置项时建议建立自己的私有分支。配置管理员对其基本不与管理，如个别私有空间上的版本树过于冗余，将对其冗余版本进行限制。 （3）小组分支 如果出现小组共同开发一配置项，该分支可视为项目组内部分组的私有空间，存放代码开发过程中的版本分支，由项目组内部控制。
EPC项目的设计管理试题解析
一、单项选择题（每小题2分，共40分） 1.建设工程项目安全管理的基本对象为（ A ）。 A.各参建单位 B.劳务分包单位 C.材料、设备等供应商 D.业主 2.以下说法错误的是（ C ）。 A.传统的全寿命周期管理将开发管理、项目管理、设施管理分隔成独立的、互不沟通的管理系统 B.全寿命周期集成化管理就是指在统一的目标、领导、管理思想、管理语言、管理规则、信息处理系统的影响下，实现三管合一的集成化管理 C.“三项管理”是指成本管理、质量管理、进度管理
3.以下关于D-B工程总承包管理模式的概念说法错误的是（C ）。 A.D-B总承包模式是采用单一合同的管理办法，将建设项目交由一家有资格和能力的承包企业，该承包企业全面负责项目的设计、施工、管理工作 B.D-B总承包模式被广泛应用于地铁、桥梁、高速公路、码头，机场等政府投资的基础设施项目中 C.对于项目中使用到的主要材料及设备，业主自行进行采购 D.以上三项都不正确 4.以下关于工程总承包管理模式的说法错误的是（D ）。 A.在D-B工程总承包中，设计施工总承包商承担项目的时间越早，设计与施工可较早的沟通与协作，发挥各自的技术优势，降低工程成本，节省工程投资，带来合理利润 B.EPC工程总承包将项目的设计、采购、施工以及试运行等一
C.PMC工程总承包主要在业主的项目管理经验不足以担当该项目的管理工作的项目中使用 D.以上三项都不正确 5.BOT即（C ），作为一种独特的项目管理办法，它在项目建设的资金筹措、合作的谈判、项目实施、生产经营管理、收益计划与分配、合同纠纷的解决以及相应政策的制定等方面，都有一套独特的运行规则和办法。 A.设计、采购、施工 B.采购、施工 C.建设、运营、转让 D.建设、移交 6.（ D ）在施工管理构成中的特殊地位决定了其参与建设工程安全管理工作能够达到其他参建方所达不到的全面协调与凝聚各方的安全效应。 A.设计单位 B.施工总承包单位 C.政府相关部门 D.业主 7.BIM信息模型在建筑工程全寿命期不同阶段的模型信息是同一的，一样的构件信息没有必要反复地输入，而且模型本身能够
软件配置管理规定
软件配置管理规定 为进一步加强软件配置管理工作，明确软件配置原则，规范软件配置流程，制定本规定。 一、配置原则 1.软件配置遵循安全性、适用性、经济性和正版化的原则，不得配置非正版软件。 2.单位使用的商业软件、OEM软件、免费软件均需纳入配置管理，不得配置与工作无关的各类软件。 3.优先采用场地授权（许可）方式配置软件。 二、配置流程 1.软件使用部门根据本部门各岗位工作需要，编制岗位软件需求清单，填写《软件使用需求申请表》（附件1）。 2.信息化部门统计、汇总软件使用部门报送的《软件使用需求申请表》，对软件使用部门需要的相关软件进行统一测试和试用，综合考虑软件的价格、兼容性、安全性和售后服务等因素，确定软件选型，明确软件名称和版本。涉及使用免费软件的，更新《可使用免费软件清单》（附件2）。 3.信息化部门依据单位软件使用管理台账，梳理单位软件需求与现有软件许可的差异。单位软件许可不足的，编制《软件采购计划表》（附件3）。
4.财务部门要将软件采购纳入单位年度预算。财务、资产管理部门指导信息化部门完成软件采购。软件采购合同要明确软件名称、版本、授权方式、许可数量、使用年限、兼容性和售后服务等要求。 5.财务、资产管理部门指导信息化部门做好软件采购相关资料管理工作，重点是软件采购合同、软件授权证书、软件安装序列号等资料的管理工作。 6.信息化部门负责软件使用管理日常工作。 7.单位采购的软件，因以下情况申请报废的，需经过信息化部门鉴定，严格履行资产处置报批手续：（1）已经达到规定的最低使用年限，且无法继续使用的。 （2）未达到规定的最低使用年限，因技术进步等原因无法继续使用的。 （3）未达到规定的最低使用年限，因计算机硬件报废，且无法迁移到其他计算机上继续使用的。 8.信息化部门在单位新采购软件、报废软件和调整可使用免费软件清单后，更新《软件使用情况汇总表》（附件4）。
软件配置管理规范标准
页眉 软件配置管理规范 1.简介 软件配置管理的目的是保证在整个软件生命周期中软件产品的完整性。 1.1 目的 本文档指导项目开展配置管理活动。 1.2 范围 本文档适用于SWL开发小组批准立项的软件项目。 1.3 文档结构 第一部分： 简介，包括本规范的目的、范围、词汇以及所涉及到的参考信息。 第二部分： 配置管理工作规范的正文，包括活动的流程图、进入能及退出的准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第三部分： 变更控制工作规范的正文，包括活动的流程图、进入能及退出准则、所涉及的角色、相关活动的阐述、验证与确认能及度量。 第四部分： 参考文献，列出了编写本规范所参考的相关的文献资料。 第五部分： 附录，本文中流程图的标准符号定义。 1.4 词汇表 CM (Configuration Management) 配置管理。 CCB (Change Control Board) 变更控制委员会。 CI (Configuration Item) 配置项，包含文档、程序。 CR (Change Request) 变更请求，对提出的要变更工件或流程的任何请求的统称。在变更请求中记录的信息是有关当前问题、提议解决方案及其成本的起源和影响的信息。 PCA (Physical Configuration Audit) 物理审计，在配置管理系统中建成立基线的工件是否为“正确”版本。 FCA (Functional Configuration Audit) 功能审计，核心软件配置项的实际性能是否符合它的需求。 基线(Baseline)
己通过复审和批准的工件发布版，由此构成进一步演进或开发的公认基础，并且只能通过正式程序，例如变更管理和配置控制才能进行更改。 CML (Configuration Management Library) 配置客理库，存储项目工件的所有版本，即存储项目的定义的配置项。 版本(Version) 页脚 页眉 某个工件的变体，工件的后期版本一般是在初期版本的基础上进行的扩展。 1.5参考信息 1.5.1 可追溯性 CMU/ SET-93-TR-024 Capability Maturity Model SM for Software, Version 1.1 1.5.2 方针 SWL开发组项目开发与管理工作方针 1.5.3 过程/规范 项目计划与控制规范 1.5.4 指南 配置管理计划指南 基线策略指南 配置状态报告编制指南 配置审计工作活动指南 配置管理工具指南 VSS 使用指南 组织管理配置库使用指南 软件开发文档命名约定 1.5.5模板 配置管理计划 配置状态报告 配置审计报告 文档变更请求 1.5.6 检查表 无 1.5.7 培训 《软件配置管理教材》 《软件变更控制管理教材》 《Clear Case 配置管理培训教材》 1.5.7 工具 Clear Case Visual SourceSafe Visual Basic Office 97/2000/XP DreamWeaver PhotoShop
软件项目-软件配置管理规范-模板
软件配置管理规范 版本：V1.0
目录 1介绍 (1) 1.1目的 (1) 1.2范围 (1) 2规范概述 (1) 3规范详述 (1) 3.1配置库管理规范 (1) 3.1.1配置库说明： (1) 3.1.2配置库目录结构： (2) 3.1.3配置库权限设置： (4) 3.1.4配置库备份机制： (5) 3.2配置项管理规范： (5) 3.2.1配置项入库： (5) 3.2.2配置项标识： (5) 3.3基线管理规范： (8) 3.3.1基线说明： (8) 3.3.2基线分类： (8) 3.3.3基线命名规则 (9) 3.4其它项配置规则： (9) 3.4.1分支命名规则 (9) 3.4.2Eclipse工作空间命名 (9) 3.4.3版本标签命名规则 (9) 3.5过程简称表： (10) 3.6配置类别简称表: (10)
1 介绍 1.1 目的 本规范目的在于指导配置管理人员如何利用配置库管理所有配置项，从而加强对公司软件产品的控制，保持软件产品在其整个生命周期中的一致性、完整性、可追溯性。 1.2 范围 本规范适用于重要软件产品和软件项目的配置项管理。对于非重要软件或已开发好的软件，可以采用本规范规定的要求的子集。 2 规范概述 本规范应用于软件配置管理过程，主要包括配置库的设置，配置项的标示，基线命名等。 3 规范详述 3.1 配置库管理规范 整个项目开发中，把所有的工作成果存放在四个库中，分别为：开发库、受控库、基线库、产品库，每个库下面对应的分为文档库和代码库两部分。前三个库存放到配置管理工具数据库中，产品库建立在文件服务器\\192……\project目录中，根目录名称为项目编号。 配置管理员根据项目情况（项目规模、人员使用工具习惯等）、开发模式（本地开发、异地分布式开发）、财力等因素，确定配置管理工具软件（如：ClearCase、SVN、VSS等）以及计算机资源（内存、CPU、网络环境）；确定存储库备份环境（备份服务器、备份介质）。 3.1.1 配置库说明： 开发库，包括整个开发过程中处于动态变化过程中的工作成果。 受控库，存放项目计划中定义的需要进行控制工作产品。软件配置管理就是对软件受控库中的各软件项进行管理，因此软件受控库也叫做软件配置管理库。 基线库，存放项目过程的基线配置项。