配置管理是软件生命周期中的重要控制过程，在软件开发过程中扮演着重要的角色，根据GB..

免费智能真题库 > 历年试卷 > 信息系统项目管理师 > 2015年上半年信息系统项目管理师上午试卷综合知识

第13题

知识点：配置管理相关概念基线角色开发过程配置管理软件工程软件工程术语生命周期

关键词：基线配置管理软件工程术语软件开发过程软件生命周期开发开发过程软件工程软件开发生命周期章/节：配置管理基础

配置管理是软件生命周期中的重要控制过程，在软件开发过程中扮演着重要的角色，根据GB/T 11457-2006《软件工程术语》的描述，以下关于配置管理基线的叙述中，（）是不正确的。

A. 配置管理基线包括功能基线，即最初通过的功能的配置

B. 配置管理基线包括分配基线，即最初通过的分配的配置

C. 配置管理基线包括产品基线，即最初通过的或有条件通过的产品的配置

D. 配置管理基线包括时间基线，即最初通过的时间的安排

相关试题：配置管理基础

更多>

第64题 2013年上半年

61%

在配置管理中，基线是一组经过审查并且达成一致的规范或工作产品，是开发工作的基础。配置管理员根据《项目计划文档》、《配置管..

第62题 2014年下半年

26%

基线由一组配置项组成，这些配置项构成了一个相对稳定的逻辑实体，是一组经过（62）正式审查、批准、达成一致的范围或工作产品，..

第42题 2011年下半年

62%

通常，项目整体变更管理过程涉及到负责批准或拒绝变更请求的变更控制委员会，下列关于变更控制委员会的描述中，错误的是（42）。..


知识点讲解
· 配置管理相关概念 · 基线 · 角色 · 开发过程 · 配置管理 · 软件工程 · 软件工程术语 · 生命周期

配置管理相关概念

配置管理

配置管理是采用技术手段和行政手段进行管理和监督的一套规范化方法；对配置项的功能特性和物理特性加以标识，并将其文档化；控制这些特性的变更；报告变更进行的情况和变更实施的状态以及验证与规定需求的一致性。

项目配置管理的主要任务包括：

.制订项目配置管理计划。

.确定配置标识规则。

.实施变更控制。

.报告配置状态。

.进行配置审核。

.进行版本管理和发行管理。

配置管理系统

配置管理系统用于控制工作产品的配置管理和变更管理。该系统包括存储媒体、规程和访问该配置系统的工具、用于记录和访问变更请求的工具。

在大多数应用领域，配置管理系统包括变更控制系统。

配置管理活动和流程

配置管理活动和流程主要包括制订配置管理计划、配置识别与建议基线、建立配置管理系统、版本管理、配置状态报告和配置审计。

配置项

IEEE对配置项的定义为“硬件、软件或二者兼有的集合，为配置管理指定的，在配置管理过程中作为一个单独的实体对待。

产品配置是指一个产品在其生命周期各个阶段所产生的各种形式和各种版本的文档、计算机程序、部件及数据的集合。该集合中的每个元素称为该产品配置中的一个配置项（CI），主要有两大类：

.属于产品组成部分的工作成果，如需求、设计文档、源代码和测试用例等。

.属于项目管理和机构支撑过程域产生的文档，如工作计划、质量报告、项目跟踪报告等。

每个配置项的主要属性有名称、标识符、文件状态、版本、作者和日期等。

配置库

配置库是一组受控制的，辅助软件开发、使用和维护的软件及相关的文档，它在软件发布与交付活动中起着器械性的作用。

配置库的主要作用表现在：

.记录与配置相关的所有信息。

.利用库中的信息可评价变更的后果。

.从库中可提取各种配置管理过程的管理信息。

配置库有三类：

.开发库。也称动态库，存放开发过程中需要保留的各种信息，供开发人员个人专用。无须对开发库的修改做限制。

.受控库。也称主库，在信息系统开发的某个阶段结束时，将工作产品存入或有关信息存入。对库内信息的修改要遵循变更控制流程。

.产品库。存放最终产品，等待交付用户或现场安装。库内信息也应加以控制。

基线

基线是一组经过正式审查并且达成一致的规范或工作产品，是开发工作的基础。一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线，内部使用的基线一般称为构造基线。

基线的主要属性有名称、标识符、版本和日期等。一组拥有唯一标识号的需求、设计、源代码以及相应的可执行代码、构造文档和用户文档可以认为是一个基线。产品的一个测试版本也可以作为基线。

在建立基线以前，工作产品的所有者能快速、非正式地对工作产品做出变更。但基线建立以后，变更则需要由正式的变更控制程序来控制。

