系统分析与设计Lesson2

作业

简答题

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

瀑布模型

优点：
- 降低软件开发的复杂程度，提高软件开发过程的透明性，提高软件开发过程的可管理性。
- 推迟软件实现，强调在软件实现前必须进行分析和设计工作。
- 以项目的阶段评审和文档控制为手段有效地对整个开发过程进行指导，保证了阶段之间的正确衔接，能够及时发现并纠正开发过程中存在的缺陷，从而能够使产品达到预期的质量要求。

缺点：
- 强调过程活动的线性顺序。
- 缺乏灵活性，特别是无法解决软件需求不明确或不准确的问题。
- 风险控制能力较弱。
- 瀑布模型中的软件活动是文档驱动的，当阶段之间规定过多的文档时，会极大地增加系统的工作量；而且当管理人员以文档的完成情况来评估项目完成进度时，往往会产生错误的结论。

---

增量模型

优点：
- 增强客户对系统的信心。
- 降低系统失败风险。
- 提高系统可靠性、稳定性和可维护性。

缺点：
- 增量粒度难以选择。
- 确定所有的基本业务服务比较困难。

---

螺旋模型（含原型方法）
优点：
- 设计上比较灵活。
- 可以在项目的各个阶段进行变更。
- 成本计算变得简单容易。

缺点：
- 螺旋模型强调风险分析，但说服外部客户接受和相信分析结果并做出相关反应并不容易，因此螺旋模型往往比较适合内部的大规模软件开发
- 风险分析需要相当的成本耗费，因此螺旋模型只适合于投资较大的规模软件项目。
- 失误的风险分析可能带来更大的风险。

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

三大特点：
1. 用例驱动
2. 以架构为中心
3. 迭代式增量开发

体现用户驱动的开发：1. 用例驱动 3. 迭代式增量开发
体现风险驱动的开发：2. 以架构为中心

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

UP中的软件生命周期在时间上被分解为四个顺序的阶段：初始阶段(Inception)、精化阶段(Elaboration)、构建阶段(Construction) 和产品交付阶段(Transition)。

每个阶段结束于一个主要的里程碑(Major Milestone)，并在阶段结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段。

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

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

精化阶段/细化阶段
- 目标：分析问题领域，建立健全的体系结构基础，编制项目计划，完成项目中高风险需求部分的开发。

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

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

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

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

- 里程碑：产品发布(Product Release)里程碑。此时，要确定最终目标是否实现，是否应该开始产品下一个版本的另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的相重合。
——from 蔡老师ppt

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

工期是事先确定好且在合同中规定，工期规定项目中各部分具体的完成时间，不能随意调整。

项目质量在合同中已严格规定，验收条件不可能由项目团队控制。

范围/内容可根据软件开发过程中的实际情况稍加修改、完善。

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

UP中的软件生命周期在时间上被分解为四个顺序的阶段，每个阶段结束于一个主要的里程碑(Major Milestone)，并在阶段结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段，因此可以说UP为固定节奏生产软件产品提供了依据。

UP是一个风险驱动的生命周期模型，为了有效地控制风险，UP采用了迭代增量建模思想。高风险因素集中在前两个阶段解决，特别是体系结构级的风险在细化阶段就得到了解决，及早降低了系统风险。每一次迭代都包括需求、设计、实施、部署和测试活动，因此，每一个中间产品都得到了集成测试，而且这个集成测试是在一个统一的软件体系结构指导下完成的。由于中间版本的产品是逐步产生的，而且核心功能和性能需求已经包含在前面的版本中，因此可以说UP为固定周期发布软件产品提供了依据。

项目管理使用

• 团队任务 Kanban