美国外国留学生中，中国学生共计六万多人仅次于印度学生，2005年外国研究生数目在连续下降三年后首次出现1％的成长。

据美国研究所协会(Council of Graduate Schools)11月7日发表的报告，美国各高校研究生外国新生入学率在连续三年下降后，2005年比2004年增长了1%。报告认为，改进入学手续及简化签证程序成功得扭转下降趋势。美国研究所学会的报告说，来自中东地区国家的研究生新生入学率比2004年增长11%；韩国的新生入学率增长5%；中国和印度的新生入学率各增长3%。

美国研究所协会主席斯图尔特(Debra W. Stewart)在公布报告的新闻简报中说："国际学生新生人数的增加是一个很好的迹象，我希望这说明我国研究所国际学生人数减少的趋势已经改变。"

美国研究所协会的报告说："新生入学率下降趋势的改变表明，各学院采取的改进入学手续措施以及国土安全部(Department of Homeland Security)与国务院(Department of State )的简化签证程序和在国外树立更积极形象的努力产生效果。 "

美国研究所协会对外国研究生入学趋势进行多年跟踪分析，上述数据来自其中2005年三阶段调查报告的最后一部分。

在2005年研究所国际新生入学率出现1%增长之前，入学率曾连续3年下降：2002年下降8%，2003年下降10%，2004年下降3%。超过125所研究所对协会的调查作了答复，在外国学生人数最多的25 所研究所中，80%以上作了答复。

美国研究所协会说，鉴于2004年中国申请就读美国研究院的人数比前一年减少了45%，同期的中国研究生新生入学人数减少了8%，2005年中国研究生新生入学人数的增加"引人注目"。

据国际教育研究协会(Institute of International Education)2004年度"门户开放项目"(Open Door)的调查报告，在2003-2004年学年，美国高等院校共有中国留学生61765人，除印度以外，居该年度在美国的外国留学生人数之首；但中国学生的总人数比前一学年的64765人下降了4.6%。

负责领事事务的美国助理国务卿哈蒂(Maura Harty)3月份对北京大学学生说："你们听到的任何所谓美国不欢迎中国学生，或外国学生的说法，完全不符合事实。" 她表示，不应将签证手续视为前往美国或赴美留学的障碍，并且说"公众对[2001年9月11日以后]签证手续调整的认识已经过时，现实完全不同。" 哈蒂认为，美国签证政策的双重目标──"开放国门"和"边境安全"──并不相互排斥，"欢迎正当合法的学生到我国来，是对我们国家未来的投资。"

研究所协会指出，2005年头两个阶段调查的主要结果显示，2004-2005年外国研究生入学申请下降了5%，外国研究生的录取人数增加了3%。

斯图尔特说："我们仍有大量的工作要做，以确保美国继续是外国优秀学生攻读学位的首选之地。外国研究生对美国的研究和创新很重要，是保持美国在全球经济竞争力的关键。"有关官员说，美国长期致力于支持国际教育交流，并且鼓励外国学生踊跃前往美国，同时努力改变美国不欢迎外国学生的看法。

国务院支持教育咨询中心

美国国务院教育和文化事务局(Bureau of Education and Cultural Affairs)的"美国教育"网站(EducationUSA)为有意到美国进修的人提供信息和服务。该网站提供各种专业介绍(大学生、研究生、专门职业项目、以及学术和短期进修机会)，并且设有网址，提供关于行前准备和在美国生活的信息数据以及选校指南。该网站还包括一个专为"EducationUSA"设置的学校搜索引擎。

"EducationUSA" 提供有关标准考试、签证手续、入学、经济资助等信息以及其它美国政府网站和校外资助来源的网址。该网站也有"如果你想留学美国"(If You Want to Study in the United States)这一四集手册的网址，这套手册有阿拉伯文、中文、英文、法文、俄文和西班牙文版。

美国国务院也积极促进外国人来美国留学，并为设在其它国家的450个教育咨询和信息中心提供支持。

