主题

决定如何执行工作流程 到页首

应就实施规程的工作流程做出以下决策:

  • 通过查看实施:工作流程,决定如何执行工作流程。研究图及其警戒条件,以及下面的指南。决定执行哪些工作流程明细,以及执行的顺序。 
  • 决定要执行实施工作流程明细的哪些部分。以下是一些可以相互相对独立地引进的部分。

工作流程的部分

注释

集成和构建管理 角色集成人员活动:计划系统集成连同工件:集成构建计划一起通常在项目早期引进。其它集成相关活动(例如活动:计划子系统集成活动:集成子系统活动:集成系统)仅在集成开始之后适时地引进。 
实施组件 角色实施者代码复审人员以及他们的活动和工件是在每个迭代中实施开始时引进的。

  • 决定在项目生命周期内何时引进工作流程的每个部分。您常常可以等到精化阶段,然后再引入整个实施规程。 任何在先启阶段进行的原型构造通常是探索性的,它的进行(例如在工件和复审方面)不如精化和构造期间整个实施工作流程所要求的那样严格。

将决策 下,作为项目特定流程的一部分。

决定如何使用工件 到页首

决定要使用哪些工件和每个工件的使用方法。下表描述您必须拥有的工件以及在某些情况下使用的工件。关于如何定制每个工件的更多详细信息,以及该特定工件的优缺点的讨论,请阅读每个工件的标题为“定制”的部分。

对于每个工件,决定应如何使用工件:必须拥有、应该拥有、可以拥有或不能拥有。

工件 用途

定制(可选,建议使用)

实施模型

实施子系统实施元素

实施模型是指在运行时环境中构建和管理系统所需要的源代码、可执行文件和所有其它工件。

实施由实施元素组成,包括代码(源、二进制文件和可执行文件)和含有信息的文件(例如启动文件或自述文件)。

实施子系统是实施元素和其它实施子系统的集合,用来将实施模型分成几个较小的部分来进行构造。

所有软件项目都有一个实施模型,实施模型所具有的实施元素至少包括一些源代码和可执行文件。

有些项目还包括子系统、库和可视化模型。

如果要组织大量的实施元素,那么子系统就有用了。

集成构建计划 定义组件的实施顺序、集成系统时要创建的工作版本以及它们的评估方式。

可选。

如果需要计划集成,则建议使用。只有在集成不重要时才省略它。


根据项目的需要定制每个工件。关于定制注意事项,请参阅工件的描述页

决定单元测试覆盖 到页首

决定执行单元测试的程度以及代码覆盖的级别,它的规模可从非正式的一直到 100% 的代码覆盖。

单元测试覆盖级别常常受集成和系统测试人员(代码移交给这些测试人员)需要的驱动。系统测试人员的工作取决于代码的质量。 如果代码的缺陷过多,集成和系统测试人员就会过于频繁地将代码发回给实施者。 这是开发流程欠佳的信号,其解决方案可能就是要求实施者进行更彻底的单元测试。

当然,您不能期望经过单元测试的代码完全没有缺陷。不过,您需要在单元测试和质量之间找出一个“健康的”平衡。

单元测试覆盖的级别在不同阶段之间也可能不同。即使是在构造和移交阶段需要 100% 代码覆盖的安全关键项目,通常在精化阶段也不需要这样,因为在该阶段有许多类只是部分实施。

决定如何复审代码 到页首

决定代码的复审程度。 

代码复审的优点有:

  • 强迫和鼓励在项目中使用共同的编码风格。代码复审是一种使项目成员遵循编程指南的有效方式。为确保这一点,复审所有作者和实施者的结果比复审所有源代码文件更显重要。
  • 找出自动测试找不到的错误。代码复审可发现在测试中未遇到的错误。
  • 在个人之间共享知识,以及将知识从更有经验的人传递到经验较少的人。

代码复审的缺点有:

  • 它会耗费时间和资源。
  • 如果执行不当,则可能缺乏效率。存在这样的危险,即“只是因为我们必须”进行代码复审而进行代码复审,而不是将其作为对自动测试的高效补充来执行。

关于代码复审的更多信息,还请参阅活动:复审代码

代码复审对项目有着重要的意义。所有开始度量代码复审相关错误和维护问题级别的项目,均称它们因为复审而提高了绩效。 但对于许多组织,他们都难以“着手”进行代码复审,原因如下:

  • 未收集足够数据来验证代码复审是否实际起作用。
  • 收集的数据过多。
  • 实施者对他们的代码的防护意识过强。
  • 复审陷入形式上的困境。
  • 管理复审事宜耗费过多的工作。

请记住以下几点,以尽可能充分利用代码复审:

  • 只收集适量的数据。
  • 度量复审的成绩,并显示结果。
  • “节俭”地使用复审。


Rational Unified Process   2003.06.15