临淄哪里做网站,公司网络安全管理制度和应急工作预案,模特公司网站源码,北京关键词优化报价目录 一、配置管理概述
1.1 定义
1.2 国标#xff08;GB/T11457-2006#xff09;规定内容
二、配置管理过程
2.1 编制软件配置管理计划
2.1.1 概述
2.1.2 配置管理计划内容
2.1.2.1 引言
2.1.2.2 引用文件
2.1.2.3 管理
2.1.2.4 SCM 活动
2.1.2.5 工具、技术和方法…目录 一、配置管理概述
1.1 定义
1.2 国标GB/T11457-2006规定内容
二、配置管理过程
2.1 编制软件配置管理计划
2.1.1 概述
2.1.2 配置管理计划内容
2.1.2.1 引言
2.1.2.2 引用文件
2.1.2.3 管理
2.1.2.4 SCM 活动
2.1.2.5 工具、技术和方法
2.1.2.6 对供货单位的控制
2.1.2.7 记录的收集、维护和保存
2.1.2.8 配置项和基线
2.1.2.9 备份
2.1.2.10 日程表
2.1.2.11 注解
2.1.2.12 附录
2.2 配置标识
2.2.1 概述
2.2.2 确定配置项
2.2.2.1 识别配置项
2.2.2.2 配置项命名
2.2.2.3 配置项的描述
2.2.3 基线
2.2.3.1 功能基线
2.2.3.2 指派基线(分配基线)
2.2.3.3 产品基线
2.2.4 建立配置管理系统
2.2.5 配置库
2.2.5.1 开发库
2.2.5.2 受控库
2.2.5.3 产品库
2.3 变更管理
2.3.1 概述
2.3.2 变更控制
2.3.2.1 定义
2.3.2.2 项目变更原因
2.3.2.3 变更控制系统
2.3.2.4 变更控制委员会
2.3.2.5 变更控制的流程
2.3.2.5.1 变更基本流程
2.3.2.5.2 变更申请内容
2.3.2.6 利用配置库实现变更控制
2.4 配置控制
2.4.1 版本控制
2.4.1.1 概述
2.4.1.2 版本控制流程
2.5 配置状态说明
2.5.1 定义
2.5.2 状态报告
2.5.2.1 状态报告信息流图
2.5.2.2 状态报告内容
2.6 配置审核
2.6.1 概述
2.6.2 配置审核的作用
2.6.3 配置审核的时机和步骤
2.6.4 配置审核与正式技术评审 一、配置管理概述
1.1 定义
软件配置管理(SoftwareConfigurationManagementSCM)是指通过执行版本控制、变更控制的规程以及使用合适的配置管理工具来保证所有配置项的完整性和可跟踪性。
配置是在技术文档中明确说明并最终组成软件产品的功能或物理属性包括即将受控的所有产品特性其内容及相关文档、软件版本、变更文档、软件运行的支持数据以及其他一切保证软件一致性的组成要素。
配置管理是对工作成果的一种有效保护。
1.2 国标GB/T11457-2006规定内容
根据国家标准《软件工程术语》(GB/T11457-2006)配置管理是标识和确定系统中配置项的过程在系统整个生存期内控制这些配置项的投放和更动记录并报告配置的状态和变动要求验证配置项的完整性和正确性。并对下列工作进行技术和行动指导与监督的一套规范:
对配置项的功能特性和物理特性进行标识和文件编制工作。控制这些特性的变动情况。记录并报告这些变动进行的处理和实现的状态。
配置管理的目的在于运用配置标识、配置控制、配置状态和配置审计建立和维护工作产品的完整性。
CMMI把配置管理分为九大部分分别是制订配置管理计划、识别配置项、建立配置管理系统、创建或发行基线、跟踪变更、控制变更、建立配置管理记录、执行配置审核、版本控制。
而国家标准《信息技术 软件生存周期过程》(GB/T8566-2007)所规定的软件配置管理过程的活动有过程实施(编制配置管理计划)、配置标识、配置控制、配置状态报告、配置评价、发行管理和交付。
二、配置管理过程
2.1 编制软件配置管理计划
2.1.1 概述
在项目启动时项目经理首先要制订整个项目的开发计划它是整个软件开发工作的基础。配置管理计划是项目开发计划的一部分。
2.1.2 配置管理计划内容
根据 GB/T 8567-2006的规定配置管理计划应该包括以下几个部分的内容:
2.1.2.1 引言
包括配置管理计划的标识、系统概述、文档概述、组织和职责、配置管理活动所需的各种资源等。
2.1.2.2 引用文件
列出配置管理计划中引用的所有文档的编号、标题、修订版本和日期还应标识不能通过正常的供货渠道获得的所有文档的来源。
2.1.2.3 管理
描述在各阶段中负责SCM 的机构和任务以及要进行的评审和检查工作指出各阶段的产品应存放在哪一类配置库中指出各机构的职责和它们之间的关系描述相关的接口控制规定实现 SCM 计划的主要里程碑指明 SCM 适用的标准和规范以及这些标准和规范要实现的程度。
2.1.2.4 SCM 活动
描述配置标识、配置控制、配置状态记录与报告、配置检查与评审等4个方面的 SCM 活动。
2.1.2.5 工具、技术和方法
指明为支持特定项目的SCM 所使用的软件工具、技术和方法以及它们的目的并在开发人员所有权的范围内描述其用法。
2.1.2.6 对供货单位的控制
规定对供货单位进行控制的规程从而使从软件销售单位购买的、其他开发单位开发的或从开发单位现存软件库中选用的软件能满足规定的SCM需求。
2.1.2.7 记录的收集、维护和保存
规定要保存的 SCM 文档以及用于汇总、保护和维护工程文档的方法和设施(其中包括要使用的后备设施)并说明要保存的期限。
2.1.2.8 配置项和基线
根据企业的有关规范对不同类型的配置项建立命名规则列出识别到的所有配置项和所属的配置基线并明确配置项的标识、作者(或负责人)和配置时间。描述配置项和基线变更、发布的流程以及相应的批准权限。
2.1.2.9 备份
说明配置库和配置管理库的备份方式、频率和责任人。
2.1.2.10 日程表
列出SCM活动的日程表并确保配置管理活动的日程表与项目开发计划、质量管理计划保持一致。
2.1.2.11 注解
包含有助于理解配置管理计划的一般信息例如背景信息、词汇表、原理等。这一部分应包含为理解配置管理计划需要的术语和定义所有缩略词和它们在配置管理计划中的含义的字母序列表。
2.1.2.12 附录
提供那些为便于维护配置管理计划而单独编排的信息(例如图表、分类数据等)。为便于处理附录可以单独装订成册按字母顺序编排
2.2 配置标识
2.2.1 概述
确定哪些内容应该进入配置管理形成配置项并确定配置项如何命名用哪些信息来描述配置项。配置标识是配置管理的基础性工作是进行配置管理的前提。
软件开发中的文档和软件在其开发、运行、维护的过程中会得到许多阶段性的成果在开发和运行过程中还需要用到多种工具软件或配置。所有这些信息项都需要得到妥善的管理决不能出现混乱以便在提出某些特定的要求时将它们进行约定的组合来满足使用的目的。这些信息项是配置管理的对象称为配置项。
每个配置项的主要属性有名称、标识符、状态、版本、作者、日期等。配置项是一个独立存在的信息项可以把它看成一个元素单独的一个元素发挥不了什么作用但随着工作的进展出于不同的要求需要将这些元素进行不同的组合这个组合称为配置。配置是一个信息系统产品在生存期各个阶段的不同形式(记录特定信息的不同媒体)和不同版本的程序、文档及相关数据的集合或者说是配置项的集合它具有完整的意义。
2.2.2 确定配置项
软件项目中形成的技术性文档和管理性文档除一些临时性的文档外一般都应该进行配置管理。一般来讲判定一个文档是否进行配置管理的标准应该是此文档是否有多个人需要使用这些文档往往在开发的过程中不断地修正和扩展要保证每个使用者都使用同一版本的文档就必须将这些文档纳入配置管理成为受控的配置项。
2.2.2.1 识别配置项
可能成为配置项组成部分的主要工作产品有过程描述、需求、设计、测试计划和规程、测试结果、代码/模块、工具、接口描述等。在软件工程方面RogerS.Pressman 认为至少以下所列的文档应该成为配置项:系统规格说明书、项目计划、需求规格说明书、用户手册、设计规格说明、源代码、测试规格说明、操作和安装手册、可执行程序、数据库描述、联机用户手册、维护文档、软件工程标准和规程。
2.2.2.2 配置项命名
确定了配置项后还需要对配置项进行合理、科学的命名。配置项的命名绝不能随意为之必须满足唯一性和可追溯性。一个典型的实例是采用层次式的命名规则来反映树状结构树状结构上节点之间存在着层次的继承关系。
2.2.2.3 配置项的描述
由于配置项除了名称外还有一些其他属性和与其他配置项的关系因此它可以采用描述对象的方式来进行描述。每个配置项用一组特征信息(名字描述、一组资源、实现)唯一地标识。配置项间的关系有整体和部分的关系及层次关系也有关联关系。配置项间的关系可以用MIL(Module Interconnection Language模块内连接语言)表示MI,描述的是配置项间的相互依赖关系可自动构造系统的任何版本。
2.2.3 基线
基线(baseline)是项目生存期各开发阶段末尾的特定点也称为里程碑(milestone)在这些特定点上阶段工作已结束并且已经形成了正式的(通过了正式的技术评审)阶段产品。
建立基线的概念是为了把各开发阶段的工作划分得更加明确使得本来连续开展的开发工作在这些点上被分割开从而更加有利于检验和肯定阶段工作的成果同时有利于进行变更控制。有了基线的规定就可以禁止跨越里程碑去修改另一开发阶段的工作成果并且认为建立了里程碑有些完成的阶段成果已被冻结。
如果把软件看做是系统的一个组成部分以下3种基线是最受人们关注的分别是功能基线、分配基线和产品基线。
2.2.3.1 功能基线
指在系统分析与软件定义阶段结束时经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明;或是指经过项目业主和承建单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标志。
2.2.3.2 指派基线(分配基线)
指在软件需求分析阶段结束时经过正式评审和批准的 SRS。指派基线是最初批准的指派配置标志。
2.2.3.3 产品基线
指在软件组装与系统测试阶段结束时经过正式评审和批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志。另外交付给项目组所在企业的外部客户的基线一般称为发行基线企业内部使用的基线称为构造基线。释放(release)是指在软件生存周期的各个阶段结束时由该阶段向下阶段提交该阶段产品的过程。它也指将系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也称为交付(delivery)。提出基线的概念本来是为了更好地实现变更控制但如果把每个基线都当成一个整体来看待会造成麻烦。因为一个变更很可能只涉及到基线的很小部分。例如假定某个大型软件中的一个模块修改了如果将这一变更当做整个软件产品基线的变更就很不方便。
2.2.4 建立配置管理系统
在配置管理中要建立并维护配置管理系统和变更管理系统。建立配置管理系统的主要步骤如下
建立适用于多控制等级配置管理的管理机制。软件生存周期中不同时间所需的控制等级不同不同的系统类型所需的控制等级也不同。存储和检索配置项。共享和转换配置项。存储和复原配置项的归档版本。存储、更新和检索配置管理记录。创建配置管理报告。保护配置管理系统的内容。配置管理系统的主要功能有文档的备份与恢复、文档的建档、从配置管理的差错状态下复原。权限分配。配置管理员为每个项目成员分配对配置库的操作权限。配置管理员的权限最高一般项目成员可拥有添加、检入/检出(checkin/checkout)、下载的权限但是不能有删除的权限。
2.2.5 配置库
配置库也称为配置项库是用来存放配置项的工具。
配置库记录与配置相关的所有信息其中存放受控的配置项是很重要的内容利用配置库中的信息可评价变更的后果这对变更控制有着重要的意义。
配置库有三类:
2.2.5.1 开发库
存放开发过程中需要保密的各种信息供开发人员个人专用。开发库中的信息可能有较为频繁的修改只要使用者认为有必要无需对其做任何限制。因为这通常不会影响到项目的其他部分。开发库对应配置管理系统中的动态系统(开发者系统、开发系统、工作空间)。
2.2.5.2 受控库
在开发的某个阶段工作结束时将工作产品存入或将有关的信息存入。存入的信息包括计算机可读的和人工可读的文档资料。应该对受控库内的信息的读写和修改加以控制。受控库也称为主库对应配置管理系统中的主系统(受控系统)。
2.2.5.3 产品库
在开发的产品完成系统测试之后作为最终产品存入产品库内等待交付用户或现场安装。产品库内的信息也应加以控制。产品库也称为备份库对应配置管理系统中的静态系统。
2.3 变更管理
2.3.1 概述
配置管理最重要的任务就是对(配置项的)变更加以控制和管理其目的是对于复杂而无形的软件防止在多次变更下失控出现混乱。
2.3.2 变更控制
2.3.2.1 定义
变更是指在项目的实施过程中由于项目环境或者其他的各种原因对项目的部分或项目的全部功能、性能、体系结构、技术、指标、集成方法和项目进度等方面做出改变。项目变更是正常的、不可避免的。
2.3.2.2 项目变更原因
在项目实施过程中变更越早损失越小变更越迟难度越大损失也越大。项目在失控的情况下任何微小变化的积累最终都会对项目的质量、成本和进度产生较大影响这是一个从量变到质变的过程。
变更产生的原因主要有以下几个方面
项目外部环境发生变化例如政府政策的变化等。 项目总体设计、需求分析不够周密详细有一定的错误或遗漏新技术的出现设计人员提出了新的设计方案或新的实现手段。建设单位由于机构重组等原因造成业务流程的变化。
2.3.2.3 变更控制系统
变更控制系统是一套事先确定的修改项目文件或改变项目活动时应遵循的程序其中包括必要的表格或其他书面文件、责任追踪以及变更审批制度、人员和权限。变更控制系统应当明确规定变更控制委员会的责任和权力并由所有的项目干系人认可。在审批变更时要加强对变更风险和变更效果的评估并选择对项目影响最小的变更方案尽量防止增加项目投资。变更控制系统可细分为整体、范围、进度、费用和合同变更控制系统。变更控制系统应当与项目管理信息系统一起通盘考虑形成整体。
2.3.2.4 变更控制委员会
变更控制委员会(Change ControlBoard,CCB)也称为配置控制委员会(ConfigurationControl Board)其任务是对建议的配置项变更做出评价、审批以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构可以根据工作的需要组成其中的人员可以全职的也可以是兼职的。
如果CCB 不只是控制变更而是承担更多的配置管理任务那就应该包括基线的审定、标识的审定以及产品的审定等工作并且可能实际的工作需分为项目层、系统层和组织层来组建使其完成不同层面的配置管理任务。
2.3.2.5 变更控制的流程
2.3.2.5.1 变更基本流程
一般来说变更控制应该遵循以下的基本流程:
变更申请。应记录变更的提出人、日期、申请变更的内容等信息。变更评估。对变更的影响范围、严重程度、经济和技术可行性进行系统分析变更决策。由CCB 决定是否实施变更。变更实施。由管理者指定的工作人员在受控状态下实施变更变更验证。由配置管理人员或受到变更影响的人对变更结果进行评价确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。沟通存档。将变更后的内容通知可能会受到影响的人员并将变更记录汇总归档。如提出的变更在决策时被否决其初始记录也应予以保存。
2.3.2.5.2 变更申请内容
变更申请需要采用书面的形式提出主要内容有如下3个方面
变更描述。包括变更理由、变更的影响、变更的优先级等就是要描述做什么变更为什么要做以及打算怎么做的问题。对变更的审批。对变更的必要性、可行性的审批意见主要是由配置管理员和CCB对此项变更把关。变更实施的信息。
在变更请求批准后实施变更需要一段时间要设置一种管理手段来反映变更所处的状态这就是变更状态说明它可供项目经理和CCB追踪变更的情况。状态说明的信息可以通过变更请求和故障报告得到变更状态可分为三种:活动(正在实施变更)完成状态(已完成变更)和未列入变更状态。
2.3.2.6 利用配置库实现变更控制
配置项可以有三种状态工作状态、评审状态和受控状态。
开发中的配置项尚未稳定下来对于其他配置项来说是处于工作状态下(自由状态、草稿状态)此时它并未受到配置管理的控制开发人员的变更并未受到限制。
但当开发人员认为工作已告完成可供其他配置项使用时它就开始于稳定。把它交出评审就开始进入评审状态若通过评审可作为基线进入配置库开始冻结此时开发人员不允许对其任意修改因为它已处于受控状态。
通过评审表明它确已达到质量要求但若未能通过评审则将其回归到工作状态重新进行调整。配置项的状态变化过程如下图所示 处于受控状态下的配置项原则上不允许修改但这不是绝对的如果由于多种原因需要变更就需要提出变更请求。在变更请求得到批准的情况下允许配置项从库中检出待变更完成并经评审后确认变更无误方可重新入库使其恢复到受控状态。
2.4 配置控制
2.4.1 版本控制
2.4.1.1 概述
在配置管理中所有的配置项都应列入版本控制的范畴。对于软件产品的版本有两个方面的意思一是为满足不同用户的不同使用要求如用于不同运行环境的系列产品。
如适合 Linux、Windows、Solaris用户的软件产品分别称为 Linux 版、Windows 版和 Solaris版。它们在功能和性能上是相当的原则上没有差别或者说这些是并列的系列产品。对于这类差别很小的不同版本互相也称为变体(variant)。
另一种版本的含义是在软件产品投入使用后经过一系列的变更(例如纠错、增加功能、提高性能的更改等)而形成的一系列的顺序演化的产品这些产品也称为一个版本每个版本都可说出它是从哪个版本导出的演化过程。
必须注意到修正后的新版本往往不能完全代替老版本尽管新版本有某些优越的特性。因为一些用户仍然使用着老版本并且不容易立刻做到“以旧换新”否则可能会打扰老版本原有的工作环境。显然多个版本被多个用户同时使用的情况是不可避免的现实。这就要求多个版本共存这也就是配置管理要解决的一个重要课题。
2.4.1.2 版本控制流程
一般来说版本控制的流程如下
创建配置项。修改处于工作状态的配置项。技术评审或领导审批。正式发布。变更修改版本号。
版本管理要解决的第一个问题是版本标识也就是为区分不同的版本要给它们科学的命名。通常有2种版本命名的方法分别是号码版本标识和符号版本标识。其中号码版本标识以数字表示如用 1.02.01.22.1.1等表示版本号符号版本标识是将重要的版本属性有选择地给出例如SOLServer2008、Jbuilder2005 等将版本产生的时间给出。为了从版本标识上看到更多信息可能给出更多的属性例如面向的客户群、开发语言、硬件平台、生成日期等。
在配置管理中版本包括配置项的版本和配置的版本这两种版本的标识应该各有特点配置项的版本应该体现出其版本的继承关系它主要是在开发人员内部进行区分。另外还需要对重要的版本做一些标记例如对纳入基线的配置项版本应该做一个标识。
2.5 配置状态说明
2.5.1 定义
配置状态说明也称为配置状态报告其任务是有效地记录、报告管理配置所需要的信息目的是及时、准确地给出配置项的当前状况供相关人员了解以加强配置管理工作。
2.5.2 状态报告
为了清楚、及时地记载配置的变化不至于到后期造成贻误需要对开发的过程作出系统的记录以反映开发活动的历史情况这就是配置状态记录。该项活动主要是完成配置状态报告的编制工作。
2.5.2.1 状态报告信息流图
在配置状态报告中需要对每一项变更进行详细的记录包括发生了什么?为什么会发生?谁做的?什么时候发生的?会有什么影响?整个配置状态报告的信息流如下图所示 正如上图所示每次新分配一个配置项或者更新一个已有配置项或配置项标识或者一项变更申请被变更控制负责人批准并给出了一个工程变更顺序时在配置状态报告中就要增加一条变更记录条目一旦进行了配置审核其结果也应该写入报告中。配置状态报告可以放在一个联机数据库中以便开发人员或者维护人员可以对它进行查询或修改。此外在配置状态报告中新记录的变更应当及时通知给管理人员和其他项目干系人。
2.5.2.2 状态报告内容
配置状态报告对于大型开发项目的成功起着至关重要的作用。它提高了所有开发人员之间的通信能力避免了可能出现的不一致和冲突。它通过支持创建和修改记录、管理报告配置项的状态或需求变化并审核变化来实现它提供用户需要的功能跟踪任意模式的软件项提供完整的各种变化的历史版本和汇总信息。配置状态报告的内容一般包括以下各项
各变更请求概要:变更请求号、日期、申请人、状态、估计工作量、实际工作量、发行版本、变更结束日期基线库状态。发行信息。备份信息。配置管理工具状态。配置管理培训状态
2.6 配置审核
2.6.1 概述
配置审核的任务是验证配置项对配置标识的一致性。软件开发的实践表明尽管对配置项做了标识实现了变更控制和版本控制但如果不做检查或验证仍然会出现混乱。配置审核的实施是为了确保软件配置管理的有效性体现配置管理的最根本要求不允许出现任何混乱现象。
2.6.2 配置审核的作用
配置审核的任务是验证配置项对配置标识的一致性。软件开发的实践表明尽管对配置项做了标识实践了变更控制和版本控制但如果不做检查或验证仍然会出现混乱。这种验证包括
对配置项的处理是否有背离初始的规格说明或已批准的变更请求的现象。配置标识的准则是否得到了遵循。变更控制规程是否已遵循变更记录是否可供使用。在规格说明、软件产品和变更请求之间是否保持了可追溯性。
配置审核工作主要集中在两个方面一是功能配置审核即验证配置项的实际功效与软件需求是否一致二是物理配置审核即确定配置项符合预期的物理特性。这里所说的物理特性是指定的媒体形式。
2.6.3 配置审核的时机和步骤
配置审核要选择适当的时机由项目经理决定何时进行配置审核工作。一般来说应该选择以下几种情况实施配置审核 产品交付或是产品正式发行前。开发的阶段工作结束之后。在维护工作中定期地进行。
实施配置审核的审核人员可以包括项目组人员及非项目组人员例如其他项目的配置管理人员、企业的内部审核员等。配置审核的步骤如下
由项目经理决定何时进行配置审核工作质量保证组或项目组的配置管理组指定该项目的配置审核人员。项目经理和配置审核员决定审核范围。配置审核员准备配置审核检查单。配置审核员审核文档和记录审核活动可能涉及到项目范围、配置项的检入检出、评审记录、配置项的变更历史、测试记录、文件的命名、变更请求、版本的编号等。配置审核员在审核中发现不符合现象并作记录。由项目经理负责消除不符合现象。配置审核员验证所有发现的不符合现象确保已得到解决。
2.6.4 配置审核与正式技术评审
配置审核的目的就是要证实整个项目生存期中各项产品在技术上和管理上的完整性。同时还要确保所有文档的内容变动不超出当初确定的软件需求范围。使得配置具有良好的可跟踪性。这是项目变更控制人员掌握配置情况、进行审批的依据除了进行配置审核外还可以进行正式技术评审。
正式的技术评审着重检查已完成修改的配置项的技术正确性评审者评价配置项决定它与其他配置项的一致性是否有遗漏或可能引起的副作用。正式技术评审应针对所有的变更进行。
配置审核作为正式技术评审的补充评价在评审期间通常没有被考虑的配置项的特性。在某些情形下配置审核的问题是作为正式技术评审的一部分提出的。但是当配置管理成为一项正式活动时配置审核就被分开而由质量保证小组执行了。 好了本次内容就分享到这欢迎大家关注《项目管理》专栏后续会继续输出相关内容文章。如果有帮助到大家欢迎大家点赞关注收藏有疑问也欢迎大家评论留言
