军衔: PMU初级二星
财产:
经验:
魅力:
来自: 重庆市
鉴定: 本功能已经被关闭
发帖: 211篇
注册: 2002-1-31

--------------------------------------------------------------------------------


请大家发表自己的看法。

--------------------------------------------------------------------------------

欢迎造访问我的网站，有UML，软件工程，项目管理
http://www.mooyee.com
ICQ# 58556674:QQ,别加我

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月17日 15:21:12 ]


一刀

头衔: 中士
军衔: PMU初级三星
财产:
经验:
魅力:
来自: 上海
鉴定: 本功能已经被关闭
发帖: 467篇
注册: 2002-4-13

--------------------------------------------------------------------------------


多小的团队？
RUP可以裁减的。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月18日 11:05:18 ]


stone

军衔: PMU初级二星
财产:
经验:
魅力:
来自: 重庆市
鉴定: 本功能已经被关闭
发帖: 211篇
注册: 2002-1-31

--------------------------------------------------------------------------------


一刀 在 2002-5-18 11:05:18 发表的内容
多小的团队？
RUP可以裁减的。

在很多地方讨论软件开发过程/方法，但多浮在表面。由于对现有软件开发中项目失控教训的慢慢积累和总结，我觉得在没有更好的方法的情况下，应用RUP也不是一种不可取的方法。

如果在一个人或三五个人的小团队中，如何应用RUP呢？

--------------------------------------------------------------------------------

欢迎造访问我的网站，有UML，软件工程，项目管理
http://www.mooyee.com
ICQ# 58556674:QQ,别加我

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月19日 12:04:49 ]


stone

军衔: PMU初级二星
财产:
经验:
魅力:
来自: 重庆市
鉴定: 本功能已经被关闭
发帖: 211篇
注册: 2002-1-31

--------------------------------------------------------------------------------


一刀 在 2002-5-18 11:05:18 发表的内容
多小的团队？
RUP可以裁减的。

裁减 的定义是什么？Rational有它的定义吗？

去掉什么不影响RUP的完整性？

--------------------------------------------------------------------------------

欢迎造访问我的网站，有UML，软件工程，项目管理
http://www.mooyee.com
ICQ# 58556674:QQ,别加我

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月19日 12:09:25 ]


一刀

头衔: 中士
军衔: PMU初级三星
财产:
经验:
魅力:
来自: 上海
鉴定: 本功能已经被关闭
发帖: 467篇
注册: 2002-4-13

--------------------------------------------------------------------------------


RUP不是一个必须完全遵守的法律，当你知道RUP所有的步骤和内容之后，你自然会知道哪些对你是有用的，哪些是可以省略的了。同时你的公司开发也并不一定能套用RUP或者迭代模式，这取决与你的应用领域和分析设计能力。举个例子，在电信行业中就不适合RUP。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月19日 13:55:10 ]


stone

军衔: PMU初级二星
财产:
经验:
魅力:
来自: 重庆市
鉴定: 本功能已经被关闭
发帖: 211篇
注册: 2002-1-31

--------------------------------------------------------------------------------


RUP本身可以看作是一个指南，统一开发过程也逐渐受到重视。它对软件研发生命期的每一个核心流程中也给出了相应的指南。
但是在实际工作中，RUP并没有显示出它的威力来。

我不了解电信行业，如果是电信行业的软件，我不知道为什么不适合用RUP?

能否解绍您的宝贵经验呢？

--------------------------------------------------------------------------------

欢迎造访问我的网站，有UML，软件工程，项目管理
http://www.mooyee.com
ICQ# 58556674:QQ,别加我

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月19日 14:41:36 ]


winnie

军衔: PMU初级一星
财产:
经验:
魅力:
来自: 深圳
鉴定: 本功能已经被关闭
发帖: 665篇
注册: 2001-12-12

--------------------------------------------------------------------------------


请一刀多介绍

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月20日 9:02:45 ]


一刀

