RUP（Rational Unified Process）是Rational公司提出的一套开发过程模型，它是一个面向对象软件工程的通用业务流程。它描述了一系列相关的软件工程流程，它们具有相同的结构，即相同的流程构架。RUP为在开发组织中分配任务和职责提供了一种规范方法，其目标是确保在可预计的时间安排和预算内开发出满足终用户需求的高品质的软件。RUP具有两个轴，一个是时间轴，这是动态的。另一个是工作流轴，这是静态的。在时间轴上，RUP划分了四个阶段：初始阶段、细化阶段、构造阶段和发布阶段。每个阶段都使用了迭代的概念。在工作流轴上，RUP设计了六个核心工作流程和三个核心支撑工作流程，核心工作流轴包括：业务建模工作流、需求工作流、分析设计工作流、实现工作流、测试工作流和发布工作流。核心支撑工作流包括：环境工作流、项目管理工作流和配置与变更管理工作流。具体可以参考图1。RUP汇集现代软件开发中多方面的佳经验，并为适应各种项目及组织的需要提供了灵活的形式。作为一个商业模型，它具有非常详细的过程指导和模板。但是同样由于该模型比较复杂，因此在模型的掌握上需要花费比较大的成本。尤其对项目管理者提出了比较高的要求。


　　图1 RUP工作流程示意图

　　IPD（Integrated Product Development）流程是由IBM提出来的一套集成产品开发流程，非常适合于复杂的大型开发项目，尤其涉及到软硬件结合的项目。IPD从整个产品角度出发，流程综合考虑了从系统工程、研发（硬件、软件、结构工业设计、测试、资料开发等）、制造、财务到市场、采购、技术支援等所有流程。是一个端到端的流程。在IPD流程中总共划分了六个阶段（概念阶段、计划阶段、开发阶段、验证阶段、发布阶段和生命周期阶段），四个个决策评审点（概念阶段决策评审点、计划阶段决策评审点、可获得性决策评审点和生命周期终止决策评审点）以及六个技术评审点，具体可以参考图2。IPD流程是一个阶段性模型，具有瀑布模型的影子。该模型通过使用全面而又复杂的流程来把一个庞大而又复杂的系统进行分解并降低风险。一定程度上，该模型是通过流程成本来提高整个产品的质量并获得市场的占有。由于该流程没有定义如何进行流程回退的机制，因此对于需求经常变动的项目该流程显得不大适合了。并且对于一些小的项目，也不是非常适合使用该流程。


　　图2 IPD流程示意图

