配置管理过程参考1Word文档格式.docx
- 文档编号:6435570
- 上传时间:2023-05-06
- 格式:DOCX
- 页数:18
- 大小:46.33KB
配置管理过程参考1Word文档格式.docx
《配置管理过程参考1Word文档格式.docx》由会员分享,可在线阅读,更多相关《配置管理过程参考1Word文档格式.docx(18页珍藏版)》请在冰点文库上搜索。
4.5配置审计12
4.5.1概述12
4.5.2主要活动12
4.5.3输入、输出14
4.6组织过程改进活动的配置管理14
4.6.1概述14
4.6.2主要活动14
4.6.3输入、输出15
5.配置变更审批准则16
1.简介
1.1目的
本文档描述了软件项目开发过程中执行项目的软件配置管理所遵循的过程活动。
1.2范围
本文档适用公司中各软件项目开发过程中的软件配置管理活动。
1.3定义、首字母缩写词和缩略语
配置管理(configurationmanagement)——对以下各项运用技术上和行政上的管理和监视的一种学科:
对一个配置项的功能特征和物理特征进行标识并写成文档;
对这些特征的更改进行控制;
对重要处理过程和实施状态进行记录和报告;
以及对规定需求的符合性进行验证。
配置单元(configurationunit)——可放人配置管理库系统和从库中检索的一个配置项或成分的最低层次的实体。
基线(baseline)——已经过正式评审和认可,作为以后进一步开发的基础,并且只有通过正式的更改控制规程才能进行更改的规格说明或产品。
开发配置管理(developmentalconfigurationmanagement)——运用技术上的和行政上的管理去指定或控制那些软件和其相关的技术文档,它们定义一个软件工作产品在开发期间内不断进化的配置。
开发配置管理处在开发者的直接控制之下。
置于开发配置管理之下的配置项不是基线,虽然在其开发的某些点上,它们可能被基线化并置于基线配置管理之下。
基线配置管理(baselineconfigurationmanagement)——建立经正式评审和认可并作为进一步开发工作的基础的基线。
某些诸如软件设计和代码这样的软件工作产品应该有在预先确定点上建立的基线,并且对这些项应该施加严格的更改控制过程。
当与顾客打交道时,这些基线提供控制和稳定性。
1.4参考资料
RationalUnifiedProcess中文版:
IBM
《CMMI3级软件过程改进方法与规范》:
电子工业出版社林锐王惠文董军著
《IEEE的软件配置管理过程》:
IEEE
《CMM1.1》:
SEI
2.角色与职责
●项目经理(ProjectManager,PM)
项目经理是整个项目研发活动的负责人,他根据软件配置控制委员会的建议批准配置管理的各项活动并控制它们的进程。
其具体职责为以下几项:
1)制定和修改项目的组织结构;
2)批准配置管理计划;
3)决定项目起始基线和开发里程碑;
●配置控制委员会(ConfigurationControlBoard,CCB)
CCB成员人数一般为奇数,人数在3~7人范围内
CCB:
由项目经理、软件质量保证人员、配置管理员CMO以及项目组其它资深工程师等组成;
CCB的决策采用“少数服从多数”的原则。
✓负责对变更控制过程进行监督;
✓负责定义在配置管理(CM)中记录的变更请求管理流程;
✓审核变更申请。
●配置管理员(ConfigurationManagementOfficer,CMO)
根据配置管理计划执行各项管理任务,定期向配置经理/SQA经理提交报告,配置管理员具体职责为以下几项:
✓制订CM策略;
✓执行配置审计;
✓软件配置管理工具的日常管理与维护、配置管理库权限的控制;
✓提交配置管理计划;
✓各配置项的管理与维护;
✓执行版本控制和变更控制方案;
✓对开发人员进行相关的培训;
✓识别软件开发过程中存在的和配置有关的问题并拟就解决方案。
●软件质量保证工程师(SoftwareQualityAssurance)
根据配置过程检查项目组配置管理活动,具体职责为以下几项
✓参与评审配置管理计划
✓跟踪配置项的管理和维护
✓跟踪和验证变更
✓协助配置管理员对开发人员的培训
✓帮助SQA经理进行过程过程审计
●系统集成员(SystemIntegrationOfficer,SIO)
集成员可以由项目组内部工程师兼任。
✓软件集成打包、修改;
✓建立集成基线;
✓负责生成和管理项目的内部和外部发布版本。
●开发人员(Developer,DEV)
这里的开发人员包括分析设计人员,编码实现人员。
✓软件设计
✓编码实现
●测试人员(QA)
这里的测试人员包括测试设计员和测试员。
✓设置和执行测试
✓评估测试执行过程
3.流程图
配置管理工作按照如下的流程进行。
该流程给出了配置管理的主要活动和每项活动的输入工作产品、输出工作产品。
输出工作产品均应作为配置管理活动的配置项,在项目资产库中进行管理。
流程图中每个活动的详细过程步骤,将在3.2节中给出描述。
图1配置管理流程图
4.主要活动描述
软件配置管理过程通过以下几个主要活动来达到以下四个目标:
Ø
软件配置管理活动是有计划的
所选定的软件工作产品是巳标识的、受控的和适用的
对已标识的软件工作产品的更改是受控的
受影响的组和个人得到软件基线的状态和内容的通知
4.1识别配置项,制定配置管理计划
4.1.1概述
配置管理计划是执行配置管理活动的基础。
在项目经理完成《项目计划书》之后,由配置经理或测试经理(测试Leader)负责制订配置管理计划,并生成《配置管理计划及配置项列表》。
4.1.2主要活动
1.识别和标识配置项
✓在项目计划阶段,项目经理根据工作拆分的WBS结果,确定本项目除文档外的物理存储结构,填写《配置管理计划及配置项列表》中的“物理存储结构”和“访问权限”
✓所用到的现成商用软件、其他供应商提供的软件(如编译器和操作系统)、非交付软件也应置于配置管理之下。
详细内容见《配置管理指南》
2.组建项目CCB
✓每个项目组需要建立项目级的配置控制委员会(即CCB)作为基线的变更权威,使项目基线的变更得到有效的控制
✓项目可以根据具体需要选择CCB合适的人选,其最小集合是项目经理、技术负责人和测试leader
✓项目经理确定CCB,并在《配置管理计划及配置项列表》的“角色”中记录确定的CCB人选
项目经理将以上表单发送给测试经理(测试Leader)和配置管理员
3.测试经理(测试Leader)在《配置管理计划及配置项列表》中,记录已确定的配置项,及配置管理活动日程,包括:
✓制订配置活动日程
✓编译环境描述
✓配置项清单
✓基线版本跟踪表
对第三方软硬件设备不作为配置项纳入《配置管理计划及配置项列表》进行管理。
这部分属于公共资产。
由系统管理员记录在《公共资产清单》中
,质量控制部经理审阅,每个季度更新一次。
测试经理(测试Leader)汇总项目经理的表单,形成《配置管理计划及配置项列表》
4.《配置管理计划及配置项列表》同其它项目子计划一起评审,评审后纳入配置库,并通知项目组成员和相关人员
4.1.3输入、输出
入口准则
《项目计划书》已经完成
出口准则
《配置管理计划及配置项列表》通过评审
输入工作产品
《项目计划书》
输出工作产品
《配置管理计划及配置项列表》
4.2建立和维护配置管理库
4.2.1概述
组织要求各项目的配置项都要纳入CVS工具中,进行配置管理。
在配置库中,每个项目有自己独立的物理存储空间和逻辑工作域。
对配置库的管理,主要从访问控制、建立配置库的物理结构、建立基线、数据备份进行控制。
此过程是配置管理活动的主要内容,在《配置管理指南》中,对配置库的建立和维护进行了详细的说明。
以下内容是建立与维护配置库的主要活动。
4.2.2主要活动
1.建立配置库和访问权限
✓配置管理员根据《配置管理计划及配置项列表》以及“配置库文档目录结构-项目级”,为该项目建立配置库的物理结构和相应的权限。
✓每个项目都需要设定不同的工作域(如开发域、集成域、发布域)。
详细信息请参看《配置管理指南》。
✓对发布域的内容实行严格的权限管理(一般项目组成员只有“读”权限,只有配置管理员有其它控制权限)和变更控制流程。
✓配置管理员根据《配置管理计划及配置项列表》在质量控制系统AIQCS中建立项目配置信息。
如:
版本号、模块名、角色等。
✓配置库建立完成后,配置管理员以邮件方式通知项目组
2.配置库结构的变更
✓配置管理员根据已经发布版本的变更情况,按照《配置管理指南》对现有配置库的结构进行修改,如新建分支或模块、从配置项列表中删除模块或某个配置项、变更编译环境等。
✓配置库结构的变更,需要得到CCB的审批,需要同步更新《配置管理计划及配置项列表》。
3.维护配置库
建立配置库安全可靠的备份切换机制。
4.2.3输入、输出
项目的配置库已经建立
配置库文档目录结构-项目级.rar
建立好的配置库
4.3配置项变更控制与跟踪
4.3.1概述
组织规定,变更控制通过CVS和AIQCS工具进行。
不同的配置项,其变更控制流程不同。
具体参见AIQCS系统的“系统管理”->
“系统帮助”中的操作手册。
由于需求是整个开发生命周期中的源头,组织要求对需求的变更请求,必须通过CCB的审批。
对组织过程改进项目,《组织标准过程变更请求表》必须经过CCB审批。
审批准则参见第4章“配置变更审批准则”。
4.3.2主要活动
1.产生配置项变更请求CR(ChangeRequest)
✓用户、PSO、测试人员或开发人员发起一个配置项变更请求,可以是需求变更请求、测试中的缺陷、产品发布后的工程故障、源码编译申请、数据库变更申请等
✓变更请求以CR工单的方式录入AIQCS系统,并在系统中实现审批和跟踪流程
2.CCB审批需求变更请求
✓《配置管理计划及配置项列表》中的CCB成员,负责对需求变更请求进行审批,详细流程参见AIQCS系统的“系统管理”->
“系统帮助”->
“需求管理模块操作说明”
✓只有得到CCB批准和分发的需求,变更才被接受
3.跟踪变更请求
变更请求在AIQCS中被跟踪,直到关闭
✓通过AIQCS系统的“统一报表”每周汇总变更状态
4.记录配置项的版本
✓配置项的每个变更版本,需要CheckIn到CVS中,CVS系统自动记载变更版本
5.变更状态分析
✓项目经理、测试经理通过AIQCS系统的“统一报表”,每周分析产品变更状态,从中发现
问题,调整计划和资源
✓“统一报表”中的数据,同时作为量化项目管理中的数据输入,用于项目的性能基线,分
析项目质量和进展。
具体内容,参见《组织过程性能OPP过程》和《量化项目管理QP
M过程》文档
4.3.3输入、输出
基线发布后,由于项目需要,提出变更申请
变更得到批准和跟踪
配置项变更申请CR
AIQCS中的“统一报表”配置项变更记录
4.4建立和维护基线
4.4.1概述
按照阶段划分,在需求评审通过后,建立需求基线;
设计评审通过后,建立设计基线;
产品发布时,建立发布基线。
对不同阶段的基线通过记录和维护基线变更历史,变更状态,使基线维护文档化,保证基线所对应工作产品的完整性。
4.4.2主要活动
1.建立需求基线
评审后的需求由需求管理人员入CVS,由配置管理员打版本标记
FeatureList由需求管理人员入AIQCS,并由测试经理(测试Leader)指定测试工程师进行物理
审计
配置管理员发需求基线建立通知给项目组
2.建立设计基线
总体设计评审通过后,负责设计文档编写的工程师将总体设计、详细设计文档入CVS,由配置管理员打版本标记
项目经理指定人员对配置正确性做物理审计
配置管理员发设计基线建立通知给项目组
3.建立发布基线
参见《V&
V&
PI过程文档》的产品发布过程
4.对基线变更做记录
配置管理员负责维护《配置管理计划及配置项列表》中的“基线版本跟踪表”,对每个基线的版本,变更原因,所包含配置项,审批人,审批时间等信息进行记录,以维护基线所对应工作产品的完整
由于组织使用CVS和AIQCS进行配置和变更管理,每个配置项的详细的变更记录,都记录在系统中,在发布基线时,由配置工程师从CVS、AIQCS中获得最新基线的配置项记录,更新《配置管理计划及配置项列表》中的“配置项清单”
4.4.3输入与输出
待确定的基线工组产品通过评审
基线通过审计
《软件需求规格说明书》、《FeatureList》、《总体设计规格说明书》、release包
《配置管理计划及配置项列表》中的“基线版本跟踪表”
“基线发布通知”
4.5配置审计
4.5.1概述
执行配置审计的目的是保证和维护配置基线的完整。
配置审计包括功能审计和物理审计。
功能审计是通过对基线配置项内容的检查,确认基线是否正确、完整;
物理审计是通过对照基线版本跟踪表的记录,检查基线标识是否与记录一致。
同时,PPQA对照配置管理日程安排,对配置管理活动进行检查,保证配置管理流程按计划,并符合组织标准过程。
4.5.2主要活动
1.需求基线物理审计
配置管理员检查《软件需求规格说明书》是否已经入CVS,AIQCS中的入库Feature与
Feature
List中的是否一致,状态和内容是否一致,并填写《配置审计报告(需求基线)》
测试经理(测试Leader)检查配置库中的版本与《配置管理计划及配置项列表》中的“基线版本跟踪表”是否一致,在《配置审计报告(需求基线)》中签字
2.设计基线物理审计
配置管理员检查设计文档是否已经入CVS,测试经理(测试Leader)检查配置库中的版本与《配置管理计划及配置项列表》中的“基线版本跟踪表”是否一致,并填写《配置审计报告(设计基线)》及签字
3.发布基线功能审计
对发布基线进行功能审计(需求和设计基线,只需要进行物理审计)
参照《V&
PI过程文档》,在产品发布阶段,由配置管理工程师按照发布基线构造发布包,
测试工程师对发布包内容进行确认测试,检查发布包是否完整,文档与发布包是否一致,发
布包功能是否正确(满足UseCase的用户需求)
功能审计通过后,测试工程师填写《配置审计报告(发布基线)》的“功能审计”部分,并
提交测试经理(测试Leader)签字确认。
4.发布基线物理审计
测试经理(测试Leader)负责指定人员对发布基线进行物理审计,检查基线记录信息与CVS、
QCS中的物理存储是否一致,并填写《配置审计报告(发布基线)》的“物理审计”部
分
审计通过后,测试经理(测试Leader)在《配置审计报告(发布基线)》的“物理审计”部
分确认签字。
5.PPQA检查
PPQA按照《配置管理计划及配置项列表》,定期审计配置管理活动。
审计的内容包括:
✓配置管理活动是否按计划进行
✓配置管理活动是否符合组织的配置管理过程
✓审计结果记录在《PPQA检查表》中
✓发现的不符合项,记入QMP系统,提交给项目经理
6.基线发布
通过以上审计和检查后,由测试经理(测试Leader)指定人员发布“产品release通知”给项目组全体
4.5.3输入、输出
项目达到里程碑阶段
必须的审计项通过审计
《配置审计报告(发布基线)》、《配置审计报告(需求基线)》、
《配置审计报告(设计基线)》
《PPQA检查表》
QMP系统的NC项
“产品Release通知”
4.6组织过程改进活动的配置管理
4.6.1概述
组织过程改进(SPI)作为一个特殊项目,也遵循配置管理过程。
本章重点描述对组织过程改进活动和建立组织标准过程(OSSP)如何进行配置管理。
4.6.2主要活动
1、识别配置项
EPGLeader指定人员做SPI活动的配置管理员
EPGLeader在《组织过程改进计划》通过评审后,为SPI活动建立配置管理计划,识别配置项,并将这些输出工作产品文档化到《组织过程改进配置管理计划及配置项列表》中
《组织过程改进配置管理计划及配置项列表》需要通过EPG评审
配置管理员按照《《组织过程改进配置管理计划及配置项列表》建立并维护配置库
2、基线建立和审计
根据《组织过程改进配置管理计划及配置项列表》中的“配置活动日程”表,为OSSP和SPI工作产品建立基线
OSSP需要全部纳入基线管理;
SPI工作产品只有在《组织过程改进配置管理计划及配置项列表》的“配置项列表-SPI工作参品”中标注“需要纳入基线”的工作产品才需要进行版本管理,其它工作产品只做存档
配置管理员对OSSP基线进行物理审计,填写《组织标准过程配置审计报告》
EPG组通过对OSSP的评审进行功能审计,填写《组织标准过程配置审计报告》
PPQA审计配置管理活动,记入《PPQA检查表》,对不符合规程,入到QMP中,发送给EPGLeader进行跟踪管理
审计通过后,EPGLeader向组织发布OSSP基线建立通知
3、配置项变更控制和跟踪
组织标准过程(OSSP)一旦建立了基线,对基线的变更需要填写《组织标准过程变更请求表》经过EPG的审批
审批后的工作产品入到CVS配置库
配置管理员在每个基线建立的同时,生成《组织标准过程配置项状态报告》
作为周期性工作,配置管理员每个月需要从CVS系统中出《组织标准过程配置项状态报告》
4.6.3输入、输出
《组织过程改进计划》通过评审
基线通过物理审计、功能审计和PPQA流程审计
《组织过程改进计划》
《组织过程改进配置管理计划及配置项列表》
《组织标准过程配置审计报告》
《组织标准过程配置项状态报告》
QMP系统的NC项
5.配置变更审批准则
配置项
配置项定义
变更请求
是否需要
CCB审批
变更控制方法
FeatureList
通过评审,形成基线的需求列表
需求变更申请
需要
AIQCS
源程序
包括源代码、配置文件、数据库文件
缺陷;
编译请求;
需求变更申请;
DB变更请求;
不需要;
需要;
CVS
文档
包括需求、设计、二次开发手册
文档的变更日志
不需要
发布包
发布给用户的程序包,包括执行程序、初始化文件、用户手册
readme
Download站点
组织标准过程文档
OSSP文档。
由EPG组开发和维护
组织标准过程变更请求表
发布站点
组织过程改进文档
SPI相关的工作文档
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 配置管理 过程 参考