CMMI配置管理计划

合集下载

(CMMI文件)XXX银行XX平台系统开发项目配置管理计划()

(CMMI文件)XXX银行XX平台系统开发项目配置管理计划()

编码:XXXX档案管理平台项目配置管理计划更改控制页序号版本号更改时间更改内容描述填写人目录1目的 (1)2范围 (1)3术语定义 (1)4输入 (1)5项目中配置项的命名 (1)6人员及职责 (1)6.1配置管理人员 (1)6.2配置管理干系人 (2)7配置管理软硬件资源 (2)8配置项计划 (3)8.1配置项 (3)8.1.1基线的配置项 (3)8.1.2非基线的配置项 (4)9基线计划 (6)10配置库规划 (7)11配置库备份计划 (8)12配置项审计计划 (8)13本计划审批意见 (8)1目的明确项目过程中配置管理人员和项目组成员在配置管理活动中的职责和工作范围。

定义配置管理活动过程中采用的工具、方法、技术。

2范围涉及到XXXX档案管理平台项目过程中的所有配置的管理活动。

3术语定义CCB:Change Control Board,变更控制委员会,是公司的常设机构,由公司总裁、研发中心与销售部的相关成员组成,针对不同性质和级别的重大变更问题进行决策,不同的问题组织不同级别的CCB。

4输入依据《项目过程定义书》和《项目计划》完成本计划的编写。

5项目中配置项的命名NK-项目名称缩写-过程名称-类型序号(中文名称)当部分配置项在用当前文件命名规则时,如果仍无法区分可加入日期或姓名配置项命名规则遵循公司<配置项命名规则>文件的要求.6人员及职责6.1配置管理人员角色人员职责及工作范围配置管理员1)选择配置管理工具;2)制定配置管理计划;3)创建配置库、分配权限;4)管理配置库;(包括填写相关的配置管理表格、进行配置库备份等;)5)进行配置审计;6)进行配置变更管理;7)发布基线;8)项目结束后,整理完善文档和记录并提交到组织。

CCB成员1)里程碑评审,基线评审;2)审批重大变更;6.2配置管理干系人角色人员职责及工作范围项目经理审核配置管理活动;项目组成员配合项目经理和配置人员的工作,及时完成和提交配置项;QA工程师定期检查项目的配置管理过程,报告不符合问题;7配置管理软硬件资源配置管理软硬件资源说明配置管理软件名称VSS用来管理文档等;cvs用来管理代码计算机名称计算机配置内存: 4G CPU: 4CPU配置服务器的网络地址128.96.96.348配置项计划作者在开发区完成相关的工作产品后, 工程类产品放入测试评审区,待相关人员完评审修正后,通知配置管理员放入受控区。

CMMI 3标准文档模板-配置管理-配置管理计划

CMMI 3标准文档模板-配置管理-配置管理计划

CMMI 3标准文档模板-配置管理
{ 项目名称}
配置管理计划
Company Information
版本历史
目录
1. 人员及职责 (4)
2. 配置管理软硬件资源 (4)
3. 配置项计划 (4)
4. 基线计划 (5)
5. 配置库备份计划 (5)
附录:本计划审批意见 (6)
1. 人员及职责
提示:
(1)根据《项目计划》中的角色分配,确定配置管理员,CCB(配置控制委员会)成员。

(2)CCB的人数根据项目规模而定。

一般地,项目经理是CCB的负责人。

2. 用于配置管理的软硬件资源
提示:
(1)配置管理员确定本项目的配置管理软件。

例如采用Microsoft公司的Visual SourceSafe或者Rationa公司的l ClearCase。

(2)配置管理员根据所采用的配置管理软件,确定计算机资源(考虑内存、外存、CPU 等)。

3. 配置项计划
提示:配置管理员标识配置项,估计每个配置项的正式发布时间。

标识符的参考格式为Project-Type…Type-Number。

例如:
4. 基线计划
5. 配置库备份计划
提示:配置管理员制定配置库备份计划,指明“何人”在“何时”(频度)将配置库备份到“何处”。

附录:本计划审批意见。

CMMI-配置管理计划

CMMI-配置管理计划

项目编号:xxxxxx项目名称:数字签名配置管理计划草稿初始版修订版无密级秘密绝密修订历史记录目录1.简介 (4)1.1目的 (4)1.2范围 (4)1.3定义、首字母缩写词和缩略语 (4)1.4参考资料 (5)1.5概述 (5)2.软件配置管理 (5)2.1组织、职责和接口 (5)2.2工具、环境和基础设施 (6)3.配置管理活动 (9)3.1配置标识 (9)3.2配置项变更控制 (10)3.3配置管理活动计划 (10)3.4报告和审计 (17)4.培训和资源 (19)4.1培训所需环境 (19)4.2培训参加人员 (19)4.3培训具体安排 (19)5.分包商和厂商软件控制 (19)配置管理计划1.简介1.1目的在数字签名项目的生命周期内,为了保证该项目工作产品、过程记录及项目相关资料的版本统一和完整,特制定本计划。

1.2范围纳入数字签名项目配置管理的配置项、过程记录及其它相关资料。

1.3定义、首字母缩写词和缩略语本小节应提供正确理解此配置管理计划所需的全部术语、首字母缩写词和缩略语的定义。

这些信息可以通过引用项目词汇表来提供。

1.3.1CM (Configuration Management)配置管理。

1.3.2配置项(Configuration item)指定为配置管理的对象且作为单个实体进行处理的硬件、软件或两者的集合。

