现代社会中竞争无处不在，产品质量是保证企业在激烈的市场竞争中立于不败之地的根本。任何企业都必需把满足客户需求作为企业发展的源动力，不断地改进产品和服务质量，为客户提供更高品质的产品和服务。只有这样，企业才能够增强自身的实力，在市场上赢得越来越多的客户，在与对手的竞争中逐渐胜出。

　　1 软件就是业务

　　现代社会中竞争无处不在，产品质量是保证企业在激烈的市场竞争中立于不败之地的根本。任何企业都必需把满足客户需求作为企业发展的源动力，不断地改进产品和服务质量，为客户提供更高品质的产品和服务。只有这样，企业才能够增强自身的实力，在市场上赢得越来越多的客户，在与对手的竞争中逐渐胜出。

　　随着科学技术的发展，我们已经步入一个信息时代，绝大多数的企业已经把他们的业务建立在信息系统之上，软件系统已经成为决定企业竞争力的关键要素之一，产品和服务的质量往往是由底层软件系统的质量所决定的，大家可能都有过银行储蓄所由于系统宕机而无法营行的经历，或者是由于电信系统发生故障而无法拨打电话；另外，企业的每一项新业务的推出都有赖于底层软件系统功能的支撑，谁的软件系统能够灵活地适应业务发展的需要，能够迅速地增加功能来支持新业务的运营，谁就能将新业务更快速地推向市场，从而为客户提供更好的服务和更多的产品选择。

　　对于每一个企业而言，提高软件系统的质量就直接关系到生产系统的可靠性和企业的竞争力，因为软件和业务密不可分，软件的品质直接决定了企业能够提供什么样品质的产品和服务给她的客户。所以越来越多的企业把软件开发作为业务流程的一部分，负责软件开发和维护的IT部门也成为企业内部一个最为重要的业务部门，所有其他的业务部门都必须依靠软件开发部门来实现他们的业务，软件开发部门则完全根据客户需求进行业务驱动的开发（Business Driven Development）。随着企业在市场上的业务开拓，对于自身质量要求的不断提高，企业对于软件系统的质量要求也相应提高，高质量的产品和服务需要有高质量的软件来支撑。

　　2 走出软件质量管理的误区

　　我们该如何来保证软件产品的质量呢？很多企业在软件系统上线之前都会对软件系统进行充分的测试来保证其质量，通过功能测试、压力测试、可靠性测试等一系列的检测来发现软件中存在的问题，从而在系统上线之前及时改正这些错误，保证最终交付给客户的产品和服务的质量。

　　但是测试并不是并且不应该是保证软件质量的唯一手段，质量管理大师戴明(Edwards Deming) 早就提出了"停止依赖检验来获得质量"的建议。依靠测试来保证软件质量是一种事后弥补的方法，它只能发现软件产品中已经的缺陷，但并不能事先避免缺陷的发生，为什么不能用"一开始就制造高品质软件"的方式来开发软件呢？试图单纯通过测试来发现软件中的缺陷在软件开发中普遍存在，但这种方式效率太低并且成本过高，并且测试从根本上不可能找出所有的软件缺陷。

　　当然测试是整个软件开发生命周期过程中一个必不可少的环节，它可以对软件质量进行有限程度内的检验，从而在一定程度上保证软件质量。但是，测试不应该成为整个软件开发过程中唯一的质量控制手段，测试人员也不是整个开发团队中唯一需要对软件质量负责的人员；质量保证应该落实到软件开发的全过程，开发团队中的每一名成员都有责任对软件质量负责。

　　3 流程决定质量

　　什么是一个流程？流程就是人们为了达到某一个特定的目标而制定的一些可执行的步骤。什么是一个软件开发流程？软件开发流程描述了在软件开发过程中的人员分工（角色），每个角色应该从事的开发活动以及相关的工件。通俗地讲，软件开发流程就是告诉你如何来组织你的软件开发团队，如何来分配开发任务，在什么时间点应该产生什么样的工作成果，这些工作成果应该附合什么样的质量标准。

　　一个好的软件开发流程可以提高软件开发团队的工作效率，控制开发过程中的风险，保证软件开发进度并且提高软件产品质量。软件质量的好坏基本上是由开发过程中的每一个环节（并不仅限于测试环节）所保证的，过程中的每一个角色都应该对软件质量负责。

　　上世纪70年代，人们为了解决日益复杂的软件开发而造成的"软件危机"提出了软件工程的思想，即要用工程化的方法来开发软件，使得软件开发的整个过程及其质量都是可控的。"瀑布模型"是那个年代最有名的软件开发生命周期模型，它是借鉴传统工业化流程中的质量管理方法，将整个开发生命周期划分成为几个阶段，在每个阶段的结束点设置一些检验点，通过控制每一个阶段的质量来保证最终软件产品的质量。

