配置管理是软件质量保证的重要一环。软件配置管理的基本任务包括配置标识、版本管理、..

2011年上半年上午试卷综合知识

第 26 题


知识点	变更管理配置审核软件配置管理版本管理基本任务配置标识配置管理软件配置软件质量保证维护质量保证
关键词	版本管理变更管理配置标识配置管理库软件配置管理软件质量保证维护变更配置管理软件配置软件质量质量保证
章/节	软件与软件工程知识

配置管理是软件质量保证的重要一环。软件配置管理的基本任务包括配置标识、版本管理、变更管理、（26)和配置报告。在配置管理库中，受控库（CL)通常以（27)为单位建立并维护。

A. 配置组管理

B. 配置对象管理

C. 配置审核

D. 配置库管理

相关试题软件配置管理

第29题

2013年上半年

软件配置项的属性一般不包含(29)。

第29题

2014年下半年

软件配置管理项都必须做到“文实相符，文文一致”，以满足”有效性”、“可见性”和 (29)要求。

第24题

2011年下半年

软件配置项是软件配置管理的对象，指的是软件工程过程中所产生的（24)。

知识点讲解

· 变更管理

· 配置审核

· 软件配置管理

· 版本管理

· 基本任务

· 配置标识

· 配置管理

· 软件配置

· 软件质量保证

· 维护

· 质量保证

变更管理

一般在合同订立之后，引起工程范围、合同有关各方权利责任关系变化的事件均可以看作是合同变更。监理进行合同的变更管理时，应注意以下几个方面的内容。

（1）分析合同变更产生的原因。合同变更产生的原因通常包括设计图纸的变更，工程条件的变动，新技术、新工艺、新材料和新成果的应用，政府部门对信息工程建设项目的新要求，如新的行业标准及技术标准等。

（2）评估合同变更可能产生的影响。合同变更可能产生的影响可能涉及以下₄个方面：建设单位、承建单位及子承建单位之间合同责任的变化；材料损失；项目停工；已完工程的返工。

（3）经评估，确实需要变更的，应尽快做出变更。并迅速、全面、系统地落实变更指令，对合同变更产生的影响进行监控。

（4）对于合同变更，应尽量采用书面形式，口头协议或临时性交换函件等是不可取的。尤其是当改变服务范围和费用问题时，监理单位应坚持要求以书面形式修改合同。

按照合同变更所产生的影响从小到大，应分别采用如下形式。

（1）信件协议。对一些内容简单、涉及面小、修改内容较少，临时决定且未经商定或来不及商定的事务性变更，可采用信件协议的方式。信件协议一经对方接纳，同意履行，该信件协议具有法律效力。

（2）委托书。对一些影响较小、内容比较简单、修改量少且时间要求紧的变更，可采用委托书的形式通知合同当事人。

（3）正式文件。对修改较大、内容复杂、影响面大且时间跨度长的变更，由合同一方提出合同变更通知，经有关各方充分协商谈判，同意履行变更内容后共同签署，以正式文件的形式发出。

（4）重新签订合同。在变动范围大，涉及合同当事各方的权利和义务，以及酬金增减等重大问题，凭上述变更很难表达清楚时，需要重新制定一个新的合同来取代原有合同。

配置审核

配置审核的主要作用是作为变更控制的补充手段来确保某一变更需求已被切实实现。在某些情况下，它被作为正式的技术复审的一部分，但当软件配置管理是一个正式的活动时，该活动由SQA人员单独执行。

软件配置管理

在软件配置管理方面，监理的主要工作如下。

（1）确保应用软件系统建设承建单位的配置管理组织和环境按照软件项目计划的要求成立并配备。

（2）控制承建单位依据书面规程，为应用软件系统建设项目制定软件配置管理计划。

（3）监督承建单位使用审批通过的、文档化的软件配置管理计划作为实施软件配置管理活动的基础。

（4）控制承建单位依据的书面规程，对所有配置项／单元的更改请求和问题报告实施初始准备、记录、评审、批准和跟踪。

