hong

导航

RUP 核心概念

RUP 核心概念


软件工程流程

流程是为实现某个目标而设定的一系列次序相对固定的步骤;在软件工程中,要实现的目标是开发一个软件产品,或增强现有软件产品;在流程工程中,其目标是实现或增强一个流程。

按业务建模的术语,软件开发流程是一个业务流程;Rational Unified Process 是一个面向对象软件工程的通用业务流程。它描述了一系列相关的软件工程流程,它们具有相同的结构,即相同的流程构架。RUP 为在开发组织中分配任务和职责提供了一种规范方法。其目标是确保在可预计的时间安排和预算内开发出满足最终用户需求的高品质的软件。Rational Unified Process 汇集现代软件开发中多方面的最佳经验,为适应各种项目及组织的需要提供了灵活的形式。

如果从零开始开发一个软件系统,开发过程是按需求创建系统的过程。而一旦系统已成形(或者,用我们的话说,一旦系统经历了最初开发阶段),所有进一步的开发都是使系统符合新需求或变更需求的过程。这在系统的整个生命周期中都是如此。

软件工程流程是按需求开发系统的过程,可以是新需求(最初开发阶段),也可以是变更需求(演进阶段)。

角色
角色是流程中最重要的概念之一。角色定义了在软件工程组织的环境中,个人或协同工作的多人小组的行为和职责。角色代表项目中个人承担的任务,并定义其如何完成工作。角色概述提供了有关角色的其他信息。

请注意角色不是个人;他们描述的是个人在业务中应该如何工作及其职责。软件开发组织的个人成员将充当不同的角色,发挥不同的作用。项目经理在计划项目、配备人员时对应为角色配备相应的人员(请参见活动:为项目配备人员),他可以让不同的人充当多种不同的角色,也可以让某个角色由多个人承担。

活动
角色从事活动,而活动了定义角色执行的工作。活动是参与项目的角色为提供符合要求的结果而进行的工作。请参见活动:获取常用词汇(活动的一个示例)。

一项活动是一个工作单元,由参与项目的某一成员执行,其具体内容由角色进行说明。活动有明确的目的,其内容通常表述为创建或更新某些工件,例如一个模型、一个类或一个计划。每个活动都被分配给具体的角色。一个活动一般延续几个小时到几天,它通常涉及一个角色,只影响一个或少数几个工件。一项活动应该是一个便于实施的计划单元及流程单元。如果活动太小,它将被忽略;而如果活动太大,流程将不得不被分解为一项活动的部分来表述。

有时可能要对同一的工件重复进行多次活动,特别是当由同一角色(但不一定是同一个人)从一次迭代到另一次迭代、对系统进行改进和扩展的时候更是如此。

步骤
活动可细分为步骤。步骤主要分为以下三类:

构思步骤:在这一步骤中,角色了解任务的实质、收集并检查输入工件、规划输出结果。
执行步骤:在这一步骤中,角色创建或更新某些工件。
复审步骤:在这一步骤中,角色按某些标准检查结果。
一项活动并非在每次实施时都一定执行所有步骤,因此它们可以表示为备用流程的形式。

步骤的示例:

活动:查找用例和主角分解为以下步骤:

  1. 查找主角
  2. 查找用例
  3. 说明主角和用例的交互方式
  4. 将用例和主角打包
  5. 在用例图中显示用例模型
  6. 生成用例模型的概览
  7. 评估您的结果

查找部分 [步骤 1 到 3] 需要一些思考;执行部分 [步骤 4 到 6] 涉及在用例模型中获得结果;在复审部分 [步骤 7] 角色评估结果的完整性、强壮性、可理解性或其他品质。

工作指南
活动可能有相关的工作指南,工作指南介绍有助于角色执行活动的技巧和实用的建议。对具有工作指南的活动,可从活动说明部分的超级链接访问。工作指南概述汇总了所有提供的工作指南,可以从树形浏览器的顶层访问。

