降低需求变更成本，第一想到的就是原型法，后面对于已完成开发工作的的反馈意见，已完成开发工作只有增量式的吧，先开发核心的，然后发布一版，得到用户反馈再修改并开发次核心。快速原型强调的是，先生产一个原型与客户交流，然后再开发，需求变更成本降低了，但是没有已完成的开发工作；敏捷开发，也能降低变更成本，而且积极拥抱变化，但是更早的用上软件不会，他也是开发完成后再交付客户，增量是核心的开发完成交给客户，收集反馈再去优化并开发次核心。

所以选C

选项中①是开头不说了，我感觉③应该是最底层的，过程文件都是过程的，规程文件对应的是所有过程的规范，模板类肯定是整个模板的。所以我选B

正确答案选D，分析错误，这个真没接触过，考的偏了

‌CMMI软件体系文件的层次结构主要由三个部分组成：总体文件、过程文件和支撑文件。‌

• ‌总体文件‌主要描述CMMI体系的总体实施\方案，包括组织的策略方针、远景目标与阶段目标、流程概述、生命周期及裁减指南、度量系统、责任矩阵、体系文件清单等。这部分文件为整个CMMI体系提供了宏观的指导和规划。

• ‌过程文件‌以过程定义为中心，描述过程的具体活动，如什么人、什么时候、做什么事。它是整个CMMI体系的主体部分，包含了组织的标准过程中每个过程的多个活动，每个活动对应的内容详细描述了如何执行这些活动。

• ‌支撑文件‌提供具体的实施方法，包括各种各样的规程、规范、准则、指南、表格、模板、检查表和工具等。这些文件发挥了操作说明书的作用，为实施CMMI提供了具体的操作指导和工具支持。

这三个层次的文件共同构成了CMMI软件体系文件的完整结构，为组织的软件工程过程提供了全面的指导和支持‌

E -R图，选B；流程图是对某一个问题的定义、分析或解法的图形表示，比如程序流程图；数据流图DFD是在结构化分析中一种工具（需求分析阶段产生的结果），它是描述数据在系统中流动和处理的过程，是一种功能模型；数据字典顾名思义。

需求工程：需求开发和需求管理。

需求开发：需求获取-->需求分析-->需求定义(SRS)-->需求验证     --> 基线

需求管理：变更控制-->版本控制-->需求跟踪-->需求状态跟踪

题目中需求发现，再分类，然后跟客户协商，再文档化，与需求开发有点类似，先排除了B，我选D，需求规格说明就是需求定义，抽取和确认只是整个需求定义的一部分。 实际答案选C。抽取也是迭代反复的进行吧。

选A，C。第一题无关性才是主要的，计算无关性不对，不管是否实现计算都需要有的

第二题，活动图是UML图之一，描述的是一个活动到另一个活动，图的经典标志是并发分叉和并发汇合，就是途中的一根大黑色实心横线。BPMN，看着像BPM变种，BPM本来就是流程相关的；Petri网是简单的过程模型；用例图也是UML图之一，它是反应用例参与者之间的关系的。

业务流程建模标注（Business Process Modeling Notation，简称BPMN）是一套规范标准，包括这些图元如何组合成一个业务流程图（Business Process Diagram）。

选A，D，C。实际BDC。

第一题：反应结构的复杂度，结构模块数能一定程度上反应，但是只能一定程度上不全面；讲过计算环路复杂度，根据流程图来计算，就是反应代码复杂度的。

第二题：最低级的语句覆盖-->判定覆盖(分支覆盖)-->条件覆盖-->组合覆盖-->最高级的路径覆盖

第三题，排除法选C。判定表与判定树是一种列表设计工具，常用于条件嵌套的复杂判定情况的分析与设计，以及多分支结构代码的设计与实现

选D，C

验收测试是在真正交付给用户前进行的测试，测试对象整个系统，以用户为主，BC都是验收的第二第三步。

从两方面出发：业务价值和技术水平，两个极端高水平高价值的肯定保留下来，改造一下，水平低价值低直接扔了(淘汰)；价值高，技术低的，这种最好别动，集成就行；价值低，技术高的，这种可以继承下来。

