国内软件产业的发展在各种因素的影响之下，行业应用软件的产品化和通用化程度始终得不到根本性提高，使软件企业的运营成本居高不下，软件质量得不到有效保证，从而制约了企业的进一步发展，进而影响了整个产业的发展。
要使我国的软件产业步入良性循环的发展轨道，就必须改进软件企业的作业模式，提高行业应用软件的产品化和通用化程度，降低企业运营成本。本文针对国内应用软件的现状，分析了应用软件规模化推广过程中的主要难点，着重介绍了集中式开发模型的特征，提出了在渐进的过程中提高应用软件产品化和通用化程度的解决方法。
由于我国各个行业的改革正在持续进行，行业运作模式本身并不成熟，一直处于动态的发展之中，因而导致业务需求多变，应用软件的个性化需求与共性化需求之间的比例失调，行业应用软件的实施成本，尤其是维护成本无法降低。
一方面，用户要求定制的服务，这也是软件企业参与市场竞争必不可少的条件之一; 而另一方面，软件企业为了降低运营成本，又必须走规范化管理的道路，并不能完全满足行业用户提出的个性化需求，这就产生了矛盾。
目前国内多数软件企业的管理模式本身并不成熟，缺乏足够的经验和管理手段来应对这种局面。当用户群和员工数量发展到一定规模之后，由于管理方法的不当，软件项目的质量和软件版本往往处于失控状态，导致��户不满，进而影响了企业的声誉。
产品化和通用化的一个主要特征就是软件产品的集中式开发，这种开发模型给设计控制、版本控制、质量控制等带来的益处是显而易见的，尽管许多企业都意识到必须通过改进作业模式来改变现状，然而企业在实施软件产品集中开发的过程中，会遇到这样或那样的困难，常常导致此项工作难以持续推进下去。如何有效推进集中式开发模型，是一直困扰着众多软件企业发展的难题之一。

集中式开发模型的风险

首先需要明确以下两个概念：软件的产品化意味着组成应用软件系统的各个部件是可复用的，即应用软件是由一系列具有高内聚、低耦合特征的部件组成，这些部件应具有最小的功能粒度，按照一定的规则进行组合搭配之后，可以满足同一行业的不同类型用户提出的应用需求；软件的通用化意味着软件系统在行业应用中具有较高的实用性，即开发出的应用软件系统可以在各个用户单位投入实际应用，而不必对软件系统进行架构上的修改。
产品设计的风险 推行集中式开发模型，产品设计人员不能在现场进行开发，在相当程度上减少了与用户直接沟通的机率，可能导致设计人员不能准确理解用户的需求，使产品设计方向产生偏差。由于开发环境不能模拟出真实的运行环境，常常会使设计开发出的产品的性能指标不能达到运行要求，这也是造成推行集中式开发模型失败的主要原因之一。
解决问题的关键在于，设计开发人员要充分参与到各个待推广项目的需求调研和分析之中，建立起与一线用户的沟通渠道，如果能够很好地解决这一矛盾，那么软件产品的实用性也就有了保证。
人员意识的风险 这里之所以把人员意识上的风险单列为一个标题来进行阐述，主要基于以下原因，我国的软件技术人员，包括项目管理者在内，普遍存在独立工作能力强，而协作能力较差的特性。归根结底是由于国内软件行业长期存在的作坊式生产方式，造成了人的行为方式的自我封闭，企业管理者也缺乏足够的管理经验，推动员工按照流程和规范行事，传统的思维习惯给新工作模式的推行造成了阻力，这也是国内软件业发展乏力的重要原因之一。
版本控制的风险 在推行集中式开发模型的初期阶段，为了快速形成原型系统，常常会采取现场实施与集中开发相结合的方式进行原型构建工作，这往往导致设计开发人员与实施人员之间没有明确的分工界面。由于工期和版本控制手段的限制，在并行实施多个软件项目时，不同的项目实施组之间往往是相互封闭的，在现场分别解决用户提出的类似需求，造成工作量的重复和软件版本的不一致，软件产品的安装数量越多，后续升级和维护的工作量就会成几何级数上升，最终超出企业所能承受的范围。
已经完成设计开发，并同时在多个用户现场投入实际运行的软件系统，由于版本更新的不及时或更新存在的时间差，也会导致软件版本失控，从而失去了集中式开发的本来意义。
项目进度的风险 在软件产品开发的初始阶段，用户往往提不出有实质意义的需求，不同类型的用户基于自身工作的需要，提出了很多个性化需求或在技术上较难实现的需求，导致需求经常性地处于未明确和待定状态，增加了设计开发的难度和工作量。
而现实情况是，用户往往要求能够将软件系统尽快地投入应用，软件产品开发工作的组织者在限定的时间范围内，很难制订出一个合乎实际的工作计划，常常导致计划延期或上线系统不稳定。
另外常常出现这样一种情况，软件开发的管理者机械地套用软件工程标准，而不是根据实际情况，对软件生命周期的各个阶段进行必要的裁剪，未充分意识到并行开展各阶段工作的重要性，浪费了本来就不多的时间资源，从而导致软件系统交付的延期。

如何实施集中式开发模型

