今日基于组件的企业开发应用在许多方面不同于以往传统的商业应用，为了成功地开发企业应用，你不仅需要新的开发工具和技术,而且需要新的开发和项目管理策略。传统的自顶向下的组织结构和直线式的、亦步亦趋的开发策略只适合独立的、自包含的系统，相反，基于组件的分布系统使其更适合于小的、合作的、自我管理的开发组模式,并且是一个更趋向于环形的、具有可再生性的开发过程。本文试图通过分析企业应用系统的特点、需求及其之间的关系，最终通过建立企业应用开发组队模型来实现系统的开发。 

　　一、企业应用系统的特点 

　　象任何现代应用一样，企业应用也必须是可靠的、操作便利的，并能提供直观的、高效的用户界面等特性。除了这些基本特征以外，它还具有以下三个特点： 

    (一)复杂性 它是一个多用户、多开发者、多机器、多组件应用,能够处理大量数据和实现广泛的并行处理、网络分布式资源和复杂的逻辑管理的系统工程，它能实现跨平台操作以及与许多其他应用交互操作,它还必须具有较强生命力。

    (二)面向商业 企业应用的目标就是处理各种特殊的商业需求。它把商业政策、过程、规则以及各种实体编成代码，并且以企业的商业需求的方式被开发和扩展。

    (三)适应性 企业应用必须健壮得足以维持其持续运行，并且它必须保持对环境变化和发展的灵活性，以达到有效地控制和管理的目的。这些特性使得企业应用开发非常具有挑战性，并且需求也越来越趋于多样化。计算机硬件和软件的快速发展，加上世界经济竞争的加剧，形成了商业应用系统必须是适应快速响应并且以空前的速度履行对客户的需求这样一个环境。 随着这种需求的增加，开发者必须使更多的商业行为自动化，使他们的软件运行得更快，服务越来越多的顾客，并且处理飞速膨胀的数据。

　　二、企业应用需求的划分及其之间的关系

　　为设计企业应用你必须考虑和平衡大量的应用需求以及它们之间的关系。例如：它的商业目标；它所要求的响应速度；预算；需要多少人开发、设计和维护；它必须支持多少用户并发处理；性能和易用性；它所要求的硬件平台；它的应用地点；它的安全性要求；期望产品的使用寿命。

　　没有对这些复杂的并且可能是相互矛盾的需求有一个系统的认识，要确认从何处着手是非常困难的。一个简单的模型可能有助于减少其复杂性，并且画一张这些需求的合适的过程图对于设计和建立应用将是十分有益的。

　　（一）需求的提取 

    今天的企业应用变得越来越复杂以至于任何人都不可能完全掌握它。没有任何人一次就能把握所有的需求、观念和设计方案，第一次对需求之间的相互影响只能有一个浅层次的认识。设计规模大的分布式应用科学要求有一种简化这些复杂性的方法，最好的控制复杂度的方法就是提取，即把一些相似的需求组织到一个小的逻辑范畴内。你可以依据不同规则达到这一目的。这些被划分出来的逻辑单元通过适当组织就能很清楚地显示它们之间的影响和支持关系，而这样就能使你容易打破这一整个企业应用开发复杂问题并进入一系列小的容易管理的任务。当你理解了这些需求组之间的相互关系，你就能以一种系统的方法处理它们，平衡和调整这些需求。

    下面这个企业应用模型就是一种提取过程，这个模型是一个对各种需求的有顺序的组合，它对每一个应用的实施都是有益的，并且被分成了六个子模块。

    下面这张表列出了各项需求的定义和模块之间的传递关系：

    模块需求 开发模块开发队伍、开发过程、项目管理、源代码控制、测 试应用以及其他重要事件和最后交付使用。

    商业模块 商业目标、开发费用、投资回报、资源需求、时间 约束、安全性、维护、现有基础组织的投资、商业 规则和政策。 用户模块用户界面、易用性要求、应用所需的训练和文档、 用户端配置和网络联接。

    逻辑模块应用对象的逻辑结构、数据建模、商业对象和服 务的界面定义。

    技术模块组件开发或重复使用开发工具、开发平台系统、 数据库技术、缓存技术、通讯技术。

    物理模块系统的物理应用体系结构、分布和最终产品组件 之间的消息传递以及迭代性。 

    商业模块 用户模块逻辑模块技术模块 物理模块 六项团队任务定义在每个企业应用系统团队开发模型的 六项基本任务 团队功能与责任依据六项基本任务，描述每个团队成员的 功能和职责 衡量团队任务通过在功能小组和特性小组之间分配和安 排共同任务和独立任务显示这六项原则在 多大范围内适合工程需要 整个工程的团体描述在一个组织良好的工程设计结构中如 结构何整合团队之间以及二级小组 开发 产品管理程序管理测试与质量保证