这种程度只能到第二级可重复或已管理吧，因为有复合企业管理体系与流程是整个行业的了，达到第三级要达到行业标准的；第一级初始的混乱，第五级持续优化排除，第四级已管理(定量管理)也没有，只有第二级可重复(已管理)和第三级已定义，所以选B

它的意思是产品在各个生命周期的表现形式，最后出来的肯定是计算机程序，最开始的肯定是需求规格说明书，所以选B。

实际答案选D。配置项的定义，软件全生命周期文档、程序、产品等，D最全面。

需求管理：需求变更、版本控制、需求跟踪、需求状态跟踪。选A

首先排除C，都换取完成了，需求分析主要是分析可行性，建模型，优先级等等，排除，描述也不太像，所以选D。需求和元素之间的联系，需求跟踪。

选B、定义、开发、运行、维护

A是对的，B错了，以人为本，D也对。

这个得记住9个工作流。。。选C，没有成本流。

选B吧

A和D肯定是结构化的，HIPO可能是IPO的变种，也算结构化，选C

选B、D。实际B、C

耦合度：无直接-->数据-->标记-->控制-->外部-->公共-->内容   越来越高

内聚度：偶然-->逻辑-->时间-->过程-->通信-->顺序-->功能      越来越高

这个做过类似的例题，边数12

节点数：10个。

12-10+2=4。

第二种方法：判定节点数 + 1

判定节点数：3个

 3 + 1 =4；选B

A，C；A，C

软件文档是影响软件可维护性的决定因素。根据文档内容，软件文档又可分为用户文档和系统文档两类。其中，用户文档主要描述系统功能和使用方法，并不关心这些功能是怎样实现的。

A，B C

这好像是PDCA，Plan Do Check Action  计划(SRS)，开发（开发出来），核对(与用户确认)，演化(演化)，所以选D，C，C。描述功能及限制应该是SRS。

软件过程(SoftwareProcedure)是指软件生存周期所涉及的一系列相关过程。

过程是活(SoftwareProcedure) (SoftwareProcedure)动的集合；活动是任务的集合；任务起着把输入进行加工然后输出的作用。

活动的执行可以 是顺序的、重复的、并行的、嵌套的或者是有条件地引发的。软件过程是指软件整个生命周 期，包括需求获取、需求分析、设计、实现、测试、发布和维护的一个过程模型。

一个软件过程定义了软件开发中采用的方法，但软件过程还包含该过程中应用的技术方法和自动化工具。过程定义一个框架，为有效交付软件，这个框架必须创建。

软件过程构成了软件项目管理控制的基础，并且创建了一个环境以便于技术方法的采用、工作产品(模型、 (文档、报告、表格等)的产生、里程碑的创建、质量的保证、正常变更的正确管理。 )

软件过程中的活动主要由软件人员来完成，软件活动主要包括软件描述、软件开发、软件有效性验证和软件演化。其中，软件描述定义了软件功能以及使用的限制。

A，C B

第一问是对应开发过程的活动，需求分析---系统设计--实现---测试，一一对应。

B ,A  D

原话：

C，B  A，C

B，C

明显选B，面向人的非过程的。

B，C。分析：录制下动作来，然后按照动作执行，这应该是结构化的；测试输入独立再数据文件中，而不是脚本中，C贴近。

实际答案：A，C

• 线性脚本是录制手工测试的测试用例时得到的脚本；
• 结构化脚本具有各种逻辑结构和函数调用功能；
• 共享脚本是指一个脚本可以被多个测试用例使 用；
• 数据驱动脚本是指将测试输入存储在独立的数据文件中，而不是脚本中；
• 关键字驱动脚本是数据驱动脚本的逻辑扩展，用测试文件描述测试用例。

A，A

D，B

需求变更管理是需求管理的重要内容。需求变更管理的过程主要包括问题分析和变更描述、变更分析和成本计算、变更实现。具体来说，需求变更是因为需求发生变化。根据软件工程思想，需求说明书一般要经过论证，如果在需求说明书经过论证以后，需要在原有需求基础上追加和补充新的需求或对原有需求进行修改和削减，均属于需求变更。因此，需求变更必然会带来相应的问题，绝不是百利无一害的。

