软件配置管理基本术语

软件配置管理(Configuration
Management)是指用于控制系统一系列变化的学科,通
过一系列技术、方法和手段来维护产品的历史、鉴别和定位产品独有的版本,并在产品的开
发和发布阶段控制变化,通过有序管理和减少重复性工作,保证生产的质量和效率。
不同于配置管理,软件配置管理以计算机为载体(不论工具和产品),不光维护产品的
状态,历史纪录,同样还支持存储、恢复和产品制造。软件配置管理是软件工程中涉及概念
较多的一项内容,为了便于说明,下面给出一些软件配置管理相关术语(主要是软件配置管
理计划规范GB/T
12505-90)的定义和说明。
(1) 项目委托单位(Project Entrust
Organization)
项目委托单位指为产品开发提供资金,通常也是(但有时也未必确定产品需求的单位或
个人。
(2)
项目承办单位(Project Undertaking
Organization)
项目承办单位指为项目委托单位开发、购置或选用软件产品的单位或个人。
(3) 软件开发单位(Software
Development Organization)
软件开发单位是指直接或间接受项目委托而直接负责开发软件的单位或个人。
(4)
用户(User)
用户指实际使用软件来完成某项计算、控制或数据处理等任务的单位或个人。
(5)
软件(Software)
软件指计算机程序及其有关的数据和文档,也包括固化了的程序。
IEEE
给出的定义为:计算机程序、方法、规则、相关的文档资料以及在计算机上运行
时所必须的数据。
由此可见,软件已不再只是一个程序和一本使用手册,而是包括大量的程序、文档和
数据。
(6)
软件对象(Software
Object)
软件对象是在项目进展过程中产生的、可由软件配置管理加以控制的任何实体。每个
软件对象都具有一个唯一的标识符、一个包含实际信息的对象实体、一组用于描述其自身特
性的属性与关系,以及用于与其他对象进行关系操作与消息传递的机制。
软件对象按其生成方式可分为源对象(Source
Object)与派生对象(Derived Object),
按其内容结构形式可分为原子对象(Atomic Object)与复合对象(Derived
Object),按其内
部结构形式可分为原子对象(Atomic Object)与复合对象(composite
Object),按照软件开
发的不同时刻(状态)可分为可变对象(Mutable Object)与不可变对象(Immutable
Object).
(7)
配置(Configuration)
配置指在配置管理中,软件或硬件所具有的(即在技术文档中所陈述的或产品所实现
的)那些功能特性和物理特性。
(8)
重要软件(Critical Software)
重要软件指其故障会影响到人身安全,会导致重大经济损失或社会损失的软件。
(9)
软件生存周期(Software Life
Cycle)
软件生存周期指从对软件系统提出应用需求开始,经过开发,产生出一个满足需求的计
算机软件系统,多面手投入运行,直至该软件系统“退役”为止。其间经历系统分析与软件
定义、软件开发以及系统的运行与维护等3
个阶段。其中软件开发阶段一般又分成需求分析、
概要设计、详细设计、编码与单元测试、组装与集成测试、系统测试以及安装与验收等6
个阶段。

(10)
软件开发库(Software Development
Library)
软件开发库指在软件生存周期的某一个阶段期间,存放与该阶段软件开发工作有关的
计算机可读信息和人工可读信息的库。
(11)
配置项(Configuration Item)
配置项指一个配置中的实体,它满足一项最终使用功能,并能在给定的参考点上意象
标识。在GB/T
11457-1995《软件工程术语》中给出配置项另外一个定义:为了配置管理目
的而作为一个单位来看待的硬件和/或软件成分,满足最终应用功能并被指明用于配置管理
的硬件/软件,或它们的集合体。
软件配置管理的对象是软件配置项,它们是在软件工程过程中产生的信息项。按照
ISO9000-3
的规定,软件配置可以是:
-与合同、过程、计划和产品有关的文档和数据;
-源代码、目标代码、和可执行代码;
-相关产品,包括软件工具、库内的可利用软件、外购软件及用户提供的软件。
组成上述信息的所有项目构成了一个软件配置,而其中的每一项便于工作称为一个软
件配置项,这是配置管理的基本单位。在软件开发过程中,最早的软件配置项是系统软件规
格说明书,随着软件开发过程的不断深入,软件配置项也迅速增加。
软件配置项基本可划分为两种类别:
-软件基准——经过正式评审和认可的一组软件配置项(文档和其他软件产品),它们作
为下一步的软件开发工作的基础,并且只有通过正式的变更控制堆积才能被更改。例如:设
计报告是编码工作的基础,设计报告可作为软件基准。
-非基准配置项——没有正式评审认可的一组软件配置项。
这可以从下面角度划分软件配置项。
一个软件系统划分为几个配置项要由项目经理所确定的开发策略决定。读者可以参考
NASA
给出的软件配置项划分原则( 《NASA Software Configuration
Management
Guidebooks》,1995),每个软件或某集合符合如下条件之一,可视为一个软件配置项:
-该软件集合是独立设计、实现和测试的;
-该软件集合对总体性能是关键的,或存在高风险的,或关系到系统安全性;
-该软件集合极为复杂,涉及高新技术,或有严格的性能要求;
-该软件集合与其他现有软件项目或由其他机构提供的软件之间有直接接口;
-预计该软件集合在成为可运行软件之后会有比常规更多的修改;
-该软件集合包括了某个特定范围的所有功能,如应用软件、操作系统等;
-该软件集合安装在与系统其他部分不同的计算机平台上;
-该软件集合被设计成可重复使用的。
下面介绍软件配置项的命名/编号。
软件的每个组件/部件的标识必须唯一,以便于用该标识符来跟踪和报告软件配置项的
状态。通常,对每一个软件配置项要赋予一个标识名称或符号,软件配置项的各部分又在该
标识符下附上描述符。NASA-CM-GDBK
给出的一个标识例子是:组成航天飞机飞行软件的
软件配置项可标识为FS(Flight Software for a
Spacecraft);而该飞行软件的组成部分,例如
飞行执行程序可标识为FS_EX,表示它是FS
软件配置项的第二层次组件;该执行程序的各
元件(子程序)可编号为FS_EX_001、FS_EX_002
等。
因此,可以根据“型号代号_分系统/设备配置代号_所处研制阶段代号_软件产品分类编
号_配置项编号”原则来对各软件配置项及其组件、子程序及相关描述文档进行命名、编号。
在软件的事个生存周期中,一般包括制定计划,分析评估、设计,测试,运行/维护等
状态。相应地可以把软件配置管理分为设计态,测试态,受控态和运行态4
种状态,其中受控态即指软件配置管理项处于配置管理状态。
(12) 软件受控库(Software controlled
Library)
软件受控库指在软件生存周期的某一个阶段结束时,存放作为阶段产品而释放的,与软
件开发工作有关的计算机可读信息和人工可读信息的库。软件配置管理就是对软件受控库中
的各软件项进行管理,因此软件受控库也叫做软件配置管理库。
(13)
软件产品库存(Software Product
Library)
软件产品库指在软件生存周期的系统测试阶段结束后,存放最终产品、交付给用户运
行或在现场安装的软件的库。软件产品库可在分系统、系统层上分别设立并维护。如果软件
产品库中的产品需要更改则应将些产品在产品库中加锁,撮软件受控库中相应的软件配置
项,履行受控库中的更改控制手续,直至更改完成并确认其能完成指定功能和性能后,方可
再次存入软件产品库。
(14)
配置管理(Configuration
Management)
配置管理是对以下各项在运用技术上和行政上的管理和监视的一门学科。对一个配置
项的功能特性和物理特性进行标识并写成文档;对这些特性的更改进行控制;对更改处理过
程和实施状态进行记录和报告;以及对是否符合规定需求进行验证。
(15)
接口控制(Interface
Control)
接口控制指描述由一个或多个部门提供的,两个或两个以上的配置项接口的所有功能
特性和物理特性的过程。在这些功能特性和物理特性实现之前,要确保对它们所做的修改
已经评审和批准。
(16)
版本(Version)
版本是某一配置项的已标识了的实例(Instance)。也可以说,不可变的源对象经质量
检查合格后所形成的新的相对稳定的格局(配置)称为软件版本。
每个软件对象可具有一人版本组,它们彼此间具有特定的关系,这种关系用以描述其演
变情况,通常软件对象的版本组呈树形结构。
(17)
版本控制(Version
Control)
版本控制就是管理在在软件生存周期中建立起恶报某一配置项的不同版本。
在软件工程过程中所涉及的软件对象都要加以标识。在对象成为基线以前可能要做多
次变更,在成为基线之后也可能需要频繁地变更。
(18)
释放(Release)
释放指在软件软件周期的各个阶段结束时,由该阶段向下阶段提交该阶段产品的过程。
它也指将系统测试阶段结束时所花篮的最终产品向用户提交的过程,这个过程也叫做交付
(Delivery)。
(19)
基线(Baseline)
基线指一个配置项在其生存周期的某一特定时间,被正式标明、固定并经正式批准的
版本。也可以说,基线是软件生存周期中各开发阶段末尾的特定点,又称里程碑。只有由正
式技术评审而得到的软件配置项协议和软件配置的正式的技术评审而得到的软件配置协议
和软件配置的正式文本才能成为基线。它的作用是使各阶段工作的划分更加明确化,使本来
连续的工作在这些点上断开,以便于检验和肯定阶段成果。
一个软件配置项一旦成为基线,就把它存放到项目数据库(也称项目信息库或软件仓
库)中。当一位软件组织成员想要对基线配置项进行修改时,就把它从项目数据库中复制到
该工程师的专用工作空间(例如ClearCase
的视图)中。这个活动记录在一个记事文件中。
总之,基线是软件配置管理的一个很需要概念。从某种意义上讲,它是在软件开发过
程中为进行质量控制而引入的,它是开发进度表上的一个参考点与度量点,是后续开发的稳
定基础。基线的形成实际上就是对某些配置进行冻结。

(20)
软件配置(Software
Configuration)
软件配置指一个软件产品在软件生存周期各个阶段所产生的各种形式(机器可读或人工
可读)和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该软件产品软
件配置中的一个配置项。
软件工程过程的输出信息有
3
种:计算机程序,描述计算机程序的文档(包括技术文
档和用户文档),数据结构。在软件工程过程中产生的所有的信息项(文档、报告、程序、
表格、数据)就构成了软件配置。软件配置是软件开发进展到某一时刻时产生的全部信息所
形成的一种格局,它反映并描述了软件开发阶段的状况。
软件配置的具体形态可分为以下两种。
-不可直接执行的材料。例如书写的文档、程序清单、测试数据、测试结果等。
-可直接执行的材料。例如目标代码、数据库信息等。它们可由计算机处理,存储于某
种存储介质上。
(21)功能基线(Functional
Baseline)
功能基线指在系统分析与软件定义阶段结束时,在经过正式评审和批准的系统设计规格
说明书中对开发系统的规格说明;或是指在经过项目委托单位和项目承办单位双方签字同意
的协议书或合同中,所规定的对开发软件系统的规格说明;或是由下级申请并经上级同意或
直接由上级下达的项目任务书中所规定的对开发软件系统的规格说明。功能基线是最初批准
的功能配置标识。
(22)分配基线(Allocated
Baseline)
分配基线指在软件需求分析阶段结束时,经过正式评审和批准的软件需求规格说明。分
配基线是最初批准的分配配置标识。
(23)产品基线(Product
Baseline)
产品基线指在软件组装与系统测试阶段结束时,经过正式评审和批准的有关软件产品的
全部配置项的规格说明。产品基线是最初批准的产品配置标识。
(24)基线配置管理(Baseline
Configuration
Management)
基线配置管理指建立经正式评审和认可,并作为进一步开发工作的基础的基线的过程。
某些(如软件设计和代码)软件工作产品应该有在预先确定点上建立的基线,并且应该对这
些项施加严格的更改控制过程。当与顾客打交道时,这些基线提供控制和稳定性。
(25)基线管理(Baseline
Management)
基线管理是指在配置管理中,运用技术上和行政上的管理来指定一些文档和更改这些文
档,这些文档在某些特定时刻正式标识和建立起基线。
(26)软件基线审计(Software
Baseline
Audit)
软件基线审计是指对于软件基线库的结构、内容和设施的考查,以便查证基线是否符合
描述基线的文档。
(27)软件基线库(Software
Baseline Library)
软件基线库是指存储配置项及相连记录的仓库。
(28)配置管理库系统(Configuration
Management Library System)
配置管理库系统是存取软件基线库内容的工具和规程。
(29)配置单元(Configuration
Unit)
配置单元是可放入配置管理库系统的、可从库中检索的一个配置项。
(30)过程能力基线(Process Capability
Baseline)
过程能力基线是指用文档记载的,对在典型环境下由于遵循某特定过程通常所能实现预
期结果的范围的特性描述。
(31)配置控制组/委员会(Configuration
Control
Board)
配置控制组/委员会是指一组负责评估和审批配置项的变更人员,以确保所有的变更都
是经过审核的。
(32)配置标识(Configuration
Identification)
配置标识是软件配置管理的一个要素,由为系统所选的配置项及记录它们功能的物理特
性的技术文档组成;经核准的配置项的技术文档是由说明书、图、表等组成的。为了方便对
软件配置项进行控制和管理,不致造成混乱,要给它们命名,这就是配置标识的任务。
配置标识主要目的是对变更配置项的软件行为及变更结果提供一个可跟踪的手段,避免
软件开发行为在不受控,混乱的情况下进行,也有利于软件开发工作以基线渐进的方式完成。
(33)变更管理(Change
Management)
变更管理是软件配置管理的一个要素,由评估、协调、批准或不批准以及对正式构造配
置标识的配置项实施变更等活动组成。
变更管理主要目的是控制和协调不同责任的软件开发人员进行有效的交流,使软件开发
人员不会在无序的环境下各自为战,导致团队开发的效率出现不可逾越的瓶颈。软件生存期
内全部的软件配置是软件产品的真正代表,必须使其保持精确。软件工程过程中某一阶段的
变更,均要引起软件配置的变更,对这种变更必须严格加以控制和管理,保持修改信息,并
把精确、清晰的信息传递到软件工程过程下一步骤。
(34)配置状态统计(Configuration
Status
Accounting)
配置状态统计是软件配置管理的一个要素,由有效管理所需的记录和报告信息组成。这
些信息包括经核准的配置标识表、需要变更的配置状态和实施经审核的变更状态。
状态统计主要目的是在版本控制与过程管理的基础上,通过量化的数据和报表展现软件
开发进度的状态。
(35)配置审核(Configuration
Auditing)
配置审核是软件配置管理的一个要素,它根据需求、标准或合同协议检验软件产品。
配置审核主要目的是以用户和开发团队均认可的衡量尺度(例如与用户签定的软件合
同),通过功能审核及物理审核两种方式,对软件实施过程和软件功能的完整性、正确性进
行检验审核。配置审核确保软件配置管理系统作用正确,保证测试过后的配置项功能满足需
求。
配置审核分为非正式审核和正式审核。
在软件生存周期的关键阶段采取非正式审核。例如,在开始系统设计前,一般要进行配
置审核,检验需求规格配置的完整性和正确性。在软件音乐会客户前采取正式审核。
正式审核包括功能型和物理型两种类型。功能配置审核(FCA)是通过对测试方法、测
试流程及测试报告的评价,鉴定软件配置项的实际性能是否符合设计文档所确定的要求。物
理配置审核(PCA)是对配置项的音乐会版本的正式检测,鉴定该版本是否与所确定的技术
和文档相一致,并保证软件音乐会版本中已完成了所有已批准的更改,包括了所有要求的软
件项目、数据、工作规程和文档。
软件配置管理的
4 个关键要素为配置标识、变更管理、配置审核、配置状态统计。
(36)开发配置管理(Developmental Configuration
Management)
开发配置管理是指运用技术上和行政上的管理来指定和控制软件和其相关的技术文档,
它们定义一个软件工作产品在开发期间不断进化的配置。开发配置管理自在开发者的直接控
制之下。置于开发配置管理下的配置项不是基线,虽然在开发的某些点上,它们可能被基线
化并置于基线配置管理之下。
(37)关键过程域(Key
Process
Area)
一组相关的活动,当这些活动共同完成时,能实现对建立过程能力至关重要的一组目标。
每个关键过程域已经定义在单个成熟度等级上。CMU—SEI
确定它们是一些主要构成单元,
用于帮助确定一个组织的软件过程能力和了解为更高成熟度等级前进所做的改进。软件配置
管理是CMM(软件能力成熟度模型)中等级2
的关键过程域。
常用的软件配置管理英文缩写:
CI Configuration Item 配置项
SCM Software
Configuration Management 软件配置管理
SCMP Software Configuration Management Plan
软件配置管理计划
CR Change Request 变更请求
SCN Specification Change Notice
说明变更注意
FCA Functional Configuration Audit 功能配置审核
GUI Graphical User
Interface 图形用户界面
PCA Physical Configuration Audit 物理配置审核
VDD Version
Description Document 版本说明文档
ECP Engineering Change Proposal 工程变更建议书
CPCI
Computer Program Configuration Item 计算机程序配置项
CSCI Computer Software
Configuration Item 计算机软件配置项
SCCB Software Configuration Control Board
软件配置控制组/委员会

时间: 2024-10-23 20:06:47

软件配置管理基本术语的相关文章

软件配置管理(SCM)简介

软件配置管理(SCM)简介qclrudse 一.引言qclrudse 软件开发过程中随着工作的进展会产生许多信息,如:需求分析说明.设计说明.源代码.可执行码.用户手册.测试用例.测试结果和这些内容形成的相应的技术文档:以及合同.计划.会议记录.报告等管理文档.另一方面,软件开发过程中出现变更是不可避免的.面对如此庞大且变动中的信息集合,如何使其有序高效地产生.存放.查找和利用成为软件工程项目十分突出的问题.如果没有一套严谨.科学的管理办法,出现混乱和差错几乎是必然的.软件配置管理正是为解决这个

《社会调查数据管理——基于Stata 14管理CGSS数据》一第3章 概念与术语3.1 和计算机及软件有关的术语

第3章 概念与术语 社会调查数据管理--基于Stata 14管理CGSS数据 在开始讲解数据管理每个流程的工作内容之前,需要简单介绍一下和数据管理相关的概念. 在讲解相关概念和术语之前,首先需要了解一下什么是数据.很多耳熟能详.天天挂在嘴边的词,不见得人人都能对其做出精准的解释. 数据:在人类历史很长一段时期中,数据指的就是数字.当计算机诞生后,得益于数据处理技术的飞速发展,数据的外延不断扩大,而今,信息时代的数据除了包含数字数据外,还包括文本.图片.录音.录像等,数据的表现形式变得多样化,数据

VSS 软件配置管理 版本控制第1/2页_应用技巧

 2.为什么需要配置管理 如果没有软件配置管理,最大的麻烦是工作成果无法回溯.随着工作的进展新的程序覆盖了老的程序,当突然发现新程序有问题而老程序正确时怎么办?那只能重写老的程序来覆盖新的程序.过一段时间又发现原来的老程序有问题,而解决方法在原来的新程序中--您是不是快要发疯了. 为了避免成果被覆盖,包括我自己在内的很多人早期采用手工管理版本的方式,例如当一个新版本产生时用当时的日期来命名文件夹,然后再复制一下以后的修改在复制的文件夹内进行,这样上一个版本就被保存下来了,周而复始不同的版本不会被

Fossil 1.19发布 软件配置管理/版本控制系统

Fossil 1.19这个版本带来了一些新的功能和改进.主要变化包括引进空目录,版本可控设置,客户端SSL证书的支持,并创建了一个Windows系统上的Fossil服务命令.一些UI的改进包括自动分色和使用更直观的相对路径. Fossil是一个分布式的软件配置管理/http://www.aliyun.com/zixun/aggregation/9591.html">版本控制系统,内置的可靠性和易用性.它配备了集成的bug跟踪和wiki.它易于安装和运行在chroot环境的能力作为一个单一的

Fossil 1.18 软件配置管理/版本控制系统

Fossil是一个分布式的软件配置管理/http://www.aliyun.com/zixun/aggregation/9591.html">版本控制系统,内置的可靠性和易用性.它配备了集成的bug跟踪和wiki.它易于安装和运行在chroot环境的能力作为一个单一的静态二进制分发.其他亮点包括一个Web界面,自动同步,简单的网络,并支持CGI. Fossil 1.18这个版本增加了连续的版本编号. 下载地址: Linux x86 455.86 KiB Linux x86_64 505.2

软件配置管理之管理什么

软件配置管理是对软件开发阶段的演化和变更进行管理:贯穿软件整个生命周期,从立项.需求定义.计划.设计.实现.测试再到发行,配置管理需要记录每一次里程碑转变的条件和结果,并且要能通过配置管理系统记录的文档和过程可以重现某个过程,也就是要能完整的记录整个研发过程,配置管理系统在定义配置项时要将项目中的每一个变化都反映到配置管理系统中: 目前公司存在的问题是 1.各个阶段的配置项依赖关系没有办法追踪,只知道有这些配置项,但是并不知道这些配置项之间的关系,哪个配置项先确立.哪个后确立: 2.各个阶段之间

软件标准项目文档

原文:http://www.cnblogs.com/Little-Li/archive/2011/06/30/2094230.html 在项目开发过程中,应该按要求编写好十三种文档,文档编制要求具有针对性.精确性.清晰性.完整性.灵活性.可追溯性. ◇ 可行性分析报告:说明该软件开发项目的实现在技术上.经济上和社会因素上的可行性,评述为了合理地达到开发目标可供选择的各种可能实施方案,说明并论证所选定实施方案的理由. ◇ 项目开发计划:为软件项目实施方案制订出具体计划,应该包括各部分工作的负责人员

《配置管理最佳实践》——导读

** 前言 **配置管理(CM,Configuration Management)在任何开发工作中都起着非常关键的作用.我从事配置管理的实施和支持工作已经超过25年,本书中将讨论的大部分内容都直接来自于个人的经验.我实施并支持过各种配置管理的实践方法并达到这样一种状态--如果建立的过程或自动化没有按照预期般运作的话,我经常会在半夜里被惊醒.作为一名教师,我向超过九百多的专业技术人员传授过工业级的配置管理工具(同样,他们在成功地完成课程后都得到了我家的电话号码,这样如果我没有教授好知识和技能,即使

《配置管理最佳实践》——第1章 源代码管理 1.1为什么源代码管理如此重要

第I部分 配置管理核心实践 第1章 源代码管理 源代码管理是保护组装成系统的所有工件(artifact)的学科.源代码管理是配置管理的核心职能(function),直接影响着团队的生产力和产品质量.不幸的是,很多公司并没有意识到建立高效源代码管理机制的重要性,缺乏实施源代码管理的能力,缺少源代码管理工具和流程.这一章将讨论如何正确地进行源代码管理.我曾经负责过多家分布全球的大公司的源代码管理工作.源代码管理必须确保产品发布的源代码永远都不能丢失.源代码需要通过一种灵活和创新的方式进行管理.每个公