工件
工件分为输入工件和输出工件。工件是流程的工作产品:角色使用工件执行活动,并在执行活动的过程中生成工件。工件是单个角色的职责,它体现的是这样一种思想:流程中的每条信息都必须是一个具体的人的职责。即使一个人可能“拥有”某个工件,但其他人也可以使用该工件,如果授予权限,或许他们还可以更新这个工件。

为了简化工件的组织结构,我们以“信息集”或工件集的形式将工件组织起来。工件集是打算用来完成相似目的的一组相关的工件。工件概述介绍有关工件和工件集的详细信息。

工件有多种形式:

模型,例如用例模型或设计模型,它包含其他工件。
模型元素,即模型中的元素,例如设计类、用例或设计子系统
文档,例如商业理由或软件构架文档
源代码和可执行程序(某种构件)
可执行程序
请注意,“工件”是 Rational Unified Process 中使用的术语。其他流程使用象工作产品、工作单元等术语表示相同的含义。可交付工件只是所有工件的一部分,最后将交付给客户和最终用户。

工件最容易受版本控制和配置管理的影响。有时无法对基本的被包容工件进行版本控制,只能对容器工件进行版本控制。例如,您可以控制整个设计模型(或设计包)的版本,但无法控制它们所包含每个类的版本。


工件通常不是文档。许多流程将注意力过多的放在文档上,特别是书面文档上。Rational Unified Process 不鼓励系统地制作书面文档。管理项目工件最有效和实用的方法是在创建和管理工件的相应工具中维护工件。如果需要,您可以随时从这些工具生成文档(快照)。您也可以考虑将工件和工具一起(而不是书面文档)交付给内部相关各方。这种方法可以确保信息总是最新的,是基于实际项目工作的,并且不必专门制作。

工件示例:

存储在 Rational Rose 中的设计模型。
存储在 Microsoft Project 中的项目计划。
存储在 ClearQuest 中的缺陷。
RequisitePro 中的项目需求数据库。
但是,有时候仍然需要纯文本文档形式的工件,如在对项目进行外部输入的情况下,或者有时仅仅是因为纯文本文档是提供说明性信息的最佳方式。

模板

模板是工件的“模型”或原型。与工件说明相关的是一个或多个可以用来创建相应工件的模板。模板和将使用的工具相联。

例如:

Microsoft Word 模板将用于文档形式的工件和一些报告。
用于 Microsoft Word 或 FrameMaker 的 SoDA 模板将从诸如 Rational Rose、RequisitePro 或 TeamTest 等工具中提取信息。
Microsoft FrontPage 模板用于流程中的多种元素。
Microsoft Project 模板用于项目计划。
对于指南,各个组织可能要在使用前定制模板,添加公司徽标、一些项目标识或该类型项目特有的信息。在树形浏览器中,模板位于与之相关的工件下。树形浏览器中单独有一个条目汇总了所有的模板。

报告
模型和模型元素可能有与之相关的报告。报告从工具中提取模型和模型元素的相关信息。例如,报告提供要复审的工件或工件集。与常规的工件不同,报告不受版本控制的影响。可以随时返回生成报告的工件重新生成报告。在树形浏览器中,报告位于它所报告的工件下。

工件指南和检查点
通常,工件有相关的指南和检查点,提供有关如何开发、评估和使用工件的信息。流程的许多实质内容包含在工件指南中;活动说明主要侧重于工作的结果,而工件指南侧重于工作的过程。检查点提供快速参考,帮助您评估工件的质量。

许多情况下,指南和检查点十分有用:它们帮助您决定做什么,如何做,并在您完成后帮助确定您是否很好地完成了工作。与每个特定的工件相关的指南和检查点与该工件一起位于树形浏览器中。工件指南概述也概括性地介绍了一下工件指南。 

 
工作流程
所有角色、活动和工件的简单列举不能组成一个流程;我们需要采用一种有意义的顺序描述产生有价值结果的活动,并显示角色之间的交互作用。一个工作流程就是一系列活动,这些活动产生的结果是可见的价值。