D，A，B

D，C；C，A

实际答案：D、B；B，A

loadrunner是测试工具；Delphi是一种语言，同时也是一种开发工具；winrunner是一种企业级的功能测试工具。

D，B

C，B。实际答案 B，C。

D；A，C。实际答案： D；A，D。

感觉它的描述像再工程，在逆向工程所获得信息的基础上，修改或重构已有的系统，产生系统的一个新版本。

A，A，C

C；A，A，D。

实际答案：C；B ,A ,D 

数据流图是从数据的角度来的来描述功能，逻辑流的，所以肯定排除；伪代码就更不是了排除。

四个独立又有联系的过程：数据、架构、人机界面(接口)、过程设计。

软件设计包括体系结构设计、接口设计、数据设计和过程设计。

• 结构设计：定义软件系统各主要部件之间的关系。
• 数据设计：将模型转换成数据结构的定义。好的数据设计将改善程序结构和模块划分，降低过程复杂性。
• 接口设计(人机界面设计):软件内部，软件和操作系统间以及软件和人之间如何通信。
• 过程设计：系统结构部件转换成软件的过程描述。

A,C 

动态测试是通过运行程序发现错误，包括黑盒测试(等价类划分、边界值分析法、错误推测法)与白盒测试(各种类型的覆盖测试)。

静态测试是人工测试方式，包括桌前检查(桌面检查)、代码走查、代码审查。

C ,A。实际答案：B，C。

软件开发环境(Software Development Environment,SDE)是指支持软件的工程化Software Development Environment SDE开发和维护而使用的一 组软件，由软件工具集和环境集成机制构成。
软件开发环境应支持多种集成机制，例如，平台集成、数据集成、界面集成、控制集成和过程集成等。---有点像企业应用集成中的平台集成。

软件开发环境应支持小组工作方式，并为其提供配置管理，环境的服务可用于支持各种软件开发活动，包括分析、设计、编程、调试和文档等。

较完善的软件开发环境通常具有多种功能，例如，软件开发的一致性与完整性维护，配置管理及版本控制，数据的多种表示形式及其在不同形式之间的自动转换，信息的自动检索与更新，项目控制和管理，以及对开发方法学的支持。

软件开发环境具有集成性、开放性、可裁减性、数据格式一致性、风格统一的用户界面等 特性，因而能大幅度提高软件生产率。
集成机制根据功能的不同，可划分为环境信息库、过程控制与消息服务器、环境用户界面三个部分。
(1)环境信息库。环境信息库是软件开发环境的核心，用以存储与系统开发有关的信息，并支持信息的交流与共享。环境信息库中主要存储两类信息，一类是开发过程中产生的有关被开发系统的信息，例如，分析文档、设计文档和测试报告等；另一类是环境提供的支持信息，例如，文档模板、系统配置、过程模型和可复用构件等。
(2)过程控制与消息服务器。过程控制与消息服务器是实现过程集成和控制集成的基础。过程集成是按照 具体软件开发过程的要求进行工具的选择与组合，控制集成使各工具之间进行并行通信和协同工作。
(3)环境用户界面。环境用户界面包括环境总界面和由它实行统一控制的各环境部件及工具的界面。统一的、具有一致性的用户界面是软件开发环境的重要特征，是充分发挥环境的优越性、高效地使用工具并减轻用户的学习负担的保证。

D ,不可能同等重要，而是份优先级的。

有点像PDCA四个活动，选D和A。

• (1)软件描述。必须定义软件功能以及使用的限制。
• (2)软件开发。也就是软件的设计和实现，软件工程人员制作出能满足描述的软件。
• (3)软件有效性验证。软件必须经过严格的验证，以保证能够满足客户的需求。
• (4)软件进化。软件随着客户需求的变化不断地改进。

A肯定不对，面向人的

B，A  B

• 软件开发工具：需求分析工具、设计工具、编码与排错工具。
• 软件维护工具：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。
• 软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件 开发工具的评价和选择。

