软件项目-软件配置管理规范-模板

合集下载

20 软件配置管理报告(模板)-GJB438C

20 软件配置管理报告(模板)-GJB438C

XX产品软件配置管理报告XXXX-PZBG共9页XXXX公司20XX年XX月密级:内部阶段:版次: AXX产品软件配置管理报告XXXX-PZBG编制审核批准修改页本文件版本情况如下:目录1 范围 (1)1.1 标识 (1)1.2 系统概述 (1)1.3 文档概述 (1)2 引用文档 (1)3 软件配置管理情况综述 (1)4 软件配置管理基本信息 (2)5 专业组划分及权限分配 (2)6 配置项记录 (2)7 变更记录 (3)8 基线记录 (3)9 入库记录 (3)10 出库记录 (4)11 审核记录 (4)12 备份记录 (4)13 测量 (5)14 注释 (5)1 范围1.1 标识本文档适用于产品型号+产品名称,模块的软件包括:XX软件。

1.2 系统概述信号处理模块是为XX单位配套的产品,主要用于实现空间谱估计运算。

根据《产品型号+产品名称技术协议》和《设计和开发任务书》的要求,信号处理模块软件包括如下几个软件:a)XX软件:XX功能;b)XX软件:XX功能。

XX软件的研制过程与产品研制周期保持同步,随产品交付用户。

项目的需求方:XX。

项目的开发方:XXXX。

项目保障机构:XX软件由XX负责开发,XX负责软件测试,XX负责软件质量保证,XX负责软件的配置管理,并全程监控软件研制的全过程。

1.3 文档概述本文档规定了产品型号+产品名称软件开发过程中必要的质量保证措施,以保证交付的XX软件能够满足规定的各项需求。

本文档作为XX软件研制过程的规范文件,对本文档的使用应遵循与此相应的相关保密性和安全性规定。

2 引用文档下列标准和文件中的有关条款,通过引用而成为本计划的条款。

对于注明日期或版次的引用文件,其后的任何修改(不包括勘误的内容)或修订版本都不适用于本计划,但提倡使用本计划的各方,探讨使用其最新版本的可能性。

对于未注日期或版次的引用文件,其最新版本适用于本计划。

GJB 438B-2009 军用软件开发文档通用要求3 软件配置管理情况综述XX软件的配置管理工作以《产品型号+产品名称软件配置管理计划》为依据,并按配置管理计划的要求开展了软件开发过程配置管理活动,软件配置标识、配置控制、配置状态记实、配置审核等与计划要求相符。

软件配置管理规范

软件配置管理规范

软件配置规范有限公司目录目录 (2)1.引言 (3)1.1.目的 (3)1.2.定义和缩略词 (3)1.2.1.定义 (3)1.2.2.缩略语 (3)2.管理 (4)2.1.任务 (4)2.2.职责 (5)2.3.适用的标准、条例和约定 (5)3.软件配置管理活动 (6)3.1.配置控制 (6)3.2.配置状态的记录和报告 (6)3.3.变更控制 (7)3.4.配置的检查和评审 (7)4.工具、技术和方法 (7)5.记录的收集、维护和保存 (7)6.附录:配置管理报表及其格式 (8)6.1.配置(变更)状态报告模板 (10)6.2.配置变更申请单模板 (11)6.3.基线发布报告 (12)6.4.基线审计报告 (13)1.引言1.1. 目的在对同一个项目中所产生大量的相关联的工作产品进行有效的控制,确保生产的工作、产品、组合不会由于同时更新、变更、多个版本而发生冲突。

来保证整个软件生命周期中建立和维护软件项目中所产生的各个产品的完整性和可追溯性。

1.2. 定义和缩略词1.2.1.定义1.2.2.缩略语2.管理软件配置管理流程2.1. 任务配置控制委员会(SCCB)担任着整个软件生存周期的评审和检查工作,并将各个阶段的产品放入对应的配置库中。

2.2. 职责A.SCCB负责人(PM项目经理)◆任命配置管理员(SCM)◆所有目录SCCB负责人有更改和书写权限。

B.配置管理员(SCM)◆所有目录SCM有更改和书写权限。