按 UML 术语,工作流程可以表现为序列图、协作图或活动图。在 Rational Unified Process 中,我们使用活动图的形式。对于每个核心工作流程,都显示一个活动图。

描述流程的一大困难是有多种将活动集组织到工作流程中的方法。我们使用以下方法组织 Rational Unified Process:

核心工作流程
核心工作流程是在整个项目中与主要“关注领域”相关的活动的集合。将活动划分出核心工作流程主要是帮助从“传统的”瀑布式开发角度了解项目 - 例如,通常情况下,更加普遍的方式是与分析设计活动一起密切配合来执行某些需求活动。将活动分成不同的核心工作流程使活动更容易理解,但会使时间安排变得比较困难。

象其他工作流程一样,核心工作流程是半条理化的活动顺序,执行这些活动是要达到特定的结果。核心流程“半条理”的性质强调核心工作流程不能反映出安排“真实工作”的实际细微差别,因为它们不能描述活动的可选性或实际项目的迭代性。然而,它们仍然是有价值的,通过将流程分解成较小的“关注领域”,为我们提供了一种了解流程的方法。

每个“关注领域”(或核心工作流程)都有一个或多个相关的“模型”,这些模型又是由相关的工件组成的。最重要的工件是每个核心工作流程产生的模型:用例模型、设计模型、实施模型和测试模型。

对于每个核心工作流程,还显示一个活动概述。活动概述显示工作流程中的所有活动和执行这些活动的角色。同时,显示工件概述图。该图显示工作流程中涉及的所有工件和角色。

需要注意“以工作流程为中心的”工件组织结构有时(虽然并不总是)和工件的工件集组织结构稍有不同。原因很简单:一些工件在多个核心工作流程中使用;严格的“以工作流程为中心的”分组使表示完整的流程更加困难。但是,如果仅使用部分流程,“以工作流程为中心的”工件概述会更有用。

工作流程明细
对于大多数核心工作流程,您还将用到工作流程明细图,该图显示经常“一起”对活动进行分组。这些图显示所涉及的角色、输入和输出工件、以及执行的活动。提供工作流程明细图有以下几个原因:

·工作流程中的活动既不按顺序执行,也不同时执行。工作流程明细图显示在执行工作流程的同时,您通常将在工作组或团队会议上工作的方式。通常,您会同时执行多个活动,考虑多个工件。核心工作流程有多个工作流程明细图。
·在一个图中显示某个核心工作流程所有活动的输入和输出工件会十分复杂。通过工作流程明细图,您可以同时看到某部分工作流程的活动和工件。
·核心工作流程之间不是完全独立的。例如,在实施和测试工作流程中都有集成情况发生,并且在实际情况中,从来不会执行其中一个而不执行另一个。工作流程明细图可以显示工作流程中的一组活动和工件,以及另一个工作流程中密切相关的活动。

其他概念
工具向导
活动、步骤和相关的指南为实施者提供了一般性指导。更进一步,工具向导是另一种提供指导的方式,它展示如何使用特定的软件工具执行步骤。Rational Unified Process 中提供工具向导,将其活动与 Rational Rose、RequisitePro、ClearCase、ClearQuest 和 TestStudio 等工具联系起来。工具向导在工具集中几乎完全含盖了流程的依赖关系,使活动不受工具具体情况的影响。开发组织可以扩展工具向导的概念,提供其他工具的指导。

概念
流程中的一些核心概念(例如迭代、阶段、风险、性能测试等)在流程中有专门介绍。通常情况下附加于相应的核心工作流程。

说明:全文摘录《RUP》

posted on 2006-09-14 00:19  hong  阅读(884)  评论(0编辑  收藏  举报