（5）监督承建单位依据书面规程，控制对基线的更改。

（6）控制承建单位编制软件配置管理报告，证明软件配置管理活动和软件基线库的内容，并提供给建设单位。

（7）监督承建单位依据书面规程进行软件基线库的审核，进行软件配置管理活动状态的跟踪和记录。

（8）定期审查软件配置管理活动和软件配置管理基线，以验证它们与文档定义的一致性。

（9）审核软件配置管理活动及其工作产品，并给出软件配置管理监理报告。

版本管理

在配置管理中，所有的配置项都应列入版本控制的范畴。对于信息产品的版本有两个方面的意思，一是为满足不同用户的不同使用要求，如用于不同运行环境的系列产品。如适合Linux，Windows，Solaris用户的软件产品分别称为Linux版，Windows版和Solaris版。它们在功能和性能上是相当的，原则上没有差别，或者说，这些是并列的系列产品。对于这类差别很小的不同版本，互相也称为变体（variant）。

另一种版本的含义是在信息系统产品投产使用后，产品经过一系列的变更，如纠错，增加功能，提高性能的更改，而形成的一系列顺序演化的产品，这些产品也称为一个版本，每个版本都可说出它是从哪个版本导出的演化过程。

必须注意到，修正后的新版本往往不能完全代替老版本，尽管新版本有某些优越的特性。因为一些用户仍然使用着老版本，并且不容易立刻做到以旧换新，否则可能会打扰老版本原有的工作环境。显然，多个版本被多个用户同时使用的情况是不可避免的现象。这就要求多个版本共存，这也就是配置管理要解决的一个重要课题。

配置项的状态通常有3种，分别是草稿、正式发布和正在修改。一般来说，配置项版本控制的流程如下：

（1）创建配置项。

（2）修改处于草稿状态的配置项。

（3）技术评审或领导审批。

（4）正式发布。

（5）变更，修改版本号。

版本管理要解决的第一个问题是版本标识，也就是为区分不同的版本，要给它们科学的命名。通常有2种版本命名的方法，分别是号码版本标识和符号版本标识。其中号码版本标识以数字表示，如用1.0，2.0，1.2，2.1.1等表示版本号；符号版本标识是将重要的版本属性有选择地给出，如Windows XP、Windows 2003、Jbuilder 2005将版本产生的时间给出。为了从版本标识上看到更多信息，可能给出更多的属性，如面向的客户群、开发语言、硬件平台、生成日期等。

在配置管理中，版本包括配置项的版本和配置的版本，这两种的版本的标识应该各有特点，配置项的版本应该体现出其版本的继承关系，它主要是在开发人员内部进行区分。另外，还需要对重要的版本做一些标记，如对纳入基线的配置项版本应该做一个标识。

基本任务

需求分析的基本任务是深入了解用户建网的目的和目标并加以分析，然后进行纵向的更加细致的需求分析和调研，在确定地理布局、设备类型、网络服务、通信类型和通信量、网络容量和性能、网络现状等几个主要方面情况的基础上形成分析报告。

（1）问题分析阶段。分析人员通过对问题及其环境的理解、分析和综合，清除用户需求的模糊性、歧义性和不一致性，并在用户的帮助下对相互冲突的要求进行折中。在这一阶段，分析人员应该将自己对原始问题的理解与网络设计经验结合起来，以便可发现哪些需求是由于用户的片面性或短期行为所导致的不合理要求，哪些要求是用户尚未提出但具有真正价值的潜在需求。由于用户群体中的各个用户往往会从不同的角度和抽象级别上阐述他们对原始问题的理解和对目标网络的需求，因此，有必要为原始问题及网络设计建立模型。

（2）需求描述阶段。主要以需求模型为基础，生成需求说明书。内容包括对目标网络系统外部特性的完整描述、需求验证标准以及用户在功能、性能、可靠性和维护管理等方面的要求。生成文档时，分析人员应该严格遵循既定规范，做到内容全面、结构清晰、措辞准确、格式严谨。