◆整个SVN由SCCB负责人指定SCM管理。

◆SCM 要维护所有目录和配置项的权限,保证配置下Reader能够获得到该文档,而其它人员无权获得。

C.软件工程师(SE)◆自己负责的程序模块有更改和书写权限。

◆对于正式发布的目录SE没有更改和书写的权限。

2.3. 适用的标准、条例和约定要标识的配置项主要包括以下几部分:◆开发环境:可以包括软件工具、硬件设备等;◆工具:可以包括测试工具、维护工具等;◆技术文档:软件需求、软件设计方案、软件测试方案、测试文档、用户手册、总结报告等;◆提交产品:计算机程序、释放产品等。

软件配置管理规范范本

软件配置管理规范范本

软件配置管理规范范本一、引言软件配置管理(Software Configuration Management,简称SCM)是软件工程中的重要环节,致力于有效管理和控制软件系统的构建、测试、发布和变更过程。

本文旨在提供一个软件配置管理规范范本,以帮助软件开发团队建立和执行一套合适的配置管理规则,确保软件项目的顺利进行。

二、配置管理范围1. 配置项范围- 软件源代码及可执行文件- 文档和用户手册- 测试用例和测试数据- 第三方库和组件- 配置文件和参数设置2. 配置管理活动范围- 版本控制:管理和跟踪软件所有配置项的版本变更和发布记录。

- 配置识别:将软件系统划分为不同的基线和模块,并进行唯一标识。

- 变更控制:确保任何软件变更都经过审批,并对变更进行记录和追踪。

- 配置审计:定期对软件配置进行审查,确保与规范一致。

- 配置状态管理:记录和跟踪软件配置的当前状态,包括开发、测试和生产。

- 工具支持:选择和使用适当的配置管理工具,提高效率和可追溯性。

三、配置管理规范1. 配置识别- 为每个配置项分配唯一的标识符,以便于跟踪和引用。

- 对软件系统进行模块化划分,每个模块应有清晰的功能和职责范围。

- 为每个配置项编写适当的描述和说明文档,包括用途、版本和所属模块等信息。

2. 版本控制- 使用版本控制工具对所有配置项进行管理,确保源代码、文档和其他资源都有清晰的版本历史。

- 维护一个主干(trunk)和分支(branch)的代码库,确保主干代码是稳定且可用的,分支用于并行开发和修复bug。

- 每个版本的发布都应有相应的发布说明,描述变更内容和风险评估。

3. 变更控制- 所有变更都必须通过变更管理流程进行审批和追踪,包括新功能添加、缺陷修复和配置项删除。

- 每个变更都要有详细的变更请求和变更记录,包括变更的原因、影响分析和验证计划等。

- 变更影响评估必须在变更实施之前进行,确保变更不会导致质量问题或功能冲突。

软件项目配置管理规范(配置项标识和配置审计的标准)

软件项目配置管理规范(配置项标识和配置审计的标准)

软件项目配置管理规范(配置项标识和配置审计的标准)1.概述本规范用于规范和指导全公司的配置管理活动,适用公司研发项目及技术支持阶段产品的开发工作,主要包括以下几个方面:建立和维护配置管理环境。

公司配置库权限管理配置库的备份和恢复。

公司配置管理相关规程及工具的培训。

制定和维护基线计划。

标识配置项。

变更控制和管理。

版本管理。

配置审计。

2.术语及定义配置管理(Configuration Management,CM):是一套应用技术上和管理上的指导和监督的方法,用来识别和记录配置项和功能特征和物理特征;控制这些特征的变更;记录和报告变更的处理和执行的状态;以及验证其是否符合特定的需求(IEEE-STD-610)。

配置项(Configuration Item,CI):配置管理中可相对独立地进行管理的单元,如文档和模块代码。

基线(Baseline):经过正式评审并且达成一致的一组工作产品,是进一步工作的稳定基础;基线化后的工作产品只能依据变更控制规程通过变更评估、审批后才能变更。

配置审计(Configuration Audit,CA):通过对配置库进行物理审计和功能审计来验证配置项信息与配置标识的一致性,确保软件资产备份的有效性和完整性。