1.3.3基线(baseline)一种通过正式评审和认可的规范说明或产品,此后将其作为进一步开发的基础,只有通过正式的变更控制过程才可以变更。

1.3.4基线库(Software baseline library)项目软件生命周期中基线的集合。

用VSS软件工具管理时,基线库可以是一个独立的VSS系统,也可以是VSS系统中的一个目录。

1.3.5配置审计(Configuration audit)审核配置管理库系统的结构和设施,验证软件基线库内容的完备性和正确性,验证与适用的配置管理标准和规程的符合性1.3.6配置控制委员会(CCB)有权力管理项目基线的委员会,它代表项目经理和所有可能受到项目基线更改影响的组的利益,由它审定项目基线的建立和配置项/单元的标识,评审和审定对项目基线的更改,审定对项目基线库制造的产品的生成。

CMMI配置管理规程

CMMI配置管理规程

配置管理广东×××技术股份有限公司修订历史记录目录1目的 (4)2适用范围 (4)2.1机构 (4)2.2业务 (4)3名词术语 (4)4概述 (5)5过程定义 (5)5.1配置管理 (5)5.1.1 角色与职责 (6)5.1.2 入口准则 (6)5.1.3 输入 (6)5.1.4 过程活动 (6)5.1.5输出 (8)5.1.6 出口准则 (9)5.1.7 过程度量 (9)5.1.8 确认与验证 (9)6规程 (9)7标准与规范 (9)8裁剪指南 (9)9模板与表格 (9)10实施指导 (10)运用配置标识、版本控制、配置变更控制、配置审计,以及通过使用配置管理软件,来保证所有配置项的完整性和可跟踪性。

2适用范围2.1机构研发中心技术部门及PMO、技术拓展部。

2.2业务贯穿整个项目的配置管理活动。

3名词术语3.1 PP(Project planning):项目策划。

3.2项目干系人(Stakeholder):在一定程度上,对项目的实施和成果负责,或受其影响的群组或个人。

项目干系人可能包括项目团队成员、提供商、客户、最终用户等。

3.3 PMO(Project Management Office):项目管理办公室。

3.4 CCB(Changing Control Board):变更控制委员会。

3.5 CM(Configuration Management):配置管理。

标识和确定系统中配置项的过程,在系统整个生命周期内控制这些项的投放和更动,记录并报告配置的状态和更动要求,验证配置项的完整性和正确性。

3.6 CMO(Configuration Management Officer):配置管理员。

3.7 基线:基线就是项目存储库中每个工件版本在特定时期的一个快照。

在配置管理系统中,基线就是一个CI或一组CI在其生命周期的不同时间点上通过正式评审而进入正式受控的一种状态,而这个过程被称为“基线化”。

CMMI-配置管理计划

CMMI-配置管理计划

项目编号:项目名称:数字签名配置管理支配状态 草稿标识号V1.0初始版当前版本修订版发布日期2C1模板编号密级 无密级 秘密 绝密修订历史记录日期版本说明作者变更恳求号0.1起草李晓娅1.0发布李晓娅目录1.简介41.1目的41.2范围41.3定义、首字母缩写词和缩略语41.4参考资料51.5概述52.软件配置管理52.1组织、职责和接口52.2工具、环境和基础设施63.配置管理活动93.1配置标识93.2配置项变更限制103.3配置管理活动支配113.4报告和审计144.培训和资源154.1培训所需环境154.2培训参与人员164.3培训具体支配165.分包商和厂商软件限制16配置管理支配1.简介1.1目的在数字签名项目的生命周期内,为了保证该项目工作产品、过程记录及项目相关资料的版本统一和完整,特制定本支配。

1.2范围纳入数字签名项目配置管理的配置项、过程记录及其它相关资料。

1.3定义、首字母缩写词和缩略语本小节应供应正确理解此配置管理支配所需的全部术语、首字母缩写词和缩略语的定义。

这些信息可以通过引用项目词汇表来供应。

配置管理。

1.3.1配置项( )指定为配置管理的对象且作为单个实体进行处理的硬件、软件或两者的集合。

1.3.2基线()一种通过正式评审和认可的规范说明或产品,此后将其作为进一步开发的基础,只有通过正式的变更限制过程才可以变更。

1.3.3基线库()项目软件生命周期中基线的集合。

用软件工具管理时,基线库可以是一个独立的系统,也可以是系统中的一个书目。

1.3.4配置审计()审核配置管理库系统的结构和设施,验证软件基线库内容的完备性和正确性,验证及适用的配置管理标准和规程的符合性1.3.5配置限制委员会()有权力管理项目基线的委员会,它代表项目经理和全部可能受到项目基线更改影响的组的利益,由它审定项目基线的建立和配置项/单元的标识,评审和审定对项目基线的更改,审定对项目基线库制造的产品的生成。

全套CMMI(信息系统项目管理)文档模板-配置管理方案

全套CMMI(信息系统项目管理)文档模板-配置管理方案

