软件开发-转

创新，作为当前各行各业一个非常时髦的话题。针对软件行业来讲，体现的尤为淋漓尽致。可以不夸张的说，推动软件行业发展的永恒动力就是创新。

所谓创新，通俗地讲就是，别人没想到的你想到了；别人没发现的你发现了；别人没做成的你做成了。创新，涉及到软件生产的各个环节和领域，从环节上包括售前创新、售中创新和售后创新；从领域上包括理论与方法论创新、管理与制度创新、过程和控制创新、技术与工具创新、文化创新、科技创新以及其它方面的创新。

针对软件开发来讲，核心问题就是如何提升软件开发的质量和生产效率！本文抛开软件开发中人为因素这一重要内容，单从技术层面上论证和阐述，在软件开发过程中可以采取的创新点和改进建议。

1、业务驱动原则：当前的软件开发过程过多的强调需求或者功能驱动，进而将一个个功能分离开来各自为战，而忽视了功能是为业务服务的核心原则。因此，需要将现有的开发驱动方式做重大改变，需要站在更高的视角，也就是业务视角来驱动整个开发过程。总体开发流程是，首先通过深入分析用户的业务流程和工作目标，通过场景技术先创建出用户的业务模型；然后在基于业务模型分析实现这一业务目标的各个用户需求间依赖关系，得出用户需求模型；最后在用户需求模型基础上分析各个功能间的依赖关系，创建软件功能模型。通过这一流程，所开发实现的各个功能已经不再是独立功能，而是一组组完成一个个业务目标的功能集。

举一个简单例子，用户提出一个报表功能，按照以往的开发方式，我们在了解完成报表的呈现样式、各个字段的计算方式后，就可以展开开发。这样的开发结果，不但会预留这一功能需求不断变更的风险，而且更重要的是用户会觉得我们不专业、不懂它们的业务，进而影响到我们的名声。换种方式，采用业务驱动，我们应该先调研清楚用户为什么需要这张报表？通过这一报表用户要得到什么信息？报表数据对他们的业务有什么帮助？报表中各字段之间有什么关系？各字段的数据大小对他们工作有什么影响？用户了解完这一报表数据后，一般还要深入了解哪些数据信息？这一报表数据与哪些报表数据之间有关联关系等等。通过这样一系列业务层面分析，我们所实现的报表功能就具有非常强大生命力和指导性意义，对我们开发人员来讲，不但从这一过程深入学习和了解了业务，而且尽最大可能降低了需求变更的频度。同时，也会无形提升我们所开发系统的核心竞争力。

2、开发模式匹配原则：现在，事业部几乎所有项目号称都是采用NUP开发模式进行开发的。但实际情况呢？可能徒有其表。原因不外乎，一方面有多少PM或PSM真正理解和掌握了这一开发模式。很多人把CMM等同于开发模式，认为项目只要按照CMM过程进行开发，就符合NUP开发模式。这完全是谬论！另一方面，是不是任何项目类型都适合应用NUP模式来开发，可能没有人认真思索和讨论过。如果真是这样，那么业界就不会诞生那么多开发模式，更不会有那么多专家学者在深入研究和创建开发模式。因此，针对我们需要改进的，一是重点学习和掌握NUP开发模式，形成指导手册，然后通过宣讲、培训、审核和总结等步骤不断循环改进，让这一开发模式真正起到应有的效能；二是通过事业部所承担的项目特点，分门别类进行归纳总结，依据项目类型特点确定应采用的开发模式，并给出指导性意见。比如，针对产品研发类的项目采用什么样的开发模式；针对中小型解决方案特点的项目采用什么样的开发模式；针对全新项目采用什么样的开发模式等等。总之，开发模式是软件开发的基石，开发模式是否与项目特点相匹配直接影响到软件开发的进程。

3、UI/UE先行原则：针对信息化应用系统来讲，用户体验已经成为越来越重要的内容，而且也越来越成为软件的核心竞争力之一。随着时代发展，当前用户已经不满足功能所实现的结果，更加关注系统的使用体验。比如展现的样式是否能个性化、展现的方式是否能多样化、展现的内容是否能定制化、操作方式是否便捷化等。这样，就要求我们在开发方式上做重大的调整和改进，在系统或产品开发前应针对行业用户特点，利用心理学、社会学等方面的知识，按照人体工学的设计原则先行进行UI/UE设计，在最短时间提供给用户一个能真实感受到的系统。通过这一方式，不但在开发前期能更深入调研到用户需求，而且能避免项目后期大量的需求变更。这种方式与原型开发方法的最大的不同在于，它是站在行业用户视角考虑呈现。那么，针对象现在事业部这样的规模，没有专门队伍研究和琢磨这一领域，是不可想象的。