配置库备份:配置库的备份包括全量备份和增量备份。

3.配置项标识编写《配置项识别表》时,配置管理工程师负责标识配置项范围,并由项目负责人确认。

项目组成员创立配置项时,根据配置项命名规则分配唯一的标识符,配置项命名根据以下原则。

文档类命名规则:公司级命名规则: [ 简称-] 文档名称 [-模块/主题简称]文档类命名原则:【局点+RM单号】-【项目名】-【文档名称】(如项目规模较大时,需分模块说明时,可增加模块简称的后缀)。

会议纪要等可增加主题简称、日期等后缀。

版本编号规则:v1.0.0.0(m.n.j.k) m 主版本号、n代表次版本号 j代表文档批准次数或者代码发布次数 k文档修改次数或者代码测试次数.配置项状态配置项状态通常有如下三种情况:草稿(draft);评审中(in review);已发布(released/passed)日常工作中经常将其剪裁为:草稿(draft);已发布(released)这两种状态,根据是否通过评审为判断节点。

软件配置管理计划模板

软件配置管理计划模板

XXXX软件项目配置管理计划XXXX企业有限公司____年___月___日文档信息修改记录目录软件项目配置管理计划 (2)1 引言 (2)1.1 编写目的 (2)1.2 术语定义 (2)1.3 参考资料 (2)2 计划内容 (2)2.1 人员及职责 (2)2.2 软硬件环境计划 (4)2.2.1 项目计划环境 (4)2.2.2 需求分析和设计环境 (4)2.2.3 开发环境 (4)2.2.4 测试环境 (4)2.2.5 配置管理环境 (4)2.3 配置项计划 (4)2.4 配置库计划 (6)2.5 权限计划 (7)2.6 基线计划 (8)2.7 发布计划 (8)2.8 配置库备份计划 (9)软件项目配置管理计划1 引言1.1 编写目的本文档目的在于对本公司项目进行软件配置管理,提高软件质量,降低软件开发成本。

本计划制定了本公司如何进行配置管理活动、活动的计划安排、指派的职责和所要求的资源。

对本公司项目实施软件配置管理活动时,需要参照本计划。

1.2 术语定义1、软件配置管理(SCM):软件配置管理是一门应用技术、管理和监督相结合的学科,通过标识和文档来记录配置项的功能和物理特性,控制这些特性的变更,记录和报告变更的过程和状态,并验证它们与需求是否一致。

2、配置项(CI):配置项可包括以下几方面:项目(或活动)文档、源代码、可执行代码、度量数据、变更请求(CR)。

项目(或活动)文档即项目(或活动)相关的规范、指南中定义的各个任务的输出和输入;源代码和可执行代码是特殊的文档;度量数据指度量分析定义表中定义的度量以及对应的实际数据。

3、基线(BaseLine): 用来标识一组配置项的特定版本的集合的标记,以记录工作成果的历史状态,或通过不同的版本组合定义不同特性的工作成果。

1.3 参考资料2 计划内容2.1 人员及职责1、根据《软件项目计划书》中的角色分配,确定CM,CCB(变更控制委员会)成员;2.2 软硬件环境计划2.2.1 项目计划环境软件:MS Office Word、MS Office Excel、MS Office Project2.2.2 需求分析和设计环境软件:MS Office Word、MS Office Visio、Sybase PowerDesigner、Rational Rose2.2.3 开发环境软件:Windows Visual Studio .Net、MyEclipse、JDK、Apache-Tomcat、Apache、Oracle 10g、SQL Server 2003、WebLogic、SQL Server 2005、Websphere2.2.4 测试环境软件:Load Runner2.2.5 配置管理环境1、软件:TortoiseSVN2.3 配置项计划配置管理员标识配置项,标识符的参考格式为:项目编号-配置项类型-配置项序号-配置项版本配置项名称。

软件配置模板

软件配置模板

目的(Purpose)为了建立和维护软件项目中所有产品的完整性,该文件描述了用于软件配置管理Software Configuration Management(SCM)的过程。