全套CMMI(信息系统项⽬管理)⽂档模板-配置管理⽅案配置管理⽅案⽬录1简介 (2)1.1⽬的 (2)1.2适⽤范围 (2)1.3术语表 (2)1.4参考资料 (2)1.5职责描述 (2)2配置管理活动 (3)2.1软件资源与硬件资源 (3)2.2标识配置项 (3)2.2.1配置项标识规则 (3)2.2.2配置项名称格式说明 (4)2.2.3配置项 (4)2.3项⽬基线管理 (4)2.3.1基线列表 (5)2.3.2基线建⽴流程 (5)2.3.3基线的变更控制 (6)2.4发布管理 (7)2.5配置库管理 (7)2.5.1各类库结构 (7)2.5.2库的权限设置 (8)2.5.3库的备份与恢复 (8)2.6配置状态的记录和报告 (8)2.7配置审计 (8)2.8⼈员安排与时间安排 (9)3数据资料管理计划 (9)1简介1.1 ⽬的本计划是⽤来指导项⽬配置管理作业的过程与步骤,以便全⾯地管理、保存软件⽣命周期各个配置项,监控各配置项的状态,让⼩组所有成员能及时了解软件基线的状态和内容,从⽽实现对软件过程的控制,持续改进软件流程,保证软件产品质量、降低风险,实现项⽬规划的所有需求,同时提⾼开发团队的⼯作效率、降低软件开发成本。

1.2 适⽤范围本项⽬中纳⼊配置管理的活动:项⽬管理⽂档(如项⽬计划、配置计划等)、项⽬技术⽂档(需求规格说明书、概要设计等)、源程序及模块⽂档、基线、产品、⽤户⽂档、项⽬⼯具。

1.3 术语表1.4 参考资料⽆1.5 职责描述表2-12配置管理活动配置活动的⽬的是向项⽬组每⼀个⼈传达在本项⽬中如何进⾏配置。

参见《配置管理过程⽂件》。

2.1 软件资源与硬件资源2.2 标识配置项2.2.1配置项标识规则项⽬级的配置项是指由于项⽬实施⽽产⽣的记录。

为了便于查询、搜索今后各项⽬的⽂档及版本,下⾯将专门制订⼀套约定,统⼀、规范项⽬的命名格式。

凡进⼊项⽬级配置管理库下的⼯作产品都应依照下列命名约定进⾏。

cmmi对配置管理的定义

cmmi对配置管理的定义

CMMI(Capability Maturity Model Integration)是一种用于评估和改进组织过程能力的模型。

在CMMI中,配置管理(Configuration Management)被视为一项重要的过程领域,它有以下定义:
配置管理是一种系统化的方法,用于识别和管理软件和系统开发生命周期中的配置项。

它包括对配置项进行标识、控制、审查和记录,以确保产品和过程的正确性、一致性和完整性。

配置管理在CMMI中被视为一个关键过程领域,涵盖了以下关键实践领域:
1. 配置管理计划(Configuration Management Planning):制定和维护配置管理计划,确定配置管理的目标、活动和责任。

2. 配置标识(Configuration Identification):为配置项分配唯一的标识符,并跟踪配置项及其变更的版本和状态。

3. 变更控制(Change Control):管理对配置项的变更请求,包括评审和批准变更,确保变更的正确性、合理性和一致性。

4. 配置状态记录(Configuration Status Accounting):记录配置项的状态和历史变更信息,跟踪配置项的版本和配置状态。

5. 配置审核(Configuration Audit):定期进行配置项的审查,验证配置项是否符合规定的要求和标准。

通过配置管理的实践,组织能够更好地控制和管理软件和系统开发过程中的配置项,确保其一致性、可追溯性和可控性,减少配置相关问题的风险,提高产品质量和开发效率。

CMMI3级软件过程 第17章 配置管理

CMMI3级软件过程 第17章 配置管理

第17章配置管理配置管理(Configuration Management,CM)的目的是通过执行版本控制、变更控制等规程,以及使用配置管理软件,来保证所有配置项的完整性和可跟踪性,配置管理是对工作成果的一种有效保护。

☆制定配置管理计划[SPP-PROC-CM-PLANNING]。

☆配置库管理[SPP-PROC-CM-LIB]。

☆配置项版本控制[SPP-PROC-CM-VERSION]。

☆配置项变更控制[SPP-PROC-CM-CHANGE]。

上述每个规程的“目标”、“角色与职责”、“启动准则”、“输入”、“主要步骤”、“输出”、“完成准则”和“度量”均已定义。

本规范适用于国内IT企业的软件研发项目。

建议用户根据自身情况(如商业目标、研发实力等)适当地修改规范,然后推广使用。

17.1 介绍项目研发和管理过程中会产生许许多多地工作成果。

例如文档、程序和数据等,它们都应当背保存起来,以便查阅和修改。

如果把所有文件一股脑地塞进计算机里,那么使用起来肯定很麻烦。

毫无疑问,人们应当将文件分类、有条理地保存起来。

凡是纳入配置管理范畴的工作成果统称为配置项(Configuration Item,CI),配置项主要有两大类:●属于产品组成部分的工作成果,例如需求文档、设计文档、源代码、测试用例等。

●项目管理和机构支撑过程域产生的文档。

这些文档虽然不是产品的组成部分,但是是值得保存。

每个配置项的主要属性有:名称、标识符、文件状态、版本、作者、日期等。

所有配置项都被保存再配置库里,确保不会混淆、丢失。

配置项及其历史记录反映了软件的演化过程。

基线(BaseLine)由一组配置组成,这些配置项构成了一个相对稳定的逻辑实体。

基线中的配置项被“冻结”了,不能再被任何人随意修改(见变更控制规程)。

基线通常对应开发过程中的里程碑(Milestone),一个产品可以有多个基线,也可以只有一个基线。

基线的主要属性有:名称、标识符、版本、日期等。

