系统分析师第8章 软件工程 软件开发模型之统一过程UP和RUP

系统分析师第8章 软件工程 软件开发模型之统一过程UP和RUP思维导图。软件开发模型(Software Development Model)是指软件开发全部过程、活动和任务的结构框架。软件开发包括需求、设计、编码和测试等阶段，有时也包括维护阶段。 软件开发模型能清晰、直观地表达软件开发全过程，明确规定了要完成的主要活动和任务，用来作为软件项目工作的基础。

软件工程

• 8.3 软件开发模型
  • 8.3.3 统一过程 UP和RUP
    • 统一过程（Unified Process，UP）
      • 是一个通用过程框架，可以用于
        • 种类广泛的软件系统
        • 不同的应用领域
        • 不同的组织结构
        • 不同的性能水平
        • 不同的项目规模
      • UP是基于构件的
        • 构件是物理上或可替换的系统部分，它实现了一个接口集合
        • 一个构件集合一般来说位于一个节点，但有可能从一个节点转到另一个节点。
        • 与构件不同的是，包纯粹是一种概念上的事物，只存在于幵发阶段，而构件可以存在于系统运行阶段。
      • 在为软件系统建模时，UP使用的是UML
      • 与其他软件过程相比，UP具有三个显著的特点，即
        • 用例驱动
        • 以架构为中心
        • 迭代和增量
      • 提供了在开发组织中分派任务和责任的纪律性方法
      • 目标是在可预见的日程和预算前提下，确保满足最终用户需求的高质量产品
      • 对所有的关键开发活动，它为每个团队成员提供了
        • 使用准则
        • 模板
        • 工具指导
      • 通过对相同基础知识的一致理解，使在进行
        • 需求分析
        • 设计
        • 测试
        • 配置管理
        • 等工作时，均能确保全体成员共享相同的
          • 知识
          • 过程
          • 开发软件的视图
    • RUP（Rational Unified Process）
      • RUP概述
        • RUP是Rational公司开发和维护的过程产品，是由Objectory过程演化而来
        • RUP将
          • 项目管理
          • 业务建模
          • 分析
          • 设计
          • 等统一起来，贯穿整个开发过程
        • RUP采用Internet技术，可以
          • 增强团队的开发效率，
          • 并为所有成员提供最佳的软件实现方案，
          • 它使团队中每个开发人员的见解和思想得到统一，
          • 使开发小组成员的沟通更为容易，
          • 而这正是任何项目想要取得成功的关键因素。
        • RUP可以增强开发人员对软件的预见性，最终的好处就是提高了软件质量，并有效缩短了软件从开发到投放市场的时间
        • RUP过程为软件开发提供了规范性的指南、模板和范例，可用来开发所有类型的应用。
        • RUP的软件过程在时间上被分解为4个顺序的阶段
          • 初始阶段
          • 细化阶段
          • 构建阶段
          • 交付阶段
          • 每个阶段结束时都要安排一次技术评审，以确定这个阶段的目标是否已经满足。如果评审结果令人满意，就可以允许项目进入下一个阶段。
        • 基于RUP的软件过程
        • 基于RUP的软件过程是一个迭代过程
          • 通过初始、细化、构建、移交4各阶段就是一个开发周期，每次经过4各阶段就会产生一代软件。
          • 除非产品退役，否则通过重复同样的四个阶段，产品将演化为下一代产品，但每一次的侧重点都将放在不同的阶段上。
        • 引发演化过程的几种情况
          • 用户需求的变化
          • 运行环境的变更
          • 基础技术的变更
          • 演化过程
            • 通常情况下，演化过程的初始阶段和细化阶段都比较简单，因为基本产品定义和架构在前面的开发过程中就已经决定。
            • 但也有例外情况，例如，对软件架构进行重新定义的演化过程
      • 初始阶段
        • 任务：为系统建立业务模型并确定项目的边界
        • 在初始阶段，必须识别所有与系统交互的外部实体，定义系统与外部实体交互的特征。
        • 在这个阶段中，所关注的是整个项目的业务和需求方面的主要风险。
        • 对于建立在原有系统上的开发项目来说，初始阶段可能很短。
        • cgh：使用UML用例图进行业务建模
        • 初始阶段的实现过程
          • 明确项目规模
            • 建立项目的软件规模和边界条件，包括验收标准
            • 了解环境及重要的需求和约束，识别系统的关键用例
          • 评估项目风险
            • 软件过程主要关心的是软件开发的已知风险，只能准确描述、计划、分配和评审那些已经知道将要完成的事情。
            • 风险管理则主要关心未知方面。
            • 在基于RUP的迭代式软件过程中，很多决策要受风险决定。
            • 要达到这个目的，开发人员需要详细了解项目所面临的风险，并对如何降低或处理风险有明确的策略
          • 制订项目计划
            • 估计整个项目的总体成本、进度和人员配备。
            • 综合考虑备选架构，评估设计和自制/外购/复用方面的方案，从而估算出成本、进度和资源
            • 在这个过程中，要通过对一些概念的证实来证明可行性，可以采用可模拟需求的模型形式或用于探索高风险区的初始原型。
            • 初始阶段的原型设计工作应该限制在确信解决方案可行就可以了，具体实现留到细化阶段和构建阶段。
          • 阶段技术评审
            • 初始阶段结束时要进行一次技术评审，检查初始阶段的目标是否完成，并决定是继续进行项目还是取消项目。
            • 在评审过程中，需要考虑
              • 项目的规模定义、成本和进度估算是否适中、
              • 估算根据是否可靠、
              • 需求是否正确、
              • 开发方和用户方对软件需求的理解是否达成一致、
              • 是否已经确定所有风险且有针对每个风险的规避策略
              • 等问题
      • 细化阶段
        • 细化阶段的任务
          • 分析问题领域
          • 建立完善的架构
          • 淘汰项目中最高风险的元素
        • 在细化阶段，必须在理解整个系统的基础上
          • 对架构做出决策，包括其范围、主要功能注入性能等非功能需求，
          • 同时为项目建立支持环境
        • CGH：使用UML组件图进行建模，管理系统构件
        • 细化阶段的实现过程
          • 确定架构
            • 确保架构、需求和计划足够稳定，充分减少风险，从而能够有预见性地确定开发所需的成本和开发进度。
            • 通过处理架构方面重要的场景，建立一个已确定基线的架构，并验证其将在适当时间、以合理的成本支持系统需求
          • 制订构建阶段计划
            • 为构建阶段制定详细的过程计划并为其建立基线
          • 建立支持环境
            • 包括
              • 开发环境
              • 开发流程
              • 支持构建团队所需的
                • 工具
                • 自动化/半自动化支持
          • 选择构件
            • 评估现有的构件库和潜在构件，充分了解自制/外购/复用决策，以便有把握地确定构建阶段的成本和进度。
            • 集成所选构件，并按主要场景进行评估
          • 阶段技术评审
            • 检查详细的系统目标和范围、
            • 架构的选择
            • 以及主要风险的解决方案
        • 可执行原型
          • 在细化阶段，可执行的原型依赖于项目的范围、规模、风险和先进程度。
          • 必须至少处理初始阶段中识别的关键用例，因为关键用例通常揭示了项目的主要技术风险。
      • 构建阶段
        • 在构建阶段
          • 要开发所有剩余的构件和应用程序功能
          • 把这些构件集成为产品
          • 并进行详细测试
        • 从某种意义上说，构建阶段是一个制造过程
        • 其重点放在管理资源及控制操作，以优化成本、进度和质量
        • CGH：主要使用UML构件图、活动图、类图、序列图以及部署图等进行建模
        • 构建阶段的主要任务是
          • 通过优化资源和避免不必要的保费和返工，使开发成本降到最低；
          • 完成所有所需功能的分析、开发和测试，快速完成可用的版本；
          • 确定软件、场地和用户是否已经为部署软件做好准备
        • 在构建阶段，开发团队的工作可以实现某种程度的并行。
          • 规模大的项目，产生许多并行的增量构建过程
          • 规模小的项目，也通常包括可以相互独立开发的构建，从而使各团队之间实现并行开发
        • 这些并行活动在加速版本发布的有效性的同时，也增加了资源管理和工作流同步的复杂性
        • 构建阶段结束时也要进行技术评审，评审产品是否可以在β测试环境中进行安装和运行
      • 交付阶段
        • 当基线已经足够完善，可以安装到最终用户实际环境中时，则进入交付阶段。
        • 交付阶段的重点是确保软件对最终用户是可用的。
        • 交付阶段的主要任务是
          • 进行β测试、
          • 制作产品发布版本；
          • 定稿最终用户支持文档；
          • 按用户的需求确认新系统；
          • 培训用户和维护人员；
          • 获得用户对当前版本的反馈，基于反馈调整产品，例如
            • 进行调试
            • 性能或可用性的增强等；
        • 交付阶段结束时也要进行技术评审，评审
          • 目标是否实现
          • 是否应该开始演化过程
          • 用户对交付的产品是否满意等
      • RUP的缺点
        • RUP太过于庞大和复杂，相对于轻量级的敏捷方法来说，显得死板和难以实施
        • RUP不但不能快速适应需求的变化，而且变更一个需求要经历复杂的过程和很多额外的工作
        • 对于较小的组织和项目来说，使用敏捷方法可能比较合适，而使用RUP方法似乎有些费力不讨好