论文部分内容阅读
（浙江工商大学信息学院，杭州 310018）
摘 要：平台技术是为了大规模提高软件的开发效率和更好的进行开发过程控制的基础技术，它就好比传统行业中的流水线。一般说来，流水线上有三个重要组成部分：技术框架、自动化设备、手工工具。按照产品生产的物理顺序，把重型自动化设备和轻型的手工工具架设起来，就是技术框架。在流水线上，人和重型设备分工合作，那些机械的重复的，消耗体力比较大的工作交给重型设备处理，而机动灵活的、消耗体力较小的工作分给各个环节的技术工人。在生产过程中，零部件会从生产线的不同的入口进入，在机器和人的共同努力下，向同一个出口不断进行各种组合，最终形成合格的产品。本文尝试按照传统工业流程的特色设计一套适合软件设计和制造过程的技术平台。当然，技术架构和技术管理是不可分割的，在这里也对管理问题提出一些建议。
关键词：软件技术；技术框架；生产线；开发过程；技术架构
中图分类号：TP31 文献标识码：A 文章编号：1007-9599 （2013） 09-0000-03
由于软件技术的发展，技术框架和开发平台的概念已经为人所熟悉，毫无疑问，平台技术是为了大规模提高软件的开发效率和更好的进行开发过程控制的基础技术。技术平台好比传统行业中的流水线，在流水线中，体现了产品的装配和制造的逻辑，也决定了技术工人的分工方式以及对生产过程管理的基本方法。
1 传统技术背景
一般说来，流水线上有三个重要组成部分：技术框架、自动化设备、手工工具。按照产品生产的物理顺序，把重型自动化设备和轻型的手工工具架设起来，就是技术框架。在流水线上，人和重型设备分工合作，那些机械的重复的，消耗体力比较大的工作交给重型设备处理，而机动灵活的、消耗体力较小的工作分给各个环节的技术工人。在生产过程中，零部件会从生产线的不同的入口进入，在机器和人的共同努力下，向同一个出口不断进行各种组合，最终形成合格的产品。
从上述分析，我们不难看出，传统的生产线有几个特点：
1.1 生产的源动力：在流水线上，生产过程是由重型设备的生产效率驱动的。因为机械的生产效率高于人，而且机械不知疲倦，会按照一个预设的速度，不断的组织零部件，推动下一个环节的进行。这个生产过程不是由测试和缺陷检查驱动的。因为，第一、在分工合理的条件下，次品的生产率是比较低的；第二、人不如机器可靠，我们无法保证测试检测环节的工作人员不会因为某种原因消极怠工。
1.2 分工合理、职能简单：在生产过程中，无论是机器还是人，他所负责的工作都是适合它的特点的单一职责的工作，这样做有三个好处，一是可以发挥各自的优势；二是职责单一，可以保证这一工作不需要技术工人掌握太多东西，上手很快；三是可以在不断操作中不断熟悉，从而提高自己的工作效率。
1.3 流程清晰、管理透明：生产的流程是严格按照产品的装配顺序展开的，流程清晰不仅表现在技术上，也表现在实际过程中，在生产线上，无论哪一个环节出了问题，该环节的操作平台上立刻会出现大量的半成品堆积，这一现象无论是管理人员还是普通员工大家都会看得到，也正因为如此，所有的技术工人才不得不严格要求自己，避免出现积压。
1.4 缺陷检测准确、处理及时：在生产过程中，无论是机器还是人都难免出现问题，但问题出现后，下一个生产环节马上会发现，并及时反馈给上一环节，不会等到产品生产出来后再最后检测。
应该说，在传统的生产线中，人和机器的配合是很默契的，当然，这也是因为我们在传统的生产制造行业已经积累了太多的经验。但通过上述分析，我们也不难看出，生产过程的顺畅是有其客观原因的。
本文尝试按照传统工业流程的特色设计一套适合软件设计和制造过程的技术平台。当然，技术架构和技术管理是不可分割的，在这里也会对管理问题提出一些建议。
2 技术问题分析
在软件开发过程中，普遍存在着大量的技术问题和管理问题，同传统的生产线对比，不难发现问题主要包括以下几个方面：
2.1 动力不足：一个大型的软件项目接下来后，分配到每个开发人员手中，开始的时候，大家都积极的应对各种问题，彼此之间也会展开讨论，可是后来随着问题的深入，讨论开始不能进行下去，开发过程也受到影响，开发人员自己普遍失去动力，开始消极怠工。此时，作为管理人员就只能通过对测试人员增加压力，指出软件中存在的问题，通过问题列表的多少来挤压开发人员。显然，由于没有一个机械固定的运转模式，这种对测试人员采取高压的处理方式明显显得动力不足。
2.2 职责不清：在软件设计过程中，没有百分之百正确的设计方法。很多功能点无论放在什么位置都可以实现，很多缺陷也是不是说只有一种办法解决。在这样的前提下，无论是工作分配还是缺陷处理，都存在大量扯皮，互相推脱任务或者责任的现象。职责不清楚，意味着分工也不能明确，这样一来使开发人员不能精心的关注与某一份确定的工作，他随时需要学习大量的东西，随时需要处理大量的问题，他所负责的模块的功能也随时发生着改变，导致他的工作效率也无法在工作中很好的提升，这同时更意味对他工作考量也存在问题。
2.3 管理困难：软件的生产流程不是一个机械的过程，因此不会像生产线一样透明，某个人那里出现了工作或者缺陷的积压，他也完全有理由推脱给别人。严重的是这种彼此推脱也会带来其他人的懈怠，很快使整个团队缺乏有效的组织和管理。
2.4 缺陷处理不及时：由于管理过程中的问题没有得到很好的解决，因此，问题往往到了最后才会发现，这样就会大大增加测试人员的工作量，并同时增加调试的工作量，以及解决问题的时间和效率。
以上问题，不完全是由于软件开发的特点所决定的，本文试图从技术架构的角度去解决上述问题。
3 开发过程分析
首先，我们看一下软件的生产过程，在下图中，需求、设计、开发、测试是四个主要的环节，工作由左向右依次推动，当发现缺陷时，再由测试向上一环节依次提出缺陷的反馈。 以上过程，是开发的整体过程，并不是开发人员在技术架构上进行部件组装的过程，也就是说技术架构在部件组装的过程中发挥不到任何作用。真正的生产线要在设计和开发的阶段展开，也就是说，本文中所提到的生产线，应该是由设计人员给开发人员搭好的一个工作平台，如果搭建的好，则工作可以顺利高效的完成，搭建的不好，则会出现问题。现有的生产过程如下所示：
从上图中，不难看出，需求部门、设计部门、开发部门的任务和工作都是比较清晰的，但在开发阶段，所有的需求、组件、工具、模型、框架，全部都被推到开发人员的面前，他们需要在很短的时间内学会这些工具，并迅速分层组织出所需要的产品，还要接受测试的检查。这个工作，技术难度虽然不大，但是工作量非常大，而且，这样的模式根本不像生产线，而像一个一堆工人聚合在一起的手工作坊。
我们知道，生产线的任务，不是生产某个零件，而是组织人、机器、工具等生产元素来组装零件。有了生产线才有了有效的管理，目前上述架构中，正是缺乏一个负责组装的技术架构。被组装的业务模块C和D，实际上需要几十个组件和工具才能组装而成，而组装C的过程和组装D的过程，实际上有很重复的和相似的劳作。下图能够更清晰的展现开发人员的工作：
用一句话来描述现有的开发过程就是：开发过程是按照业务逻辑在技术架构上进行的技术组件的组合过程。这样就会自然产生三个方面的副作用：（1）业务开发需要等待技术开发完成后才能开展，不能同步进行；（2）技术组件和框架的缺陷会自然而然的带到业务开发过程中；（3）业务逻辑需要在全部组合完成后才能得到验证。
但我认为，业务逻辑本身是一种组合，也是一种单纯的技术，也是可以被组件化的，只不过这个组件可能复用性比较低。但把业务逻辑组件化会有三个好处：（1）业务开发可以和技术开发同步进行并且不会相互牵制；（2）业务逻辑的问题和平台组件的问题彼此不相关；（3）业务逻辑做成组件后，就可以独立于产品而进行单元测试。业务逻辑组件化后，产品组成关系如下所示：
在上图中，技术框架由粗的CDE可插入模型，变为了CDE通过AB接口可插入的模型，其中CDE不再是独立的可运行的业务模块，而是使用了AB接口的一个组件，同时，负责开发CDE的开发人员不需要保证CDE可运行，只需要保证其对AB的使用逻辑没有问题，而对CDE的调试和检测统统由技术框架负责。同时要说明的是AB接口不是原来的AB组件直接的接口，而是由业务部门和技术部门共同约定的一个组件接口，在这里技术框架看起来更像一个集成框架，因为它真正负担起了生产线的职责。而改进后的过程如下图所示：
在作出上述改进后，生产的流程清晰了很多，但是这里面还存在一个问题，就是最后的一步组装由谁来完成。显然，无论是设计还是技术部门都可以做这个工作，但如果这个工作仍然是手工作业，就仍然存在很多问题，所以这个工作的必须主要是由开发框架来完成的，至少最后的组装需要用工具来完成，而不能用手工编码来完成，一起手工编码的工作都必须分解到足够简单。因此这要求技术框架要包含下面一些组成部分。
4 技术框架组成
我们普遍认为，技术框架包括组件、工具、手册、规范四部分组成，从这四个组成部分就不难看出，我们要求开发人员参考手册的说明、使用工具生成一部分元数据和源代码，再使用组件开发出符合规范的代码。但是很明显，这四个部分中有三个部分都有严重的人为的痕迹，手册、组件、规范都是需要学习和遵守的，只有工具比较机械化一点，但又常常为开发人员带来很多限制。
为了实现把技术框架打造成生产线的理想模式，必须要求技术框架包含如下的组成部分：
4.1 技术框架需要独立于任何业务运行：从界面到服务到序列化，技术架构要遍布每个技术环节，这个要求看起来很高，但实际上也是很基本的，无论是通过工具生成的，还是手工编写的，技术框架要提供一套包含增删改查的最基本的技术环节的界面，并为技术组件和业务组件提供接口。当业务组件没有插入框架的时候，框架可以独立运行并可接受测试人员的测试。这也是为了保证业务和技术可以分离测试。独立于业务逻辑运行起来并不复杂，复杂的应该是如何让业务代码能够顺利嵌入进来，这需要对各方面做全面的设计，对于接口做充分的预留，在设计模式上做出松耦合的设计等等。
4.2 全自动装配的工具：当业务模块开发完成后，技术框架需要提供一种非编程的方式，把业务组件嵌入框架内，并使其良好的运行。我们现有的模式是由平台的工具生成代码再让开发人员在此基础上修改，或者由业务设计人员写好框架代码，由开发人员去填空。自动装配工具就是为了避免这种同一个文件多人负责的模式。我们提供全自动装配的工具就是为了避免装配过程中可能出现的装配使用错误与组件内部错误分不清的情况。
4.3 白壳测试系统：无论是技术组件提交过来还是业务组件提交过来，在真正组装起来之前，技术框架需要提供一套工具来进行白壳测试。这套工具有两个目的，一是辅助测试，二是辅助管理。我们都知道测试工作不可能完全由机器来运行，必要时候还是需要人的参与，我们提供这套工具要把所有的接口的可能的问题都列举出来，一部分由工具测试填写结果，一部分由白壳测试人员手工测试后填写。这些测试数据将部分的驱动开发工作的运行。我们现有的开发过程与其说是测试驱动的，不如说是缺陷系统来推动的，但缺陷系统目前仅限于黑客测试人员使用，没有紧扣开发过程中的环节，因此需要这套测试工具来驱动。
4.4 过程监控系统：有了上面的全自动装配工具和白壳测试系统，很显然，就可以有一套全过程的监控系统了，这是对整个开发过程实施过程管理的一套工具软件。在这个系统上，任何人都可以看到，我们一共需要开发多少组件、组件难度如何（包括接口数、代码数、依赖关系组合成的一个参数）、现在已经开发了多少、还有多少存在问题、哪些组件在等待装配、装配好的界面运行效果如何等等。这个系统不能凭空建立，如果凭空建立一个这样的系统，肯定运行不起来，因为大家可能全部忙碌于具体工作而架空了这个系统，但是如果这个系统中包含具体的工作如自动装配和白壳测试工具，那么这一系统的运行就会非常自然了。这个系统，才是整个开发过程的源动力所在。
以上四个部分中，可运行是一切的基础，只有框架随时可运行，才能充分暴露各方面的问题；全自动装配技术是支撑生产线的最基础的框架，白壳测试系统是使开发过程权责分明、及时发现问题及时改正的关键，而过程监控系统是整个框架的眼睛。它使得软件开发过程真的像工厂车间的流水线一样，可以清晰的看到每个人的工作量和每个人的问题。毫无疑问，这会大大鞭策和鼓励我们的技术人员对自己进行更进一步的严格要求。
整个过程如下图所示：
参考文献：
[1]周丽，聂汉军.虚拟化高可用性架构研究[J].计算机光盘软件与应用，2012，21：120-121.
[2]魏喆.ORACLE ERP系统架构设计与应用研究[J].计算机光盘软件与应用，2012，06：179-180
[作者简介]张玉玉（1989-），女，本科生，现就读于浙江工商大学信息学院计算机科学与技术专业，研究方向：计算机科学与技术。
摘 要：平台技术是为了大规模提高软件的开发效率和更好的进行开发过程控制的基础技术，它就好比传统行业中的流水线。一般说来，流水线上有三个重要组成部分：技术框架、自动化设备、手工工具。按照产品生产的物理顺序，把重型自动化设备和轻型的手工工具架设起来，就是技术框架。在流水线上，人和重型设备分工合作，那些机械的重复的，消耗体力比较大的工作交给重型设备处理，而机动灵活的、消耗体力较小的工作分给各个环节的技术工人。在生产过程中，零部件会从生产线的不同的入口进入，在机器和人的共同努力下，向同一个出口不断进行各种组合，最终形成合格的产品。本文尝试按照传统工业流程的特色设计一套适合软件设计和制造过程的技术平台。当然，技术架构和技术管理是不可分割的，在这里也对管理问题提出一些建议。
关键词：软件技术；技术框架；生产线；开发过程；技术架构
中图分类号：TP31 文献标识码：A 文章编号：1007-9599 （2013） 09-0000-03
由于软件技术的发展，技术框架和开发平台的概念已经为人所熟悉，毫无疑问，平台技术是为了大规模提高软件的开发效率和更好的进行开发过程控制的基础技术。技术平台好比传统行业中的流水线，在流水线中，体现了产品的装配和制造的逻辑，也决定了技术工人的分工方式以及对生产过程管理的基本方法。
1 传统技术背景
一般说来，流水线上有三个重要组成部分：技术框架、自动化设备、手工工具。按照产品生产的物理顺序，把重型自动化设备和轻型的手工工具架设起来，就是技术框架。在流水线上，人和重型设备分工合作，那些机械的重复的，消耗体力比较大的工作交给重型设备处理，而机动灵活的、消耗体力较小的工作分给各个环节的技术工人。在生产过程中，零部件会从生产线的不同的入口进入，在机器和人的共同努力下，向同一个出口不断进行各种组合，最终形成合格的产品。
从上述分析，我们不难看出，传统的生产线有几个特点：
1.1 生产的源动力：在流水线上，生产过程是由重型设备的生产效率驱动的。因为机械的生产效率高于人，而且机械不知疲倦，会按照一个预设的速度，不断的组织零部件，推动下一个环节的进行。这个生产过程不是由测试和缺陷检查驱动的。因为，第一、在分工合理的条件下，次品的生产率是比较低的；第二、人不如机器可靠，我们无法保证测试检测环节的工作人员不会因为某种原因消极怠工。
1.2 分工合理、职能简单：在生产过程中，无论是机器还是人，他所负责的工作都是适合它的特点的单一职责的工作，这样做有三个好处，一是可以发挥各自的优势；二是职责单一，可以保证这一工作不需要技术工人掌握太多东西，上手很快；三是可以在不断操作中不断熟悉，从而提高自己的工作效率。
1.3 流程清晰、管理透明：生产的流程是严格按照产品的装配顺序展开的，流程清晰不仅表现在技术上，也表现在实际过程中，在生产线上，无论哪一个环节出了问题，该环节的操作平台上立刻会出现大量的半成品堆积，这一现象无论是管理人员还是普通员工大家都会看得到，也正因为如此，所有的技术工人才不得不严格要求自己，避免出现积压。
1.4 缺陷检测准确、处理及时：在生产过程中，无论是机器还是人都难免出现问题，但问题出现后，下一个生产环节马上会发现，并及时反馈给上一环节，不会等到产品生产出来后再最后检测。
应该说，在传统的生产线中，人和机器的配合是很默契的，当然，这也是因为我们在传统的生产制造行业已经积累了太多的经验。但通过上述分析，我们也不难看出，生产过程的顺畅是有其客观原因的。
本文尝试按照传统工业流程的特色设计一套适合软件设计和制造过程的技术平台。当然，技术架构和技术管理是不可分割的，在这里也会对管理问题提出一些建议。
2 技术问题分析
在软件开发过程中，普遍存在着大量的技术问题和管理问题，同传统的生产线对比，不难发现问题主要包括以下几个方面：
2.1 动力不足：一个大型的软件项目接下来后，分配到每个开发人员手中，开始的时候，大家都积极的应对各种问题，彼此之间也会展开讨论，可是后来随着问题的深入，讨论开始不能进行下去，开发过程也受到影响，开发人员自己普遍失去动力，开始消极怠工。此时，作为管理人员就只能通过对测试人员增加压力，指出软件中存在的问题，通过问题列表的多少来挤压开发人员。显然，由于没有一个机械固定的运转模式，这种对测试人员采取高压的处理方式明显显得动力不足。
2.2 职责不清：在软件设计过程中，没有百分之百正确的设计方法。很多功能点无论放在什么位置都可以实现，很多缺陷也是不是说只有一种办法解决。在这样的前提下，无论是工作分配还是缺陷处理，都存在大量扯皮，互相推脱任务或者责任的现象。职责不清楚，意味着分工也不能明确，这样一来使开发人员不能精心的关注与某一份确定的工作，他随时需要学习大量的东西，随时需要处理大量的问题，他所负责的模块的功能也随时发生着改变，导致他的工作效率也无法在工作中很好的提升，这同时更意味对他工作考量也存在问题。
2.3 管理困难：软件的生产流程不是一个机械的过程，因此不会像生产线一样透明，某个人那里出现了工作或者缺陷的积压，他也完全有理由推脱给别人。严重的是这种彼此推脱也会带来其他人的懈怠，很快使整个团队缺乏有效的组织和管理。
2.4 缺陷处理不及时：由于管理过程中的问题没有得到很好的解决，因此，问题往往到了最后才会发现，这样就会大大增加测试人员的工作量，并同时增加调试的工作量，以及解决问题的时间和效率。
以上问题，不完全是由于软件开发的特点所决定的，本文试图从技术架构的角度去解决上述问题。
3 开发过程分析
首先，我们看一下软件的生产过程，在下图中，需求、设计、开发、测试是四个主要的环节，工作由左向右依次推动，当发现缺陷时，再由测试向上一环节依次提出缺陷的反馈。 以上过程，是开发的整体过程，并不是开发人员在技术架构上进行部件组装的过程，也就是说技术架构在部件组装的过程中发挥不到任何作用。真正的生产线要在设计和开发的阶段展开，也就是说，本文中所提到的生产线，应该是由设计人员给开发人员搭好的一个工作平台，如果搭建的好，则工作可以顺利高效的完成，搭建的不好，则会出现问题。现有的生产过程如下所示：
从上图中，不难看出，需求部门、设计部门、开发部门的任务和工作都是比较清晰的，但在开发阶段，所有的需求、组件、工具、模型、框架，全部都被推到开发人员的面前，他们需要在很短的时间内学会这些工具，并迅速分层组织出所需要的产品，还要接受测试的检查。这个工作，技术难度虽然不大，但是工作量非常大，而且，这样的模式根本不像生产线，而像一个一堆工人聚合在一起的手工作坊。
我们知道，生产线的任务，不是生产某个零件，而是组织人、机器、工具等生产元素来组装零件。有了生产线才有了有效的管理，目前上述架构中，正是缺乏一个负责组装的技术架构。被组装的业务模块C和D，实际上需要几十个组件和工具才能组装而成，而组装C的过程和组装D的过程，实际上有很重复的和相似的劳作。下图能够更清晰的展现开发人员的工作：
用一句话来描述现有的开发过程就是：开发过程是按照业务逻辑在技术架构上进行的技术组件的组合过程。这样就会自然产生三个方面的副作用：（1）业务开发需要等待技术开发完成后才能开展，不能同步进行；（2）技术组件和框架的缺陷会自然而然的带到业务开发过程中；（3）业务逻辑需要在全部组合完成后才能得到验证。
但我认为，业务逻辑本身是一种组合，也是一种单纯的技术，也是可以被组件化的，只不过这个组件可能复用性比较低。但把业务逻辑组件化会有三个好处：（1）业务开发可以和技术开发同步进行并且不会相互牵制；（2）业务逻辑的问题和平台组件的问题彼此不相关；（3）业务逻辑做成组件后，就可以独立于产品而进行单元测试。业务逻辑组件化后，产品组成关系如下所示：
在上图中，技术框架由粗的CDE可插入模型，变为了CDE通过AB接口可插入的模型，其中CDE不再是独立的可运行的业务模块，而是使用了AB接口的一个组件，同时，负责开发CDE的开发人员不需要保证CDE可运行，只需要保证其对AB的使用逻辑没有问题，而对CDE的调试和检测统统由技术框架负责。同时要说明的是AB接口不是原来的AB组件直接的接口，而是由业务部门和技术部门共同约定的一个组件接口，在这里技术框架看起来更像一个集成框架，因为它真正负担起了生产线的职责。而改进后的过程如下图所示：
在作出上述改进后，生产的流程清晰了很多，但是这里面还存在一个问题，就是最后的一步组装由谁来完成。显然，无论是设计还是技术部门都可以做这个工作，但如果这个工作仍然是手工作业，就仍然存在很多问题，所以这个工作的必须主要是由开发框架来完成的，至少最后的组装需要用工具来完成，而不能用手工编码来完成，一起手工编码的工作都必须分解到足够简单。因此这要求技术框架要包含下面一些组成部分。
4 技术框架组成
我们普遍认为，技术框架包括组件、工具、手册、规范四部分组成，从这四个组成部分就不难看出，我们要求开发人员参考手册的说明、使用工具生成一部分元数据和源代码，再使用组件开发出符合规范的代码。但是很明显，这四个部分中有三个部分都有严重的人为的痕迹，手册、组件、规范都是需要学习和遵守的，只有工具比较机械化一点，但又常常为开发人员带来很多限制。
为了实现把技术框架打造成生产线的理想模式，必须要求技术框架包含如下的组成部分：
4.1 技术框架需要独立于任何业务运行：从界面到服务到序列化，技术架构要遍布每个技术环节，这个要求看起来很高，但实际上也是很基本的，无论是通过工具生成的，还是手工编写的，技术框架要提供一套包含增删改查的最基本的技术环节的界面，并为技术组件和业务组件提供接口。当业务组件没有插入框架的时候，框架可以独立运行并可接受测试人员的测试。这也是为了保证业务和技术可以分离测试。独立于业务逻辑运行起来并不复杂，复杂的应该是如何让业务代码能够顺利嵌入进来，这需要对各方面做全面的设计，对于接口做充分的预留，在设计模式上做出松耦合的设计等等。
4.2 全自动装配的工具：当业务模块开发完成后，技术框架需要提供一种非编程的方式，把业务组件嵌入框架内，并使其良好的运行。我们现有的模式是由平台的工具生成代码再让开发人员在此基础上修改，或者由业务设计人员写好框架代码，由开发人员去填空。自动装配工具就是为了避免这种同一个文件多人负责的模式。我们提供全自动装配的工具就是为了避免装配过程中可能出现的装配使用错误与组件内部错误分不清的情况。
4.3 白壳测试系统：无论是技术组件提交过来还是业务组件提交过来，在真正组装起来之前，技术框架需要提供一套工具来进行白壳测试。这套工具有两个目的，一是辅助测试，二是辅助管理。我们都知道测试工作不可能完全由机器来运行，必要时候还是需要人的参与，我们提供这套工具要把所有的接口的可能的问题都列举出来，一部分由工具测试填写结果，一部分由白壳测试人员手工测试后填写。这些测试数据将部分的驱动开发工作的运行。我们现有的开发过程与其说是测试驱动的，不如说是缺陷系统来推动的，但缺陷系统目前仅限于黑客测试人员使用，没有紧扣开发过程中的环节，因此需要这套测试工具来驱动。
4.4 过程监控系统：有了上面的全自动装配工具和白壳测试系统，很显然，就可以有一套全过程的监控系统了，这是对整个开发过程实施过程管理的一套工具软件。在这个系统上，任何人都可以看到，我们一共需要开发多少组件、组件难度如何（包括接口数、代码数、依赖关系组合成的一个参数）、现在已经开发了多少、还有多少存在问题、哪些组件在等待装配、装配好的界面运行效果如何等等。这个系统不能凭空建立，如果凭空建立一个这样的系统，肯定运行不起来，因为大家可能全部忙碌于具体工作而架空了这个系统，但是如果这个系统中包含具体的工作如自动装配和白壳测试工具，那么这一系统的运行就会非常自然了。这个系统，才是整个开发过程的源动力所在。
以上四个部分中，可运行是一切的基础，只有框架随时可运行，才能充分暴露各方面的问题；全自动装配技术是支撑生产线的最基础的框架，白壳测试系统是使开发过程权责分明、及时发现问题及时改正的关键，而过程监控系统是整个框架的眼睛。它使得软件开发过程真的像工厂车间的流水线一样，可以清晰的看到每个人的工作量和每个人的问题。毫无疑问，这会大大鞭策和鼓励我们的技术人员对自己进行更进一步的严格要求。
整个过程如下图所示：
参考文献：
[1]周丽，聂汉军.虚拟化高可用性架构研究[J].计算机光盘软件与应用，2012，21：120-121.
[2]魏喆.ORACLE ERP系统架构设计与应用研究[J].计算机光盘软件与应用，2012，06：179-180
[作者简介]张玉玉（1989-），女，本科生，现就读于浙江工商大学信息学院计算机科学与技术专业，研究方向：计算机科学与技术。