$news_page $
　　三、流程与技术
　　流程和成功不是等价的。没有流程成功是不可能得到保证，但有了流程并不意味着肯定能够成功。这恐怕是很多迷信于流程的人所不能接受的。但这的确是个事实。记得有个做了将近30多年的需求分析专家说过：即使是一个已经达到CMM4级的公司，也完全有可能做不好需求分析。为什么？技术，技术是成功的另外一个必要条件。好比现在你要从上海到北京去，流程给你指出了短的路径，技术提供给你快的交通工具。两者结合是完美。
　　对于软件开发来说，要保证软件的质量，需要掌握多方面的技术，包括分析技术、设计技术、编码技术和测试技术等等。在国内有一个普遍的非正常现象，是大家觉得只有编程能力才是玩电脑的真正技能。好像造一套房子，其它都不重要，只要砖瓦匠有高超的技能行了。尽管这个比喻会打击很多程序员的自尊心，但这的确是一个事实。我们缺少系统级的工程师，在分析和设计方面的工作做得很不扎实。
　　需求是一个项目的灵魂。模棱两可的需求带来不可避免的后果便是返工——重做一些你认为已做好的事情。返工会耗费开发总费用的4 0%，而7 0%～8 5%的重做是由于需求方面的错误所导致的（l e ff i n g w e l l1 9 9 7）。想像一下如果你能减少一半的返工会是怎样的情况？你能更快地开发出产品，在同样的时间内开发更多、更好的产品，甚至能偶尔回家休息休息。在《软件需求》一书中关于如何进行需求分析给出了比较详细的介绍，RUP中关于需求的指导也是很实用的。
　　设计是能体现一个工程师能力和水平的环节。一个好的设计基本上决定了产品的终质量。设计是把需求转换成系统的一个关键步骤，它需要从自然语言描述的需求中寻找出设计的基础单元，构建出整个系统的构架。在RUP中关于系统构架师和设计师的定位是相当高的。关于设计方面的技能涉及面是很广的，包括传统的结构化设计到面向对象设计。设计人员需要掌握一定的建模技术。UML是国际上比较流行的一种建模语言。在嵌入式方面，SDL也是一种非常好的选择。《设计模式》是在设计思想方面总结的非常出色的一本书，作为一名设计人员（尤其是面向对象设计人员）必须要好好研究一下。但是对这些模式的应用应当讲究一种自然的应用，千万不要因为模式而去设计模式，否则会适得其反。
　　现在的程序员热中于掌握多种编程语言，或者讲究语言的过分技巧化，而往往忽略了编程语言的规范化。不规范的语言应用给程序的可理解性、可维护性以及可测试性带来了大的伤害，进而损害了产品的质量。某公司曾对中国程序员和印度程序员做过一个测验，这个测验要求参加者对一组数进行排序。测试结果发现，印度程序员设计的程序使用的算法并不是优，但却是不容易出错的，并且几个程序员写出来的代码如出一辙。而几个中国程序员写出的代码，有的非常漂亮，很精练，效率很高；有的却很冗杂，还有错误。如果大家是在做研究性的项目或纯粹兴趣性的项目，那么充分发挥自己的编程天才也无可厚非。然而，对于一个软件公司，产品终是要交给用户的，需要遵循的是一个软件产品的开发工程。因此这类软件的开发需要遵循一定的编程规范，毕竟开发的软件不是自己用，还需要和别人的集成，还需要给以后版本重用和维护。
　　测试的技术将在第五节进行阐述。总之流程很关键，技术也很重要，我的观点是：鱼和熊掌，两者都不能放。
　　四、全面质量管理
　　自从Deming的全面质量管理（TQM）原则在日本工业界获得了巨大成功之后，这个原则迅速被传播到了世界各个地方，同样，全面质量管理原则也被应用到了软件开发当中。如前面提到的，软件开发也是一个工程性的工作，因此必须提高整个工程的质量。
　　产业界的大量研究（TRW、Nippon Electric和Mitre Corp.以及其它一些公司）表明设计活动引入的错误占软件过程中出现所有错误（和终的缺陷）数量的50％到65％。根据IBM的研究表明，假定在分析阶段发现的错误其改正成本为1个单位的话，那么在测试之前（设计编码阶段）发现一个错误的修改成本约为6.5个货币单位，在测试时（集成测试，系统测试和验收测试）发现一个错误的修改成本约为15个货币单位，而在发布之后（已经交到用户手上）发现一个错误的修改成本约为60到100个货币单位。同样该比例也适用用于发现一个错误需要的时间。我们可以看下面两条曲线图：


　　图3缺陷代价曲线

　　为了提高产品质量，缩短产品开发进度，节约产品开发成本，必须尽早的进行产品质量控制。全面质量控制要求在过程的每个阶段每个步骤上都要进行严格的验证和确认活动。
　　什么是验证？验证是要用数据证明我们是不是在正确的制造产品。注意这里强调的是过程的正确行。
　　什么是确认？确认是要用数据证明我们是不是制造了正确的产品。注意这里强调的是结果的正确性。
　　IEEE给出的验证和确认过程可以用下图来表示。验证和确认是一个广泛的概念，感兴趣的读者可以参考IEEE Std 1012-1998。


　　
　　图4验证和确认模型

　　五、关注测试
　　软件测试是软件质量控制中的关键活动。业界的统计数据表明，测试的成本大约占软件开发总成本的50％左右。
　　软件测试的目的是要发现软件中的错误。一个好的测试是发现至今没有被发现的错误。传统的软件测试专注于动态测试范畴，如：单元测试，集成测试和系统测试。而测试工程的发展已经进入到了全流程的测试，包括开发过程前期的静态测试。
　　一般我们可以把测试分为白盒测试和黑盒测试。白盒测试：顾名思义，白盒测试应当是透明的。的确，该类测试是根据程序代码的内部逻辑结构来设计测试用例进行测试。那么什么是测试用例？一个测试用例是一个文档，描述输入、动作、或者时间和一个期望的结果，其目的是确定应用程序的某个特性是否正常的工作。
　　黑盒测试：看了白盒测试的解释，我想你很快能猜出黑盒测试是不考虑程序内部结构情况的。事实上也是这样。黑盒测试是根据规格说明书进行的测试。规格说明书记录了用户的需求。比如用户希望在编辑器中增加查找功能，那么我们把该需求写入规格说明书，根据该项要求，直接调用应用程序的该项功能进行测试，而不管其内部是用什么算法实现的。