4、样式家族化原则：一个成熟的软件产品应有其内在的特色，有区别于其它产品的标志性内容。就象汽车行业，比如宝马汽车，自从诞生以来，无论外形、颜色如何变换，即使你没有看到BMW的标志，但你能从车的很多特点上，比如宝马经典的“双肾型”栅格，一下子就能知道这是宝马车。同理，在软件行业也有大量的这样案例，比如微软风格的界面样式、MAC风格的界面样式等。那么，作为我们这样一直从事业务应用系统开发的公司来讲，是不是也应该有这样的考量呢？不论用户应用我们任何一款产品，都能清晰的感觉到东软风格，这对东软所开发系统的整体声誉提升有着重大的战略意义。样式家族化，主要指展现层面图标的样式统一、布局方式统一、操作方式统一、交互方式统一等。这样，对外，用户使用过我们的一个系统后，再使用其它系统时感觉非常熟悉和亲切，增强了系统的亲和力；对内，家族化统一后，不但增强了复用度，提升了开发效率，而且将各个项目由于人的不同而造成的系统呈现差异降低到最小。通过在事业部整合资源，建立样式库，使项目开发人员更加专注业务实现。

5、    组件化开发原则：在软件开发模式和方法上，如何将软件开发向软件生产转变，也就是如何从手工作坊式开发向流水线生产转变，是业界研究的重要内容之一。其中，能否转化的关键就是，是否有大量可复用“零件”。按照工业化生产概念和流程，工业化产品最终是通过组装完成，并不是由一组人在一块胚料上打造完成。那么，针对软件行业来讲，这一方式是否具有借鉴和指导意义呢？道理是相同的，只是具体手段有区别而以。针对当前事业部来讲，十多年的软件开发，累计的代码量可能成几千万或上亿计，但到现在为止，我们所开发的系统代码复用度有多高呢？是否已经达到组件化组装生产呢？因为没有调查研究，不能妄加评论。但无论现状如何，提出改进方式：一是在事业部，最低标准在部门建立组件库，为此要建立完善的组件库管理规范（当前我们部门正在做有意义的探索）。二是在项目规划阶段，要增加软件复用度的规划，重点是组件复用度规划。在部门或事业部级别要对这一项做重点审核，因为代码复用和组件复用完全是两个层次，对软件开发生产效率和质量的影响有天壤之别；三是在项目总结阶段，在总结过程中要将这一系统哪些内容具有复用性进行重点总结。将可复用需求抽取后，按照研发的思路将这一需求形成功能组件，以利后面的项目复用。这样周而复始，在组件库容量不断增加的情况中，系统复用度也会不断提升，最终，走到组件组装化生产过程；

6、核心竞争力培养原则：一个产品或系统是否具有强大的生命力，是否能在激烈的市场环境中始终取得领先的地位。在技术层面，一个重要的条件，就是是否具有核心竞争力。比如，Ipone手机核心竞争力是什么？一个是用户体验，另一个是开放的平台。从手机基本功能上，它并没有什么特别之处，但就因为抓住了以上两点，在市场上具有了蓬勃的生命力，进而为公司带来了可观的利润。再比如IBM公司，在软件领域，它在国内的核心竞争力是什么？是强大的业务咨询和系统规划能力，并不是它的软件产品。IBM通过网罗各行各业的业务专家，以群体而不是个人，向用户展示了他们强大的、高人一筹的业务咨询和系统策划能力，进而带动了他们产品或系统的销售。那么，对于我们这样一个从事解决方案类型的公司，在没有强大咨询能力带动系统销售的前提下，我们又该如何？是不是软件最低端的“蓝领“工作是我们唯一选择。我个人以为，我们可以在以下层面重点培育和培养我们系统的核心竞争力：

1）  核心业务模型研究：核心业务模型是系统基石，通过深入研究业务模型，实现系统的高扩展性、高适应性和高配置性。

2）  核心处理算法研究：比如计费算法的研究、拓扑发现算法的研究等等。通过核心算法的研究，不断提升系统的处理效率和算法的灵活性，使之，不但提升系统的整体运行性能，而且加快系统的响应速度；

3）  业务展现逻辑研究：应用用户体验的设计原则，在深入研究用户业务特点的基础上，在展现层面提升用户体验，比如系统图形化展现就是其中之一，这样，提高系统的易用性和友好性；

4）  系统搭建模式研究：现在很多大、中、小型的网站，并不是一点一点从头到尾分析、设计开发完成，而是采用内容管理产品或系统，通过配置方式实现智能、灵活、高效的搭建。而当前我们所开发的系统大多数是信息管理系统（MIS系统），那么，这种系统搭建方式也可以借鉴过来。这样，从根本上改变现有系统开发方式，能更快的完成系统建设。缩短实施时间，从而节省大量开发成本。

这样的核心竞争力还有很多，需要我们认真研究和探讨。总的原则就是找到差异性！创造出人无我有、人有我好、人好我优的局面。这就要求事业部在管理层面就要宣导和推动我们核心竞争力的研究。

    总结起来，在创新内容上，不能为了创新而创新，应该始终以“谁将从创新中受益？”、“是否对软件质量和生产率有根本提升？”为导向；在创新思想上，以不断“超越自己”、追求“更高、更快、更强”为最高目标；在创新过程中，以“先僵化、再优化、最后固化”为行动原则；只有这样，我们的改进和创新才会有效力，才会产生最大的效益，才会让我们所开发的系统站在软件行业之巅！