学习时间:4月13日
091610
配置管理(交于测试来做更加合理,因为交给开发不安全,开发随时在改):
通过对在软件生命周期的不同时间点上的软件配置进行标识(V1.0、V2.0…),并对这些被标识的软件配置项的更改进行系统控制,从而达到保证软件产品的完整性和可塑性的过程.
目的:
- 可视性
- 管理层能够知道产品特性
- 所有项目参与者在同一平台下交流
- 了解现在和计划的配置
- 管理层可看到变更的影响
- 管理层可选择参与的节点
意义:避免产生异步沟通(与测试沟通结果未告知开发…)
从项目角度:减少返工、减少工作量
从公司角度:节约成本、积累项目财富
常用术语
配置(细项):在技术文档中明确说明并最终组成软件产品的功能或物理属性. 软件版本、软件运行的支持数据. 如:一个用例
配置项(细项的汇总):一组软件功能或物理属性的组合. 如:需求文档、测试用例(所有用例的组合)
基线(已定稿的文档):配置项在其生命周期的不同时间点上通过评审而进入正式受控(已存于配置库)的一种状态,而这个过程被称为“基线化”(从开始到定稿的过程),基线的变更由变更控制委员会(CCB)控制(需修改的文档审核通过后才能再次生效).
版本和版本标识:版本以版本号进行标识
配置库:用于管理配置项的数据库.
工具:
学习时间:4月15日
091611
企业中若有QA,则配置管理一定交由他控制,因为QA是控制流程的,配置管理则是流程中最重要的一部分
配置管理中两个虚拟组织
CCB(变更控制委员会):包括项目经理,测试经理,技术经理,产品经理,以及QA(企业无QA则由测试经理或主管兼任)
具体工作:评审和批准变更
SCM(系统配置管理)团队:
具体工作:协调和实施SCM活动
变更通用流程
CR:Configuration Requirements, 配置需求
CMO:Configuration Management Officer, 配置管理员
有些企业对于不太重要的测试用例可不走变更流程
但产品经理提供的需求文档、测试提供的测试计划和测试报告、开发提供的概要设计和数据字典等具有指导性的文档发生变化必须经过评审才能提交