IBM杰出工程师Bran  Selic

领域热点主题概述

    【IT168现场报道】今天下午主要是三大块，第一块解释一下问题背景，什么是嵌入式系统，什么是工业系统，下一步谈一下IBM  Rational的方面，最后介绍一下我们相关的工具架构。所谓的嵌入式系统，大家看到的工业系统是由软件控制管理硬件的由系统构成的系统。这是嵌入式系统应用的主要的一些领域，航空航天、电信、汽车等等。所以我们在嵌入式系统开发的方面到底有哪些问题呢，第一个是有关需求方面的，需求可能是现在大家知道太复杂了，可能有一些需求写的不够完备，有的可能太过于完备，以至于它们之间太矛盾了，或者之间发生了变化，是我们经常遇到的问题。
   

    另外一个问题就是我们在开发嵌入式系统过程当中，运用了不同的开发流程，不同的工具，涉及到软件和硬件，有的时候想知道硬件系统设计发生的变化，对软件发生的影响，这是我们开发的时候遇到的难点。那么另外在开发嵌入式系统的时候，我们必须处理很多很复杂的一些因素，比如说要处理容错机制，怎么样处理这种分布性的要求等等，还有响应时间，这些给我们的开发带来很大的风险和困难。还有治理的问题，即便是在英文单词Governance里面也是一个很复杂的概念，下面会给大家做一个详细的解释什么是Governance？另外我们现在开发越来越趋向于分布式的团队，这家空客的A380飞机设计的时候是法国和德国两个分布式的团队开发的，他们运用的工具和方法不兼容，导致这个项目的一再延误，导致上亿美金的损失。这是我们开发软件的现状，我们做不同的工作使用不同的工具，硬件可能用CAD工具，软件还有软件开发的工具，项目有项目管理的工具，它们之间的耦合非常脆弱，它们之间可能进行用一些文档进行耦合。因为它们之间的耦合很松散的，你的信息从一种工具转入到另外一种工具的时候，不可避免的会引入一些错误，值得指出的如果能够自动化的话，对这个方面有很大的改善的。所以这里给出Governance治理的一个定义，治理就是在公司企业内部建立的一整套机制，由它来保证公司日常运营中做的任何工作，跟公司的策略、目标相一致的，那么并且要保证我们日常所做的工作，要符合公司的一些规范、一些法规等等。那么我们这边要讨论的就是Development  Governance，它指的是怎么样治理整个开发的过程，我们的开发的话必须跟公司的策略相一致的。
   

    所以接下来我们看一下策略方面的，在这里把我们开发过程分成几个层次，最下面的这个层次是非常具体的一些开发活动，开发一个组件也好，开发一个模块也好，这里涉及到的个人用到的开发工具。所以这些方面看到的工具是两类，电子电路的设计，机械的设计，另外一个方面我们看到的软件部分的设计工具，Rational是涉及到在软件方面的领域。当然我们要成功的开发一个嵌入式产品，光看软件或者硬件是不够的，我们必须把眼光上升到一个层次，把整个嵌入式在系统这个级别上升到一个层次。但是作为一家企业来讲，你光开发单个的产品是不够的，你要上升到更高的一个层次，产品家族，产品组合这个层次，这个层次上除了开发产品之外，还要关心市场的需求等等，很多方面的因素。所以我们开发一个嵌入式产品的话，涉及到所有的三个层面。所以我们需要一整套的工具管理整个的开发过程。所以IBM  Rational专注的领域是红框的领域，我们提供工具、服务、方法。至于在我们不涉及的这个领域，我们的策略就是我们想办法把我们的工具跟其他的工具来进行集成。

    所以这边列出的是我们针对这个领域的四个策略，第一是把我们可视化建模的优势引入到嵌入式的领域，我们的MDSD的嵌入式系统开发，第二我们采用标准的规范的一些流程和框架，第三我们采用开放的流程控制项目的风险，最后我们采用一些非常客观的评价手段评价我们的开发是不是做得好还是坏。下面我们逐点给大家详细地解释一下。其实建模的概念并不是一个新的概念，是一个传统的工程技术，建模主要的目的就是要把管理复杂度，把复杂的系统要简化，解决问题的时候，把你的注意力集中到一些相对简单的侧面上。所以建模主要的解决的问题就是复杂度的问题。模型就是抽象的，比较复杂的东西用一个简单的东西把它抽象出来。模型这个概念在软件工程里面是一个什么样的作用，这边举了一个例子，大家看到的是我们先设计一个状态机，然后我们转换成一个代码，就是这样一个Switch语句。在这个转化的过程当中，很容易引起一些问题，把这个Bug带进来。人在看这个东西的时候，可能对模型的认知更容易理解一些，这种转化工作有一个工具自动化的来做，可能更加有效。如果我们建的模型更加复杂一些的话，那么你在把它翻译成代码的时候，有一些问题，而且这个Bug的话就更多了。在这个过程当中，其实工具自动化的代码生成的工具可以扮演一个很重要的作用，在转换的过程完全是一个机械的过程。所以这就是我们引入模型驱动软件开发这个概念的一个原因。那么MDD这种方法的话，主要基于两种基本的原则。第一点就是我们要尽量地提高这个抽象层次，使得我们能够更加专注于描述问题的本身。那么第二点就是尽量地用一些自动化的手段、用工具帮助我们把高抽象度的模型转换成为比较具体的代码。这个模型相当于我们以前引入的第三代语言，高级语言一样，这种转换的过程可以很大的提高我们的生产效率。这里给大家举一个例子，一个主要的电信设备供应商，采用的模型驱动，开发的这种技术，它自动生成的代码达到450万行代码，这个自动生成的代码，在性能方面的表现可能比手工的代码大概正负15%的总偏差。那么生产力的提高的话，大概有关质量和生产力的提高，大概80%到200%之间。这里是一些其他的例子，从卡拉OK唱机到核弹的设计等等。我们把模型驱动开发这种概念从纯软件的开发进一步推广到嵌入式开发的这个领域。当你在设计一个模型的时候，实际上你设计的系统跟具体的实践技术是没有关系的。那在这个过程中，你所构建的模型，扮演的就是我们平时所说的文档的角色，这个里面我们用模型取代了这个文档，并且提供了一种更加自动化的开发过程。

    那么在这里就是我们谈到的概念就是系统模型，就是对你的目标系统的一个刻划，是独立于任何具体的实现系统的技术。那么这个领域有一种新的基于UML的语言叫SysML，已经成为新的建模里面的标准。如果你熟悉UML的话，这种SysML的语言跟它很相像，借用了很多UML当中的语言，像状态机，像持续图等等。这里所增强的部分第一在需求方面，它能够描述需求之间的关系，那么在另外一个方面，它可以描述系统的不同的模块之间的功能上的关系。所用到的工具就是从我们的工具叫ISA的工具，还有一个SysML，就可以做这种类型的设计。有关标准的话，早上已经谈了很多，我们也参与了很多标准的制定，并且我们的工具基本上都是满足这些标准的。那么在工具方面我们采用的是一个更加开放的策略，我们并不强调我们的用户把所有的工具集中到Rational平台上来，我们采用一个联合的方式，跟我们的合作伙伴一起合作来提高这种开发的能力。所以我们采取了策略就是跟业界一些最好的供应商来结成合作的关系，能够使他们的这些工具能够插入到我们的工具平台上来。
   
    观众提问：刚才的那张图下面的那块的模拟的，看起来的两个观点完全是不一样的，能不能解释一下到底有什么差别，或者以后做什么结合，还有以后的发展？

    Bran  Selic：因为刚才的问题是说在最下面的层次的话，我们平时讲的系统建模的话，主要在最下面的层次描述这个软件和硬件的驱动关系，至于跟上面的层次的关系的话，因为首先描述这种关系的话，是UML和SysML，都是用这种描述语言的话，可以很好的描述它们之间的关系，我们现在推荐的是Jazz的技术，可以更好地整合各种不同阶段的模型，可以很好地进行关联起来。在这次大会上，大家有很多次机会听我们谈到这个Jazz的新的技术，大家可以访问Jazz.net这个网站，可以了解更多的有关Jazz的信息。Jazz不是一个产品，是下一代的新技术的框架，它使得不同的开发团队可以很好地在一起进行实时的协作。Jazz的另外一个目的可以从项目开发的整个过程当中，更加有效地抽取一些我们想要的数据，通过这些数据可以更加客观的描述项目的状态和项目的进展情况。Jazz的另外一个作用就是回答刚才的问题，它可以很好的把开发过程当中，采用不同的工具，可以组建的话这些信息的话可以很好地进行关联起来。更重要的采用Jazz技术的话，可以使你的项目真正采用针对你这个项目的特定的工作流程来进行工作，并且它可以帮助你来监控在项目的进展过程当中，是不是按照这个流程来走的，有没有什么偏差。跟Eclips不同的话，大家看它是一个总线，你可以在上面插各种各样的插线，在上面又分了一层可以成为一个框架，这是理解项目的过程的，所以说你插入一个ISA模型的话，插入一个电路设计模块的话，就知道这个硬件设计怎么样的，可以在两者之间建立起关联。

    第三个基本点就是我们采用迭代化的开发流程来控制风险。那么迭代化开发跟传统的项目开发流程相比的话，传统的流程大家看上面这条红线，就是在整个项目周期中，一般来说一个项目开始的时候风险比较高的，传统的这种工作流程的话在整个项目过程当中，可能风险始终维持在一个高的水平，只有你做系统集成系统测试的时候，在那个时候会发现很多的问题，导致你的返工，迭代化开发的话，试图在项目的早期尽早把风险降低，从而使我的项目周期的话，大部分时间处于一个低风险的状态。我们采用的方法我们要做到的目的就是要尽早地看到哪里有风险，并且要对风险的严重性、紧急程度做出一个客观的预测。那么我们这里要介绍的一个方法，传统的方法就是一开始的时候，由项目的干系人来提出各种需求，然后在这个基础上抽取出系统的需求，然后逐步地细化，细化到概要设计、详细设计，是传统的瀑布式模型开发的过程。我们借用了刚才讲的软件开发里面模型驱动开发的方法，那么我们在系统需求这个层次，我们会首先把系统需求进一步细化，而且在这个级别我们来设计一个系统模型，在系统模型的级别，我们判断一下系统模型有没有很好地执行系统需求所定义的功能，同时在这个过程当中，我们会对系统需求来提出一些反馈，可能系统需求有不对的地方可以及早改正这些不正确的需求。并且在这个层次上，我们还可以找到及早发现一些关键的风险，并且及早地解决这些风险，不是在这些风险解决之前，就急着进入下一个层次的设计。所以你会看到这样的话一层一层的逐步地细化我的设计，直到最后得到我的实现。大家看到传统的瀑布式模型的开发到这边的直线，还有不同的层次的话做这个模型，及早地发现这些问题。最后一点是怎么样客观地进行一些对项目过程的评价。我们这里建议采用一些自动化的软件工具来帮助我们统计一些客观的评价数据，不是通过问某一个人而得到一些非正式的主观的一些答案。在这个过程当中，除了刚才提到的Jazz平台之外，除了帮助我们收集相关的数据之外，我们还可以称之为模拟的技术，可以使我们在模型这个级别可以模拟目标系统的执行，这里大家看到的是我们的一些合作伙伴提供的插件，使得我们能够去做这种模型级别的这种模拟的工作。或者你可以采用数学的方式，这里采用的技术已经被称之为MARTE的技术，已经在这个模型里面用数学公式表达的这种精确的描述，来帮助你描述这个模型。你可以精确地用一些数据来限制你的系统的一些性能的描述。所以这个里面举一个例子，你可以用 我们的RSD这个模型，在这个模型里面加入这些MARTE的限制性的描述，然后你可以由这个模型生成一个比如说排队系统，你可以模拟排队系统的模型帮助你来判断排队系统的性能到底怎么样。现在跟你的传统的开发方式相比，你原来在脑子里面来判断，你这个系统正确，大概性能怎么样，这里采用一些更加数学的和工具自动化的方式来帮助你做这个方面的判断。所以这是我们的工具架构的一个图，以前我们在Eclipse上面有一个插件，构建我们的平台，这个价值平台可以了解项目的数据，可以更好地整合不同的工具，以达到它们之间的联系。那么这里大家看到这个架构实际上是我们一直讲的SOA架构，这个里面都有一个SOA的接口跟它的总线进行互联，里面还有一个库，称之为语义链接，可以跟硬件模型关联起来，当任何一个部分发生变化的时候，会告诉你哪一部分受到了影响。

    观众提问：第一个问题刚才讲的嵌入式的开发在航空航天方面的运用是非常明显的，我想说一些模型化的问题，怎么样利用这个工具支撑这个模型，刚才讲的没有具体的，只是一种主意，但是现在对工业来说，如果实施的话比较关心这个问题。第二我们刚才说的IBM要收购一家公司，他们有一个产品，那么未来的发展会朝着什么样的方向发展。这也是IBM产品战略的一个方面。

    Bran  Selic：首先怎么样去做实际的开发，从方法论的角度来说，我们有Rup  SE这样的方法，包括刚才提到的模型驱动的系统开发的方法，来支撑怎么样把这些理念落到实处进行开发。另外有这样一本书，一起跟别人合写的一本系统的、有关嵌入式开发的一本书，大概两三个月就可以出版了。

    谈到第二个问题，我们为什么要收购这个公司呢，因为在工具的领域我们双方的认同是一致的，我们对工具发展的方向，一个前景的预测是非常接近的，所以我们决定收购这家公司，至于以后产品怎么样发展，因为收购还没有完成，所以有一些法律方面的限制，现在还不能探讨这个方面的信息。

    观众提问：我是做嵌入式系统设计的，我关心一个事后的问题，我的嵌入式系统已经完成了，因为在运用过程当中各种条件是不可预料的。一个系统的建设程度跟系统的运行之间有一个关系，可能这个系统运行着，但是非常依赖于一个软件或者硬件。这个问题怎么解决呢？

    Bran  Selic：基本上讲的跟我们介绍的方法可以解决一部分问题，我们强调的系统模型的设计，你在模型的级别，在正式的系统开发出来之前，可以利用MARTE的一种数学的方式，在这个方面进行运行，帮你及早地帮你找出逻辑运行方面的问题在一定程度上可以解决你刚才提出地问题。谢谢大家！
   

