软件配置管理基本术语

  1. 云栖社区>
  2. 博客>
  3. 正文

软件配置管理基本术语

lzhdim 2009-02-02 16:49:00 浏览1011
展开阅读全文
软件配置管理(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 软件配置控制组/委员会

网友评论

登录后评论
0/500
评论
lzhdim
+ 关注