文 档 说 明< xmlnamespace prefix ="o" ns ="urn:schemas-microsoft-com:office:office" />
| 文档名称 | SDC版本管理.doc | ||
| 文档编号 |
| 版本号 | 初稿 |
| 编 制 | 韩:hanfi@163.com | 日 期 | 2010-08-15 |
| 审 核 |
| 日 期 |
|
|
| 日 期 |
| |
|
| 日 期 |
| |
|
| 日 期 |
| |
| 备 注 |
| ||
文档修改履历
| 版本 | 制定/修订日 | 对应页对应项目 | 制定/修订要点 | 编写 | 批准 | 批准日期 |
| 初稿 | 2010-8-09 | 全页 | 新编写 | 韩 |
|
|
| 初稿 | 2010-8-12 | 全页 | 修改 | 韩 |
|
|
| 初稿 | 2010-8-15 | 6页-13页 | 修改目录结构、增加基线发展附录 | 韩 |
|
|
| 2010-8-16 | 6页 | 修改配置库目录 | 韩 |
|
| |
| 初稿 | 2010-8-20 |
| 增加角色职责说明 | 韩 |
|
|
|
|
|
|
|
|
|
|
该文档的统一编号为：SDC-CM-001
该文档的标题为：SDC平台配置管理计划
SDC平台在对外支持过程中，涉及不同的大小版本，各个项目的应用范围也并不一致，原有的管理过程与规范已经不能满足项目的需要。为了更好的为项目提供支持，使项目本身具有良好的持续性，特制订此配置管理计划。以更好的为项目服务。
l 计算机数据定义Computer Data Definition
对硬件相应的计算机指令所操作的信息元素基本特性的说明。这些特性可包括（但不限于）类型、范围、结构和值。
l 计算机软件部件（CSC）Computer Software Component
计算机软件配置项中功能和性质不同的部分。计算机软件部件可以进一步分解成其它计算机软件部件和计算机软件单元。
l 计算机软件配置项（CSCI）Computer Software Configuration Item
为独立的配置管理而设计的且能满足最终用户功能要求的一组软件。
l 计算机软件文档Computer Software Documents
一个资料或信息的集合，包括计算机软件的列表和打印输出。用文档记录了计算机软件的要求、设计或细节，解释软件的能力和限制条件，并提供在软件运行中或保障时使用的操作命令。
l 计算机软件单元（CSU）Computer Software Unit
计算机软件部件设计中确定的能单独测试的一部分软件。
l 发行Release
为某种目的，对某个可用的软件版本进行的一种配置管理的行为。
l 可重用软件Reusable Software
为一种应用要求开发的，但可全部或部分满足另一种应用要求的软件。
l 软件开发文件Software Development File
有关软件开发和维护保障资料的集合。其内容一般包括（或引用）设计考虑的约束条件、设计文档和数据，进度和状态信息，测试要求、测试用例、测试规程和测试结果。
l 软件保障Software Support
为保障和支持已实现和投入使用的软件正常运行所进行的全部活动。
l 软件测试环境Software Test Environment
测试软件所需的一组自动工具、固件和硬件的集合。自动工具可以包括（但不局限于）测试工具，如模拟软件、代码分析器和测试用例生成器等，也可能包括那些包含在软件工程环境中的工具。
对于任何一个管理流程来说，保证该流程正常运转的前提条件就是要有明确的角色、职责和权限的定义。特别是在引入了软件配置管理的工具之后，比较理想的状态就是：组织内的所有人员按照不同的角色的要求、根据系统赋予的权限来执行相应的动作。因此，在本文档中所说明的这个软件配置管理过程中主要涉及下列的角色和分工：
l 项目经理（Project Manager，PM）：
项目经理是整个软件研发活动的负责人，他根据软件配置控制委员会的建议批准配置管理的各项活动并控制它们的进程。其具体职责为以下几项：
制定和修改项目的组织结构和配置管理策略；
批准、发布配置管理计划；
决定项目起始基线和开发里程碑；
接受并审阅配置控制委员会的报告。
l 配置控制委员会（Configuration Control Board，CCB）：
负责指导和控制配置管理的各项具体活动的进行，为项目经理的决策提供建议。其具体职责为以下几项：
定制开发子系统；
定制访问控制
制定常用策略；
建立、更改基线的设置，审核变更申请；
根据配置管理员的报告决定相应的对策。
l 配置管理员（Configuration Management Officer，CMO）：
根据配置管理计划执行各项管理任务，定期向CCB提交报告，告，并列席CCB的例会。其具体职责为以下几项：
软件配置管理工具的日常管理与维护；
提交配置管理计划；
各配置项的管理与维护；
执行版本控制和变更控制方案；
完成配置审计并提交报告；
对开发人员进行相关的培训；
识别软件开发过程中存在的问题并拟就解决方案。
l 系统集成员（System Integration Officer，SIO）：
系统集成员负责生成和管理项目的内部和外部发布版本，其具体职责为以下几项：
集成修改；
构建系统；
完成对版本的日常维护；
建立外部发布版本。
l 开发人员（Developer，DEV）：
开发人员的职责就是根据组织内确定的软件配置管理计划和相关规定，按照软件配置管理工具的使用模型来完成开发任务。
本文档描述了项目的开发和实施过程中，项目相关软件和文档的管理方法，其中主要包括软件和文档的存放目录、文件的备份机制、程序开发的版本控制办法等信息。
此文档的阅读对象是项目管理人员、部门质量监督员、部门经理、公司质量管理部门、及其他项目相关人员。
n 保证项目开发的进度和质量；
n 提供并优化配置项目各开发阶段的资源；
n 保证项目对外支持过程中的一致性、有序性
n 管理控制项目开发中代码，文档和其他软件项；
各子系统由开发人员根据项目的配置管理计划的要求进行控制。系统源程序代码、可执行代码项目负责人或项目负责人指定人员进行管理。系统所有文档的配置管理由项目负责人或项目负责人指定的人员进行管理。在系统生成新的版本时，必须提供相应的配置报告。（配置报告模版）
主要根据当前配置管理库整理并扩展
根目录 | 一级目录 | 二级目录 | 内容 | 备注 | 权限说明 |
| $/ | 开发库
| 产品立项 | 产品立项文档 |
| 存放开发人员工作产品，进出库操作不受控。项目组需求、设计、编码、测试只对本组成员开放 |
| 项目计划 | 可行性报告 |
| |||
| 项目开发计划 |
| ||||
| 产品测试计划 |
| ||||
| 设计文档 | 需求规格说明书 |
| |||
| 需求分析说明书 |
| ||||
| 概要设计，详细设计 |
| ||||
| 数据字典 |
| ||||
| 项目代码 | 源代码目录 | 临时性 | |||
| 培训文档 | 培训文档，用户手册 |
| |||
| 测试 | 测试用例，测试记录 |
| |||
| 试运行文档 | 试运行文档 |
| |||
| 客户数据资料 | 客户数据资料 |
| |||
| 记录库 | 评审记录 | 评审记录 |
| 存放项目在开发过程中产生的记录文档对项目成员开放出/入库权限 | |
| 会议记录 | 会议记录 |
| |||
| 培训记录 | 培训记录 |
| |||
| 外部记录 | 外部记录 |
| |||
| 受控库 | 管理 | 工作计划 |
| 存放为管理项目开发而产生的工作产品，操作受控制，并做出入库记录。对PM、SCM、开放出/入库权限，对其它项目成员开放只读权限 | |
| 人员计划 |
| ||||
| 评审文档 |
| ||||
| 管理控制程序 |
| ||||
| 其他 |
| ||||
| 工程库 | 立项 |
| 只对SCM开放出/入库权限，其它项目组内人员只是有只读权限。 | ||
| 计划 |
| ||||
| 实施 |
| ||||
| 收尾验收 |
| ||||
| 测量库 | 月报 |
| 对SCM、PM开放出/入库权限，其它人员只有周报、月报的出入库权限 | ||
| 周报 |
| ||||
| 阶段性工作总结 |
| ||||
| 基线库 | 存放基线版本 项目名称+版本+日期 | 基线包含项目的源码、设计文档、用户手册等 | 只对项目SCM开放出/入库权限，其它人员只是有只读权限 | ||
| 产品库 | 已经发布的产品目录（项目名称+版本+日期） | 最终产品，包含二进制代码、用户手册等 | 只对部门SCM开出/入库权限，其它人员对他无权限。 | ||
| …… |
| ||||
| 作废库 | 作废文档、代码等 | 存放废止的文件 | 作废的东西 |
|
由配置管理负责人在适当时间段建立基线库，其它相关人员配合完成。目前我们的开发测试支持等工作共用一个代码库，没有基线。这方面的工作量比较大。
现存测试系统有三个，由不同的小组在修改，必须整合或停止三个系统的同时使用，集中完成基线建立工作，否则基线无法建立。
SDC平台存在很多子项：
toft_jbpm_1.0_jdk14
toft_workflow_1.2
toft-core
toft-exchange
toft-old
toftuiv3tag
toft-utils
toft-workflow
toftcore
这些项目必须依据依赖关系，同步建立基线。
由相应的工作、模块负责人通过SVN对需要修改变更的程序文件进行提取。
如对外支持过程中的BUG修改，则需提取相应基线产品源码、支持文档至开发库。
由相应的工作、模块负责人对程序进行测试，确认修改完成后，在SVN中实施程序修改部分的提交。新增加模块与修改相同。
要变更已经冻结的基线的内容时应该按照以下的过程进行；
n 项目负责人向配置管理负责人提出指示：对评价后的需要变更的内容进行提取；
n 配置管理负责人进行提取，也可在其指导下由项目组相关人员进行；
n 项目组相关人员对于评价后的变更内容进行变更；
n 项目负责人对于变更的品质状况进行确认，向配置管理负责人给出提交要求；
n 配置管理负责人对于确认批准完了的配置管理单位向基线库进行再提交前，应将基线库中原相应内容进行备份以满足可追溯性；
n 配置管理负责人向相关人员通报基线的变更情况；
n 向变更要求者说明变更情况。
（变更申请单）
项目采用的配置管理工具为SVN
配置库内的数据流向规定了工作产品在不同阶段和不同状态下数据存放的规程。
存放内容：开发库中存放项目周期各个阶段的中间产品和项目管理文档。在产品支持过程期间，不同版本的内容可以建立不同的源码子项目录，当工作完成，由配置管理员删除。
权限：项目组的成员对于自己的目录，有读写权限。在项目周期的各个阶段，项目组成员都拥有读取权限，根据需要赋予相应人员写权限。
受控程度:该库中的项目不记录在配置项出入库记录表和配置项状态记录表中。（配置项出入库记录表、配置项状态记录表）
库划分：
存放内容：记录库中存放项目周期各个阶段会议记录、评审记录、培训记录、email备份、还有作废文件。
权限：PM和SCM小组拥有读写权限，项目组其他成员只有读权限。
受控程度: 该目录中的项目不记录在配置项出入库记录表和配置项状态记录表中。
库划分：
按记录的类型分为：
会议记录、评审记录、email备份等
示例说明：
在会议或评审之后，会议记录/评审记录的编写人员将该备忘录，通过邮件发送给PM和SCM 人员，SCM或PM将备忘录放入“记录库→会议记录”目录中。
Email备份，在项目各个阶段的邮件也是非常重要的历史纪录，记录了当时的情况，保留关键的邮件以便查证。
作废箱：存放废止的文件，如配置库废弃不用的Readme文件等
存放内容：受控库中存放项目生命周期各个阶段受到“管理和控制”和“置于配置管理”之下的工作产品。
权限：SCM小组拥有读写权限，项目组其他成员只有读权限。
受控程度: 该库中的项目严格记录在配置项出入库记录表和配置项状态记录表中。
库划分：
管理库、支持库、工程库、测量库、基线库、产品库
管理库：项目计划、成本估算、风险跟踪、培训计划、组织计划
项目计划：存放项目计划、SCM计划、施工进度计划等
成本估算：存放项目估算报告
风险跟踪：存放风险跟踪和管理矩阵
工程库：立项、计划、实施、收尾验收
测量库：周报、开发实施人员日报
周报：存放项目组周报和项目组成员周报
日报：存项目成员开发实施日报
文档编号管理规约.DOC
如配置项发生变更，按《变更程序》执行。
本项目所有受控文档的版本升级规则如下：
l 初稿和所有其他未经评审的文档都不加版本号，初稿文档只在备注栏标注“初稿”即可。
l 文档未通过评审，如果有修改，则需要在备注栏标注“修改稿”，同样也不加版本号。
l 文档第一次通过正式评审后，即形成 1.0版本，成为受控文档，入库前需要在版本号处标注“v< xmlnamespace prefix ="st1" ns ="urn:schemas-microsoft-com:office:smarttags" />1.0”，并在备注栏标注“定稿”。
l 形成1.0版本之后，如有其他修改，视改动量的大小，有不同的升级规则，小改动则按顺序升级副版本号，例如：1.0 à 1.1 à 1.2 ，改动内容要在相应的备忘录里体现；如有大改动，必须经过正式评审，则升级主版本号，例如：1.2 à 2.0。无论大小改动，都需在备注栏标注“改进稿”，如有必要，可以标注修改原因。
l 每天，都将新建文件夹对SVN管理库进行完整备份。其备份目录为..\\配置管理服务器\transback\ yyyymmddDAY
l 每周，都将新建文件夹对SVN管理库进行完整备份。其备份目录为..\\配置管理服务器\transback\ yyyymmddWEEK
l 每月，都将新建文件夹对SVN管理库进行完整备份。备份介质为光盘，备份方式刻录。
1、 变更《变更流程》、《变更申请表》
2、 评审《评审管理流程》、《评审记录表》
3、 配置状况《受控库配置状况报告》
4、 基线《基线出入库记录》、《基线入库申请单》、《基线出库申请单》《基线版本描述》《基线升级申请单》、《基线交付清单》
5、 故障需求处理《故障、需求处理表》、《补丁包描述》
6、 产品《产品出入库记录》、《产品入库申请单》、《产品出库申请单》、《产品版本描述》
平台产品版本应该遵循一个有序的过程，循序发展，产品的每个研发阶段，必须定立基线，以基线作为研发、对外支持的基础。研发期间，增加改进功能，修改上一版本的BUG必须以基线为基准，对外支持必须以项目对应基线为基准。
对外支持版本如果尚未有下一基线，则可以走研发流程，如果下一基线已经确立，则必须走Pack流程
如下所示：
< xmlnamespace prefix ="v" ns ="urn:schemas-microsoft-com:vml" />
产品研发流程中的修改、功能的添加等，需要走修改流程，当需要修改基线时，则需要走基线变更流程。修改流程限制较为宽松，变更流程较为严格
1、首先，要保证基线版本的质量，尽量减少BUG、功能缺失等问题； 2、开发流程按既定目标前进， ver1.0、1.1……2.0； 3、支持版本一定要有确定的基线，支持过程中发现产生BUG，新需求、原有功能完善，均以Pack包发布，如： toftcore_V1.1_Pack_001； toftcore_V2.0_Pack_022； 4、所有在支持过程中发现的BUG，功能缺陷，分阶段通过基线变更，更新至基线版本；所有新功能、新需求，分阶段分析，将必要的功能添加至开发计划。 5、源代码的出库，入库，版本发布、支持版本的发布、Pack包发布必须专人负责，防止引起版本混乱； 6、基线变更必须多级审批，经过严格测试；
评论