　　（二）各种需求之间的渗透关系 

　　下面的图表显示不仅一个企业应用的需求范畴会面对，而且各种需求之间也存在这种关系。通过箭头，你能看到商业需求作为一个应用开发的起点，并且整个系统的物理结构作为最后的输出。在这两个范畴之间，用户、逻辑和技术需求被执行，每个范畴都依赖于从商业需求和它相邻子模块的输入，每一个模块的输出都直接地传递给作为最终被执行的物理模块。这一模型体现了各种需求的渗透和相互作用。 图1企业应用开发模型 

　　（三）需求分析的重要性

     对于这一模型的观察，立刻就提供给你一个成功企业应用开发的需求的完整视图。

    理解各种不同需求之间的关系，对你通过应用系统的设计和构建过程而不会遗漏每一个设计任务对整个设计的其他部分的重要地位起到关键作用。

    所有基于每个子模型的需求都是整个企业应用模型的一部分，并且决定了你应用的成败，而不管这些需求在开发过程中是否是被有意识指明。

    每个子模块都能被以有联系但更具有独立性的方式处理，这一点非常类似于软件组件，每一子模块有它自己的一组概念、需求、技术和方法、工具、存储方式、输入/输出。

    在很多事件中，每一子模块的输出将成为工程的整个功能计划书的一个最重要部分。反过来，这计划书将被用来定义工程的物理架构并且产生工程的测试计划。

    以上分析说明企业应用系统开发过程是迭代的、增量的、而非直线式的，象这样的过程让你可以在任何时间都可以基于某一需求的一小部分工作，并且可以经常间隔性地停下来评定每一模块对于其相邻模块的影响和效果。这有助于即时发现有冲突的需求，这样当需要重新实现你的应用的主要部分前，可以充分权衡和调整各种需求。

    以上对企业应用开发的组成模块、模块之间的相互关系以及各个模块所满足的需求进行了讨论，但如何真正实现它，就必须在开发人员之间进行有效的分工和协调，下面这一模型就是为达到这一目的而形成的。

　　三、企业应用系统开发团队模型 

    企业开发团队模型是基于一个工作在相互依赖和合作的规则下的一小组人。你必须分配每一个小组成员在工程中的合适位置，并且关注每一个特殊的任务。这一方法激励一种所有感，并且最终结果是一个好的产品。团队的领导必须是在管理、指导和协调方面受到敬佩，而团队成员必须全神贯注于执行他们的任务。

    下面是一个企业应用系统开发团队模型的详细细节：

    (一)六项团队任务 在小组模型中六项基本任务是：

    1.产品管理 

    2.程序管理

    3.开发

    4.测试和质量保证

    5.用户培训

    6.维护计划 

