阅读下列说明，回答问题1至问题3，将解答填入答题纸的对应栏内。<br />【说明】<br />..

免费智能真题库 > 历年试卷 > 系统集成项目管理工程师 > 2016年上半年系统集成项目管理工程师下午试卷案例

第3题

知识点：配置管理项目进度计划变更管理测试阶段调试调试过程管理流程集成测试开发过程模板

阅读下列说明，回答问题1至问题3，将解答填入答题纸的对应栏内。
【说明】
项目经理小王目前正在负责一个小型的软件开发项目，一开始他觉得项目比较小，变更应该不多，流程也不需要太复杂，因此就没有制定项目变更计划，而是强调团队成员间的及时沟通来保证项目按照计划进行。根据项目经理小王的理解，所谓变更管理的主要目标就是保证项目能够按照计划进行，如果能够保证不发生超越项目进度计划、成本计划等控制范围外的偏差，就可以不用指定项目变更管理计划，以减少项目的工作量。而项目执行过程中对计划的微调根本不需要记录和管理，也不需要走变更管理流程。而且他认为如果所有项目变更都必须向相关领导请示汇报，过程太复杂和麻烦，还不如有执行人员提出变更的方案，彼此讨论一致后，来的更方便和便捷。
但是在项目进入到集成测试阶段的时候，突然很多莫名其妙的问题出现，如在调试过程中，由于相关设计和记录的简化和不规范，造成了调试的困难，很难定位各个问题模板的错误，由于项目执行过程中，人员的调配替换，造成了文档记录不一致，导致后期人员阅读和理解方面的障碍。并且由于缺乏对开发过程的配置管理和控制，导致版本混乱，很难形成有效支持各模板集成的文档。另外，项目中很多细小的改动，由于没有准确的记录，或者是根本没有记录，导致集成测试发现问题时，根本没有办法更改。小王对此也没有办法，不知道是因为什么导致目前状态，项目面临返工的危险。

问题：3.1 结合案例，请说明项目经理小王对项目变更管理的认识哪些是正确的？哪些是不正确的？

问题：3.2 根据你的理解，请说明项目变更管理在软件项目管理中的主要活动内容。

问题：3.3 针对项目的当前状态，小王应该采取什么补救措施？


知识点讲解
· 配置管理 · 项目进度计划 · 变更管理 · 测试阶段 · 调试 · 调试过程 · 管理流程 · 集成测试 · 开发过程 · 模板

配置管理

配置管理是为了系统地控制配置变更，在系统的整个生命周期中维持配置的完整性和可跟踪性，而标识系统在不同时间点上配置的学科。

GB/T 11457—2006中，对“配置管理”的正式定义为：“应用技术的和管理的指导和监控方法以标识和说明配置项的功能和物理特征，控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。”

项目进度计划

项目进度计划是进度模型的输出，展示活动之间的相互关联，以及计划日期、持续时间、里程碑和所需资源。项目进度计划中至少要包括每个活动的计划开始日期与计划结束日期。即使在早期阶段就进行了资源规划，在未确认资源分配和计划开始与结束日期之前，项目进度计划都只是初步的，一般要在项目管理计划编制完成之前进行这些确认。项目进度计划可以是概括（有时称为主进度计划或里程碑进度计划）或详细的。项目进度计划可以采用以下一种或多种图形来呈现。

.横道图：也称为甘特图，是展示进度信息的一种图表方式。在横道图中，进度活动列于纵轴，日期排于横轴，活动持续时间则表示为按开始和结束日期定位的水平条形。横道图相对易读，常用于向管理层汇报情况。为了便于控制以及与管理层进行沟通，可在里程碑之间或横跨多个相关联的工作包，列出内容更广、更综合的概括性活动（也叫汇总活动）。下图中的“开发和交付新产品Z”为概况性活动。

横道图（甘特图）示例

.里程碑图：与横道图类似，但仅标示出主要可交付成果和关键外部接口的计划开始或完成日期，如下图所示。

里程碑进度计划示例

