软件项目跟踪与勘察

软件项目跟踪与勘察的目的在于建立实际进度的适当可见度，以便管理人员在软件项目的执行极大偏离软件计划时采取有效的措施。

目标 1：对比软件计划追踪实际结果和性能。

如软件项目规划一节所述，Rational Unified Process 有几个级别的项目计划和一个状态评估报告。状态评估报告对比计划与实际的结果，从而进行评估。为特定里程碑生成状态评估报告是项目经理的职责。

主要的 Rational Unified Process 里程碑对应着一个阶段（先启、精化、构建或产品化）的结束，有明确指定的完成标准。一个阶段的每次迭代结束时，在次要的里程碑处都存在复审的机会，这也是决策点，是未来发展方向的经验教训。

例如，精化阶段的目标是分析问题领域，建立一个坚固的构架基础，制定项目计划，消除项目中的风险最高的元素。必须对整个系统有了理解之后，才能做出构架决策。这就暗示着在描述大部分用例时会考虑一些约束：补充需求。为验证构架，实施一个系统，来证明所选构架是正确的，并执行意义重大的用例。

在精化阶段结束时，检查详细的系统目标和规模，以及选择的构架和确定的主要风险。当实际结果和性能极大地偏离软件计划时，采取纠正措施，并管理至项目结束。

风险列表是一个 Rational Unified Process 工件，它概括了项目中所有已知风险，并作为规划和项目评估的输入。每个风险都根据它的影响和应急计划来进行描述，应急计划是为降低风险而制定的。风险列表与业务案例一起制定，它们形成了“执行”或“不执行”项目的决策基础。风险列表在项目的整个生命周期都要进行维护。

目标 2：软件承诺的变更得到受影响的小组和个人的同意。

如 Rational Unified Process 所述，受控的迭代式开发流程确保涉众能经常看到项目进展情况以及为了保持项目不偏离轨道所作的任何必要的变更。提议的变更由变更控制委员会 (CCB) 进行复审，确保变更符合现实的，并且可以被项目的整体日程接受。

Goal-3: Changes to software commitments are agreed to by the affected group and individuals.

The controlled iterative development process, as described in the Rational Unified Process, ensures that stakeholders get regular visibility into project progress and any changes that may be necessary to keep the project on track. Proposed changes are reviewed by a Change Control Board (CCB) to ensure they are realistic and can be accommodated into the overall project schedule.

软件分包管理

分包管理的目的在于选择合格的软件分包商并对他们进行有效的管理。它综合考虑了需求管理、软件项目规划、软件项目跟踪与勘察等的基本管理控制，以及软件质量保证和软件配置管理之间的必要协调，并在适当时候对分包商施以控制。

目标 1：由主承包商选择合格的软件分包商。

目标 2：主承包商和软件分包商同意彼此承担的义务。

目标 3：主承包商和软件分包商保持连续不断的交流。

目标 4：主承包商针对其承诺追踪软件分包商的实际结果和执行情况。

这些目标超出了 Rational Unified Process 当前的范围，并且依赖于组织的具体情况。尽管 Rational Unified Process 并未对项目分包作明确说明，但它的工具、技术和机制都是以向下流动到分包商为前提的，因此流程仍属同类。

所有的分包决策都应该记录在商业理由中。与主承包商执行同一开发计划的分包商还参与技术交换、主要里程碑和状态评估等活动。

软件质量保证

软件质量保证的目的是为管理人员提供软件项目所用流程和正在构建的产品的可见度。软件质量保证是大多数软件工程和管理流程的一个构成部分。

Rational Unified Process 认为“质量”是所有项目员工共同的责任，它并非由组织本身体现出来。

目标 1：计划软件质量保证活动。

软件质量保证的规划是组织的一个责任。然而，Rational Unified Process 有许多属性用来塑造一个有效的项目质量保证计划。

每个 Rational Unified Process 里程碑都有特定的完成标准，这些标准可作为审计的基础。Rational Unified Process 中的每个活动都有一个单独的复审活动。每次复审都有一组检查点与之相关，它们代表了在进入下一个活动之前必须“通过”的“关口”。

Rational Unified Process 提供有关谁应该复审给定工件的指南。例如，设计员执行的“对象分析”的结果需要由一个独立的构架设计师、设计员、用例设计员和设计复审员来进行复审。如果有已定义的 Rational Unified Process 和工件复审标准，产品质量密切相关的目标实体应该能够轻松地评估是否遵守流程以及是否符合开发标准及指南。

目标 2：客观地验证软件产品及活动是否遵守适用的标准、过程和需求。

该目标可以通过挑选组织的质量保证人员来实现。.然而，Rational Unified Process 提供了必要的复审清单和文档模板，它们可作为项目标准。

目标 3：将软件质量保证活动和结果通知受影响的小组和个人。

如软件项目规划所述，Rational Unified Process 的目标之一是确保各方的期望同步并且保持一致。除根据质量审计结果提供的输入之外，Rational Unified Process 还需要关于资源（员工配备和财政）、首要十大风险、用指标进行衡量的技术进展以及主要里程碑结果等的报告。Rational Unified Process 指标计划提供了关于以下指标集合的指南：