东软公司案例分享

东软公司　王爱民博士

IBM印度公司软件开发的管理经验

IBM印度公司技术负责人 Ameeta  Roy女士

    【IT168现场报道】这几本书主要是说关于世界全球化的趋势的问题，主要讲外包的。基本上对于一个外包项目来说，我们在这个片子上可以看到，这个项目在美国的话，一个软件开发的项目的一些工作，比如说需求和建模，还有一些设计会放在本土做，因为是希望一些团队跟一些客户在一起做一些分析的工作，基本上把一些代码、测试还有验证的工作会放在印度去做。如果在印度做工作的话，需要做测试、集成等等的工作，对印度团队还是其他团队来说都是需要做的事情。

    比如说项目开发在美国做的，这个是在On-Site完成，这个后面的工作会分成两个地方，一个是在多伦多，还有一个在印度拜嘉罗尔，是因为跟在美国时间是在一个时期的，可以做一些大家上班的时间可以做互相传递的工作，就是进行一些传递。这个时候美国下班的时候，可能是印度下班的时候，可以做相应的编码测试的工作，有了结果之后，第二天美国上班的时候可以看到前一天编译的结果。实际上对于项目来说，是一个多点的开发，那么现在我们看到另外一个趋势印度会越来越把设计的工作，会逐渐移到印度去做。如果我们做外包开发的时候，最终的结果可以帮助我们多少成本，最终的结果是30%。首先是70%我们得到的，是因为外包的话到印度的人力成本是最低的，是因为有70%的节省，因为我们做外包的结果选择外包商，我们要跟他们签合同，这些会有另外的成本，所以会减去20%，因为我们到印度开发的话，同时我们看他们的状况，又会减去节省的20%的成本，实际上可以得到一个30%的节省。

    那么我们刚才看到的是成本的降低，对于印度外包来说还有另外两个优势，一个是它的生产力，以及它的系统开发出来的质量。因为印度很多的外包公司基本上是CMMI的一些公司，他们非常重视产品质量的。如果客户交付给它产品，一定可以作出高质量的产品。还有一个生产力，因为印度和美国有时差的关系，早上我们在美国做需求，印度可以晚上开发，第二天可以拿这个开发的系统，可以给客户做验证，你的产品研发来说，这个生产力非常高的，一个7×24小时这个团队都在做运转。那么刚才说的印度优势，就是成本、质量、还有更高生产力，质量这一块他们如何确保呢，这个里面讲的印度非常大的SI的例子，整个历程是怎么样的，通过一些标准的流程控制它，达到这些目的。首先从ISO9000开始，还有CMM  Level-3，还有CMM  level-5，然后是Six  Sigma，可以达到降低开发成本，可以使项目的时间有一定的控制，不会做太多的拖延，还有可以逐渐的修补，可以达到这个目的，使得他们交付出来的系统是非常好的，让客户非常放心的，所以它其实所在的是一个不断持续进步的过程，不是说到CMMI里，就到此为止了，而是不断有新的标准。

    对于软件开发来说，如何计算项目的开发成本和开发时间呢，其实是有一个公式的，也是Rational大师的一个总结成果，首先有一个计算公式，你的代码行，还有你的流程是否规范，还有开发团队的人员的技术、技巧，还有使用自动化工具的辅助，基本上下来我们给大家讲一下，他们非常注重这些计算公式，怎么样通过这些因素可以提高系统开发的质量。

    那么刚才公式里面讲的流程这一块，是公式从流程标准化的一个过程，也是我们CMM分五级的目标，第一个是混乱的，没有开发的形式，第二个是每个项目有自己的一个项目流程，第三这些项目流程经过优化之后变成一个新的流程，然后企业达到这一步的时候，不断把流程进行精划，然后持续地改进它的流程。对于刚才的公式来说，人员也好，流程也好，印度公司如何实现这些最优化呢，他们会遵循这些不同的标准，ISO9000、CMM、CMMI，这些流程是对人本身怎么管理呢，这些现在做的就是人的CMM，怎么样使人也是分成五级，从一级到五级，可以把人的水平提高到企业需要的水平，这是CMM非常重视的一块。还有Six  Sigma怎么样持续提高产品的质量，也是他们非常重视的一块。所以说同样回到公司里面，那么总结出来四个非常好的实践，复杂度怎么降低呢，希望通过这个范围管理，或者叫资产为基础的开发，基本上它能从不同的行业里面，总结出来一些经验，做成一些核心的资产，比如说一些核心的模块，然后把这些总结出来放在行业里面进行实现它，这样的话有了这样一些软件基础的话，可以降低整个项目，以后不断交互项目的复杂度，这是第一点。第二点是流程的管理，因为流程的话，因为一个企业有很多种项目，有一些大项目，还有一些小项目，针对一些行业有不同的行业特点，怎么样把流程做到适合企业的所有的项目呢，这是他们希望做到的，也是我们后面会谈到的，怎么样项目的流程的规模适应到团队的特点。第三个非常好的实践是非常诚实地检验自己的系统。只要定出来这个度量的话，他们是非常认真地去得到这些的度量，然后得到这样的报表，然后跟客户一起分析系统的状况。第四是持续地进行测试。测试不是在这个系统交付前做的测试，一开始不断测试自己的系统，希望越到发现问题，越早去解决。那么这张图讲的是怎么样用更少的时间更快地交付我们的项目，可能一开始用的是传统的流程，或者一些不开放的工具，那么如果逐渐迁移到迭代式的开发，或者用中间件或者一些成熟的商业工具的话，可以更快地提高项目的速度。那么可以迁移到更好的SOA的方式，又能以更快地速度交付你的项目。

    那么这其中后面几个片子是一个印度非常大的SI，就是万人以上的非常大的SI公司给客户讲的一些片子，里面是摘抄的一些东西。我们看到每年可能有四、五千个项目做不同的开发，可以看到一些系统的移植。首先可以看到有ISO，ITIL，Six  Sigma，他们可以把这些流程集成在一起，通过这些集成可以定义出自己组织上的流程。从上到下，要定义自己的方法论，定义这些人员的职责，还要定义项目团队的这些人，什么时候应该做什么事情，这个会定义好。有这些人，这些职责，什么时候做什么东西，如何做的方法论，也会定义好。最后下来是所有的手册，还有这些指南，包括一些代码的指南，包括您如何用第三方的工具，这些他们已经定义的非常好了。那么对于组织来说，是一个非常标准的东西。

    对于这个企业来说，因为在不断壮大过程当中，同时会遇到一些相应的挑战，那么这个挑战就是说首先我可以看到现在印度企业基本上在全世界各地都有相应的办公室，他们的触角越来越全球化，这个时候遇到一些什么问题呢，比如说要提供一个新的解决方案，这个新的解决方案里面原来制定好的企业的流程怎么样运用到这些公司里面，可以提高客户的质量，同时如何使得刚刚有新的团队组建的时候，如何把这些方法流程贯彻到这些团队里面去，当这个触角越来越大，团队越来越大的时候，如何把这个流程如何适应到这个企业的壮大过程当中。这是他们的一些Challenges。

    怎么样保持企业流程的一致性，同时又可以适应到不同的项目开发的团队里面，大项目，小项目。现在他们有三千多个项目在同时进行，每个项目里面是否遵循同样的流程方法，什么人，什么时候，应该干什么事情，这是每个项目可以遵循整个企业的流程，这是他们遇到的一个挑战。那么怎么样迅速把这些流程针对不同的项目类型可以定制好，可以让这些项目遵循它，也是一个我们的挑战。同时他们又遇到一个问题，他有这么多的流程规范，对于一个项目团队来说，是不是会变成一个负累呢，是不是增加一个工作量呢，这个流程是不是可以非常容易让他们接受呢，他们想的方法通过把这个流程跟他们使用的开发工具和他们的工作管理工具结合在一起，在开发工具里面做一个操作的时候，可以在开发工具的某个地方可以看到流程的指导，可以告诉你要做这个事情应该怎么做的，不需要找到一本手册，然后翻到第几页去看，如果这样的话，对一个团队来说是非常不容易让人接受的，他们要让这个流程做得好的同时，让人非常容易的可以接受它。

   所以对他们前面的挑战，对一个企业来说，要做下一代的全球交付的平台，那么这个平台的核心就是要把他们之前的流程做得非常的灵活，非常融合，非常友好。比如说有一个手机，有非常好的功能，但是这个功能隐藏在不同的地方，不知道怎么用它，你会觉得很痛苦。你做出来的功能不能被手机用户接受。也就是说现在把这个流程做得非常好，但是我怎么样让我的团队，所有的项目的团队成员，项目经理，都可以接受它，更快地接受它，能够遵循流程的规范，希望下一代的系统可以做到这些东西。这是在企业里面不同的团队，他们在流程当中是互相协作的，首先SEPG的部门会定义这个流程，会持续改进这个流程。对于企业所有人的话，要很容易的找到，以及使用这个流程。那么对于每个项目团队来说，PM，他们专门有一个Delivery Management，会帮你做定制，把这个流程缩减到项目需要地东西，对于整个TEAM来说，我们怎么样可以在持续地改进它。

    对于刚才的软件的机器公式来说，四个因子我们可以通过这样的一些方法去提高，我们首先降低复杂度，我们可以用中间件的方式，同时可以通过架构设计的方式去降低我们要搭建的软件系统的复杂度，或者我们可以定义出一些可以用的重用的模块。第二我们怎么样改善我们的流程，刚才一直谈的不同的标准、不同的规范有RUP，有CMI，有ITIL，对于整个团队的技能的提高，可以通过一些培训，刚才说的那些，每年给工程师很多的培训，同时可以参加很多的考试，非常重视这个事情，怎么样对团队人员的素质的提高。还可以通过一些智能化的公式帮助他们管理变更，管理资产，可以更好地协作开发。

    所以说对于人本身的团队的技能是非常重要的。林肯说过“如果给我八个小时砍这个树，我会花六个小时磨我的刀”。你做一个项目确保成功之前，你要确信你的团队和你的人有这样相应的技能可以实现这个东西。所以说基本上你首先提高个人的能力，同时这个基础上，提高项目团队协作起来的工作效率。最后使得你怎么组织他的效率，会有很大的提高。要使用自动化工具去帮助你减少人为的错误，去提高技术的质量。这个说明使用工具可以帮助我们使用效率的提高，如果你要人工计算的话，可能需要比较长的时间，如果用计算器的话，会提高效率。如果你用Excel，你把公式放在里面可以很快地计算出来，所以这个工具可以帮助我们提高我们的生产力。这是一个自动化的例子，就是说在我们建模，我们划分模型之后可以通过双向工程的方式，可以帮助我们提高开发的效率，直接可以从模型生成代码，可以进行开发，通过工具的自动化方式可以帮助我们提高生产力。

    这个企业的管理的话，可以通过这些工具，可以减少在管理当中出现的人工的错误。这是一个例子，是使用的这个工具，可以更好地集成使我们可以管理好版本，还有需求的变更，其中是一个印度使用的这样一个方式。另外一个方式，通过Real  Case的例子，可以减少32%的工作量。那么用Robot这个工具，通过Robot的辅助，可以在交互之前，可以找到1437个问题，没有通过这个工具辅助的话，没有直接交给客户的话，客户一定非常不满意，因为之间有太多的缺陷，这是一些例子，可以告诉我们一些印度的大的SI，可以通过一些工具，可以减少开发的成本。这是SI他们自己总结出来的多年过程当中，他们的一些每千代码行的缺陷，其实从97年开始，我们看到确实近年来是越来越低，同时因为看到项目的复杂度越来越高，同时他们能使得缺陷越来越降低是非常好的一个结果。那么实际上同时他们的开发成本也是越来越低的。这是他们总结出来的这样一些图表。对于这些印度的大的SI来说，基本上每个大的SI，都跟Rational签订了很多的协议，购买了很多的工具和服务，可以更快地交付产品，同时可以使得他们的项目都能在规定时间可以交付。还有他们的流程的定制，使得他们可以把他们的流程根据项目的不同特点，可以定制出来一个适合项目的流程。

    对于印度的这些外包企业成功，从一开始是从成本降低的角度，因为美国的项目可能成本低可能外包给印度，印度的语言是英语，沟通起来更方便。这些不是这么多国家把项目拿到印度的主要原因，多年可以发现印度的企业不断演进，不断提高，这些交付出来的产品的质量非常好，让客户非常放心，这是印度多年的可以获得更多客户的主要原因。
   
    观众提问：印度工程师，一年生产的有效的代码是多少？

    Ameeta  Roy：其实这个问题真的很难回答。其实对于印度企业来说，从这个片子理解出来，印度希望可以做到所有的东西都是可以重复用的。流程和重用性是他们真正追求的东西，这个东西确实很难回答。

    观众提问：在印度的软件外包企业中，有多大的比例购买了IBM  Rational的解决方案？
   

    Ameeta  Roy：基本上都有。基本上我们帮印度的SI做的工作基本上本身他们搭建起来这个软件的开发平台，这些基础性工作。有的时候培训他们的工程师，比如说刚才说的一万五千多的开发人员，基本上培训两、三百个Rational的技术专家，然后这些专家在自己的公司里面然后再推行Rational的这样的工具。
 