.项目进度网络图：通常用节点法绘制，没有时间刻度，纯粹显示活动及其相互关系，有时也称为“纯逻辑图”，如本章第1张图所示。项目进度网络图也可以是包含时间刻度的进度网络图，有时称为“逻辑横道图”，如下1图所示。项目进度网络图的另一种呈现形式是“时标逻辑图”，也叫“时标网络图”，其中包含时间刻度和表示活动持续时间的横条，以及活动之间的逻辑关系，它用于优化展现活动之间的关系，许多活动都可以按顺序出现在图的同一行中，如下2图所示。

逻辑横道图示例

时标逻辑图示例

变更管理

变更是指在信息系统项目的实施过程中，由于项目环境或者其他的各种原因对项目的部分或项目的全部功能、性能、体系结构、技术、指标、集成方法和项目进度等方面做出改变。项目变更是正常的、不可避免的。在项目实施过程中，变更越早，损失越小；变更越迟，难度越大，损失也越大。项目在失控的情况下，任何微小变化的积累，最终都会对项目的质量、成本和进度产生较大影响，这是一个从量变到质变的过程。

变更产生的原因主要有以下几个方面：

（1）项目外部环境发生变化，例如政府政策的变化。

（2）项目总体设计、项目需求分析不够周密详细，有一定的错误或遗漏。

（3）新技术的出现，设计人员提出了新的设计方案或新的实现手段。

（4）建设单位由于机构重组等原因造成业务流程的变化。

配置库

配置库也称为配置项库，是用来存放配置项的工具。配置库记录与配置相关的所有信息，其中存放受控的配置项是很重要的内容，利用库中的信息可评价变更的后果，这对变更控制有着重要的意义。

配置库有3类：

（1）开发库（development library）。存放开发过程中需要保留的各种信息，供开发人员个人专用。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无须对其做任何限制。因为这通常不会影响到项目的其他部分。开发库对应配置管理系统中的动态系统（开发者系统、开发系统、工作空间）。

（2）受控库（controlled library）。在信息系统开发的某个阶段工作结束时，将工作产品存入或将有关的信息存入。存入的信息包括计算机可读的，以及人工可读的文档资料。应该对库内信息的读写和修改加以控制。受控库也称为主库，对应配置管理系统中的主系统（受控系统）。

（3）产品库（product library）。在开发的信息系统产品完成系统测试之后，作为最终产品存入库内，等待交付用户或现场安装。库内的信息也应加以控制。产品库也称为备份库，对应配置管理系统中的静态系统（受控系统）。

作为配置管理的重要手段，上述受控库和产品库的规范化运行能够实现对信息系统配置项的管理。

变更控制

变更控制系统是一套事先确定的修改项目文件或改变项目活动时应遵循的程序，其中包括必要的表格或其他书面文件，责任追踪，以及变更审批制度、人员和权限。变更控制系统应当明确规定变更控制委员会的责任和权力，并由所有的项目干系人认可。在审批变更时，要加强对变更风险和变更效果的评估，并选择对项目影响最小的变更方案，尽量防止增加项目投资。变更控制系统可细分为整体、范围、进度、费用和合同变更控制系统。变更控制系统应当同项目管理信息系统一起通盘考虑，形成整体。

变更控制委员会

变更控制委员会（Change Control Board, CCB）也称为配置控制委员会（Configuration Control BoarD），其任务是对建议的配置项变更做出评价、审批，以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构，可以根据工作的需要组成，其中的人员可以是全职的，也可以是兼职的。

如果CCB不只是控制变更，而是承担更多的配置管理任务，那就应该包括基线的审定、标识的审定，以及产品的审定，并且可能实际的工作需分为项目层、系统层和组织层来组建，使其完成不同层面的配置管理任务。

变更控制的流程

变更管理的基本流程如下：

（1）变更申请。应记录变更的提出人、日期、申请变更的内容等信息。

（2）变更评估。对变更的影响范围、严重程度、经济和技术可行性进行系统分析。

（3）变更决策。由具有相应权限的人员或机构决定是否实施变更。

（4）变更实施。由管理者指定的工作人员在受控状态下实施变更。

（5）变更验证。由配置管理人员或受到变更影响的人对变更结果进行评价，确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。

（6）沟通存档。将变更后的内容通知可能会受到影响的人员，并将变更记录汇总归档。如提出的变更在决策时被否决，其初始记录也应予以保存。