CMMI-3CM-GP22-配置管理计划模板

CMMI-3CM-GP22-配置管理计划模板

CM计划1 前言1.1 目的本计划是XXX项目计划的组成部分,它规定了在信贷管理系统项目中如何开展配置管理工作,以便在项目的整个生存周期中,建立和维护工作产品的完整性和一致性。

1.2术语定义和缩写词CCB(Configuration Control Board):配置控制委员会Baseline:基线,是开发规程中标识出的里程碑所交付的一个或多个配置项,它有以下三个特征:•已经通过正式的评审和批准;•作为项目扩展和产品升级的基础;•其变更必须遵循《配置管理规程》的约定。

1.3 参考文献《配置管理规程》项目计划初稿2 角色、职责与培训2.1 角色与职责2.2 CCB组成3 配置管理活动3.1 基线和配置项的标识本项目的配置项和基线的名称和编号参见《配置项状态报告》。

项目初期,需要确定项目的配置项并对其进行标识。

当新增或修改配置项时,同样需要对配置项进行标识。

本项目的配置项和基线的标识详见《配置项标识和状态列表》(基线的变更标识依照《配置管理规程》执行),该表包括配置项和基线清单及预计创建时间。

3.2 配置库结构和权限3.2.1 配置管理库描述本配置管理库作为CVS中的一个独立的源代码仓库(Repository),分成四个物理上互相独立的存储空间:产品空间、基线空间、组工作空间和个人空间,每个空间作为一个独立的目录(用module实现)。

产品空间属于产品库,基线空间、组工作空间的内容均属于受控库,个人空间的内容属于开发库。

产品空间:存放提交给用户的产品;基线空间:存放所有基线内容。

组工作空间:存放经过评审的文档和所有不放入基线库的工作产品,个人空间:项目组成员存放个人任何信息,文档的开发和修改均在个人空间进行。

从个人空间向组工作空间的提升由项目经理批准,从组工作空间向基线空间的提升由CCB评审批准,均由CM工程师执行。

提升后删除原空间的配置项。

产品空间用Tag的方式标识不同版本的产品。

例如,软件需求规格说明书在编写或修改时,放到作者的个人空间进行管理,经过评审后,提升到相应的“211 需求规格说明书”目录中,形成基线后,再提升到“110 需求规格说明书”。

CMMI配置管理计划

CMMI配置管理计划

CMMI配置管理计划项目配置管理员负责数字签名项目的配置管理,包括配置项的识别、控制、审计和变更管理等。

同时,还需与项目经理、开发团队、测试团队等相关人员建立良好的沟通和协作关系,确保配置管理活动的顺利进行。

2.1.2配置控制委员会配置控制委员会是数字签名项目的决策机构,由项目经理和各相关组织的代表组成。

委员会负责审定项目基线的建立和配置项/单元的标识,评审和审定对项目基线的更改,审定对项目基线库制造的产品的生成。

配置管理员应该与配置控制委员会保持密切的联系,及时向其汇报配置管理的情况,以便委员会能够及时做出决策。

2.1.3项目经理项目经理是数字签名项目的领导者,负责项目的整体规划、组织、实施和控制。

在配置管理方面,项目经理需要与配置管理员、配置控制委员会等相关人员协作,确保配置管理活动符合项目的整体计划和目标。

2.1.4开发团队和测试团队开发团队和测试团队是数字签名项目的核心团队,他们负责开发和测试项目的软件产品。

在配置管理方面,他们需要与配置管理员密切合作,确保软件产品的配置项得到正确的识别、控制和变更管理。

2.2配置管理活动2.2.1配置项识别配置项是指作为单个实体进行处理的硬件、软件或两者的集合。

在数字签名项目中,配置项包括软件产品、文档、测试数据等。

配置管理员需要确定哪些项是配置项,以便进行后续的配置管理活动。

2.2.2配置项控制配置项控制是指对配置项进行标识、版本控制、访问控制等,以确保配置项的正确性和完整性。

配置管理员需要使用相应的工具和流程对配置项进行控制,防止配置项的误用或丢失。

2.2.3配置项审计配置项审计是指对配置管理库系统的结构和设施进行审核,以验证软件基线库内容的完备性和正确性,验证与适用的配置管理标准和规程的符合性。

配置管理员需要定期进行配置项审计,确保配置管理库的正确性和完整性。

2.2.4配置项变更管理配置项变更管理是指对配置项进行变更控制,以确保变更的正确性和可追溯性。

CMMI中配置管理