目标(Objective)通过有计划的软件配置管理活动,使软件工作产品经过标识、受到控制并具有可用性。

任何对软件工作产品的更改都是受控的,并确保相关小组和个人能及时了解软件基线的状态和内容。

范围(Scope)受控于配置管理下的工作产品,包括交付给客户的软件产品,以及生成软件产品所需要的或由软件产品标识的有关项。

准备/前提/条件(Input)软件配置控制委员会(SCCB):负责评价、认可或否定有关基线更改建议并确保确认的更改得以执行。

具体活动包括,授权标识与建立软件基线,阐述项目负责人和所有受软件基线变更影响的小组的权益。

高层SCCB包括BUM和高层经理。

项目SCCB包括项目经理和产品经理。

每个软件产品都有一个软件配置管理(SCM)小组负责协调和实施产品的软件配置活动。

SQA定期对SCM小组的活动进行监察与审核,以验证SCM小组的活动是否按照相应的规程进行。

规程/任务/活动(Procedure)制定SCM计划Making SCM Plan在项目的初期需要制定《SCM计划》SCM Plan.dot,并且始终与项目保持一致。

在项目计划(Project Plan.dot)的软件配置管理一章中,需要指明该项目对应的SCM计划文档。

项目经理或由项目经理指定的SCM小组成员制定SCM计划,并提交该项目的SCCB进行审批。

SCM计划的主要内容包括:确定该项目的SCM小组以及SCCB的成员名单。

需要管理的工作产品和项目使用工具,以及管理它们的目录结构设置。

项目的工作产品包括项目文档、源代码、源代码所生产出的EXE、OCX、DLL等所有生成文件。

目录结构设置可参考《SCM路径设置规程》(SCM Path Setup Procedure.doc)。

软件项目管理及配置管理

软件项目管理及配置管理
配置管理系统应该具备以下主要功能: 配置管理系统应该具备以下主要功能: 并行开发支持:因开发和维护的原因,要求能够实现开发人员同时在同一个软件模块上工作,同时对同一个代 码部分作不同的修改,即使是跨地域分布的开发团队也能互不干扰,协同工作,而又不失去控制; 修订版管理:跟踪每一个变更的创造者、时间和原因,从而加快问题和缺陷的确定 ; 版本控制:能够简单、明确地重现软件系统的任何一个历史版本 ; 产品发布管理:管理、计划软件的变更,与软件的发布计划、预先定制好的生命周期或相关的质量过程保持一 致;项目经理能够随时清晰地了解项目的状态 ; 建立管理:基于软件存储库的版本控制功能,实现建立(build)过程自动化 ; 过程控制:贯彻实施开发规范,包括访问权限控制、开发规则的实施等 ; 变更请求管理:跟踪、管理开发过程中出现的缺陷(Defect)、功能增强请求(RFE)或任务(Task),加强沟 通和协作,能够随时了解变更的状态 ; 18 代码共享:提供良好的存储和访问机制,开发人员可以共享各自的开发资源
一、软件项目管理
项目的定义: 项目的定义: 为完成某一独特的产品或服务所做的一 次性努力。 项目管理的定义: 项目管理的定义: 在项目活动中运用知识、技能、工具和 技术,以便达到项目的要求。 利用获得的信息来计划、协调并管理各 项承诺,通过实现时间、成本、质量和范围 内的目标,获得客户满意。
2
一、软件项目管理
提纲
一、项目管理 1、项目管理过程(五大过程、九大知识体系)。 2、软件项目开发的六个阶段。 3、项目管理过程中输出的文档。 4、主要输出文档的编写(需求文档、概要设计文档、详细设计 文档测试文档等)。 二、配置管理 1、配置管理的作用、功能、基本概念等。 2、配置管理的基本知识,三库(开发库、受控库、产品库)、 Version、Tag、Branch、 Conflict 、Merge等。 3、主流配置管理工具介绍

软件项目配置管理规范(配置项标识和配置审计的标准)

软件项目配置管理规范(配置项标识和配置审计的标准)

软件项目配置管理规范(配置项标识和配置审计的标准)1.概述本规范用于规范和指导全公司的配置管理活动,适用公司研发项目及技术支持阶段产品的开发工作,主要包括以下几个方面:建立和维护配置管理环境。