（3）需求评审阶段。分析人员要在用户和网络设计人员的配合下对自己生成的需求说明书进行复核，以确保网络需求的全面性、精确性和一致性，并使用户和网络设计人员对需求说明书的理解达成一致。

配置标识

配置标识是配置管理的基础性工作，是配置管理的前提。配置标识是确定哪些内容应该进入配置管理形成配置项，并确定配置项如何命名，用哪些信息来描述该配置项。

确定配置项

信息系统项目中形成的技术性文档和管理性文档，除一些临时性的文档外一般都应该进行配置管理。一般来讲，判定一个文档是否进行配置管理的标准应该是此文档是否有多个人需要使用，这些文档往往在项目的进程中不断地修正和扩展，要保证每个使用者都使用同一版本的文档，就必须将这些文档纳入配置管理，成为受控的配置项。

（1）识别配置项。可能成为配置项组成部分的主要工作产品有过程描述、需求、设计、测试计划和规程、测试结果、代码／模块、工具（如编辑器）、接口描述等。在软件工程方面，Roger S. Pressman认为至少以下所列的文档应该成为配置项：系统规格说明书、项目计划、需求规格说明书、用户手册、设计规格说明、源代码、测试规格说明、操作和安装手册、可执行程序、数据库描述、联机用户手册、维护文档、软件工程标准和规程。

（2）配置项命名。确定了配置项后，还需要对配置项进行合理、科学的命名。配置项的命名绝不能随意为之，必须满足唯一性和可追溯性。一个典型的实例是采用层次式的命名规则来反映树状结构，树状结构上结点之间存在着层次的继承关系。

（3）配置项的描述。由于配置项除了名称外还有一些其他属性和与其他配置项的关系，因此它可以采用描述对象的方式来进行描述。每个配置项用一组特征信息（名字、描述、一组资源、实现）唯一地标识。配置项间的关系有整体和部分的关系及层次关系，也有关联关系。配置项间的关系可以用MIL语言（Module Interconnection Language）表示。MIL描述的是配置项间的相互依赖关系，可自动构造系统的任何版本。

（4）识别配置项的步骤。识别配置项的主要步骤如下：

.识别配置项。

.为每个配置项指定唯一性的标识代号。

.确定每个配置项的重要特征。配置项的特征主要包括作者、文档类型、代码文档的程序设计语言。

.确定配置项进入配置管理的时间。

.确定每个配置项的拥有者及责任。

.填写配置管理表。

.审批配置管理表。CCB审查配置管理表是否符合配置管理计划和项目计划文档的规定，审批配置管理表。

基线

基线（baseline）是项目生存期各开发阶段末尾的特定点，也称为里程碑（milestone），在这些特定点上，阶段工作已结束，并且已经形成了正式的阶段性产品。

建立基线的概念是为了把各开发阶段的工作划分得更加明确，使得本来连续开展的开发工作在这些点上被分割开，从而更加有利于检验和肯定阶段工作的成果，同时有利于进行变更控制。有了基线的规定就可以禁止跨越里程碑去修改另一开发阶段的工作成果，并且认为建立了里程碑，有些完成的阶段成果已被冻结。

作为阶段工作的正式产品，基线应该是稳定的，如作为设计基线的设计规格说明应该是通过评审的。如果还只是设计草稿，就不能作为基线，不能被冻结。

如果把软件看作是系统的一个组成部分，以下3种基线最受人们关注的：功能基线、分配基线、产品基线。

（1）功能基线：指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标志。

（2）分配基线（指派基线）：指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标志。

（3）产品基线：指在软件组装与系统测试阶段结束时，经过正式评审批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志。

另外，交付给外部顾客的基线一般称为发行基线，内部使用的基线称为构造基线。释放是指在软件生存周期的各个阶段结束时，由该阶段向下阶段提交该阶段产品的过程。它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也称为交付。

：提出基线的概念本来是为了更好地实现变更控制，但如果把每个基线都当成一个整体来看待会造成麻烦。因为一个变更很可能只涉及基线的很小部分。例如，假定某个大型软件中的一个模块修改了，如果将这一变更当做整个软件产品基线的变更，就很不方便。