CMMI中配置管理
受控软件经常被划分为各类配置项(Configuraion items, CIs),这类 划分是进行软件配置管理的基础和前提,CIs是逻辑上组成软பைடு நூலகம்系统的各 组成部分。比如一个软件产品包括几个程序模块,每个程序模块及其相 关文档和支撑数据可能被命名为一个CI。一个系统包括的CIs的数目是一 个与设计密切相关的问题。一个纯软件的CI通常也称之为软件配置项 (CSCI)。
现在所有的配置管理工具均提供对配置项的管理工具,包括(Check in 和Check out机制的 )版本管理和版本标号功能。由于版本和标号管理比 较繁琐,一般推荐使用配置管理工具,减少事务性工作。
基线
在配置管理系统中,基线就是一个CI或一组CIs在其生命周期的不同时间 点上通过正式评审而进入正式受控的一种状态,而这个过程被称为“基 线化”。每一个基线都是其下一步开发的出发点和参考点。基线确定了 元素(配置项)的一个版本,且只确定一个版本。一般情况下,基线一 般在指定的里程碑处创建,并与项目中的里程碑保持同步。
配置审计 配置审计的主要作用是作为变更控制的补充手段,来确保某 一变更需求已被切实实现。在某些情况下,它被作为正式的 技术复审的一部分,但当软件配置管理是一个正式的活动时, 该活动由SQA人员单独执行。 审计机制保证修改的动作被完 整地记录,也就是说,记录了谁修改了这个工件,什么时候 做的修改,为什么原因做出这个改动,以及修改了哪些地方。 在版本控制过程中,如果利用一些配置管理工具(或者版本 控制工具)的支持,则可以自动地记录审计工作所需的四个 “W”(Who、When、Why、What)。 同时配置审计工作 应当可以说明如下信息。
变更管理的流程: 1.(获得)提出变更请求; 2.由CCB审核并决定是否批准; 3.为(被接受)修改请求分配人员,提取SCI,进行修改; 4.提交修改后的SCI,并测试(或者评审); 5.重建软件的适当版本; 6.复审(审计)所有SCI的变化; 7.发布新版本。

CMMI3_之配置管理

CMMI3_之配置管理


16
© 1995-2002 Soft Tech Development, Inc. All rights reserved.
配置审计

配置审计是指对于存储配置项及相关记录的软 件基线库的结构、内容进行检验,其目的在于 验证基线是否符合描述基线的文档。

配置审核工作主要集中在两个方面,即:


功能配置审核 (FCA)—— 验证配置项的实际功效是 与其软件需求一致的。 物理配置审核 (PCA)—— 确定配置项符合预期的物 理特性,即特定的媒体形式。

17
© 1995-2002 Soft Tech Development, Inc. All rights reserved.

14
© 1995-2002 Soft Tech Development, Inc. All rights reserved.
软件配置库的要求

安全可靠性


保证软件配置库中的内容不被任意删除、修 改 保证软件配置库不被非法用户获取 保证各阶段基线各配置项的完整性

22
© 1995-2002 Soft Tech Development, Inc. All rights reserved.
特定活动

SP 1.2-1 Establish a Configuration Management System

10
© 1995-2002 Soft Tech Development, Inc. All rights reserved.

The CM Wheel
Identification
CM PLAN
Accounting Audit Control

CMMI3之配置管理

CMMI3之配置管理

降低开发通过规范化的 流程和工具,降低了因 版本混乱导致的错误和
缺陷修复成本。
配置管理通过有效的变 更管理和审核机制,避 免了不必要的返工和重 复劳动,降低了开发成
本。
配置管理通过优化资源 配置和提高工作效率, 减少了人力和物力资源 的浪费,进一步降低了
开发成本。
05
配置管理的最佳实践和案例分享
性和可靠性。
通过配置管理数据库,可以方 便地查询、修改和管理配置项, 提高软件开发的效率和质量管
理水平。
变更管理工具
变更管理工具用于协调和控制软件开发生命周期中的变更,确保变更的合 理性和可控性。
变更管理工具通常包括变更请求、变更评估、变更实施和变更验证等环节 的管理功能。
通过变更管理工具,可以有效地跟踪和管理变更,降低变更对软件开发过 程的影响,提高软件质量。
成功的配置管理经验分享
建立明确的配置管理流程
制定详细的配置管理计划,明确配置项、配置标识、配置 控制和配置审计等环节,确保所有相关人员都清楚自己的 责任。
实施定期的配置审计
为了确保配置管理的有效性和合规性,应定期进行配置审 计,检查配置管理活动的执行情况,识别存在的问题并及 时纠正。
建立配置管理知识库
对配置管理活动进行审查,确保其符合计划 要求和标准。
制定配置审计计划
明确配置审计的目标、范围、方法和时间表。
配置审计报告
生成配置审计报告,总结审计结果,并提出 改进建议。
03
配置管理工具
版本控制工具
01
版本控制工具用于管理软件配置项的变更,确保在软件开发过 程中,各个版本之间的一致性和可追溯性。
配置项发布
将经过批准的配置项发布到相应的存储库,并对其进行版本控制。

基于CMM和CMMI的配置管理(一)

基于CMM和CMMI的配置管理(一)

基于CMM和CMMI的配置管理(一)1 配置管理内容的逻辑关系在CMM和CMMI中,将配置管理的目的定义为“建立和维护产品的完整性”,这个目标没有提到对项目管理的支持,也就是说,它定义的配置管理的目标比当前业界对配置管理的认识有些缩小。

但是,仔细分析可以发现“建立和维护产品的完整性”是其他配置管理目标的基础。

下面就从这个目标出发进行分析。

逻辑关系见下图:配置完整性(对标准的理解)1. 产品完整性:就是项目提交的工作成果是“产品集合完整、子产品的正确”的2. 产品集合完整:产品包含的子产品(配置项)是完整的3. 子产品的正确:子产品(配置项)达到了需求要求,满足标准、规程的要求逻辑关系分析1. “基线管理”支持“产品集合完整”,明确产品的“子产品”(配置项)集合,并进行管理和控制2. “配置项管理”,提供了了对子产品(配置项)的控制管理,支持“子产品的正确”3. “变更管理”,同时支持“产品集合完整、子产品的正确”,用于控制子产品(配置项)和产品(基线)的变更4. “配置标示”,建立对配置项(子产品)的识别、命名,支持“配置项管理”5. “版本控制”,控制配置项(子产品)生命历程,保留配置项(子产品)演进历史6. “过程管理”,就是对配置项、基线的建立、变更的状态标示、过程控制,保证产品(或子产品)按照规定的流程进行了操作;例如“配置项”进入“基线”的过程包括:配置项标示、产品验证、进入配置、配置审计等7. “配置计划”、“配置库管理”、“配置审计”、“配置报告”等是整个配置管理得支持系统。