公司配置库权限管理配置库的备份和恢复。

公司配置管理相关规程及工具的培训。

制定和维护基线计划。

标识配置项。

变更控制和管理。

版本管理。

配置审计。

2.术语及定义配置管理(Configuration Management,CM):是一套应用技术上和管理上的指导和监督的方法,用来识别和记录配置项和功能特征和物理特征;控制这些特征的变更;记录和报告变更的处理和执行的状态;以及验证其是否符合特定的需求(IEEE-STD-610)。

配置项(Configuration Item,CI):配置管理中可相对独立地进行管理的单元,如文档和模块代码。

基线(Baseline):经过正式评审并且达成一致的一组工作产品,是进一步工作的稳定基础;基线化后的工作产品只能依据变更控制规程通过变更评估、审批后才能变更。

配置审计(Configuration Audit,CA):通过对配置库进行物理审计和功能审计来验证配置项信息与配置标识的一致性,确保软件资产备份的有效性和完整性。

配置库备份:配置库的备份包括全量备份和增量备份。

3.配置项标识编写《配置项识别表》时,配置管理工程师负责标识配置项范围,并由项目负责人确认。

项目组成员创立配置项时,根据配置项命名规则分配唯一的标识符,配置项命名根据以下原则。

文档类命名规则:公司级命名规则: [ 简称-] 文档名称 [-模块/主题简称]文档类命名原则:【局点+RM单号】-【项目名】-【文档名称】(如项目规模较大时,需分模块说明时,可增加模块简称的后缀)。

会议纪要等可增加主题简称、日期等后缀。

版本编号规则:v1.0.0.0(m.n.j.k) m 主版本号、n代表次版本号 j代表文档批准次数或者代码发布次数 k文档修改次数或者代码测试次数.配置项状态配置项状态通常有如下三种情况:草稿(draft);评审中(in review);已发布(released/passed)日常工作中经常将其剪裁为:草稿(draft);已发布(released)这两种状态,根据是否通过评审为判断节点。

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

软件配置管理规范
版本:V1.0
目录
1介绍 (1)
1.1目的 (1)
1.2范围 (1)
2规范概述 (1)
3规范详述 (1)
3.1配置库管理规范 (1)
3.1.1配置库说明: (1)
3.1.2配置库目录结构: (2)
3.1.3配置库权限设置: (4)
3.1.4配置库备份机制: (5)
3.2配置项管理规范: (5)
3.2.1配置项入库: (5)
3.2.2配置项标识: (5)
3.3基线管理规范: (8)
3.3.1基线说明: (8)
3.3.2基线分类: (8)
3.3.3基线命名规则 (9)
3.4其它项配置规则: (9)
3.4.1分支命名规则 (9)
3.4.2Eclipse工作空间命名 (9)
3.4.3版本标签命名规则 (9)
3.5过程简称表: (10)
3.6配置类别简称表: (10)
1 介绍
1.1 目的
本规范目的在于指导配置管理人员如何利用配置库管理所有配置项,从而加强对公司软件产品的控制,保持软件产品在其整个生命周期中的一致性、完整性、可追溯性。

1.2 范围
本规范适用于重要软件产品和软件项目的配置项管理。

对于非重要软件或已开发好的软件,可以采用本规范规定的要求的子集。

2 规范概述
本规范应用于软件配置管理过程,主要包括配置库的设置,配置项的标示,基线命名等。

3 规范详述
3.1 配置库管理规范
整个项目开发中,把所有的工作成果存放在四个库中,分别为:开发库、受控库、基线库、产品库,每个库下面对应的分为文档库和代码库两部分。

前三个库存放到配置管理工具数据库中,产品库建立在文件服务器\\192……\project目录中,根目录名称为项目编号。

配置管理员根据项目情况(项目规模、人员使用工具习惯等)、开发模式(本地开发、异地分布式开发)、财力等因素,确定配置管理工具软件(如:ClearCase、SVN、VSS等)以及计算机资源(内存、CPU、网络环境);确定存储库备份环境(备份服务器、备份介质)。