建立配置管理系统

在配置管理中，要建立并维护配置管理系统和变更管理系统。建立配置管理系统的主要步骤如下：

（1）建立适用于多控制等级配置管理的管理机制。生存周期中不同时间所需的控制等级不同，不同的系统类型所需的控制等级不同，满足专属性和安全性方面的不同的控制等级。

（2）存储和检索配置项。

（3）共享和转换配置项。

（4）存储和复原配置项的归档版本。

（5）存储、更新和检索配置管理记录。

（6）创建配置管理报告。

（7）保护配置管理系统的内容。配置管理系统的主要功能有文档的备份与恢复、文档的建档、从配置管理的差错状态下复原。

（8）权限分配。CMO的权限最高，一般项目成员可拥有添加、检入／检出、下载的权限，但是不能有删除的权限。

创建基线或发行基线

创建基线或发行基线的步骤如下：

（1）获得CCB的授权。CMO根据项目进展情况或项目组的要求和基线计划规定，提出创建基线的书面请求，提请CCB授权。

（2）创建构造基线或发行基线。

（3）形成文件。

（4）使基线可用。

配置管理

随着信息系统软件版本不断变化，开发时间的紧迫以及多平台开发环境的采用，使得软件开发、维护面临越来越多的问题，其中包括对当前多种软件的开发和维护、保证产品版本的精确、重建先前发布的产品、加强开发政策的统一和对特殊版本需求的处理等等。

信息系统软件配置管理是一种应用于整个软件工程过程的标识、组织和控制修改的围绕软件资产的管理技术。界定软件的组成项目，对每个项目的变更进行管控（版本控制），并维护不同项目之间的版本关联，以使软件在开发过程中任一时间的内容都可以被追溯。其关键活动包括：配置管理计划、配置项管理、版本控制、变更控制、配置审计、状态报告等。

配置管理计划

根据信息系统软件运维制度和规范、标准，制定配置管理计划，主要包括以下内容。

（1）该项目对配置管理的要求。

（2）实施配置管理的责任人、组织及其职责。

（3）需要开展的配置管理活动及其进度安排。

（4）采用的方法和工具等。

配置与配置项

“配置”是在技术文档中明确说明并最终组成软件产品的功能或物理属性。因此“配置”包括了即将受控的所有产品特性，及其内容及相关文档，软件版本，变更文档，软件运行的支持数据，以及其他一切保证软件一致性的组成要素。

为了方便对“配置”进行管理，“配置”经常被划分为各类配置项，这类划分是进行软件配置管理的基础和前提。配置项是一组软件功能或者物理属性的组合，在配置管理过程中，配置项被作为一个单一的实体对待。配置项包括各种管理文档和技术文档，源程序与目标代码，以及运行所需的各种数据等。同时，应该建立配置库来管理所有的配置项。

版本控制

版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加，修改或删除，配置项的版本随之演变。应当记录每个软件配置项的所有历史记录，并记录该软件配置项由何人创建，何人在何时因何原因进行了修改等信息，以及对这些软件配置项版本的进行检索和信息查询等活动。

变更控制

变更在信息系统软件运维过程中是不可避免的。变更控制是配置管理的一个重要组成部分，包含评估、协调、批准／拒绝、实施对配置项的变更。

配置审计

配置审计是对配置管理的独立的查检过程，确认受控软件配置项满足需求并就绪。其内容如下。

（1）功能审计：配置项的变更控制是否和配置管理计划中的描述相一致。

（2）物理审计：配置项的完整性、正确性、一致性和可跟踪性。

状态报告

状态报告用来记录和报告有效管理配置所需要的必要信息。这些信息包括一个已批准的配置标识清单，变更请求当前的处理状态，以及批准的变更的实现情况。配置状态报告可以跟踪对软件的更改的过程，它保证对正在进行和已完成的变更进行记录、监视并通报给相关人员。

软件配置

软件配置是指一个软件产品在软件生存周期各个阶段所产生的各种形式（机器可读和人工可读）和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该软件产品软件配置中的一个配置项。