背景
许多人都知道也会使用到使用案例 (Use Cases)，但是却很少有人能够明确了解使用案例的定义以及合适的使用时机，我们也时常可以看到复杂而庞大使用案例让人变得难以真正理解系统概括的需求。
使用案例最早是在1986年由Ivar Jacobson所提倡的（在UML出现之前），他也是UML的主要贡献者之什么是使用案例
使用案例本身并不是指图形，而是一种文字型的文件，建立使用案例时主要的工作也是在撰写说明文字而非画图。之后UML定义了使用案例的图形，主要目的来展现使用案例中参与者与使用案例之间的名称与关系。
基本上使用案例代表了系统的功能性需求（或行为）。
使用案例中有参与者，参与者可以是人、计算机系统或组织等。例如在POS系统中，收银员是一个参与者。而使用案例主要便是描述参与者使用系统而达到目的的一组情节（包含成功情节与失败情节）。如果我们有一个POS的使用案例名称是处理退货，在这则使用案例中我们会详细描述收银员处理退货的步骤（情节）。
在对象导向分析中我们也可以使用互动图形来协助描述这些情节，例如循序图或者合作图，这也称为使用案例实例，但是并不是因此就代表我们可以省略文字来描述使用案例中的情节。
从另一个角度来看，使用案例是分析需求的工具，而我们做完需求分析之后，我们需要与客户确认需求的分析结果正确与否，只有严谨仔细的文字描述才有可能得到客户的签字认可，相信没有人会认为画几个UML中的使用案例图形就可以让客户签字吧（当然前提是客户需要懂得使用案例）。
用EBP（企业基本流程）作为找出使用案例的原则
许多人在定义使用案例时都会遭遇到没有一个可以依循的标准来作为使用案例的遵循依据。在这里介绍一个可以遵循的参考。
EBP：基本企业流程（BASIC BUSINESS PROCESS）
EBP的定义是，为了响应某个企业事件，一个人在某个地方、某个时间点所执行的工作。这个事件会增加可衡量的企业价值，并且让数据处于一致状态。也就是喔，当我们在寻找使用案例时，焦点应该放在能够增加企业看得见的价值的工作。例如，核准信用卡或者处理订单。换个角度来说，我们会说撰写企画书是一项有价值的工作，而非打开计算机或者使用WORD这样的工作。
关键在于：能够增加企业可衡量的价值
例如，登入系统显然并不能增加企业价值，特别是当老板询问你今天作了什么，而你回答『登入系统二十次』时。所以我们在找出使用案例时，应该避免用在描述过多低阶的需求上，而使得使用案例变得庞大而失焦，并且最后变得无法管理。
但某些低阶重要的使用案例则可以权衡的出现，例如『使用信用卡付款』这个使用案例并不能符合EBP指引，但是这样的子工作可能反复出现在基本使用案例中，因此我们可能会将他分离出来变成独立的使用案例。
使用案例应该符合参与者的目标（USER GOAL），这样的使用者案例称为使用者层级使用案例。

因此使用案例的重点在于：寻找使用者想要达成的目标，而非使用者想做什么。当我们询问使用者想做什么时，可能会得到笼统而且错误的答案，结果并不符合使用者真正的需求。
定义使用案例的四个基本流程
我们可以依循以下四个步骤来找出符合我们需要的使用案例来。
1. 选择系统边界：软件系统或者是软件体整合系统，使用者是个人或者组织。
2. 找出主要参与者：这些使用者会透过系统所提供的服务满足他们的目标。
3. 针对每个主要参与者，找出他的使用者目标。把这些使用者目标变成满足EBP指引的高阶使用者目标层级。并且在稍后列出参与者目标清单。
4. 定义满足使者目标的使用案例：根据这些目标替使用者案例命名。通常目标与案例是一对一的。
本篇文章主要的目的不在解释如何画出UML中的使用案例图形，而在于让读者了解使用案例的概念以及使用的时机，只要能够了解使用案例的精神，使用什么样的工具来辅助都是可以接受的。

如果一个软件公司或软件人，只把自己定位在做小型的商务数据应用项目，那只需要一些简单的结构化分析及编程技术；然而国际上各式软件技术及方法论快速发展，着实希望我们能够跟上国际的脚步，进而发展出自己的价值。技术的演化有其目的与价值
从笔者学生时代开始参与软件项目至今，虽然才短短几年时间，在软件设计的技术及方法论上，就已经出现了不少的变化。这从许多贩卖专业计算机书籍的书店就可以略知一二了。虽然现在这些书店的计算机书还是以基础技术实作以及工具使用的书籍为大宗，但是这2、3年来，已经出现了越来越多如Pattern、软件架构、 UML、UP/RUP、Open Source Framework甚至项目管理的相关中文书籍。这种情况代表着计算机书籍的市场，反应出目前业界的问题，也反应出了软件技术演化的需求。

