【正确答案】1．简要介绍你参与管理和开发的大中型信息系统软件工程项目的基本情况，简要说明自己在该项目中的角色、所承担的主要任务及开展的主要工作。论文叙述自己参与设计和实施的软件项目应有一定的规模，自己在该项目中担任的主要工作应有一定的分量。
2．统一软件开发过程(RUP)是一种用例驱动的，以体系结构为中心、迭代和增量的软件开发过程。可以采用二维模型来描述RUP——时间和内容。从时间维来看，软件生存周期被划分为不同的循环(Cycles)。每个循环又被划分为4个连续的阶段(Phase)，每个阶段都包含一个妥善定义的里程碑(Milestone)；每个阶段还可以被进一步划分为若干轮迭代(Iterations)。一次迭代是一次完整的开发过程，每次迭代结束时会发布一个可执行的产品，这个产品是正在开发的软件系统的一个子集，它会逐渐扩展为最终系统。内容结构指的是一些将活动(Activities)组织在一起的、天然存在的规则。
1)RUP的生命周期
RUP把生命周期模型划分为初始阶段(Inception)、细化阶段(Elaboration)、构造阶段(Construction)和交付阶段(Transition)4个阶段，如表5—25所示。每个阶段结束于一个主要的里程碑(MaiorMilestones)。每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。

表5-25 RUP各阶段说明
阶段	目标	目标说明	里程碑	里程碑说明
初始阶段	确定项目开发 的目标和范围，即 确定项目的边界	为了达到该目的必须识别所有与系统交 互的外部实体，在较高层次上定义交互的特 性。在这个阶段中所关注的是整个项目进行 中的业务和需求方面的主要风险。对于建立 在原有系统基础上的开发项目来讲，初始阶 段可能很短	生命周期目标 (Lifecycle Objective)	评价项目基本的生存能力
精化阶段	确定系统架构 和明确需求。分析 问题领域，建立健 全的体系结构基 础，编制项目计 划，淘汰项目中最 高风险的元素	为了达到该目的，必须在理解整个系统的基 础上，对体系结构作出决策，包括其范围、主 要功能和诸如性能等非功能需求。同时为项目 建立支持环境，包括创建开发案例，创建模板、 准则及准备工具	生命周期结构 (Lifecycle Architecture)	为系统的结构建立了管理基 准并使项目小组能够在构建阶 段中进行衡量。此刻，要检验 详细的系统目标和范围、结构 的选择，以及主要风险的解决 方案
构建阶段	实现剩余的系 统功能，所有的功 能被详细测试	所有剩余的构件和应用程序功能被开发并 集成为产品，所有的功能被详细测试。从某种 意义上说，构建阶段是一个制造过程，其重点 放在管理资源及控制运作以优化成本、进度和 质量	初始功能 (Initial Operational)	决定了产品是否可以在测试 环境中进行部署。此刻，要确 定软件、环境及用户是否可以 开始系统的运作。此时的产品 版本也常被称为“Beta”版
移交阶段	完成软件的交 付工作，将系统移 交给客户	重点是确保软件对最终用户是可用的，该阶 段可以跨越几次迭代，包括为发布做准备的产 品测试，基于用户反馈的少量的调整。用户反 馈应主要集中在产品调整、设置、安装和可用 性问题，所有主要的结构问题应该已经在项目 生命周期的早期阶段解决了	产品发布 (Product Release)	此时要确定目标是否实现， 是否应该开始另一个开发周 期。在一些情况下这个里程碑 可能与下一个周期的初始阶段 的结束重合