C，D。实际是A和D

逆向工程：分析程序，然后将软件以某种更高抽象层次的表示(如比源代码高)。

它分等级：

• 实现级(语法树，符号表，过程设计)
• 结构级(分量间依赖关系，如调用图，结构图，程序和数据结构)
• 功能级(程序段功能与程序段间管辖，如数据和控制流模型)
• 领域级(分量或程序诸实体与应用领域概念间关系，如E-R模型)

重构：相同抽象层次换种描述

设计恢复：从程序恢复当时的设计，如数据设计、总计结构设计、过程设计

再工程：逆向工程基础上，然后根据这些设计信息并增加新需求，重构，产生新版本。

正向工程：恢复设计信息，然后使用这些信息改变或重构，改善质量

A

• 1、计划阶段，在计划阶段，要进行现有系统的调查整理，从移植技术、系统内容(是否进行系统提炼等)、系统运行三个方面，探讨如何转换成新系统，决定移植方法，确立移植工作体制及移植日程。
• 2、准备阶段，在准备阶段要进行移植方面的研究，准备转换所需的资料。该阶段的作业质量将对以后的生产效率产生很大的影响。
• 3、转换阶段，这一阶段是将程序设计和数据转换成新机器能根据需要工作的阶段。提高转换工作的精度，减轻下一阶段的测试负担是提高移植工作效率的基本内容。
• 4、测试阶段，这一阶段是进行程序单元、工作单元测试的阶段。在本阶段要核实程序能否在新系统中准确地工作。所以，当有不能准确工作的程序时，就要回到转换阶段重新工作。
• 5、验证阶段，这是测试完的程序使新系统工作，最后核实系统，准备正式运行的阶段。

C ,C 

A，D

郭建过程领域好像是CMM和CMMI表格的关键过程域吧；

这里有详细补充：软件架构设计师-能力成熟度模型-关键过程领域-需求跟踪能力链-工作分解结构-CSDN博客

第二题做过，A好像是6个，B明显不对，C是顺序不对，我记得老师说是选择题中选项，步骤可以少，但是顺序必须对。

过程能力成熟度模型(CMM)在软件开发机构中被广泛用来指导软件过程改进。该模型描述了 CMM

软件 处理能力的 5个成熟级别。为了达到过程能力成熟度模型的第二级，组织机构必须具有 6个

关键过程域 KPA(Key Process Areas)。故A选项错误。除了文本，每一个功能需求应该有一些相关的信息与它联系，我们把这些信息称为需求属性。对于 一个大型的复杂项目来说，丰富的属性类别显得尤为重要。例如，在文档中考虑和明确如下属性：创建需求的时间、需求的版本号、创建需求的作者、负责认可该软件需求的人员、需求状态、需求的原因和根据、需求涉及的子系统、需求涉及的产品版本号、使用的验证方法或者接受的测试标 准、产品的优先级或者重要程度、需求的稳定性。故B选项错误。 B

需求的变更遵循以下流程：

• (1) 问题分析和变更描述。这是识别和分析需求问题或者一份明确的变更提议，以检查它的有效 性，从而产生一个更明确的需求变更提议。
• (2) 变更分析和成本计算。使用可追溯性信息和系统需求的一般知识，对需求变更提议进行影响分 析和评估。变更成本计算应该包括对需求文档的修改、系统修改的设计和实现的成本。一旦分析完成并且被确认，应该进行是否执行这一变更的决策。
• (3) 变更实现。这要求需求文档和系统设计以及实现都要同时修改。如果先对系统的程序做变更，然后再修改需求文档，这几乎不可避免地会出现需求文档和程序的不一致。故C选项错误。

B ;C,D。实际答案：B；B，D。

(1)XP(Extreme Programming,极限编程)在所有的敏捷型方法中，XP 是最引人瞩目的。

它源于 Smalltalk 圈子，特别是Kent Beck 和 Ward Cunningham在20世纪 80年代末的密切合作。XP在一些对费用控制严格的公司中的使用，已经被证明是非常有效的。

  