相信有许多老手当初在接软件项目时，是从瀑布式流程的方式开始进行。从确定需求，到使用DFD分析客户访谈所得到的数据并归纳出功能列表之后，大致就开始进行SA之后的工作。然后就定期地和客户review进度，并且在每次的review　meeting之后又会有一些修改以及新的功能。周而复始地重复这个梦魇，直到终于上线后，开始祈祷系统短期之内不要有事就好了。

以前这种方法，是从客户所要的功能项目开始项目的开发，注重的是输入、输出与数据，很程序性地完成需求，就像是一根根直通通的水管，把水运到目的地就好，不需要真正的OOAD，大不了需要OOP，十分地直觉简单。但是由于技术及软件市场的演化，在台湾开始出现了许多现在大家耳熟能详，诸如这几期的软件美学连载里所提到的技术，我才开始感受到，在我们市侩的项目心态之外，软件设计也有其美学之道的。

迷思与挑战
在这8篇连载文章里，笔者从对象（Object）技术、Pattern、架构到UP谈起，因为这些东西是习习相关的，我希望能表达出这些技术的完整性。然而在这些不同的主题里，充满了许多常在技术会议或讨论网站上出现的议题，例如，学UML等于导入OO、Use Case与DFD的比较、OO思维与数据思维、再利用迷思、Iterative与Waterfall等等。以下笔者仅针对部分的迷思讨论，提出个人主观的想法。

学UML等于导入OO？
在之前的篇幅中，笔者都没有提到UML，因为它只是一种提供思维表达的工具之一。虽然有一些在坊间讲相关主题的书籍会以UML的学习做为开埸，不过工具的用途在于被使用，与思维本身没有直接的关系，就像哈利波特的故事可以用许多不都的语言在世界流传一样。UML是用来表达对象观念的绝佳工具，不过，千万不要将导入UML与物件思维画上等号。

Use Case与DFD？
许多人会拿这两种技术来比较，殊不知这两种技术有着本质及面向上的差异，无论学理或实作，都不应该将他们混为一谈。「Use Case」技术纯粹用来「描述」使用者需求，是以「使用人员」的观点来看他们与系统的互动，它比较接近传统瀑布式流程中SA阶段的「确定需求」步骤。 Use Case Diagram则是用UML来可视化Use Case文件的工具，有点像图像化的需求索引，它不是「Use Case」技术的全部。另外，因为Use Case的观点与客户使用系统的方式一致，因此从Use Case来设计Test Case可以比较容易测试出用户所关心的东西。

而DFD是结构化分析中「分析需求」的工具，它是以开发人员的角度来看系统，以数据流为中心，找出相关的程序及数据储存等等，它是瀑布式流程中 SA阶段「确定需求」的下一个步骤。DFD需要有一定程度的客户，才有可能和您一起讨论。当然，与客户的需求确认，Use Case文件或Use Case Diagram，也不见得是与客户确认需求的好方法，端看客户的习惯与能力，有时UI Prototype再加上Functional List就能简单地与客户沟通。

OO思维与结构化分析？
有人会将DFD当作OOD及OOP的开端，但笔者认为由于对象导向思维与结构化分析在本质上的不同，这样做就像让狗来生蛋一样地奇异。这两种思维，有着截然不同的思考出发点，OO是结合「行为」与「数据」，强调抽象并用对象来呈现概念，而结构化分析则是清楚地将这些东西分开。OOA中包含了对象分析，就是找出并描述领域模型（Domain Model），接下来才有办法完成OOD，因此，怎能把DFD当作OOD的开端呢？物件可不是天上掉下来的礼物啊。

OOA中的Domain Modeling是结构化分析不会出现的概念，它也是OOAD中，从「需求」进化到「对象设计层次」中间的重要媒介。在实作上，也有人会把它放到Use Case之前，把它当作整理Use Case的第一步。对于OO的抽象设计来说，Domain Modeling的结果，常会连结到Interfaces（types）而不是实作，这个观念对于领域知识在系统设计上的「再利用」，有着不少的帮助。

在实际的软件市场上，有人会说大部份的系统都在使用RDB，而OO无法与关连性数据的思维整合，因此以结构化的分析来设计会好的多。我们先撇开世面上的OR Mapping相关技术不谈，如此的说法没有考虑到OO的「抽象」能力。笔者在这里当然是不建议各位使用OO的方式来设计数据库，因为如果这样做，即使 DBA不跳脚，系统的执行效率也会有问题。这时可以使用Layer的观念替系统设计一个抽象层，用它来连结OO与数据的世界，把对象设计与数据库设计的专业分开。

