系统分析与设计 HW2

简述瀑布模型、增量模型、螺旋模型（含原型方法）的优缺点。

瀑布模型：

• 优点 为项目提供了按阶段划分的检查点。当前一阶段完成后，您只需要去关注后续阶段。可在迭代模型中应用瀑布模型。它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

• 缺点 各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量。由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。通过过多的强制完成日期和里程碑来跟踪各个项目阶段。瀑布模型的突出缺点是不适应用户需求的变化。

增量模型

• 优点 采用增量模型的优点是人员分配灵活，刚开始不用投入大量人力资源。如果核心产品很受欢迎，则可增加人力实现下一个增量。当配备的人员不能在设定的期限内完成产品时，它提供了一种先推出核心产品的途径。增量能够有计划地管理技术风险。

• 缺点 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析，这种模型将功能细化后分别开发的方法较适应于需求经常改变的软件开发过程。

螺旋模型（含原型方法）

• 优点 通过原型的创建，使软件开发在每个迭代的最初明确方向。通过风险分析，最大程度地降低软件彻底失败造成损失的可能性。在每个迭代阶段植入软件测试，使每个阶段的质量得到保证。整体过程具备很高的灵活性，在开发过程的任何阶段自由应对变化。每个迭代阶段累计开发成本，使支出状况容易掌握。通过对用户反馈的采集，与用户沟通，以保证用户需求的最大实现

• 缺点 过分依赖风险分析经验与技术，一旦在风险分析过程中出现偏差将造成重大损失。过于灵活的开发过程不利于已经签署合同的客户与开发者之间的协调。由于只适用大型软件，过大的风险管理支出会影响客户的最终收益。

简述 UP 的三大特点，其中哪些内容体现了用户驱动的开发，哪些内容体现风险驱动的开发？

一、用例驱动

（1）采用用例来捕获对目标系统的功能需求

（2）采用用例来驱动软件的整个开发过程，保证需求的可跟踪性，确保系统所有功能均被实现

（3）将用户关心的软件系统的业务功能实体功能模型和开发人员结合起来，提供一种贯穿整体软件生存周期的开发方式，使得软件开发的各个阶段的工作自然、一致地协调起来

二、以架构为中心的

（1）强调在开发过程的早期，识别出软件与软件的体系结构紧密相关的用例，并通过对这些用例的分析、设计、实现和测试，形成体系结构框架

（2）在后续阶段中对已形成的体系结构框架进行不断细化，最终实现整体系统

（3）在开发过程中的早期形成良好的软件体系结构，有利于对系统的理解、支持重用和有效的组织软件开发

三、受控的迭代式增量开发

（1）将软件开发分为一系列小的迭代过程，在每个得带过程中逐步增加信息、进行细化

（2）根据具体情况决定迭代的次数、每次迭代延续的时间以及迭代工作流

（3）每次迭代都选择目前对风险影响最大的用例进行，以分解和降低风险

用例驱动和受控的迭代式增量开发体现用户驱动开发，以架构为中心体现风险驱动开发。

UP 四个阶段的划分准则是什么？关键的里程碑是什么？

1、初始阶段

• 目标:为系统建立业务案例 (Business Case) 并确定项目的边界。业务案例包括项目的验收规范、风险评估、所需资源估计、阶 段计划等。确定项目边界需要识别所有与系统交互的外部实体， 并在较高层次上定义外部实体与系统交互的特性，主要包括识 别外部角色 (Actor)、识别所有用例并详细描述一些重要的用例。

• 里程碑:生命周期目标 (Lifecycle Objective) 里程碑，包括一些 重要的文档，如:项目构想 (Vision)、原始用例模型、原始业务 风险评估、一个或者多个原型、原始业务案例等。需要对这些 文档进行评审，以确定正确理解用例需求、项目风险评估合理、 阶段计划可行等。

2、精化阶段

• 目标:分析问题领域，建立健全的体系结构基础，编制项目计划，完成项目中高风险需求部分的开发。

• 里程碑:生命周期体系结构 (Lifecycle Architecture) 里程碑。包括风险分析文档、软件体系结构基线、项目计划、可执行的进化原型、初始版本的用户手册等。通过评审确定软件体系结构已经稳定、高风险的业务需求和技术机制已经解决、修订的项目计划可行等。

3、构建阶段

• 目标:完成所有剩余的技术构件和稳定业务需求功能的开发，并集成为产品，详细测试所有功能。构建阶段只是一个制造过程，其重点放在管理资源及控制开发过程以优化成本、进度和质量。

• 里程碑:初始运行能力 (Initial Operational Capability) 里程碑。 包括可以运行的软件产品、用户手册等，它决定了产品是否可 以在测试环境中进行部署。此刻，要确定软件、环境、用户是 否可以开始系统的运行。

4、产品化阶段/移交阶段

• 目标:确保软件对最终用户是可用的。产品化阶段可以跨越几次迭代，包括为发布做准备的产品测试，基于用户反馈的少量调整。

• 里程碑:产品发布 (Product Release) 里程碑。确定最终目标是否实现，是否应该开始产品下一个版本的另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的相重合。

IT 项目管理中，“工期、质量、范围/内容” 三个元素中，在合同固定条件下，为什么说“范围/内容”是项目团队是易于控制的？

工期是在合同中规定的，质量也受到甲方的约束（交付时要达到的效果是约定好的，写在合同里）。范围/内容是项目团队在具体实践中真正实现的东西，可以通过不停迭代、增量以扩大范围、完善内容等。

为什么说，UP 为企业按固定节奏生产、固定周期发布软件产品提供了依据？

因为开发过程中的每一个阶段都有固定长度，必须在时限之前完成该阶段任务（做不完就砍掉一些功能/部分）。总而言之，UP有着明确的时间限制，每一次迭代，都能有一个“新产品”出现。因此可以为企业按固定节奏生产、固定周期发布软件产品提供依据。

2、项目管理使用

• 使用截图工具（png格式输出），展现你团队的任务 Kanban，请注意以下要求 每个人的任务是明确的。即一周后可以看到具体成果

  每个人的任务是1-2项。

  至少包含一个团队活动任务。