头衔: 中士
军衔: PMU初级三星
财产:
经验:
魅力:
来自: 上海
鉴定: 本功能已经被关闭
发帖: 467篇
注册: 2002-4-13

--------------------------------------------------------------------------------


在做rational公司的培训时，给我一个很强烈的感觉，整个流程中结构工程师的能力对RUP起决定性的作用。RUP是一个迭代的过程，而每个过程都要求生成一个可执行的代码以实现该次迭代的测试过程，通过对测试结果的评估来决定是否进行下一个迭代。这里项目经理和结构工程师需要先对use case集进行风险分析，选择高风险及重要的用例并进行排序。大家可以想像这里的难度有多高，因为这里不仅牵涉到设计和开发的工作，更重要的是牵扯到了测试的工作。要做到每次迭代的产出都是可以被测试的，模块的设计必须做到偶合性极低（最好是0偶合），这一点对结构工程师的要求太高了。最后，要实现测试，还必须构造许多的桩模块来模拟周围的环境，这一点对于测试方面的工作量需求是非常巨大的。所以当初我向rational公司的代表提出类似问题的时候，他也觉得很难平衡，说穿了还是要有高素质的人。
这里我仅仅是说一下RUP中可能存在的一些风险或着说是“陷阱”，至于流程在RUP软件中都可以看到，其实是没有什么特别的，就是螺旋性开发模式的一个净化罢了，其实IBM早就有类似的流程出现了。RUP如果只有一次迭代的话就是瀑布模型，还不如V模型好呢！
至于电信行业的问题，大家知道像3G这样的系统就是在实现一个通信协议，大家可以去看看这些协议，就会知道为什么电信软件不适合用RUP了。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月20日 12:06:30 ]


stone

军衔: PMU初级二星
财产:
经验:
魅力:
来自: 重庆市
鉴定: 本功能已经被关闭
发帖: 211篇
注册: 2002-1-31

--------------------------------------------------------------------------------


统一软件开发过程把人力资源转化成 工作人员(包括项目经理，架构设计师，设计员，测试人员等)
而统一软件开发过程同时强调以架构为中心，用例驱动迭代增量的开发。

如果集项目经理，架构设计师，设计员一身，其中有什么其要特别注意的地方？

--------------------------------------------------------------------------------

欢迎造访问我的网站，有UML，软件工程，项目管理
http://www.mooyee.com
ICQ# 58556674:QQ,别加我

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月20日 21:49:48 ]


一刀

头衔: 中士
军衔: PMU初级三星
财产:
经验:
魅力:
来自: 上海
鉴定: 本功能已经被关闭
发帖: 467篇
注册: 2002-4-13

--------------------------------------------------------------------------------


个人觉得这样分配职责不好，管理应该和技术分开，这样能管得好。至少在我实际的经验中是这样的。
如果真要将这些角色合在一起那你要多注意工作量的安排上，计划工作充分些，控制严格些。最好找一个QA来协助管理工作。
以架构为中心是最难的一步，说起来简单做起来难，难在没有合适的人。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月20日 23:13:45 ]


stone

军衔: PMU初级二星
财产:
经验:
魅力:
来自: 重庆市
鉴定: 本功能已经被关闭
发帖: 211篇
注册: 2002-1-31

--------------------------------------------------------------------------------


您的意思可以这样理解吗？
尽可能管理和技术分开；研发和质保(QA)分开吗？

构架设计师可否理解为高手水平研发人员，如我们常说的系统分析员呢？

能否给我讲讲RUP定义中的系统分析员和架构设计师之间的人员分配呢？

构架设计师负责在整个项目中对技术活动和工件进行领导和协调。构架设计师要确立每个构架视图的整体结构：视图的详细组织结构、元素的分组以及这些主要分组之间的接口。因此，与其他角色相比，构架设计师的见解重在广度，而不是深度。 [RUP2000]

系统分析员通过概括系统的功能和界定系统来领导和协调需求获取及用例建模。例如，确定存在哪些主角和用例，以及他们之间如何交互。[RUP2000]