• 进度（代码行、类、每次迭代的功能点）
• 稳定性（返工类型、易变性）
• 适应性（返工成本）
• 模块度（返工影响范围）
• 质量（缺陷发现频率、密度、继承深度）
• 成熟程度（每次故障的测试时间）
• 资源耗费配置文件（计划的与实际的）

目标4：在软件项目内无法解决的非兼容性问题由高级管理层负责处理。

这超出了 Rational Unified Process 的范围，属于组织的职责范畴。然而，Rational Unified Process 里描述的变更控制流程可以驱动某个机制，藉此记录非兼容性的问题并可以记录下来并向上提交以便解决。

软件配置管理

软件配置管理的目的是在项目的整个软件生命周期内建立并维护软件项目产品的完整性。软件配置管理是大多数软件工程和管理流程的一个构成部分。

目标 1：计划软件配置管理活动。 如 Rational Unified Process 所述，可靠的配置管理是受控的迭代式开发方法中一个必不可少的元素。既然软件是分阶段演进的，因此以前开发的软件版本可以用于后续开发是非常重要的。在每一阶段规划如何开发指导性软件是 Rational Unified Process 的核心。

Rational Unified Process 有两个主要手段，用于规定如何维护项目的软件开发资产以及如何集成这些资产：

• 配置管理计划
• 集成构建计划

在先启阶段启动的配置管理计划描述以下内容：

• 管理软件的版本化和处理
• 保存指定的 Rational Unified Process 模型，将它们分成多个配置项
• 使用变更控制方法管理变更和发布

集成构建计划提供了关于待构建的配置项的详细信息以及它们在某个特定的迭代中的集成顺序。

目标 2：确定、控制所选的软件工作产品，并使之可用。

Rational Unified Process 配置管理计划需要一个对配置控制和管理流程的说明，确保确实确定和控制工作产品，并使之可用。

目标 3：对已确定软件工作产品的变更进行控制。

Rational Unified Process 主张，项目应有一个变更控制委员会 (CCB) 和一个变更管理系统，以便有效地管理、跟踪和实施变更请求，并计算其变更成本。

目标 4：将软件基线的状态和内容通知受影响的小组与个人。

Rational Unified Process 提倡使用电子方式维护需求、设计和实施基线以及它们之间的可追踪性。基线的所有变更分别由不同级别的项目控制团队来裁定。例如，变更控制委员会 (CCB) 负责考虑需求级别的变更所带来的影响。规模较小的设计和实施变更，由相应级别的技术权威进行复审。批准、控制级别以及它们传达的方式分别在配置管理计划和软件开发计划中说明。

级别 3，已定义的

组织流程重点

组织流程重点的目的是建立软件流程活动的组织职责，这些活动提高了组织的整体软件流程能力。组织流程重点活动产生的主要结果是一组软件流程资产，这些资产在组织流程定义中有描述。如集成软件管理所述，软件项目使用这些资产。

目标 1：在组织范围内协调软件流程开发和改进活动。

Rational Unified Process 是一个迭代式流程，它依赖于在多次迭代中重新制定“同一”已定义的流程。流程制定的重复性质、状态指标的评估、以及每一阶段和迭代获得的经验教训都提供了在连续的各次迭代中调整流程的机会。

目标 2：软件流程的优缺点根据相对于流程标准进行鉴别。

Rational Unified Process 代表了一个整体软件开发流程，可对其进行定制，以便在某一类型的项目中更有效地使用它。环境工作流程提供关于如何定制 Rational Unified Process 的指南。除了技术和管理复杂性外，在项目中可用于确定流程“形状”的一些流程判别标准有：

• 业务环境（投机或者内部的合同）
• 软件开发工作量的大小
• 创新程度
• 应用类型

目标 3：计划组织级别的流程开发和改进活动。

该级别 3 目标完全依赖于采用该级别的组织。

组织流程定义

组织流程定义的目的在于开发和维护一套适用的软件流程资产，提高项目的流程性能，为组织提供不断积累的长期利益的基础。这些资产提供了一个通过培训等机制实现制度化的稳定基础，这在培训计划中进行说明。

目标 1：为组织开发并维护一个标准的软件流程。

Rational Unified Process 在这方面居于领先地位，用作组织的基线软件开发流程，可对其进行发展、定制和维护。

目标 2：收集、复审与软件项目使用组织的标准软件流程有关的信息，并使之可用。

这一目标需要得到采用 Rational Unified Process 的组织的支持。

培训计划

培训计划的目的在于发展个人的技能和知识，以便他们能高效地履行其职责。培训是组织的职责，但软件项目应该先确定所需要的技能，并在项目需求独特时提供必要的培训。

目标 1：计划培训活动。

这个目标只有采用 Rational Unified Process 的组织才能实现。然而，Rational Unified Process 是一个“行业最佳方案”知识库，它提供了关于如何开展各种软件开发活动的指南、概念和详细的分步说明。因此，Rational Unified Process 本身就是一个优秀的培训材料来源。

