●统一过程是用例和风险驱动，以架构为中心，迭代的增量开发过程。(49)是一种统一过程。(49)A.RUPB．XPC．SCRUMD．水晶法

正确答案：B

正确答案：B
解析：统一过程(UP)的基本特征是“用例驱动、以架构为中心的和受控的迭代式增量开发”。一个UP可分为若干个周期，每个周期的开发过程被分为4个阶段，每个阶段可进行若干次迭代。UP将一个周期的开发过程划分为如下的4个阶段。(1)先启阶段(Inception)：该阶段的主要意图是建立项目的范围和版本，确定业务实现的可能性和项目目标的稳定性。提交结果包括原始的项目需求和业务用例。(2)精化阶段(Elaboration)：该阶段的主要意图是对问题域进行分析，建立系统的需求和架构，确定技术实现的可行性和系统架构的稳定性。提交结果包括系统架构及其相关文档、领域模型、修改后的业务用例和整个项目的开发计划。(3)构建阶段(Construction)：主要意图是增量式地开发一个可以交付用户的软件产品。(4)提交阶段(Transition)：主要意图是将软件产品提交用户。

正确答案：B,D,D

正确答案：D
解析：统一过程(United Process)是一种用例驱动的、以体系结构为核心、迭代和增量的软件过程框架，它提供了一种演进的特性。“用例驱动”指到最终产品为止的每个阶段都可以回溯到用户的真正需求。“以体系结构为核心”是指关注体系结构模式的开发，以引导后续系统，保证系统的平滑演进。

正确答案：A
解析：统一过程(United Process)是用例驱动的、以架构为核心、迭代和增量的软件过程框架，它提供了一种演进的特性。它包括迭代的软件开发、需求管理、使用基于构件的体系结构、可视化软件建模、验证软件质量和控制软件变更等内容。其中，统一过程的需求管理提供了有效需求分析的方法和步骤，它描述了如何提取、组织和文档化需要的功能及约束；如何跟踪和文档化折衷方案及决策；如何捕获和进行商业需求交流。过程中使用用例和场景来捕获功能性需求，并确保由它们来驱动设计、实现和软件的测试，使最终系统能满足最终用户的需要。同时，统一过程给开发和部署系统提供了连续的和可跟踪的线索。统一过程(UP)提供了在开发组织中分派任务和责任的纪律化方法。其目标是在可预见的日程和预算前提下，确保满足最终用户需求的高质量产品。对所有的关键开发活动，它为每个团队成员提供了使用准则、模板和工具指导。而通过对相同基础知识的一致理解，使在进行需求分析、设计、测试项目管理或配置管理等工作时，均能确保全体成员共享相同的知识、过程和开发软件的视图。

正确答案：A
    统一过程（UP）的基本特征是“用例驱动、以架构为中心和受控的迭代式增量开发”。其核心的工作流包括捕获用户需求、分析、设计、实现和测试等。首先，开发人员通过和用户的沟通、了解，捕获用户需求并制作软件用例图，从而得到软件的用例模型。然后分析并设计满足这些用例的系统，得到分析模型、设计模型和实施模型，进而实现该系统，最后通过测试模型来验证系统是否满足用况中描述的功能。需求捕获过程中得到的用例将各个核心工作流结合为一个整体，驱动整个软件开发过程。

正确答案：C

正确答案：B

正确答案：D
RUP是统一过程的商业版本，是用例和风险驱动，以架构为中心，迭代的增量开发过程。XP是一种轻量级，高校，低风险，柔性，可预测的，科学的软件开发方式，不断迭代。螺旋模型将开发过程分为几个螺旋周期，每个螺旋周期在前一个螺旋周期的基础上迭代进行开发。瀑布模型将软件生存周期各个活动规定为依线性顺序连接的若干阶段的模型。

