软件产业化软件外包的未来之路.docx

软件产业化软件外包的未来之路.docx

《软件产业化软件外包的未来之路.docx》由会员分享，可在线阅读，更多相关《软件产业化软件外包的未来之路.docx（7页珍藏版）》请在冰点文库上搜索。

软件产业化软件外包的未来之路

软件产业化-软件外包的未来之路

软件产业化-软件外包的未来之路

北京瑞富恩杰科技有限公司范世虎

一、总述

软件产业化一直是我国软件界同仁的梦想，国家也为实现软件产业化投入了很多力量，然而，我国的软件开发水平却一直是处在国际软件产业的中下游水平，不要说产业化，很多软件企业都在为生存而战。

什么是软件产业化，不是我们的软件企业多，从业人员多就是产业化了，而是要看主流生产企业有没有通过先进的生产方法，高效率的生产出高质量的软件产品。

相关的配套生产企业和服务企业有没有可持续发展的前景。

纵观计算机制造业的迅猛发展，硬件技术及硬件性能的提高速度总是快于软件，但是考察一下软件开发的速度，可以发现软件开发的速度一直远远地落后于硬件的速度。

原因是硬件的生产已经形成了产业，如果我们每一台计算机都需要从制造螺丝钉开始的话，那么就不可能有今天的电脑时代。

实际上我国业内人士一直没有停止过对软件产业化的探索，只不过国内快速地对软件

软件项目合作：

供应商针对客户大型IT项目，分承包子项目或子系统的开发工作，发挥专业人员数量和小组管理优势，与客户或合作伙伴达到优势互补、共同发展的目的。

1、软件项目开发：

针对客户的软件应用目标，承包客户软件应用项目开发工作，交付完成目标系统。

项目开发服务要求供应商具有全面理解客户需求、系统分析设计的能力，以及专业的软件项目总体组织能力和环境，稳定、规范的技术人力资源；还要求供应商具备规避一般开发和技术风险的能力。

2、软件咨询/设计/技术合作：

为已经成熟的软件产品的实施提供咨询，或者参与软件产品的设计，或者在新的技术领域上双方展开合作。

这类外包项目需要供应商具有很强的行业经验、技术实力等因素，所以附加的价值也比较高。

以上四类中，主要还是以人员外派和软件项目合作为主要发包内容，从软件工程的角度来看，这类项目并不能覆盖全部的软件生命周期，也就是说，在完成一个软件产品的过程中，这类项目只是完成里面的一部分工作，就好像造一辆完整的汽车，我们只是完成安装车轮或者安装座椅的工作，无论从管理方面还是从技术方面，这都不能代表我们掌握了制造软件的最先进的方法，说得更确切一点，我们只是在做着代工和测试的工作，劳动强度大，附加价值低，软件工程当中核心的分析和设计过程，我们并没有涉及到，即使我们建成了中国的班加罗尔，也不过是世界软件代工的中心，还没有达到我们的目标。

那么我们的目标是什么呢？

软件外包的内涵，绝不仅仅是软件代工，而是成为软件生产和服务的巨头。

只有自主创新，走出我们自己的软件产业化道路，才能真正实现软件强国的梦想。

三、软件产业化

在其他行业，提高生产能力的途经是从手工作业过渡到机械生产。

在手工作业阶段，所有产品都是由个人或小组从无到有制造出来的，而在机械生产阶段，各种产品通过组装多家供应商生产的可重复利用的组件迅速生产出来，在这个过程中，许多机械琐碎的任务都是由机器自动完成的。

这些行业对工艺、设计和包装进行标准化，借助产品线实现系统性重复利用，并通过供应链分担成本和风险。

现在已有部分行业可以实现大规模定制，根据需求快速而经济地制造出各种产品，以满足不同客户的特定要求。

软件能够实现产业化吗？

假设可以在软件行业实现产业化，那么结果将会是什么样子呢？

我们可以根据国外软件行业的发展道路以及其他行业产业化后的情形作出合理的预测。

不过有一点可以确定，软件开发永远不会简单到有些人们所希望的那种纯机械化的程度，输入我们的需求，就能自动产生满足我们要求的软件。

软件产业化，可以从三个方面进行考虑：

1、标准化的软件工程规程和工艺要求

相对于其他行业，标准化的软件工程规程和工艺要求在软件行业还不是很普遍。

那么什么是软件工程规程和工艺要求呢？

那就是在生产软件产品或者开发软件项目的工程过程当中，应当遵守的标准化的工作流程和规程，以及产生的工作产品应当达到的工艺水准。

按照标准化的工作流程和规程，可以保证生产的过程有序可控，不同的工作小组之间可以通过统一规范的标准来达到互相理解。

这一点在国内的软件开发中很难做到，不管是需求文档，还是设计文档，一人一个样，除了自己没有其他人能看懂。

所以我们的软件开发从需求开始到最终的验收，都必须是同一批人来实现。

