系统配置管理方案(最终)
配置管理
PM/CMO/QA
5、各审计负责人跟踪问题直 至解决
配置管理 员
版本控制
现代软件开发的特点？ 版本控制？
1. 2. 3. 4. 5. 6.
众多的开发人员 多种多样的文件及 相关资源 多个发布版本 多种开发平台 多个开发地点
怎样对研发项目进行整体管理？ 开发小组成员之间如何以一种有效的机制进行协调？ 如何进行对小组成员各自承担的子项目的统一管理？ 如何对研发小组各成员所作的修改进行统一汇总？ 如何保留修改的轨迹，以便撤销错误的改动？ 对在研发过程中形成的软件的各个版本如何进行标 识，管理及差异识辨？
SVN客户端基本操作-续
① ② ③ ④ ⑤ ⑥ ⑦ ⑧ ⑨ 检出文件（Checkout） 增加文件（Add） 提交文件（Commit） 更新最新文件（Update） 文件重命名（Rename） 修改文件（modify&commit） 删除文件（Delete） 导入/导出文件（Import/Export） 文件锁定/解锁（Get lock/ Release lock）
SVN--服务器端
服务器端： 创建配 置库 创建用 户和组 分配权 限
备注：windows环境下用“VisualSVN
Server” 软件
SVN--客户端
备注：客户端采用“TortoiseSVN”软件，同时用http或者https 的方式访问。
SVN客户端基本操作
SVN客户端基本操作-续
2 、检查相应工作产品并 将对应工作产品，加入产 品库。
产品 库
3、更新《基线记录表》，并邮件 通知干系人。
基线建立规则—变更基线
开发库
2、修改完成后 check in 3 、PM对变更后的 配置项进行验证并 打上变更label,邮 件提交干系人确认.
软件的系统部署和升级流程和管理系统方案
软件系统部署及升级流程及管理第一章总则第一条为保障股份有限公司（简称：公司）信息软件系统安全运行在生产环境，规范软件系统部署与升级流程、控制软件系统的生产运行安全，保证业务流程的顺畅和生产系统的完整性、功能完备，特制定本办法。
第二条本办法所指软件系统包括，但不仅限于公司组织实施的账户管理和受托管理核心业务系统、网上受理系统、呼叫中心系统、投资交易系统、投资估值系统、投资风险控制系统，以及OA办公系统、对外网站系统、基础技术架构系统等涉及的软件系统的部署、安全运行与升级管理。
第三条本办法所指软件系统部署与升级管理主要包括以下内容：软件系统投产前准备、软件系统投产管理、软件系统生产运行管理、软件系统生产安全管理、软件系统升级管理。
第四条信息技术部是本办法的制定部门和执行部门，设立系统运维岗，负责系统软件系统部署、安全运行与升级的具体技术实现，其它相关岗位和部门应按本办法所制定的流程配合完成相关工作。
第二章软件系统投产前准备第五条软件系统的投产关系到整个信息系统的安全运行，应做好充分的投产前准备。
投产前的准备工作包括以下几个方面：环境设备的准备、硬件设备的准备、投产程序和数据的准备、相关投产文档和培训的准备等。
第六条环境设备的准备主要包括：系统架构确认、机房机柜机架配备、电源使用配备、网络线路配备、操作系统预安装和配置、主机命名和网络配置、存储环境配置检查、备份环境、环境参数配置、数据库配置、中间件配置、环境冗余切换配置、通讯配置、部署操作员配置、环境变量、客户端环境等。
第七条硬件设备的准备主要包括：主机连接方式、主机型号配置、处理器频率和数量、内存配置、内置硬盘容量、网卡类型和数量、光纤通道卡型号和数量、其他内置的I/0卡和其他外设等。
第八条投产程序和数据的准备主要包括：目标程序及相关清单说明、可控版本组织、系统配置参数、数据库初始化数据等。
第九条相关投产文档和培训的准备主要包括：《系统安装部署手册》、《系统IT参数配置手册》、《数据备份和恢复操作指导》、《系统故障与恢复手册》、《系统文件目录清单说明》、《系统运行日志存放说明》、《系统各类密码修改说明》、《文件清理计划及操作指导》、《管理员、项目经理、厂商负责人通讯录》以及相应的功能使用培训、安装部署培训、日常维护培训等。
配置管理流程(整理)
流程图1） PM ：项目经理（Project Manager)是负责项目管理的专业人员，项目经理负责一个项目的计划，执行及结束关闭。
目前，项目经理管理角色在多种行业中得到应用，尤其是在建筑、网络技术、通信、软件开发等行业发挥积极而重要的作用。
项目经理的主要对项目目标的完成负责。
项目目标包括项目的项目范围，成本，进度，质量，沟通等多维目标，项目经理通过专业努力，组织团队按项目要求，在一定的时间内完成项目规定的任务。
PMI （The Project Management Institute ）讨论和制定了一套有关项目管理的原则和方法论，形成一套专业的指导体系，强有力地支持了项目经理的专业化发展。
从从业角度，项目经理有时会获得企业法人代表或项目拥有者的授权，在工程项目中全面负责，成为企业法定代表或项目拥有者在工程项目上的代表人。
2）CCB：CCB变更控制委员会(Change Control Board)又名配置控制委员会(Configuration Control Board)实施整体变更控制——变更控制委员会软件开发活动中公认变更控制委员会为最好的策略之一CCB的组成CCB可以由一个小组担任，也可以由多个不同的组担任，负责做出决定究竟将哪些已建议需求变更或新产品特性付诸应用。
典型的变更控制委员会会同样决定在哪一些版本中纠正哪些错误。
CCB的成员应当能代表变更涉及的团体。
其可能包括如下方面的代表：1.产品或计划管理部门2.项目管理部门3.开发部门4.测试或质量保证部门5.市场部或客户代表6.制作用户文档的部门7.技术支持部门8.帮助桌面或用户支持热线部门9.配置管理部门当组建包含软硬件两方面项目的CCB时，还应当包含来自硬件工程、系统工程、制造部门或者硬件质量保证和配置管理的代表。
CCB是系统集成项目的所有者权益代表，负载裁定接受那些变更。
CCB由项目所涉及的多方成员共同组成，通常包括用户和实施方的决策人员。
配置管理方案
元征科技配置管理方案(草稿)深圳元征科技有限公司版权所有Copyright ownership belongs to GUIYI, shall not be reproduced , copied, or used in other ways without permission. Otherwise GUIYI will have the right to pursue legal responsibilities.目录1.前言 (3)1.1.目的 (3)1.2.背景 (3)1.2.1.配置管理现状 (3)1.2.2.源码管理现状 (3)1.2.3.产品现状 (5)2.产品运行的几个环境 (5)2.1.开发环境 (5)2.2.测试环境 (6)2.3.预发布环境(待建) (7)2.4.生产环境(由运维部管理) (7)3.源码版本管理 (7)3.1.研发新库 (7)3.2. 研发旧库 (11)3.3. 库迁移 (11)3.4.源码库管理 (11)4.构建与发布（待补充） (12)4.1.构建 (12)4.2.产品发布 (15)4.2.1.客户端（app）发布 (15)4.3.实施部署 (16)4.4.紧急补丁发布 (17)4.5.升级包发布 .................................................................................... 错误！未定义书签。
5.发布版本注释（release note） (17)6.变更管理（待补充） (18)7.资源管理 (18)7.1.提供统一的工作环境标准 (18)7.2.文件共享(由信息部规划实现) (18)7.3.知识库 (18)8.服务器规划 (19)9.服务器安全管理(待完善) (23)9.1.备份管理 (23)9.2.业务连续性方案（待补充） (23)1.前言1.1.目的本文档针对目前公司的产品/项目规划、研发、发布、系统实施等提出整体的配置管理解决方案。
配置管理策划方案
配置管理策划方案引言配置管理是软件开发过程中非常重要的一环，能够帮助团队有效地保证代码的版本控制和变更管理。
本文档将详细阐述一个配置管理策划方案，包括配置管理的目标、配置项的定义和分类、变更控制流程、配置管理工具的选择以及团队成员的角色和责任等内容。
目标本配置管理策划的目标是：1.实现对软件开发过程中的代码版本控制和变更管理；2.提高团队的工作效率，减少代码冲突和错误；3.确保开发过程中的完整性与一致性；4.实现可追溯性和可重现性。
配置项的定义与分类配置项的定义配置项是指在软件开发过程中需要进行配置管理的各个部分，包括但不限于代码、文档、数据、构建脚本等。
配置项的分类1.软件代码：包括源代码、编译后的可执行文件等。
2.文档：包括需求文档、设计文档、用户手册等。
3.数据：包括测试数据、样本数据等。
4.构建脚本：包括编译脚本、部署脚本等。
变更控制流程变更控制是确保所有配置项的变更都经过审批和记录的过程，下面是变更控制的基本流程：1.变更请求：团队成员需要对某个配置项进行变更时，需提交变更请求。
2.变更评审：变更请求提交后，由配置管理团队进行评审，评估变更的风险和影响。
3.变更批准：若变更请求符合变更管理计划和标准，则被批准。
4.变更实施：经批准的变更由相应的团队成员实施，并记录变更详细信息。
5.验证与审计：验证变更实施的结果，进行审计，确保变更正确实施。
配置管理工具的选择配置管理工具在配置管理中起到至关重要的作用，它能够帮助团队有效地管理配置项的版本和变更。
以下为几种常见的配置管理工具：1.Git：分布式版本控制系统，适用于多分支开发和团队协作。
2.SVN：集中式版本控制系统，适用于较小的项目和个人开发者。
3.Mercurial：分布式版本控制系统，类似于Git，但简化了某些操作。
4.Perforce：适用于大型项目和对性能有较高要求的团队。
根据项目的特点和团队的需求，选择合适的配置管理工具进行使用。
(完整版)系统配置管理方案(最终)
XXX工程XXXXXXXXXXXXXXXXXXXX信息系统建设项目（招标编号：XXXX—EMTC—XXXX）XXXXXX总集成项目配置管理方案XXXXX科技股份有限公司2009年10月目录关于本文档 (1)第1章配置项的标识规则 (3)第2章配置管理计划 (3)2。
1 配置管理计划目的 (3)2。
2 角色、职责和人员 (4)2.3 配置和细化管理控制 (5)2。
3。
1 ...................................................工作空间规则 5 2。
3。
2 ...................................................细化管理控制 5 2。
4 配置状态统计 . (6)2.4。
1 DCB会议备忘录 (6)2。
4。
2 .................................................细化请求的汇总 6 2.4.3 基线状态报告 . (6)2.5 配置审核 (6)第3章配置项说明 (6)关于本文档主题XXX工程XXXXXXXXXXXXXXXXXXXX信息系统建设项目总集成项目配置管理方案说明本文档用于说明系统配置计划，并指导配置管理工作。
适用对象业主方、监理方、承建方相关领导、配置管理员.修订历史版本章节类型日期作者说明1。
0C2009年10月总集成项目配置管理方案说明：类型－创建（C）、修改（U）、删除（D）、增加(A)；评审记录角色签名日期说明第1章配置项的标识规则公司名称—Project Name—Type – Name – Version 其中:项目名称或项目编号:采用立项后的项目名称缩写或给定的项目编号表示系统名称或组件名称：采用约定的缩写规则取长度不超过6位的字符表示类型名称为（标识代码）：项目工作产品名称的标识，为采用约定的缩写规则取长度不超过8位的字符。
➢编号：当配置项为同一模板样式的序列的工作产品时可将编号标识引入，一般为三位数字；➢版本：采取两位，形式为0。
CMMI配置管理计划
CMMI配置管理计划项目配置管理员负责数字签名项目的配置管理，包括配置项的识别、控制、审计和变更管理等。
同时，还需与项目经理、开发团队、测试团队等相关人员建立良好的沟通和协作关系，确保配置管理活动的顺利进行。
2.1.2配置控制委员会配置控制委员会是数字签名项目的决策机构，由项目经理和各相关组织的代表组成。
委员会负责审定项目基线的建立和配置项/单元的标识，评审和审定对项目基线的更改，审定对项目基线库制造的产品的生成。
配置管理员应该与配置控制委员会保持密切的联系，及时向其汇报配置管理的情况，以便委员会能够及时做出决策。
2.1.3项目经理项目经理是数字签名项目的领导者，负责项目的整体规划、组织、实施和控制。
在配置管理方面，项目经理需要与配置管理员、配置控制委员会等相关人员协作，确保配置管理活动符合项目的整体计划和目标。
2.1.4开发团队和测试团队开发团队和测试团队是数字签名项目的核心团队，他们负责开发和测试项目的软件产品。
在配置管理方面，他们需要与配置管理员密切合作，确保软件产品的配置项得到正确的识别、控制和变更管理。
2.2配置管理活动2.2.1配置项识别配置项是指作为单个实体进行处理的硬件、软件或两者的集合。
在数字签名项目中，配置项包括软件产品、文档、测试数据等。
配置管理员需要确定哪些项是配置项，以便进行后续的配置管理活动。
2.2.2配置项控制配置项控制是指对配置项进行标识、版本控制、访问控制等，以确保配置项的正确性和完整性。
配置管理员需要使用相应的工具和流程对配置项进行控制，防止配置项的误用或丢失。
2.2.3配置项审计配置项审计是指对配置管理库系统的结构和设施进行审核，以验证软件基线库内容的完备性和正确性，验证与适用的配置管理标准和规程的符合性。
配置管理员需要定期进行配置项审计，确保配置管理库的正确性和完整性。
2.2.4配置项变更管理配置项变更管理是指对配置项进行变更控制，以确保变更的正确性和可追溯性。
项目管理系统方案
5.系统测试：进行功能测试、性能测试、兼容性测试等，确保系统质量。
6.培训与部署：组织系统培训，确保用户熟练掌握系统操作，然后正式上线。
7.运维与优化：持续关注系统运行状况，及时解决用户反馈的问题，优化系统性能。
六、风险管理
1.技术风险：项目开发过程中可能出现技术难题，影响项目进度。应对措施：加强技术预研，提高团队技术能力，确保技术可行性。
五、风险管理
1.技术风险：项目开发过程中，可能出现技术难题，影响项目进度。应对措施：提前进行技术预研，确保技术可行性；加强团队协作，提高技术攻关能力。
2.业务风险：业务需求变更，可能导致项目范围扩大。应对措施：与业务部门建立良好的沟通机制，及时了解业务需求变更，合理调整项目计划。
3.数据安全风险：项目涉及大量敏感数据，存在数据泄露风险。应对措施：加强数据加密、访问控制、备份恢复等安全措施，确保数据安全。
2.降低项目风险，确保项目质量。
3.实现项目资源的合理配置，提高资源利用率。
4.提升企业项目管理水平，增强企业核心竞争力。
三、系统设计
1.系统架构
本项目采用B/S架构，分为前端展示层、业务逻辑层和数据访问层。前端展示层负责与用户交互，业务逻辑层处理具体业务，数据访问层负责与数据库交互。
2.功能模块
（1）项目管理模块：包括项目创建、项目分解、项目进度管理、项目风险管理等功能。
3.系统设计：根据需求说明书，进行系统设计，输出设计文档。
4.系统开发：按照设计文档，进行前后端开发。
5.系统测试：对开发完成的系统进行功能测试、性能测试、安全测试等。
6.系统部署：将测试合格的系统部署到生产环境。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
XXX工程XXXXXXXXXXXXXXXXXXXX信息
系统建设项目
（招标编号：XXXX-EMTC-XXXX）XXXXXX总集成项目配置
管理方案
XXXXX科技股份有限公司
2009年10月
目录
关于本文档 (1)
第1章配置项的标识规则 (2)
第2章配置管理计划 (2)
2.1 配置管理计划目的 (2)
2.2 角色、职责和人员 (2)
2.3 配置和细化管理控制 (3)
2.3.1 工作空间规则 (3)
2.3.2 细化管理控制 (4)
2.4 配置状态统计 (4)
2.4.1 DCB会议备忘录 (4)
2.4.2 细化请求的汇总 (5)
2.4.3 基线状态报告 (5)
2.5 配置审核 (5)
第3章配置项说明 (5)
金宏工程国家发展改革委药品和医疗器械价格评审信息系统A包总集成项目配置管理方案
关于本文档
主题XXX工程XXXXXXXXXXXXXXXXXXXX信息系统建设项目总集成项目配置管理方案
说明本文档用于说明系统配置计划，并指导配置管理工作。
适用对象业主方、监理方、承建方相关领导、配置管理员。
修订历史
版本章节类
型
日期作者说明
1.0 C 2009年10月总集成项目配置管理方案
说明：类型－创建（C）、修改（U）、删除（D）、增加（A）；
评审记录
角色签名日期说明
第1章配置项的标识规则
公司名称-Project Name-Type – Name – Version 其中：
项目名称或项目编号：采用立项后的项目名称缩写或给定的项目编号表示
系统名称或组件名称：采用约定的缩写规则取长度不超过6位的字符表示
类型名称为（标识代码）：项目工作产品名称的标识，为采用约定的缩写规则取长度不超过8位的字符。
➢编号：当配置项为同一模板样式的序列的工作产品时可将编号标识引入，一般为三位数字；
➢版本：采取两位，形式为0.0，第一版为V1.0，以后每增加0.1表示较小修改，增加1.0表示新的Release。
第2章配置管理计划
2.1配置管理计划目的
配置管理计划编写目的如下：
➢在项目的整个生存周期中建立和维护产品的完整性
➢软件配置管理活动是有计划的
➢确定需要CM控制的工作产品
➢建立和维护工作产品的基线
➢控制对工作产品的细化
2.2角色、职责和人员
2.3配置和细化管理控制
2.3.1工作空间规则
（1）工作空间的划分
➢工作空间分为：项目基线空间(PXST-BASELINE目录)，小组工组空间(PSXT 目录)，个人工作空间；
➢个人工作空间是个人进行与本项目有关工作的目录，在指定PC的工作目录下；
➢小组工作空间是小组中个人工作的集合，在指定服务器的工作空间内；
➢项目基线空间是经过评审纳入基线的配置项，在指定服务器的工作空间内；（2）工作空间的规则
➢小组工作空间中，需要基线化的配置项经过评审后进入项目基线空间；
➢项目基线空间的配置项由DCB通过后，由CM管理员从项目基线空间检出到小组工作空间；
2.3.2细化管理控制
（1）角色及职责
2.4配置状态统计
2.4.1DCB会议备忘录
项目的DCB 会议备忘录需要被维护。
每次DCB会议的备忘录应该按召开会议的时间来命名。
文件名称的格式可以是“DCB日期”(日期格式为YYYYMMDD，其中YYYY是年，MM是月，DD是天)。
例如在2007年12月25日召开的DCB会议，次会议备忘录的文件的名称可以是DCB20071225。
2.4.2细化请求的汇总
CM工程师必须定期（每月）提供细化请求汇总报告给项目经理，用以报告和跟踪每一个细化请求的状态。
2.4.3基线状态报告
基线状态报告用以记录和报告基线项的状态。
CM工程师按计划跟踪软件基线状态并提供此报告。
2.5配置审核
项目的PPQA工程师对CM进行审核，并将审核结果记录在审核报告中。
第3章配置项说明
根据配置项计划，我们将在项目生命周期中的每一个阶段确立基线。
每一个基线确立的标志在于本阶段产生的配置项被技术小组以及PPQA审核通过，并且保存到了配置基线库。
已确立A子包基线的文档如下：。