正确答案：用例分析技术是Rational三友之一的Ivar Jacobson先生于1967年在爱立信公司开发AXE交换机时开始研究并于1986年总结、发布的一项源于实践的需求分析技术。 Ivar先生在加盟Rational之后与三友合作提出了UMI、完善了RUP用例分析技术也因此被人广泛了解和关注。 用例分析技术为软件需求规格化提供了一个基本的元素而且该元素是可验证、可度量的。用例可以作为项目计划、进度控制、测试等环节的基础。用例是开发团队与客户之间有效的沟通工具它可以用来描述功能和非功能需求其有助于确保需求的可跟踪性能够抑制过早的设计。不过值得注意的是关于用例有2个常见的误区。 (1)用例分析技术包括了整个需求过程：它只是一个需求分析技术是在传统的需求捕获技术的基础上使用的无法替代这些技术； (2)用例分析技术是分解技术：其实用例分析技术是一种合成技术将在需求捕获中收集而来的零散的特性合成为用例。 因此要清楚地认识用例源于涉众不能够自己杜撰出用例但也不要企图直接问他们还有什么用例；另外用例描述的编写工作应由开发人员和客户组成的团队完成。 总之用例来源于传统的需求捕获方法所产生的结果。通常采用迭代的方式来创建需求：首先生成提纲和高层描述(即粗略的用例模型)然后对其进行拓展和深化(即对用例模型的描述进行完善)最后进行集中的整理与修剪。用例模型的建立过程主要分为识别参与者(actor)、合并需求获得用例、细化用例描述3个步骤。 根据上面的分析可知用例是一种需求的描述方法因此用例的获取也是需求的获取因此在本篇论文的写作过程中应该充分说明如何结合用例技术来获取需求。 具体来说写作要点主要包括以下几个方面： (1)所列举的参与分析和开发的软件项目应该适合于用例分析技术而非如驱动程序之类系统参与者不明显或不重要的应用。 (2)文章中应该详细地说明获取系统用例所采用的工作步骤应该从需求的捕获开始然后详细地说明如何识别参与者如何识别用例如何进行描述的细化和模型的建立。 用例获取的基本步骤： ①定义该应用系统的边界(可以用计算机系统作为边界也可以用使用该应用系统的机构中的部门界限作为边界还可以用该机构本身作为边界)。 ②识别出该应用系统所有的参与者。 ③对于所识别出的每一个参与者分别确定； .该参与者所参与的每一种业务活动； .各种业务活动的完整的事件序列； .激发上述每一个事件序列的参与者。 ④对③中确定的事件序列进行分析去掉其中重复的事件序列。 ⑤用结构化的自然语言来描述④中确定的每一个事件序列得到初步确定的每一个用例。 ⑥对⑤中初步确定的每一个用例进行分析和必要的重组采用包含(include)、扩展 (extend)和概括(generalization)关系来表示用例之间的关系最终得到所有的用例。 (3)在描述获取系统用例的步骤时应该尽可能结合项目实际情况描述具体的过程而不要过多地列举相关书籍中内容干巴巴的理论会显得文章十分空洞要充分体现出真实性。 (4)可以充分地引入一些用例分析模式来说明用例的获取过程。 (5)文章中应该对用例获取的效果进行分析特别是对用例模型的全面性并且应该充分体现出客户在用例获取过程中的参与情况。 (6)可以适当地对用例获取的过程中的不足进行评价并提出相应的改进方法。
用例分析技术是Rational三友之一的Ivar Jacobson先生于1967年在爱立信公司开发AXE交换机时开始研究，并于1986年总结、发布的一项源于实践的需求分析技术。 Ivar先生在加盟Rational之后，与三友合作提出了UMI、完善了RUP，用例分析技术也因此被人广泛了解和关注。 用例分析技术为软件需求规格化提供了一个基本的元素，而且该元素是可验证、可度量的。用例可以作为项目计划、进度控制、测试等环节的基础。用例是开发团队与客户之间有效的沟通工具，它可以用来描述功能和非功能需求，其有助于确保需求的可跟踪性，能够抑制过早的设计。不过值得注意的是，关于用例有2个常见的误区。 (1)用例分析技术包括了整个需求过程：它只是一个需求分析技术，是在传统的需求捕获技术的基础上使用的，无法替代这些技术； (2)用例分析技术是分解技术：其实用例分析技术是一种合成技术，将在需求捕获中收集而来的零散的特性合成为用例。 因此，要清楚地认识用例源于涉众，不能够自己杜撰出用例，但也不要企图直接问他们还有什么用例；另外用例描述的编写工作，应由开发人员和客户组成的团队完成。 总之，用例来源于传统的需求捕获方法所产生的结果。通常采用迭代的方式来创建需求：首先生成提纲和高层描述(即粗略的用例模型)，然后对其进行拓展和深化(即对用例模型的描述进行完善)，最后进行集中的整理与修剪。用例模型的建立过程主要分为识别参与者(actor)、合并需求获得用例、细化用例描述3个步骤。 根据上面的分析，可知用例是一种需求的描述方法，因此用例的获取也是需求的获取，因此在本篇论文的写作过程中，应该充分说明如何结合用例技术来获取需求。 具体来说，写作要点主要包括以下几个方面： (1)所列举的参与分析和开发的软件项目应该适合于用例分析技术，而非如驱动程序之类，系统参与者不明显或不重要的应用。 (2)文章中应该详细地说明获取系统用例所采用的工作步骤，应该从需求的捕获开始，然后详细地说明如何识别参与者，如何识别用例，如何进行描述的细化和模型的建立。 用例获取的基本步骤： ①定义该应用系统的边界(可以用计算机系统作为边界，也可以用使用该应用系统的机构中的部门界限作为边界，还可以用该机构本身作为边界)。 ②识别出该应用系统所有的参与者。 ③对于所识别出的每一个参与者，分别确定； .该参与者所参与的每一种业务活动； .各种业务活动的完整的事件序列； .激发上述每一个事件序列的参与者。 ④对③中确定的事件序列进行分析，去掉其中重复的事件序列。 ⑤用结构化的自然语言来描述④中确定的每一个事件序列，得到初步确定的每一个用例。 ⑥对⑤中初步确定的每一个用例进行分析和必要的重组，采用包含(include)、扩展 (extend)和概括(generalization)关系来表示用例之间的关系，最终得到所有的用例。 (3)在描述获取系统用例的步骤时，应该尽可能结合项目实际情况，描述具体的过程，而不要过多地列举相关书籍中内容，干巴巴的理论会显得文章十分空洞，要充分体现出真实性。 (4)可以充分地引入一些用例分析模式来说明用例的获取过程。 (5)文章中应该对用例获取的效果进行分析，特别是对用例模型的全面性，并且应该充分体现出客户在用例获取过程中的参与情况。 (6)可以适当地对用例获取的过程中的不足进行评价，并提出相应的改进方法。