全文预览

配置管理计划

上传者:叶子黄了 |  格式:doc  |  页数:9 |  大小:162KB

文档介绍
备份。备份介质为光盘,备份方式刻录。Р10    相关文档Р1、变更《变更流程》、《变更申请表》Р2、评审《评审管理流程》、《评审记录表》Р3、配置状况《受控库配置状况报告》Р4、基线《基线出入库记录》、《基线入库申请单》、《基线出库申请单》《基线版本描述》《基线升级申请单》、《基线交付清单》Р5、故障需求处理《故障、需求处理表》、《补丁包描述》Р6、产品《产品出入库记录》、《产品入库申请单》、《产品出库申请单》、《产品版本描述》Р11    产品版本的制定Р11.1  产品版本的制定Р平台产品版本应该遵循一个有序的过程,循序发展,产品的每个研发阶段,必须定立基线,以基线作为研发、对外支持的基础。研发期间,增加改进功能,修改上一版本的BUG必须以基线为基准,对外支持必须以项目对应基线为基准。Р对外支持版本如果尚未有下一基线,则可以走研发流程,如果下一基线已经确立,则必须走Pack流程Р如下所示:Р Р11.2  产品的修改及基线变更Р产品研发流程中的修改、功能的添加等,需要走修改流程,当需要修改基线时,则需要走基线变更流程。修改流程限制较为宽松,变更流程较为严格Р Р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、基线变更必须多级审批,经过严格测试;

收藏

分享

举报
下载此文档