2)RUP中有9个核心工作流，分为6个核心过程工作流(Core Process Workflows)和3个核心支持工作流(Core Supporting Workflows)。9个核心工作流在项目中轮流被迭代使用，在每一次迭代中以不同的重点和强度重复
(1)业务建模(Business Modeling)工作流：描述了如何为新的目标组织开发一个构想，并基于这个构想在商业用例模型和商业对象模型中定义组织的过程、角色和责任。
(2)需求(Requirements)工作流：描述系统应该做什么，并使开发人员和用户就这一描述达成共识。为了达到该目标，要对需要的功能和约束进行提取、组织和文档化；最重要的是理解系统所解决问题的定义和范围。
(3)分析和设计(Analysis或Design)工作流：将需求转化成未来系统的设计，为系统开发一个健壮的结构并调整设计使其与实现环境相匹配，优化其性能。分析设计的结果是一个设计模型和一个可选的分析模型。
(4)实现(Implementation)工作流：以层次化的子系统形式定义代码的组织结构，以组件的形式(源文件、二进制文件或可执行文件)实现类和对象，将开发出的组件作为单元进行测试，并集成由单个开发者(或小组)所产生的结果，使其成为可执行的系统。
(5)测试(Test)工作流：检验对象间的交互作用，验证软件中所有组件的正确集成，检验所有的需求已被正确的实现，识别并确认缺陷在软件部署之前被提出并处理。
(6)部署(Deployment)工作流：软件打包、生成软件本身以外的产品、安装软件，以及为用户提供帮助等。成功的生成版本并将软件分发给最终用户。该工作流描述了那些与确保软件产品对最终用户具有可用性相关的活动。
(7)配置和变更管理(Configuration或Change Management)工作流：描述了如何管理并行开发、分布式开发、如何自动化创建工程，以及对产品修改原因、时间和人员保持审计记录。该工作流提供了准则来管理演化系统中的多个变体，跟踪软件创建过程中的版本。
(8)项目管理(Project Management)工作流：为项目的管理提供框架，为计划、人员配备、执行和监控项目提供实用的准则，为管理风险提供框架等。软件项目管理平衡各种可能产生冲突的目标，管理风险，克服各种约束并成功交付使用户满意的产品。
(9)环境(Environment)工作流：向软件开发组织提供软件开发环境，包括过程和工具。该工作流集中于配置项目过程中所需要的活动，同样也支持开发项目规范的活动，提供了逐步的指导手册并介绍了如何在组织中实现过程。
3)关于RUP迭代计划的安排，通常有以下4种典型的策略模式
(1)增量式(Incremental)。该模式的特点是项目架构的风险较小(往往是开发一些重复性的项目)，所以精化阶段只需要一个迭代。但项目的开发工作量较大，构建阶段需要有多次迭代来实现，每次迭代都在上一次迭代的基础上增加实现一部分的系统功能。
(2)演进式(Evolutionary)。当项目架构的风险较大时(从未开发过类似项目)，需要在精化阶段通过多次迭代来建立系统的架构，架构是通过多次迭代的探索，逐步演化而来的。当架构建立时，往往系统的功能也已经基本实现，所以构建阶段只需要一次迭代。
(3)增量提交(Incremental Deliveq)。该模式的特点是产品化阶段的迭代较多，比较常见的例子是项目的难度并不大，但业务需求在不断地发生变化，所以需要通过迭代来不断地部署完成的系统；但同时又要不断地收集用户的反馈来完善系统需求，并通过后续的迭代来补充实现这些需求。
(4)单次迭代(Grand Design)。传统的瀑布模型可以看做是迭代化开发的一个特例，整个开发流程只有一次迭代。但这种模式有一个固有的弱点，由于它对风险的控制能力较差，往往会在产品化阶段产生一些额外的迭代，造成项目的延误。
4)结合项目实践经验，说明在你参与管理和开发的软件项目中如何应用RUP，在项目实施过程中遇到了什么问题，采用了哪些技术、方法和步骤来解决相关的问题，以及它们对该工程项目后期的工作产生了哪些积极(或消极)的影响(效果和存在的问题)。对所提出的问题，应有具体的着眼点，不能泛泛而谈。
3．RUP是一个通用的过程模板，包含了很多开发指南、制品，以及开发过程所涉及的各种角色说明。RUP非常庞大，没有一个项目会使用RUP中的所有东西，针对具体的开发机构和项目，应用RUP时还要做裁剪，即要对RUP进行配置。RUP就像一个元过程(meta-process)，通过对RUP进行裁剪可以得到很多不同的开发过程，这些软件开发过程可以看做RUP的具体实例，以适应于不同的开发机构和项目需求。针对一个具体的软件项目，RUP裁剪可以分为以下几个步骤。
(1)确定本项目需要哪些工作流。RUP的9个核心工作流并不总是需要的，可以根据项目的规模、类型等对核心工作流做一些取舍。例如，嵌入式软件系统项目通常不需要业务建模这一工作流。
(2)确定每个工作流要产出哪些制品。例如，规定某个工作流应产出哪些类型的文档。
(3)确定生命周期的4个阶段之间如何演进。确定阶段间演进要以风险控制为原则，决定每个阶段要执行哪些工作流，每个工作流执行到什么程度，产出的制品有哪些，每个制品完成到什么程度等。
(4)确定每个阶段内的迭代计划。规划RUP的4个阶段中每次迭代开发的具体内容有哪些。
(5)规划工作流内部结构。工作流不是活动的简单堆积，它涉及角色、活动及制品，其复杂程度与项目规模及角色多少等因素有关。通常用活动图的形式给出所规划的工作流的内部结构。这一步决定裁剪后的RUP要设立哪些角色，是对RUP进行裁剪的难点。
结合RUP裁剪步骤的相关知识，分析与评估你在所参与项目中应用RUP裁剪的实际开发效果。注意要给出具体的评价依据，评价要客观、适当。论文最后可以进一步讨论你在该工程项目中获得的、应用RUP方面的几点经验体会，以及在今后的工作过程中，如果碰到类似的开发项目你将如何应用这些经验或教训。