Iterative与Waterfall？
不管你喜欢用那一种技术来开发软件项目，都会牵涉到项目进行时的流程，像是UP/RUP和Waterfall。有些人会认为UP/RUP所强调的 Iteration开发方式，不符合台湾的文化国情，所以可能比较适合产品型的项目，而不是一般商业整合型的项目。因为大部份的项目是固定价钱的，使用这种流程会导致成本的增加，因为客户不会另外付费支付多出来的Iteration。不过，在这种情况之下，Waterfall的流程一样也逃不过工期的延长而增加成本的命运，同样的，难道开发产品就可以容许成本的增加吗？因此，这个迷思的重点在于Iteration Plan以及项目管理能力，而不是方法论本身。

结语
在我们所处的环境中，许多的软件项目是偏向商业的数据库系统，而软件公司的接案心态大多都以系统能在最短的时间结案为重心，不太考虑完整售后客服所需的能量、团队经验的累积，甚至是与世界接轨的机会。至于软件项目的买方，常见的状况则是固定价格及时间，但却有不固定的需求。在如此恶劣的发展环境之下，在国内的软件项目市场里讨论软件美学，的确是充满了迷思与挑战。如果一个软件公司或软件人只把自己定位在做小型的商务数据应用项目，那真的只需要一些简单的结构化分析流程以及编程技术，就够处理大部分的项目。然而国际上的各式软件技术及方法论快速地发展着，笔者着实希望我们能够跟上国际的脚步，进而发展出自己的价值。

三大精神，四大核心，让你UP起来
秀出设计，才能让人感受思维的美，而实作出来，才能满足现实的世界，软件设计有其美学之道，它和建筑一样，可以利用「工程方法」，让美学之道和实际需求接轨。在前一篇所介绍的三大UP（Unified Process）精神之下，还有许多在实践项目时会遇到的开发阶段和工作科目，其相互的运作流程与软件设计之间的关系，是最难想象与实作的部份。关于这些开发阶段与工作科目，我想曾经读过这个方法论的人都会很熟悉一个诡异的波浪图（如右图所示），这张图是UP的精华，不过我个人觉得对于刚踏入UP的人来说，如果没有好好地理解它，这张图会像个镇煞避邪的石敢当，反而就会把大家吓跑了。

简单地来解释这张图，它的X轴所代表的是四大开发阶段以及许多的反复期（Iteration），也代表着时间轴；Y轴则代表工作科目，而在此图表上的大大小小波浪，则是代表项目随着时间进行时，各个工作科目在各开发阶段上的比重，其实这也隐喻着这四个阶段有着不同的核心任务，只要能掌握这些灵魂，执行UP就能简单不少。

是大饼，还是焦油坑－－Inception阶段
项目的一开始，绝对不是一头埋进成堆的客户需求之中，然后埋头苦干地开工实作，因为你不一定会知道，前面的路是个焦油坑还是一块大饼。虽然有时迫于情势，就算是个焦油坑项目，我们还是得做，不过起码我们可以先实行一些预防措施，例如使用符合成本的技术、资源，或者尽早另觅他处等等。

在这个阶段的时间会比较短，因为重点在于确立产品范围，了解项目关系人是否对项目愿景有基本的认同。因此，在这个阶段里，我们可能会只先列出大部份使用案例的名称，描述其中小部份，但却非常重要、有疑虑或者风险较高的使用案例，甚至建立一些简单的使用者界面prototype来验证需求，然后针对一些不确定或者难度高的技术做POC（Prove of Concept）测试。

真正的需求开发以及软件架构的建立，会是在下一个阶段，而在Inception阶段可能的唯一一个反复期（Iteration）里，是要能了解项目未来的路是通住天堂，或者是条令人心惊胆寒的天堂路。

给我架构，踏出美的第一步──Elaboration阶段
当完成了Inception阶段的工作并通过里程碑（milestone）的查核后，也不代表我们就可以放心地往前冲了。在这个阶段里，我们必需要厘清大部份的需求，但最重要的，是要能产出一个能够解决高风险元素的「架构原型（architectural prototype）」。这也是整个UP流程和传统的开发流程最不一样的地方了。

实作此阶段的关键概念就是要进行短时间且长度固定的多个反复（Iteration）、优先厘清重要或高风险的需求，然后及早开始写程序并测试，最后再将测试结果以及需求变化回馈到下一个反复（Iteration）之中。除此之外，我们要记得另一个重要观念－「建立软件架构的关键在于能够提供软件系统未来实用而稳固的发展基础」。

