Baseline an executable architecture early on
        很多项目风险与所选用的框架有关。因此你总会希望选择正确的框架。实际上，能够把基线建立在一个功能性框架上，就是说尽可能早的设计、实现、测试这个框架对于一个成功的项目来说是很关键的。因此RUP把它作为一个精化阶段的主要目标，比如在一个有四个阶段的项目中，这个过程会占到两个阶段。
        首先，框架对我们来说有什么意义？框架包含一个软件系统的绝大多数重要的模块和接口--即子系统和子系统的接口、组件和组件的接口。这个结构为系统提供了一个“骨架”，它会占到最终代码的百分之十到百分之二十。这个框架同样包含所谓的“框架机制”。就是指对于一些通用问题的经典解决方法，比如持久化机制和垃圾回收机制。要想得到一个正确的框架是相当困难的，因此你需要选用你手下最有经验的人来从事这项工作。
        当手头有了合适的框架以后，也就相当于拥有了一套健全的模块或组件，进而为最终的产品做好准备。同时，遵照RUP的迭代过程，你的团队可能已经在分析、设计、实现以及测试中得到了很多重要的经验，所以你需要牢牢地抓住这些“无形的财富”来使你的系统不断完善。以一个可以运转的框架为基线，你可以更加准确的估算出项目所需要的资源和时间。掌握了这些重要的信息，你就可以优化你的资源配置并通过对边界的管理来更好的与商务运作相配合。
        一个正在运转的框架，传达了这样一种信息：就是你已经处理好了大多数建造系统的难点。现在想要向项目中引入一个新成员，变得更加容易；边界已经被那些关键的组件、基本的接口定义好了；并且框架机制已经开始被越来越多的使用，普通的问题可以很上手的解决。

Build your system with components
        随着功能分布到系统的各个部分，数据也随着功能被随处堆放。结果导致维护系统需要很大的花费。比如如果改变数据的存储模式，将会给相当数量的功能造成压力，并且通常情况下很难知道在这个系统中到底哪些功能会真正受到影响。
         另外，这种开发模式把数据和施之于数据上的一组操作封装到一个组件里面。当你需要修改数据的存储方式，又或者想要修改数据的处理方式的时候，这些变化都会被组件所隔离。这回导致系统变得更加具备“柔性”。
        和组件打交道，使用它所能提供的功能和代码，你只需要知道组件的接口即可，你完全不用关心它内部是如何工作的。更甚至一个组件可以被完全重写，而不会给当前的系统和系统代码带来任何的影响，当然前提是接口不能变动。这就是面向组件开发的重要特色，我们叫它“封装性”，这使得组件更加易于重用。
        组件同样可以被另外一个组件所集成，从而使集成者具备更加高级的能力。连接、封装以及大型组件的出现更加促进了重用带给应用程序开发的生产力。
        组件技术同时也是WebService的基础。所以WebService几乎具备组件的一切优点，同时它还有“跨平台”的特点。

Work together as on team
        人是一个项目中最宝贵的资产。软件开发越来越变得像是一个团队竞技，并且迭代式的软件开发方法对你管理团队的方式、你的团队使用的工具以及每一个团队成员的价值都有深远的影响。
         传统意义上，很多公司都有各司其职的小组织：所有的分析人员在一个小组里，设计者在一个小组里，测试者在一个小组里，甚至说会在另一幢建筑里。尽管这个组织让有相应资格的人在一起工作，但是会这会削弱交流的效果。这会导致如需求小组产生的需求不会被开发者或测试者所吸收这种情况的出现。这会导致交流上出现断层，附加额外的工作，甚至使项目延期。
        按照职责对人进行划分是瀑布方法时代常用的管理方法，如果你有20个月以上的时间，你完全可以这样去管理。但是现实是你只有一半的时间，甚至只有三个月的时间。你需要一个畅通无阻的平台去让团队进行交流。为了达到这一点，你需要：
在你的项目中打破“职责组”的划分。
确保团队成员本着“我要尽可能的为提高项目质量而工作”的思想参与项目，而不是成天想着只完成“指派给我的本职工作”。
为不同职责的人提供有效的交流工具。
现在看一下具体怎样做：
        项目团队应该包含分析人员、开发人员、测试人员，一个项目经理，若干构架师等等等等。你可能会说对于小项目来说，这样做还算不错，但是对于更大的项目，比如需要50个人参与的时候，这样还合适吗？答案是围绕框架再进行划分。建立一个“架构师”小组，让这些人把握架构；让他们决定自系统和接口。同时，每一个子系统所对应的团队应该包含分析员、开发员、测试员，让他们处在高度交流和高速决策的状态中。他们可以与另外一个团队进行交流，讨论架构方面的问题。

        为了确保分析员、开发员和测试员能够更加紧密地工作，他们需要良好的基础设施。你需要让每个人都能够接触到需求、次品率、测试状态等等。
        在这样一个团队中，不会出现某个成员拥有某样东西的情况。比如你的设计、我的代码等等。因为工作是建立在思想高度统一的交流机制上的。
Make quanlity a way of life,not an afterthought
        迭代的一个最主要的好处就是，你可以尽早的开始测试工作。早在第二阶段--精化阶段，就已经有可执行的软件出现了，它实现了框架。这表明你可以通过测试来印证这个框架是不是工作良好。你可以对框架进行一些负载测试。尽可能早得得到这方面的反馈会赢得大笔的时间并会降低花费。
        通常RUP要求你在实现的时候就进行测试。从注重重要功能实现的早期，一直到项目的结束，软件会逐渐成长并一直运转，同时也被测试了相当的时间。按照这样进行，软件的质量的提高是显而易见的。
        另外一种思路就是在设计时期就抓质量。这意味着把设计和测试紧绑在一起。在设计时考虑系统在测试时会被如何测试，会让你的测试变得高度自动化，因为测试代码可以从设计模型生成。这大量的节省了时间，鼓励早期测试，并且提高了测试的质量。
         质量是关乎所有团队成员的东西，它需要渗透到项目进程中的方方面面。你需要反复查看项目所产生的文档、报告，考虑如何测试一个需求以及如何通过设计来产生测试等等。