--------------------------------------------------------------------------------

欢迎造访问我的网站，有UML，软件工程，项目管理
http://www.mooyee.com
ICQ# 58556674:QQ,别加我

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月21日 13:57:01 ]


stone

军衔: PMU初级二星
财产:
经验:
魅力:
来自: 重庆市
鉴定: 本功能已经被关闭
发帖: 211篇
注册: 2002-1-31

--------------------------------------------------------------------------------


我觉得我现在问题的关键不在于小团队中应用RUP而是怎样理解和应用RUP上。

--------------------------------------------------------------------------------

欢迎造访问我的网站，有UML，软件工程，项目管理
http://www.mooyee.com
ICQ# 58556674:QQ,别加我

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月21日 14:16:19 ]


一刀

头衔: 中士
军衔: PMU初级三星
财产:
经验:
魅力:
来自: 上海
鉴定: 本功能已经被关闭
发帖: 467篇
注册: 2002-4-13

--------------------------------------------------------------------------------


研发与QA能分当然分，而且最好要分，这是百分百的经验。
至于后两个角色请关注于他们所需干的活，而不要关注于名称，需求和设计是两个活动，架构是用来填放需求的。同时捕获需求的人不仅仅是系统分析员，他还包括所有的stakeholder，反正我们不仅要发现他们现在的需求，还要发现将来的需求。
反正有很多东西的，这里用文字的形式说这些问题实在是受不了，有机会搞个聚会说吧。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月21日 14:37:53 ]


一刀

头衔: 中士
军衔: PMU初级三星
财产:
经验:
魅力:
来自: 上海
鉴定: 本功能已经被关闭
发帖: 467篇
注册: 2002-4-13

--------------------------------------------------------------------------------


研发与QA能分当然分，而且最好要分，这是百分百的经验。
至于后两个角色请关注于他们所需干的活，而不要关注于名称，需求和设计是两个活动，架构是用来填放需求的。同时捕获需求的人不仅仅是系统分析员，他还包括所有的stakeholder，反正我们不仅要发现他们现在的需求，还要发现将来的需求。
反正有很多东西的，这里用文字的形式说这些问题实在是受不了，有机会搞个聚会说吧。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月21日 14:38:06 ]


winnie

军衔: PMU初级一星
财产:
经验:
魅力:
来自: 深圳
鉴定: 本功能已经被关闭
发帖: 665篇
注册: 2001-12-12

--------------------------------------------------------------------------------


agree with yi dao.

QA and develop team should be divided. and should be in parallel. You can say QA team takes the responsibility to monitors develop process.

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月21日 14:46:24 ]


stone

军衔: PMU初级二星
财产:
经验:
魅力:
来自: 重庆市
鉴定: 本功能已经被关闭
发帖: 211篇
注册: 2002-1-31

--------------------------------------------------------------------------------


把QA与RD分开是一个公开的法则，我也是这样做的。
不过行政管理和技术管理暂时没法分开了。

--------------------------------------------------------------------------------

欢迎造访问我的网站，有UML，软件工程，项目管理
http://www.mooyee.com
ICQ# 58556674:QQ,别加我

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月21日 20:33:40 ]


一刀

头衔: 中士
军衔: PMU初级三星
财产:
经验:
魅力:
来自: 上海
鉴定: 本功能已经被关闭
发帖: 467篇
注册: 2002-4-13

--------------------------------------------------------------------------------


stone别这样说，QA和开发是可以兼职的，当项目足够小时就可以这样的。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月21日 21:41:54 ]


stone

军衔: PMU初级二星
财产:
经验:
魅力:
来自: 重庆市
鉴定: 本功能已经被关闭
发帖: 211篇
注册: 2002-1-31

--------------------------------------------------------------------------------


一刀 在 2002-5-21 21:41:54 发表的内容
stone别这样说，QA和开发是可以兼职的，当项目足够小时就可以这样的。