(2) Cockburn的水晶系列方法，水晶系列方法是由 Alistair Cockburn提出的。它与XP方法一样，都有以人为中心的理念，但在实践上有所不同。Alistair考虑到人们一般很难严格遵循一个纪律约束很强的过程，因此，与XP的高度纪律性不同，Alistair探索了用最少纪律约束而仍能成功的方法，从而在产出效率与易于运作上达到一种平衡。也就是说，虽然水晶系列不如 XP那样的产出效率，但会有更多的人能够接受并遵循它。

  

(3)开放式源码，这里提到的开放式源码指的是开放源码界所用的一种运作方式。开放式源码项目有一个特别之处，就是程序开发人员在地域上分布很广，这使得它和其他敏捷方法不同，因为一般的敏捷方法都强调项目组成员在同一地点工作。开放源码的一个突出特点就是查错排障(debug)的高度并行性，任何人发现了错误都可将改正源码的“补丁”文件发给维护者。然后由维护者将这些“补 丁”或是新增的代码并入源码库。

  

(4) SCRUM。SCRUM已经出现很久了，像前面所论及的方法一样，该方法强调这样一个事实，即明确定义了的可重复的方法过程只限于在明确定义了的可重复的环境中，为明确定义了的可重复的人员所用，去解决明确定义了的可重复的问题。

  

Coad的功用驱动开发方法(FDD-Feature Driven Development)

FDD是由Jeff De Luca和大师Peter Coad提出来的。像其他方法一样，它致力于短时的迭代阶段和 可见可用的功能。在FDD中，一个迭代周期一般是两周。在FDD中，编程开发人员分成两类：首席程序员和“类”程序员(class owner)。首席程序员是最富有经验的开发人员，他们是项目的协调者、设计者和指导者，而“类”程序员则主要做源码编写。

  

ASD方法，ASD(Adaptive Software Development)方法由Jim Highsmith提出，其核心是三个非线性的、重叠的开发阶段：猜测、合作与学习。

D更贴合。实际选B。

B，B；D。实际是C，B；D

A,B,A 。实际答案A；C，A

用于描述系统中每个模块的输入，输出和数据加工的图是IPO图，而非程序流程图。

高水平，低价值，集成啊，选D

，

B，C；D

• 单元测试也称为模块测试，测试的对象是可独立编译或汇编的程序模块、软件构件或OO软件中的类(统称为模块),其目的是检查每个模块能否正确地实现设计说明中的功能、性能、接口和其他设计约束等条件，发现模块内可能存在的各种差错。单元测试的技术依据是软件详细设计说明书。
• 集成测试的目的是检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。集成测试的技术依据是软件概要设计文档。
• 系统测试的对象是完整的、集成的计算机系统，系统测试的目的是在真实系统工作环境下，验证完 整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。系统测试的技术依据是用户需求或开发合同，除应满足一般测试的准入条件外，在进行系统测试前，还应确认被测系统的所有配置项已通过测试，对需要固化运行的软件还应提供固件。
• 回归测试的目的是测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有 的、正确的功能、性能和其他规定的要求的不损害性。

根据项目规模的大小，系统方案既可以单独形成文档(系统建议方案报告、系统方案说明书),也 可以合并到可行性研究报告中。如果单独形成文档，其内容和格式与可行性研究报告也是类似的。作为一个正式文档，系统建议方案报告至少应该包含以下内容：

• (1)前置部分。包括标题、目录和摘要。摘要部分以1～2页的篇幅总结整个系统建议方案报告，提供系统方案中的重要时间、地点、人物、原因，以及系统方案是如何实现的等信息。因为多数高层管理人员没有时间读完整个报告，他们可能只阅读摘要。因此，摘要部分显得特别重要。
• (2)系统概述。包括系统建议方案报告的目的、对问题的陈述、项目范围和报告内容的叙述性解释。
• (3)系统研究方法。简要地解释系统建议方案报告中包含的信息是如何得到的，研究工作是如何进行的。例如，通过各种调查技术获取用户初步需求，通过座谈和观察获取现有系统的资料等。
• (4)候选系统方案及其可行性分析。系统阐述每个候选系统方案，并采用合适的方法进行可行性评价。
• (5)建议方案。在对各个候选系统方案进行可行性评价之后，通常会推荐一个解决方案，并且要给出推荐该解决方案的理由。
• (6)结论。简要地描述摘要的内容，再次指出系统开发的目标和所建议的系统方案。同时，需要再次强调项目的必要性和可行性，以及系统建议方案报告的价值。
• (7)附录。系统分析师认为阅读者可能会感兴趣的所有信息，但这些信息对于理解系统建议方案报告的内容来说不是必要的。

