文档介绍：第17章配置治理 4[Step1]确定配置治理的软硬件资源 4[Step2]制定配置项打算 5[Step3]制定基线打算 5[Step4]制定配置库备份打算 5[Step5]审批《配置治理打算》 6[Step1]创建配置库 6[Step2]分配权限 7[Step3]配置库操作与治理 9[Step1]创建配置项 9[Step2]修改处于“草稿”状态的配置项 9[Step3]技术评审或领导审批 9[Step4]正式公布 9[Step5]变更 10[Step1]变更申请 10[Step2]审批变更申请 10[Step3]安排变更任务 10[Step4]执行变更任务 10[Step5]对更改后的配置项重新进行技术评审(或审批) 10[Step6]结束变更 11第17章配置治理配置治理(ConfigurationManagement,CM)的目的是通过执行版本操纵、变更操纵等规程,以及使用配置治理软件,来保证所有配置项的完整性和可跟踪性。配置治理是对工作成果的一种有效爱护。配置治理过程域是SPP模型的重要组成部分。本规范阐述了配置治理过程域的四个要紧规程:制定配置治理打算[SPP-PROC-CM-PLANNING]配置库治理[SPP-PROC-CM-LIB]配置项版本操纵[SPP-PROC-CM-VERSION]配置项变更操纵[SPP-PROC-CM-CHANGE]上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“要紧步骤”、“输出”、“完成准则”和“度量”均已定义。本规范适用于国内IT企业的软件研发项目。建议用户依照自身情况(如商业目标、研发实力等)适当地修改本规范,然后推广使用。,例如文档、程序和数据等,它们都应当被保存起来,以便查阅和修改。假如把所有文件一股脑地塞进计算机里,那么使用起来确信专门苦恼。毫无疑问,人们应当将文件分门不类、有条理地保存起来。凡是纳入配置治理范畴的工作成果统称为配置项(ConfigurationItem,CI),配置项要紧有两大类:(1)属于产品组成部分的工作成果,例如需求文档、设计文档、源代码、测试用例等。(2)项目治理和机构支撑过程域产生的文档。这些文档尽管不是产品的组成部分,然而值得保存。每个配置项的要紧属性有:名称、标识符、文件状态、版本、作者、日期等。所有配置项都被保存在配置库里,确保可不能混淆、丢失。配置项及其历史记录反映了软件的演化过程。基线(Baseline)由一组配置项组成,这些配置项构成了一个相对稳定的逻辑实体。基线中的配置项被“冻结”了,不能再被任何人随意修改(见变更操纵规程)。基线通常对应于开发过程中的里程碑(Milestone),一个产品能够有多个基线,也能够只有一个基线。基线的要紧属性有:名称、标识符、版本、日期等。通常将交付给客户的基线称为一个“Release”,为内部开发用的基线则称为一个“Build”。所有的项目成员都要使用配置治理软件来爱护自己的工作成果。机构应当采纳统一的配置治理软件,常见的配置治理软件有Microsoft的VisualSourceSafe和Rational的ClearCase等。为了提高配置治理的效率和安全性,机构应当有专门的配置治理员(角色)。配置治理员为每个项目制定《配置治理打算》,创建和维护配置库。鉴于配置治理的重要性和复杂性,机构还应当设立配置操纵委员会(B)。CCB是个虚拟小组,对配置治理各项活动拥有决策权(例如审批打算,审批变更请求等)。B是决策者,而配置治理员是执行者。假如机构的各个项目紧密相关(例如一个产品线下的多个项目),B,B对所有项目的配置治理拥有决策权。假如机构的各个项目相对独立,B的决策采纳“少数服从多数”原则。配置治理的流程如图17-1所示。