架构原型只是整个系统的骨干及部份肌腱，因此，及早开始写程序的意思是在于及早开始实作「架构原型」，并不是开始实作出系统的大部份哦。因为唯有不断地透过开发、测试人员，甚至是使用者的回馈，架构原型才能真正的确定系统风险的解决，并成为下一个阶段的稳定发展蓝图。

实作这个阶段使用到许多软件美学的重要技术及设计工具，例如，使用Use Case来描述需求细节、利用Domain Modeling来找寻软件对象灵感、利用Pattern来设计软件架构中的逻辑观点等等。因此这个阶段可说是整个流程的重心，也是软件架构师最重要挑战以及最大的舞台了。

开工、发包──Construction阶段
这个阶段会是整个流程里面最热闹的一段时期，因为在成本可行并且有计划的情形下，会有越来越多的人可以在这个时期里加入团队，甚至可以多个团队一起工作，包括外包。为什么呢？因为上一个阶段的结束，代表我们已经了解了大部份的需求，解决了高风险的问题并且完成软件架构原型、软件架构书（SAD）以及架构原型的系统设计相关文件等等重要产出。因此，我们也比较能预估项目接下来所需要的工作量及时间，而现阶段的开发团队可以依样画葫芦地照着架构原型的程序代码及其程序风格来开发建构系统其余的部份。

软件架构师在这个时期所扮演的角色就是开发团队的领导以及教练了。软件架构师此时必须掌握开发团队所发展的程序是否遵循着软件架构书所设计的大方向，并且时时利用架构原型都各部份为范本，教导开发团队来建构系统尚未完成的部份，如此这般的，一个反复一个反复地往下走。这个阶段的工作有时会有点像在填补Elaboration阶段所建构出来的骨架的肉，也就是架构原型以外的所有东西。因此，这个阶段的成功，和上个阶段的结束，有着非常重要的关系，而这个阶段的后期，团队也该完成一些如使用者手册等文件以及alpha测试，以便能替下一个阶段的beta测试做好准备。

完美的收尾－－Transition阶段
在经过前面三个阶段之后，在这个最后的阶段当然就是要做个漂亮的收尾了。这个阶段的主要目的是将系统变成真正的产品，工作的内容可能包含了最后测试、针对测试结果所做的响应、展示、教育训练以及将产品交付客户等等。最后，当然就是希望能撇开一些可能的政治问题，顺利结案并且拿到钱了。

在执行这些开发阶段时，还有一个重要观念：每个阶段的结束，都是为了下一个阶段的开始，因此每个阶段的结束，都会有一些确实的，可以衡量的产出物（deliverables），例如，文件、程序代码、测试结果等等，这些产出物就是下一个阶段最重要的输入，这是个容易影响UP执行顺畅度的观念。

近两期文章的种种，仅是极精简的UP内容，UP方法论的细节的确很繁多，不过，规则永远是人定的，只要能理解UP的三大精神及四大核心，再找出一个适合你所属团队的工作科目，才是真正的王道。

为什么需要流程？
虽然之前的文章都在谈论软件美学，但是在这篇文章，让我们暂时先丢开这个浪漫传说，回头来看看真实世界的软件项目。公司接案的最大目的是什么呢？当然就是要能赚钱，这也许很俗气，不过却是事实。软件开发的项目有四个重要的变量－成本、时间、质量及规模，如果以企业生存游戏的角度来看，那成本一定是最难控制的变量，而质量是客户坚持的，时间是客户规定的，相对之下，只要能符合客户的业务需求，最容易控制的，我想就是「规模」了。因此我们可以假设在质量及时间不变的情况之下，若受到规模冲击的影响变小，则成本也会下降，而在成本越小的情况下，公司的获利当然也就会越多了。

只要能积极地管理规模变量，团队及客户对于其它三个变量的控制能力也能增加。因为通常客户不会太清楚他们要的是什么东西，真正的规模到那里，当然，这不是他们的错，软件的本质本来就是恒变的需求，而软件项目的开发本来就常处于「一寸以前，才是光明的」的状况，开发团队必需要协助客户，帮助客户找到他们真正的需求，帮助他们厘清可能的风险，一寸一寸地走，一点一点地将整个光明都找出来。