D，JRP拉一批人开会，这是获取需求。C，D。

JRP是一种相对来说成本较高的需求获取方法(而非需求分析与验证的方法),但也是十分有效的一种。它通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需 求。通常该会议的参与人数为6～18人，召开时间为1～5小时。JRP的主要意图是收集需求，而不是对需求进行分析和验证。实施JRP时应把握以下主要原则：

• (1)在JRP实施之前，应制订详细的议程，并严格遵照议程进行。
• (2)按照既定的时间安排进行。
• (3)尽量完整地记录会议期间的内容。
• (4)在讨论期间尽量避免使用专业术语。
• (5)充分运用解决冲突的技能。
• (6)会议期间应设置充分的间歇时间。
• (7)鼓励团队取得一致意见。
• (8)保证参加 JRP的所有人员能够遵守事先约定的规则。 JRP将会起到群策群力的效果，对于一些问题最有岐义的时候、对需求最不清晰的领域都是十分有用 的一种方法。这种方法最大的难度是会议的组织和相关人员的能力，要做到言之有物，气氛开放。否则，将难以达到预想的效果。

B，庞大的团队不适合，敏捷适合较小的团队

A，保持稳定，减少用户负担。A  选C

用户界面设计的3条黄金规则为：

1、让用户拥有控制权；

2、减少用户的记忆负担；

3、保持界面一致。

D  B，A。

静态分析(static analysis)是一种对代码的机械性的、程式化的特性分析方法。静态分析一般常用软 件工具进行，包括控制流分析、数据流分析、接口分析等。

用数据流图来分析数据处理的异常现象(数据异常),这些异常包括初始化、赋值、或引用数据等的序列的异常。

使用控制流图系统地检查程序的控制结构。按照结构化程序规则和程序结构的基本要求进行程序结 构检查。控制流图描述了程序元素和它们的执行顺序之间的联系。一个程序元素通常是一个条件、一个简单的语句，或者一块语句(多个连续语句)。

程序的接口分析涉及子程序以及函数之间的接口一致性，包括检查形参与实参类型、个数、维数、顺序的一致性。当子程序之间的数据或控制传递使用公共变量块或全局变量时，也应检查它们的一 致性。

D A

驱动模块是用来模拟被测试模块的上一级模块，相当于被测模块的主程序。它接收数据，将相关数 据传送给被测模块，启用被测模块，并打印出相应的结果。

桩模块(Stub)是指模拟被测试的模块所调用的模块，而不是软件产品的组成的部分。主模块作为驱动模块，与之直接相连的模块用桩模块代替。在集成测试前要为被测模块编制一些模拟其下级模 块功能的“替身”模块，以代替被测模块的接口，接受或传递被测模块的数据，这些专供测试用的“假”模块称为被测模块的桩模块。

B，A，D

检测并消除体系结构失配：体系结构失配问题由 David Garlan 等人在 1995 年提出。

失配是指在软 件复用的过程中，由于待复用构件对最终系统的体系结构和环境的假设(assumption)与实际状况 不同而导致的冲突。在构件组装阶段失配问题主要包括：

• (1)由构件引起的失配，包括由于系统对构件基础设施、构件控制模型和构件数据模型的假设存在冲突引起的失配；
• (2)由连接子引起的失配，包括由于系统对构件交互协议、连接子数据模型的假设存在冲突引起的失配；
• (3)由于系统成分对全局体系结构的假设存在冲突引起的失配等。要解决失配问题，首先需要检测出失配问题，并在此基础上通过适当的手段消除检测出的失配问题。

D，A，B