变更申请需要采用书面的形式提出，主要内容有如下3个方面：

（1）变更描述。包括变更理由、变更的影响、变更的优先级等，就是要申述做什么变更，为什么要做，以及打算怎么做的问题。

（2）对变更的审批。对变更的必要性、可行性的审批意见，主要是由配置管理员和CCB对此项变更把关。

（3）变更实施的信息。

利用配置库实现变更控制

配置项可以有3种状态，分别是工作状态、评审状态和受控状态。开发中的配置项尚未稳定下来，对于其他配置项来说是处于不处理工作状态下（自由状态），此时它并未受到配置管理的控制，开发人员的变更并未受到限制。但当开发人员认为工作已告完成，可供其他配置项使用时，它就开始稳定。把它交出评审，就开始进入评审状态；若通过评审，可作为基线进入配置库（实施检入），开始冻结，此时开发人员不允许对其做任意修改，因为它已处于受控状态。通过评审表明它确已达到质量要求；但若未能通过评审，则将其回归到工作状态，重新进行调整。配置项的状态变化过程如下图所示。

配置项的状态变化过程

处于受控状态下的配置项原则上不允许修改，但这不是绝对的，如果由于多种原因需要变更，就需要提出变更请求。在变更请求得到批准的情况下，允许配置项从库中检出，待变更完成，并经评审后，确认变更无误方可重新入库，使其恢复到受控状态。

测试阶段

. 可靠性测试（含于集成测试、系统测试）；

. 排错；

. 可靠性建模；

. 可靠性评价；

. 调整可靠性活动计划；

. 收集可靠性数据；

. 明确后续阶段的可靠性活动的详细计划；

. 编制可靠性文档。

调试

调试的任务就是根据测试时所发现的错误，找出原因和具体的位置，进行改正。调试主要由程序开发人员来进行，谁开发的程序就由谁来进行调试。常用的调试方法有试探法、回溯法、对分查找法、归纳法和演绎法。

调试过程

调试的过程如下图所示。首先执行设计的测试用例，对测试结果进行分析，如果有错误，需要运用调试技术，找出错误原因和具体的位置。调试结果有两个：一是能确定错误原因并进行了纠正，为了保证错误已排除，需要重新执行暴露该错误的原测试用例以及某些回归测试（即重复一些以前做过的测试）；另一种是未找出错误原因，那么只能对错误原因进行假设，根据假设设计新的测试用例证实这种推测。若推测失败，需进行新的推测，直至找到错误并纠正。通常确定错误原因和具体的位置所需的工作量在调试过程中是非常大的，大约占调试总工作量的95%，而且花费的时间也不确定。

调试过程

管理流程

信息系统软件交付之后就进入了运维阶段，该阶段短则4～5年，长则可达10年以上。运维的目的是保证信息系统软件能正常而可靠地运行，并能使系统不断得到改善和提高，以充分发挥作用。运维的过程也就是不断满足用户各种维护需求的过程。用户的维护需求是不断变化的，所以需要持续地对信息系统软件进行修改和维护。这一过程从本质上来说是一个P、D、C、A（P-Plan，策划；D-Do，实施；C-Check，检查；A-Act，处理）循环，不停顿地周而复始地运转。按照戴明质量控制理论，信息系统软件运维的管理流程如下图所示。

信息系统软件运维管理流程

信息系统软件运维服务的四个关键要素是：人员、资源、技术和过程，每个要素通过关键指标反映运维服务的能力。在运维服务提供过程中，通过应用PDCA的方法论，在运维的策划、实施、检查、改进等不同阶段，通过对人员、资源、技术和过程四个服务要素的统一管理，来实现运维服务能力的持续提升。

集成测试

集成测试也叫做组装测试或联合测试。通常，在单元测试的基础上，需要将所有模块按照概要设计说明书和详细设计说明书的要求进行组装。

. 组装时需要考虑的问题。

①在把各个模块连接起来的时候，穿越模块接口的数据是否会丢失；

②一个模块的功能是否会对另一个模块的功能产生不利的影响；

③各个子功能组合起来，能否达到预期要求的父功能；

④全局数据结构是否有问题；

⑤单个模块的误差累积起来，是否会放大，以至达到不能接受的程度。