是尽或给QA的RD分开吗？
有时候的确是项目很小，一个人从头到尾都可以搞定。但不能满足日益增高的用户需要。。

--------------------------------------------------------------------------------

欢迎造访问我的网站，有UML，软件工程，项目管理
http://www.mooyee.com
ICQ# 58556674:QQ,别加我

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月22日 1:11:04 ]


一刀

头衔: 中士
军衔: PMU初级三星
财产:
经验:
魅力:
来自: 上海
鉴定: 本功能已经被关闭
发帖: 467篇
注册: 2002-4-13

--------------------------------------------------------------------------------


从成本和效率角度来裁决如何操作。当然最好是当执行组织的CMM级别高一些才开始这样操作比较好。要兼职最合理的是项目经理自己兼。

--------------------------------------------------------------------------------

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月22日 9:08:47 ]


stone

军衔: PMU初级二星
财产:
经验:
魅力:
来自: 重庆市
鉴定: 本功能已经被关闭
发帖: 211篇
注册: 2002-1-31

--------------------------------------------------------------------------------


找到几篇文章。国外对这样的讨论好像开展得更早更深入

1http://www.therationaledge.com/content/jan_02/f_agilityWIthRUP_pk.html
Agility with the RUP
by P. Kruchten
[2] href="http://www.therationaledge.com/content/feb_02/f_processForOne_pk.jsp
A Software Development Process for a Team of One
by P. Kruchten

http://www.therationaledge.com/content/jan_01/t_rup_ge.html

--------------------------------------------------------------------------------

欢迎造访问我的网站，有UML，软件工程，项目管理
http://www.mooyee.com
ICQ# 58556674:QQ,别加我

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月22日 14:06:32 ]


stone

军衔: PMU初级二星
财产:
经验:
魅力:
来自: 重庆市
鉴定: 本功能已经被关闭
发帖: 211篇
注册: 2002-1-31

--------------------------------------------------------------------------------


粘贴一篇文章，希望能帮助和我一们受困的人们.引用的时候请注意版权

RUP的剪裁原理和剪裁过程
2002年05月08日

RUP即Rational Unified Process，是Rational公司开发的软件过程产品。The Unified Software Development Process也指的是RUP，不过去掉了前面的公司名。本文分别采用“统一软件过程”和“RUP”作为其全称和简称。

　　就笔者所了解，当前国内业界普遍关心的一个问题是：RUP的剪裁原理是什么，有没有工程化的RUP剪裁过程。本文将讨论上面两个问题。本文有不少观点来自个人心得，有不妥之处，敬请斧正。

第一部分 RUP的剪裁原理

　　首先介绍“软件过程也是软件”这一著名原理，然后指明RUP的剪裁原理是：软件过程开发的再工程。

一、 软件过程也是软件

　　软件工程大师Osterweil在其论文《Software Processes are Software Too》中高屋建瓴地指出：软件过程也是软件。软件有一个开发的过程，软件过程也有一个开发的过程；软件开发产出软件产品，软件过程开发产出过程产品；软件开发可以是一个演进过程，软件过程开发也可以是一个演进过程。

1. 软件过程也有一个开发的过程

　　软件过程也是经过了需求捕获、分析、设计、实现和测试等活动才开发出来的。下面仅简单论述。软件过程开发中，需求是指采用该软件过程的目的是什么（高层需求），要用来指导哪些活动（需求）；分析和设计是指，活动之间如何衔接甚至并行执行，各活动产出什么产品；实现是指，将软件过程文档化，相当于软件开发的coding；软件过程开发也有测试，不过是在脑子里run的，而上级领导用脑子run两遍批示通过就是验收测试。

