软件从它诞生之日起就带着“手工”生产的烙印，甚至有人将软件看作是程序员的“艺术作品”，而“艺术作品”当然是只能用“手工”方式生产的。
这些年来，尽管软件发展得愈来愈大，愈来愈复杂，但它的生产率仍然十分低下。颇有讽刺意味的是，当一些传统行业，比如制造业，在软件的帮助下走向自动生产、柔性制造时，软件本身的生产却仍然远离自动化、缺乏灵活性，基本上还停留在落后的“手工”生产阶段。
在IT领域，作为孪生兄弟的硬件和软件，经过了几十年以后，这两兄弟的差距却愈来愈大了。这些年来，硬件的发展始终遵循着“摩尔定律”，每一年半性能翻一番，而支撑着硬件的这种指数律增长的是硬件的自动设计技术，即EDA技术。依托EDA工具，硬件的设计已经达到了高度的自动化，例如一个开发组可以在几个月的时间里设计出包含百万晶体管甚至千万晶体管的集成电路芯片。相比之下，软件的发展并没有类似的“摩尔定律”，软件落后的“手工”生产方式使软件的发展大大落后于硬件，比如软件规模似乎只能以很慢的速度增长，从Windows3.1发展到Windows2000，在9年的时间里源代码行数只增长了9倍左右。
我们可以对软件生产率作个估算。中国一些公司的经验表明，从零开始，开发百万行源代码等级的大型软件，几百人的团队大约需要五、六年时间才能达到实用水平。折算起来，也就是每人年约2000行源代码而已。最近欧盟关于
开源软件的研究报告（《
开源软件对欧盟信息通信技术（ICT）部门创新与竞争力的影响》）对
开源软件Debian3.1作了估计，它的2.21亿行源代码如果由专门程序员开发，将需要16.4万人年，折算起来，也就是每人年约1300行源代码。由此可见，大型软件的生产率每人年只有一、二千行源代码，而且软件愈大，生产率愈低。
图灵奖获得者、计算机科学家布鲁克斯曾在其著名文章《没有银弹》一文中提出一个论断：“没有一种单纯的技术或管理上的进步，能够独立地承诺在10年内大幅度地提高软件的生产率、可靠性和简洁性”。他的这个论断是要强调，提高软件生产率是多么困难！但即使如此，人们还是要朝这个方向努力，因为对此有迫切的需求。
首先，提高软件生产率是软件厂商的迫切要求。今天，几乎所有的软件公司都不能摆脱软件计划延迟、开发预算超支、版本不能及时推出的困扰；至于软件缺陷更是无法避免，人们不得不一次次地发布补丁，而又一次次地发现新的缺陷。
其次，提高软件生产率也是用户的迫切要求。现在的企业面临激烈的竞争，为了提高竞争力，就要推进信息化。如按需求重新开发软件，无论是自己开发还是委托软件公司开发都需要很长的时间；如是购买现存的通用软件，也需要进行定制，同样非常费时。即使软件开发或定制出来了，但市场情况瞬息万变，软件应当能快速响应，而现在的软件却很难做到。所以，很多企业的业务都受到软件的制约。总之，软件厂商也好，软件用户也好，都希望能突破软件生产率的瓶颈，寻找解决这一问题的出路。
布鲁克斯认为，提高软件生产率不能由一种技术或管理的进步达到，也就是不能用一颗“银弹”解决问题，他也许是对的。但是否会有某些技术或管理对提高软件生产率产生重要的、甚至是决定的作用呢？也就是说，如果不能用一颗“银弹”，那么是否能用一些“银弹”解决问题呢？
构件技术显然有可能成为这样的“银弹”。在集成电路领域，构件技术取得了极大的成功，硬件的构件小至“标准单元”，大到“IP核”，都可以在集成电路设计中复用，大大提高了硬件的生产率。可是软件的构件概念提出了多年，却很难实现产业化，看来至少有两方面的原因。一方面原因是，将软件构件技术产业化需要有一个高效、实用的构件平台。正如普元公司的经验所表明的，它们开发了EOS
中间件平台，即一个以构件为核心的生态系统，包括了构件运行环境、开发环境、应用管理环境、基础性的公共构件库、以及面向构件的方法学和经验论，有了这样的平台，很多用户就容易采纳构件技术，并容易取得成效。
|
服 务 CIO 推 进 信 息 化 
