RUP - IBM Rational Unified Process/学科或工作流
工作流或学科（取决于 RUP 版本）分布在各个阶段和迭代中。它们被分为六个工程学科和三个支持学科。
工程学科包括业务建模、需求、分析与设计、实现、测试和部署。
业务建模解释了如何描述系统将要部署的组织的愿景，以及如何利用这种愿景作为基础来概述流程、角色和责任。
组织正在变得越来越依赖 IT 系统，这使得信息系统工程师了解他们正在开发的应用程序如何融入组织变得至关重要。企业在了解了技术的竞争优势和增值后才会投资于 IT。业务建模的目的是首先在业务工程和软件工程之间建立更好的理解和沟通渠道。了解业务意味着软件工程师必须了解目标组织（客户）的结构和动态、组织中存在的问题以及可能的改进。他们还必须确保客户、最终用户和开发人员之间对目标组织的共同理解。
需求解释了如何征集利益相关者的请求并将其转化为一组需求工作产品，这些工作产品将要构建的系统范围并提供对系统必须执行的操作的详细需求。
分析与设计的目标是展示系统将如何实现。目的是构建一个系统，该系统
- 在特定的实现环境中执行用例描述中指定的任务和功能。
- 满足其所有要求。
- 当功能需求发生变化时易于更改。
设计结果生成设计模型，分析可选地生成分析模型。设计模型充当源代码的抽象；也就是说，设计模型充当源代码结构和编写方式的“蓝图”。设计模型由结构化为包和子系统的设计类组成，这些类具有定义明确的接口，代表将在实现中成为组件的内容。它还包含有关这些设计类的对象如何协作以执行用例的描述。
实现的目的是
- 根据分层组织的实现子系统来定义代码的组织。
- 根据组件（源文件、二进制文件、可执行文件等）实现类和对象。
- 将开发的组件作为单元进行测试。
- 将单个实施者（或团队）产生的结果集成到可执行系统中。
系统是通过实现组件来实现的。该过程描述了如何重用现有组件或实现具有明确定义责任的新组件，使系统更易于维护并提高重用可能性。
测试工作流：测试的目的是评估产品质量。这不仅涉及最终产品，而且从项目的早期开始，包括对体系结构的评估，并持续到对交付给客户的最终产品的评估。测试工作流涉及以下内容
- 验证组件的交互
- 验证组件的正确集成
- 验证所有需求已正确实现
- 识别并确保在部署软件之前解决所有发现的缺陷
部署的目的是成功地生成产品发布，并将软件交付给最终用户。它涵盖了广泛的活动，包括生成软件的外部发布、打包软件和业务应用程序、分发软件、安装软件以及为用户提供帮助和支持。虽然部署活动主要集中在过渡阶段，但需要在早期阶段包含许多活动，以便在构建阶段结束时为部署做好准备。Rational Unified Process 的部署和环境工作流的细节比其他工作流少。
支持学科包括配置和变更管理、项目管理和环境。
配置和变更管理学科不仅用于跟踪版本，还用于控制变更。关键活动包括管理变更请求、管理配置和基线。
RUP 中的项目管理学科和项目规划发生在两个级别。存在一个粗粒度的阶段计划，它描述了整个项目，以及一系列细粒度的迭代计划，它描述了迭代。
它主要侧重于迭代开发过程的重要方面：风险管理、规划迭代项目（贯穿整个生命周期和特定迭代）、通过指标监控迭代项目的进度。但是，RUP 的这一学科并不试图涵盖项目管理的所有方面。
这一学科侧重于提供软件开发环境所需的活动，包括流程和工具。考虑到它可能是繁重且昂贵的学科，可以使用 IBM Rational Method Composer 来帮助简化它，以便流程工程师和项目经理可以更轻松地为他们的项目需求定制 RUP。