　　在这样一个开发过程中，很多开发人员有时会不尊守流程的规定而跳过其中的部分环节，例如编码完成过后跳过单元测试阶段的工作，表面上是节约了开发时间，但结果一定是在系统测试阶段需要花更多的时间才能找出这些未经测试代码的问题，或者更糟糕的是隐藏着的质量问题可能要到生产阶段才能暴露出来，从而造成更严重的损失。

　　很多企业都设置有质量管理或质量保证(Quality Assurance)部门，由他们来推动整个企业的质量管理活动，质管部门的主要职责包括：

　　制定高效的生产开发流程
　　监控并保证流程在每一个生产项目中的执行
　　根据客户和生产部门的反馈不断改进流程
　　负责这些任务的具体角色叫流程工程师(Process Engineer)，由流程工程师来指导企业内部的所有软件项目团队尊循所制定的标准化流程进行开发，从而保证软件质量。

　　4 高品质软件，Rational工艺

　　IBM SDP 是 IBM 针对软件开发而推出的一整套解决方案平台，它的全称是 IBM Rational软件开发平台 (Software Development Platform) 。它使得软件开发组织能够更有效地开发软件产品：提高软件质量，保证开发进度，并且控制开发成本。

　　4.1 软件开发的四项基本原则

　　IBM 软件开发平台中集中体现了以下软件开发的最佳实践经验：

　　迭代化开发：有效控制项目风险、增加项目预见性、尽早地发现软件产品中的缺陷；
　　以架构为中心：采用可视化建模技术来构建以构件为基础的系统框架，有效地管理系统的复杂度，增强系统的灵活性和可扩展性；
　　持续地质量验证：在整个产品生命周期中持续地验证软件质量，确保产品满足客户的需求，并且构造一个高性能、高可靠的软件系统；
　　管理软件资产和变更：在整个产品生命周期中管理好企业的软件资产，并对所有的变更请求进行管理，支持虚拟团队的并行开发。

　　这些实践经验是从数千个实际软件开发项目的实践中总结出来的，具有很强的可操作性，对于保证软件产品的质量有着非常重要的指导作用。

　　在IBM 软件开发平台中，这些最佳实践经验被整合在Rational 统一开发流程中，我们称之为RUP (Rational Unified Process)。作为一个软件开发流程，RUP告诉人们应该怎样来开发一个软件，包括：如何制定软件开发计划、确定角色分工、分配开发任务、应该提交的工件及其质量标准等。在多年的软件开发实践过程中，RUP逐渐地被越来越多的软件开发团队所接受，越来越多的项目团队在尊循着RUP的指导下进行着软件开发工作，它已经成为一个事实上的工业标准，RUP是我们软件开发的方法论。

　　4.2 覆盖整个软件开发生命周期的工具平台

　　好的方法也需要优秀的开发工具的支持，IBM 软件开发平台也为项目团队中的不同角色准备相应的开发工具，这些开发工具可以满足软件开发的整个生命周期的需要，主要包括以下产品：

　　由软件开发方法论RUP和软件开发平台中各种各样的开发工具，构成了软件项目开发过程的工艺流程，我们通过这些定义完善的工艺流程来保证软件产品质量，并按时交付产品。

　　5 持续地进行流程改进

　　市场竞争尤如逆水行舟，不进则退。只有认真听取客户的意见，不断改进产品和服务质量来满足客户不断增长的需求，才能在市场竞争中保持领先的地位。任何固步自封，不思进取的做法都是不可取的。为了提供更高品质的产品和服务给客户，每一个企业都有必要不断地改进自身的生产流程，力争把每一件事情都做得更好。流程改进并不是一件一劳永逸的工作，企业管理层最大的责任在于持续不断地改进。

　　5.1 流程改进的标准

　　目前国内很多企业都在应用ISO9000、CMMI、6 Sigma等方法来改进自身的流程，它们的目标都是一致的，都是要帮助企业来不断改进生产工艺，提高产品质量。这些标准实际上都是对质量管理大师戴明的全面质量控制TQC (Total Quality Control) 理论为依据的实践，这些标准各不相同，但是它们殊途同归，都是为了帮助企业提高质量。其中国际化标准组织制定的ISO9000较多应用于生产制造型企业，在软件团队中应用较多的是CMMI和6 Sigma。