当一个团队千辛万苦地将一个软件项目完成后，最重要的事情除了收钱之外，还有什么呢？答案是「累积与再利用」，如果你是老板，你会不会希望看到下次在接到相似类型的项目时，开发团队可以利用更少的时间完成项目呢？因此，如何让团队能够在每个案子产生一个正向的回馈，让下次同类型的项目可以减低规模的冲击，进而减少成本，最后提高项目的利润，是一个非常重要的课题，而软件组件重用（Reuse）的技术也就呼之欲出了，这时，以Pattern为基础，并且以软件架构为中心的开发方式将是关键。这整个过程，势必需要一个软件开发流程来指挥协调。

各式软件开发流程
最常见的软件开发流程就是线性或「瀑布式」的旧式流程，当然还有相当有名的XP（Extreme Programming）以及我们要讨论的UP（Unified Process）等等。

软件开发的方法论有很多，各有其巧妙及适合的时机，端看开发团队的能力、项目类型甚至是文化国情。笔者就曾在某大电信公司，遇过某个开发团队所采用的是「课长流程」（就是以该单位主管心中的喜恶为主的「无定向」开发方式）！相信这在台湾也算是一种流行的开发流程吧。

「瀑布式」的旧式开发流程常见的做法依序是收集需求、系统分析、系统设计，最后根据设计结果来实作。这会衍生出一些职位如系统分析师（SA）、系统设计师（SD）以及「最底层」的程序员（Programmer），因此除了开发步骤的每一个阶段是线性的走向之外，时常连开发工作也会依职位的高低而变成官僚作风。有时在同一开发团队的SA甚至会做出和Programmer实作不同的需求文件，因为真正的需求及设计最后是靠SD，甚至是 Programmer以及客户的「提醒」才找出来的。如此的开发方式，不容易应付恒变需求的软件项目，更不容易累积可再利用的软件组件，而开发工作的责任及角色虽然和经验累积有关，但并不全然和职位的线性关系划上等号，因为每一种角色都有其专门的责任及技术深度。

UP精神
「统一流程（unified process）」对于「管理规模变量」以及「提高软件组件的重用」有着不错的影响，而针对线性流程无法确实掌握需求与实作关系的缺点，也有不错的解决方式。我们暂时抛开在流程里常会令人心烦的工作项目及开发阶段，先体会一下UP精神，这将有助于UP的实作。

UP精神最主要围绕在三个方向，分别是Use-Case-Driven、Architecture-Centric以及Iterative & Incremental。以下我先简述其重要观念，针对工作流程及项目的协调运作，将在下一篇的文章提及，而关于UP的详细内容，笔者建议大家阅读「The Unified Software Development Process」这本书。

所谓的Use Case「Driven」，就是指团队在执行整个流程时，都是从Use Case开始所有的工作项目。这样可以让开发团队在每次的工作循环里，以聚焦在客户的需求为出发点，避免迷失在项目的规模中。Use Case是大家用来发掘并记录功能性需求的一种技术。换句话说，它的功用在于找出对使用系统的参与者有价值的需求，并且能产生有价值及看的到的结果；例如，买机票、处理退货、结帐等等。而Use Case也可以帮助我们开发使用者界面，让客户清楚他们未来要如何使用系统来完成他们的工作，帮助客户找出他们真正要的东西，也帮助大家控制「规模变量」。

Architecture-Centric的概念最容易被想要实行UP的开发团队遗忘。通常大家只会注意到UP所定义出来繁复的工作项目，并拘泥在工作项目的意义及执行时间点，殊不知以软件架构为中心的开发观念是UP在执行对象导向项目的支柱。

软件架构的功用及开发步骤在之前的几篇文章之中已经提过了，在此我只再强调其对于「提高软件组件的重用」及「提供稳定的开发基础」有着重要的影响。在Use Case Driven的观念下，Architecture的开发是以支撑Use Case需求为目的，而Architecture的建构则会影响到那些Use Case可以被实现。

Iterative & Incremental意谓着透过回馈与调整来拥抱改变。在软件需求的恒变性之下，我们需要反复式的开发，让软件可以在一连串的建构、回馈与调整的循环之中逐步完成，这是线性式的开发流程所欠缺的。而这种短期、固定时间长度以及小规模的开发循环之下，可以让软件开发的复杂性变小，我们也可以用Risk- Driven的观念，先开发风险比较高的部份，让早期的进展减缓风险可能带来的冲击。

大部份的人也许会觉得UP是一部很笨重的方法论，拿来做研究还不错，但是对于用在实际的项目上，则是望之却步。其实在了解UP的精神后，再找出自己团队或者项目适合的开发活动与工作流程才是真正的关键。UP其实可以很敏捷，也可以很繁重，端看团队真正的需求。