PTC收购MKS 热门话题PTC计划要收购MKS
发布时间：2012/1/4 21:43:47 | 人感兴趣 | 评分：3 | 收藏：
- PTC收购MKS 热门话题PTC计划要收购MKS PTC收购MKS 热门话题PTC计划要收购
-
- 几个星期前我同几个老朋友在波士顿吃午餐。我们几个谈到了最近业界的动态，然后就转到了PTC收购MKS这个话题。
- “我不是很了解这个的意义，对我来说没有意义”。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。我们已经讨论过了功能上的原因，接下来我将从业务和我个人的角度来谈论一下这个问题。
您看到此篇文章时的感受是：
[1] 
