《配置项管理规范》_第1页
《配置项管理规范》_第2页
《配置项管理规范》_第3页
《配置项管理规范》_第4页
全文预览已结束

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

文件编号编写:何鹏,修订侯洪志编写时间:2009-6PAGEPAGE22024配置项管理规范定义配置项(ConfigurationItem):由配置管理视为一个单一整体而进行处理的工作产品(例如:在软件生存周期各阶段所产生的各种形式和各种版本的文档、程序、数据等)以及完成工作产品所需的软件工具和支持系统。个人工作区:“工作区”是配置项管理服务器上的文件和文件夹在客户端的副本。用户在工作区中添加、编辑、删除、移动、重命名或者管理任何受源代码管理的项时,这些更改会保留,但是不会影响服务器和其他员工的内容。等到个人工作区的变更稳定了之后,员工再将自己工作区的变动内容提交到服务器,供其他人下载使用。工作任务(活动):记录和跟踪变更请求,并且可以和工具结合通过任务来控制对元素的修改。签入/签出:对元素进行修改前先将元素签出,保证对该元素的独占性,这时候就没有其他人可以修改了,当修改完之后再将这个元素签入,取消对该元素的独占性。配置计划的定义和输出配置管理计划就是对配置管理工作的计划与规范,按照阶段制定,明确各个阶段的负责人,明确各个阶段的配置项输出,明确详细的阶段时间划分,以此为依据进行阶段性成果收集。每个立项发版版本要求应有一个独立的配置计划,计划中需要确定计划名称,计划负责人,过程管理QA,计划内容(包含哪些配置项),配置项确认方式(评审/审核)。。配置计划的定义可以按阶段(概念阶段、开发阶段,产品发版阶段)分别由阶段计划的负责人在计划评审时同步定义输出。概念阶段的输出有产品定义,概要设计等,这些内容可以不按产品/模块去区分。开发阶段又可以分为小的迭代阶段,按照产品划分,每个产品包括详细需求,详细设计,编码及单元/集成测试相关配置项。通常由产品开发经理根据实际情况对模板中的配置项进行裁减,确认。产品发版阶段,需要输出发版测试相关文档、安装文档、手册等,代码由配置管理员最终构造发布的基线为准,安装文档及手册由相关负责人提供。配置项的输出可以从不同的配置管理工具或平台中进行。配置计划模板请参照:配置管理计划.doc识别配置项配置项是指一个软件产品在软件生存周期各个阶段所产生的各种形式(机器可读或人工可读)和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该软件产品软件配置中的一个配置项(configuration

item)。配置项可以根据配置计划的不同阶段来划分类,并且不同的配置项都需要有对应的成果输出。配置项划分及成果输出参考如下。开发阶段成果输出备注开发策划立项任务书概念需求产品定义文档三级目标清单总体设计概要设计文档详细需求产品详细需求与其他产品相关需求可包含在详细需求中产品四级目标清单可包含在详细需求中详细设计详细设计关键特性解决方案数据字典若提交设计文档可不单独提交数据字典编码&单元测试编码&单元测试用例联调测试集成测试总结报告系统性能压力测试报告性能测试报告效率报告环境测试总结报告用户测试报告并发测试报告顾问测试报告遗留问题集成测试联调测试总结报告环境测试总结报告并发测试总结报告效率测试总结报告性能单点并发测试报告需求确认表联调提交集成跟踪单验收测试发版验收测试总结报告产品发版帮助文档手册规范编写规范:版本名称:该名称中应体现版本名称、版本号、类型和附加信息以U8为例:U8水平产品<产品线><版本编号>→U890<水平产品名><行业、插件、补丁或专版名称>[版本类型][行业版本号]→U872汽配版4.3行业版→U872电子行业插件V3.1插件版→U872院校专版专版版本名称体现在整个产品的开发过程的配置管理工作。在产品立项过程中,在立项任务书里的版本名称中没有明确的规范,建议在产品立项过程中也能够参照这个规范,统一版本名称。配置计划名称:该名称中应该体现配置计划属于哪个版本和产品如<版本名称>_<产品>U890_BI_U8商业智能配置项名称:对应配置项名称应该可以体现出对应的开发阶段如详细需求、单元测试报告配置项开发任务:对应配置项进行签入签出的开发任务如sb_配置项开发任务_AR_应收管理_计划阶段_三级开发计划文档名称&文档内容:文档名称需要体现出版本及配置项的内容,如果能够对应到模块级别名称上也应该体现出来。文档内容的编写应遵循配置项对应文档编写模板的要求。文档内容中需包括编写人信息以及每次变更条目的记录信息等。代码编写:参照各种语言的代码编写规范操作规范:在对配置项的产生,变更过程中需要遵循一定的流程,以记录完整的变更情况对文档或代码进行增加或修改时应使用签出→修改→签入的方式进行对应每一次添加或修改应该有独立的活动进行支持,并且使用该活动进行签出签入开发较复杂的内容可采用多分支的方式进行开发,一个分支可以继承于另外一个分支,并且各分支上的修改步相互干扰。项目、活动要对应,不要使用该项目的活动修改其他项目的内容,也不要使用一个活动去修改其他活动的内容。以CC&CQ为例,需要做代码修改的时,首先需要在CQ中建立一个修改活动,然后开发人员使用该活动对代码进行签出,修改,修改完毕后将代码签入,签入内容存储到服务器段,修改活动记录下

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论