变更控制委员会

变更控制委员会（CCB）也称为配置控制委员会，是配置项变更的监管组织。其任务是对提出的配置项变更做出评价、审批以及监督已批准变更的实施。

变更控制委员会的成员可以包括项目经理、用户代表、项目质量控制人员、配置控制人员等。CCB可以不是常设机构，完全可以根据工作需要组成，小项目CCB可以只有一人，甚至只是兼职人员。它的任务除控制变更以外，也可以负责更多的配置管理任务，如基线的审定、标识的审定以及产品的审定。

基线

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

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

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

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

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

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

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

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

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

角色

考虑一个有很多出纳的银行。每一个出纳必须对同一组关系具有同种类型的权限。无论何时指定一个新的出纳，他都必须被单独授予所有这些授权。

一个更好的机制是指明所有出纳应该有的授权，并单独标示出哪些数据库用户是出纳。系统可以用这两条信息来确定每一个有出纳身份的人的权限。当一个人被新雇佣为出纳时，必须给他分配一个用户标识符，并且必须将他标示为一个出纳，而不需要重新单独给予出纳权限。

角色（role）的概念可用于该机制。在数据库中建立一个角色集，和授予每一个单个用户一样，可将权限授予角色。分配给每个数据库用户一些他（或她）有权扮演的角色（也可能是空的）。

事实上，在银行的数据库里，角色的例子可以包括system-administrator、branch-manager、teller和auditor。一个不是很合适的方法是建立一个teller用户号，允许每一个出纳用这个出纳用户号来连接数据库。该机制的问题是它无法鉴别出到底哪个出纳执行了事务，从而导致安全隐患。应用角色的好处是需要每个用户用自己的用户号连接数据库。

任何可以授予一个用户的权限都可以授予一个角色。给用户分配角色就跟给用户授权一样。与其他授权一样，一个用户也可以被授予给他人分配角色的权限。这样，可以授予支行经理（branch-manager）分配出纳角色的权限。

开发过程

嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段。

项目计划、可行性分析、需求分析、概要设计及详细设计等几个阶段，与通用软件的开发过程基本一致，都可按照软件工程方法进行，如采用原型化方法、结构化方法等。

：由于嵌入式软件的运行和开发环境不同，开发工作是交叉进行的，所以每一步都要考虑到这一点。

程序建立阶段的工作是根据详细设计阶段产生的文档进行的，主要是源代码编写、编译链接等子过程，这些工作都在宿主机上进行，不需要用到目标机。产生应用程序的可执行文件后，就要用到交叉开发环境进行调试，根据实际情况可以选用3.6.3节中提到的调试方法或其有效组合来进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高，所以，在对嵌入式系统进行白盒测试时，要求有更高的代码覆盖率。

最后，要将经调试后正确无误的可执行程序固化到目标机上。根据嵌入式系统硬件配置的不同，可以固化在EPROM（Erasable Programmable ROM，可擦除可编程ROM）和Flash等存储器中，也可固化在DOC（DiskOnChip）等电子盘中，通常还要借助一些专用编程器进行。

配置管理

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

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

配置管理计划

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

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

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

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

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

配置与配置项

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

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

版本控制

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

变更控制

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

配置审计

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

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

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

状态报告

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

软件工程

1）软件工程的概念

为了消除软件危机，通过认真研究解决软件危机的方法，人们认识到软件工程是使计算机软件走向科学的途径，逐渐形成了软件工程的概念，并开辟工程学的新兴领域，即软件工程学。

2）软件工程的要素

软件工程具有以下3个要素。

（1）方法。完成软件工程项目的技术手段。

（2）工具。支持软件的开发、管理、文档生成。

（3）过程。将方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。

3）软件生命周期

软件生命周期是指软件产品从考虑其概念开始到该软件产品交付使用，直至最终退役为止的整个过程，包括计划阶段、分析阶段、设计阶段、实现阶段、测试阶段和运行维护阶段。

4）软件开发模型

比较经典的软件开发模型有瀑布模型、快速原型模型、演化模型、增量模型、螺旋模型、喷泉模型等。

5）软件开发方法

软件开发方法有以下几种。

（1）结构化软件开发（SASD）方法：采用结构化技术来完成软件开发的各项任务。它把软件生命周期划分成若干个阶段，依次完成每个阶段的任务。它与瀑布模型有很好的结合度，是与其最相适应的软件开发方法。

（2）面向数据结构的软件开发方法：从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其他细节，从而可得到完整的程序结构图。有Jackson方法和Warnier方法。

