原文 by Chad Jackson “我不是很了解这个的意义，对我来说没有意义”。PTC发布这个消息后，我交流过的很多人都是这个反应。所以，这个帖子，想阐述一下那次午餐上我的观点。“这个动作将会改变PLM这个行业。”
背景 回到2011年4月7号。PTC宣布收购MKS的意向（press release）。交易最终于2011年5月31号结束（press release）。MKS的核心产品是Integrity，提供了需求管理，软件配置管理(wikipedia entry)和应用程序生命周期管理(wikipedia entry)等功能。 提供的功能 那么，Integrity到底能做些啥？这和PTC有啥关系呢？我的解答包括两方面：一个是涉及到产品信息的记录，还有一个是关于跨学科工程领域的流程管理。 产品信息中更好的粒度 在我解释为啥MKS的收购会对PTC的产品Windchill作出一些改变之前。我想先提供一些上下文（下面是我之前些的文章Mechatronics Management (Part 3): Software Aspects 请查阅它山之前的翻译）中的一些段落。相关的观点如下： 现代软件开发实际上与机械或电气设计非常类似。软件研发分解成模块。这些单独的模块依次被编写，组装和编译。整体而言，这非常类似于机械或电气部件的设 计，每个单独的零件放在一起成为组装件。各个版本软件模块由不同频率的变更形成，这很像机械和电气元件。最终组装的软件是由众多的软件模块（存在不同的版 本）组成的。跟踪软件模块是哪个版本就是配置管理的问题。现代软件配置管理（SCM，维基百科条目）跨越多个站点同时为众多用户自动化地管理这些版本。 此类型系统的主要目的是确保正确的配置被正确地测试，验证，并烧入到机电产品中。而随着新的软件开发方法多采用daily builds (wikipedia entry)，配置变得非常重要。但也有很多其他原因。正如在机械和电气设计一样，软件设计的重用可以节省大量的时间。现有的不同的软件模块再利用就意味着少量的纯新软件的编写和测试。这也意味着同重用软件模块代码关联的低风险。 以前（还会持续一段时间）PTC的Windchill已经有了“软件配置管理”的集成（SCM）工具。此工具仅仅是将编译好的软件作为若干项插入到产品结构树和BOM中。这种集成并没有将“未编译的代码”和“库文件”（用来编译最终软件成品的构成项）显示出来。就像是机械组装件作为一个大疙瘩而没有任何零件和特征的信息。 Windchill和Integrity的集成意味着“嵌入式软件”更细的粒度。进入到下列的“评论和分析”后，我们再谈谈其重要性吧。 跨学科流程 它不仅仅是从更细的粒度来管理嵌入式软件哦。实际上嵌入式软件开发的本身也有严谨的流程。我想引用前一篇稿子earlier post（见它山前面翻译的帖子）来解释。 就像任何产品，最终的软件产品有一个属于自己的生命周期。它从需求管理，需求分解和需求分配开始。然后有那么一个阶段规划该软件最终产品的架构设计。接下 来的进行代码编写并使用到各类项目管理技巧以及频繁地进行测试。最后它被发布出来，然后启动变更管理流程来管理如何，何时和为什么要更改。 工程领域中跨学科的流程大部分都很类似。但是在收购前或Windchill，Integrity两者整合前。这些流程要么在Windchill的机械设计管理部分运作，与此同时，软件部分的流程在Integrity中运作。为什么呢？因为这些流程是同产品结构中某些项目关联得。没有编译过的代码和库文件并没有放在windchill里面，所有你不可能将软件需求和它们关联上。就像在Integrity里面没有机械元器件的管控，所以涉及到机械元器件的管控就不可行了。最重要的是一个变更流程里不能够囊括相关联的“未编译代码”和“机械元件”，好像他们不能够共存似的。 不远的将来，集成完成后，被流程影响的两个领域就可以一起运作了。你可以将需求分析分解并分配到产品模型树下（包括机械元件，编译的软件，未编译的软件和库文件）。同时变更流程也能够涉及到两个领域。还有验证，测试流程等等。。 评论和分析 花了点时间才进入主题。虽然我不想在谈论这个主题前喋喋不休。但是没有上面细致的探讨，也许你还在不停地想为啥PTC需要收购MKS。我们已经讨论过了功能上的原因，接下来我将从业务和我个人的角度来谈论一下这个问题。 整体配置管理和跨学科流程 首先，我们讨论一下配置管理吧。为了了解这个方法。我们需要一些背景。 你应该知道，很多时候产品信息中的软件配置依赖于部分硬件的配置。以前都是由人手动地用电子文档管理这些相互依赖关系。假如考虑到产品中大量的变形设计的话，这里面就有两个事情会发生。一个是主管配置管理员工的工作量将会变得很多很难，变得令人沮丧。第二个是，考虑到手工管理是不太能够保证各个项目（item）相互间100%的匹配度，这就有可能会在下游发生错误。也许你可以努力去避免错误，并且最后有可能搞定一切。但问题是有很大的可能，你会错过之前预订的计划，结果是订单变更了，产出的产品变废品了等等。 跨学科的流程也是同样的道理。对机械部件和软件代码的需求分析分布在电子文档中，或是PLM,ALM系统中。这些分离的系统实际上是增加了我们手动工作量来匹配各种产品配置。除此之外还有协调产品变更，验证和测试等流程。当前大部分的这类跨学科研发流程都是通过手动管理的。而结果就是沮丧，错误，延期等纷至沓来。 显而易见的是Windchill和Integrity的集成将细化产品结构下机械部分和嵌入式软件部分的管理。这样一来，在同一个产品结构树下的我们可以处理机械部分和软件部分的复杂的配置信息。我可以看到两者融合带来的极大好处。 一个纯粹主义的视角：打开天窗说亮话 虽然我承认非常看好这次收购，但对整个业态还是持有一个疑问。 为啥这个动作推迟了这么久？ 我并不是针对PTC来谈这件事情的，而是这个行业。多年前我们就被PLM厂商告知——仅仅需要将编译好的软件作为“成品”（end item）罗列在产品结构树下就好了。我们还被告知其他部分（比如软件部分）不需要被罗列出更细的层级。 实际上PLM供应商迟迟没有进入这个领域的真实原因并不是我们想的那样。相当一段时间，IBM的Rational产品在软件需求管理（RM），SCM和ALM领域上所向披靡。但是却没有一家真正关注于产品的嵌入式软件管理的供应商，有针对性地为机电一体化产品研发出一个新的RM，SCM和ALM系统。我想这类研发本身将是一个漫长而艰辛的努力过程。最终PLM供应商不得不做出明智的业务决策—–投资这个领域将会让自己出类拔萃，当然也可以更容易地赚钱。但是说实话，我们能责怪他们吗？ 对于机械和软件的跨学科研发，我们还是可以看到将配置管理和研发流程集成在一起的好处。我希望其他PLM供应商可以做出类似的行动—-提供具有竞争力的产品。但说实话，为机电产品提供RM， SCM和ALM的解决方案的厂商真的很少。 这些又让我想到了很有趣的一点： 为啥PLM供应商不能对电子和PCB的信息提供如结构设计同样级别粒度的管理？ 当然跨机械和软件的管理带来的好处同样适用于电子工程。在PCB,轨迹，组件和元件库之间存在着不同层级的粒度。这就像未编译的软件代码和软件库共存于Windchill一样得。FPGA编程也是如此，这种方法在电子工程中非常流行。然而三大PLM软件供应商和其他较小的供应商现阶段的情形就像若干年前软件行业中的SCM。天知道以后会咋样，但我敢肯定会有不断的惊喜哟。 总结和结论 PTC收购了MKS公司并将整合Windchill和Integrity产品，这种整合将为机械和嵌入式软件提供更细粒度的产品配置管理。它还将提供跨学科的流程管理，如需求管理，测试，验证和变更管理等等。最终效益将会减少这两个领域中因为手动操作带来的个人或组织上的失误。 轮到你来权衡了，你是如何看待跨学科的配置和流程管理的呢？你是否看到了整合后带来的优势？机电产品中更细的粒度是啥？它是否应该被添加到产品结构里呢？就此打住吧，希望听到您的想法。 谢谢阅读！！ |