提供了配置管理“可视性”和监督管理2 配置和配置项在配置管理中,“配置”和“配置项”是重要的概念,“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。

因此“配置”包括了即将受控的所有产品特性,其内容及相关文档,软件版本,变更文档,软件运行的支持数据,以及其他一切保证软件一致性的组成要素,相对与硬件类配置,软件产品的“配置”包括更多的内容并具有易变性。

基于CMM和CMMI的配置管理(一)

基于CMM和CMMI的配置管理(一)

基于CMM和CMMI的配置管理(一)1 配置管理内容的逻辑关系在CMM和CMMI中,将配置管理的目的定义为“建立和维护产品的完整性”,这个目标没有提到对项目管理的支持,也就是说,它定义的配置管理的目标比当前业界对配置管理的认识有些缩小。

但是,仔细分析可以发现“建立和维护产品的完整性”是其他配置管理目标的基础。

下面就从这个目标出发进行分析。

逻辑关系见下图:配置完整性(对标准的理解)1. 产品完整性:就是项目提交的工作成果是“产品集合完整、子产品的正确”的2. 产品集合完整:产品包含的子产品(配置项)是完整的3. 子产品的正确:子产品(配置项)达到了需求要求,满足标准、规程的要求逻辑关系分析1. “基线管理”支持“产品集合完整”,明确产品的“子产品”(配置项)集合,并进行管理和控制2. “配置项管理”,提供了了对子产品(配置项)的控制管理,支持“子产品的正确”3. “变更管理”,同时支持“产品集合完整、子产品的正确”,用于控制子产品(配置项)和产品(基线)的变更4. “配置标示”,建立对配置项(子产品)的识别、命名,支持“配置项管理”5. “版本控制”,控制配置项(子产品)生命历程,保留配置项(子产品)演进历史6. “过程管理”,就是对配置项、基线的建立、变更的状态标示、过程控制,保证产品(或子产品)按照规定的流程进行了操作;例如“配置项”进入“基线”的过程包括:配置项标示、产品验证、进入配置、配置审计等7. “配置计划”、“配置库管理”、“配置审计”、“配置报告”等是整个配置管理得支持系统。

提供了配置管理“可视性”和监督管理2 配置和配置项在配置管理中,“配置”和“配置项”是重要的概念,“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。

因此“配置”包括了即将受控的所有产品特性,其内容及相关文档,软件版本,变更文档,软件运行的支持数据,以及其他一切保证软件一致性的组成要素,相对与硬件类配置,软件产品的“配置”包括更多的内容并具有易变性。

CMMI3配置管理文件

CMMI3配置管理文件
1. 2. 3. 4. 5. 6. 7. 8. 9. 所有经过批准的变更都已经得到实施 相关的配置项得到更新 没有进行未经授权的变更 已经建立了适当的状态报告入口 所有的新增或者变更的配置项都经过了质量检查点 发布的产品和软件需求、设计保持一致的 对发布进行评审,以确保产品满足客户需求 相关的变更控制机构已经审核过未处理的变更请求 版本描述文件已经准备完成
基础管理篇
之(一)
1
配置管理(CM)
Agenda
项目中的CM问题 CMMI中CM过程域描述与定义 CM的实践 CM工具
3
项目中的CM问题
4
开发中典型的CM问题
发错了版本 安装后不工作 异地不能正常工作 已经解决的缺陷过后又出现错误 开发人员把产品拿出去出售赢利 找不到最新修改了的源程序
5
CMMI模型有关CM实践解析
基线是一组配置项(CI)的集合:
– 经过了正式的评审和批准 – 作为进一步工作的基础 – 变更必须经过正式的变更控制程序
不同的基线可能:
– 在开发的不同阶段建立 – 控制权限会有不同
1.2 定义基线
31
推荐的基线
基线 需求 开发 运行 何时建立 客户需求评审 概要设计评审 发布给客户 CCB 项目经理 CCB 控制者
职能:
– – – – 确保变更被分类以及被评估 评审和批准变更 确保只有被批准的变更得到实施 决定需要实施的变更的优先级
变更控制活动必须在整个项目中具有可视性 CCB成员可能包括: 项目经理,配置管理员,质 量保证人员,开发人员代表,客户代表
36
CCB主席的职责
设立接收变更的标准 发起对请求的变更的评估 从CCB成员获取建议的行动方案 解决关于变更请求的争议 做出CCB负责的裁决的最终决策 记录CCB会议纪要,记录 CCB对变更请求的 处理行动

CMMI配置管理及变更流程介绍

CMMI配置管理及变更流程介绍