　　进一步讲，软件过程不仅有开发过程，而且有完整的软件过程生存周期。因为软件过程在开发出来之后，也有交付使用、维护升级直至废弃的过程。交付使用就是将软件过程实施，用于指导软件项目的开发。要是在使用软件过程时发现有错误之处（bug，需纠错性维护）或欠缺之处（新需求，需升级性维护），可以对原软件过程进行修改或增强。当其经过修改升级也不能满足指导开发的需要时，就将其废弃，软件过程生存周期结束。 顺便插一句，当前异常火爆的CMM说是“软件过程框架和标准”，当如何理解。从“软件过程也是软件”的角度考虑，CMM的本质其实是软件过程开发的需求和测试方案：CMM的每个“关键实践”都是软件过程开发的一条需求；至于“关键过程域”和“关键实践类”，从需求的层次角度（请参考Wiegers著陆丽娜译《软件需求》一书），可分别理解为“业务需求”和“用户需求”；CMM提问单的每个问题就是测试方案的一个一个的测试案例，测试方案是依照需求来制定的，CMM把需求和测试方案二合一了。“CMM是软件过程的进化框架”也不难从“软件过程也是软件”的角度找到犀利的理解，那就是：CMM对所有软件过程开发的需求，依据重要性和相互依赖关系，划分了优先级，然后依据需求的优先级将需求分成五组，即初始级、可重复级、已定义级、定量管理级和优化级。

2. 软件过程开发产出过程产品

　　软件开发产出的软件产品是程序和文档的集合，那么，过程开发产出的过程产品是什么样呢？过程成品从存在形式上，是一些文档。通过评审的过程产品，就是标准化制度化的文档，这些文档来指导和制约软件开发过程。

　　过程产品都必须具备四要素：功能要素（即活动），行为要素（即活动间通过依赖等关联构成活动模型，其实四大经典开发模型的图基本都是活动模型），组织要素（即人和活动间的关联），信息要素（即产品）。

　　再看RUP，该过程产品也是一些文档，总共有上千页，被组织成可以在线查询的知识库。我们看其核心概念：角色、活动、工作流和工件，并没用离开四要素的范畴：角色即人（的职责），工件即产品，工作流是涉及角色、活动和工件的模型。

3. 软件过程开发也可以是一个演进过程

　　为了进一步证明软件过程开发和软件开发的相似性，我们选择很流行的“演进”概念来考察二者。演进开发在RUP中叫增量开发，就是后一步的开发在前一步开发的半成品的基础上进行。软件开发采用演进开发的，一般称为“喷泉模型”。而软件过程开发也可以采用演进开发，特别是开发针对大项目的软件过程时，由于软件过程足够复杂，演进开发是必要的。

二、 RUP的剪裁原理

　　首先说明再工程的概念，然后说明RUP剪裁就是一项再工程。

1. 再工程的概念

　　再工程（reengineering）是对现有软件系统的重新开发过程，包括逆向工程、新需求的考虑和正向工程三个步骤。

2. RUP剪裁是软件过程开发的再工程

　　既然“软件过程也是软件”，那么再工程概念对软件过程开发也适用。RUP剪裁的故事就可以这样讲：Rational公司开发出了RUP；我们想将RUP剪裁后用于某软件项目，于是我们就对RUP进行逆向工程得到《RUP开发需求》和《RUP设计方案》等文档；然后，再考虑我们这个软件项目得到《某软件项目软件过程需求》；最后，比较两个需求，借鉴《RUP设计方案》，进行软件过程开发的正向工程得到《某软件项目软件开发过程》。

　　是的，“RUP剪裁是软件过程开发的再工程”的观点确实很有启发，为我们制定工程化的RUP剪裁过程打下了坚实的理论基础。

第二部分 对RUP进行逆向工程

　　依据“RUP剪裁是软件过程开发的再工程”的观点，RUP剪裁分为对RUP进行逆向工程、考虑软件过程新需求和过程开发正向工程三个步骤。但是，对RUP进行逆向工程只需进行一次，以后的RUP剪裁过程都可以重用了。所以，笔者将“对RUP进行逆向工程”从“工程化的RUP剪裁过程”单独提出讨论。