3.1.1 配置库说明:
开发库,包括整个开发过程中处于动态变化过程中的工作成果。

受控库,存放项目计划中定义的需要进行控制工作产品。

软件配置管理就是对软件受控库中的各软件项进行管理,因此软件受控库也叫做软件配置管理库。

基线库,存放项目过程的基线配置项。

产品库,主要存放项目中产生的工作产品,用于测试及其他人员的交互,由于程序文件都一次生成,不需要进行版本管理的,所以产品库存放在文件服务器上。

3.1.2 配置库目录结构:
开发(产品)目录结构的规划是软件配置管理的主要内容,由过程工程师、架构师配合配置经理来共同制定,并在配置管理工具的支持下予以实施。

3.1.2.1 Stream(流)的划分
3.1.2.2 VOB(版本对象库)
1.PVOB:
代码库:
文档库:
3.1.3 配置库权限设置:
开发库(开发流程)权限设置:
文档库权限设置:
3.1.4 配置库备份机制:
项目开发实施过程中,配置管理员应定期做好配置库,数据库的备份,以防劳动成果的丢失给整个项目及公司带来的严重损失。

1.配置库备份周期:配置库的备份采取每周进行一次。

2.配置库备份方案:先将数据备份到服务器本机XX目录下,同时利用ftp进行远程备份,将数据
备份到10.21.8.33的YY目录下,备份策略采取先删除前一天备份文件,然后备份当天数据。

3.2 配置项管理规范:
3.2.1 配置项入库:
对配置管理计划中选定的需要入库的配置项进行检查,当配置项被批准后,配置管理员将它提交到受控库中,其中部分配置项要受到基线控制,部分配置项要受到版本控制。

3.2.2 配置项标识:
为了识别产品的结构、产品的构件及其类型,为其分配唯一的标识符,也就是说,每一个配置项要有一个唯一标识。

3.2.2.1 Stream(流)
3.2.2.2 VOB
3.2.2.3 View(视图)
项目组成员创建视图时,只允许创建静态视图。

3.2.2.4 Componet(组件)划分
3.2.2.5 配置项标识规则:
3.2.2.6 配置项标识规则说明:
版本
否,非基线项
的工作产品
可以不包含
此参数
由两位组成,形式为
V0.0
初始版本为
V1.0
3.2.2.7 配置项标识举例:
文档类配置项:
软件类配置项:
3.3 基线管理规范:
3.3.1 基线说明:
基线是指经过正式评审和批准,可作为下一步工作基准的一个配置。

软件开发过程中,无论是需求分析、设计、测试都需要在完成时建立基线,也就是说基线是确保在给定的时间点记录并归档所有的已开发工作产品,以作为下一步工作的基础。

3.3.2 基线分类:
3.3.3 基线命名规则
基线命名规则:<产品名称>_<项目简称>_<基线简称>_<版本>_<日期>
参数说明:其中“版本”的初始值为V1.0,增量为1;“日期”的格式为“YYYYMMDD”
例如:QP_DEC_REQBL_V1.2_20080713
3.4 其它项配置规则:
非基线版本是指在项目的生命周期中,除基线版本外,还有必要标识的其它版本。

例如,项目组在完成某一阶段工作后、提交评审的版本,项目在测试阶段的版本都需要标识。

3.4.1 分支命名规则
分支命名约定是用小写字母来表示名称。

3.4.2 Eclipse工作空间命名
3.4.3 版本标签命名规则
1.普通Label:
<产品简称>_<项目简称>_<日期>_<时间>
例如:QP_DEC_20080715_1213
2.提交评审的Label:
<产品名称>_<项目简称>_<日期>_<时间>_<FORREVIEW>
例如:DP_DEC_20080712_1030_FORREVIEW
3.提交测试的Label:
<产品名称>_<项目简称>_<日期>_<时间>_<FORTEST>
例如:DP_DEC_20080716_0930_FORTEST
注:不要在同一元素版本树中多次使用同一版本标签。

3.5 过程简称表:
3.6 配置类别简称表:。

相关文档
最新文档