2)SVN(已文档库为主) SVN全名Subversion,即版本控制系统。 192.168.5.17
HANWEB NETWORK CO., LTD © 2007
HANWEB
. COM
中国电子政务专业提供商
公司的组织财富库 • 请参见svn\cmmi\Support the process\CM\01 过程规程 \组织财富库管理规程.doc
HANWEB NETWORK CO., LTD © 2007
HANWEB 变更
. COM
中国电子政务专业提供商
变更会涉及到的配置项,举例:
是否影响 需求发生变更
需求
项目软件需求说明书、 需求分析报告;
是否影响
产品设计说明书、数 据库设计、产品文件 目录结构;
进度计划、总体计划、 集成测试计划;
HANWEB NETWORK CO., LTD © 2007
基本概念: • 配置项
1)凡是纳入配置管理范畴的工作成果统称为配置项(CI)。配置项 主要有两大类: 属于产品组成部分的工作成果,例如源代码、需求文档、设计文 档、等等即目前公司采用的配置项。 在管理过程中产生的文档例如各种周报、监控报告等等,这些文 档虽然不是产品的组成部分,但是值得保存,也就是我们的数据 项。 2)每个配置项的主要属性有:名称、标识符、版本、作者、日期等。 所有配置项都被保存在配置库里,确保不会混淆、丢失。配置项 及其历史记录反映了软件的演化过程
HANWEB
注意事项
. COM
中国电子政务专业提供商
• 1、配置审计由CM工程师与项目经理共同完成 • 2、测试人员系统(集成)测试的包由CM工程师提供
HANWEB
. COM
中国电子政务专业提供商

CMMI-支持-CM-配置管理计划制定规程_V1.2

CMMI-支持-CM-配置管理计划制定规程_V1.2

广州润衡软件连锁有限公司软件配置管理计划制定规程软件配置管理计划制定规程变更记录修改点说明的内容有如下几种:创建、修改(+修改说明)、删除(+删除说明)目录1简介 (1)1.1文档目的 (1)1.2适用范围 (1)1.3背景描述 (1)1.4缩略语 (1)2参考资料 (2)2.1标准文件 (2)2.2引用文件 (2)3机构描述 (2)4规程概述 (2)5软件配置管理计划内容描述 (3)5.1组织和资源 (3)5.1.1软件配置管理组织结构 (3)5.1.2角色功能介绍 (3)5.1.3软件配置管理所需资源 (4)5.2配置项和基线 (4)5.2.1识别定义配置项 (4)5.2.2配置项标识 (5)5.2.3配置基线库 (5)5.3基线变更控制 (5)5.4状态报告 (6)5.5基线审计及发布 (6)5.5.1基线的建立与批准 (6)5.5.2基线审计 (6)5.5.3基线发布 (7)5.6估计时间表 (7)5.7配置库权限管理 (7)5.8配置库备份 (7)5.9培训 (8)1 简介1.1 文档目的本规程是描述在项目阶段软件配置管理计划制定的程序及需要进行的活动。

1.2 适用范围本规程适用于组织中的各个项目的软件配置管理计划的制定。

1.3 背景描述软件配置管理计划是在整个项目立项阶段,为保证需求活动能够置于配置管理之下,在核心组成立之后就开始制定的。

软件配置管理计划(SCMP),连同软件质量保证计划(SQAP)和其他的描述规范的计划都附属于软件项目计划。

软件配置管理计划应该与项目开发计划一同完成,以保证软件配置管理计划的范围同项目开发计划的范围一致。

通过识别应置于配置管理之下的配置项和将要在此基础上建立的准则,就可以决定软件配置管理的需求范围和作用时间。

软件配置管理负责人应该用软件配置管理计划模板来制定软件配置管理计划,模板描述了需求格式和计划内容。

软件配置管理计划完成之后应该交由项目经理,软件质量保证(SQA)负责人和其他相关的负责人来讨论和审计。

CMMI-配置管理计划

CMMI-配置管理计划

EPG过程改进项目_x001D_ 配置管理计划广东×××技术股份有限公司修订历史记录目录1人员及职责 (4)2软件硬件资源 (4)3配置项计划 (4)4基线计划 (5)5配置库备份计划 (5)6版本控制规则 (5)7变更控制规则 (6)1人员及职责2软件硬件资源3配置项计划4基线计划5配置库备份计划6版本控制规则文档版本号规则文档版本和配置管理中的版本概念不同,它指的是文档的发布版本。

1、处于“草稿”状态(开发库)的文档的版本号格式定义为:0.YZ.➢YZ数字范围可以为01~99。

➢随着草稿的不断完善, “YZ”的取值应不断递增。

2、处于“正式发布”状态(基线库)的文档的版本号格式定义为:X.Y。

➢X为主版本号,取值范围为1~9。

Y为次版本号,取值范围为1~9。

➢如果文档第一次“正式发布”时,版本号为1.0。

➢如果文档的版本升级幅度比较小,一般只增大Y值,X值保持不变。

只有当文档版本升级幅度比较大时,才允许增大X值。

3、处于“正在修改”状态(开发库)的文档的版本号格式定义为:X.YZ。

➢文档正在修改时,一般只增大Z值,X.Y值保持不变。

➢当文档修改完毕,状态重新成为“正式发布”时,将Z值设置为0,增加X.Y值。

注:产品发布后要注意产品发布版本号与VSS版本号的对应关系7变更控制规则基线了的配置项需要修改的时候按照《配置变更控制规程》执行。

具体操作如下:配置管理员向CCB提交变更申请(变更申请表合并在《项目、产品变更表》中,由项目经理一起提交给CCB)。

如果CCB同意变更,CMO给项目组足够的权限修改同意变更的配置项,CCB 督促变更任务的执行,项目组修改完成后,CMO审核变更后的配置项,审核通过后发布变更的配置项;如果不同意变更,终止变更。

无论配置项变更是否同意,最终由CMO保存变更申请单。