因此，在单元测试的同时可进行集成测试，发现并排除在模块连接中可能出现的问题，最终构成要求的软件系统。

子系统的集成测试称为部件测试，它所做的工作是要找出组装后的子系统与系统需求规格说明之间的不一致。

选择什么方式把模块组装起来形成一个可运行的系统，直接影响到模块测试用例的形式、所用测试工具的类型、模块编号的次序和测试的次序以及生成测试用例的费用和调试的费用。

. 模块组装成为系统的方式。

模块组装成为系统的方式有两种：一次性组装方式和增殖式组装方式。

①一次性组装方式（big bang）。

它是一种非增殖式组装方式，也叫做整体拼装。使用这种方式，首先对每个模块分别进行模块测试，再把所有模块组装在一起进行测试，最终得到要求的软件系统。例如，有一个模块系统结构，如下图（a）所示。其单元测试和组装顺序如下图（b）所示。

一次性组装方式

在如上图（b）中，模块d1，d2，d3，d4，d5是对各个模块做单元测试时建立的驱动模块，s1，s2，s3，s4，s5是为单元测试而建立的桩模块。这种一次性组装方式试图在辅助模块的协助下，在分别完成模块单元测试的基础上，将所测模块连接起来进行测试。但是由于程序中不可避免地存在涉及模块间接口、全局数据结构等方面的问题，所以一次试运行成功的可能性并不很大。其结果是，发现有错误，却茫然找不到原因。查错和改错都会遇到困难。

②增殖式组装方式。

这种组装方式又称渐增式组装，是首先对一个个模块进行模块测试，然后将这些模块逐步组装成较大的系统，在组装的过程中边连接边测试，以发现连接过程中产生的问题。最后通过增殖逐步组装成为要求的软件系统。

. 自顶向下的增殖方式。这种组装方式是将模块按系统程序结构，沿控制层次自顶向下进行组装。其步骤如下：首先以主模块作为所测模块兼驱动模块，所有直属于主模块的下属模块全部用桩模块代替，对主模块进行测试。再采用深度优先（如下图所示为自顶向下的增殖方式）或广度优先的策略，用实际模块替换相应的桩模块，再用桩模块代替它们的直接下属模块，与已测试的模块或子系统组装成新的子系统。然后，进行回归测试（即重新执行以前做过的全部测试或部分测试），排除组装过程中引入新的错误的可能。最后，判断是否所有的模块都已组装到系统中。是，则结束测试；否则，转到B去执行。

自顶向下的增殖方式

自顶向下的增殖方式在测试过程中较早地验证了主要的控制和判断点。在一个功能划分合理的程序模块结构中，判断常常出现在较高的层次里，因而，能够较早地遇到这种问题。如果主要控制有问题，尽早发现它能够减少以后的返工，这是十分必要的。如果选用按深度方向组装的方式，可以首先实现和验证一个完整的软件功能，可先对逻辑输入的分支进行组装和测试，检查和克服潜藏的错误和缺陷，验证其功能的正确性，就为其后对主要加工分支的组装和测试提供了保证。此外，功能可行性较早地得到证实，还能够增强开发者和用户成功的信心。

. 自底向上的增殖方式。这种组装方式是从程序模块结构的最底层模块开始组装和测试。因为模块是自底向上进行组装的，对于一个给定层次的模块，它的子模块（包括子模块的所有下属模块）已经组装并测试完成，所以不再需要桩模块。在模块的测试过程中需要从子模块得到的信息可以通过直接运行子模块得到。自底向上增殖的步骤如下：首先由驱动模块控制最底层模块的并行测试；也可以把最底层模块组合成实现某一特定软件功能的簇，由驱动模块控制它进行测试。再用实际模块代替驱动模块，与它已测试的直属子模块组装成为子系统。然后，为子系统配备驱动模块，进行新的测试。最后判断是否已组装到达主模块。是，则结束测试；否则，执行B。

以如下图一（a）所示的一次性组装方式系统结构为例，可以用如下图二说明自底向上组装和测试的顺序。

一次性组装方式

自底向上的增殖方式

. 混合增殖式测试。自顶向下增殖的方式和自底向上增殖的方式各有优缺点。一般来讲，一种方式的优点是另一种方式的缺点。