　　CMMI是美国卡耐基梅陇大学软件工程研究所制定的一个企业能力成熟度综合改进模型，该模型根据企业在质量管理能力上的强弱而将企业分为不同的成熟度等级，获得CMMI成熟度能力级别的"认证"成为很多企业追求的目标，实际上该"认证"是由SEI授权的主任评估师出具的一份关于该企业在某一段时期内的生产流程是否附合CMMI模型规定的评估报告。企业不应以追求达到某一CMMI成熟度级别为最终目标，我们要达到的实际目标是不断地改进流程以提高质量，CMMI的成熟级别只是让企业对目前自身所达到的质量管理水平有一个量化的认识而已，从而帮助了解自己还有那些方面的差距而需要做进一步的提高。值得注意的是CMMI模型中第5级所关注的主要问题就是不断地优化流程，以帮助企业获得更高的质量。

　　6 Sigma 则定义一个流程改进的具体方法，称之为 DMAIC 模型：

　　定义 (Define)
　　定义问题并确定重要的内容
　　度量 (Measurement)
　　度量当前过程
　　分析 (Analysis)
　　分析错误和潜在的解决方案
　　改进 (Improvement)
　　通过实现解决方案来改进过程
　　控制 (Control)
　　通过确保这些改进被继续保持下去来控制改进了的过程
　　无论是部署IBM Rational软件开发平台还是实施CMMI的过程中都可以应用6 Sigma的方法来持续地改进软件开发流程。

　　5.2 走出CMMI实践的误区

　　国内部分软件企业实施了基于CMMI模型的流程改进之后，普遍感觉到自身的开发水平和产品质量并没有得到预期的提升。其中涉及到几个方面的原因，一个就是流程改进措施是否落到了实处，是不是开发过程中每一个环节每一个角色都切实执行了流程改进的措施；而不是仅仅将流程改进落在了容易体现成果的"文档"上，从应付审查的角度来说"文档"是最有效的证据，但这并不企业进行流程改进的目标。

　　另一方面我们应该充分认识到流程改进的复杂性，改进意味着改变现有的工作习惯，如果没有让所有的团队成员统一认识到流程改进的前景目标，可以想象这种改进工作一定会受到来自各方面的阻力，从而影响改进的效果，或者使流程改进流于形式。另外我们也看到一些CMMI流程改进的速成案例，一个软件企业可以在一两年内就可以完成CMMI模型中几个成塾度级别的飞跃，可以想象这种大跃进的实际效果如何。

　　第三就是CMMI 为软件团队的流程改进提供了一个系统的框架，但是它所提供的只是一个流程框架，在实践过程中还需要具体工程技术的支持。如对于CMMI 中的每一个目标，CMMI 建议了一些实践来达到该目标，但这些实践只是提出了在具体实践过程应该注意的事项，并没有列出具体可采用的工程技术。因为作为一个标准，它不可能局陷在某一特定的工程技术之上，不同的软件组织可以采用不同的技术手段来达到相同的目标。

　　实际上CMMI模型有两种不同的表述形式，阶段式表述和连续式表述，后者建议企业根据自身的情况，优先改进自身最为薄弱的环节，这种改进可以循序渐进的，相比前者每次改进的步骤都比较小，从而更易于见到实际效果。由于众所周知的原因，绝大多数企业都选择CMMI的阶段式表述模型来指导流程改进工作。

　　5.3 保证流程改进的效果

　　应该如何保证流程改进的效果呢？我们建议软件团队可以在基于CMMI模型进行流程改进的同时，同时导入RUP流程。CMMI实施过程中要求软件团队改进自己的流程以满足模型中的标准规定，对于任何一个团队而言，制定一个完善的开发流程是非常困难的，因为这个流程既要能满足CMMI模型的定义又必须是一个实际可操作的流程。而RUP是从软件开发的实践经验中总结出来的流程，它是一个实际可执行的流程；同时RUP又是一个非常完善的软件开发过程，RUP中几乎所有的内容都是与CMMI模型相兼容的。当然CMMI模型的范畴要比RUP更广一些，不过当软件团队导入RUP流程之后，再去对照CMMI模型进行改进的难度和工作量就不大了。

　　CMMI流程的实施也需要落到日常开发工作的每一个环节，IBM 软件开发平台正好作为一种特定的工程技术解决方案为 CMMI 流程改进提供了一种具体可操作的实践手段，CMMI 中很多过程域都有相关的Rational解决方案与之相对应。例如：CMMI模型中的"需求开发 (Requirement Develop)"这一过程域的目标之一是要"分析和确认需求，并开发一个所需要的功能性定义"，IBM软件开发平台中就提供了具体的用例建模技术来完成这方面的工作。另外，流程的标准规范也需要在工具中固化体现，人对于规范的执行往往是有弹性的，但工具平台就可以克服人的这些惰性，从而保证流程规范在软件团队中得到彻底的执行。

　　总之，IBM Rational 软件开发平台可以与CMMI、6 Sigma这些业界标准一起配合使用，全面改进软件团队生产流程，从而生产出更高品质的软件产品。