然而，Rational Unified Process 还需要相关的支持课程，包括：

• Rational Unified Process 概述，包括需求、分析设计、实施、测试、构架、流程配置、管理、工具等几个模块，以及对面向对象的介绍。
• 通过用例来实现需求管理 (RMUC)
• 面向对象的项目管理 (OOPM)
• 面向对象的设计分析 (OOAD)
• 软件质量自动化
• 配置管理
• 软件构架和迭代式流程

目标 2： 为培养履行软件管理和技术职责所需的技能和知识而提供培训。

目标 3：软件工程组和其他软件相关小组的个人接受必要的培训，以便履行其职责。

采用 Rational Unified Process 的组织需实现这些培训计划目标。然而，Rational Unified Process 提供了一系列的课程，如上节所述。

集成软件管理

集成软件管理的目的在于将软件工程和管理活动集成到一个一致、确定的软件流程中，该流程是根据组织的标准软件流程和相关流程资产定制的，这在组织流程定义中有描述。如软件产品工程所述，该定制是根据业务环境和项目的技术需要进行的。集成软件管理是从级别 2 的软件项目规划和的软件项目跟踪与勘察演进得到的。

目标 1：项目的已定义软件流程是组织标准软件流程的一个定制版本。

与 Rational Unified Process 环境工作流程一致，Rational Unified Process 的标准交付版本是可配置并且可以根据各种类型的项目调整使用规模。

目标 2：根据项目的已定义软件流程计划并管理项目。

这一目标需由采用 Rational Unified Process 的组织来说明。

软件产品工程

软件产品工程的目的是为了统一执行一个明确定义的软件工程流程，将所有的软件工程活动进行集成，以便高效地生产出正确、一致的软件产品。软件产品工程描述项目的技术活动，如需求分析、设计、代码和测试等。

目标 1：定义、集成并统一执行软件工程任务，以便生产软件。

Rational Unified Process 活动以及对每个角色需要什么的定义，在项目必备计划工件的背景下，确保确定、分配和完成任务。Rational Unified Process 内在的迭代式开发流程可以迅速证明软件开发团队的效力，并提供对最终产品的评估。

目标 2：软件产品互相保持一致。

工程模型（用例模型、设计模型、源代码和可执行构件）之间的可追踪性通过环境进行维护。

组间协作

组间协作的目的是为软件工程小组积极参与其他工程小组的工作提供一种方法，以便项目能更好地高效满足客户的需要。组间协作是集成软件管理的跨学科的方面，它超越了软件工程的范围。不但软件流程应该集成，软件工程小组与其他组的交互也必须协调和控制。

目标 1：客户的需求得到所有项目涉及的团队的同意。

使用用例而不是其他“正式”需求规约方法作为需求获取和说明的依据的一个重大好处在于，用例容易被涉众理解。同样，Rational Unified Process 用例需求获取方法代表所有涉众可以对需要执行的任务达成一致意见。这在流程中得到进一步的贯彻执行，并反映在作为软件开发基础的模型和复审中。

目标 2：工程组之间的承诺得到项目涉及的团队的认可。

这个目标需由采用 Rational Unified Process 的组织来说明。然而，Rational Unified Process 可视模型有助于人们理解产品开发各个阶段（从需求获取到部署）有什么要求。Rational Unified Process 变更和配置管理流程确保提议的变更得到适当评估，并将评估结果向所有涉众传达。

工程组确定、追踪并解决组间问题。Rational Unified Process 迭代式开发流程有助于通过连续集成所有已开发软件来及早发现软件问题。为提出和解决团队间的问题，对多个团队开发的软件进行集成时产生的问题可作为一个“公共空间”。Rational Unified Process 检测和变更请求流程支持这种观点，该流程提供了一种正式机制，用于捕获、追踪并解决项目开发问题。

平级复审

平级复审的目的是为了及早有效地排除软件工作产品的缺陷。一个重要的结果就是加深了对软件工作产品以及可以防止的缺陷的理解。平级复审是软件产品工程提出的一个重要而有效的工程方法。

目标-1：计划平级复审活动。

如在级别 2 的质量保证目标中所述，Rational Unified Process 内的每个活动都有一个独立的复审活动。

由于早期问题检测能降低整体成本，因此 Rational Unified Process 提倡“及早并经常”所有工件，尤其是关键工件进行平级复审。Rational Unified Process 提供了每一阶段、每一模型内要复审的重要特性清单。

目标 2：识别和排除软件工作产品中的缺陷。

Rational Unified Process 工件复审员需要确定用于下一个开发阶段的工件是否准备就绪。如果工件未达到复审“合格”标准，根据 Rational Unified Process 指标计划，需要获取以下方面的详细资料：

• 稳定性（返工类型、易变性）
• 适应性（返工成本）
• 模块度（返工影响范围）
• 质量（缺陷发现频率、密度、继承深度）
• 成熟程度（每次故障的测试时间）
• 资源耗费配置文件（计划的与实际的）