自顶向下增殖方式的缺点是需要建立桩模块。要使桩模块能够模拟实际子模块的功能十分困难，因为，桩模块在接收了所测模块发送的信息后，需要按照它所代替的实际子模块功能返回应该回送的信息，这必将增加建立桩模块的复杂度，而且导致增加一些附加的测试。同时，涉及复杂算法和真正输入/输出的模块一般在底层，它们是最容易出问题的模块，到组装和测试的后期才遇到这些模块，一旦发现问题，就会导致过多的回归测试。而自顶向下增殖方式的优点是能够较早地发现主要控制方面的问题。

自底向上增殖方式的缺点是“程序一直未能作为一个实体存在，直到最后一个模块加上去后才形成一个实体”。就是说，在自底向上组装和测试的过程中，对主要的控制直到最后才接触到。这种方式的优点是不需要桩模块，而建立驱动模块一般比建立桩模块容易，同时由于涉及到复杂算法和真正输入/输出的模块最先得到组装和测试，可以把最容易出问题的部分在早期解决。此外自底向上增殖的方式可以实施多个模块的并行测试，提高测试效率。因此，通常是把以上两种方式结合起来进行组装和测试。

在进行集成测试时，测试者应当确定关键模块，对这些关键模块及早进行测试。关键模块至少应具有以下几种特征之一：

. 满足某些软件需求；

. 在程序的模块结构中位于较高的层次（高层控制模块）；

. 较复杂、较易发生错误；

. 有明确定义的性能要求。

在做回归测试时，也应该集中测试关键模块的功能。

. 集成测试的组织和实施。

集成测试是一种正规测试过程，必须精心计划，并与单元测试的完成时间协调起来。在制定测试计划时，应考虑如下因素：

①采用何种系统组装方法来进行集成测试。

②集成测试过程中连接各个模块的顺序。

③模块代码编制和测试进度是否与集成测试的顺序一致。

④测试过程中是否需要专门的硬件设备。

解决了上述问题之后，就可以列出各个模块的编制、测试计划表，标明每个模块单元测试完成的日期、首次集成测试的日期、集成测试全部完成的日期、以及需要的测试用例和所期望的测试结果。

在缺少软件测试所需要的硬件设备时，应检查该硬件的交付日期是否与集成测试计划一致。例如，若测试需要数字化仪和绘图仪，则相应的测试应安排在这些设备能够投入使用之时，并要为硬件的安装和交付使用保留一段时间，以留下时间余量。此外，在测试计划中需要考虑测试所需软件（驱动模块、桩模块、测试用例生成程序等）的准备情况。

. 集成测试完成的标志。

集成测试完成的标志主要有以下几项。

①成功地执行了测试计划中规定的所有集成测试。

②修正了所发现的错误。

③测试结果通过了专门小组的评审。

集成测试应由专门的测试小组来进行，测试小组由有经验的系统设计人员和程序员组成。整个测试活动要在评审人员出席的情况下进行。

在完成预定的集成测试工作之后，测试小组应负责对测试结果进行整理、分析，形成测试报告。测试报告中要记录实际的测试结果在测试中发现的问题、解决这些问题的方法以及解决之后再次测试的结果。此外还应提出目前不能解决、还需要管理人员和开发人员注意的一些问题，提供测试评审和最终决策，以提出处理意见。

集成测试需要提交的文档有集成测试计划、集成测试规格说明和集成测试分析报告。

开发过程

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

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

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

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

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

模板

模板是Word 2003中采用dot为扩展名的特殊文档，它由多个特定的样式组合而成，能为用户提供一种预先设置好的最终文档外观框架，也允许用户加入自己的信息。新建一个文档时，用户可以选择系统提供的模板建立文档。用户也可以自建一个新的模板。

当用户自己创建好一个文档后，若要保存为模板，只要在“另存为”对话框中选择保存类型为“文档模板（*.dot）”就可以了。使用模板的方法在如何创建一个空白文档时已经介绍，这里不再赘述。

题号导航 2016年上半年系统集成项目管理工程师下午试卷案例

本试卷我的完整做题情况



	第3题在手机中做本题