（3）面向对象的软件开发方法：随着OOP（面向对象编程）向OOD（面向对象设计）和OOA（面向对象分析）的发展，最终形成面向对象的软件开发方法OMT（Object Modelling Technique）。这是一种自底向上和自顶向下相结合的方法，而且它以对象建模为基础，从而不仅考虑了输入、输出数据结构，实际上也包含了所有对象的数据结构。

（4）基于构件化的开发方法：用预先建立的构件和模板，像"搭积木"一样进行建造。

软件工程术语

《GB/T 11457—2006信息技术软件工程术语》定义了软件工程领域中通用的术语，适用于软件开发、软件维护、科研、教学和出版等方面。

.抽象：对某一问题的概括，它抽取于某一特定目标相关的本质内容而忽略其非本质内容。

.验收准则：系统或部件必须满足的准则，其目的是用户、客户或其他授权实体能够予以接受。

.验收测试：确定一系统是否符合其验收准则，使客户能确定是否接收此系统的正式测试。

.活动：一个过程的组成元素。对基线的变更要经有关机构的正式批准。

.活动图：用于对涉及一个或多个类目的进程建模的状态机的一种特例。

.适应性：使不同的系统约束条件和用户需求得到满足的容易程度。

.关联：规定其实例件连接的多个类目之间的语义联系。

.审计：为评估工作产品或工作产品集是否符合软件需求、规格说明、基线、标准、过程、指令、代码以及合同和特殊要求而进行的一种独立检查。

.可用性：软件（系统或部件）在投入使用时可操作和可访问的程度或能实现其指定的系统功能的概率。

.基线：业已经过正式审核与同意，可以作下一步开发的基础，并且只能通过正式的修改管理工程方能加以修改的规格说明或产品。在配置项目生存周期的某一特定时间内，正式指定或固定下来的配置标识文件。基线加上根据这些基线批准同意的改动构成了当前配置标识。对于配置管理，有三种基线：功能基线（最初通过的功能配置）、分配基线（最初通过的分配的配置）、产品基线（最初通过的或有条件地通过的产品配置）。

.边界值：相应于为系统或部件规定的最小或最大的输入、内部、输出的数据值。

.代码审计：由某人、某小组或借助某种工具对源代码进行的审查，目的是验证其是否符合软件设计文件和程序设计标准，还可能对正确性和有效性进行估计。

.代码评审：把软件代码呈现给项目人员、管理人员、用户、客户或其他感兴趣的人员用于评论或批准的会议。

.数据字典：软件系统中使用的所有数据项的名字及与这些数据项有关的特性（例如数据项长度、表示等）的集合。

.依赖：两个建模元素之间的一种关系，对其中一个建模元素（独立元素）的更改，将影响另一建模元素（依赖元素）。

.验证：确定软件开发周期中的一个给定阶段的产品是否达到在上一阶段确立的需求的过程。

.确认：在软件开发过程结束时对软件进行评价以确定它是否和软件需求相一致的过程。

.测试：通过执行程序来有意识地发现程序中的设计错误和编码错误的过程。测试是验证和确认的手段之一。

.软件开发方法：是指软件开发过程中所遵循的办法和步骤。软件开发活动的目的是有效地得到一些工作产物，也就是一个运行的系统及其支持文档，并且满足有关的质量要求。

.鉴定：是一个正式的过程，通过这个过程决定产品是否符合它的规格说明，是否可在目标环境中使用。

生命周期

IT服务生命周期由规划设计（Planning&Design）、部署实施（Implementing）、服务运营（Operation）、持续改进（Improvement）和监督管理（Supervision）5个阶段组成，简称“PIOIS”。

（1）规划设计：从客户业务战略出发，以需求为中心，参照ITSS对IT服务进行全面系统的战略规划和设计，为IT服务的部署实施做好准备，以确保提供满足客户需求的IT服务。

（2）部署实施：在规划设计基础上，依据ITSS建立管理体系、部署专用工具及服务解决方案。

（3）服务运营：根据IT服务部署情况，依据ITSS，采用过程方法，全面管理基础设施、服务流程、人员和业务连续性，实现业务运营与IT服务运营的全面融合。

（4）持续改进：根据IT服务运营的实际情况，定期评审IT服务满足业务运营的情况，以及IT服务本身存在的缺陷，提出改进策略和方案，并对IT服务进行重新规划设计和部署实施，以提高IT服务质量。

（5）监督管理：本阶段主要依据ITSS对IT服务质量进行评价，并对IT服务供方的服务过程、交付结果实施监督和绩效评估。

题号导航 2015年上半年信息系统项目管理师上午试卷综合知识

本试卷我的完整做题情况



	第13题在手机中做本题