　　作为一个项目小组的领导，你可以对一个独立的或较大的工程安排每一项任务。而对于较小的工程，你可以赋予小组成员以责任而不是单个任务。 

    下面这张图表说明了在这六项工程小组任务之间的相互关系：

    (二)良好的开发环境及必要的激励机制 组队模型的关键特性是队伍小、具有丰富经验和内聚力强的小组，技术知识型的领导和自我激励的小组成员。 

    团队成员在项目工程组中承担着不同的任务，虽然每人的贡献不同，但都是最终产品形成的重要组成部分。在小的、相互依赖的团队间构建的工程组织必须具备下面几点：

    1.使每一个成员都能从系统的成功中获得利益。

    2.创造一个透明、高效、积极参与、承担责任和团队精神的文化环境。

    3.改进责任划分，并避免任何人或小组依赖于其他人或小组的成功。

    4.使开发小组保持在一个稳定的、相互协作的系统中。

    保持最高效率的方法关键是限制每个功能性小组的成员数在3～7人，如果问题复杂要求一个大的， 胜任所有任务的团队，则小组领导可以把问题分解成可控制的部分。关键的标准是降低风险和使项目能被更高效地管理。 

    组队的概念在这里是指最小单位的合作团体。在大的项目，它可能是专职于项目的一小部分功能集的开发者所组成的小组，或者是一个基于大任务的产品管理任务的一组产品管理者合作组成的产品管理小组。下图说明了这一点：

     (三)六项团队任务中小组的功能与职责 

    在小组模型中，六项团队任务的每一项都有特殊的功能和职责。无论你是在独立的小项目开发，或者是一个比较大的团队的二级小组，这六项任务都适用。 以下详细描述了每个小组成员的任务：

     1.产品管理 产品管理（或产品管理组）建立并维持工程的商业事件，并且在确认和设置目标顾客优先权方面扮演着重要角色。这包括确保商业期望被工程组清晰地表达和理解和功能特征能响应其商业优先权。 产品管理拥有项目的初步设想说明，而这设想说明是商业期望与基于工程的设想相交汇的正式文档。产品管理也代表一种高水平的项目交流（或沟通），如商业方案、方案成本和合同谈判。产品管理是目标用户与其他小组交流的高水平的重要里程碑。

     2.程序管理 程序管理员（或程序管理组）掌握应用的特征和功能说明书，并且在组织标准范围内为高效地、一致地开发和交付应用提供日常的交流和合作。 程序管理员有一个关键的交流和合作任务，因此它在组队模型图中处于中心位置。伴随着其他任务组的输入，程序管理在清晰地表达项目的设想方面对产品管理有一定的帮助。利用产品管理所产生的设想说明，程序管理员设计基于基本功能的最初版本，并且也被认为是这些功能特性的管理人。程序管理对与分析、规格说明书和设计有关的一切活动负责。程序管理也必须确保使项目与外部标准兼容，保持与外部技术的合作和交流，并且管理主要计划。

     3.开发 开发小组的任务是交付一个完全符合功能要求的、可靠的系统。任务的一个重要方面是在建立功能特性过程中保持积极的合作。开发在建立系统原型时与程序管理并行的，这样就可对技术可行性和开发设计观点提出意见。当功能特性被确定时，开发必须与程序管理就问题的重要部分如何解决达成一致，并把它们变成具体的开发计划。在组队模型中一个中心观念就是尽可能地建立一个基准，然后再对偏离基准的部分通过正式的偏差控制来管理。例如，为了尽快把功能特性作为基准的核心特征集达成一致，程序管理将与开发一起工作。结果，当开发人员继续去验证和精炼执行方法时，程序管理人员有责任去估计暗藏着的变化。

     4.测试和质量保证 测试和质量保证小组验证系统与所需功能特性的一致性，在保证零错误代码的哲理下，测试和质量保证小组必须积极参与设计过程以保证产品质量，而不是仅限于产品测试。测试的目的并不是证实程序没有错误，而是发现系统存在的各种缺陷，一个没有发现问题的测试是一个不成功的测试。测试和质量保证小组准备测试计划，写自动化的测试报告，并且管理程序执行过程中的缺陷。当然，这项任务必须独立地执行，而不是与开发并行，并且保持与开发小组的核实和平衡。

     5.用户培训（文档） 用户培训小组设计、开发并出版可打印和在线的文档，包括指导材料。 

　　作为用户的引导者，用户培训小组必须参与设计和系统及界面原型的构建，他也参与安装程序的界面、过程以及发送细节的设计。用户培训促进并参与可用性测试和产品的二次开发设计，并且与程序设计和开发紧密在一起工作，从而确保在文档中反映产品的设计和功能范围的变化。 

    6.维护计划 维护计划组管理从开发到操作的平稳过渡，确保一个流畅的首次展示、系统升级和系统支援，他与开发组一同工作，以便确保系统以一种便利的安装和管理被打包。维护人员也与操作人员协同工作，以便考虑象安装、问题解决和日常维护（包括局域网和服务器管理）、灾难挽救计划和版本控制等等问题。 

    维护计划人员必须对组织文化和基础结构相当熟悉，他们需要了解任务执行环境的性能问题，详细考虑计划的能力和操作过程。

     以上对企业应用开发模型作了详细的探讨，虽然企业应用开发的复杂度受到企业规模、组织结构、生产方式、业务范围等各种因素的影响，但其基本思路和构架确是具有普遍的通用性。对于企业应用开发的基本构架的熟悉，无论你作为开发项目领导，还是项目组成员，或者系统应用与维护人员，都将有助于你从总体上把握企业应用系统。