系统分析与设计作业2

1 模型对比

1. 瀑布模型

【优点】
- 开发具有阶段性，当前一阶段完成后，您只需要去关注后续阶段
- 基本可确定何时交付产品及进行测试，为项目提供了按阶段划分的检查点
- 可在迭代模型中应用瀑布模型。
【缺点】
- 开发过程一般不能逆转，否则代价太大
- 实际的项目开发很难严格按该模型进行，而往往在项目开发最初阶段很难清楚地给出所有的需求
- 软件的实际情况必须到项目开发的后期才能看到，这要求客户有足够的耐心
- 不能反映出开发过程的反复性和迭代特性，无任何类型的风险评估，出现或隐藏的问题直到开发后期才会显露，失去了及早纠正错误或缺陷机会

2. 增量模型

【优点】
- 人员分配灵活，刚开始不用投入大量人力资源。
- 如果核心产品很受欢迎，则可增加人力实现下一个增量。
- 可先发布部分功能给客户，能够在较短的时间内向用户提交一些有用的工作产品，解决用户的一些急用功能
- 在开发过程中，需求的变化是不可避免的。增量模型就更加灵活

【缺点】
- 由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构
- 增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，从而是软件过程的控制失去整体性。

3. 螺旋模型

【优点】
- 设计上的灵活性,可以在项目的各个阶段进行变更。
- 以小的分段来构建大型系统,使成本计算变得简单容易；
- 客户始终参与每个阶段的开发,保证了项目不偏离正确方向以及项目的可控性；
- 随着项目推进,客户始终掌握项目的最新信息 , 从而他或她能够和管理层有效地交互。

【缺点】
- 要求开发人员要擅长寻找可能的风险，准确地分析风险。
- 强调风险分析，但要求许多客户接受和相信这种分析，并做出相关反应是不容易的。一般用于内部大规模软件开发。
- 建设周期长。

2 UP 的三大特点以及内容体现

UP的三大特点：用例驱动、以体系结构为核心、迭代及增量。

• 用例驱动: 用例驱动意味着开发团队使用通过代码和测试收集需求的用例。在项目早期通过用例来开发，所以这体现了用户驱动的开发。
• 以体系结构为核心: 强调在开发过程的早期，识别出软件与软件的体系结构紧密相关的用例，并通过对这些用例的分析、设计、实现和测试，形成体系结构框架，提供了所有其他发展演变的中心点。基于独立的、可替换的、模块化组件的体系结构有助于管理复杂性，提高重用率。这有助于设计一个有弹性的、能适应变化的、易于理解的、有助于重用的软件体系结构
• 迭代式的增量开发: 迭代和进化的方法允许用不完整的，不完善的知识开始开发。这体现了风险驱动的开发。 系统在迭代过程中逐步趋向稳定，有效管理需求变化

3 UP 四个阶段的划分准则和关键里程碑

四个阶段是初始阶段、细化阶段、构建阶段和交付阶段。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话，可以允许项目进入下一个阶段

1. 初始阶段 ：包括用户沟通和计划活动两个方面，强调定义和细化用例，并将其作为主要模型。
   里程碑：是评价项目基本的生存能力，包括一些 重要的文档，如:项目构想、原始用例模型、原始业务风险评估、一个或者多个原型、原始业务案例等。需要对这些 文档进行评审，以确定正确理解用例需求、项目风险评估合理、 阶段计划可行等。
2. 细化阶段 ：细化阶段主要目标是减轻直到本阶段结束时分析确定的关键风险项目。细化阶段是项目开始形成的地方。在这个阶段进行问题域分析，并且项目的体系结构得到它的基本形式
   里程碑：包括风险分析文档、软件体系结构基线、项目计划、可执行的进化原型、初始版本的用户手册等。通过评审确定软件体系结构已经稳定、高风险的业务需求和技术机制已经解决、修订的项目计划可行等
3. 构建阶段 ：主要目标是构建软件系统。 在这个阶段，主要关注于系统组件和其他功能的开发。 这是大部分编码发生的阶段。 在较大的项目中，可能会开发几个构建迭代，以便将用例划分为可管理的段，以生成可证明的原型。
   里程碑：包括可以运行的软件产品、用户手册等，它决定了产品是否可 以在测试环境中进行部署。此刻，要确定软件、环境、用户是 否可以开始系统的运行。
4. 交付阶段：将产品发布给用户进行测试评价，并收集用户的意见，之后再次进行迭代修改产品使之完善。
   里程碑：确定最终目标是否实现，是否应该开始产品下一个版本的另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的相重合

4 在合同固定条件下，为什么说IT 项目管理中“范围/内容”是项目团队是易于控制的

工期是在合同中确定好的，质量也是双方协商和规定了项目的验收条件，而范围/内容则是团队真正可以控制的。对于范围/内容而言，则主要关注的是实现的语言，实现的架构和实现的方式。在保证了工期和质量的前提下，如何实现，怎么实现这个IT项目其实不是用户关注的主要点上，IT项目团队可以根据团队实际情况和现有的经验调研，合理地选择自己实现功能的方式以及组件内容，所以说这个对于项目团队来说是易于控制的。

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

UP将软件的生命周期划分为四个阶段，每个阶段终结于良好定义的里程碑，并且开发被组织成一系列固定的短期小项目，称为迭代，每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试活动。因此，在每次迭代完成后，都有一定的产品可供发布。每个阶段又有自己明确的目标，例如初始化阶段是为系统建立商业案例以及确定项目的边界，而细分阶段是为了分析问题领域，建立健全的体系结构基础等；以及核心工作流当中的 9 个核心的过程工作流，保证了企业能够按固定节奏生产，固定周期发布软件产品。

6 团队KANBAN

这个是小组每日的汇报

Screenshot-2018-3-22 Build software better, together.png

这个是前端团队的第一次迭代计划

Screenshot-2018-3-22 Build software better, together(1).png

前端团队kanban

Screenshot-2018-3-22 rookies-sysu Order-System-Frontend.png