配置管理无线电分类2010-09-13 10:49:27 阅读334 评论0 字号:大中小订阅文档说明文档修改履历1概述1.1标识该文档的统一编号为:SDC-CM-001该文档的标题为:SDC平台配置管理计划1.1目的SDC平台在对外支持过程中,涉及不同的大小版本,各个项目的应用范围也并不一致,原有的管理过程与规范已经不能满足项目的需要。
为了更好的为项目提供支持,使项目本身具有良好的持续性,特制订此配置管理计划。
以更好的为项目服务。
1.2缩略语定义●计算机数据定义Computer Data Definition对硬件相应的计算机指令所操作的信息元素基本特性的说明。
这些特性可包括(但不限于)类型、范围、结构和值。
●计算机软件部件(CSC)Computer Software Component计算机软件配置项中功能和性质不同的部分。
计算机软件部件可以进一步分解成其它计算机软件部件和计算机软件单元。
●计算机软件配置项(CSCI)Computer Software Configuration Item为独立的配置管理而设计的且能满足最终用户功能要求的一组软件。
●计算机软件文档Computer Software Documents一个资料或信息的集合,包括计算机软件的列表和打印输出。
用文档记录了计算机软件的要求、设计或细节,解释软件的能力和限制条件,并提供在软件运行中或保障时使用的操作命令。
●计算机软件单元(CSU)Computer Software Unit计算机软件部件设计中确定的能单独测试的一部分软件。
●发行Release为某种目的,对某个可用的软件版本进行的一种配置管理的行为。
●可重用软件Reusable Software为一种应用要求开发的,但可全部或部分满足另一种应用要求的软件。
●软件开发文件Software Development File有关软件开发和维护保障资料的集合。
其内容一般包括(或引用)设计考虑的约束条件、设计文档和数据,进度和状态信息,测试要求、测试用例、测试规程和测试结果。
●软件保障Software Support为保障和支持已实现和投入使用的软件正常运行所进行的全部活动。
●软件测试环境Software Test Environment测试软件所需的一组自动工具、固件和硬件的集合。
自动工具可以包括(但不局限于)测试工具,如模拟软件、代码分析器和测试用例生成器等,也可能包括那些包含在软件工程环境中的工具。
1.3软件配置管理角色职责对于任何一个管理流程来说,保证该流程正常运转的前提条件就是要有明确的角色、职责和权限的定义。
特别是在引入了软件配置管理的工具之后,比较理想的状态就是:组织内的所有人员按照不同的角色的要求、根据系统赋予的权限来执行相应的动作。
因此,在本文档中所说明的这个软件配置管理过程中主要涉及下列的角色和分工:●项目经理(Project Manager,PM):项目经理是整个软件研发活动的负责人,他根据软件配置控制委员会的建议批准配置管理的各项活动并控制它们的进程。
其具体职责为以下几项:制定和修改项目的组织结构和配置管理策略;批准、发布配置管理计划;决定项目起始基线和开发里程碑;接受并审阅配置控制委员会的报告。
●配置控制委员会(Configuration Control Board,CCB):负责指导和控制配置管理的各项具体活动的进行,为项目经理的决策提供建议。
其具体职责为以下几项:定制开发子系统;定制访问控制制定常用策略;建立、更改基线的设置,审核变更申请;根据配置管理员的报告决定相应的对策。
●配置管理员(Configuration Management Officer,CMO):根据配置管理计划执行各项管理任务,定期向CCB提交报告,告,并列席CCB的例会。
其具体职责为以下几项:软件配置管理工具的日常管理与维护;提交配置管理计划;各配置项的管理与维护;执行版本控制和变更控制方案;完成配置审计并提交报告;对开发人员进行相关的培训;识别软件开发过程中存在的问题并拟就解决方案。
●系统集成员(System Integration Officer,SI O):系统集成员负责生成和管理项目的内部和外部发布版本,其具体职责为以下几项:集成修改;构建系统;完成对版本的日常维护;建立外部发布版本。
●开发人员(Developer,DEV):开发人员的职责就是根据组织内确定的软件配置管理计划和相关规定,按照软件配置管理工具的使用模型来完成开发任务。
1.4文档概述本文档描述了项目的开发和实施过程中,项目相关软件和文档的管理方法,其中主要包括软件和文档的存放目录、文件的备份机制、程序开发的版本控制办法等信息。
1.5阅读对象此文档的阅读对象是项目管理人员、部门质量监督员、部门经理、公司质量管理部门、及其他项目相关人员。
2配置管理目标⏹保证项目开发的进度和质量;⏹提供并优化配置项目各开发阶段的资源;⏹保证项目对外支持过程中的一致性、有序性⏹管理控制项目开发中代码,文档和其他软件项;3配置管理体制各子系统由开发人员根据项目的配置管理计划的要求进行控制。
系统源程序代码、可执行代码项目负责人或项目负责人指定人员进行管理。
系统所有文档的配置管理由项目负责人或项目负责人指定的人员进行管理。
在系统生成新的版本时,必须提供相应的配置报告。
(配置报告模版)4配置管理目录结构及实施程序4.1文档软件项的存放目录及权限主要根据当前配置管理库整理并扩展4.2配置管理实施过程4.2.1建立基线库由配置管理负责人在适当时间段建立基线库,其它相关人员配合完成。
目前我们的开发测试支持等工作共用一个代码库,没有基线。
这方面的工作量比较大。
现存测试系统有三个,由不同的小组在修改,必须整合或停止三个系统的同时使用,集中完成基线建立工作,否则基线无法建立。
SDC平台存在很多子项:toft_jbpm_1.0_jdk14toft_workflow_1.2toft-coretoft-exchangetoft-oldtoftuiv3tagtoft-utilstoft-workflowtoftcore这些项目必须依据依赖关系,同步建立基线。
4.2.2提取(check out)由相应的工作、模块负责人通过SVN对需要修改变更的程序文件进行提取。
如对外支持过程中的BUG修改,则需提取相应基线产品源码、支持文档至开发库。
4.2.3提交(check in)由相应的工作、模块负责人对程序进行测试,确认修改完成后,在SVN中实施程序修改部分的提交。
新增加模块与修改相同。
4.2.4基线变更要变更已经冻结的基线的内容时应该按照以下的过程进行;⏹项目负责人向配置管理负责人提出指示:对评价后的需要变更的内容进行提取;⏹配置管理负责人进行提取,也可在其指导下由项目组相关人员进行;⏹项目组相关人员对于评价后的变更内容进行变更;⏹项目负责人对于变更的品质状况进行确认,向配置管理负责人给出提交要求;⏹配置管理负责人对于确认批准完了的配置管理单位向基线库进行再提交前,应将基线库中原相应内容进行备份以满足可追溯性;⏹配置管理负责人向相关人员通报基线的变更情况;⏹向变更要求者说明变更情况。
(变更申请单)5配置管理中所使用的工具项目采用的配置管理工具为SVN6配置库说明配置库内的数据流向规定了工作产品在不同阶段和不同状态下数据存放的规程。
6.1开发库存放内容:开发库中存放项目周期各个阶段的中间产品和项目管理文档。
在产品支持过程期间,不同版本的内容可以建立不同的源码子项目录,当工作完成,由配置管理员删除。
权限:项目组的成员对于自己的目录,有读写权限。
在项目周期的各个阶段,项目组成员都拥有读取权限,根据需要赋予相应人员写权限。
受控程度:该库中的项目不记录在配置项出入库记录表和配置项状态记录表中。
(配置项出入库记录表、配置项状态记录表)库划分:6.2记录库存放内容:记录库中存放项目周期各个阶段会议记录、评审记录、培训记录、email备份、还有作废文件。
权限:PM和SCM小组拥有读写权限,项目组其他成员只有读权限。
受控程度:该目录中的项目不记录在配置项出入库记录表和配置项状态记录表中。
库划分:按记录的类型分为:会议记录、评审记录、email备份等示例说明:在会议或评审之后,会议记录/评审记录的编写人员将该备忘录,通过邮件发送给PM和SCM 人员,SCM或PM将备忘录放入“记录库→会议记录”目录中。
Email备份,在项目各个阶段的邮件也是非常重要的历史纪录,记录了当时的情况,保留关键的邮件以便查证。
作废箱:存放废止的文件,如配置库废弃不用的Readme文件等6.3受控库存放内容:受控库中存放项目生命周期各个阶段受到“管理和控制”和“置于配置管理”之下的工作产品。
权限:SCM小组拥有读写权限,项目组其他成员只有读权限。
受控程度:该库中的项目严格记录在配置项出入库记录表和配置项状态记录表中。
库划分:管理库、支持库、工程库、测量库、基线库、产品库管理库:项目计划、成本估算、风险跟踪、培训计划、组织计划项目计划:存放项目计划、SCM计划、施工进度计划等成本估算:存放项目估算报告风险跟踪:存放风险跟踪和管理矩阵工程库:立项、计划、实施、收尾验收测量库:周报、开发实施人员日报周报:存放项目组周报和项目组成员周报日报:存项目成员开发实施日报7配置标识版本文档(需求,设计,计划)标识、版本规则见:文档编号管理规约.DOC8版本控制的约定8.1配置项变更控制如配置项发生变更,按《变更程序》执行。
8.2版本升级规则本项目所有受控文档的版本升级规则如下:●初稿和所有其他未经评审的文档都不加版本号,初稿文档只在备注栏标注“初稿”即可。
●文档未通过评审,如果有修改,则需要在备注栏标注“修改稿”,同样也不加版本号。
●文档第一次通过正式评审后,即形成1.0版本,成为受控文档,入库前需要在版本号处标注“v1.0”,并在备注栏标注“定稿”。
●形成1.0版本之后,如有其他修改,视改动量的大小,有不同的升级规则,小改动则按顺序升级副版本号,例如:1.0 → 1.1 → 1.2 ,改动内容要在相应的备忘录里体现;如有大改动,必须经过正式评审,则升级主版本号,例如:1.2 → 2.0。
无论大小改动,都需在备注栏标注“改进稿”,如有必要,可以标注修改原因。
9备份策略(建议)●每天,都将新建文件夹对SVN管理库进行完整备份。
其备份目录为..\\配置管理服务器\transback\yyyymmddDAY●每周,都将新建文件夹对SVN管理库进行完整备份。
其备份目录为..\\配置管理服务器\transback\yyyymmddWEEK●每月,都将新建文件夹对SVN管理库进行完整备份。