　　另外，本文也不打算详细阐述逆向工程的工程化过程，那将是非常庞大和非常理论化的。本文采取的方法是，列出逆向工程过程的产出产品的子集，而且每个产品的内容也仅涉及核心子集。

　　其实，如果不从理论化的角度讲，对RUP进行逆向工程其实就是个理解RUP的过程（不理解RUP就没用办法进行剪裁），因此，下面的阐述也是笔者对RUP的一点理解，抛砖引玉，敬请斧正。

一、 需求

　　Rational的大师们在开发RUP时先要进行需求捕获，他们捕获到的需求肯定少不了下面的内容：
　　◆RUP将是一个有足够通用性的过程产品，将RUP适当剪裁后应能适合绝大多数项目。（功能需求）
　　◆采用RUP作为开发过程，开发风险必须最小化。（非功能需求）

二、 分析

　　接下来进行分析，想必会是这样：
　　◆开发过程由多种“活动”组成。
　　◆每种“活动”生产出不同的“产品”，也可能多种“活动”生产出一种“产品”。
　　◆活动有业务建模、需求、分析和设计、实现、测试、实施、配置和变更管理、项目管理和环境。（RUP的九个核心工作流）
　　◆产品有：用例模型、分析模型、设计模型、源程序和测试报告等。
　　◆活动可以包含子活动，子活动之间可以并行进行，干脆把活动改称工作流，把子活动改称活动。
　　◆“产品”可以是成品或供演进的半成品，干脆把成品和半成品合称为“工件”。

三、 设计

　　接下来进行设计，想必会是这样：
　　◆为了满足通用性需求：借鉴面向对象的泛化思想（即参数化或模板），RUP只提供框架而和具体项目无关。
　　◆为了满足风险最小化需求：引入阶段概念和迭代开发模型，以便给开发者足够多的机会，在付出太多代价之前放弃或调整开发。

四、 实现

　　RUP的实现我们都看到了，就是那个可以在线查询的知识库，内容很丰富。

第三部分 工程化的RUP剪裁过程

　　在对RUP进行了逆向工程，并且比较好地理解了RUP之后，还需要进行的两个步骤是RUP剪裁过程的核心部分，本段给出一种工程化的解决方案。首先，讨论软件过程开发的需求工程；然后，讨论软件过程开发的正向工程，即五步法；最后，对五步法给出几点说明，着重说明五步法是如何降低RUP剪裁的复杂性的。下面要阐述的工程化的RUP剪裁过程，不是放之四海而皆准的，但确实有一定的通用性。

一、 软件过程开发的需求工程

　　这里，软件过程开发的需求工程，完全可以借鉴软件开发中的需求工程，包括需求捕获、需求分析、编写需求文档和需求评审。

1. 需求捕获

　　首先明确项目环境，然后向项目所有涉及人员收集信息。项目环境包括软件类型、软件规模、软件重要程度、开发人员素质、合作单位素质等，这些因素都会影响到将来软件过程的制定。项目涉及的人员包括用户、开发人员、合同确定者和投标者等，从他们那里收集对软件过程的要求。

2. 需求分析

　　研究采集到的要求，形成有条理的需求表述。

3. 编写需求文档

　　将有条理的需求表述文档化。

4. 需求评审

　　组织由上级领导、开发人员及其他人员参加的评审。若评审未获通过，根据具体情况从上面三步的其中一步开始回溯，直至评审通过。

二、 软件过程开发的正向工程

　　采用“五步法”。一方面，五步法保留了RUP的优秀概念，如阶段、迭代、工作流、工件和角色等。另一方面，五步法采用了一些旨在降低RUP剪裁复杂性的策略，在后面“五步法的几点说明”中有讲述。

1. 确定本项目的软件过程需要哪些工作流

　　根据项目规模的大小不同，RUP的九大工作流并不总是需要的；另外嵌入式软件项目一般不需要业务建模工作流。虽然工作流中可以包含并行执行的活动，但本阶段并不关心这些，而是仅把工作流看成黑盒，也就是说工作流退化成了活动。