对于那些在“变更控制和管理流程”中确定的小型变更则不必执行此配置变更规程,只需项目组口头向CMO申请变更,项目组修改后由CMO审核通过即可,并通知项目组。

  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

项目编号:xxxxxx 项目名称:数字签名
配置管理计划
修订历史记录
配置管理计划
1.简介
1.1目的
在数字签名项目的生命周期内,为了保证该项目工作产品、过程记录及项目相关资料的版本统一和完整,特制定本计划。

1.2范围
纳入数字签名项目配置管理的配置项、过程记录及其它相关资料。

1.3定义、首字母缩写词和缩略语
本小节应提供正确理解此配置管理计划所需的全部术语、首字母缩写词和缩略语的定义。

?这些信息可以通过引用项目词汇表来提供。

1.3.1CM (Configuration Management)
配置管理。

1.3.2配置项(Configuration item)
指定为配置管理的对象且作为单个实体进行处理的硬件、软件或两者的集合。

1.3.3基线(baseline)
一种通过正式评审和认可的规范说明或产品,此后将其作为进一步开发的基础,只有通过正式的变更控制过程才可以变更。

1.3.4基线库(Software baseline library)
项目软件生命周期中基线的集合。

用VSS软件工具管理时,基线库可以是一个独立的VSS系统,也可以是VSS系统中的一个目录。

1.3.5配置审计(Configuration audit)
审核配置管理库系统的结构和设施,验证软件基线库内容的完备性和正确性,验证与适用的配置管理标准和规程的符合性
1.3.6配置控制委员会(CCB)
有权力管理项目基线的委员会,它代表项目经理和所有可能受到项目基线更改影响的组的利益,
由它审定项目基线的建立和配置项/单元的标识,评审和审定对项目基线的更改,审定对项目基线库制造的产品的生成。

1.3.7QA (Quality Assurance)
质量保证。

1.4参考资料
1.5概述
本计划主要针对数字签名项目从立项到结项的过程中的配置管理活动进行了规划、估计,并对配置管理具体环境作了详细说明。

2.软件配置管理
2.1组织、职责和接口
2.1.1项目配置管理员
人员:李晓娅。

职责:负责制定项目配置管理计划;
按照计划实施项目配置管理活动;
将配置状态报告及时提交给相关人员。

2.1.2CCB
人员:郭红宇、李强、罗会梅、谢婷、李晓娅。

负责人: 郭红宇
职责:在配置管理员提交配置项后,CCB检查并批准/不批准配置项。

检查和批准项目基线。

在得到变更请求的影响分析后,CCB检查和批准/不批准该变更请求。

变更审定配置项的基线建立。

定期举行工作会议。

2.1.3项目经理
人员:李强。

职责:负责审批项目配置管理计划,支持项目配置管理人员工作。

2.1.4QA
人员:谢婷。

职责:负责检查项目配置管理过程执行的有效性。

2.1.5采购人员
人员:罗会梅。

职责:负责外购产品的采购。

2.2工具、环境和基础设施
2.2.1项目的环境、工具
SVN服务器地址:
SVN路径:
目录结构:
2.2.3相关环境及工具提交计划
3.配置管理活动3.1配置标识
3.1.1标识方法
3.2配置项变更控制
3.2.1变更请求的处理和审批
由变更发起人填写《配置项变更申请表》,项目经理填写审批意见,在该表格中明确变更的原因、变更项、变更开始和完成时间等信息。

变更请求的审批由CCB来组织。

3.2.2变更控制委员会 (CCB)
CCB组织相关评审人员对变更申请进行审查,分析所申请变更对其它配置项的影响,填写评审意见。

通过评审的变更申请由CCB批准。

3.3配置管理活动计划
3.3.1项目介质存储和发布进程
保留策略: 数字签名项目活动中所产生的所有数据保留至项目完成之日,然后根据公司的相关规定进行移交,由公司统一保留。

备份计划: 由项目配置管理人员每天对项目配置库进行备份。

事故处理计划: 在数字签名项目实施过程中,如有项目计划中所列风险或者其他事故发生,项目配置管理员应配合项目经理对其进行妥善处理。

如果在项目配置管理活动中出现事故,应按照公司文件的相关规定进行处理。

恢复计划: 由项目配置管理人员提供日常备份的项目工作产品及相关资料,对项目配置管理库进行恢复。

介质保留方式: 采用联机网络拷贝备份。

介质类型格式: 服务器硬盘。

发布过程: 遵照公司以下规定的流程对数字签名项目产生的基线和工作产品进行发布。

项目经理和项目配置管理员一起列出将发布的产品清单、产品发布号和相关资料,并
向CCB提出发布申请(参见《基线发布申请检查表》或《产品发布申请检查表》)。

基线或产品发布,CCB组织公司有关人员对产品进行全面的审核,并在《基线/产品发
布申请检查表》填写意见。

产品发布,QA人员评审发布活动,并在《产品发布申请检
查表》中填写意见。

CCB批准基线或产品发布。

项目配置管理员保存《基线发布申请
检查表》或产品发布申请检查表》,发布项目基线或项目产品,并将发布消息通知给
所有相关人员。

3.3.2配置项纳入计划
3.4报告和审计
3.4.1配置管理状态报告提交计划
4.培训和资源
4.1培训所需环境
笔记本一台;投影仪一台;公司网络环境。

4.2培训参加人员
项目组全体成员。

4.3培训具体安排
5.分包商和厂商软件控制。

相关文档
最新文档