有些公司已经能够实现在公司内部的交接，但是对于软件产业化的要求来说，还差得很远。

至于说到软件的工艺水准，就是通过数字来说明软件生产过程当中以及软件质量的一些关键指标，这一点在国内更是凤毛麟角，如何衡量一个软件产品的质量，能够说明问题的数字实在少的可怜。

在软件工程规程和工艺要求方面，CMMI的5个等级的实现，可以说是不二法门。

无论从项目管理，工程过程还是质量审计都有严格的过程和规程要求，企业如果达到CMMI3级的水平，已经具有了规范的生产流程和规程，并且开始注意收集数据和分析数据。

在企业达到CMMI5级水平的时候，就可以通过量化的指标来反映软件质量的提升。

如果没有软件工程规程和工艺要求做保证，就是再先进的技术，再优秀的个人，也无法制造出高质量的，有生命力的软件。

2、建立业务数据逻辑模型和模型驱动的开发方法

无论多么复杂的软件，它都有一套完整的数据逻辑模型。

每个数据逻辑模型既有它的普遍性，又有它的特殊性。

普遍性是说它代表了行业的主要特点，只要是本行业的应用，都会遵从相应的流程。

特殊性是说在不同的实际应用当中，又会有不同的取舍和变化。

这样一套数据逻辑模型，应该是由本行业的专家制定，经过不断的完善和发展，并且在实际应用当中检验过的，最能代表本行业的现状和发展的模型。

有了这样的模型，在做软件需求分析的时候才会少走弯路，同时，所积累的经验也能为他人所共享。

听起来好像对于需求的分析本来就应该是这样来完成的，但在实际的软件开发过程当中却不是这样。

需求的确定主要还是要靠有行业经验并且了解软件开发的人员来担当，需求的准确性和应变能力完全取决于需求分析人员的经验，这也是软件需求变化较多，成功率较低的一个原因。

与此同时，本行业的企业在进行信息化建设的时候，往往还在继续重复地走着别人走过的弯路。

即使对于一个很特殊的行业，在初次进行信息化建设的时候，也应该建立一个数据逻辑模型。

并且把它发布到公共的区域，使相关的专业人士能够对它提出意见和建议，不断完善，最终形成权威的应用架构。

数据逻辑模型对于外包事业更是益处多多，如果我们掌握了发包方的数据逻辑模型，不仅能加快软件开发的效率，还能为发包企业规划信息化发展的方向。

在具有权威的数据逻辑模型后，就可以运用模型驱动的方法来开发软件，甚至能够实现代码的自动化。

3、软件构件化方法

软件构件化是以数据逻辑模型为基础的，有了规范化的模型，在经过软件建模的设计技术的抽象（例如UML），划分为不同的构件，通过构件的组装来实现高效率的软件生产。

构件有如下的几个基本属性。

1、构件是可独立配置的单元，因此构件必须自包容；2、构件强调与环境和其他构件的分离，因此构件的实现是严格封装的，外界没机会或没必要知道构件内部的实现细节；3、构件可以在适当的环境中被复合使用，因此构件需要提供清楚的接口规范，可以与环境交互；4、构件不应当是持续的，即构件没有个体特有的属性，理解为构件不应当与自身副本区别。

那么构件是如何和模型相结合的呢？

模型根据业务的需要，定义好和构件对接的标准接口（如下图），模型是本行业认可的业务架构，不同的供应商可以各施所长，制造出效率最高，设置最灵活，稳定性最好，价格最经济的构件，只要符合与模型对接的借口规范，能够于模型紧密结合，就能实现盈利。

四、软件外包的未来之路

试想未来的软件外包事业，在软件产业化的环境中迅猛发展。

我们有专业做行业需求分析的企业，他们为客户建立起具有前瞻性的先进业务模型，同时又能为客户量身定做符合自身特点的应用系统；我们还有专业的软件设计企业，设计软件不再是类似代码一般的搭建架构，而是寻找最适合业务模型的构件，定义它们的装配顺序和集成准则；我们有大型的软件工厂，开发代码成为重复性的装配活动，由软件产业工人来完成；我们还有大大小小各种生产构件的企业，它们只要按照接口标准，生产性能越来越优良的构件，放到市场上去卖，不论哪个客户，买回去一装配就能用；软件的质量不再全部押在测试阶段，因为在软件开发的每个环节，质量都是有保证的，规程的审计结论和工艺数据说明了结果。

而最振奋人心的是，所有这一切活动，都是由不同的企业，不同的人完成的，但是大家却可以很清楚的互相理解对方的意图，那是因为我们有了统一的、标准化的交流方式。

到那时，世界各地的订单像雪片一样的飞来，他们只要按照我们的规格，详细填写需求说明书，剩下的事情就有我们来完成，以前需要1、2年才能完成的项目，在我们这里最多也就是几个月。

我想，这才是软件强国的样子。