• 实现级：包括程序的抽象语法树、符号表、过程的设计表示。
• 结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构。
• 功能级：包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型。
• 领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，例如实体关A。

A,B   B ,A; C 

RUP包括四个阶段：初始阶段、细化阶段、构建阶段、交付阶段。

初始阶段的任务是为系统建立业务模型并确定项目的边界。在初始阶段，必须识别所有与系统交互的外部实体，定义系统与外部实体交互的特性。在这个阶段中，所关注的是整个项目的业务和需求方面的主要风险。

细化阶段的任务是分析问题领域，建立完善的架构，淘汰项目中最高风险的元素。在细化阶段，必须在理解整个系统的基础上，对架构做出决策，包括其范围、主要功能和诸如性能等非功能需求，同 时为项目建立支持环境。

在构建阶段，要开发所有剩余的构件和应用程序功能，把这些构件集成为产品，并进行详细测试。

 

从某种意义上说，构建阶段是一个制造过程，其重点放在管理资源及控制操作，以优化成本、进度和质量。构建阶段的主要任务是通过优化资源和避免不必要的报废和返工，使开发成本降到最 低；完成所有所需功能的分析、开发和测试，快速完成可用的版本；确定软件、场地和用户是否已 经为部署软件作好准备。

当基线已经足够完善，可以安装到最终用户实际环境中时，则进入交付阶段。交付阶段的重点 是确保软件对最终用户是可用的。交付阶段的主要任务是进行β测试，制作产品发布版本；对最终用 户支持文档定稿；按用户的需求确认新系统；培训用户和维护人员；获得用户对当前版本的反馈，基于反馈调整产品，例如，进行调试、性能或可用性的增强等。

RUP 中的每个阶段可以进一步分解为迭代。一个迭代是一个完整的开发循环，产生一个可执行 的产 RUP 品版本，是最终产品的一个子集，它增量式地发展，从一个迭代过程到另一个迭代过程到成为 最终的系统。传统上的项目组织是顺序通过每个工作流，每个工作流只有一次，也就是我们熟悉的 瀑布生命周期。

这样做的结果是到实现末期产品完成并开始测试，在分析、设计和实现阶段所遗留 的隐藏问题会大量出现，项目可能要停止并开始一个漫长的错误修正周期。

一种更灵活，风险更小的方法是多次通过不同的开发工作流，这样可以更好的理解需求，构造 一个健壮的体系结构，并最终交付一系列逐步完成的版本。这叫做一个迭代生命周期。在工作流中 的每一次顺序的通过称为一次迭代。软件生命周期是迭代的连续，通过它，软件是增量的开发。一 次迭代包括了生成一个可执行版本的开发活动，还有使用这个版本所必需的其他辅助成分，如版本 描述、用户文档等。

因此一个开发迭代在某种意义上是在所有工作流中的一次完整的经过，这些工作流至少包括：需求工作流、分析和设计工作流、实现工作流、测试工作流。其本身就像一个小型的瀑布项目。

自顶向下方法的优点是

1、可为企业或机构的重要决策和任务实现提供信息。 

2、支持企业信息系统的整体性规划，并对系统的各子系统的协调和通信提供保证。 

3、方法的实践有利于提高企业人员整体观察问题的能力，从而有利于寻找到改进企业组织的途径。

自顶向下方法的缺点是：

1、对系统分析和设计人员的要求较高。

2、开发周期长，系统复杂，一般属于一种高成本、大投资的工程。 

3、对于大系统而言自上而下的规划对于下层系统的实施往往缺乏约束力。 

4、从经济角度来看，很难说自顶向下的做法在经济上是合算的。

D

       B

• 封装性决定了面向对象系统的测试必须考虑到信息隐蔽原则对测试的影响，以及对象状态与类的测试序列，因此在测试一个类时，仅对该类的每个方法进行测试是不够的；
• 继承性决定了面向对象系统的测试必须考虑到继承对测试充分性的影响，以及误用引起的错误；
• 多态性决定了面向对象系统的测试必须考虑到动态绑定对测试充分性的影响、抽象类的测试以及误用对 测试的影响。