软件质量保证

软件质量保证包括与以下7个主要活动相关的各种任务。

（1）应用技术方法。软件质量保证首先从一组技术方法和工具开始，这些方法和工具帮助分析人员形成高质量的规格说明和高质量的设计。

（2）进行正式的技术评审。这是一种由技术人员实施的程式化会议，其唯一的目的是揭露质量问题。

（3）测试软件。软件测试组合了多种测试策略，这些测试策略带有一系列有助于有效地检测错误的测试用例及设计方法。

（4）标准的实施。多数情况下，标准由客户或某些章程确定。与标准是否一致的评估可以被软件开发者作为正式技术评审的一部分来进行。

（5）控制变更。变更控制过程通过对变更的正式申请、评价变更的特性和控制变更的影响等直接提高软件的质量。变更控制应用于软件开发期间和较后的软件维护阶段。

（6）计量。其包括某些技术上的和面向管理的计量。

（7）记录保存和报告。为软件质量保证提供收集和传播软件质量保证信息的过程。评审、监察、变更控制、测试和其他软件质量保证活动的结果必须变成项目历史记录的一部分，并且应当把它传播给需要知道这些结果的开发人员。

维护

维护阶段是软件生存期中时间最长的阶段。软件一旦交付正式投入运行后便进入软件维护阶段。该阶段的关键任务是通过各种必要的维护活动使系统持久地满足用户的需要。每一项维护活动都应该准确地记录下来，作为正式的文档资料加以保存。

质量保证

系统质量是指反映系统或产品满足规定或隐含需求的能力的特征和特性全体。软件质量管理是指对软件开发过程进行的独立的检查活动，由质量保证、质量规划和质量控制三个主要活动构成。质量保证是指为保证系统或软件产品充分满足用户要求的质量而进行的有计划、有组织的活动，其目的是开发高质量的系统。

质量特性

讨论系统质量首先要了解系统的质量特性。已经有多种软件质量模型来描述软件质量特性，目前较多采用的如ISO/IEC 9126软件质量模型和Mc Call软件质量模型。ISO/IEC 9126已经被ISO/ICE 25010系统和软件质量模型所取代，其主要改进包括将兼容性作和安全性作为质量特性，ISO/IEC 25012数据质量模型与ISO/IEC 25030使用质量模型作为补充。

ISO/ICE 25010系统和软件质量模型

ISO/ICE 25010系统和软件质量模型包含8个质量特性，每个特性由一组相关的质量子特性组成，如下图所示。该产品质量模型既可以用于软件，又可以用于任何包含软件的计算机系统。

产品质量模型

其中，各质量特性和质量子特性的含义如下。

（1）功能适合性（functional suitability）。与一组功能及其指定的性质的存在有关的一组属性。功能是指满足规定或隐含需求的那些功能。

.功能完整性（functional completeness）：与对规定任务和用户目标加以实现的功能是否完整有关的属性。

.功能适当性（functional appropriateness）：与对规定任务和用户目标能否提供一组功能以及这组功能是否适合有关的属性。

.功能正确性（functional correctness）：与能够得到正确或相符的结果或效果有关的产品或系统属性。

（2）性能效率（performance efficiency）。在规定条件下，系统的性能水平与所用资源量之间的关系有关的一组属性。

.时间特性（time behavior）：与响应和处理时间以及软件执行其功能时的吞吐量有关的属性。

.资源利用率（resource utilization）：与系统执行其功能时所使用的资源量以及使用资源的类型有关的属性。

.容量（capacity）：与系统满足特定需求时指标参数的最大限制有关的属性。

（3）兼容性（compatibility）。与系统或组件与其他系统或组件进行信息交换，或在不同软硬件环境中执行所需功能有关的一组属性。

.共存性（co-existence）：与同其他系统运行在同一环境使用相同的资源而不相互影响的能力相关的属性。

.互操作性（interoperability）：与同其他指定系统进行交互操作的能力相关的属性。