根据行业应用的特点，推行集中式开发模型需要设立一个软件产品组，负责软件产品的需求分析、架构设计、代码开发工作; 还需要设立一个质量控制组，负责软件产品的质量控制和配置管理工作；根据市场拓展情况设立多个软件实施组，负责软件产品的需求调研、安装、调试和实施工作。

在完成需求调研和分析工作之后，首先需要对软件系统中涵盖的各个功能进行细分，分割成相对独立的一个个部件，将用户需求变化不大的部分和用户需求变化较大的部分分离出来，界定出软件系统的核心功能和外围功能。根据行业用户的信息化应用水平及业务模式特点的不同，采取不同的集中式开发模型。以下就不同模型的作业流程和各自的优缺点分别展开论述。

1．集中式开发模型一

本开发模型是一种完全集中式的工作模式，软件产品组、质量控制组与软件实施组之间的关系如图1所示：
 


图1 开发模型一中的软件产品组、质量控制组与软件实施组之间的关系

在本开发模型中，产品组负责软件系统核心与外围功能模块的设计开发，接受实施组反馈的用户需求和问题，开发或修正相应的功能模块。
实施组负责对用户需求进行调研，发现系统运行过程中存在的问题，用书面的形式对需求进行详细描述和分析，提交给产品组进行开发或修正，并进行软件系统的现场安装调试，保障系统的稳定运行。质量控制组负责监督软件系统开发过程中的流程控制，并对软件系统进行测试和配置管理。
这种开发模型的优点在于，在管理手段到位的前提下，能够确保各个项目现场的软件版本完全统一，便于实施版本控制和质量控制，将需要投入的人力、物力和时间资源降到一个较低的水平。
这种开发模型的缺点在于，当项目数量超出了一定的临界值（如5个），用户的个性化需求将成几何级数增多，产品组无法及时响应或软件系统的架构无法支持各个用户提出的本地化需求，从而导致实施组的抱怨和用户满意度的下降，还有可能导致集中式开发模型无法继续推进，而回到现场开发的老路上去。
本开发模型的适用范围：用户对行业的业务模式十分成熟，软件系统经过相当一段时间的应用，功能比较全面，质量比较稳定，能够满足不同类型的用户提出的绝大多数需求。

2．集中式开发模型二

本开发模型是一种集中式与分散式开发相结合的工作模式，软件产品组、质量控制组与软件实施组之间的关系如图2所示：
 


图2 开发模型二中的软件产品组、质量控制组与软件实施组之间的关系

在本开发模型中，产品组负责软件系统核心功能模块的设计开发，接受实施组反馈的与核心功能相关的用户需求和问题，开发或修正相应的功能模块。
实施组负责对用户需求进行调研，发现系统运行过程中存在的问题，用书面的形式对需求进行详细描述和分析，与产品组共同界定需求的性质。属于核心功能的部分，提交给产品组进行开发或修正，属于本地化的部分，由实施组进行开发或修正，同时进行软件系统的现场安装调试，保障系统的稳定运行。
质量控制组负责监督软件系统开发过程中的流程控制，以及对核心软件系统和本地化功能进行测试和配置管理。
这种开发模型的优点在于，在管理手段到位的前提下，对核心软件系统实施版本控制和质量控制，快速响应用户提出的需求。只要核心系统的版本一致性问题解决了，软件质量也就控制住了。这样可以形成一个良性循环，在条件许可的情况下，可逐步降低现场开发的比例，提升软件系统的产品化程度，从而为大规模的市场推广建立基础。
这种开发模型的缺点在于，需要投入较多的人力、物力和时间资源。由于软件系统的架构可能无法完全支持不同用户提出的本地化需求，造成实施组开发或修正的外围功能与核心软件系统不兼容，从而对系统的正确稳定运行造成一定的影响。
本开发模型的适用范围：行业用户的业务模式处于频繁变化阶段，软件系统经过相当一段时间的应用，功能比较全面，质量比较稳定，能够满足不同类型的用户提出的大多数需求。

3．建议的开发模式

