您的位置: 首页  >  文章  >  软件生命周期模型与UP -- Homework 2

软件生命周期模型与UP -- Homework 2

分类: 文章 • 2023-10-25 18:39:28

1、简答题

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

    瀑布模型

    优点：

    1. 为项目提供了按阶段划分的检查点。
    2. 降低软件开发的复杂程度，提高软件开发过程的透明性，提高软件开发过程的可管理性。
    3. 推迟软件实现，强调在软件实现前必须进行分析和设计工作。
    4. 以项目的阶段评审和文档控制为手段有效地对分析、设计、编码、测试、交付和维护整个开发过程进行指导，保证了阶段之间的正确衔接，能够及时发现并纠正开发过程中存在的缺陷，使产品达到预期的质量要求。

    缺点：

    1. 只强调过程活动的线性顺序。由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险，并且早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。
    2. 缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。
    3. 风险控制能力较弱，无法适应用户需求的不断变化。
    4. 瀑布模型中的软件活动是文档驱动的，各个阶段的划分完全固定，当阶段之间规定过多的文档时，会极大地增加系统的工作量。
    5. 管理人员如果仅仅以文档的完成情况来评估项目完成进度，往往会产生错误的结论。

    增量模型

    优点：

    1. 每个增量可以交付一个实现了部分功能的可操作的产品给用户，增强了用户对系统的信心。
    2. 降低了系统失败和用户需求变化产生的风险。
    3. 提高了系统的可靠性、稳定性和可维护性。
    4. 人员分配灵活，刚开始不用投入大量人力资源，如果核心产品很受欢迎，可增加人力实现下一个增量。

    缺点：

    1. 增量粒度难以选择。
    2. 确定所有的基本业务服务比较困难。
    3. 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
    4. 在开发过程中，需求的变化是不可避免的。增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而使软件过程的控制失去整体性。

    螺旋模型

    优点：

    1. 设计上具有较好的灵活性，可以在项目的各个阶段进行变更。
    2. 以小的分段来构建大型系统，使成本计算变得简单容易。
    3. 客户始终参与每个阶段的开发，保证了项目不偏离正确方向以及项目的可控性。
    4. 随着项目推进，客户始终掌握项目的最新信息，从而能够和管理层有效地交互。
    5. 客户认可这种公司内部的开发方式带来的良好的沟通和高质量的产品。

    缺点：

    1. 采用螺旋模型需要具有相当丰富的风险评估经验和专门知识，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失。
    2. 过多的迭代次数会增加开发成本，延迟交付时间。

    以上三种模型都可以与原型方法结合进行使用，而与原型方法结合后，增加的优点有：

    1. 有助于增进软件人员和用户对系统服务需求的理解，减少两者之间的误解。
    2. 易于确定系统的性能，确认各项主要系统服务的可应用性，确认系统设计的可行性，确认系统作为产品的结果。
    3. 软件原型版本有的可以原封不动地成为产品，有的略加修改就可以成为最终系统的一个组成部分，有利于最终系统的建成。

    同时，与原型方法结合也会增加一定的局限性：

    1. 原型方法对于大型系统并不适用。大型系统难以进行直接的原型模拟，只能经过系统分析得到系统的整体结构。
    2. 原型方法难以构造处理大量运算、逻辑性较强的程序模块的原型。
    3. 原有应用的业务流程、信息流程混乱的情况下，原型构造与使用有一定的困难。
    4. 批处理系统的大部分活动是内部处理的，应用原型方法会有一定的困难。
    5. 原型方法还存在容易忽略文档工作、建立原型带来的资源浪费、项目规划和管理困难等问题。

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

    三大特点：

    • 用例驱动(Use Case Driven)。这个特点强调整个开发过程都要围绕用例来进行设计、编码和测试等。这样可以使得团队成员在设计、实现、测试和最终编写用户手册的过程中紧紧的以用户需求为中心。这一特点体现了用户驱动的开发。

    • 以架构为中心(Architecture-centric)。 迭代开发的实践，意味着早期迭代要致力于核心架构的构造、测试和稳定。因为没有稳定的架构就会带来高风险。这一特点体现了风险驱动的开发。

    • 迭代增量开发(Iterative and incremental)。在 UP 过程中，整个开发被组织成一系列固定的短期（如三个星期）小项目，称为迭代；每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试活动。迭代生命周期基于对经过多次迭代的系统进行持续扩展和精化，并以循环反馈和调整为核心驱动力，使之最终成为适当的系统。随着时间和一次又一次迭代的递进，系统增量式地发展完善。可见，迭代增量开发是通过不断获取用户反馈来进行调整和开发的，这一特点体现了用户驱动的开发。

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

    UP 四个阶段的划分准则是各阶段的不同里程碑，每个阶段本质上是两个里程碑之间的时间跨度。四个阶段关键的里程碑如下：

    1. 初始阶段：生命周期目标(Lifecycle Objective)里程碑。生命周期目标里程碑用于评价项目基本的生存能力。此刻，要通过慎重的分析和评价决定项目是否继续。
    2. 细化阶段：生命周期结构(Lifecycle Architecture)里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻，要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案。
    3. 构造阶段：初始功能(Initial Operational)里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻，要确定软件、环境、用户是否可以开始系统的运作。
    4. 移交阶段：产品发布(Product Release)里程碑。此时，要确定目标是否实现，是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合。

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

    在合同固定的条件下，工期已经被明确规定，这不是项目团队可以调控的；而质量是受客户监督，由客户的体验来确定的，项目团队自身无法确定质量的好坏；范围/内容是项目团队在开发过程中考虑的具体问题，受到合同和客户的约束较少，可以通过在开发过程多次迭代而进行有效控制。

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

    因为 UP 把整个软件开发组织成一系列固定周期的迭代，而每一次迭代都固定地包含各自的需求分析、设计、实现和测试活动，最终都会产生一个可执行的增量产品。因此说 UP 为企业按固定节奏生产、固定周期发布软件产品提供了依据。

2、项目管理使用

使用截图工具（png格式输出），展现你团队的任务 Kanban，请注意以下要求

  • 每个人的任务是明确的。即一周后可以看到具体成果
  • 每个人的任务是1-2项。
  • 至少包含一个团队活动任务

软件生命周期模型与UP -- Homework 2

相关推荐