Rational高级产品经理卓艳

项目外包后软件工程管理需要注意的因素

    【IT168现场报道】今天我先讲讲我们的客户他的案例分析。接下来有一段小的总结，大家有问题可以提出来，我可以尽量回答。最后给大家看看我们即将推出的Rational的一个产品，9月底这个产品就会出来，在我们网站上可以下载下来。现在我们先简单介绍一下这个客户，是IBM  Rational在美国的一个客户，主要负责的业务是负责传统的数据化的邮件和包裹的服务。我其实在波士顿这个地方，我们的邮件和包裹的收发是由他们来做，我们也打外包，把这个服务包给这家服务来做的。我们的培训教材的打印也是由这家公司来做的，他们是我们的客户，我们也是他们的客户。这个公司在全球有四个点，在美国、加拿大、英国和印度都有他们的站点。这四个站点他们负责四百多个软件，六百多个界面，他们的机构也是非常庞大。我们这里面的主人公，就是写这个故事的人不是说，是这个公司的质监机构的负责人，类似这样的会议。在美国我们跟这个会议也是一模一样的，他分享的这个案例。我把这个案例跟大家一起分享。

    有一本书叫做《世界是平的》，有几个人读过这本书，请大家举手。我想问一下谁在做外包的甲方，有没有人做的乙方。还有谁对CMMI比较有兴趣的。谁对循规有兴趣呢。大家其实发现这些问题，这几个问题是关联的，循规、过程成熟，还有CMMI，还有外包，在这些客户身上要解决所有的这些问题。

    在04年这个公司决定把所有的应用软件开发和维护全部打外包。他们跟一个印度的外包商签了五年的协议，其实打外包就是为了缩减开支。这是主要的原因之一。也不是唯一的原因。他们打算五年当中每一年都可以削减六百万的IT开支。他们也希望通过把产品打外包来提高产品的质量，提高产品的性能，也逐渐改善他们的软件开发过程。从交付的角度来看，他们希望看到一个更准确的预测到他们什么时候可以交付，然后准时地交付他们的产品。这个客户有四百多的应用软件，还有六百多个界面需要维护。我想在这里用个类比的方式，在美国用最好的餐馆吃饭，没有发现菜单的菜只有几样，不超过十样的菜，为什么呢，好的厨师要保证把所有的菜样样做到精到，然后说这个菜单有一百来样是不可能的，所以要把这个菜单简化、精化，可以把这个菜做到非常好的程度，这是他们的好的餐馆的经验之谈。软件开发也是这样，有几百来个产品，每个做一点事，每个都比较粗糙，你的客户不满意，而且维护和开发起来都非常昂贵，而且使用的寿命又很短，因为一下子发现问题很多，可能这个客户不满意也就走了，然后你的产品就不卖了，所以要把这个产品简化，这个应用组合进行简化，把质量提高，然后达到让客户满意。还有从通过外包也来提高公司的竞争能力。因为在美国不是一家公司打外包，很多公司用打外包的形式，降低他们的成本费用，提高他们的质量。对他们公司来说，也有这个战略性的思路。

    其实我们想都以为每个公司在过程成熟方面都是很发达了，其实不然。其实美国的文化当中，强调的很多的是个人的表现。他们每个人做一样的事情是很难很难的。就像我在自己的部门里面，我是一个产品经理，但是我们部门里面有三个每个人做事的方式都不一样，我们觉得这样做好，那个人觉得那样做好，我们每个人做都有自己的原因、自己的理由，除非老板说大家必须这么做，强迫这么做，大家才这样做，必然的话大家各做各的。这其实是非常非常的普遍。我们所说的客户的成熟度，按照CMMI来说，他们的成熟度是初始级。而他们选择的印度的外包商，已经达到优化级，也就是等级五。这种合作不是那么一帆风顺的，这个问题出了很多。我一直再想好的类比，这边是规规矩矩，那边是混乱不堪，这样一合作的话问题就来了，本来想说打外包的形式可以节省费用。因为美国在这个方面的需求不断变化不断变化，没有一个成熟的过程。那你跟外包商今天说要这个，明天说要这个，那外包商说您这一改，意味着我的交付期要延迟，这个费用要提高，他们把这个算得清清楚楚。等于说某种意义上，你甲方说要什么你得有一个代价，你乙方要把这个代价算出来，你需要我变这个需求可以，对我们来说这个工期、时间、费用方面会有什么样的影响。所以说合作的初期过程出现了很多的问题，而且不断返修。其实从需求的角度来说，从合作的初期，甲方这么说，乙方那么理解，这个说的人和听的人，不一定一下子可以达到那个默契。所以这个过程也是一个磨合过程。

    我们先看看甲方和乙方的合作模式。在业务分析和需求分析以及系统地分析，这是由甲方来做。然后乙方是负责Technical  Design，还有开发和测试。乙方主要负责功能，还是这个方面的测试。有一部分的测试由甲方来做的，主要的是验收、产品验收、用户验收方面的测试。还有一个部分是怎么样确认产品和现有的产品链接。从产品测试结束之后要投入生产，也是由甲方来负责。接下来的服务和维修继续由乙方来完成。其实这种外包模式可能比较常见的外包模式，当然有一些公司只是把测试方面外包了，也有一些公司把开发和测试同时包出去，还有一种只把最后的维护方面外包。每个公司的决策不一样，有的公司把最不重要的，或者是他们认为费用又高，但是又不能达到他们的核心价值的部分去做外包。也有这样的情况。我们这个案例打外包的程度比较高级，比较多的东西都给它的外包公司来做。既然他们决定把所有的开发和维护都给外包商来做，那么意味着公司要经历了很大的变革。从04年开始他们从美国和加拿大开始，到05年着手于英国和印度，整个过程有六个月，这个当中有140个人下岗。然后有137上门服务的和外包的服务商来代替，上门其实是相当贵的，我们作为IBM  Rational是做相当的上门服务，是很贵的，包括差旅、住宿，还有每天按小时计算的上门服务。当然这个比例是小的，在05年达到3：7，尽量减少上门服务的昂贵的费用。把大多数的费用转给境外的外包商来做。他们剩下的85名专家成为业务分析员。公司所保留的职能主要是放在需求的开发、获取，以及需求的管理。还有项目管理，构架设计，一部分的兼容测试，用户验收测试。这些职能都保留下来了。但是在公司的转型过程当中，面对着很多的问题，最主要的问题一个是规范化、在美国规范化的东西很难的事情。因为跟他们的文化有关系。在中国我想我们做事要有规矩，但是有方法，要讲究方法和规矩，我觉得中国实施起来要容易的多，在美国这个相当难。所以他们谈到需要改变企业文化，改变文化的方式来解决一些问题。从甲方的角度来说，他们要把重心首先放在需求方面，因为只有你把你的需求、把你想要的东西说清楚了，说明白了，说准确了，你才可以说叫外包商交付你要的东西。你把自己的需求说的不好，说错了，说偏差了，说的模棱两可了，却出现返工的现象。可能别人交付的东西不是你需要的，这个时候太晚了，他们用我们的RequisitePro工具来帮助他们。他们公司高层决定不是选择连续表述模型，他们要把这个放在最重要的过程域里面。乙方可能注重强调的综合能力方面，甲方只是要把自己的问题解决好了就可以。把重心放在需求的开发、管理、还有核查方面。但是他们的目的，对自己的要求不是很高，过程是从0-1。在初期过程他们雇佣了一个IBM的连续表述模型，需求开发、管理，以及工具的一系列的课程客户化。因为客户化的目的就是针对性，把教材更针对客户，然后更集中讲他们需要解决的问题。然后他们雇了顾问，一共讲了12次课，把所有公司的内部人员都培训过去了。之后还做了一些辅导，200个小时的辅导。这个时候意识到不能只买工具，还有他们的培训和服务帮助他们尽快地结束这个转型过程。他们实施的有四个站点，他们对于外包商用我们的RequisiteWeb参与需求的审查，这个反馈回来需求写的是不是这个样子。很多东西在英文当中看起来很简单，每个人有很多种的理解方法和方式。要不断地跟乙方有交流，确保他们对需求的认识是正确的，还有在加拿大的团队。为了实施他们的转型，以及用我们的工具，他们其实设计了工具构架，你可以看的出来，但是他们公司所实施的工具是我们的Rational，还有微软的工具用做项目管理的。然后RequisitePro做需求管理，用Testmanager等等。还有产品之间的联接，从上面看他们把一些重要的一些过程制品放在SharePoint上面，这个地方用的是ChearQuest。

    这家公司的成功的很大的因素，跟IBM  Rational的关系，像我们合作伙伴一样的关系，不止是我们的客户。跟我们公司之间的来往是很多的。他们不断积极主动地跟我们合作。在他们实施  Rational  Team  Unified  Platform的时候，他们的用的这个版本是我们的一个旧版本，用这个文件的时候打开比较慢，Test  Manager不能在Citrix，上运行，还有让客户尽量参与我们的产品开发。我们在销售产品之前，推到市场之前，有一些项目让大家提早看到我们的产品，但是把你们的使用问题反馈给我们，帮助我们提高我们的产品质量。他们参与了我们6.15的项目，然后这个性能有了很显著的提高，打开一个东西从60秒缩减到5秒。在05年时候进行了SCAMPI的一个评审。它的评审结果，只是希望从0到1，结果评审的结果是2。评审员对他们在RequisitePro的实施非常满意，他们把需求明确地定义出来，他们用的一个很重要的链接，或者是需求之间的追踪和链接，或者用Attributes来管理需求的风险，优先和签署。需求不是写就是需求了，写下来之后要评审、确认、最后还要批准。

    客户认为他们的成功主要跟他们高层的支持，以及他们在过程当中，非常地勤勤恳恳地工作。还有他们说要利用在变革过程当中，总是有支持你的人，还有反对你的人，他们充分利用这些支持他们的人的力量。我们看看过程成熟和增加过程成熟的透明度，其实很多时候，当然你可以自发地去做，通常情况下有很多外因在里面。主要的外因这个客户身上是循规。因为在美国是一个法制的国家，用不同种的法律，条规来限制或者管制这些公司。像FDA，食品药检这个方面有很多的规矩。这个SOX是安然公司之后，政府出台了一些新规矩，叫管理这个公司的商业运行。所以循规很重要的一点要对整个软件开发过程有一个明确的定义。不但有这个想法是不够的，你得写下来，定义下来，而且整个开发过程要规范化。如果说大大小小的团队每个人用不同的工具，不同的开发过程，这个公司面对循规评审，这是很难过的。因为评审团看到这边做得不一样，那边做得不一样，大多数情况下他们很不满意了，所以你想通过的话会很难。如果把整个过程明确定义规范化，你用的都是同一个工具、同样的工具，同样的流程，对于评审来说只审一个，那其他的不用看了，这个相当重要。在过程规范化和自动化的过程当中，他们用了Clear  Quest他们认为是核心工具。这张图上面显示的是整个开发的流程，这个流程的步骤里面用的是什么样的工具，而这个工具又管理什么样的过程制品，在这个图上面明确地显示出来了，其实每个公司都应该有这样的东西，为什么呢，大家知道我在每个步骤当中，我到底需要完成什么样的过程制品，需要由什么样的工具进行管理，这个方面一目了然，而且这边有一个虚线下来。因为我们这边讲的循规，很重要的一点就是说什么东西好了，我要迁移，然后才可以转到下一步做，有这个过程可以追踪责任在谁身上。因为“循规”很多的方面，就是每个公司出问题了，责任在谁身上，要找出来。整个过程一步步当中都有签字确认的过程。

    如果客户发现什么问题，把变更需求输入，然后进入到Clear  Quest，然后有一些请求的话，如果请求合理的话，我们需要转换成产品的需求，然后的需求一旦定义完成之后，经过批准可以放到Requirements  approved的进行去管理，要建立基线，然后建立基线完了以后，然后你要走另外一个需求变更过程，这个外包商要负责接受这些需求，然后开始开发、测试，然后又回到甲方这边来进行验收测试，然后开始生产。如果说在测试过程当中，找到了问题，那么就把它又送到Clear  Quest里面去。这是一个很简单的需求基线，如果要改需求基线，你要走什么样的流程，其实这是相当关键的。前面我们谈到因为甲方的公司的工作流程非常的初级，不成熟，他们的需求不断变化，使乙方非常的痛苦。而且乙方当然也用他们的数据告诉甲方你们这样做的不合理性，所以甲方意识到问题了，所以非常注重需求的变更过程。我们所说的客户完成这些之后，决定他们下一步该做什么样的事情，他们要不断地提高他们软件开发的成熟度，以及软件工具的实现。这个公司一定花了两年半的时间来实施变革，两年半的时间里面，让大量的外包工作达到稳定。没有那么多的返工和问题了。而且他们在公司的四个站点，二十多的团队都达到了过程的规范化，而且过程的规范化他们用的帮助他们自动化的这些工具，他们的工作能力从0提高到2，两年半来说他们的收获很多。而且他们通过过程成熟、以及开发过程的标准化、规范化，来帮助他们减少循规的费用。循规的费用在美国很多公司花了几百万、几千万的美元花费在这个方面。所以说这个方面的节省其实是相当大的一个数字。你要实施这样的变革，其实我们在中国要有上层的支持才能贯彻的下去。这个公司有高层管理的支持，才帮助他们在两年半的时间达到这些成果。他们重视在变革过程当中，谁支持你的，要把他们作为你的盟友，如果支持你的人太少的话，也做不到。客户认为说至少有16.7%的人来支持你，才能帮助你完成变革的过程。在跟外包商之间的合作过程当中，你应该是一个团队精神，不是甲方和乙方的问题。彼此之间要达到一种合作的协调性，我自己认为乙方不要把甲方的所有的东西当做命令执行，乙方要反馈问题，积极主动地告诉甲方说把问题反馈给他们，这样的话才会有长期合作的成功性才会提高。他们非常强调公司内部，以及公司内部与外包商之间的沟通和交流，提高信噪比，这样的话可以树立榜样，把这些成功的例子举出来。如果成功的话，要马上认可你的成功。如果两个月之后再说要晚了，如果意识到马上嘉奖人家，这样才可以达到效果。中国人说用事实说话，这个在美国也可以说的通，你要想实施变革，让别人接受你的观点的话，你得拿出事实和数据来。过程成熟，不是说今天买了工具，明天就可以成熟，这是一个过程，这个过程当中需要与你的客户合作，也需要你跟你的外包商不断合作才可以完成和提高。即便我们是IBM  Rational，每个公司都有缺陷，所以你要对你的工具了解的透彻一些，知道它的局限性，还有哪些方面的长处和短处，你都应该有所了解。然后作为我们的客户，我们希望你跟我们紧密合作，有问题都来找我们。

    这个产品其实是Rational开发出来，主要讲的是怎么样达到等级二，目前还在开发过程当中，已经在末期了，9月底会发布出来。这是一些其他的参考资料和资源。

    观众提问：我想问一下现在的国外CMMI的认证，是一个灵活应用。而在国内CMMI作为一种认证资格来说，我们公司要是上的话，如何灵活地应用CMMI？我公司是甲方。

    卓艳：甲方的话你有甲方的问题，乙方是乙方的问题。乙方的话我CMMI是5，我一下子鹤立鸡群了，我在竞争方案的时候，我赢得的机率比较大。作为甲方首先从外包方式来看，你到底把什么东西进行外包，外包出来的东西，你可以找一个很强的外包商，来弥补你的不足。从甲方的角度看你自己，在哪个过程方面的问题比较多。你着重这个开始，把这个过程成熟化，然后再找下一个问题，然后再解决下一个问题。谢谢大家！