2. 确定每个工作流产出哪些工件

　　因为很多开发单位还是评审传统形式的文档，因此，可以规定工作流产出某传统文档。

3. 确定阶段间演进

　　RUP将开发过程分为四个阶段（初始阶段、细化阶段、构造阶段和移交阶段）是控制风险的很好的方法，确定阶段间演进就是要以风险控制为原则，决定每个阶段要执行哪几个工作流，每个工作流执行到什么程度，产出的工件有哪些，每个工件完成到什么程度。

4. 确定阶段内的迭代计划

　　迭代是RUP非常强调的一个概念，可以进一步降低开发风险，在RUP的四大阶段（在后三个阶段进行迭代更常见）中，决定是否采用迭代开发，每次迭代开发的内容有哪些。

5. 规划工作流内部结构

　　工作流不是活动的简单堆积，工作流涉及到角色、活动和工件，并且工作流的复杂程度和项目规模及角色多少等有很大关系。因此，我们应首先决定本软件过程要设立哪些角色；如果第二步中引入了传统文档，还要将传统文档映射到RUP工件；最后，规划工作流内部的结构，通常用活动图的形式给出。

　　若想通过对RUP剪裁得到比较复杂的软件过程，无疑这一步是剪裁的难点。

三、 五步法的几点说明

1. 确定软件过程的时机

　　在实际中，确定软件过程的时机不是一成不变的。比如，如果新项目和该项目组以前开发过的某个项目很相似，就可以在软件开发开始之前确定将采用的软件过程；如果是不熟悉的项目，就可能在初始阶段完成后才能确定或修改要采用的软件过程；如果项目有很多未知因素，迭代计划推迟到阶段开始前比较好，工作流规划也同样推迟。

2. 五步法为何前瘦后胖

　　五步法中的五步，让人感觉前三步很“瘦”，而后两步比较“胖”，这是为什么呢？其实，将迭代计划和角色设立都往后推迟，是为了使软件过程开发简单化。软件过程开发主要有两种流派：以活动为中心和以角色为中心。而RUP的工作流这个核心概念是角色和活动并重的，通过适当推迟规划工作流，可以使RUP剪裁简单化。五步法正是这样一种RUP剪裁过程：它以活动为中心的，它的第一步就是确定活动；并且它把角色的设立推迟到了最后，既降低了RUP剪裁的复杂性，又保留了工作流的优点。

3. 传统文档和RUP工件的对应关系

　　传统文档和RUP工件之间，有时存在一定的对应关系，而且往往是一对多的关系。因此五步法的第二步可以用传统文档，不仅是符合习惯的，也减少了软件过程开发先期阶段的细节，降低了RUP定制的复杂性。到了第五步，再将传统文档分解成RUP工件，以利用RUP的工作流方面的指南。传统的《软件定义文档》可以分解为RUP的scope、vision和features；传统的《软件需求规格说明书》的非功能需求部分要包括RUP的business rules；等等

粘贴一篇文章，希望能帮助和我一们受困的人们.引用的时候请注意版权
Stone

--------------------------------------------------------------------------------

欢迎造访问我的网站，有UML，软件工程，项目管理
http://www.mooyee.com
ICQ# 58556674:QQ,别加我

--------------------------------------------------------------------------------
[ 本文发表于 2002年5月22日 17:18:02 ]


hand789

军衔: PMU初级二星
财产:
经验:
魅力:
来自: 四川
鉴定: 本功能已经被关闭
发帖: 494篇
注册: 2002-2-16

--------------------------------------------------------------------------------


好文章,受益非浅.软件开发流程设计本身就是一个软件工程.那么项目的进度计划实际上就是项目的实施设计了.

--------------------------------------------------------------------------------

性格决定命运，
气度左右格局。

--------------------------------------------------------------------------------
[ 本文发表于 2002年6月16日 11:48:27 ]