（4）易用性（usability）。与为使用所需的努力和由一组规定或隐含的用户对这样使用所作的个别评价有关的一组属性。

.可识别性（appropriateness recognizability）：与用户识别系统是否满足需求有关的属性。

.易学性（learnability）：与用户为学习使用产品（例如操作控制、输入、输出）的有效性、效率、风险和满意度相关的属性。

.易操作性（operability）：与用户为进行操作和操作控制所付出的努力有关的属性。

.错误防御（user error protection）：与阻止用户错误输入有关的属性。

.界面美观性（user interface aesthetics）：与系统用户界面使用户进行愉快满意交互有关的属性。

.可访问性（accessibility）：与用户可访问系统完成特定目标的范围和能力有关的属性。

（5）可靠性（reliability）。与在规定的一段时间内和规定的条件下，系统维持在其性能水平有关的能力。

.成熟性（maturity）：与正常操作情况下满足可靠性需求有关的属性。

.可用性（availability）：与系统运行可用使用能力有关的属性。

.容错性（fault tolerance）：与在系统错误或违反指定接口的情况下，维持指定的性能水平的能力有关的属性。

.易恢复性（recoverability）：与在故障发生后，重新建立其性能水平并恢复直接受影响数据的能力，以及为达到此目的所需的时间和努力有关的属性。

（6）安全性（security）。与避免对程序及数据的非授权故意或意外访问的能力有关的系统属性。

.机密性（confidentiality）：与系统确保只有授权才能访问其数据能力有关的属性。

.完整性（integrity）：与系统防止未经授权对数据和程序进行访问和修改能力有关的属性。

.不可抵赖性（non-repudiation）：与对系统使用行为及发生时间真实性有关的属性。

.可审计性（accountability）：与对系统使用行为进行追踪有关的属性。

.真实性（authenticity）：与证明主体或资源身份是所声称的身份有关的属性。

（7）可维护性（maintainability）。与进行规定的修改所需要的努力有关的一组属性。

.模块性（modularity）：与所组成系统的模块独立性有关的属性。

.可复用性（reusability）：与模块用于其他系统有关的属性。

.易分析性（analyzability）：与为诊断缺陷或失效原因，或为判定待修改的部分所需努力有关的属性。

.易修改性（modifiability）：与进行修改、排错或适应环境变换所需努力有关的属性。

.易测试性（testability）：为确认经修改系统所需努力有关的属性。

（8）可移植性（portability）。与系统可从某一环境转移到另一环境的能力有关的一组属性。

.适应性（adaptability）：与系统转移到不同环境时的处理或手段有关的属性。

.易安装性（installability）：与在指定环境下对系统进行安装／卸载所需努力有关的属性。

.易替换性（replaceability）：与一产品在该软件环境中用来替代指定的其他软件的可能和努力有关的属性。

Mc Call软件质量模型

Mc Call软件质量模型从软件产品的运行、修正、转移三个方面确定了11个质量特性，如下图所示。Mc Call也给出了一个三层模型框架，第一层是质量特性，第二层是评价准则，第三层是度量指标。

Mc Call软件质量模型

质量保证

质量保证是指为保证系统或产品充分满足用户要求的质量而进行的有计划、有组织的活动，其目的是生产高质量的产品。在系统质量方面强调三个要点：首先系统必须满足用户规定的需求，与用户需求不一致的系统，就无质量可言；其次系统应遵循规定标准所定义的一系列开发准则，不遵循这些准则的系统，其质量难以得到保证；最后系统还应满足某些隐含的需求，例如希望有好的可理解性、可维护性等，而这些隐含的需求可能未被明确地写在用户规定的需求中，如果系统只满足它的显性需求而不满足其隐含需求，那么该系统的质量是令人担忧的。

质量保证包括7个主要活动相关的各种任务，分别是应用技术方法、进行正式的技术评审、测试系统、标准的实施、控制变更、度量（metrics）、记录保存和报告。

更多复习资料
请登录电脑版软考在线 www.rkpass.cn

京B2-20210865 | 京ICP备2020040059号-5