配置管理过程域

发表于:2018-7-05 11:03  作者:王小双   来源:简书

字体: | 上一篇 | 下一篇 |我要投稿 | 推荐标签: 配置管理

  实施本过程域要达到以下目标:
  1)软件工作产品的版本得到控制;
  2)软件工作产品的变更得到控制;
  3)利益相关方清楚了解软件工作产品的状态。
  但是,如果把所有软件开发过程的工作产品都严格控制起来,这个代价太大,而且有很多浪费。
  那么,应该哪些软件工作产品纳入配置管理呢?标准中是这样描述的——“置于配置管理之下的工作产品包括向顾客交付的产品、指定的内部工作产品、采购的产品、工具以及在生成和描述这些工作产品时使用的其他项”。
  这里把纳入配置管理的工作产品分成以下几类:
  向顾客交付的产品:通常在合同或者软件研制任务书中明确的那些软件承制方应交付的产品;
  指定的内部工作产品:组织内部要求软件研制任务完成时应交付的产品,比如软件研制任务书中没有明确要交付设计说明,但组织内部要求此类软件应有设计说明归档,则应将设计说明纳入配置管理;
  采购的产品:软件外包合同中要求承制方提供的产品;
  其他项:如纳入配置管理的产品引用的重要文档资料。
  专用实践1.1 标识配置项
  本实践就是要把置于配置管理的工作产品标识出来。标准建议的应标识的工作产品在前面已经有了说明。
  本实践下面的5个子实践完整地阐述了本实践应进行的活动:
  条是“选择作为配置项的工作产品”,b)条是对其“赋予唯一标识符”,c)条是指明作为配置项的工作产品的特征(作者、文件类型等),d)条指明受控时机,e)条标识受控配置项责任人。
  专用实践1.2 建立一个配置管理系统
  本实践就是要求使用工具管理受控的配置项以及变更记录
  配置管理也是需要投入很多时间和精力,所以不能“眉毛胡子一把抓”,标准当中也给出了一个很好的建议——“建立配置管理的多级控制机制”。而控制级的例子,包括:“创建——受作者控制;工程——进行更改时通知利益相关方;开发控制——低层的配置控制委员会控制;正式控制——顾客参与的高层的配置控制委员会控制”。
  这4个控制级别,可以这样理解:
  “创建”对应的是通常所说的开发库,即工作产品由作者控制签入、签出和变更;
  “工程”级别则要求作者更改工作产品时通知相关方;
  “开发控制”可以对应项目组或科室级别的受控库;
  “正式控制”可以对应的是组织级的受控库。
  专用实践1.3 生成或发布基线
  前两个专用实践就是本实践的基础。当已经标识好的、组成基线的配置项用配置管理系统控制起来之后,我们就可以进行本实践的工作——生成或发布基线。
  而且,基线的来源是:“仅从配置管理系统中的配置项生成或发布”。这里表达的意思就是,本实践的前提是组成基线的配置项已经受控,已经纳入配置管理库。
  专用实践2.1 跟踪更改申请
  本实践要求做好变更影响分析,通过评审,并且被记录,被验证关闭。
  做变更影响分析都考虑哪些受影响的对象?
  标准中说,“分析更改申请以确定此更改对此工作产品、相关的工作产品、预算和进度的影响”。这里的“对此工作产品、相关的工作产品、预算和进度的影响”就是变更影响分析的内容和范围。
  变更还要和利益相关方取得一致意见。“实施(更改)处置中所要求的措施,并向利益相关方报告结果”,就是说,更改后的结果(更改的内容、更改可能造成的影响等)要告知利益相关方。
  专用实践2.2 控制配置项
  本实践就是要控制受控配置项变更的各个版本和变更历史。
  控制配置项变更,很重要的一点就是,“为了以维护配置项正确性和完整性的方式纳入更改,从配置管理系统检入和检出配置项”。
  很多开发人员喜欢在自己本地存储的工作产品基础上进行更改,可是如果更改日期距离工作产品产生日期已经很遥远,就会很容易出现版本混乱。所以组织在体系上应规定要更改的配置项应从配置管理系统中检出,在技术上也应在检入的时候进行文本比对以核对是否仅更改了变更申请中所描述的更改内容。
  不仅如此,“所更改的配置项在配置更改经评审批准后发布”,这是要求所有的更改都要进行验证后才允许检入配置管理系统。不经过验证的更改是不允许的。
  专用实践3.1 建立配置管理记录
  本实践要求做好各类配置状态记录,包括:配置项状态、配置项变更历史、各种变更记录以及基线之间的差异。
  其中有个子实践——“描述逐个基线之间的差异”,在一些组织的标准实施当中,经常被忽略或者做得不是太好。
  对基线的记录,仅仅给出基线的版本、构成基线的配置项的版本还是不够的,毕竟基线牵涉到不仅仅是项目组成员,还有项目组外的其它利益相关方。所以还应记录基线之间内容上的差异,以便其它利益相关方获取基线的状态信息。
  专用实践3.2 执行配置审核
  本实践是为了确保配置项正确地受控且受控的配置项也是正确的所进行的活动。
  配置审核分为功能配置审核、物理配置审核、配置管理审核三类:
  功能配置审核是确认基线及其构成的配置项工作产品是否符合需求;
  物理配置审核是确认配置项是否符合体系或者规范对于工作产品的约定(包括SP1.1中所要求的配置项标识、文档特征、时机、责任人等);
  配置管理审核是确认配置管理活动的正确与否(通常由QA人员或更高级的配置管理员来完成)。

上文内容不用于商业目的,如涉及知识产权问题,请权利人联系博为峰小编(021-64471599-8017),我们将立即处理。

Python+Selenium大型电商项目(京东商城)实战直播,优惠名额抢占中>>

评 论

论坛新帖

顶部 底部


建议使用IE 6.0以上浏览器,800×600以上分辨率,法律顾问:上海瀛东律师事务所 张楠律师
版权所有 上海博为峰软件技术股份有限公司 Copyright©51testing.com 2003-2018, 沪ICP备05003035号
投诉及意见反馈:webmaster@51testing.com; 业务联系:service@51testing.com 021-64471599-8017

沪公网安备 31010102002173号

51Testing官方微信

51Testing官方微博

扫一扫 测试知识全知道