从以上分析可以得出，第二种开发模型较为适应目前的行业状况，在行业用户的业务运作模式和软件企业的管理模式都趋向于成熟之后，将会逐步过渡到第一种开发模型，这是一个渐进的过程，在目前的客观环境下并不具备一蹴而就的可能性。不同的行业应用状况，可以灵活运用不同的开发模型，亦不可一概而论。同时，为了保证集中式开发模型的顺利推进，现提出以下工作思路：
用户需求的集成 需求包括两个层面的含义，第一个层面的含义是指外部需求，即用户提出的需求，包括业务和技术方面；第二个层面的含义是指内部需求，即研发团队提出的需求，主要指的是技术方面，但其也来源于用户提出的需求。所以下面所提到的需求均为用户提出的需求。
按照领域工程的概念，在实施8～10个同一类型的软件项目之后，就具备了实现软件产品化的条件。同一行业的不同类型用户都会提出各自的本地化需求，对用户提出的这些需求进行仔细分析后，我们常常会发现，某几个用户提出的需求往往具有相似的特征。
当用户提出一个需求时，需求分析人员首先需要判断这个需求是否包含在已有的部件之中，如果是，则将这个部件挂接到系统之中; 如果不是，则需要将这个新增需求封装为一个新的部件。通过将各个用户提出的需求不断集成到软件产品之中，软件系统的结构会因此变得庞大，功能点会逐渐增多，这有助于提高软件的复用程度，提高项目实施的效率，但系统会变得更加复杂，这就需要不断提高模块的内聚程度，降低模块之间的耦合度，从而在渐进的过程中提高软件系统的产品化和通用化程度。
先实现核心功能产品化 基于现实情况的考虑，全面推行软件系统的产品化还存在一定困难，可以尝试将软件系统分为核心系统和外围系统两个层次。核心系统包括主要的业务处理程序，这一部分相对而言变化较少，外围系统包括统计报表、查询等程序，变化相对较多。所以只要将核心系统的设计质量和产品质量控制住了，也就解决了主要矛盾，在人力、物力、时间资源等条件成熟的情况下，再进一步扩展到外围系统，整个软件系统的产品化程度就得到了大幅度的提升。
采用成熟而非超前的技术 越简单的技术往往越可靠，所以在软件产品的研发过程中应主要采用成熟的技术，适当采用一些经过实践证明具有实用价值的新技术，以降低研发工作的风险，同时可以在软件产品的研发过程中不断融入已成熟的新技术，达到系统的先进性与可靠性之间的平衡。
如何理解产品升级 产品升级的概念不仅仅是指软件系统性能的全面提升，实际上每新增一个功能，发现并修正了软件系统中的一些错误，都属于产品升级的范畴，通过不断改进现有产品，实现从量变到质变，使企业的软件产品在市场上始终处于领先地位。

当发生以下三种情况时，一般需要进行相应的产品升级工作：
（1）在测试或现场运行过程中发现故障，修正了产品中存在的错误；
（2）根据用户提出的需求，新增或变更了功能；
（3）一旦发生前两种情况，为了保持发布版本的一致性，需要对所有的现场版本进行统一的更新，这将有助于改进现场系统的运行质量，并给今后的维护工作带来极大便利。不过这对质量管理、配置管理和版本控制也提出了比较高的要求。
版本更新的方式 根据客观条件和应用软件特点的不同，大致可以区分为以下三种版本更新方式：

（1）依托内部专网更新

应用软件在同一行业的多个用户单位投入应用，并且各用户单位之间已经通过DDN或DCN专网实现联接时，可以设立一个版本控制服务器，各用户单位通过专网，定期从服务器上下载最新的应用软件版本。这种更新方式的特点是，具有较高的网络传输速度，便于各相关组织之间的交互，可实现对各现场系统的实时监控，通过网络本身提供的安全机制，保证版本管理的安全性，采用这种更新方式对网络环境有较高的要求，设备投资和运行成本较高。

（2）依托互联网更新

应用软件在互不关联的多个用户单位投入应用，并且各用户单位均具备连接Internet网的条件时，可以建立一个WEB服务器，各用户单位的版本控制服务器通过互联网，定期到指定的Web站点上检测最新的应用软件版本，并进行实时的下载更新，这种更新方式的特点是方便快捷、费用低廉，但需要提供良好的安全机制和消息发布机制。

（3）采用磁盘、光盘等介质更新

在不具备专网联接或互联网上网条件的情况下，可以将需要更新的软件补丁复制/刻录到磁盘/光盘等介质上，通过邮寄的方式进行分发，由于这种更新方式的效率较低，已渐渐趋于淘汰。

效益分析

当投入应用的软件系统的用户数量较少，例如少于3～5个时，集中式开发的效益并不明显，反而要投入较多的管理成本，投入产出比不高，因此具体采用何种开发方式，可以根据实际情况酌情考虑。对于具有较大推广价值的软件系统，并发实施的项目数量较多时，集中式开发和项目管理的效益方能显现出来，具有较高的投入产出比（效益曲线如图3所示）。
 


图3 效益曲线

只有当软件系统的用户群达到了一定的数量规模之后，不同用户提出的功能需求不断被集成到软件系统之中，用户提出的个性化需求在软件系统中所占的比例会逐渐降低，从而为软件系统基本实现产品化奠定了基础。通用化程度曲线与个性化需求曲线的交汇点代表在完成了一定数量的项目实施之后，软件系统的通用化程度将得到有效提高，进入了稳定运行的阶段（如图4所示）。
 


图4 通用化程度曲线与个性化需求曲线的交汇

需要说明的一点是，推行集中式开发模型，对企业的技术、质量和项目管理水平都提出了更高的要求。较为理想的结果是软件系统经过一段时间的现场推广之后，各种类型的需求已经较为充分地反映出来，通过归类和整理，就可以将许多公共的功能封装为一个个标准化部件，从而为建立软件生产线奠定了基础。
国内软件企业在时机成熟的情况下，可以挑选某种软件产品作为试点，进行建立软件生产线的尝试，逐步脱离作坊式的软件生产模式，在市场、人才、资金等内外部环境成熟的情况下，进一步建立软件工厂，从而推动整个软件产业的发展水平达到一个新的高度。