IBM  Rational北方区的技术负责人李纪华

如何用Rational工具帮助遵循规范

    【IT168 现场报道】这个“循规蹈矩”在我们中国传统里面略带贬义的词汇。当我们遵循某种规定或者法规的时候，首先很难彻底理解。因为这个国际规则就是这样，所以我们通常借用一个鲁迅的话就是拿来主义，我们首先先适应，先通过审查。我们第一步先要循规蹈矩，首先说让开发人员熟悉这个法律，那个代价都受不了，我们第一步要循规蹈矩，通过审查，通过规定。第二我们彻底消化它，结合自身的情况，做持续性的改进。因为一个法律的改进，需要一个很长的修订过程，但是不是一个完美的东西，但是是一个合理的东西。但是这个过程当中，哪些东西为我所用，我应该在哪个领域进行投入，当你坚持持续改进的话，最后达到一个量变到质变的过程，这也是给大家一个建议，特别是中国的企业的一个建议。所以今天的讲座里面会跟大家稍微比较概括全面的介绍一下遵规的所有的内涵及外延，结合Rational的方案做好这个工作。在座的企业里面有没有一个叫做Complicnce  Officer的职位，在座的企业的公司没有在国外上市、香港上市，作为一个现在的上市企业的话，现在特点在香港和美国上市的话，刚才我们反复提到的萨班斯法案，公司里面谁去监督、谁负责这个制度，现在有遵规、合规、还有循规，非常统一的。

    我们看到这个遵规的一个概要。我们生存在一个法律的国家，我们国家的制度，到一些企业的处罚条例，内部的规章制度，非常广泛。我在准备题目的时候，特别关注了一些日常的生活的东西。这个东西大家可以看到，小心地滑的标识，我搜索了很多的法案，有很多这样的案例。在四川有一个餐馆小孩就摔死了，然后跟他们打官司。为什么很多餐馆说已经提醒过你了，地上滑，你摔倒了，我已经尽责任了。然后美国有一条法规，叫职业和健康安全的法律，运用这个法律里面的条文设立了这个东西。这是最早的他们的出处，这个在我们生活当中广泛使用了。我看了中国的法律，一个是消费者权益法，另外在我们《民法》里面有类似的描述，描述的原文，在公共场合提供商品和服务的时候，要保证消费者的健康安全，这是法律里面的条文，但是落实到生活当中很多的条例，大家如果感兴趣的话，大家回去查一下，几乎中国的省或者市，特别是市一级的有具体的消费者的条例，比法来的更具体，如果一旦出了官司，就要有很多的法律依据。这是我们日常生活的事情。对于我们软件开发现在可能更关键一些。

    这是现在我们在经济全球化、一体化的情况下，我们面对的各种常见的法律。大家都知道这些是做什么的吗？非常多的法，现在大家看新闻，看到中国的玩具被人家拒绝了，要召回了，因为印证了他们的法律，或者一些全球化的WTO的法律，非常残酷的，因为经济全球化，必须有统一的标准约束彼此，这是我们的现实。那么我稍微跟踪了一下这些东西，发现这些都是干什么了，比如说萨班斯法案。还有Basel  II，跟个人的信息安全的观念。我们想到在网络银行上，如果个人的信息被窃取了，被传递了，是违法的。不是银行就是网站违法了，因为我的个人信息被窃取了，如果被检查机构检查到的话，说明这个银行或者网站违规了。换句话说，因为客户在你这里的安全性没有得到保证。如果是上市公司的话，这个问题还不小。这是现在法律的重要性，还有一些法律，是用于医疗卫生机构的，在国外的检查非常细致和严格。前一个阶段我们药监局的腐败问题，跟国外对比的话，我们有很大的距离。我们假药横行。我们现在的食品、医药仔细分析了一下，都是非常密切相关。现在对于比较热门的就是这个法律，是现在的上市公司的做检查的，其中的404号法案跟IT系统非常密切的，中国的公司在国外上市必须要通过审查的。所以说我们很多的大型企业里面，如果是上市公司的话，现在纷纷设立了这个部门，整天教育员工要符合这个规定那个规定，跟我们的软件开发结合在一起来看看。

    什么是“遵规”无法是按照规章制度来办事情，按照约定来做事情。我们还有一个关于IT治理和遵规实际上有着千丝万缕的关系，实际上从企业治理过来的，现在发现IT越来越乱了，遗留的系统非常多，开发工具也是五花八门的，开发系统整个的需求也在变，然后资产经过几十年的积累，IT的资产越来越多，能不能治理一个企业一样来治理IT，出现了IT治理，它的内涵无非是建立一系列的职权、流程的一个全面的框架，可以让人更好地在IT系统整个大的流程里面发挥它的作用。就是把IT都搞得井井有条。但是和这个法规什么关系呢，实际上法律建立了很多的度量指标，你IT做得好不好，你说做得好与不好，有一个标尺来衡量它，这个标准来说，我们IT普遍采用很多的标准，比如说CMMI，或者还有Six  Sigma，还有很多IT方面的标杆、标尺，你是否满足了，你是否做到了，你用的哪种方法达到什么层次，也是衡量你治理级别的一个标杆。所以说是相辅相成的，跟我们的IT治理。通过分析，我们发现这么多法规，都有它的特点，刚才讲的我发现的特点是跟金融、金融的面很广，包括保险、证券，还有跟食品、药品这几个方面非常密切。同时又跟安全性、风险管理、还有机密性、透明性几个方面都有关系。我们把这几个法规、还有几个特点罗列了一下，大家可以宏观看到这些法律法规，主要在美国来适用，中国还在治理当中。中国的法律研究很难给出一个准确的，包括网上犯罪，我们还好像有一个法律正在制定，关于网络的黑客行为，很多是在制定过程当中。我们可以借鉴一下国外的法律法规。还有这些法规有很多的特点，一个是强制性的，不要问为什么，你违反了就是违规了，你要执行。这些法律法规包括IT的标准，包括CMMI的法规都是非指导性的，不会告诉你一步步怎么做到这一点，你达到这个层次是合规了，如果你不合规的话，不会告诉你这个过程，所以说不是有指导性的。并且它在持续变化，不是今天合规就是明天合规的，这些法律会有变化，这个大家可以理解，因为这些法律法规推出之后，要看到市场的反应，要经常做调整。还有对IT的影响加大，虽然法律法规很少有直接施加于IT的，但是现在的业务系统几乎都是IT系统，所以对规章制度的遵循程度直接落实到IT系统的执行程度上，比如说拿这个来说，要做财务的审核审计，所有的都是计算机打出来的，从你系统里面生成出来的东西。比如说对IT的影响加大。还有有非证实性，这些法律法规用了某种方式，比如说用了CMMI，然后这个审计部门说就算过了，不推荐你用什么方案，不强制说用什么方案，不会帮助你证实用了这样的方案是一定合规，他们有自己的一套方法审计你。这也是告诉大家，你在遵规的过程当中，有很多不同的渠道和手段，但是要看你的理解是否透彻。另外的话，这个遵规跟风险、利益、损害有密切相关。所以遵规实际上已经把损害降低到最低级别的一个门槛。比如说你们分析一下法律法规，那个法律法规保证的你最低级别的安全性，比如说让你的地面不要滑，是最低级别，当然没有规定一定要铺上地毯，只是说不要滑倒，所以跟风险有很大关系，只要你合规，就避免最低程度的风险，但是不是让你很舒服。然后它覆盖的范围很广，从战略层，组织层，流程，应用和数据，技术，基础设施，这个跟规定都有关系。

    另外一个方面我们看看假设有一个审计公司，到你们公司做审计的话，要做哪些事情，有内部审计，外部审计。英文里面有个词语，一个是inspector，带有外部审计，请一个审计公司来帮助审计。还有auditor是内部审计。有三件事情要记住，说你所做的事，一方面是说文档化，要把你做的事记录下来。比如说人家来了，告诉人家你如何做软件开发。第二件事是做你所说的事。有一个企业说过CMMI，我们好像像应付托福考试一样，你的行为要一致的，你写了那么多文档，到具体的落实当中，你可能按照CMMI的0级来做，这个严格审计的话可以审计出来。最后就是要有能够证明两个是一致的。它的目的是看你的业务控制力度，到底和流程是否一致。这个控制的依据在哪里，常用的手段和问题呢，你的流程在哪儿，他需要看你的文档，人家需要备案。第二要衡量你的流程是否成熟，如何证明你的成熟，会拿你的历史数据来看，比方说今天来审计了，昨天才把文档写好了，他会看你这个流程是否成熟，是不是跑了一年两年的流程，一定有历史数据，这是一个稳定不稳定，成熟不成熟的证据。还有流程本身是否遵规，对你本身的流程进行检查。还有产出的流程与工件的关联性，还有提交的时候移交过程、签署过程在哪里，你交一个过程的时候一定要签字，在审计的时候这点很关键。一定要签字，在国外很认签名。在很多情况下需要签字的，把文档交到另外一个部门需要签字的，这是应付审计的。当然这个有好处的，出了事的话好查实。还有支持工具之间是否有链接性，集成性。如果你用的工具五花八门的，之间没有关系的话，那应付审计的话非常麻烦。他需要你有证据来证明。这样的话你很辛苦。还有你的测试结果与需求的关联性。这是审计人员或者审查人员，我们内部叫QA的过程，跟外部的调查公司有异曲同工的地方，他们会从这个方面入手。这些审查人员在什么时间进入你公司的现场，往往在公司出事的时候，美国的很多的公司为什么接受审查呢，是因为这些公司闹出丑闻，2001年安然是一个导火索。首先从三个地方进行审查，告诉你系统设计有缺陷造成这个事故，第二是不是人为的错误，第三是不是有恶意行为。一旦事故发生的时候，这些审查人员怎么样调查你。如果你软件本身出了一个Bug，你需要看一下是不是设计的情况，人为的错误，还有恶意行为呢，不能把恶意行为放在第一位。

    所以我们讲遵规既是一个需求，有一些企业必须遵循它，也是一个机会，契机，借助这个大环境，这个推动力，帮助我们优化一个软件的开发过程。这个遵规表现在三个层面的体现上，第一要避免惩罚，要遵循这个规定，避免一些不必要的麻烦。很多企业的出发点从这里开始。然后在做好遵规之后，第二阶段很重要的是自我改进和持续优化。自己慢慢看这个规定生搬硬套的，循规蹈矩的做完了，看看有没有持续性的改进。然后量变达到质变的时候，充分利用遵规可以赢取业务优势。对于国内CMMI的遵循和改进的道路，我们发现很多的公司现在做到一个遵规以后，就不再往前走了。我过了CMMI几级之后，我该怎么做起来怎么做，我们真正没有从CMMI里面，或者ISO9000也好，没有吸取真正的精华的东西，去改进自身。只是考完了托福了，英语还是那样。然后你很难达到这个方面，不客气的讲，我的感觉以及看到一些数据，北京市过CMMI3的企业有多少，可能有上百家，但是真正可以承担的一千万两千万以上外包业务的究竟有多少。就会知道为什么过了CMMI那么多的级别，为什么达不到这个阶段，大概没有脚踏实地地做事情，这也是一个机会，就要靠大家如何抓住这个机会。

    下面我们看看IT组织，特别是我们软件交付组织的遵规，有哪些具体的。刚才讲了这么多遵规的内容，到底要归结到IT系统上。现在查你业务的时候，基本上查你IT的应用系统。这是一些大的企业，一些咨询公司说过的话，比如说像KPMG头说的，任何审计都是IT的审计，符合规定已经变成它的需求了，还有可以符合哪些规定，应对哪些审查。这是我做了一些小规模研究，发现在IT上使用的一些标准和框架。很多都是大家很熟悉的，比如说CMM、CMMI，ITIL是符合IT业的标准，还有Six  Sigma是项目管理的方面，还有国军标5000是做了CMMI一个汉化的标准。IBM自身有很多的方法和标准，IPD我们做产品研发的，IRUP是我们做软件开发管理的标准。很多成为业界公认的标准。比如说ISO9000的标准，因为9000太多了，现在大家知道ISO  900X里面有很多的内涵。还有COBIT，这边关于IT治理方面的，有一些东西大家不太熟悉。大家注意关注一下这些标准。包括COSO，主要是对内部审计的一个框架，更大的做整个IT治理的一个规范或者一个评价标准。这么多标准，同样IT的规范和标准，跟我们刚才看到的金融、食品、卫生的标准，实际上都是息息相关的，这边的遵规可以直接影响到业务系统的遵规，这个方面我们想看看开发对于遵规的影响。如果我们审计一个公司，具体的IT开发的遵规程度如何，很可能会问到这些问题。大家可以看看，就是说你的企业里面是否有这样的一个环境去记录和审计，来应对这些审计。首先谁批准了把这些东西部署到测试和生产环境，记录在哪里，签字在什么地方，然后签字的这些记录在哪里。然后当前测试环境下、生产环境下，部署的什么版本的构建，又是谁同意，谁做的构建。比如说给客户交付了1.0，然后客户说传输网络坏了，能不能重新传一下，对不起，昨天那个东西组合不出来了，只能给你一个1.1版，还在测试当中。你在构建当中，没有任何记录，还要重新构建一次。然后有哪些工件呢，提交的什么内容，这些东西在哪儿，工件之间的关联性怎么样，还有哪些源代码文件，可执行文件跟源代码的版本有哪些关系，如何编译出来的。我们做的软件开发做得很细致了，要落实到这些地方去，是很实用的。这些规定，这些东西看上去好像挺严格的，但是如果照着去做的话，一定会有好处的。你如果刚刚接触这个方面的话，可以照着去做，慢慢去消化。

    我们看结合前面讲的几件事情，说你要做的事，实际上先把你的流程建立起来，要做什么东西，要有一个很好的思路。这个思路在我们软件开发里面，就要把软件流程做好，包括技术控制的流程，包括业务控制的流程，还有一个职责分立的过程，审批、授权、质量把关的三层分立。为什么这么做呢，就是大家要互相监督，怕什么东西，集中在一个人身上肯定要出事。中国药监局为什么出事呢，因为质量把关管，质量授权也管，审批也管，他只要一签字肯定出事。做什么药品批出去了，假药出去了，没有人监督它可以出事。你做软件开发，如果三个方面没有分开的话，我觉得很危险，没有人考核你，非常危险。第二点做你说的事，如果你做了这些工作流，这些流程看上去很漂亮、很完美，你一定要做到，一定要认真执行，如果执行不下去，不合理，不要再这里说。你人行要一致，你说了人家要检查你，如果内部QA很严格，当然这个前提是你分立，如果你开发完了，你自己做质量审核就另外说。如果别人的话肯定要审核的。第三一定要证明，所有的东西都要有记录。特别是一些签署的过程，报告的记录。如果坚持做这三点的话，才能赢取竞争的优势。这个CMMI五个级有很多内部相通的地方，第二级的时候可以做可重复流程，不管好坏，这样的话可以遵守某些规定，好不好的话先不管，第三级的时候遵循标准化的流程，这个可能比较好的做法，经过消化后的话，到了四级之后知道好在什么地方，必须经过一些大量的统计指标度量指标，这样的话可以做持续性改进。这是有内部相通的地方的。

    下面我们看一下典型的遵规的项目管理过程，涉及到企业里面的很多的决策。一开始提出发现的业务问题，一个审计要求。接下来有一些人做风险评估，我们是否要立一个新的项目，开始做这个事情，这个项目要做可行性报告，然后进行审批，接下来开发层面开始介入，要做解决方案的设计，开发仅仅发布版本的时候，什么时候进行发布，接下来做功能性的开发，领导团队，然后要做签署。这个项目立项，开始组织开发团队，开始批钱了，这些地方需要有签字证明。然后这个地方非常严格，开发和测试当中要做非常重要的签署过程，什么时候进行测试的，什么时候测试给了生产，这是有严格过程的。我前一段时间做银行的，我发现银行这个方面做得很严格，因为这几个部门都是分布在不同地方，如果没有这种签署记录基本上没有办法管理，如果通过邮件的话把东西传过去了，怎么审计呢，如果删除了的话怎么找呢，必须要有记录。在运营过程当中要接受审计员的一些审核。这是我们的一个典型的过程。如果我们结合具体的问题来看的话，如果我们把IT做得再具体一些，说你做得事是我们的流程的定义，首先要预先定义好这个项目谁来批准，怎么批准，这个钱从什么地方来，什么时间，做什么权限，要做什么事情，流程要写好，规定好。如果项目评优先级的话，你的标准是什么，保留和撤销的标准是什么，要预先制定好，文档的话要制定好，你做不到的话不要写。如果甲方做CMMI的时候，其实很多事情不用那么生搬硬套做的，应该选择一些重点的领域做，当然这个考试过去的话，其实该扔的可以扔，剩下的东西要按照这个步骤很好地去做。在技术上有很多具体的问题。从Rational产品支持上面可以有两个产品推荐给大家，一个是RMC，是植根于开源的，是一个方法的写作平台，ROP只是一个输入。跟我们写论文一样，这个抄一点那个抄一点，成为我自己的东西了。这个工具跟那个很类似，从ROP里面抄一点，或者CMMI抄一点，最后形成公司自己的开发流程，产品发布出来像一个网站出来，我公司的流程全部是活的，如果新员工来了以后，企业如何做开发的，自己可以浏览、学习可以去看，这个固化你的开发流程非常有好处的。另外一个工具RPM做项目的组合和管理的，里面有一个强大的流程模板，整个项目的开发过程可以进入流程，一个风险、问题，缺陷的典型的处理过程和爆发的时机，暴露的指出，如何消除它，消除的途经，花多少人，需要什么技能可以全部装在这个模板里边，你做项目的时候，这个模板可以做大量参考，如果出现风险的话，可以把这个项目抓过来自己用。在遵规流程地定义上，可以帮助你很大的忙。前不久一个客户做CMMI，用了一个RPM的模板，任何一个工程师过来以后把这个模板拿过来，第一步开箱，有一个单子记录的很清楚，有一个安装手册，一切都是标准化的东西。

    第二点做你所说的事，这个方面Rational提供了很多开发的工具和开发的平台，帮你做事情可以做得比较轻松一点，不要给开发人员增加太大的负担，让开发人员理解法律法规不太可能的事情。要把遵规的过程自动化和流程化，不自觉地就遵规了。我画出一个图，一个开发人员做日常开发的时候，用UCM的方式进行开发的时候，首先第一步选择开发的活动，第二步检出并修改文件，然后编译和链接，然后测试变化，然后检入变化。这个周期花费了很多的时间做了这个东西，然后可以帮助他做审计。这个简单的过程里面，修改某一个缺陷到底动了哪些文件和版本。这个东西不自觉地被工具记录下来。跟我们写日记一样，实际上挺痛苦的，每天要回顾今天所干的事情，但是如果坚持下去的话，不自觉地写日记的话，对你的帮助很大。其实Clear  Quest、Clear  Cast你今天工作了一天你很容易找到，你可以看到你做了多少。也是一个写日记的过程，是一个帮助你做遵规的过程。

    我们看到这张图从交付的角度来说，实际上交付给客户的到底是什么呢，甲方会怀疑你给我的什么东西，以前做得很粗放，搞一个大包送上来，如果遵规的话很严格你这个可执行文件给我的怎么出来的，你做出来的什么时间。然后这个里面的内容包含了哪些工件，最终你这个里面包含哪些功能，哪些文件和版本的变化，如果软件开发可以做到一个逆推的过程的话，可以做任何审计。不要老是想着正向推，如果出事的话要逆推找这个原因，现在没有客户没有办法说清楚在系统上跑的什么版本，但是逆推可以保证你的可追踪性。这个方面有很多的产品，Rational有很多产品可以帮助你做到可逆推的逆倒性。

    最后看看Rational的方案，从沟通的高层来进行管理，从战术层面上，变更和发布管理，质量控制架构方面的控制，还有细节的工件层面进行控制管理。在软件交付平台，Rational的覆盖程度很广，你在企业里面做遵规，这个方面改进的时候，一定要选择一个适合自己的开发过程，不要生搬硬套的去CMMI也好，或者Six  Sigma也好。第一步可以做拿来主义，第二步要根据自身的情况做定制，你定制好要按照这个方向去做，不断改进。Rational可以给你提供很好的支持平台和方法。那么从遵规的整个方案来说，IBM遵规是很庞大的方案，今天我们讲的方案只是侧重在应用的开发部署和监控的，如果你对IT的运行管理、信息管理，业务的监控这个方面感兴趣的话，IBM和其他的软件部门可以帮助你来做，IBM有五大软件功能，实际上针对五个不同的领域进行不同的解决方案。

    那么Rational的整张图可以看到，从战略层面上，从战术层面上，团队的协作上，以及每一种决策的支持上，有很多的工具，很多的方法可以支持。我觉得对大家最有利的是基于开放的平台，很多的公司，第三方的工具可以放在我们的平台里面去。我想提的最近的一个变化，我们刚刚收购一家企业，这家企业在做安全性测试，以前测试好了，用户接收测试，然后就上线了，但是在遵规的背景之下，当然看到遵规跟你的私密性，都有很多的关系，导致很多的系统出现了这个方面的问题，容易遭受攻击，个人资料被剽窃了。前不久出现一个网络问题，银行的网络系统被攻击了，发现个人的身份证号，密码都出现了。跟你的外部系统的安全性有很大的关系，所以Rational最近收购的这家企业专门做安全性测试的，你的应用系统是否具备了抗干扰性、抗攻击性。我们很多的网民系统，最后的有一个认证号的地方可以分析出来，可能受到黑客的攻击，然后有不同的参数测试。告诉你的URL不要这么些等等。这些Rational的产品，有一个非常强的安全性和遵规测试，特别是基于外部的系统，一般的应用系统有两个组件可以扫描你的系统里面是否有攻击的部分，特别是你的外部系统，我们不停地向这个方向做努力。

    最后我们看看整个Rational产品线的整个的可跟踪性怎么可以做到的。从一开始的业务线上，从需求管理开始，到你的提案的提出，基于提案做提案的审核，然后做投资回报的分析，最后做批准。然后做资源的组成开发团队。这条业务线都是有产品来覆盖的，比如说Rational  Portfolio  manager做项目管理的，会跟我们的有集成关系，然后在？进行追踪，还有针对需求的变更，然后进一步跟源代码进行关联，然后进行构建脚本，然后进入应用系统，然后进行发布。燃烧这些产品之间都是告诉可以集成的，然后进行测试，然后把测试结果保持在Clear  Quest进行追踪和部署，从而把整个脉络梳理清楚。如果大家要关心一下遵规更多的东西，我们有两门培训课程，还有一本非常好的红皮书希望大家可以阅读，还有药品检查的方面。

    给大家介绍一个案例，就要福特，每年投入IT方面20亿美金，按照IT服务业ITIL的方法进行投入。很遗憾他没有通过审计，发现他违规的地方上千。尽管照着ITIL去做的话，发现很多的方面不符。在投产方面缺乏职责分立，类似的这种情况很多。缺乏可审计和可跟踪性，谁，什么，为什么，哪儿，这些方面做的很差。通过Rational的应用，有4000个应用最后120个审查通过认证和审计。然后做到一个三权分立，开发人员，构建经理，部署经理，他们之间互相牵扯还有一个互相的关系。具体的审计和负责工具，开发组长签署变更，构建管理员，保证构建可以进行QA，可以部署到生产，一切环节做到职权分立，做到签署和可追踪。那么客户这边有这么一个决策，专门负责遵规方面的，得到的结果是你可以承受的方式通过审计，付出了很大的代价。但是至少是买了Rational的东西，通过审计。对应用开发部门，按照ITIL的原则进行了职责化，可以保证一个安全的生产环境。具体的控制方法，关键在工作流程中有三个关键控制点，第一点控制由开发组长来进行控制，把什么样的开发成果放在一个共享集成区里面去，要签字的。比如说上面面对上百开发人员，但是最后要集成起来，这个权限在开发组长那儿，是他负责。也许具体做事情的人是集成人员，做合并的人员，这个要负责对他的变化的审批。所以说对于共享区、集成区里面的内容，如果说我上回交错了，再交一遍的话，不是你想就可以，需要通过他的审批。第二控制点由构建管理员进行控制，所有参与构建的对于都会被加入版本控制，我只相信版本控制那条基线的内容，其他人给的任何传输的介质都不相信。因为那个东西是开发组长来负责的，中间不要任何干扰。否则一些非常细小的东西，可能产生不可预期的后果。第三我通过控制之后叫QA  Ready，可以进行测试，在部署的时候，由发布管理员进行控制的，如果没有被置成QA  Ready则不允许进入QA环境，如果所提交的基线没有被置为Prod  Ready的话就不允许通过。这是刚才实施过程的一个具体的做法。平时的开发活动有一个活动的实体进行跟踪和控制，一旦发生变更的话，有一个严格的变更处理过程，部署的时候部署包有自身的生命周期。几个方面有千丝万缕的转移的关系，我看到一个实体的状态的时候可以判断出来处于一个什么阶段，归谁负责。比如说放在这儿的时候，归谁负责，谁来签署以及这个传递的过程，从它到这儿的时候谁来传递，有一个非常强的流程化的控制。其实你日常生活当中，日常开发中不知不觉在遵守某种规定，变成习惯了，习惯成自然了，自然会产生效率。我们要正面看待遵规的问题。当然Rational有很多全球的其他的成功的案例。
    最后总结一下遵规管理对一些大型企业来说，对外的全球性的企业是势在必行的，包括IBM自身要遵守很多的规定。如果在座的是IBM的都知道，要求非常严格。包括正装的要求。最好的控制会产生最少的干扰。然后可以提供很好的IT治理的基础。如果想获得更多的案例、白皮书，大家可以上IBM的官方网站。