系统分析师论文

系统分析师论文

-

1

系统分析师论文案例集

南昌大学计算中心武夷河

E_Mail:wuyihe5304@

说明：本文所有资料均由本人收集于网络，在此对原作者表示衷心的感谢！网友们可自由传播

此资料，但不得用于商业目的。

目录

企业人事信息系统的应用.............................................................................................................2

企业集团的信息管理系统应用.....................................................................................................4

通信行业的应用............................................................................................................................5

IC行业内部的CAD应用.............................................................................................................7

ERP开发的应用............................................................................................................................9

通信服务平台的应用..................................................................................................................11

论实时控制系统与企业信息系统的集成...................................................................................12

工业自动化改造的应用...............................................................................................................14

数字图书馆类的应用..................................................................................................................16

银行业的应用..............................................................................................................................18

论系统设计中对用户需求的把握...............................................................................................19

论软件开发平台的选择与应用...................................................................................................21

论基于构件的软件开发...............................................................................................................23

论软件的性能优化设计...............................................................................................................25

论企业数据安全与应用...............................................................................................................26

论建立企业内部网INTRANET的策略.....................................................................................28

如何保证软件质量......................................................................................................................30

论软件项目的进度管理...............................................................................................................32

论软件项目的进度管理...............................................................................................................34

论软件过程的改进......................................................................................................................36

应用CMM改进银行软件过程...................................................................................................38

论软件开发平台的选择与应用...................................................................................................40

论软件开发平台的选择与应用...................................................................................................42

论软件开发平台的选择与应用...................................................................................................44

论软件三层结构的设计...............................................................................................................46

论软件三层结构的设计...............................................................................................................48

论软件三层结构的设计...............................................................................................................50

XML在网上银行中的应用.........................................................................................................52

论XML技术在Internet平台上的应用.....................................................................................55

图书馆网络应用体系安全设计...................................................................................................57

论计算机网络的安全性设计.......................................................................................................59

论新技术的引进..........................................................................................................................61

论软件测试方法和工具的选用...................................................................................................63

论嵌入式实时软件测试方法和工具的选用...............................................................................65

论分布式数据库的设计与实现...................................................................................................67

论基于WEB的系统测试策略....................................................................................................68

异种数据库集成的主要技术.......................................................................................................70

历年考试论文题分类：...............................................................................................................71

2

企业人事信息系统的应用

【摘要】

本文讨论《企业人事信息系统》项目的需求分析方法与工具的选用。该系统的建设目标是

帮助该企业管理好企业内部的人员和人员的活动，人事信息管理指的是企业员工从招聘面试到

离职退休的全过程，涉及的主要活动包括面试、报到、培训、升职、离职或其他的人事变动，

也包括电子化考勤、工资性收入的计算与分发、使用其他公司资源的有关记录（如宿舍、保险、

证件办理等等）。此外，本系统也涉及到企业在全国各地的人事信息管理，企业的组织架构的设

置，级别与职务管理，人力申请直至人力需求报表，从而形成一个对企业真正有用的人事信息

管理应用系统。在本文中首先讨论了选用面向对象方法与工具的主要理由与策略，进一步通过

一个简例说明该方法与工具使用的效果，也讨论了使用多种工具与方法在需求分析中的必要性，

最后简要小结了选用正确工具与方法的意义和作用。

在项目开展期间，我担任了系统分析、系统设计与数据库管理等大量工作。

【正文】

人事信息管理系统是一个有着广泛应用面的实用性系统，但是，我国各个企业有着自身的

体制、机制、特点与不同的要求；在开发这类系统时，系统需求分析是极为重要的一环。在整

个分析过程中，我们都采用了面向对象的分析方法，这是因为我们在近几年的实践中已坚信这

种方法能够更加有效地表达和描述现实世界。软件要具有适用性和扩展性，就必须更接近于现

实世界本身的发展规律。

以一个简单的例子来看，假设要求设计关于引进人才评估的一个系统，按我们过去的做法，

先会要求提供给我们一份相关的引进人才评估表，然后依葫芦画瓢地设计相应的表单与界面。

在短期来说，这样做是简便而实用的，但并不能够符合现实世界的长远目标，这套设计方法不

具有扩展性，因为任何一份评估表的结构都会有可能发生许多改变的。采用面向对象的方法，

可以从中提取出表类型、表结构、评分方法以及能考虑继承等各方面的要素，这样就可以保证

软件的通用性，可配置性与可维护性。

在工具的选择过程中，我们选择了现在已十分流行的Rational系列，包括RationalRose、

RUP、SoDA等，为什么选取这个系列工具呢？这是基于我们对软件需求分析目标的看法，我们

认为需求分析应当能正确地回答如下的几个关键性问题：

（1）用户的需求是否已详尽地被考虑到了？

（2）用户能理解或明白我们所描述的内容吗？

（3）分析是否会和设计相脱节，

（4）程序员能明白我们的分析与设计要求吗？等等。

以下对上述几个问题逐一简要地加以说明：

（1）详尽地获取用户的需求。

用户的需求可分为显式的需求与隐性的需求，用户的倾向往往只顾及到当前的与明显的需

求。要达到对需求理解的全面性，不仅仅只是依靠有效的用户谈话和调查，因为我们所面对的

用户需求往往会有些片面的，采用RationalRose（基于UML）提供的用例，以及多种图的联合

使用，可以使我们发现其中的遗漏。

（2）使用户能充分地理解我们的表示方法，能够真正明白我们描述的内容。

软件需求分析规格说明书通常会是冗长而枯燥的，一般的用户不容易深入理解，这样就削

弱了分析的正确性。通过支持面向对象及UML语言的RationalRose可以更好地和用户交流，

让用户了解系统的运作方式甚至细节的操作。

（3）使分析和设计两个阶段互相联系与贯通。

这是我们选择面向对象的方法及RationalRose工具的重要原因，系统分析要向用户描述

3

的不仅仅是用户的需求，而且包括解决方法，解决方法当然应包括设计（程序）、数据库与系统

配置，我们当然不希望用户得到的是一个与需求规格说明不相同的软件，也不可能要求程序员

完成一个不可胜任的任务。然而我们在以前的多项工作中经常发现这类情节，因为系统分析与

设计相互脱节，导致一头扎在分析中不顾设计有关的事宜。

分析与设计的脱节，还不利于设计现格说明的评估，因为分析往往会脱离现实，导致缺乏

评估的依据。

因为不可能成功地完成设计而使分析需要重来，就会造成巨大的浪费与损失。一个好的工

具可以使分析与设计更紧密地连结起来，甚至于—一对应。面向对象的分析方法使对象之间相

对而言有独立性，减少了任何影响到全局的改动，能避免因需求变化而导致全盘皆动的被动局

面。

（4）使程序员明白我们的设计。

一个好的设计应该让程序员感到清晰明白，更少疑问。一个疑问很多的设计加上沟通不畅，

绝对会出现在应用环境下所不需要的另一个软件，所以设计规格说明书务必清楚、形象与明确，

当然，RationalRose具有足够的图形与其他形式，能使程序员更加明确，甚至能细微到每一

个语句（事实上如果使用VB，程序架构都有可能直接生成了）。

（5）选择UML可能会有更多的理由。

比如用户文档的编写、数据库设计，我们都需要做到有延续性，有自动化支持和具有质量

上的保证。

所以，我们选用了以上的方法和工具。

在分析中，面对考勤班次的问题时，由于过去一直使用纸卡方式考勤，使用户对班次形成

了固定的概念，而现在的许多考勤软件也采用多次刷卡的方法来形成一天的记录。经过面向对

象的分析可以发现，事实上每天的上班记录是由多个时段所形成的，时段的多少在各个公司，

各个工种与部门都不尽相同，每个时段可能有不同的属性，时段与时段组合可形成为班次，这

更适合于现实的情况，使之能更加灵活与更有扩展性。其实，在天与天之间也都有相互之间的

关系。在这一点上，我们又发现必须在考勤与薪金工资中加入与MRP中相似的期段（Periods）

的基本概念，比如可以称之为考勤期段，允许为用户更加方便地设置考勤期段，可能使之不一

定与自然年月日相同等等。

RationalRose使我们更方便地把上面的想法在类上去实现，更进一步地设计好我们的高

效率的数据库。

当然，使用单一的一个工具去完成一个中大型的应用系统的需求分析，是不可能成功的。

因为社会在发展，用户的需求也在改变，如何把握住用户的需求是需要时间的，面向对象的方

法有时也会忽略外在的与表层的要求，不仅仅是要获得关键的需求，其他更多的需求往往要等

到用户在使用后才知道，然而等到用户使用是不现实的，作为原型开发模型中的原型也是收集

用户需求，描述与解释需求的一类相当有效的方法与工具。

在我们的开发过程中，为了更好地让用户了解我们的系统和我们的设计方案，让用户在见

面会上更有方向性与针对性，我们首先用Access开发出原型，让用户先试用。这样，我们在真

正的分析与设计时就能更加符合用户的要求。

总之，软件需求分析方法和工具的使用，对我们软件开发过程影响是很深远的，选用高效

能的正确的方法与工具，可以使我们的软件更加正确地反映现实需求，更加具有可用性、可扩

展性和可维护性；降低了软件项目的风险。

评注：（1）写得有些特色，观点鲜明。（2）摘要写得不错，既反映了项目内容，也小结了本文

的写作要点。（3）文中所举的例子虽然简单，但很实际。（4）多种方法与工具的使用，叙述得

简明扼要。（5）内容可更丰富一些，更深入的例子也可再增多一些，则会更有说服力。（6）对

需求分析的全过程的描述太少。

4

企业集团的信息管理系统应用

【摘要】

本文以某个IT产品销售公司的信息系统项目的开发为背景，讨论了一个信息系统需求分析

的整个过程，其重要特征是：所涉及的项目是原有系统的一个升级替换版本。因此，需求分析

过程不同于建立一个全新的系统，大体上可分为三个阶段：（）实施逆向工程获得对系统的初步

了解；（2）在第1步的基础上写出基本需求，交由客户评审补充；（3）在第2步的基础上开发

原型，利用原型与客户交流，最终获得基线需求。针对上述三个阶段，本文论述了所使用的分

析方法与工具以及所遇到过的一些典型问题和措施，最后对需求分析中使用的工具，谈一些自

己的初步体会。

【正文】

我于1998年8月至2000年7月参加了某个大型集团的企业信息系统的开发工作，该大型

集团的业务主要涉及到IT类产品的进销存。本人在项目中负责系统分析的工作，该集团企业原

先已委托某个电脑公司开发过一套IT类产品管理系统，但是该老系统存在两个主要的问题：

（一）系统运行速度非常慢，如商品销售开单时，从确定开单到开单完成有时需要1～2分钟左

右的响应时间，让客户无法忍受。（二）系统数据不准确，经常出现实物库存与电脑库存严重不

相匹配的情况，使销售数据的统计产生一些混乱，有关财务的数据因此无法有效使用，只能采

用人工录入方式补充进行。在这种情况下，该集团的总经理决定参考原有系统重新开发一个系

统，以便解决原系统所存在的上述两个难以克服的难题。注；原系统采用PB6.5开发，数据库

采用SYBASE，服务器采用Windows2000Server，客户端采用Windows98，程序架构采用的是传

统的C/S结构。

鉴于该集团业务操作复杂，流程多，涉及人员多等特点，以及项目完成时间短，经费有限，

人员有限等限制约束条件，再考虑到必须避免前一系统出现过的结构混乱与难于维护等问题，

我们决定要对原系统的需求做一个比较彻底的和切实可行的分析，由于原有系统已经开发了近

两年，并且客户也有了一定的使用经验，业务基本流程本身也并没有太大的变化，因此，我们

把需求分析的过程分为三步：（）分析原有系统的结构，主要是数据库结构和程序结构，（2）在

获得第（1）步结果的基础上写出基本需求，交由客户评审补充，（3）在第（2）步的基础上开

发原型，利用此原型与客户交流，从而获得最终可用的需求结果。下面按上述三步分别加以论

述。

第一步是实施逆向工程，获取原有系统的基本需求。

由于原有系统在功能上大体上能基本满足客户的需求，并且在两年多的开发中也积累了不

少经验，因此，从中可以获得一些有益的参考，也可以避免多走弯路。在这一阶段，我们采用

的主要工具是PB自带的PowerDesigner和PBDocuments；前者主要用来分析数据库结构，后

者主要用来分析程序结构，便于开发人员与高级用户理解程序。采用这两个工具的原因是：原

系统过于庞大，模块多，数据库模式多，表格量很大，仅靠人工的方法很难从中获得一个比较

完整的、明确的系统结构以及整体构成，而且原有系统未能提供一套正确完整有效的设计文档，

于是我们只能依靠工具辅助来进行。在使用PowerDesigner分析数据库，并且用PBDocuments

分析原程序中的PBL以后，我们对原系统的结构有了一个初步的了解，再结合对原系统的使用，

基本明确了功能与流程的需求，并在此基础上用人工录入方式，产生了初步需求的自然语言文

档。这里指出，使用PowerDesigner的一个不足之处是：如果一个表中的字段过多，而且又同

时依赖多个表时，输出的表格相关图形很复杂，有很多交叉，且难于调整，不方便阅读及打印。

第二步是在第一步的基础上进行的，即写出系统基本需求，交由客户评审和补充。

通过第一步的逆向工程，我们获得了系统的基本需求。为了充分记录需求的变化及需求之

间的依赖关系，我们决定选用Rational公司的RequisitePRO作为我们的需求管理工具，

Rational公司有一整套用于需求管理的工具，功能非常强大，包括RequisitePro、ClearQuest

5

等等，这些需求分析工具可以对需求进行全面的管理，包括记录需求的变化情况，需求之间的

依赖关系等等。但是，我们考虑到Rational的一套工具全面实施会非常昂贵与复杂，需要非常

强的项目管理能力才能全面实施，因此，我们只采用了其中最简单的一部分功能，那就是记录

需求变更，记录需求之间的依赖关系，其他跟RUP有关的功能都给略去了。之所以这样做，主

要是考虑到项目的经费、人力以及国内软件开发的实际情况。正如前面所说，我们根据自己的

理解并写出基本需求后，交由客户做评审井做适当补充，我们将经过补充整理后的需求作为正

式需求记录入RequisitePro所维护的数据库中，并对各个需求进行分类，设定优先级等，这

些工作完成后，就可以从数据库中直观地了解客户到现在为止提出了哪些需求，哪些需求是必

须优先考虑的，哪些是难度较大的等等。在这个过程中，我们遇到了一些问题，譬如：用户对

我们用自然语言书写的需求文档有许多地方不理解，往往在花了较长时间阅读之后，仍不明白

我们所描写的需求过程与他们所完成的业务之间的对应关系；另外是由于首次采用Requisite

Pro进行需求管理，在类型划分，属性值的确定上，部分开发人员没有经验，造成了不少反复，

对于前者，我们的方法是想办法增加一些示意图，将大的流程分解为小流程，再与客户反复交

流与沟通，最终达到双方理解一致的目的。对第二个问题，则参考了一些例子，再结合实际中

属性的使用情况，给予取舍或者选择，经过这一阶段的工作，我们建立了基本的需求库，定出

了基本需求规格说明。

第三步则是在第二步的基础上建立起原型，利用原型与客户进行更深入的交流，通过交流修改

相应的需求。

在这一阶段的工作是在对第二步任务进行报告交流的基础上进行的。我们用PB开发了一个

原型系统，就具体的业务流程与客户进行交流与沟通，通过原型，客户发现了许多我们与他们

的理解相互不协调的地方，我们在修改需求的同时，也在RequisitePro需求数据库中记录下

修改的历史。事实证明，这种记录历史的作用是很有效的，如曾经有客户在两个不同的时间对

同一需求提了相反的需求，我们根据历史记录很快证实了该客户的提法有错误，在事实面前无

需再作争论，同时利用RequisitePro，我们还发现了一些需求相互之间有矛盾。经过这一阶

段工作，我们终于获得了经过用户认可的需求基线，即是可用于下一步进行详细设计的基线需

求。

在这个项目中，我们利用了PowerDesigner、PBDocuments等逆向工程分析工具和

RequisitePro需求管理工具，这些工具的使用，使我们提高了工作效率，起到了一定的辅助

作用。但是，就需求分析工具方面而言。我们觉得国内应用得还是太少了，这一方面是因为对

需求分析不够重视，另一方面是因为管理水平还达不到相应的层次。Rational公司的一整套需

求分析工具，其功能是非常强大的，国外已在普遍地使用，在国内也逐渐开始普及，特别是那

些通过CMM二级以上评审的单位，都必须使用工具对需求进行管理。在本项目中，我们仅仅利

用了RequisitePro功能的一些小方面，已经体会到该工具对于项目管理的诸多好处。如果一

个有实力的公司能够全面实施RUP，那么需求管理这个老大难的问题会变得不再那么棘手了，

项目的质量也会得到相应的提高。目前国内由于CMM热潮的兴起，已经逐渐重视需求分析，也

逐渐使用需求分析工具，这是非常可喜的，当然，更希望在不久的将来，能用上国产的需求分

析工具，那时我们的软件产业也许会真正地腾飞了。

评注；采用逆向工具进行再工程的应用很多，本文给出了一个实际的例子。写作有条理，也很

实际。合理地界定了需求分析的现实水平。所采用的需求分析的方法与工具相对较合理科学。

能在对项目讨论的同时抒发议论、使用体会、爱国心和事业心。深度还可以提高，例子宜更加

丰富一些。

通信行业的应用

【摘要】

本文以某通信公司的业务报表系统开发为例，讨论了软件需求分析工具与方法的选用。我

们认为，软件需求分析是软件工程中重要的一步，直接关系到后继工程的进行以及最终的产品

6

能否满足用户的需求，因此在整个工程中起着关键性的作用。采用适当的工具，有可能显著减

少需求阶段的错误，也可大幅度提高需求分析的质量和工作效率。当然工具的选用应当与实际

的项目相结合，充分地发挥工具的作用。本文结合我们工作的实际经历，简要讨论了开发系统

时所选用的工具及其应用，选用时所考虑的原则以及所碰到的问题。在文中也结合多种开发方

法（即传统的瀑布法、信息工程法、面向对象的方法）的比较，指出各种方法的不足之处，说

明我们所采用的工具对软件需求分析所起的作用，以及相应产生的效果。

【正文】

我在某市一家通信公司工作，作为一名技术骨于，受领导委托，参与了开发本公司的业务

报表系统，我担任系统的需求分析、总体设计和部分代码的编写工作。

我所在的企业作为一家通信运营公司，分为总部、省级公司和地市级分公司三级，各级公

司之间都有数据报表的要求。但是，每一个地市分公司因所处的地方不同，经营环境不同，所

面临的问题也不一样，因此形成了各具特色的数据报表（除地市分公司向省公司汇报的之外）。

公司又分设了许多部门，这些部门也都会需要数据，作为分析决策的依据。因此，了解各个部

门的需求就成了业务报表系统的关键。

在调研的过程中，我选用了一种工具叫PlayCASE，可以从网上免费下载，有很强的功能。

下面就介绍一下，在需求分析阶段，我是如何使用这一工具的。

第一步，了解业务组织结构。公司内部的数据实际上是在部门之间流动的。业务部门需要

知道在本地覆盖区内各基站的话务量、当天的话务量（即话务量的时空分布）。财务部门需要知

道本月各类用户的话费收入、预交款收入、与其他电信运营商的网间结算等。计划部门需要各

部门的分析数据。计费部门需要提供本月的账革统计数据、话单统计数据分布（比如分别按照

基站分布、时段分布以及按用户类别分布）、预交款统计数据、当前的欠费总额分布、催缴情况

等等。这些部门时常为了数据而产生了大量无谓的争议。在使用PlayCASE工具时，先要将这

些部门录入到PlayCASE的“业务部门”中．构成了一个信息源的接收点（或发送点）；而Play

CASE通过图示表示了这些部门的关系，并转换成了相应的软件结构。实际上，这是一种系统建

模的方法，即把业务系统中的各个组织转变为软件功能中的各个结构。这样，在需求分析阶段，

明确哪些部门需要数据，从而保证了需求分析对整个公司的全面性，而不会忽略掉某一个部门，

导致需求分析的不完整。

第二步，了解各个业务部门中的业务流程，使之通过PlayCASE转换成软件的运行过程，

这是一种动态建模的方法。在上一步的基础上，追踪各个部门的行为，录入到PlayCASE中，

并以形式化的语言描述各过程。对于复杂的过程，该工具还提供了进一步细化的方法，并且形

成了业务流程图和业务状态图。根据这些流程图、状态图与实际业务部门的业务相结合比较，

还是较为吻合的。在此步的实施过程中，运用了动态建模技术，使各部门业务流程的情况在软

件的运行过程反映出来，从而保证了需求分析阶段中运行过程的描述能真实地反映实际情况，

防止在后继的程序编写过程中，可能会经常发生的一类情况：程序员因为没有理解业务流程而

出现“闭门造车”的现象，从软件的功能角度上保证了软件的正确性。

第三步，将业务数据转变为软件数据，这一步工作实际上就是收集各部门所需要的数据。

分析各部门需要的数据都有哪些；以及数据是如何转换的，这可以归入“功能建模”的范畴。

将这些相应数据录入到PlayCASE中，选定所属的部门。这时就自动地建立了DFD图（数据流

程图），数据字典，省去了人工建立时的很大麻烦。

第四步，将业务上的数据关系转变成软件中的数据关系。这里采用了面向对象的方法，把

业务部门所需要的数据看作一个实体，部门间的数据关系就是实体之间的关系。比如：经营部

门所需要的用户资料、用户话费，实际上就是用户这一实体与账单这一实体间的关系。PlayCASE

提供了构件（不过我觉得是部件更为合适一些），来表示对应的数据，并提供了三种构件的表示

关系即组装关系、分类关系与相连关系。这三类关系基本上反映出了现实世界中的业务数据之

间的关系。例如现实世界中的用户资料与用户话费，在PlayCASE中，可将用户构件与账单构

件用相连关系表示。这种方法，实际上是借鉴了OOA面向对象的分析方法中的类、聚集、继承、

7

封装等概念，能较好地反映出现实中的业务；同时，这一步的工作也为总体设计中数据库的概

念模式设计奠定了很好的基础。

经历了上述四个步骤以后，利用PlayCASE工具自动生成了软件需求规格说明书、初步的

DFD图和业务流程图，为下一步的总体设计打好了基础。

使用PlayCASE工具，使需求分析既能继承传统的结构化分析方法，又能吸收面向对象设

计方法的优点。比如能把业务流程转变成为运行过程，业务组织转变成了软件的结构等都体现

了这一点。而在运行过程中，对复杂过程的细分以及追踪则反映了传统方法中的自上到下分解

的分析思想，这对于解决复杂系统的分析是很有帮助的。

通过使用，我觉得这个工具还是很不错的。因为它实际将以下四个方面的问题结合起来了：

软件、业务、开发人员和用户。对于用户而言，PlayCASE用图形化的方式显示出业务流程，

使用户了解业务在软件中的运行过程，提供了将来验收软件时的依据。对于开发人员来说，使

开发人员能更清楚地了解业务流程，不会再发生“因为不理解用户的需求而出现的闭门造车情

况，从而导致开发出来的产品不符合用户需要”的现象。因此，PlayCASE所自动提供的需求

说明书能够很好地沟通用户与开发人员之间的理解，使他们都能对需求有共同的理解。

使用PlayCASE工具后，使我们的需求分析取得了很好的效果，不但能自动地提供许多结

果，如需求说明书等；还使需求的质量有了很大的提高，受到领导的赞扬（领导不是学计算机

的，但对公司的业务十分熟悉）；在后继的设计与维护工作中，我们感到工作似乎轻松了很多。

当然，该软件工具也有不足之处，一个突出问题是灵活性不够，一县公司的部门或者组织

机构发生变化时，整个设计都要重新来过。因此，在改进的过程中，我们在第一步过程预留了

好多个虚拟的部门，以备将来进一步的扩充或者变动。

评注：（1）具体项目有些体会，完成情况似乎不错。（2）条理较清晰，比较系统地描述了使用

PlayCASE的过程和体会。（3）偏重于工具的讨论，对需求分析的方法分析还嫌不够。（4）项

目相对较小，仅涉及报表系统，对更为复杂的业务流程应举例分析，才能更充分地体现方法与

工具的作用。

IC行业内部的CAD应用

【摘要】

本文通过一个集成电路设计有关的软件项目，讨论了该项目的主要特点和本人所担任的工

作，着重讨论了在项目需求分析过程中采用的具体方法和工具以及选用的理由。

由于项目的专业领域的特殊性，分两类不同的需求讨论了需求分析中遇到的问题及解决方

法；在这个过程中给出了对选用的具体工具和方法的效果的描述。接着本文讨论了对使用方法

的改进的一些想法以及具体的实现过程。最后提出了我对需求分析的某些看法，强调了与客户

沟通的重要性。

【正文】

近年，我一直从事某企业中有关IT项目的开发，有一个系统是用于计算机辅助电路设计的，

包括了从上流设计到下流设计的所有流程，如用于可设计百万门数量级的逻辑门电路。有关方

面把电路中路径的提取、过滤以及表示的某软件开发任务交给我公司，我有幸担任了该部分的

需求分析以及设计。

我所设计部分为一单独可启动的软件，主要是解析文件中的连线路径，以列表视图和用直

方图等把它们显示出来，还可以执行诸如查找与过滤等功能。

委托方对此提供了很初步的需求说明，把一些基本功能及性能要求描述了一下。我在需求

分析时的工作主要有两点：第一，对该软件的界面等详细需求要自己重新进行分析提取。第二，

对于已提供的功能要求需要深化和细化，以形成真正完整的需求分析文档。

在接到需求分析任务后，我分析了一下所要完成的工作。发现由于是专用领域的软件，对

专业领域要求相当高，所以准备把此项目分成两部分：

8

（1）界面所受专业领域影响几乎没有，但由于全部没有任何要求，反而会感到风险和改动

可能是最大的。

（2）功能方面由于委托方的许多功能都可以调用相应模块来得到，并且已有了相应的书面

的简单需求，相应来说只是完成深化。对界面，我采用了部分RUP的思想迭代与渐进。而对功

能需求采取了分层细化，每细化一层就要求委托方确认、修改和补充。

首先把风险较大的部分完成，这是现代软件开发的基本常识。我选择先进行界面的需求分

析。第一步是根据功能描述抽取出逻辑模型，并使逻辑模型与界面元素及功能一一对应，大体

上决定了界面应有的功能，然后根据该界面功能描述，确定具体的控件，这时，我参考了委托

方已初步完成的主窗口的界面布局及控件的使用规律，然后根据需要完成的功能从Qt（由于要

支持Windows和Unix双平台，所以控件库采用Qt）的类库中选择相应的控件。在提取和抽象

逻辑模型时，我采用了Rose2000中的用例图，即以USE-CASE图来描述与外部的关系。之所

以采用Rose，我是基于以下的原因：第一，在已开发的部分中，委托方统一要求我们使用Rose

进行类和顺序图等的设计和代码生成。第二，Rose提供了标准的图来描述系统与外部的关系，

在全球范围已是一种标准结构。第三，使用上的方便性。我用Rose的USE-CASE图，理清了我

们的软件窗口与委托方主窗口以及外部角色（操作者）之间的相互关系。

在确定了界面元素后，考虑到文档的可理解性不是很强，我采用Visio2000把界面的外观

绘制出来，写上了基本的控件作用，随后送给委托方评审，幸运的是除了几个小功能的修改，

委托方基本批准了我的方案。

下面的工作是为控件的行为及状态变化制定相应的状态迁移图，我选用的工具仍是Rose，

我用了状态图和时序图，把重要的控件状态变化及相应顺序进行了描述，随后的几天把相应的

DOC文档建好写明，基本上界面设计就完成了。

下面的需求是针对功能需求的。虽然委托方技术部门有初步的需求文档，但由于领域的专

门化不对，我不清楚其中复杂的路径提取关系及较深入的专业术语，一直有一种举步维艰的感

觉。只能采用分层细化的原则，从最初的几条深入一层变成十几条。这样的话，不会一下子碰

到太深的专业问题，可以循序渐进从委托方与文献的解答中不断学习，深化自己对专业领域的

了解，这样在设计中自己始终是层层推进的，不至于一于碰到无法逾越的专业障碍。

在这一阶段的开发中，由于一直是与自己不熟悉的专业领域打交道，所以我觉得一些辅助

设计工具似乎无法发挥应有的功能。在这期间，对我帮助最大的应是公司的E-Mail系统，所有

不清楚的问题的提出，以及对问题的解答都通过它进行周转。换句话说，在需求分析阶段，它

起到了一个与客户的交流沟通和客户需求的提取作用。所以，我认为在这一阶段，E-Mail系统

是对我帮助最大的工具，其次是Excel，我用它建立了问题跟踪图表，对每一个提出的问题，

均需要记录上去，把问题结果（可分为已清楚、仍不太清楚、不清楚、尚未回答）均记录下来，

根据这些表，我可以很好地了解自己工作中的核心问题，并有了解决它的方向，提高了工作效

率。

每进行一层的细化，我都把结果交付委托方审核，由他们进行提出何时能终止细化，大约

在八层细化后，对方认为已达到了效果，确认可以结束。至此，分析工作全部完成，项目的需

求分析基本成功了。

在这次需求分析中，我认为取得成功的原因主要是方法和工具选择得正确。在界面设计中

采用了流行的辅助工具，对需求及逻辑模型的建立提供很大的帮助，可以更方便帮助自己理清

思路。选用了迭代法，把一些错误的影响在功能分析和界面分析的不断迭代过程中加以改正。

在后期，以功能需求为主时，我主要依赖的是沟通工具和表格工具，这也说明辅助工具不是万

能的，需求分析的关键之关键，应是与客户的交流与沟通。

通过这次案例，我认为在软件的需求分析工作中，方法的重要性应远超过工具的使用，应

当首先确定分析中的风险，把风险分类，用不同的方法去解决各类风险，而工具的选择不仅是

要看影响力和名气，而是要真正为我所用，应把握其精髓，即是此工具到底可以对开发有什么

帮助，而不是仅限于如何使用。我认为在需求分析中工具的作用不外乎两个：一是实际系统与

9

环境模型等的抽象工具，二是需求表达工具。第一类的代表是Rose，第二类的代表是Word，WPS，

Visio等，在这次项目中由于地理上的限制还用到了沟通工具，Web浏览与E-Mail服务系统。

最后我还是总结一下，在需求分析中工具方法都只是辅助项目成功的因素，真正的决定因

素还是—一“与客户的沟通”。

评注；

（1）较实际地讨论了方法与工具。（2）两类需求的讨论有点特色，解决需求问题的方法较成功，

有说服力。（3）能发表自己的观点和意见，体会较实在。（4）本例似乎有些特殊性，还是要鼓

励对自己熟悉的业务领域做项目，否则的话，有时会事倍功半。（5）最好再列举更多的项目或

例子，使方法与工具的讨论更全面一些。

ERP开发的应用

【摘要】

根据某类企业的迫切需要，我所在的信息技术公司组织了一个企业资源计划（ERP）项目的

开发，希望推进我国ERP应用的发展，也希望更深入有效地运用Java技术。该项目的内容涉及

到某类行业的企业生产经营的全过程，其基本目标是为了提高企业的劳动生产率，增加企业的

利润，优化配置企业的资源，使企业的整体运营水平能上一个台阶。这是一个基于Java技术的

Intranet典型应用项目。

在该项目中，我承担项目负责人的重要职责，比如在项目的准备阶段，我曾组织了对项目

组的成员进行该类企业业务流程方面的培训；在项目需求分析和设计阶段，我着重考虑了架构

好系统的框架和原型，为项目组及其他分析员进行下一步的细化分析奠定了坚实的基础。同时

我还组织好项目总体组，把握住各模块之间的接日分析，保持各个分析员之间实现密切的沟通。

在系统的开发阶段，做好开发、测试方面的协调和同步工作，保证系统的可靠性，在系统的实

施阶段能够顺利地推进项目，此项目开发后的应用已得到了用户们的一致好评。

【正文】

与国际上ERP项目的广泛应用相比，我国的ERP应用水平尚有相当大的差距。根据某类企

业的实际迫切需求，我公司组织了对一类ERP产品的开发，我有幸参与了该项目的分析与设计，

开发的成果是一个典型的Java技术应用于Intranet的实际项目。

在选择具体的技术方案时，我们曾经进行了认真的思考和研究。对于选择普遍采用的微软

模式的平台方案，还是跨平台式的Java方案，我们曾举棋未定，这是因为微软的VB＋ASP已成

为大家在较长时间工作后认可而熟悉了的方案。而Java由于其环境要求高与执行效率低的老大

难问题，成为我们担心害怕的重要因素。但是Java的跨平台特性越来越成为人们的关注点，尤

其是许多大中型的企业，他们现有的网络系统都是基于多种平台的，对跨平台的要求和呼声极

为强烈，而对软件公司来说，软件的跨平台特性有可能会节约开发成本，降低维护量，也能获

得更多客户的认可。综合考虑了诸多市场行情与行业发展因素，最终决定一定要用Java。所幸

的是现在Java用于因特网的开发也已经越来越便利了。

目前Java在因特网上的开发技术已呈白花齐放之势态，有最初的JavaServlet，有与数

据库联系在一起的SQL-J，还有可与ASP和PHP相媲美的JSP。尤其是JSP技术的迅速发展，使

得Java的网络应用不再是少数人的专利，JSP以其执行的高效性和使用的方便性，已成为近年

来大家首选的因特网开发技术，JSP是一种页面开发技术，它以Java为其服务器端语言，结合

JavaScript作为其客户端语言，能方便地实现页面的表示。

选择好了后端的Java和前端的JSP，还有一项重要的任务，那就是前后的联接。由于JSP

主要用于页面表现，需要表现的内容要封装起来，这样，为了保证主要商务逻辑的安全性，我

们采用了JavaBean作为桥梁，即客户端JSP通过其中JavaBean的使用，完成主要的商务逻

10

辑功能。在后台，将Bean构造好，形成一个强大的Bean库，再由前台JSP进行使用。

在进行JavaBean的规划时，我们下决心作出很大的投入，因为这些不仅是我们当前项目

中所需急用的，而且还应成为公司长期积累使用的一个强大的资源库，能实现一定程度的资源

共享和软件复用，为其他项目开发打好基础。因此，此次规划的目标是形成公司Java技术的

JavaBean的平台库。

我们根据JavaBean所体现的类的用途，将这些类分成几个层次。最底部的一层就是参数

化类的构造，这一层的类所实现的主要功能包括通用访问机制，对数据库等其他层次的访问接

口和公共处理系统等。中间一层是实体类的构造，这些实体类包括与数据信息相关的结构及其

处理方法，其中的重点是包含了一些重要的商务逻辑的处理。这一层类与系统各部分相关，并

且其安全性要求很高，直接影响到系统主要功能的体现，因为系统的主体是对一些逻辑进行处

理，这就要求这层实体类的规划需要十分认真，做到细节准确。最上面的一层可以称为接口类，

这一层类主要用于实现底层的类与前台之间的关系。也只有这层类才能由前台JSP进行Java

Bean调用而加以使用，只有这层具有开放性，这一层类除了上述的接口功能外，还应当有一项

重要的实用内容，即包括用于实现前台JSP的页面自动构造程序。

这里所说的页面自动构造程序可以认为是本系统的一个重要特点，目的是为了让用户可以

方便地自定义界面，而不需要由程序员修改程序，这样能够极大地满足了用户的要求。页面自

动构成程序的主要内容包括对界面元素的定制与修改、位置的修改、动作的触发、行为的控制

以及报表设计和计算汇总等功能。页面自动构成程序的设计主要采用上述的接口类与JSP相结

合的方式，用类实现元素的定制、控制及关联，并将重要信息加以保存，以利于用户的多次反

复修改。该自动构造程序提供了强大功能，已成为我们的一个独立产品。能应用于各个项目的

界面制作，实现了我们原先制定的共享资源的目标。

在前台JSP的应用中，做到了尽可能最简化的程度，这样可以提高系统的安全性。当然在

我们的系统中，还存在一些客户端控制比较复杂的情况，为保护这段比较复杂的控制脚本，我

们采取了用Servlet的方法，保护这段脚本，从而保证了一定程度的安全性。

在系统的登录过程中，我们采取了相当严格的登录键检查操作，用户没有供应商提供的相

应的键，就无法通过验证而进入系统。对于试用版的用户则提供了一种有效期限约束。这些加

密或安全措施，通过在JavaBean中封装了严格而有强大功能的加密算法，在客户端申请验证

后才能准予通过。

在使用这套技术方案的过程中，我们曾经遇到过许多的困难。比如；前面曾提到过要求JSP

中代码能够尽量简化，以提高安全性。由于JSP中仍有一些容易让人可能猜测到处理方法的语

句及处理的过程，为进一步提高安全性，我们通过查阅大量的网上资料，才形成了一套较好的

措施，比如制作JSP的标记库，将有可能被猜测的处理进一步加以规划，对应地生成一套行之

有效的实用标记库，这样就又增加了一道很有效的防护墙，大幅度地提高了安全保密性，并且

使页面结构的分离达到了一定的水准。又如：在对数据的处理上，刚开始时也总是遇到系统运

行会变得越来越慢的情况，最后追查其原因，发现原来是数据的连接过多，我们及时地采用了

数据连接池等技术解决了此类问题。

该系统采用Java平台，提供了深入地使用JavaBean和JSP的方案，其效果是相当显著的，

在用户真实使用环境中受到了一致好评，运行也较为稳定。由于采用了统一而方便的页面自动

构造程序，用户的界面非常友善，并且可以按用户需求进行定制，满足了用户的适应性需求。

而在我们公司的内部，也开始建立了一套基于此平台的资源库，成为公司的今后开发使用的宝

贵财富。

必须指出的是，在此系统中，还存在着很多的不足，比如实体类的组装程度尚不尽如人意，

根据多种商务逻辑的一些共同点，可以进一步加以抽象封装，使这部分内容能满足多种系统对

类似逻辑的处理过程。我将会在今后的工作中进一步加强各方面的分析能力，带领团队不断地

超越现在的层次与水准，加强我们的队伍建设，希望有更多优秀的软件产品上写着MadeIn

China。

11

通信服务平台的应用

【正文】

数据通讯是当前十分活跃与热门的计算机与信息技术的应用领域。某大型通信公司开发了

其业务的主要支撑平台，在这里，我们简称之为“通信信息服务平台”，用于在全国与全球开展

数据业务的需要。该平台是一个典型的Java技术应用于Internet的项目。

作为信息技术公司中的一名技术骨干，我有幸参加了该系统的分析与设计工作，承担了相

当多的Java应用开发任务。此系统中的软件部分大多由Java来实现，在全系统中我们是这样

来用Java构架系统的：

（1）本系统可分为4层，分别是Browser、表示层、中间件层和数据层。

（2）表示层用Java中的JavaScript来实现页面输出。

（3）中间件层用Java来实现CORBA，即实现Component（构件），主要实现业务逻辑的封装与

复用。

（4）数据层主要是数据库和存储过程的实现。

我们在应用Java技术时，所采用的技术和策略可大致上归纳为以下5个方面：

（1）使JavaScript尽量简单，因为JavaScript在我们系统中是放在服务器端执行的，

该语言是通过一个解释器解释执行的，相对速度很慢，我们采用了两台HP前置机来运行Java

Script，但是其运行速度还是不理想，所以我们在设计中把JavaScript仅用来显示从中间件

层所得到的数据，生成动态页面。在最初的设计中表示层（JavaScript）曾承担了一些业务逻

辑处理操作，导致效率不理想，因此，我们不得不尽量地减少JavaScript的程序量。

（2）用Java实现CORBA时，应尽量考虑共享和复用。在本系统中，最初的设计是让Java

在实现Component时，只是执行一些数据库表的操作，导致表示层的负载较大。后来，我们重

新设计时，总结归纳了所有的UseCase，找出了其中可供共享和复用的接口，把相同的业务逻

辑操作封装到一个接口中去。因为Java的执行效率比JavaScript要高，因此提高了系统效

率。

（3）在别的项目中，我们曾大量地使用过Java中的JSP技术和Servlet技术，一般人可

能不能区分这两种Java技术的区别。为了得到系统的一些执行速率的数据，我们采用了一个著

名的压力测试软件——LoadRunner来测试这两种技术的差别。测试表明：用JSP和Servlet

完成同样的一个操作，并且保证是在相同的测试环境中（相同服务器、压力测试工作站与数据

库环境），得到的测试数据却有着很大差别，JSP完成一个操作的平均执行时间大致会是Servlet

程序的两倍。在一个企业级应用项目中，这可能是一个很关键的瓶颈。因此，我们得出的结论

是：在可能的条件下，尽量地多使用Servlet。当然，与Servlet相比，JSP编程快速，修改方

便，在访问量不是很大的应用场合下也是可以接受的。

（4）使用Java作为整体解决方案时，应尽量使用相同版本的JDK。在用Java作为编程语

言的项目中，几乎大多要遇到“汉字”问题，即Java在没有经过转换的情况下，在输出汉字时，

很可能会出现乱码。采用不同版本的JDK，解决的方案是不一样的，比如V1.2.2版本的JDK和

V1.3版本的JDK解决方法就会有一些不一样，把V1.2.2的Java程序放在V1.3的JDK中，就

不能顺利输出汉字了。其根本原因在于Java使用了Unicode编码，和我们中国的国标编码不一

样。所以在这个意义上一些人竭力鼓吹的“一次编写，到处运行”似乎不一定能在所有的场合

都行得通。

（5）使用Java时，应尽量遵从软件规范。在Java中有一个JVM的概念，即在Java虚拟

机中使用了一个垃圾收集器，专门用来回收内存。但是该垃圾收集器在给编程人员带来方便的

同时，也隐埋下了隐患。在程序设计中，并不能强制执行垃圾收集器，所以，开发人员不能确

12

定某对象是否已释放，常常让编程人员养成依赖自动收集的坏习惯，因此我们要求：在Try，

Catch之后必须明确要求回收内存（当然，也只能是通知垃圾收集器来回收垃圾），这样可以有

效地提高系统稳定性。

以上这些实用性的技术与策略，是我们在实践中的一些实际体会，仅供各位开发人员根据

实际情况参考。

当然，在使用Java作为解决方案时，也会遇到很多让我们头疼的问题，这些问题导致同时

执行的并发性比较差，系统速度慢等等。归纳起来看，我们曾遇到过的主要具体的问题有：

（1）用Java来实现CORBA中的Component，有时效率会比较低。

（2）用Java来建立数据库连接往往会比较慢。

（3）用JSP编程时容易导致系统信息的扩散。比如，如果有黑客攻击一台运行JSP程序的

服务器，他可以故意地输入一些非法字符或异常信息给JSP程序，于是程序执行将出现异常。

这时，就会在页面上打印出相应的错误信息。很不幸的是，这些信息极有可能暴露出这台服务

器的JDK的版本号与路径信息等内容。这往往容易让黑客们有机可乘，有可能去抓住系统的漏

洞。

在发现了这些问题后，我们经过仔细研究，找出了一些解决办法。比如：

（1）既然用Java实现Component比较慢，我们就尽量减少Component所执行的业务逻辑

量。争取把能够放在存储过程中实现的操作，尽可能在存储过程中加以实现。众所周知，数据

库的存储过程操作，比起在Java程序中执行数据库操作要快得多。

（2）既然用Java建立数据库连接比较慢，我们就可以把数据库连接封装成连接池（Connect

Pool），从而能非常有效地提高系统效率。我们也曾经用“LoadRunner”作过压力测试，使用

连接池比不使用连接池的速度要快上3～5倍。

（3）为了对付JSP程序与Servlet程序会打印出异常系统信息的问题。我们曾查阅了很多

JSP或Servlet的资料，最终是毫无头绪。但是我们可以换另一种思路，即是不从程序下手，

而从WebServer着手，我们可以把Apache配置成为使这类异常信息不再打印出来，而是使之

仅出现一个通用的异常说明的页面，这样，就能十分有效地解决这个问题。

在我们使用Java作为编程语言的这么多项目中，绝大多数是比较成功的。Java语言作为

一种快捷、稳定的计算机语言，开发基于因特网应用的项目大多是相当稳定和比较适用的。

在我个人看来，Java的应用前景十分光明，大体上可以着眼于以下方面：

（1）在因特网上将会有更加广泛的应用。

（2）在嵌入式设备中，Java也大有用武之地。比如，在最新推出的Java技术中，Java已

经进入了手机领域。

（3）Java程序大多以线程运行，占用资源少，会逐步代替ASP与CGI程序。根据第三方

测试表明：JSP程序比ASP程序要快2倍以上。用JSP代替ASP应是大势所趋。

（4）Java在无线互联网中的应用将会更加广泛。Java支持WAP，可以方便地用Java开发

WAP程序，实现WAP应用。

（5）Java与XML的无缝连接使Java在数据传输和异构网络通信方面有着很大的优势。

就我个人而言，我将会在相当长一段时期内致力于Java在无线互联中的应用，为我国的移

动通信事业开发出更多的优秀实用的项目。

评注；参与了一个较大的项目后有实践体会。全文都采用1、2、3、4方式，文章的风格显得单

调，不大吸引人。但是本文的优点是；（1）写得很有条理。（2）内容的选择合适。（3）所列举

的策略、注意事项与发现的问题都很现实可信。

论实时控制系统与企业信息系统的集成

【摘要】

13

本文通过“工控组态软件”项目的开发，着重讨论实时系统与信息系统的集成。近年来，

国内外的组态软件取得了很大的发展，已广泛应用于企业生产。组态软件以实时数据库作为核

心技术，综合了工控、网络、图形处理与数据库访问接口等技术，是技术含量较高的一类软件

产品，具有良好的应用前景和市场潜力，因此，有多家信息技术公司都在开发工业组态软件。

我有幸参与了该项目，在该项目中担当了分析与设计的部分任务，该软件采用Windows2000

操作系统，主要采用VC6.0进行开发。以下本文将从我所开发的组态软件的特征、软件的体系

结构设计、实时数据库设计、可扩充性与可维护性设计以及项目实施管理等几方面加以论述。

【正文】

工业控制组态软件在工业界有着相当广泛的应用，此类软件允许用户在图形界面下对控制

系统的各种采样点、过程输出点、设备、生产车间、控制回路、文件报警、生产报表、控制策

略、网络设备和生产工艺画面进行定义与组态。使用该类软件时，用户甚至可以不写一行程序

就能够构成自己的控制系统，有些功能强大的组态软件还可提供与网络、Internet、数据库访

问接口等的连接功能，使现场控制系统能相对方便地和企业的信息管理系统加以集成，某信息

技术公司决定开发新的具有一定通用性的工业组态软件，作为技术骨干，我在该项目中担当了

分析与设计的部分任务，该软件采用了Windows2000操作系统，主要采用VC6.0进行开发。

本文将从我们所开发的组态软件的基本特征、软件的体系结构设计、实时数据库设计、可

扩充性与可维护性设计以及项目实施管理等几方面加以论述。

l.我所从事开发的组态软件的基本特征

通过分析国内外的组态软件的特点和当前的技术发展情况，我认为我们着手开发的组态软

件应当突出下述三个特征：

（1）“实时与可靠”是此类软件赖以生存的应用前提，但是目前还是有很多的组态软件做

不到这一点。

（2）具备良好的网络连网能力与分布功能。

（3）有效地采用ODBC（开放的数据库连接），便于和其他信息系统集成。

这个项目在技术上，应着重于组态软件的体系结构设计与实时数据库的设计上需求分析则

应着重分析国内外同类软件的功能，通过比较与鉴别，才能产生真正优秀的软件。

2.组态软件的系统体系结构

本软件采用的是三层体系结构，设计结构时要具有开放性和良好的可扩充性。

（1）软件的底层是硬件访问控制层。这一层所采用的是前几年才推出来的OPC（OLEfor

ProcessControl）技术，采用该技术的好处是OPC是微软参与制定的标准接口技术，有众多的

硬件厂商支持，所采用的OLE技术使软件具有良好的适应性和扩展能力。

（2）中间层是实时数据库。该层是整个系统的核心，在设计上除了具有一般实时数据库具

有的特性之外，应当为应用层提供了两类接口：一是应用编程接口API（比如以DLL的方式实

现），二是ODBC接口，该接口使系统具有很好的开放性，便于系统集成。

（3）上层是应用程序层。在该层通过ODBC接口访问实时数据库，可以通过SQL语句查询

数据库的数据。

3、本项目涉及到实时数据库设计

在设计时，我们着重考虑了以下的四个方面：

（1）实时数据库的基本功能：实时数据库完成实时数据库的采集、输出、报警文件等的管

理，也进行历史数据的管理。

（2）实时性设计：由于本系统所采用的操作系统是Windows2000．它的实时性较差，因

此要求任务管理定时器必须具有良好的实时性，在系统设计时，我们采用了抢占式服务的高精

度定时器，在一定程度上保证了系统具有良好的实时性。

（3）任务调度：其目标主要是使系统在各时间段达到较理想的负荷任务的均衡性。

14

（4）ODBC接口设计：即开发相应的驱动程序，实现ODBC功能，使之完全遵守SQL约定，

这样能允许应用程序的开发手段和开发工具多样化，允许可以采用VC、VB或Delphi等作为开

发语言，也使数据库具有很好的开放性。但SQL语句不能实现数据发生时间方面的选择，影响

了实时性，因此，系统自动给每个数据库加上时戳，SQL可以通过时戳进行时间控制来选择（读

取）数据，从而满足了实时性方面的基本要求。

4.本系统的可扩充性与可维护性设计

组态软件综合了多种技术，其体系结构与数据结构都较为复杂，再加上我们又希望能适应

的实际应用场景有着复杂多变性，因此要求系统必须具有良好的可扩展性与对维护性，以满足

功能与性能上不断变化的要求。在系统的设计技术上，我们大量地采用组件技术，如OPC，

COM/DCOM与3D图形控件等，组件技术的采用使系统具有了良好的可扩展性与可维护性，降低

了系统的复杂度。而且也使我们较方便地获得第三方支持，例如，请经验丰富的图形处理专家

编写图形处理控件，就能加快软件开发的进度。

5.本项目中软件项目实施和管理

组态软件的需求在当前工业控制领域中是较成熟的，基本能满足一般用户的功能上需求，

通过比较多家组态软件，可以发现：在它们之间有80％的功能是相同的或雷同的，由于我们项

目开发的起步较晚，在自控领域里，我们处于劣势，因此我们提出了“重技术分析，轻需求分

析”的思路，即把重点放在组件设计与体系结构的实现上。

在人员的配备上则根据组态软件的技术组成特点，组织一批在自控、网络、组件、实时系

统设计和硬件上各有所长的VC高手组成一支精干高效的队伍。

在开发进度上则反复强调“质量第一，进度第二”的原则。

在我们的项目实施中，可靠性作为设计的首要原则，要求项目组成员养成良好的编程习惯，

每天必须完成认真的工作日志，每周要写工作总结，完成一段程序代码之后，即应自己先进行

从里到外的测试，只有从基础抓起，才能保证组态软件的质量。

通过本项目的开发成功，我深切地体会到要使组态软件在企业实时控制与信息系统集成中

发挥其应有的作用，必须注意以下各点：先进的体系结构；支持ODBC的实时数据库；强大的网

络功能；功能日益强大的脚本语言等。我期待着本人通过在这个领域中的辛勤耕耘，将会结出

更多更丰硕的IT成果。

评注：

本文抓住了企业实时控制与信息系统集成中的一类关键软件——组态软件项目的开发，进

行了较有条理的讨论，思路很清晰。

由于项目在一定程度上的“通用性”，未能结合具体的应用背景论述；但本文的一个缺点是

未能给出开发与应用的实际效果例子，也未能对开发中遇到的困难与问题展开深入的探讨。

工业自动化改造的应用

【摘要】

本文以一个信息化改造项目为例讨论了实时系统与信息系统的集成。我曾参加了一个中等

规模的现代化生产企业的数字化改造项目，该企业拥有4座自动化连续式工作的窑炉，以及8

座自动化间隙式工作的窑炉以及多台半自动的中大型辅助机器。该企业希望能将这些设备实现

数字化，并且重点要建立起一个中央监控室，能实现对设备的运行状态参数的监督和记录两大

任务，前者用于防止意外事故，后者可用于向该企业的决策人员和技术开发部门提供信息。

通过我们的开发组与该企业相关人员一起努力，分四个步骤共同完成了这一工作。第一步

是实现设备状态参数的数字化输出；第二步是建立中央监控室的监督和记录功能；第三步健全

监控室的控制功能及相应信号的输出；第四步则是实现生产设备自动化控制的数字信号接入功

15

能。

我在其中的主要工作有三个方面：

（1）作为公司开发组和企业间联络的桥梁；

（2）负责确定该项目中各部分之间的分工，在发生冲突或出现问题时提出相应的具体解决

办法；

（3）帮助解决与协调在工作过程中出现的各种困难。

【正文】

现代化企业发展生产与提高效率的根本途径之一是加速信息化的进程。在所从事的专业生

产领域中，我参与开发项目的这家企业可以认为已经具有相当程度的现代化的基础了，比如它

已拥有4条自动化连续式工作的窑炉、8座自动化间隙式工作的窑炉和多台半自动的中大型辅

助机器。但是这些设备的自动化控制在改造前还主要依靠模拟量控制，也不具备信息与数据的

记录、汇总与分析功能。该企业一方面出于对今后发展的需要，希望记录下这些设备在工作过

程中连续的状态参数的变化情况，有运行的日志与历史记录，以提供给其技术开发部门，作为

产品质量改进研究中的参考；进一步还可提供给企业管理部门决策分析时的参考。另一方面，

企业希望能够对设备生产状态有全面的监督和一定的紧急控制与应变的能力，能对生产设备的

操作意外和设定不当，或者发生突然的未预料到的事件，防止造成事故与损失。

我们根据该企业的要求，结合项目的资金、时间、人员等现实状况，再三考虑了该企业的

经营情况、产品的市场和前景、项目开发所面临的风险等诸多因素，经过仔细分析，得出了如

下的4条意见：

（l）由于资金的限制，切实地在相应各个环节上节约成本是相当重要的，因此要尽可能地

在原有设施与条件的基础上进行改造，而不是进行根本性的替换；

（2）此企业需要的是“实时控制系统和企业信息系统的初步集成”，而不是一个功能相当

丰富和完善的系统，该企业现阶段既不具备开发这样一个系统的能力和条件，也不具备管理维

护和应用高级集成系统的相关人员，所以，项目的目标应当切合于目前条件下企业的总体要求。

这样既有利于控制成本，也有利于减少项目风险；

（3）由于该企业的生产情况和资金、人员的限制，项目必须分阶段地进行。大体上可划分

为如下四个阶段：①实现设备状态参数的数字化输出；②建立中央监控室的监督和记录功能；

③健全中央监控的控制功能和相应信号的输出；④实现生产设备自动化控制的数字信号接入功

能；

（4）参与本项目涉及到的双方的大多数人员都不精通对方的专业领域，因此必须在加强互

相沟通的同时，确定明确的分工关系。

上述四条意见在经过双方的磋商与研究后，获得了双方全体项目参与人员的一致认同，成

为这个项目开发过程中双方必须理解与遵循的准则。

在第一阶段，我们开展了对半自动的中大型辅助机器的自动化改造。事实上，该企业早有

这类打算，并且已做了相应的技术储备，因而这一部分的工作由该企业自身的技术人员全权负

责并加以实施。项目中所涉及到的所有自动化生产设备都已具有依据状态参数模拟信号量进行

控制的能力，对于所采集到的状态参数模拟量，企业曾计划采用一类以模拟信号远程地传至中

央监控室，再进行模数转换的方案。此方案对企业来说实现比较简单，但存在着成本较高、远

传过程易受到干扰等不利因素。随着模数转换设备成本的显著下降和可靠性提高，经我们建议

和双方讨论，企业有决心在生产设备的控制设备上就地实现现场模数转换，再远传数字信号至

监控室，这一工作同样地由熟悉这项技术的企业技术人员实行。

第二阶段的工作主要由我方开发组成员负责。我们将人员大体上分为3组，第一组主要是

根据企业长期累积的资料以及公开发表的相关技术，建立起一个合理有效的模型，其中包括诸

如数据采样记录的间隔时间，不同生产阶段的数据处理时所采用的数学模型等数据处理的相关

内容；第二组负责监控记录软件的输入输出接口，用户图形界面的选定和设计等软件外围功能

16

的实现；第三组则集中力量编写一个简单实用的、针对性强和小巧的相关数据记录的专用数据

库。这一阶段是控制质量和成本的关键性阶段。出于对成本的考虑，以及根据数据的流量不很

大，对数据的实时性处理要求不是很高（通常情况下，设备的实时控制仍由原来的自动化系统

所承担）的实际情况，中央监控室采用了一套有双机备份的服务器作为数据处理用的服务器，

另一套同样有双机备份的服务器作为数据库服务器，并且没有使用价格昂贵的商用数据库，而

采用了由自己开发的一个经济实用的专用数据库。

第三阶段可以看成是第二阶段的自然延伸，在第二阶段成功的基础上，利用第二阶段模块

处理后所获得的数据，依据设备的多种临界指标，进行相应的判断，允许在紧急情况下，发出

相应的警报，并同时依据设备本身的相应紧急情况处理办法，发出控制信号加以处理实现。这

一阶段的关键有两方面内容：一个问题是要求数据转换设备拥有相对较高的可靠性与可用性，

另一个问题是要注意做好与自动化设备原有控制系统的自我保护功能的配合协调工作。

第四阶段则仍然由该企业的技术人员为主实施，在实现过程中主要是解决好第三阶段所遇

到的上述两个关键问题。对于第一个问题，使用了更好的设备和部件来实现数模转换和动态控

制；对于第二个问题，则在控制设备中设立了优先级判断，使自我保护装置的启动优先级离开

中央监控室（由于自我保护启动速度更快，但是功能较弱）而加以解决。

从总的项目实施进程上来看，一、四两个阶段相连贯，二、三两个阶段相连贯，而它们之

间则可并行地进行，从而满足了时间进度上的要求。

今后，本项目所采用的这类技术可能要走向全自动化。项目中涉及到的数据量将会更大得

多，实时性要求也会更高。我们应注意使现有成熟的商业系统与产品如何应用到其中去，使之

能尽快地满足企业的要求，节约成本，并且减少开发的风险。

评注：本项目初步实现了生产控制与信息系统的第一阶段集成，项目实现目标明确，效果

直接。摘要中写了项目的背景与作者所从事的工作，正文中条理较清晰地列举了项目实施的策

略、过程与主要技术。

数字图书馆类的应用

【摘要】

一个大中型的图书馆信息系统涉及到许多方面的技术与方案，本文着重讨论与Web服务器

性能有关的一些内容。

本人有幸作为项目负责人之一参与了某大型图书馆数字化信息系统的设计和基于Web应用

软件的开发工作。由于在数字化图书馆信息系统中流通着的大多是数字化的索引、文摘、全文、

图像或音频视频等多媒体信息，对Web服务器性能有着较高的要求。

结合实际工程的经验，本文将从硬件实现手段（缓存服务器、均衡负载设备、Web双机镜

像、CPU和网卡的提升、网络带宽扩充）和软件实现手段（三层C/S软件结构设计、应用程序

部署）等两个大方面论述如何提高Web服务器的性能，以便使用户能够更快捷、高效、安全地

使用应用系统。

【正文】

随着Intranet信息技术的发展，图书馆为了更好地发挥其图书流通、资料检索和学术交流

的职能，图书馆的数字信息化工程也势在必行。某图书馆为了尽快地步入世界先进图书馆的行

列，已经启动了一部分的数字图书馆工程。

该数字图书馆工程主要包括对外信息Web发布系统，交互式检索网、后台馆藏信息管理系

统、多媒体资料采集制作以及VOD点播系统等。本人有幸作为项目负责人之一，参与了整个数

字化信息系统的总体设计，并参与了基于Web的一些应用（如对外信息发布系统、图像/全文混

合检索系统、VOD点播系统）的开发。

某图书馆数字化信息系统从网络环境上讲，主要划分为多个网段：（一）Intranet接入部

17

分，采用2M的DDN专线；（二）公共网段（非军事区），主要包括前台发布数据库服务器、Web

服务器、E-Mail/FTP/DNS服务器、检索服务器及SAN网络区域存储设备；（三）是内部局域网，

包括内网Web服务器、后台馆藏数据库服务器、OA服务器等。（四）是VOD点播专用网，包括

音频视频点播服务器等。由于制定了严格的网络级和应用级访问权限，通过具有三层交换能力

的高性能交换机和安全授权认证系统等，有效地控制了防问权限，确保了数据的安全性和完整

性。考虑到经费和人员素质及今后的维护管理运营等方面，操作系统采用WindowsNT平台，服

务器选用DELL高端的系列，数据库采用IBM的DB2。主干网为千兆快速交换式以太网，局域网

百兆到桌面，VOD点播网十兆到桌面。

在该网络环境下应用主要分为三大部分：（一）对外Web发布系统、对外图书辅助检索系统；

（二）后台馆藏信息管理系统和图像/全文混合检索系统；（三）VOD点播系统。由于绝大部分

应用采用Browser/Server方式结构，最终用户在本地只需安装IE或者NetscapeWeb浏览器，

在后台数据库服务器的支持下通过网页方式请求和访问各类应用服务。另外，由于在图书馆信

息系统中流通的多为索引、摘要、全文或音频视频等多媒体信息，对Web服务器性能与网络带

宽等都有更高的要求。

通过不断地试验和实践，我们发现从以下几个方面可以相对有效地提升Web服务器性能；

（1）缓存服务器和均衡负载设备使用可以缓解访问瓶颈，提高网络带宽、实现均衡负载。

缓存服务器也称为cache服务器，可以存储cache静态的内容如网页、多媒体点播资源和

会议实况（已压缩的、有一定格式要求的）等。此外，目前美国cashflow缓存服务器，已经可

以存储cache数据库、ASP等动态内容。cache服务器通常放到防火墙之外，外网Web服务器之

前，因此Internet用户点击网页不再直接访问网站Web服务器，而是访问cache服务器。

由于cache服务器具有多个CPU和高速大容量I/O通道，独立的OS，因此能大大缓解

Internet访问瓶颈，而且也具有一定的抗黑客攻击的能力。

目前某图书馆采用这种方式，把大数据量的静态图片、点播资源、虚拟三维应用等都事先

置放在cache服务器中，即使现今只有2MInternet的接入带宽，以上应用的播放速度和效果

仍能让用户满意。

另外一种方式采用均衡负载设备或Web双机镜像。这种方式通过负载均衡的方法达到Web

访问性能最优。Web双机镜像是较早以前流行的方式，虽能使系统可靠性提升，但由于双机总

是在互相询问对方状态，将会影响一定的访问性能。均衡负载设备是独立于Web服务器的硬件，

它和Web服务器及网站中其他服务器接在同一交换机上，通过负载调度程序为各个服务器分配

工作量，从而，能达到充分利用资源，提高访问性能的目的。只是由于某图书馆目前对外发布

资源相对仍较少，只采用了三台Web服务器，因此目前的均衡负载设备作用还不显著。

（2）从Web服务器的配置来看Web服务器自身CPU个数及速度、网卡数量、Web服务器与

防火墙的位置关系等，都会影响到Web服务器的性能。

从Web服务器硬件本身来讲，CPU个数的增加、网卡个数的增加、I/O信道的扩展无疑可以

直接地提高Web服务器性能。此外，由于千兆口的防火墙目前较少且费用较高，如果把Web服

务器放置防火墙之后，一定会大大影响Internet访问性能。某图书馆采用IDS（入侵侦测）+Web

服务器（服务器防火墙，较低端，不会影响流量）+应用服务器+数据库服务器（防火墙，高端），

分层次的安全模式，既保证了系统的安全性，又提升了网络访问性能。

另外，某图书馆还采用了SAN网络区域存储来提高服务器访问速度。

（3）三层C/S软件结构设计和应用程序的适当部署也会提高Web服务器的性能。

将业务逻辑、通用访问接口与数据等相互分离、分别置放于Web服务器、应用服务器、数

据库服务器上，通过程序功能和逻辑的合理部署，也能大大改进Web服务器性能。

一般的原则是，Web服务器只需接受Internethttp访问请求，使Web只有最少的任务，

把实际处理交给各个应用服务器处理，然后返回结果给Browser。某图书馆采用这种方式专门

开发了搜索引擎应用服务器和混合检索应用服务器等，达到了良好的应用效果。

18

事实上，Web服务器的性能提升还存在很多手段和方法，比如CPU与存储之间关系，Web交

换机等等，有待于我们进一步的实践、分析和讨论。（本文主要参考了上海童茵等人的论文）

评注：主题鲜明，条理也较分明。但所讨论的技术应更有机地结合于项目的实例。

银行业的应用

【摘要】

因特网上应用的日益普及与深化，为Java技术的运用提供了广阔的活动舞台，也大大推进

了Browser/Server模式的企业内联网应用与网络计算。

作为某信息公司中的技术骨干，我有幸承担了某银行信贷管理与查询系统等的开发任务，

独立地完成了其中的系统设计、类设计、部分开发及测试工作。

整个系统完全按照J2EE的标准来设计。前台界面应用了JSP技术，控制部分采用了Servlet

来开发，业务逻辑应用了EJB技术来封装，应用服务器采用了支持J2EE标准的BEA公司的

Weblogic，后台的数据库选用的是Informix7.3，目的是为了与银行中其他业务系统数据库保

持一致。在硬件平台上，我们选用的是HP公司的某台中型服务器机器，操作系统是HP-UX。

该系统界面运用的是IE，它不仅兼容性较好，而且已为广大用户所熟悉。系统运行后，各

个支行都普遍反映界面友善，功能强大，开发的效果令人满意。

【正文】

在银行应用中私人的储蓄、企业的会计、国际的业务、信贷、财务管理都是十分重要的，

它们构成银行的基础业务系统。我从事开发的信贷业务更是银行利润来源的重要部分。与储蓄，

对公等以交易事务为主的业务模式有所不同的是，尽管信贷也是交易，但需要更多其他辅助信

息的支持。如客户的基本资料，在本行内业务发生状况、信用等级、是否有逾期贷款未能归还

等。各个支行的有关业务人员及分行管理人员都希望能方便及时地了解这些信息。传统的基于

终端的用户界面难以传递这么多信息给用户，所以我们决定采用基于测览器IE的用户界面，一

方面IE使用方便，不需要专门培训，另外它是与Windows操作系统捆绑在一起的，也可节省前

台费用。在开发技术上有ASP，JSP可供选择。

由于考虑到Java技术在Internet上的迅速发展，J2EE更是提出了全新的用语言来统一平

台的思路，于是我们决定采纳J2EE标准，并选用了JSP。在设计上，基本上是采用了一个交易

画面对应于一个JSP程序，充分发挥JSP动态处理页面的长处。

为了使设计有更好的可扩性、灵活性与逻辑性，能为以后扩展奠定坚实的基础，我采用了

（Modelu，View，Controller）的MVC设计模式，View全部由JSP实现，而Controller则是

设计了一个Servlet程序，它负责处理前台浏览器传送来的所有请求，并按事先定义好的路径/

程序关系，分发给相应的JSP程序去处理。由于Servlet本来就是为Java服务器端编程来设计

的，因此由它来负责服务器端的处理是相当合适的。

在开始设计时，我运用了构件技术，由EJB承担起设计模式的Modelu角色。具体的贷款开

户，放款，结息逾期贷款，归还贷款等交易都对应一个具体的EJB。为了将这些处理逻辑与相

应的数据库操作分离开，能更加便于维护，我将处理业务的EJB设计成SessionBean，而为每

个SessionBean再配备一个相对应的EntityBean，用于访问后台的数据库。贷款管理中有很

重要的一点是进行查询，我按照需求分析的结果，为每类查询都设计了相对应的Bean，其目标

是尽可能地提高查询的速度。

在对数据库的存取中，我本来的设计应用InformixJDBC所带的DriverManager，这样，

在存取数据库中的Bean中就要把Driver及Server写入，后来考虑到应尽量提高应用的平台独

立性，在参阅了J2EE中JDBC部分的说明后，改用了DataResource的处理方法，这样，即使

19

以后数据库换成Oracle或其他产品，程序也不用修改，只需要在配置时进行变动即可。

在这次信贷管理系统的开发过程中，Java的平台无关性优势，在开发人员从事开发的活动

中体现得淋漓尽致。由于经费相对紧缺，我们的开发环境是各个项目组共用一台HP机器，虽然

每个开发小组都搭建了自己的环境，但项目一多，特别是遇上结息与批量测试等场合，机器就

显得不堪重负，使开发与测试工作的效率大为下降。我们小组由于采用的是Java技术，大家可

以在自己的NT机器上搭建相同的环境。这样一来，大家平时的开发工作，包括JSP，Servlet，

EJB的程序，都可以在本地完成，只是到测试或展现阶段才需放到HP开发机器上进行。

以前我们开发的Web应用，往往只是应用了部分的Web技术，如采用ApacheWebServer、

ASP开发语言等。整个体系的集成与组合往往不够理想，这次由于我们采用的一整套符合J2EE

标准的组件，整个系统的协同性与一致性非常之好。再加上有一个支持J2EE的应用服务器——

BEAWeblogic，以往我们做得不理想的复杂配置，模块间的连结，如今都用不到再操心了，只

需在图形化的配置工具中，输入系统所需要的配置，如路径与实际应用程序的关系，组件中的

EJB引用，DataResource的属性等；全部配置完成后，Weblogic会替我们完成项目的部署，

并将这一切有关的程序都封装起来。

原来，我们开发小组的文档编制任务显得非常之繁重，因为整个系统既有交易部分，又有

管理查询部分，交易、数据与源程序都很多。为了解决这个问题，我们直接应用了Java源程序

中的Javadoc导出文档，这样不仅文档美观，而且能够保持与源程序的一致性，实乃一石二鸟

之举。

整个项目完成后，用户使用下来都觉得界面友好，操作简便。但是我心里知道．这个系统

还有很多可以加以改进的地方。

首先，基于Java系统的开发需要资金较多的投入，由于该系统受到经费的限制，只申请到

一台生产用机，这样，WebServer、ApplicationServer、DBServer只能被挤放在一起。虽

然Weblogic能实现部分负载平衡，但在将来的业务发展时，这样的分布肯定不是最理想的。好

在我们在设计时已经考虑过尽量有良好的扩展性，在以后条件许可时，只需进行在不同机器之

间的进一步部署即可，应用程序大体上无需改动。

其次，在设计上，可以采用UML的产品，如RationalRose，另一方面，RationalRose具

有自动代码生成功能，也可以大大节省开发的成本。

最后，目前的信贷管理系统相对用户数目量不多，当推广类似系统需要拥有大批用户时，

基于Java的系统的响应时间与系统分布都会有较为突出的矛盾出现。

以上这些，都是我在今后的系统设计与开发中需要加以注意的地方，也是运用Java技术应

当努力的方向

评注：讨论具体，应用较为深入，表达清晰。存在的问题属实。

论系统设计中对用户需求的把握

摘要：

在系统分析与设计的过程中如何将用户需求正确的反映到系统中去，避免开发完成的

系统却不是用户需要的软件成为系统分析人员的首要任务。本文将以我2004年在某自来水公司

实施的水务综合管理系统为例，详细讨论了在系统分析过程中如何对用户的需求进行把握所采

取的方法与措施。在需求分析中我主要做了如下工作：（1）、将与系统相关的用户进行分类以明

确用户需求的来源及优先级；（2）、采用多种方式和途径获取用户的需求；（3）、利用Rational

Rose创建的用例与用户进行沟通；（4）、在用户需求分析的过程中注意用户对系统的非功能性

需求进行提取与处理。最后对收集的需求编写成用户需求规格说明（SRS）交由用户进行确认。

通过上述措施准确的把握了用户需求并顺利完成系统的开发。同时也对需求分析过程中存在的

一些不足之处进行了简要的总结。

20

正文：

本人所在的某市级自来水公司经过多年的信息化建设，已经形成了数个应用系统如客户用

水工程系统、用水抄表计量系统、营业收费管理系统、欠费催收系统、生产调度系统及客户服

务系统等。由于原系统都是由各部门或分公司为主导建设的，因业务需求的“局部性”及当时

技术条件的限制导致系统之间很难共享信息，已经不再适应公司业务发展的需要。为此，公司

领导经过研究决定于2004年利用自身技术力量重新开发设计一套水务综合管理系统，我作为技

术部的负责人及主要技术骨干，主持并参与了系统的方案选型、系统分析、设计及部分开发工

作。

在对水务系统进行开发设计之前，我对公司原来所用的几个应用系统进行了详细的调研后，

发现原来系统因为建设过早或公司业务已经发生改变，目前都不同程度的存在不适应用户需求

的情况，在关键业务的处理过程中也存在处理步骤繁琐、处理速度很慢等系统非功能性的一些

问题。随着公司业务的发展用户也提出了许多新的需求，但因原系统不方便扩充也未能及时的

得到满足。为此，如何准确的把握用户在新的业务环境下对系统提出的功能或非功能性需求，

成为系统分析、设计工作中的头等大事，也直接影响着后期软件开发工作的进度及成果。在软

件需求工程中对于用户需求的获取与把握属于需求的开发过程，接着我将就如何在软件需求分

析中正确把握用户需求进行详细的讨论。

用户需求是对业务需求的细化，为了在用户需求分析阶段不会超出系统开发的范围，在业

务分析的基础上我们建立了系统视图（范围）以规范用户需求分析的边界。对于水务系统范围

的简要描述为：水务综合管理系统是为自来水公司日常经营管理服务的，提供对客户用水从报

装工程施工、用水计量、费用结算直至客户不再用水整个过程中业务处理的集成管理环境。并

对客户用户过程中单个或多个水表生命周期（从安装、检修、维护到报废拆表）进行全程管理，

为企业领导管理决策及相关业务人员业务工作提供支持和服务，并对客户信息查询、报障提供

及时的响应。确定系统视图后对于用户要求分析阶段的工作我们主要注意了以下几个方面的问

题。

首先，将与系统相关的用户进行分类以明确用户需求的来源及优先级。对于像我司这种涉

及企业所有业务的大型应用系统的开发来说，用户需求的调查对象多种多样涉及到不同的部门

或人员，为此为了更方便的从用户处获取有效的需求，我们将用户分成不同的类如首先将其分

为管理人员、业务人员、最终客户等，通过这种划分明确了需求的来源，在需求分析的理解出

现不一致时可以有确定用户为系统分析人员提供“决策”。用户类不一定都指人也可以是其它应

用程序接口或硬件组件，如在抄表计量业务流程的分析时，相关的业务人员要求系统能够简便

一些，在经过系统分析人员进行详细的分析后发现是老系统对抄表机传输接口的处理不当造成

的，通过对其进行记录后来在系统的设计中解决了此问题。

其次，采用多种方式和途径获取用户的需求。在需求分析的初期我要求系统分析人员要深

入到用户的工作现场中以观察用户是如何工作的，从而正确的把握用户需求的实质。如在完成

客户档案登记的业务中，原来系统只提供给数据组一个窗口进行录入操作，而通过系统分析人

员对其实际工作的观察发现客户在报装时就已经形成了部分资料，对此发现我们在新系统中的

工程报装模块出现的客户信息进行了提取，从而极大的提高了操作人员的工作效率。在需求分

析中我也注意了多种沟通方式的利用，如果对于复杂的业务处理流程则采用用户与分析人员的

小组会议进行正式的讨论，而对于最终客户的一些需求则采用电话或Email的方式与之联系。

通过以上方式的采用极大的提高了用户需求分析的速度与质量。

再次，利用RationalRose创建的用例与用户进行沟通。系统分析人员在开始阶段对用户

需求的确认主要是通过需求文档与用户进行沟通的，在实际的需求分析过程中我发现用户并不

能看懂系统分析文档，对于需求分析的准确性也就无法保证。为此我们及时采用了Rational

Rose创建的用例（UseCase）来展现用户的业务处理过程，并使用用例文档对其进行简要的描

述，这样用户就能够很好的理解系统能够帮助其完成的工作任务，一般通过两到三次的沟通就

能够确定用户的需求，极大的提高了用户需求获取的质量与效率。同时也使用了传统的一些需

21

求描述方式，如对于复杂的业务处理过程，我们就采用了判定树的方式进行描述。在用例文档

的描述中我们汲取了前面的教训，使用通俗的语言进行表达以方便与用户进行沟通，如对于前

置条件和后置条件我们就换成了前提条件及处理结果，避免了用户理解冗长而晦涩的专业用语，

有利于与用户进行沟通并可简单明了的表达用户使用系统所要完成的任务。

最后，在用户需求分析的过程中注意用户对系统的非功能性需求进行提取与处理。在系统

需求分析的过程中用户往往不会对系统的非功能性需求，如可操作性、界面的简便性及系统性

能提出明确的要求，而这也往往是系统分析人员容易忽略的一个方面。为此，在系统分析的过

程中我要求系统分析人员注意用户描述中的“简单”、“快一些”等词语的分析。如在了解处理

客户扣款银行文件时用户抱怨系统处理不方便，而且在处理时其它业务都得停下来等。分析人

员在知识这个情况时及时了解到系统在处理此业务时采用了独占的方式访问数据库，而且由于

每次需求处理的记录都上万条，所以造成了以上情况。为此用户需求中的一些隐性的非功能性

需求也得到了很好的处理，对于后期的系统设计有很好的帮助作用。

需求分析阶段的成果是用户需求规格说明（SRS），完成SRS后再用户代表进行沟通确定以

为系统的设计开发工作设定一条基线。通过综合采用如上所述的方法，在用户需求分析的过程

中系统分析人员很好的把握了用户的需求，使得需求获取的效率与质量都有明显的提高，为系

统的设计工作奠定了良好的基础。总的来说我们的需求分析工作是成功的，在系统设计开发阶

段没有出现因需求不完全而停工的情况，系统已于2004年底顺利完成并能够较好的满足用户的

要求，得到了公司领导及同事的认可。同时，在用户需求的把握上也存在一些不足之处，（1）、

系统分析人员对于RationalRose的使用不是很熟练导致需求开发的速度有所降低；（2）、在用

户需求与分析人员的理解存在冲突时过份迁就用户而使部分需求用例开发的质量不高。

论软件开发平台的选择与应用

摘要：

本文以我2004年在某自来水公司实施水务综合管理系统的经历为例，详细介绍了软件开发

平台的选择与应用，我本着软件开发平台的开放性、分布性及先进性等原则，对当前主流的J2EE

及.NET平台进行对比分析，重点考虑了以下因素：（1）、开发平台的使用要有利于保持系统的

开放性；（2）、开发平台的使用要有利于保持系统的兼容性与先进性。通过仔细的评比我们选

择.NET作为本项目的开发平台，在系统设计时构建多层应用体系结构以适应系统在布署、维护

及性能方面的要求，并注意了设计模式的使用为系统的可扩展性奠定了良好的基础，同时使用

Web服务及XML的数据交换格式为与异构系统交互提供了方便。基于互联网的企业应用要求开

发平台具开放性、分布性及平台无关性，作为一名分析人员则需要不断的学习和了解新的技术

以更新自己的知识结构。

正文：

本人所在的某市级自来水公司经过多年的信息化建设已形成数个应用系统，如客户用水工

程系统、用水抄表计量系统、营业收费管理系统、欠费催收系统、生产调度系统及客户服务系

统等。由于原来的系统都是由各部门或分公司为主导建设的，因业务需求的“局部性”及当时

技术条件的限制导致系统之间很难共享信息，已经不再适应公司业务发展的需要。为此，公司

领导经过研究决定于2004年利用自身技术力量重新开发设计一套水务综合管理系统，我作为技

术部的负责人及主要技术骨干，主持并参与了系统的方案选型、系统分析、设计及部分开发工

作。

新的水务综合管理系统涉及到客户用水工程、抄表计量、营业收费、欠费催收、用水报障、

生产调度、客户服务及网上业务授理等，除了满足以上的业务功能需求以外系统还具备如下特

点：（1）、涉及业务种类繁多，如客户用水工程、抄表计量、费用的计算与收取、票据打印与管

理、银行实时扣款及网上业务受理等；（2）、业务处理的分布式，要求系统易于布署、升级与维

护，这主要是由各部门地理位置分散所致，如各营业所、水厂分布于全市范围内不同镇区；（3）、

业务处理的多种形式，有些需要采用C/S结构完成，而另外一些则须采用B/S结构，如网上业

22

务受理、相关法规的发布等；（4）、开发成本上的限制，特别是对于开发人员已有知识经验的利

用。

工欲善其事，必先利其器。随着软件技术的发展，开发平台也朝着开放性、分布性和与平

台的无关性方向发展，相继出现了COM、CORBA等技术，但因其开发上的复杂性、布署上难于通

过防火墙等，从而限制了其继续发展与更广泛的应用。为了进一步适应Web应用及多层体系结

构软件的开发，又出现了以JavaJ2EE和微软的.NET为主的两种相互竞争的开发平台。

对于水务系统的开发到底选择哪种平台，在开发人员之间曾展开的激烈的争论。面向对象

技术使Java语言迅速发展与成熟起来，特别是J2EE具有的平台无关性，一次编译多处运行以

及EJB、JSP、JavaServlet等技术的发展，使其成为企业级应用开发的首选平台。而我司原有

系统及相关应用都架设在微软的Windows系列家族产品上，并且技术部的开发人员在其上积累

了大量的开发与实施经验，.NET平台支持多种程序语言，如C++.NET、、C#及

等，实现了语言的互操作性，而且易开发性都强过JavaJ2EE平台，使得开发人员的知识得到

延续与发展。

随着需求分析的深入及软件体系结构的日渐清晰，我决定最终选择微软的.NET作为新系统

的开发平台，开发工具则使用，其原因主要居于开发平台以下几方面的考

虑。

首先，开发平台的使用要有利于保持系统的开放性。水务系统要求在内部网络、远程网络

及Internet环境中使用，单纯使用C/S或B/S结构都无法满足要求。在设计时我们使用了混合

的C/S、B/S多层体系结构，如对于抄表计量、水费计算与收取、表务管理及管网管理子系统采

用C/S结构，而对于客户服务、网上报装、用水法规的发布等则采用B/S结构实现。.NET就是

应对如上复杂应用而出现的，对于桌面应用可使用C#或进行Winform快速开发，对Web

应用则可使用开发，两者都可以使用统一的存取引擎进行数据库操作，.NET

的使用保证了水务系统的开放性。

其次，开发平台的使用要有利于保持系统的兼容性与先进性。我司原有的应用都是基于微

软Windows家族产品，而.NET已经与Windows2003集成在一起，相应使用SQL2000作为数据

库管理系统，使得.NET开发的应用具有更好的兼容性、可用性。同时.NET对WebService进行

了很好的支持，使得在其下对Web服务的开放变得异常容易，对数据库的存取则提出了比ADO

更高级的引擎，使得系统的兼容性与先进性都有较好的保证。而且在.NET下提供了语

言的互操作性，开发人员可以选用自己熟悉的或C#进行开发，其开发效率、兼容性与

可用性得到很好的保证，这也是JavaJ2EE平台无法比拟的。

在选择了.NET作为水务综合管理系统的软件开发平台后，为保持系统的开放性、先进性我

们主要做了如下工作：

构建多层应用体系结构以适应系统在布署、维护及性能方面的要求。在设计时我将系统体

系结构主要分为三个层次：（1）、表示层完成与用户的交互及数据的展现功能，我们利用.NET

设计了抽象的表示框架，使得开发人员可以迅速的创建基于Web或SmartClient的客户端应用；

（2）、业务逻辑层负责业务规则的封装，如对于抄表计量的处理各分公司略有不同我们则只需

要在业务逻辑层进行处理，简化了系统的设计难度与维护工作量；（3）、数据层采用SQLServer

2000数据库，使系统之间的兼容性与性能都有较好的保障。

设计模式的使用为系统的可扩展性奠定了良好的基础。系统设计时以多层体系结构为基础

上我注意了对设计模式的应用，使用MVC模式隔离数据表示与控制的关系，如果通过表格窗口、

图表窗口为客户历月用水提供了丰富的展现形式又不影响后台的数据处理。在相关业务的处理

操作中则大量使用了命令（Command）模式，使得相关业务操作可以串行化提高了系统的自动化

程度。同时还综合运用了工厂方法、职责链以及单件模式，设计模式的应用使系统的结构更为

清晰也更容易扩展。

使用Web服务及XML的数据交换格式为与异构系统交互提供了方便。在系统的开发过程中

我适当的采用了Web服务及XML为系统与其它系统进行数据交换提供了方便，如对客户水费实

23

时扣款处理与银行大机（Unix）进行交互时，我们通过创建Web服务的方式为其调用提供简单

的接口，采用XML格式是由于各家银行的扣款格式并不统一，为此只需要针对不同的银行创建

一个XSL就能顺利实现不同格式的转换，大大的简化了系统设计的难度。

通过如上设计保证了系统的开放性、分布性及可扩展性，新系统于2004年底顺利上线并取

得了较好的效果，得到公司领导及同事的认可。当前，开发平台已随软件技术向Web应用、开

放性、分布性及平台无关性的方向发展，并出现了以微软的.NET及Sun的JavaJ2EE为代表的

相互竞争开发平台。技术的发展日新月异，要求系统分析人员不断的学习新的技术更新自己的

知识结构，了解和掌握相关技术的适应领域，才能在具体的项目实施中选择合适的软件开发平

台。正所谓路漫漫兮其修远兮吾将上下而求索！

论基于构件的软件开发

摘要：

本文结合我于2004年在某市级自来水公司开发的水务综合管理系统，介绍了在项目中采用

基于构件技术开发的经历与心得。在系统的开发中我结合项目的实际情况，将其分成三个阶段

来完成。（1）构件体系结构与接口的设计，为系统的完成打下的基础；（2）基于领域工程的应

用构件的开发，重点介绍了构件的提取、适应性修改及新构件的开发过程；（3）运用开发完成

的领域构件组装软件系统，这也是系统开发的最终目的。通过采用构件技术为系统的开发积累

了大量的可复用资产，为组装式的软件开发提供了现实的基础，在本文的最后一部分也对系统

中存在的不足之处进行了简要的总结。

正文：

本人所在的某市级自来水公司经过多年的信息化建设，已经形成了数个应用系统如客户报

装业扩系统、营业收费系统、抄表计量系统、人事管理系统及生产调度系统等。由于各系统都

是以部门或各分公司为主导建设的，因当时技术条件所限及业务需求的“局部性”等原因，虽

然系统从一定程序上解决了业务自动化与效率的问题，但并没有解决各部门与人员之间的协作

问题，也不能很好的共享信息，已经成为公司发展的一种桎梏。

针对以上问题，公司领导经过深入的调研分析后，决定于2004年由公司技术部自主开发一

套能够较好的解决上述问题的水务综合管理系统。我作为技术部的负责人及主要技术骨干，主

持并参与了系统的方案选型、需求分析、设计与开发过程。水务综合管理系统涉及公司从生产

到客户服务的几乎所有业务，主要包括客户用水报装工程、抄表计量、费用计算与收取、欠费

催收、用水报障、生产调度及客户服务等子系统。

水务综合管理系统不仅需要满足总公司的日常业务需求，而且还要布署到市属所有镇区的

自来水分公司。由于各分公司的日常业务流程并不一样，如同样对于客户水费的计算有的是直

接由前后两期水表行度相减得到，而有的则要加调表底用水再加公摊水量得到。其它的业务处

理也大同小异，如何在有限的资源条件及项目周期内，开发完成适合各企业的水务管理系统成

为系统设计的首要目标，做到系统的灵活性与适用性的最佳平衡。

为此，我们需要一种能够利用已经开发过的系统组件搭建新的软件系统的技术，开发其中

不存在的业务组件，而不是从头开发，以达到积累和固化开发人员知识财富的作用。在经过对

多种开发技术的分析比较后，我决定在系统的开发中引入基于构件的软件开发技术，但因技术

部相关开发人员对其不熟，同时，技术部人手也不多（总共7人，除去日常系统维护的可实际

投入开发的就4～5人）。为了增强开发人员的信心，我将系统的开发任务分成三个阶段。

首先，通过定义完善的系统体系结构为领域工程中的应用构件开发提供支持。目前支持构

件体系结构开发较成熟的模型有CORBA、COM/DCOM及J2EE三大技术体系。它们各有长处如J2EE

提供了平台无关性，一次开发多处运行等特点，使其已成为企业级应用的首选平台。而COM/DCOM

则是微软提供的在Windows下分布式组件模型，具有开发、布署容易，支持多种程序语言等优

点。另外，我司的原有业务都是基于Windows的，经过反复考虑，我们决定采用COM/DCOM体系

24

结构，使新开发的系统具有良好的兼容性与可扩展性。我们还将系统划分成各个独立的层，各

层构件独立工作又相互协调的完成系统的功能。有利于系统的维护与升级，而且可以并行的开

发这些组件，互不影响。

系统的体系结构如下图所示：

稳定的接口定义为基于构件的开发提供了保障。在基于构件的软件开发中，由于系统是依

靠预制的或独立运行的组件协同工作来完成系统的功能。各构件对信息的交换就成为必然。而

要完成此工作则必须定义一组能用的信息交换接口。在我们的系统中采用一组服务来完成，上

层或需用方通过以XML定义的服务接口向提供者请求服务，系统中的各构件也是利用XML定义

的接口发布和请求服务的。这保证了各构件间的相互协作，也为第三方的开发提供了可能。

其次，与构件基础结构对应的是创建可复用资产和可复用的领域构件。可复用构件是领域

内通用性较好的对象，在领域构件的开发过程中我们主要采取了以下步骤：

通过对以前的可复用资产进行整理为领域构件的开发打下基础。将原来开发的系统的设计

结构、数据流图、业务逻辑规则及所有的文档资料都做一次全面的梳理。将存在的源代码与文

档进行统一的标识管理，以便在进行构件开发时可以直接引用相关的数据结构或算法。在上述

工作的基础上，对原来系统中一些好的业务流程、效率高、质量好的组件分别从源代码或流程

中提取出来，并放入构件库内，详细记录其使用的环境、开发语言、接口定义等资料，为下一

步的复用做好准备。

对登记入库的“原始”组件进行适应性修改以满足构件体系结构的要求。在修改的过程中，

我们主要从系统的功能出发，在构件库查找到最接近要求的组件，然后按照接口定义进行修改。

如对于抄表计量业务构件的开发就是在原来算法的基础上，根据各分公司的计算特点，抽取各

家的共性生成一个抽象的处理构件，再对其中特殊的地方（有些存在表底数、公摊、水损等）

进行子类化或参数化处理。这样就形成了满足要求的合格组件。

对于没法通过适应性修改得到的构件，我们就根据业务需求全新开发它。在开发时注意了

构件的应用环境与不同分公司在业务上的差异性，以使开发出来的应用构件具有较高的复用价

值。如对于用户用水工程的业务流程，有的分公司的处理为：申报→安装→交费→开通用水；

而有的分公司则为：申报→勘查→工程预算→审批→交费→施工→验收→结算→开通用水。各

分公司并不统一，为此我们并不是分别开发，而是根据业务最复杂的流程开发，完成后再根据

各分公司的实际情况进行裁剪以满足各自的要求。这样既使开发工作量减到最小，在业务需求

与系统开发之间取得较好的平衡，保证了系统各阶段的工作产品按时上线运行，其它的构件如

语音查询、实时扣款构件等也如此开发完成。

最后，通过XML定义的接口将各层构件连接到一起形成满足业务要求的软件。从上图中可

见系统是通过各层构件相互配合完成任务的，在层与层或构件与构件之间是通过其接口描述文

件来进行连接的，并由系统核心的基础件将各构件最终加载到系统中。构件组装人员可以根据

业务的需要从构件库中选取合格的构件进行装配以形成可用的应用软件。一方面可以很好的满

足业务需求的变化，另一方面也为类似软件的开发积累了大量可复用的资产。

本系统于2005年初投入使用，由于采用构件技术大大缩短了开发的时间，同时也达到了系

统的设计目标，培养了开发人员的可复用意识，也使自己的软件分析与设计水平得到了提高。

另外，因系统采用的是自定义的软件构件接口，难于与第三方软件交互，这也是系统中存在的

不足之处，为此我们打算在第二阶段以WebServices来对系统进行改造，以加强系统的开放性

与可集成性。当前IT技术发展日新月异，如面向服务架构（SOA）、面向方面开发（AOP）及中

间件技术的发展都为基于构件的开发提供了新的方向，也将使得我的软件分析与设计工作进入

到更宽广的领域。

25

论软件的性能优化设计

摘要：

本文结合我2004年在某市级自来水公司实施的水务综合管理系统的经历，就软件的性能优

化设计进行了详细讨论。在系统的设计中针对企业的实际应用环境主要从以下几方面对系统性

能进行了优化设计：（1）、选择当前成熟的三层C/S体系结构进行开发，以减轻数据库服务器的

负担；（2）、优化数据存取策略以降低系统运行对网络带宽的要求；（3）、对客户端应用进行优

化，如减少数据请求量、相关的处理利用多线程进行以提高系统的响应速度。通过以上优化设

计，系统满足了企业百万级以上主题数据库处理要求，得到了企业领导与同事的认可与赞许。

最后对系统中存在的不足进行了简要的总结，如系统应用服务器端的负载平衡算法过于简单等。

正文：

本人所在的某市级自来水公司经过多年的信息化建设，已经形成了数个应用系统如客户用

水工程系统、用水抄表计量系统、营业收费管理系统、欠费催收系统、生产调度系统及客户服

务系统等。由于原来的系统都是由各部门或分公司为主导建设的，因业务需求的“局部性”导

致系统之间很难共享信息，已经不再适应公司业务发展的需要。为此，公司领导经过研究决定

于2004年利用自身技术力量重新开发设计一套水务综合管理系统，我作为技术部的负责人及主

要技术骨干，主持并参与了系统的方案选型、系统分析、设计及部分开发工作。

新的水务综合管理系统涉及到客户用水工程、抄表计量、营业收费、欠费催收、用水报障、

生产调度、客户服务及网上业务授理等业务，除了满足以上的业务功能需求以外，还要应对如

下性能方面的需求。（1）、公司的大部分业务工作都由分散全市各镇区的分公司和营业所完成，

相应要求系统适合于分布式的应用环境并提供较好的性能；（2）、对于远程客户端应用来说，必

须在较小的网络带宽占用下完成日常业务处理，如分公司都使用512KB的ADSL与总公司连接，

但一般的业务处理要求在10秒以内完成；（3）、对于大型的业务如抄表数据的上传、水费的批

量计算，报表统计与生成工作等，要求不能影响其它业务的正常进行。

根据公司的业务和管理特点及上述提出的对软件性能方面的要求。在对软件的性能优化设

计中我和系统分析人员主要做了以下几方面的工作。（1）、选择当前成熟的三层C/S体系结构进

行开发，以减轻数据库服务器的负担；（2）、优化数据存取策略以降低系统运行对网络带宽的要

求；（3）、对客户端应用进行优化，如减少数据请求量、相关的处理利用多线程进行以提高系统

的响应速度。

工欲善其事，必先利其器。在本系统的开发中我们选择了目前在数据库开发方面非常成熟

的Borland公司的Delphi开发工具、负载平衡使用的是其附带的ConnectionBroker、应用服

务器连接则采用其MIDAS（DataSnap）技术。由于整个技术方案都使用的是Borland公司的技

术，系统具有良好的兼容性与可扩展性的同时，也为系统的性能改善提供了可能。下面将就我

在系统性能优化方面所做工作进行详细介绍。

首先，在水务综合管理系统中我们根据企业业务处理分散在异地的特点，采用了三层C/S

体系结构，系统的体系结构如下图所示：

通过三层C/S体系结构的设计可以将数据库的访问及业务处理逻辑移到应用服务器进行。

由于我司应用特点，我们在应用服务器的设计中主要采取了连接池和负载均衡的技术来提高系

统性能。（1）、对于客户的连接我们首先去查找连接池中是否有可用的连接，如果没有才则建立

之，否则直接利用连接池中的连接来处理客户端的请求，这样做可以有效降低系统因建立与数

据库的连接而带来的性能影响，同时也可以较好的节约系统资源。（2）、针对系统主题数据库容

量上百万及日常业务处理繁重的情况，在应用服务器端我们利用Borland公司的VisiBroker组

件为系统提供了负载均衡的能力，如在业务处理高峰期系统将会自动通过VisiBrokerAgent将

26

客户端的请求转发给空闲的应用服务器，这样极大的提高了应用服务器的响应能力。

其次，优化的数据库存取策略降低了系统的网络数据传输量。各分公司及营业所都采用

512KB的ADSL与总公司进行连接，要求系统能够在较低的网络带宽下提供良好的性能表现。为

此，我经过与系统分析人员的讨论验证后决定将系统所有的数据库访问请求与处理操作都放在

应用服务器端进行，如客户报装、资料修改、客户查询等业务流程的处理客户端只负责将相关

的客户资料传给应用服务器，应用服务器进行处理后再将结果显示在客户端从而减轻网络带宽

的需求。另外，在系统中我们采用了大量的存储过程对业务进行处理，既简化了业务逻辑变化

带来的维护工作量，利用数据库服务器的处理能力也提高了系统的性能。

最后，在客户端主要采取GUI方式与用户进行交互，那么如何利用客户端技术提高系统的

性能呢？我们主要使用了以下技术和方法：（1）、使用多线程技术对用户输入进行处理，如用户

输入完相关资料在提交时，系统利用线程来进行处理，这样系统主线程就不会因等待处理结果

而停顿。另外，系统在查询中也大量使用了线程技术，系统首先利用线程对用户要求的资料进

行查询，待结果出来后再交给主线程将结果显示出来。（2）、将抄表数据上传、水费计算、银行

代扣及报表生成等大型业务利用作业的形式在系统闲时进行处理，一方面可以缓解业务高峰期

的性能压力，另外还可以实现作业的调度提高系统的自动化程度。（3）、在客户端我们还充分利

用了TClientDataSet组件中的Clone方法及PacketRecords特性来提高系统处理速度和降低网

络流量。如对业务数据的修改就使用了克隆数据集的方式进行处理；（4）、在显示浏览表格或用

户查询结果时并不是一下将所有的结果都从服务器提取过来，而是每次利用PacketRecords设

置的记录数如每次100条记录，如果用户继续查看则进行“翻页”操作以提高系统的响应速度。

通过综合利用以上技术，系统于2004年底投入试运行时就取得了较好的效果，满足了在系

统分析与设计时所提出的性能需求，也得到了公司领导和同事的一致认可与赞许。我也看到了

系统存在的不足之处。（1）、对于应用服务器中的负载均衡处理过于简单，在实际的应用环境中

容易造成有些应用服务器负载过度而另外一些则十分空闲的情况，对于协同处理时的事务支持

也不是很完美。（2）、在利用线程进行处理时虽然能够较好的解决系统性能问题，但也引起了另

外一方面的问题，如各线程在对用户界面进行处理时可能造成冲突。通过此次水务综合管理系

统的顺利实施为我在中、大型软件性能设计方面积累了较多的经验，为我以后的工作提供了很

好的帮助。同时，软件技术的日新月异也促使我要不断更新自己的知识结构，为应对不同体系

结构的软件分析与设计做好准备。

论企业数据安全与应用

摘要：

本文以我2004年在某自来水公司实施的水务综合管理系统为例，详细介绍了企业信

息化建设中的数据安全策略与应用，为保证企业数据安全我主要做了以下几项工作：（1）、将公

司网络划分为不同的子网并通过防火墙对内外网进行隔离；（2）、创建域控制器对用户进行集中

管理，采用Norton杀病毒软件防止病毒或木马程序的蔓延；（3）、对于数据管理系统采用系统

集成的验证方式、为不同的用户创建分组并充分利用视图、存储过程以加强数据库的安全；（4）、

应用系统对数据库的存取都采用统一的安全基础设施，在增强系统安全性的同时简化管理员的

工作；（5）、制定严密的信息安全管理制度为数据安全应用提供制度上的保证。通过如上措施有

效的保证企业运用的安全，得到了公司领导与同事的认可与赞许，同时我也认识到企业数据安

全工作是一项长期持续的过程，任重而道远。

正文：

本人所在的某市级自来水公司经过多年的信息化建设已形成数个应用系统，如客户用水工

程系统、抄表计量系统、营业收费管理系统、欠费催收系统、生产调度系统及客户服务系统等。

由于原系统都是以各部门或分公司为主导建设的，因业务需求的“局部性”及当时技术条件的

限制导致系统之间很难共享信息，同时企业业务数据特别是涉及客户费用的核心数据安全性也

成为系统的一个致命伤，已不再适应公司业务发展的需要。为此，公司领导经过研究决定于2004

27

年利用自身技术力量重新设计开发一套水务综合管理系统，我作为技术部的负责人，主持并参

与了系统的方案选型、系统分析与设计工作。

新的水务综合管理系统涉及到客户用水工程、抄表计量、营业收费、欠费催收、用水报障、

生产调度、客户服务及网上业务授理等不同的子系统，除了满足以上的业务功能需求以外系统

还具备如下特点：（1）、系统涉及企业内部不同部门如日常业务、生产管理、财务与审计等，要

求实现各部门之间应用的隔离；（2）、系统需要与外部系统如语音查询系统、银行客户增值业务

系统（实现客户水费的批量及实时扣款处理）；（3）、网上业务授理要求系统利用Web方式为客

户提供方便快捷的服务；（4）、防止非法用户通过业务系统、Web浏览器获取企业信息或对信息

进行破坏。数据安全成了系统设计的首要目标，没有确实有效的安全措施而谈企业数据安全，

就尤如无源之水，无本之木。

企业数据安全不应该只依赖于某一种安全技术或手段，如信息加密技术、身份验证、安全

套接字、访问控制或审计技术等，而是需要一套安全策略作指导。根据公司的企业信息环境及

系统建设的具体要求，为保证企业数据安全我主要做了以下几方面工作：（1）、将公司网络划分

为不同的子网并通过防火墙对内外网络之间的通信进行过滤；（2）、创建域控制器对用户进行集

中管理，采用Norton杀病毒软件防止病毒或木马程序的蔓延；（3）、对于数据管理系统采用系

统集成的验证方式、为不同的用户创建分组并充分利用视图、存储过程以加强数据库的安全；

（4）、应用系统对数据库的存取都采用统一的安全基础设施，在增强系统安全性的同时简化管

理员的工作；（5）、制定严密的信息安全管理制度为数据安全应用提供制度上的保证。

因行业特点我公司各部门都较为分散，如各营业所、水厂就遍布于各镇区，同时部门繁多

包括管理、工程、生产、仓储、财务、客服等，为让各部门或分公司都能在统一的网络环境中

协同工作，而又不会影响各自的数据，我们采用一台Cisco三层交换机作为企业核心交换机，

并将各部门划分为8个C类地址的VLAN从而将其隔离开来。在内网与外网之间采用一台

netscreenns25防火墙作为访问Internet的网关，同时用其创建了各分公司与总公司的VPN

连接保证分公司的安全接入，也为外出人员提供了接入公司内网的能力，确保相关业务的连续

性。

公司运行着3台数据库服务器、2台文件服务器、1台Web服务器、3台应用服务器和200

多个客户端，上面是财务、抄表计量、营业收费及生产调度等核心业务，因此对于相关操作系

统、数据库管理系统及业务系统的安全成为安全工作的重点。我们使用Windows2003在网络中

创建了一台主和备份DNS控制器并建立了活动目录，对所有用户的验证全部采用域验证方式，

并禁止Guest帐户、不必要的服务及远程安装、注册表操作的功能，为用户的登录及相关操作

建立操作审计日志记录。为防止病毒或木马程序给公司日常业务造成影响和对核心数据的破坏，

我们在全公司范围部署了Norton企业版杀病毒软件，并利用其管理控制台完成对客户端的部署

及病毒库的下载更新。

公司核心业务相关的数据都存储在数据库内，而我公司的数据库管理系统都采用SQL

Server2000。在信息化建设初期采用的是SQLServer验证方式，但当业务系统逐渐扩展到公

司的其它部门时发现这种方式在管理上十分不便，于是我们采用了与系统集成的验证方式。对

于新开发的应用系统我们则通过DNS实现的单点登录来简化系统的管理，同时创建了如SQL

ServerAdmin、SQLServerUsers、SQLServerDeniedUsers及SQLServerDevelopers等

组对用户实行统一管理。在数据库的开发过程中我要求尽量使用视图、存储过程等对数据库进

行操作，避免将数据操作代码固化到程序中以减少给不法份子进行注入式攻击的可能性，同时

为保证企业运用的连续性使用了ARCServeBackupforwin&mssql对数据库进行双机热备份。

在企业应用系统的设计过程中，如抄表计量子系统、营业收费子系统、生产调度子系统等，

为减少安全设计的难度和复用已有资源，我们开发了企业统一的全局安全基础设施（Global

SecurityInfrastructure，GSI），各子系统都通过GSI进行用户的验证、授权及审计操作。GSI

有两种工作模式，（1）、与操作系统集成的安全管理策略，此时GSI作为应用系统的安全验证代

理将用户的验证请求转发给DNS，DNS完成用户的验证及授权工作并实现单点登录；（2）、独立

28

的安全管理策略，各应用系统共享一份由数据库保存的用户及分组信息，设计时我们引入了角

色的概念，对于多应用系统可分别设计不同的分组与角色，不同的角色拥有不同的授权，用户

的最终权限由各角色及私有权限的公共集合组成。通过GSI解决了长期困绕公司的多个应用系

统的安全管理问题，用户也不用记住多个帐号与密码。

企业数据安全除了技术上的措施以外完善的安全管理制度则是安全工作的保证。为此我制

定了一套安全管理制度主要包括，（1）、对中心机房的进入实行严格的登记制度，并要求管理员

定期更改管理密码；（2）、要求系统管理员每日对系统相关的审计记录进行检查，以发现系统运

行中的异常情况；（3）、定期对系统进行升级和打补丁以防止黑客利用系统安全漏洞对网络或服

务器进行攻击；（4）、定期下载病毒库并为每台客户机进行分发，以保持系统能够对最新的威胁

做出及时响应；（5）、对企业核心数据资产进行定期的备份，要求对备份数据进行异地存放，以

防止火灾、地震等造成不可挽回的损失。通过制度与技术措施的结合为企业数据安全保驾护航。

新系统及系统安全改造工作于2004年底完成，通过以上措施有效的保证了企业数据安全，

简化了系统管理人员的日常工作量，特别是基于GSI的单点登录的实施，得到了公司领导及同

事的认可与赞许。同时，我也认识到企业数据安全工作是一项长期持续的过程，任重而道远，

还需要我们在日后工作中做出不懈的努力。现阶段需要重点加强的工作是对公司相关人员安全

意识的培训，以使企业信息安全制度与措施落到实处而非形式上的过程。

论建立企业内部网INTRANET的策略

近年来，英特网internet以其丰富的应用在社会的迅速得以普及，internet技术的

先进性，引起的企业的广泛关注。于是利用internet技术的思想，在企业局域网（LAN）上加

以应用，组建企业内部网Intranet（在互联网上，相对于英特网现在有人称为内特网）成为时

尚。

作为一名单位内信息中心的技术骨干，我有幸独立完成了整体方案设计、组织参与了

本单位的Intranet的建设并承担了部分软件的开发工作。该方案实施后，集成了原有的业务应

用系统，建立了企业内部信息发布系统和FTP文件传输系统，并与下属单位实现了网络互连，

实现了相互间信息共享，并利用VPN技术利用INTERNET网能访问总公司的Intranet。现将实

施这一工程的一些方法和策略以及我们采用的一些措施介绍如下，希望能对组建中小企业

Intranet网有所启发：

基本情况：1、应用单位情况：某外运集团在某口岸外贸运输企业，是一家经贸部属企

业，是集团的分布各地的一个分支机构，承担进出口货物的运输代理，以进出口货物的单据流

转为主配合物流为客户服务作为主业务。

2、计算机应用情况：现企业有一局城网，NT4.0平台，运行的核心应用软件为集装

箱运输代理业务系统，为VISUALFOXPRO5.0开发的网络多用户系统。还有其它一些人事、财

务、统计软件、办公软件（OFFICE）在使用。有专门的计算机应用机构4人。

本单位Intranet网的实施主要是针对系统内信息流转不畅的需求而得以进行的。在实

施方案的过程中我们主要进行了如下的策略选择：

1、网络建设方案：单位原有一局城网，25个信息息点。但随着信息化建设的高要求，

已远远不能满足需要。单位有6层办公楼，要求人手一机，同时要求与三个基层单位（车队、

外运仓库）和一个集装箱站相连。领导层、中层干部等都要求有相应数据和各种查询。对于本

单位情况，首先在办公楼进行了综合布线工程，由于办公楼不大，集用了集中走线的方案，采

用5类线，100M带宽，125个信息点。交换机采用12口3COM3C5092A10/100M自适应设备，

共享HUB采用数个3COM16口HUB。并选用CISCO3600作为路由器，4个广域网口连接4个远

程基层单位和箱站，采用拨号方式.并将来打算用帧中继FR与北京总部相连（因为经费，暂时

没有申请）。由于单位多为PC机，有庞大的WINDOWS用户群，故网络平台也采用WINDOWSNT4.0.

采用Intranet的基础协议TCP/IP作为网络协议。

另外对于办公楼较大的可采用采用结构化布线，大对数电缆做主干，设主工作间、每

29

层设水平工作间的方案进行。若有好几个楼群如校园网，可采用光纤做主干网（FDDI），再在每

个楼实行P&S布线。

2、软件平台的选择：当前流行的Intranet平台，有A、基于UNIX，B、基于LINUX

（开放源代码的OS）C、基于微软平台WINDOWSNT。考虑到中小企业的特点、可供选择的第三

方软件比较多、支持微软平台的软件厂商多以及方便用户简便易操作、GUI界面等因素，我们

选择了windowsnt4.0作为网络操作系统,用自身配备的IIS4.0作为WEB平台,IE4.0作为客户

Intranet网上浏览平台.相比于SYBASE、ORCALE、INFORMIX、DB2等大型数据库由于SQLSERVER

是与NT平台具与极佳的配合性能的小大型数据库,对中小型企业较为合适,自然就选择SQL

SERVER6.0作为数据库平台.另外，用LINUX平台技术当前也十分红火，从技术上讲也是完全

可以胜任的，只是考虑到学习上的要一断时间，以及用户的接受能力故未采用。

3.由于我们自已的技术力量较强,并且面对外运行业的商品化软件较少.我们打算自已

开发INTRANET上一些WEB应用软件.开发平台用VISUALBASIC/FRONTPAGE/Htmleditor,由于

还要开发一些交互式WEB应用程序，还要采集原应用系统的数据。需要掌握相应用交互式开发

技术和与数据库相连的技术，如CGI（公共网关接口）、API（应用程序编程接口）、ASP（活动

服务器页）、ODBC（开放数据库互连）、RDO/ADO（ACTIVEXDATAOBJECT活动数据对象）。在上

述技术中，考虑到响应速度和效率，我建议采用ASP加ADO的技术进行开发。并且这是当前和

将来的INTERNET/Intranet网主流开发技术。

4、内网与外网的互通以及安全考虑：由于属中小企业，单位上英特网的并发用户数一

般不会超过15人，我们采用了较为低廉的ISDN一线通方式，专用一台PC用安装了代理服务器

软件（PROXY），可实现按需拨号、HTTP代理、FTP代理、TELNET代理、SMTP/POP

邮件代理、用户管理等，可设快速缓冲。当然，用DDN方式，申请合法的IP地址再设

代理的方式也可行，只是由于经费的原因，没有选择。由于内外网的互通，如果没有一定的安

全机制，将使公司的内部数据、机器、应用系统受病毒或黑客的攻击或非授权访问等。

内外网间的安全技术有包过滤、防火墙、安全代理服务等，由于我们选择的代理服务

器软件已有部分安全方面的机制并且内部数据的安全措施、管理制度、备份机制做的还可以。

故没有在这方面投入更多的资金。在内部局域网上，我们选择了NETVRV（50用户）网络版防

病毒软件，在服务器端和客户端都各自安装相应的版本，保证了内网的安全可靠性。当前，做

网络安全的公司很多，如王江民的KV系列、瑞星公司等都可选择。

5、原有的应有系统与Intranet技术的集成：由于原应用系统是基于FOXPRO，数据库

为文件型数据库，所选的WEB应用开发环境并不能直接操作FOXPRO数据库。对此我们有另外编

制了一个软件用于每天从应用系统中将管理者与领导层要的数据导入SQLSERVER中，再以SQL

SERVR为后台，编制WEB交互查询系统。

6、与集团总部的相连：现在WIONDOWSNT4.0支持一种新技术即VPN(虚拟专用网),对

于实时性要求不高又受经费困扰的应用来说,无疑是一种较为可行的方案,由于总部的条件较好,

已建设好INTRANET网,并通过路由器以DDN与INTERNET直通.分公司在目前条件下,与总公司的

连接是暂通过INERNET网,并在此链路基础上,运行PPTP协议(而非PPP协议),虚拟出一个数据

通道,并在此基础上,通过用户身份验证即可实现总公司Intranet与分公司LAN的连接.现在的

应用有,分公司的LAN用户可直接浏览总公司的Intranet网的WEB站点.同时,全系统的业务统

计软件也是改为通过WEB应用程序实现的。

Intranet网运行后,在公司的用户间获得好评,客户界面(IE)的单一化,简化用户培训

学习的过程.同时,网络的建成,极大方便了系统内信息和单据的流转速度,文件、数据的上传、

下载十分方便.原有的应用系统数据还可通过IE浏览查询.部分WEB应用程序的建立,使客户端

的维护成本大大降低.同时Intranet的成功运行，也使得我们的信息部门的地位有所提高。

但是，由于单位性质、规模的许多局限性，诸如费用、本身的技术水平、系统分析能

力等，使一些应用走了简单、实用、低廉的策略。我们仅做了一台WEB服务器、一台SQLSERVER

服务器和一台主域NT服务器，由于机器较少，没有作域名分配；对于与原文件型数据库的应用

30

系统，没有采用效率更好的方法，做了简单化处理；与总公司总部的相连，速度稍难忍受、高

峰堵塞严重，一般使用都各分公司划时间段使用；另外，在说服领导花钱投入加以重视方面还

有待改进；也许，采用与软件公司、ISP等专业公司合作开发会更好地把本企业Intranet网做

好。

鉴于上述原因，我认为我们公司的Intranet网将来还要作如下方面的改进：

1、通信线路的改进：随着各种数据通讯网的建立和改善以及费用的逐步下降，分公司

与总公司、分公司与基单位将来都应该采用DDN/FR甚至光缆等专线接入。

2、软件应用模式从DOS单用户、文件型数据库多用户、C/S、向B/S结构、三层结构

和多层次结方向方向发展，我们单位，将来的应用升级可直接使用B/S结构、三层结构，在开

发技术中要广泛使用面向对象OOP、COM/DCOM构件组件、ADO数据库连接对象、ASP技术。并且

开发方式也要采取与专业技术软件公司进行合作或委托开发的形式，否则，自已开发的软件的

质量、可靠性等方面都难以达到软件工程的高要求；另外，更要在开发中重需求分析、重建模

（可采用UML建模技术）、加强项目管理、团队协作。

3、在1-2年内，用专线接入INTERNET网，建立基于INTERNET网的客户查询系统，在

内外网间设立防火墙。

如何保证软件质量

【摘要】：

软件质量是软件的生命。保证软件质量除了技术上过硬以外，还需要一个良性的管理环境。

软件过程作为软件开发的管理环境对软件质量起着决定性的作用，一个成功的软件过程应该具

备以下几个特性：

1、软件过程是有效的，能够确定并解决软件开发中的不确定因素

2、软件过程中的所有资源都是可以控制的，不会出现依赖某种资源，如依赖某个开发员，

或依赖某台计算机等。

3、软件过程是可预测和可跟踪的，能够知道软件开发所处于的状态以及可能存在的缺陷。

4、软件过程是可以扩展、可调整的；知道缺陷后，能够对软件过程进行修改。

5、软件过程应该是个管理的过程，每个小组的成员都是管理的主体，他们的行为直接影响

到产品的质量，充分调动和激发小组成员的能量对提高软件质量有积极的作用。

本文就上述几个方面结合自己的经验谈谈如何来保证软件质量。

【正文】：

随着计算机软件开发技术的发展和演变，软件开发经历了从简单开发到大规模的软件开发。

可以肯定的是，不论软件开发如何演变，软件质量始终是软件的核心竞争力。目前，我们国家

的软件开发也正在朝大规模软件开发的模式前进，很多国外的先进经验对我们管理软件开发有

很强的指导作用。下面我打算结合自己五年的开发经验从软件过程、风险管理、团队组织来谈

谈我对保证软件质量的看法和做法。

软件过程。

从几年的开发经历来看，传统的瀑布开发已经不适合现在的小团队（<10人）的开发，快

速开发工具RAD的出现以及辅助设计工具的使用，加上软件规模的日益扩大，我们更需要的像

RUP这样的迭代式的开发过程，对各种问题的快速的应变能力成为一个软件开发组织成熟的标

志。

首先我们要认识到像RUP这样完整的软件过程对一个小团队的实施是不切实际的，所以就

有必要对标准的RUP开发过程进行裁减，使得其符合自身开发的特点，所以说一个开发过程是

否有效就是看能不能解决实际问题。

31

去年，我参与了一个不是很成功的项目，项目进度严重超期，开发员信心全无，大家互相

推卸责任，对问题也是机械式的反应。总结后发现，项目不成功的很大一个原因没有一个符合

自身特点的开发过程，在问题出现后没有任何预先制定的制度来协调，所以定义好一个符合自

身特点的软件开发过程是保证软件质量的基础。

根据RUP的经验，我们把软件开发分成和RUP一样的四个阶段：初始化、精化、构建、部

署四个阶段。由于我们是初试使用RUP开发过程，同时根据我们小组的特点我们把软件开发的

目标定位在基本满足CMM2的关键过程域（KPA），达到一些CMM3的关键过程域上。我们制定

了需求分析、变更与配置管理，项目管理，分析设计、测试等几个关键过程，通过对这些关键

过程的定义来控制整个软件开发的活动。

需求分析关键活动是完成收集和定义软件开发需要的资源。根据开发项目性质的不同，需

求分析的重点有所不同，比如对于数据库为主的项目我们就把重点放在项目的业务逻辑上，主

要分析和比较业务逻辑之间的差别和实现，如简单的进销存项目，而对于与系统结合的比较紧

密的项目，就把需求分析的重点放在接口的实现上及与平台相关的特性上，如网络数据包分析

项目。实践证明注意到项目之间的差别对我们开展项目计划和制定项目计划都有

重要的意义。

变更和配置管理关键活动定义了当出现需求需要变更时采取的对策。我们采取的策略是：

当需求出现变更的时候，所有成员都进行交流确定这个变更对项目进度的影响，然后综合考虑

后确定是否要进行变更，一旦确定了对策，任何成员都必须无条件的执行，由于团队规模较小，

这一活动相对容易实现。

项目管理关键活动主要是定义项目开发所需要的环境以及如何协调成员之间的进度。这个

关键活动的实施我们是主要集中在版本控制上，利用现在流行的版本控制工具，如CVS，VSS都

可以有效的管理和协调小团队的开发。

分析设计和测试这两个关键活动我们主要采用几个原则。第一，分析和设计适当分开。做

分析的不能全去做做设计的，在设计中有不做分析的人才可能发现分析的缺陷，分析的鉴定应

该由所有成员统一来执行。第二，设计和测试适当分开，开发员并不是很乐意去做繁杂的测试

工作，而且开发员的测试思路都比较狭窄。第三，设计和文档编写员适当分开。设计员应该将

精力放在设计上，可提供简单的样稿，具体的文档编写应该交与专人。实践证明，上述原则的

应用是成功的。

除了上述的几个重要关键活动以外，RUP软件过程还定义了其他更为细的关键活动，在这

里就不详细叙述了。

风险管理。

风险是最容易影响软件进度的因素，在开发项目的过程中往往由于某种突发事件而影响到

整个开发进度。就我所经历的项目来看，项目大概可以分为为企业定制软件和通用的商业软件

两类，而为企业定制软件的项目占多数。

不难看除，为企业定制软件的风险除了技术风险以外，商业风险等其他风险几乎没有，所

以对于这类项目，我们就要把精力放在技术上，主要是预先判断采用的技术方案对项目的成功

是否有推动作用，比如用VB去开发与操作系统结合得很紧密的项目就不太合适。除了这样的问

题以外，当突发事件到来时，我们要严格按照定义好的流程去处理，切不可随意行事或按主观

意思行事，当没有流程与之定义，应该征求成员的意见然后定义出一个大家都接受的流程,这样

增加开发员的主人翁意识也是有帮助的。对于通用的商业软件，除了技术上的风险以外，商业

风险也是很重要的，密切注意竞争对手的状态和市场对该项目的容纳程度也是项目成功的关键，

由于实践不够，体会也不是很多。

团队组织。

小组的每个成员都是开发项目的主体，他们的行为直接影响到软件质量。一个成功的软件

必然是有一个好的团队，所以开发项目时要充分尊重和调动团队的每个成员。

32

长久以来，我们都采用的是树型式管理(图1)。一个项目经理管着几个程序员，由项目经

理分配任务，程序员按时完成任务，这个模式对项目经理的要求很高，项目成功的风险都由项

目经理承担，成员的主动性也不够，一旦项目经理离开，整个项目就陷入瘫痪状态。这种模式

比较适合于一个项目参加的都是新手，这些新手在项目经理的指导下完成任务。

比这种模式更为民主的模式是互相平等模式(图2)。在这种模式中，成员彼此之间互相平

等，共同商讨问题，可以充分发挥出每个成员的主动性，但这种模式的问题在于当问题出现后

容易耽误时间。要避免这种现象对成员的要求比较高，大家不要互相推卸责任，也不要互相扯

皮，所以这种模式比较适合于小组成员具备较高的素质和技能。

结合这种模式就产生了第三种模式：混合管理(图3)。这种模式对于高级别的成员采用平

等模式，对于新手采用树型式管理。

在几年的开发过程中，受到管理学的影响，我们采用了一种驱动式的管理模式(图4)。在

这个模式中，项目经理不是直接管理其他成员的活动，而是类似于教练的角色在旁边不断的指

导和纠正他们的行为，整个实际活动还是由成员自己完成。这种模式可以有效的分担项

目经理的压力，可以把项目经理从以往的转注于项目实现转移到管理的角色上来，项目经

理根据成员的能力和特点不同，分配他们不同的角色，明确他们的责任，指导他们的行为，而

项目经理注重管理，这种模式类似于足球队管理，在足球队中，教练不会自己上场，而是在场

边确定中场、前锋、后卫之间的关系，把自己的战术贯彻下去，实际的操作还是有队员自己完

成。

经过实践比较，我认为对于一个刚成立的团队第一种模式是比较合适的，当成员的意识和

能力提高后，就要加大他们的参与性，采用第二种模式或第三种模式，当成员成熟后，采用第

四中模式能够有效的提高成员的参与意识和责任意识，所以说软件开发中的每个成员都是管理

的主体，只有成员的能力提高了，软件的质量也就有保证。

综上所述，软件过程的定义，风险的处理策略，团队的组织对软件质量的影响是最大的，

在处理好这些问题之后，我们的软件质量有了大幅度的提高，而且我相信这些问题的解决是大

规模软件开发的基石之一，也是软件组织成熟的标志之一。

论软件项目的进度管理

摘要

本文讨论了《电力行业工作票、操作票系统》的项目管理，在本项目中我作为项目负责人，

承担了项目管理工作。

在本项目管理中，我主要采用了面向对象技术同传统技术相结合的原则，在估算项目的工

作量这方面尤为突出，面向对象技术对传统技术有所改进，传统技术能弥补面向对象技术的不

足。

本文从合理的估算项目的工作量及技术难度；识别关键任务；随时了解项目进度，必要时

调整进度表等方面讨论了《电力行业工作票、操作票系统》项目管理的基本活动与方法，有效

地控制开发进度，确保项目如期按质量完成。本系统在电力系统已经运行，状况良好，受到一

致好评。

正文：

2003年2月，我参加了《电力行业工作票、操作票系统》的开发，担任项目管理工作。电

力系统有关部门在对电力设施进行检测、维修、试验等一系列活动时应按照我国电力行业相关

标准进行工作，《电力行业工作票、操作票系统》就是按照国家有关标准及电力行业操作规程设

计的仿真系统。工作人员在施工前按照工作流程在此仿真系统上进行操作，严格遵守电力设施

的逻辑闭锁关系，顺序执行。有效地防止不规范操作，确保电力设施及现场工作人员的安全，

提高安全意识。

本系统由系统图编辑平台和工作票、操作票签发系统两大部分组成，其中系统图编辑平台

33

主要是编辑变电站、用电系统及变电站控制系统图，每一个电力设施对应一个对象，在系统图

上都有相对应的部分，系统图真实地反映电力设施的布局及相互关系，生动形象又合乎技术标

准，同时为第二部分提供操作对象。工作票、操作票签发系统主要是在系统图的基础上进行点

击操作，每次点击对应一个对象即一个电力设施，根据电力设施的逻辑闭锁关系自动生成相应

的工作票或操作票或提示操作不规范。

在本系统的开发过程中，我通过合理的估算项目工作量及技术难度；识别关键任务；随时

了解项目进度，必要时调整进度表等方面对项目进行管理，确保本系统如期按质量完成。

1、合理的估算项目工作量及技术难度

我们在项目工作量及技术难度的估算上采用面向对象技术同传统技术相结合的原则。

本系统采用了面向对象的分析、设计等一系列面向对象技术，在本系统工作量的估算上根

据功能点进行估算。将每个功能模块逐步分解，直至基本模块为止。我们将系统分为系统图编

辑与工作票、操作票签发两个大的功能分别进行估算。系统图编辑部分主要是一个图形编辑系

统。一种电力设施对应一个类，电力设施的技术参数及其操作对应相应类的属性和方法，电力

设施图是由线段、圆、曲线、折线、多边形等基本图形组成，这些基本图形分别对应一个类，

这些类又继承一个最基本的类。系统图编辑部分的工作量也就是这些类的实现，工作票、操作

票签发部分用到了编辑平台的系统图，因此由大量的功能可以复用，这部分的功能划分同系统

图编辑部分一样也是采用类作为基本结构，这样就比较准确的进行工作量的估算。

同时我们开发的这个系统是基于C/S结构的，由于C/S结构的系统我们公司有不少成功的

案例，因此有不少的案例供我们参考。对于本系统的第二部分我们就是借鉴以前我们做过的基

于C/S结构的系统，基于C/S结构的系统的框架基本上是一致的，数据库的设计、前台操作如

对数据库进行添加、删除、修改、查询等一系列活动大体相同。正是如此，有大量的东西可供

我们复用，如权限控制模块我们就是复用以前的案例，仅作少量修改。在工作量的估算上也有

很好的借鉴作用。这对工作量的估算也是一个重要的参考，为工作进度安排提供了依据。

在技术上，我们重点考虑本系统与其他C/S结构的系统的不同之处，相同或相似之处我们

认为没有技术难点。系统编辑平台主要是绘图，我们知道MFC的绘图功能确实强大，但是过于

繁琐，功能封装不是十分完美，我们采用了Form++这个MFC扩展类库，这个扩展类库对图形操

作封装得很好，大大降低了系统图编辑部分的难度，在界面设计上我们采用了BCG这个扩展类

库，使得VC应用程序界面设计得如同Delphi等工具一样完美。同时减少了工作量，在工作安

排上，技术难度相对大一点的部分我们安排经验丰富的程序员，同时也同其他工作组的成员商

讨技术细节问题，同他们进行技术探讨。这样不至于因为某一技术细节而影响整个工程进度。

根据上述分析我们制定一个详细的进度表并定义相应的里程碑。

2、识别关键任务

系统图编辑部分是整个系统的基础，因为工作票、操作票签发部分是建立在该部分的基础

之上，系统图编辑部分直接影响到整个项目。因此该部分是整个系统的关键部分，在这部分中

每种电力设施所对应的类及其父类的定义是关键，因为所定义的类必须完整、准确地反映该电

力设施的技术参数和操作。

工作票、操作票签发部分，是用户明确提出的要求实现的功能，直接面对用户，这部分的

成功与否直接影响到该系统的质量，因此也是不容忽视的。

如果上述两部分任务的进度受到影响，则整个项目的完成将受到威胁。因此是本项目的关

键任务。在进度控制时我们将其作为重点对象进行控制。

3、随时了解项目进度，必要时调整进度表

在确定项目开发计划时，我们制定了详细的进度表。我们在确定每一项任务时都确定该任

务的工作量、开始时间、持续时间、结束时间。同时让每个小组成员知道自己所承担任务的时

间表，小组成员根据自己的任务制定自己的详细工作计划。

工作日志是了解每个小组成员工作情况的很好的方式，我们要求每个小组成员对自己的工

34

作都要做工作日志，对自己每天的工作做详细记录。每周对自己的工作进展做出结论，向项目

组汇报。在做结论时，不得使用“差不多”、“大概”、“完成了90%”…等模糊字眼。而是

采用某任务“已经全部完成”、或者“90％的工作全部完成”或者“再过1天全部完成”…

等方式。每个小组成员对自己做出的结论负责，这样可以做到随时了解项目进度，为调整项目

计划提供客观基础。

同时我们在项目进度计划中根据项目设计定义了相关的里程碑，在每个里程碑我们都采取

小组会议形式对本阶段的工作进行确认、总结，对本阶段的进展情况做出结论，并决定是否调

整下一阶段的进度计划。

在系统图编辑部分我们认为各电力设施所对应的类（包括其父类）定义完成为一个里程碑，

每个类是否具备了相对应的电力设施的技术参数及操作是该里程碑的标准，这些类（包括其父

类）的实现完成又为一个里程碑，……整个系统图编辑部分完成也是一个里程碑。每个里程碑

的标准在系统设计时已经定义好。

结束语

《电力行业工作票、操作票系统》目前已经开发完毕，运行状况良好，受到一致好评。在

本系统开发的整个过程中采用了面向对象技术同传统技术相结合的原则，因为小组成员的各有

特长，面向对象技术不是每个小组成员都熟练掌握，加之面向对象技术在我们公司还不是很成

熟，必须有一个过渡，不能一下子转型，因此采用这种策略符合我们公司的现实情况。

由于项目进度管理得当，项目按期完成，我们小组赢得公司的好评，其他小组也研究我们

的管理方式。当然项目管理方式多种多样，根据项目不同、人员不同管理模式应做调整而不是

一成不变。适合本项目的管理模式才是最好的模式，先进的管理方法在不同的项目组中取得的

效果是不同的，这有待于我们去研究，探索，实践，总结。

论软件项目的进度管理

摘要

2001年10月，我参与xx市农村信用联社综合业务信息系统的开发工作，该系统面向交

易、以客户为中心、采用大会计模式，并以会计核算为核心，实现本外币合一，将柜员管理与

柜面业务有机地结合起来，以业务种类码来划分整个业务系统。该项目分为二期：第一期为柜

面业务,为期14个月，已于2002年底完成；第二期为卡业务，为期一年，尚在开发中。

在该系统的开发中，我主要担任可行性分析、需求分析、概要设计和第一期项目的项目管

理工作。我采用PERT计划评审技术，标识关键任务的同时，允许一些任务并行进行；着重考虑

人员在整个项目开发过程中的安排；重视文档规范、命名规范，为减少员工之间的通讯障碍，

还启用了Notes系统；跟踪和控制项目计划的执行等措施，保证了项目按期完成。但是，由于

对人员流动估计不足，复用力度不够，给项目的进度管理带来了一定的困难。在以后的项目中，

我们把限制人员流动率将作为一项合同约束。

正文

2001年10月，我参加了XX市农村信用联社综合业务信息系统（以下简称XX系统）的分

析和开发，该系统由我联社与乙集团公司联合开发，系统采用C/S体系结构，主机采用两台IBM

RISC/6000S系列机，操作系统为IBM的AIX4.3.3，数据库选用IBM的DB2UDB6.1，磁盘

阵列选用IBM的7133SSA串行存储体系结构，前台为SCOUNIX5.0.5，中间件采用IBMTxseries

CICS，编程语言采用SQL和C。

XX系统面向交易、以客户为中心、采用大会计模式，以县级联社为单位设立一个帐务系统，

改变原来的储蓄、对公等总帐分开的做法，并以会计核算为核心，把整个帐务系统融合在一起，

实现本外币合一，将柜员管理与柜面业务有机地结合起来，以业务种类码来划分整个业务系统，

打破传统的业务品种和业务部门的界限。

XX系统分两期实现，第一期为期14个月，已于2002年年底完成并投入运行，主要完成农

35

村信用社柜面业务，包括储蓄（对私）、对公、信贷、系统内电子联行、通存通兑、与人行的天

地对接、中间业务等；目前系统内共设机构87个，柜组415个，业务操作员三千余名。第二期

为期一年，尚在开发中，主要为卡业务（包括与人行的一卡通、自办农信卡业务等）及客户自

助业务（包括ATM、电话银行、网上银行等）。

在XX项目中，作为联合开发的甲方主要代表，我担任项目的可行性分析、需求分析、概要

设计和一期项目的项目管理，跨地区通存通兑接口模块的详细设计与实现等工作。

软件开发项目进度管理是软件开发项目管理的一个重要内容，有效的进度管理是保证软件

开发项目如期完成的重要环节。在XX一期项目软件的开发过程中，为保证软件按时完成，我采

用PERT计划评审技术及一系列的方法和策略。

1、采用PERT计划评审技术标识关键任务

采用PERT计划评审技术标识关键任务。XX项目计划中规定了一期项目的的交付期限为2002

年年底。整个一期项目长达14个月。在一期项目的开发过程中，采用的是“改进型瀑布模型”，

我们从可行性分析结果出发，使用快速原型方法来补充和完善需求说明，还对信贷部分的需求

进一步细化。从设计阶段起的各阶段基本采用了传统的开发方法，各阶段的结束标志比较明显。

所以在软件的开发过程中，我采用了PERT计划评审技术对开发过程中的各关键任务加以标识，

允许关键任务以外的其他任务在机动期内伸缩。而关键任务的伸缩不得超过一周。当遇到关键

任务延期时，我召集大家寻找原因，并由主要责任人签字。把这种责任作为业绩考核的一部分

与收入挂钩。

在标识关键任务的同时,根据PERT图，允许某些任务的并行。在概要设计阶完成并通过评

审后，允许各子系统在详细设计阶段及实现阶段任务上的并行进行。我把系统划分成储蓄对公、

信贷、联行三个子系统，在概要设计阶段的任务一完成，就将开发人员分成三个小组，分别进

行上述三个子系统的详细设计与实现。实现了在这两个阶段上任务的并行，也确保了项目的如

期完成。

2、着重考虑人员在整个项目开发过程中的安排

着重考虑人员在整个项目开发过程中的安排。我从各县联社抽调业务骨干，作为业务分析

人员，提出并确认需求。考虑到本项目完成后的维护需要，在乙方开发人员大部分撤离后，维

护任务将主要由我社一方承担，所以从概要设计阶段开始，我方派出了三名高级程序员，分别

参与储蓄对公、信贷、联行子系统的设计，继而参与详细设计、编码实现，也为后来的维护作

准备。

3、减少开发人员之间的通讯障碍，提高生产率

减少开发人员之间的通讯障碍，提高生产率为了确保项目的如期完成，我们事先规定了文

档编写规范、命名规范，重视文档的编写、保管等工作。重视文档与设计的一致性，先修改文

档，再修改程序，不至于因为文档与设计的不一致而影响工期，对跨越里程碑的文档修改设置

严格评审。为了减少开发人员之间的通讯障碍，还启用了Notes系统，开发人员可以通过内部

Mail进行交流，及时沟通，减少误解。

4、跟踪和控制项目计划的执行

跟踪和控制项目计划的执行。为确保本项目的如期完成，在项目开始后，我们定期召开各

组长会议，让组长们报告各自小组的进展情况及遇到的问题。通过交流开发过程中遇到的问题，

共同探讨解决方法。我对照计划，跟踪实际执行情况，如果项目进展顺利，在预算范围内，我

会适当放松一些控制；但只要一有问题，我会尽可能帮助排解。例如，在编码及单元测试时，

因为时间比较紧，尤其信贷组，按揭贷款和跨社多头贷款控制的编码过程中遇到些阻挠，测试

也不够充分，加之个别人员流动，我只好调整计划，适当调整人员，还让信贷组开发人员加班

加点。有时我也找个别开发人员交谈，以了解他们对开发进展情况的评价，以及他们个人遇到

的一些问题。尽我所能帮他们解决问题。

在本项目的开发过程中，所有由于以上采取了以上的技术和方法，在很大程度上保证了项

36

目的如期交付（一期项目按计划已于2002年年底交付并投入运行）。其中采用PERT计划评审技

术，标识各阶段的关键任务，允许一些任务的并行执行是比较成功的，划分的储蓄对公、信贷、

联行三个组在详细设计与编码阶段的并行执行，缩短了整个项目的开发周期。重视文档的编写，

效果也比较好，内部Notes的启用减少了通讯障碍，提高了生产率。安排本系统员工的积极参

与也是成功的一面，参与过需求分析和确认测试的我方人员在系统上点过程中对培训辅导帮助

很大，而参与概要设计起各阶段任务的三名高级程序员更为系统投入运行后的维护提供了方便。

一方面，这些人员参与了从概要设计阶段起的各个阶段，熟悉了整个的实现过程；另一方面，

这些员工熟悉业务，在后来的改正性、完善性维护方面起了很大的作用。

但是对人员的流动把握不足，尤其对乙方人员的流动更显得无可奈何。很大程度上带走了

经验，也影响了进度。同时，也没有充分考虑到本系统内参与设计人员的流动。项目初期，本

想增加候补人员的，但考虑到那样做还得培训，同时也增加通讯、交流的时间，担心反而会影

响进度，所以未安排充分的候补人员。致使人员离去时只好再作调整，显得有些被动。所以对

于人员的流动，现已作为一项约束，限制人员流动率不得高于某个百分点而在二期的开发合同

中明确规定，相信会带来好处。

另外，在项目设计过程中未充分考虑代码的复用，复用程度比较低，三个组间复用的只是

本项目公用的如记帐部分等，还有就是各自组内的代码积蓄了。开发效率比较低，也正因如此，

不但延长了编码时间，而且还必须加强测试。如果能加大复用力度，在保证项目的进度和系统

的质量方面会更完善些。

论软件过程的改进

摘要：

2001年8月，我参加了公司一个对原有产品进行升级的项目，担任项目经理一职。这个项目

是在原有的产品上进行升级，系统架构由二层改为三层，并在功能上对原有系统进行扩充。同

时考虑到以前我们做开发时，软件过程不规范，原有系统在设计、开发、维护、实施上存在一

些弊端，开发出来的软件总存在这样那样的问题。我们在这个项目进行过程中，对软件过程进

行了改进。以前我们做开发时，软件过程不规范，开发出来的软件总存在这样那样的问题，在

这个项目里，我们努力做好项目规划、加强版本控制，采取了一些质量控制手段，如同行评审、

专家评审、加强测试等，使软件的质量得到保证，同时也降低了开发成本。现在看来，这个项

目在一定程度上是取得了成功，但还是存在一些问题，如采用工具方面，过程改进制度化方面，

过程标准化与工程进度方面的矛盾等都有不如意的地方，后来公司都对这些问题有所认识，也

在不断地进行改进，公司的软件过程已日渐成熟，并于去年顺利地通过了CMM3认证。

正文：

软件过程的改进是一项需要长期不断地进行下去的工作。以我们公司来说，做为一家软件

公司，过去对软件的开发过程并不重视，接到项目后首先考虑的是如何用尽量短的时间来完成，

而忽略了软件的质量，结果也往往是欲速则不达，甚至因为产品的不成熟使工期一拖再拖。

在2001年8月，我们要对公司原有的《城镇职工基本医疗保险》产品进行升级。这个产品

是为了配合国家的公费医疗制改革，由公费医疗改为基本医疗保险而开发的。产品由各地劳动

部门下属的医疗保险管理中心组织建设，中心机房设在医保中心，通过城域网连接到各定点医

疗机构（医院和药店），参保职工可持医保卡在定点医疗机构直接消费，由医疗机构为病人垫付

费用，事后再与医保中心结算。原产品为两层C/S结构，各定点医疗机构的前台为脱机消费，

定时传送数据。这次产品升级首先将系统架构由原来的两层C/S升级为三层C/S，中间层采用

比较流行的Weblogic或SilverStream做应用服务器，用J2EE实现业务逻辑，并采用标准的程

序接口与各前台程序连接，以方便与第三方软件与我们的系统集成。网

37

络传输也由原来的定时传送改为实时连接，软件功能上也需要突破由于原产品设计时没考

虑周全而带来的限制，如原系统为实现脱机消费，采用了IC卡带金方式，但系统设计时没有考

虑到IC卡本身可能存在质量问题，而经常发生医保个人帐户透支问题，在新系统中我们就采用

了个人帐户在医保中心统一管理，IC卡只是作为一个身份识别的工具来解决这个问题。因此在

项目起动时，对这个产品的定位就是一个全新的产品，而不是对原有产品进行修改。在这个项

目里,我担任了项目经理一职。

1、做好项目规划

在项目的规划阶段，我们意识到公司原有的软件过程存在很大的弊端，首先，原来的软件

过程中，设计与开发职责不分，甚至存在分析、设计、开发、测试全由一个人承担的做法，这

样做不但是对人力资源的浪费，同时软件质量也得不到保证。开发和测试由一人承担，不利于

测试出软件中存在的错误，整个过程由一个人来做，做出来的软件究竟对不对，没有一个说法，

只有到最后程序拿给用户去用时问题才能暴露出来。再者在这样的过程中，开发人员往往会忽

略文档的重要性，这对后期的维护也会带来一些问题。针对这一点，我们首先将项目组分为设

计、开发、测试三个组，设计和开发组由系统总设计师负责，测试组有一个专门的组长。设计

组负责软件的分析和设计，形成设计文档，设计文档首先要做同行评审，评审内容一般是文档

的规范性以及对开发人员的指导性方面，同行评审后由系统总设计师来做专家评审，评审的内

容是设计是否符合业务需求。开发组负责根据设计人员的设计文档编写出代码，代码编写出来

后要通过同行评审，评审内容是代码的编写是否符合编码规范、是否具有可读性和可维护性。

测试组负责根据需求和设计文档编写测试用例，并对开发出来的代码进行测试。通过这样的改

进，我们充分调动了各员工的积极性，也明确了各自的责任，使得整个过程处于受控状态。

2、加强版本控制

在原来的软件过程中，我们对软件的版本控制不严密，没有采用必要的工具，而是完全由

版本控制员手工进行操作，且版本控制员还要兼一部分开发任务。在这种情况下，版本控制经

常出问题，有时同一代码被不同的人员同时修改，有时将本应发给甲用户的程序发给了乙用户，

又或者开发人员自以为自已手上的代码是最新的，而出现已改过的BUG又重复出现的现象。这

样做的另一个问题是版本的历史很难追踪，由什么人在什么时候做了什么样的修改完全没法掌

握。在这个项目里，我们意识到这一点，首先，设立了专门的版本控制人员，同时使用了ClearCase

版本控制软件，所有对文档和代码的修改必须先从版本控制服务器上CheckOut，改完后再Check

In。这样做就杜绝了版本的覆盖问题，而且版本历史也是一目了然，任何修改都会形成日志，

这也为问题责任的追究提供了依据。

3、加强测试工作

在这个项目里，我们特别加强了测试人员的作用。在这之前，公司也设立过测试部，但由

于存在部门之间的沟通问题，测试部很难参与到项目中来，即使参与进来也发挥不了应有的作

用，测试部曾一度被撒消。这一次参与测试的是新成立的测试部，而测试人员加入到项目组，

业务上测试组是受项目经理领导，人事上仍受测试部领导并考核。这样做，首先消除了测试与

开发之间的沟通隔阂，而测试人员也少了其他项目的打扰，可以专心只为一个项目做测试。而

以前出现的因部门间隔不让测试人员参与直接由开发人员自已测试的情况也就不存在了。

由于以前的软件过程存成那么多的问题，使我们的产品不是一个成熟的产品，不成熟的产

品后期施工的成本是很高的，因为存在太多的问题，维护人员要做大量的维护，而前期开发并

没有留下什么文档，也给后期的维护带来很多困难，维护人员每修改一段代码首先需要读懂原

来的程序，往往读不懂时就直接在原来的程序上加上一段通过设置条件来跳过原来的代码，这

样使得程序越来越难读懂，问题也越改越多。这样的产品拿到一个点去施工时往往需要二个月

甚至更长的时间。在这次的升级中，由于采用了较好的软件过程，产品的成熟度得到了很大的

提高，而设计文档也是我们这一次重点控制的对象。这样的产品为后期的施工提供了很好的条

件，现在，产品在一个点的实施时间可以缩短到四十天以内，大大地减少了施工成本。

而好的设计文档也为产品的本地化修改提供了好的条件，维护人员读懂设计文档比读懂程

38

序要容易得多，在这样的基础上做修改出现的问题也越来越少。

尽管在这个项目里我们做了这么多的改进，但也存在不少的问题，首先我们使用的

ClearCase版本控制软件存在问题，这个软件要求所有开发人员将自已的机器加入到由服务器

控制的域里，否则，就只能取到版本快照而不能进行版本更新。由于这样做，域管理员具有比

本机超级用户更高的权力来控制每台机器，使得开发人员不愿意这样做，于是出现了多人用服

务器超级用户远程控制服务器来取版本的现象，使得版本的责任追究出现问题。而我们使用的

ClearCase版本不支持WindowsXP，也使这个版本控制软件的使用出现了问题。

另外，我们的软件过程制度化方面也没做好，在项目的早期，各项工作流程都被很好的执

行，各种文档也非常完整。由于我们这一次的升级只是针对的整个产品的一个部分进行的，在

这之后我们又对这个产品进行了一次更大的升级，使得我们的产品能覆盖更大的范围。但后面

的这次升级由于规模比这一次大，人员也大量的增加了。而新加入进来的人员并没有很好地进

行规范培训，好的软件过程标准也没有形成有效的制度，再加上项目工期非常紧，包括同行评

审、专家评审这样的流程都开始有些流于形式甚至被忽略。开发组编码时也没有完全按制定的

规范进行。因此，产品质量上就出来了一些反复。我们这个产品是个可分可合的产品。因些在

后来的产品实施上出现了这样一种情况：如果一个点只实施前一次升级的那部分，施工难度很

小，能在短期内完工，本地化开发工作也很好完成。而要全面实施整个产品的话，工期就会被

拖得很长，本地化开发工作也存在很大的问题。

针对出现的这种情况，我们公司意识到了软件过程改进的重要性，针对版本控制软件问题，

我们改用了功能虽然没有ClearCase强，但更适合于我们的VSS。而在制度化方面，更是下了

大力气，从印度请来了专家为我们的改进做参谋，现在公司的情况已有很大改观，各项制度已

不再流于形式，而公司更是在并在去年年底顺利地通过了CMM3的认证。软件过程改进的路还很

长，但有一点是不变的，只有通过软件过程的改进，我们的产品才能不断地走向成熟。也只有

产品成熟了，我们才能在竞争中永远立于不败之地。

应用CMM改进银行软件过程

摘要

我在某银行软件开发科室工作，长期从事商业银行中间业务应用的开发。在以往的中间业

务产品开发过程中，存在许需求不明确；开发人员有章不循，依靠个人智慧，开发处于低水平

的重复状态；项目的进度、质量难以保证等问题。

我们从2001年底开始着手解决中间业务产品的整合和综合发展问题，经过项目分析和论

证，我们提出了要开发一套具有良好扩展性、通用的中间业务平台系统。为了避免在新平台的

开发过程中继续出现上述问题，作为该项目的主要负责人，我在中间业务开发团队引入ＣＭＭ，

采取了一些有效的策略和方法，主要包括：进行CMM培训和咨询工作；重新制定中间业务开发

规范；做好需求管理；加强过程的跟踪和监督等。我们成功实施了银行中间业务软件过程的改

进，开发了高质量的中间业务平台。CMM是全面持续的过程改进，笔者从定量过程管理和人员

组织管理方面，提出了今后的努力方向。

正文

中间业务是指银行利用自己的网点、设备、网络、信息等优势，以中间人的身份接受客户

委托，提供各类金融服务并收取相应手续费的业务。作为银行业务新的利润增长点及重要的吸

收存款手段，中间业务正日益受到国内各商业银行的重视。近年来，我所在银行根据业务发展

的需要，通过陆续推出代发工资、代收电话费、代收水电费、代收学费、行政事业代收费等一

系列代收代付的中间业务，在提高自身服务水平的同时，增强了在同业中的竞争能力。

一、中间业务开发过程中存在的问题

随着中间业务品种的增多和市场对中间业务要求的提高，中间业务系统越来越庞大与复杂，

尽管我们中间业务开发团队不乏技术过硬的开发人员，还是经常出现项目不能按时完成；新的

中间业务项目上线时，软件质量不理想，其中包括一些明显的错误，如客户不能交费、重复扣

39

或少扣客户的费用，客户交费后打印不了发票等；而且文档不齐全，造成维护比较困难。作为

中间业务开发团队的主要负责人，我召集了几名技术骨干总结了以往的经验教训，找出了存在

的一些主要问题：

1、随意性决策较多。往往软件产品从立项阶段开始就成了“实验田”——软件产品做与不

做，什么时候交付等多是凭个人的主观意愿，没有参考以往经验，也没有充分考虑资源的有效

投入，导致开发的产品维护成本较高，“打补丁”现象较多，用户使用不方便。

2、有章不循。尽管我们科技部门比较注重规章制度的建设，也针对软件开发过程制定了大

量的程序性文件，但由于没有严格的后续跟踪与监督机制，使软件开发的质量控制大打折扣。

3、依赖个人智慧。我们开发团队中不乏一些具有相当才干的项目经理和骨干人员，他们为

研发银行软件产品做出了较大贡献。然而，由于他们的经验没有被很好地总结、归纳，并上升

为整个开发团队的财富，致使有的项目负责人一走，开发质量就会下降，这说明软件产品的研

发依赖于个人而不是整个开发团队。

4、“可视性”低。软件开发过程不透明，上级不了解下面在做什么，无法实时监控项目进

展；下面的开发人员“报喜不报忧”。由此导致产品缺陷被慢慢积累起来，等看到结果为时已

晚。

二、应用CMM改进中间业务平台开发过程

由于传统的中间业务系统产品开发平台多样化、缺少统一规范、产品分散、功能不足，大

大影响了开发效率和增加了维护难度。为解决传统中间业务开发模式存在的诸多弊端，我们从

2001年底开始着手解决中间业务产品的整合和综合发展问题，经过项目分析和论证，我们提出

了要开发一套具有良好扩展性、通用的中间业务平台系统。为了避免在新平台的开发过程中继

续出现上述问题，作为该项目的主要负责人，我考虑在中间业务开发团队引入ＣＭＭ，试图把

个人的脑力劳动规范为有纪律的智力产品。

1、培训与开发过程规范的制定

在项目启动前，我们请了一家知名的培训机构，培训了CMM的基础理论，并结合一些软件

开发公司实施CMM的案例讲解，促进了团队成员对CMM的认识和对软件过程实行规范管理的理

解和支持。然后，我们分析开发部已有的规章制度存在的问题和缺陷，重新制定了中间业务开

发规范。

首先定义出软件开发中的主要过程，参考CMM并针对中间业务开发的实际需要，确定了每

个过程的具体工作内容。

其次确定了软件开发的具体方法，我们确立了面向对象的开发方法，并对每个开发过程定

义了相应的具体文档，如系统计划阶段必须提交《系统开发计划》，需求分析阶段必须提交《软

件需求规格说明书》。并定义了文档的格式和必须提交的内容。

最后，对每个过程划分相应的人员职责，即按照工作要求，进行人员分工，并确定具体的

工作内容。

2、努力做好需求管理

在银行的软件研发过程中，需求管理是一个“老大难”问题。技术部门抱怨业务部门提出

的需求不清晰，甚至提不出需求；业务部门抱怨技术部门对需求理解有偏差，开发的产品与初

衷相去甚远。从ＣＭＭ的角度来说，业务部门提出的需求只是顾客需求，而在顾客需求中既有

技术层面，也有非技术层面的，即便是技术层面的需求，也并非面面俱到都要开发，比如一些

技术上不可行或者资源要求不能满足的需求就必须剔除。只有适合软件产品研发的需求才会被

最终制作成规格说明。

在中间业务平台需求的制定过程中，我采取了以下措施：

（1）组成业务部门与技术部门共同参与的需求组，需求提出后经过上级领导的评审和业务

部门确认才实施开发。

40

（2）制定技术部门必须和业务部门商定需求变更流程和跟踪监督的机制，需求变更如何提

出、由谁进行评审、由谁决定做与不做、对项目进度及对资源的影响如何等都应事先考虑。

3、加强过程的跟踪和监控

软件开发过程中，我们按照软件开发过程规范严格实施。在项目启动的初期，开发人员要

花很大一部分时间写文档资料，工作压力比以前大多了，工作流程的改变，也导致一段时间内

效率降低。大家逐渐习惯后，感觉文档是研发人员劳动成果最好的记录，工作比以前清晰，规

范的文档减少了对某个人的依赖，使软件研发过程的上下环节紧密衔接。在整个过程中，我们

得到所有的文档，并根据文档的内容对每个过程进行了检查。在进度控制方面，我首先制定了

系统开发计划，要求开发人员填写工作量周报，并据此绘制项目进度图，随时了解项目进展，

并适当调配人手，整个项目比计划略早完成。

在质量保证方面，银行软件产品质量对业务的开展尤为重要，它涉及银行的资金安全和自

身信誉，因此必须确保软件开发产品质量。现在我国各银行并没有成立单独的质量保证机构，

对质量的控制主要掌握在项目研发人员手中，为此ＣＭＭ建议成立专门的ＳＱＡ组，检查软件

开发过程标准、规程的合理性。鉴于人手问题，我们没有成立专门的SQA小组，采用测试小组

兼做SQA工作，对项目组的监督“对事不对人”，并定期公布监督结果。

三、经验和不足之处

经过近一年工作，我们完成了中间业务平台的开发，新的中间业务平台运行良好，受到了

业务部门和技术部门高层的赞许。在该项目的开发中，由于引进了CMM，加强了软件过程管理，

很好地解决了以前存在的四个问题。中间业务产品的开发目标更明确，提高了产品开发过程的

可视性和可控性，从而在提高产品开发能力的同时提高了产品的质量；我的开发管理水平也得

到了很大的提升。高层领导尤其对我们的开发流程和开发规范表示认可，并决定在整个开发部

门推广。我将这次软件过程改进的成功实践归功于两个原因：一是基于我们长期中间业务开发

的基础上总结出来的经验和教训，二是CMM原则与我们团队和项目本身的特点的有效结合。

然而，由于我们初次应用CMM，还有许多需要改进的地方：

1、我们仅运用了CMM的基本原则，整个软件过程的管理基本是定性的。过程改进的趋势是

定量管理，必须采用合适的工具，如采用项目管理工具MSPROJECT控制项目进度，使用RATIONAL

ROSE对需求分析和系统设计进行辅助设计，可预测和监控整个过程性能和产品质量，及时纠正

偏差。

2、鉴于人手的问题，我们团队成员往往身兼设计、开发、测试、SQA数职，组织结构不合

理、人员分工不清显然制约过程改进的实施，我们最近打算成立一个独立于开发部的质量控制

部，分清设计、测试和质量保证的责任、界限和权限，使其在更高的层次上控制软件质量。

软件过程的改进是一个很大的课题和实践方向，在今后的工作中，我们将争取向CMM更高

的级别努力。

论软件开发平台的选择与应用

摘要：

我校教务管理系统是在根据我校原来的教务管理系统不再适应现在发展的要求而立项开发

的。目的是为教务工作有关部门提供优质、高效的业务管理和事务处理，建立完备、可靠和开

放性的教务管理系统。

我有幸参加了新的教务管理系统的开发，担任项目管理、系统分析与设计等工作。本文结

合工作的实际经历，简要讨论了软件开发平台的选择与应用。在软件开发平台的选择与应用过

程中，我们本着平台的开放性、分布性和平台无关性的原则，根据我校的具体情况，通过对目

前两种主流平台：J2EE和.NET的比较分析，和体系结构、应用平台的无缝集成、开发成本及易

开发性的思考与研究，选择了.NET作为开发平台。使用Microsoft全新的集成开发环境Visual

，采用、WebService、和XML等技术进行系统开发。

41

正文：

随着我校规模的不断扩大，计算机科学技术的进步，我校原来的教务管理系统已不适应现

在发展的要求。以前单机版的VFP教务管理软件，被分散的安装于全校的14个系部和教务处，

各系部之间、系部与教务处之间信息不能共享，而且对教学计划、教学考核等功能不完善或根

本不支持。教务处是学校主管教育教学工作的职能部门,也是学校领导在教学业务方面的参谋机

构。教务工作直接影响学校教育教学改革和教育教学质量。因此，学校决定由教务处立项重新

规划建设教务管理系统。整个系统包括教学计划子系统，教学资源子系统，网上选课子系统，

智能排课子系统，教学考核子系统，学生学籍子系统，学生成绩子系统，教学实践子系统，教

材管理子系统等。

我有幸参加了新的教务管理系统的开发，担任项目管理、系统分析与设计等工作。

由于我校分南北两个校区，教务处和14个系部分布较散，另外随着Internet的迅速发展，

部分信息需要通过网络向全校师生及外部用户发布，例如网上选课信息、学生基本信息及成绩

等。基于传统的C/S模式体系可维护性和发布性差等原因难以满足新系统的要求，有效的采用

基于B/S体系的Web应用能很好地解决这方面的问题。

基于互联网的应用要求软件平台具有开放性、分布性和平台无关性。从而相继出现了RPC、

COM和CORBA等技术，但这些技术在实际应用中存在着许多不足和局限.它们的特定协议难以通

过防火墙，因而不适应于Web上的应用开发。为了进一步开发基于Web的应用，出现了Sun公

司的J2EE和Microsoft公司的.NET两种主流的软件开发平台。

在J2EE和.NET两者之间进行选择时，我们曾举棋不定。随着面向对象技术的兴起，Java

语言应用的迅速发展，以Java为程序设计语言的J2EE具有平台无关性。同时J2EE已成为Web

应用开发的标准平台。以及它的相关技术EJB、JSP、JavaServlet等的迅速发展，J2EE平台

已成为Java技术企业级应用的理想平台。但我校原有的大部分操作系统、数据库和Web服务器

都是采用Microsoft的系列产品，并且在Microsoft系列产品的使用和开发方面积累了较丰富

的经验。.NET支持多种程序设计语言如：C++.NET、、、C＃等，实现了语言互

用性。而J2EE只能使用Java，这是J2EE所不及的。并且使得.NET的开发

较J2EE的易用性好。

在最后具体的软件开发平台与应用的技术方案选择时，我们采用了.NET开发平台。其原因

主要基于对开发平台选择原则如下的认真思考和研究。

一、体系结构方面的考虑

随着Internet的迅速发展，传统的C/S体系结构已显示出了它在异构的、分布式的网络环

境中的不足。可维护性和可安装性差、并且不利系统扩展。从而新的体系结构B/S模式迅速发

展了起来。B/S模式有利于系统的扩展性、维护性。

在校园网发展逐步完善的今天，考虑到教务管理系统安装、维护的方便和部分信息的向外

发布，以及传统的C/S模式技术的成熟性。我们采用了C/S和B/S相结合的模式。.NET开发平

台正是为进一步开发基于Web的应用而出现的，是一组用于建立Web服务器应用程序和Windows

桌面应用程序的软件组件。.NET支持多种编程语言，使各种语言可以自由地在整个.MET平台内

互用，很好的发挥各种语言的特性。例如：我们对C/S结构程序使用执行效率高的VC++.NET和

快速开发的，B/S结构程序使用.NET专门为Web应用定制的和C#。再加上功能

强大的集成开发环境，.NET为C/S和B/S相结合的模式提供了很好的解决

方案。

基于此原因，我们把系统的教学计划子系统，智能排课子系统，教学考核子系统，教学实

践子系统，教材管理子系统等设计为C/S结构，网上选课子系统，学生学籍子系统，学生成绩

子系统，教学资源子系统等设计为B/S结构。

二、应用平台的无缝集成性

由于我校使用的操作系统都是Microsoft的Windows系列，同时.NET是与Windows操作系

42

统紧密捆绑在一起，使得.NET在Windows上的应用开发更为容易。并且以前的数据库是VFP的。

考虑到数据的平稳过渡以及我们对数据库的熟悉程度，再加上.NET提供的数据访问组

件是对ADO的改进，分为三组：ODBC、OleDB、SqlClient。其中SqlClient是专门为SQLServer

设计的，性能明显优于其它的数据访问组件。我们在新系统的后台数据库服务器的选择上采用

了MicrosoftSQLServer2000。

选择Microsoft的操作系统Windows，数据库服务器SQLServer2000和开发平台.NET应用

平台，充分利用无缝集成平台的优势，使.NET应用开发更容易，运行更可靠、更安全。

这是J2EE所不及的。

三、节约开发成本

由于我校在以前的信息化建设过程中培养了一批经验较丰富的C++、VB、ASP等开发人员，

熟悉Windows上的开发，同时在数据库管理系统MicrosoftSQLServer上的设计与开发方面有

一定的经验。而在Java开发方面的经验相对不足。如果我们选择J2EE则意味着开发人员资源

的浪费，并且要重新培养Java开发人员，并且新培养的开发人员由于缺乏经验，很难保证开发

效率和质量。选择.NET，则我们的开发人员便能轻松的转变到C++.NET、、及

C#的开发当中来。再加上以前在Windows上的开发经验，最终有利于我们的开发速度加快，质

量提高，从而很好的节约了开发成本。

四、易开发性

就.NET开发平台的容易使用性来看，在如下几点得到了很好的体现。

1．.NET的重要部件使Web应用程序的开发和部署更为容易。.NET相对较新，它

拥有Java所缺乏的改进，例如，使开发者可以用比Java开发者在J2EE平台上更少的

代码来实现WebServices。在教务管理系统中，我们对学生成绩查询、学生网上选课和教学资

源调配等交互较多的逻辑模块，都设计成Webservice结构的中间组件。轻松的节省了花在用

户界面编程上的开发时间、同时Webservice完全可以在应用程序集成等场合下被重用。

2．数据访问组件较以前的ADO更方便的访问各种类型的关系数据库和非关系数据

库，获取本地和远程数据源，并对XML提供了强大的支持。这对以后的后台数据库的扩展也提

供了很好的支持。

3．为.NET提供了一个统一的集成开发环境及工具，大大提高了开发

者的效率;集成了多种语言支持;简化了服务器端的开发；提供了高效地创建和使用网络服务

的方法等等。

通过对上述四个主要方面的思考，所以我们选择了.NET平台作为开发与应用。

目前软件开发平台主要向Web的应用方向发展。由于Web的应用是基于分布和异构的网络

环境的，所以要求开发平台应具有开放性、分布性和平台无关性。现在流行的软件开发平台主

要有Microsoft的.NET和Sun的J2EE。在实际应用当中，我们具体选择那种方案应根据具体情

况而定，很多情况可能会综合使用两种开发平台。在适应技术发展的过程中，快速的跟上新技

术是必须的。

论软件开发平台的选择与应用

摘要：

我所在的单位是国内主要的商业银行之一，作为单位的主要技术骨干，2003年1月，我主

持了远期结售汇系统的开发，该系统是我行综合业务系统XX2000的一个子系统，在选择IBM的

VISUALAGEFORJAVA作为软件开发平台的过程中，我主要遵循了保证与原有系统的互用性；保

证开发人员快速而准确开发出应用程序；延长应用的生命力的原则。在选定了软件开发平台后，

我还采用了三层C/S的软件体系结构；利用CICS的SWHITCH组技术；使用标准﹑开放的规范等

措施，保证了远期结售汇系统的按计划完成并且顺利投产，确保了该系统的开放性﹑互用性﹑

可用性﹑先进性和稳定性，特别是我所选用的VISUALAGEFORJAVA开发平台和为了保证系统开

43

放性和先进性所采用的措施得到了领导和同事的一致认同和称赞。目前，但是，我也看到了近

期软件开发平台的主流是SUN公司的SUNONE和MICROSOFT的.。NET两大阵形，我认为，而软

件开发平台将朝着集成性﹑开放性﹑平台无关性的方向发展。

正文：

我所在的单位是国内主要的商业银行之一。众所周知，银行的业务存在一个“二八定理”：

即银行的百分之八十的利润是由百分之二十的客户所创造。为了更好的服务大客户，适应我国

对外贸易的蓬勃发展态势，促进我国对外贸易的发展，2003年1月，我行开展了远期结售汇业

务。

所谓的远期结售汇就是企业在取得中国外汇管理局的批准后，根据对外贸易的合同等凭证

与银行制定合约，银行根据制定合约当天的外汇汇率，通过远期汇率公式，计算出交割当天的

外汇汇率，并在那天以该汇率进行成交的外汇买卖业务。远期结售汇系统是我行综合业务系统

XX2000的一个子系统，它主要包括了联机部分﹑批量部分﹑清算部分和通兑部分，具有协议管

理﹑合约管理﹑报价管理﹑外汇敞口管理﹑帐务管理﹑数据拆分管理﹑报表管理﹑业务缩微和

事后监督等功能。

我作为单位的主要技术骨干之一，主持并参与了远期结售汇系统的项目计划，需求分析，

设计，编码和测试阶段的工作。在选择使用VISUALAGEFORJAVA作为软件开发平台的过程中我

主要采用了以下几个原则：

1、保证与原有系统的互用操作性和兼容性。由于远期结售汇是我行综合业务系统的一个子

系统，必须保证与原有业务系统的互用性，以确保我行业务的正常开展。我行以前的联机系统

一直都是使用IBM的VISUALGEN2.0来开发的，编译后生成COBOL程序，由于COBOL特别适合

用来表示商业逻辑，所以在我行的联机系统取得了很大的应用。我主要选择使用VISUALAGEFOR

JAVA开发平台的VISUALGEN部分的功能，程序编译后也是生成COBOL程序，确保了与原有系统

的互操作用性和兼容性。这样，以前开发的应用程序可以不经过任何修改，方便快捷地移植到

VISUALAGEFORJAVA开发平台上，这样既保护了以前的投资，又消除了因为移植而可能导致的

错误，为我行的安全生产打下了良好的基础。

2、保证开发人员快速而准确开发应用程序。首先，VISUALGEN2.0是我行一直使用的开发

平台，外汇部的开发人员能够用它快速而准确地开发出联机系统的应用程序，而VISUALAGEFOR

JAVA的VISUALGEN部分和VISUALGEN2.0只有很小的区别，只要进行很短时间的简单培训，开

发人员便可以快速而准确地得开发应用程序；其次，VISUALGEN2.0只支持IBM的OS/2操作系

统，而大部分的文档，办公软件和NOTES等都是安装在WINDOWS操作系统之上的，这样开发程

序的时候需要在两个操作系统之间不断地切换，不但浪费了开发人员的时间，降低开发效率，

还给开发工作带来了很多的不便，容易造成错误，比如开发人员在开发的过程中需要对照详细

设计文档的时候，需要切换到WINDOWS操作系统，当数据比较多的时候，切换的次数也多，这

样便浪费了开发时间，容易造成错误。而VISUALAGEFORJAVA则支持WINDOWS操作系统，大大

地方便了开发人员，提高了开发效率，减少了开发错误，得到了领导和开发人员的一致好评。

最后，VISUALAGEFORJAVA集成了很多软件管理的技术，增强了对项目的管理，比如它支持团

队开发，良好的团队开发管理为外汇部的开发工作带来了很大的方便，使得各个部分有条不紊

地进行。又比如它良好的版本管理功能，使得开发工作可以更加高效而准确地进行，极大地支

持了开发工作的顺利进行。

在选定了VISUALAGEFORJAVA作为远期结售汇系统的开发平台之后，我还采用了以下几个

措施来保证系统的开放性和先进性：

1、采用三层的C/S软件体系结构。根据银行联机系统对开放性﹑可用性和伸缩性的要求特

别高的特点，我采用了三层C/S软件体系结构，三层C/S软件体系结构是目前比较先进和流行

的软件体系结构，按照它所建立的分布式应用系统有很好的开放性﹑可用性﹑伸缩性和互用操

作性，很好地适应了银行应用系统的特点，其中：表示层我采用了我行自行研发的CITE字符终

端，由于字符终端在运行速递上比图形终端更快，很好地适应了我行对联机系统高速的要求；

44

中间层我采用了IBM的CICSTRANSATIONSERVER（以下简称CTS），用来连接CITE和数据层，

这样做的好处是屏蔽了通信，安全，线程管理等最重要而又最耗时的功能开发，使得开发人员

可以专注于应用逻辑的开发，缩短了开发周期，减少了开发，维护和集成费用，增加了开发的

成功率，极大地增强了系统的开放性，互用性和安全性；数据层采用了IBM的DB2UDB7.1数据

库，它的数据库连接池、，方便快捷的索引等众多的技术能很好地适应了强调吞吐量和速度的银

行系统。

2、利用CICS的SWITCH组技术。我行今年实现数据集中，全国设了南北两个数据中心，分

别位于XX和XXYY两地，而两个数据中心的数据传输显得尤其重要。比如我行的外汇报价管理

采用总行集中统一报价，各个地区再根据各自的业务量大小设置相应的优惠点数来进行远期结

售汇的外汇买卖。由于总行在北方中心，这样就涉及到两个数据中心通信的问题，为了实现两

个数据中心通信的负载均衡和容错，我采用了CICS的SWHITCH组技术，所谓的CICS的SWHITCH

组技术就是在南北中心之间架设一组的CICSTRANSATIONSERVERCTS，每个CICSTRANSATION

SERVERCTS都是相同的，起到了连接南北中心的作用，消除了单点故障。该SWHITCH组不但具

有开放性：每个CICSTRANSATIONSERVERCTS与具体的应用逻辑无关，意味着所有的应用逻辑

也可以共有该SWHITCH组。，而且具有先进性。：为了简化系统的设计，缩短通信时间，我采用

了简单的负载均衡算法，比如这次分配给第N个CICSTRANSATIONSERVERCTS，下次则分配给

第N+1个；为了实现更好的容错，我采用了当某个CICSTRANSATIONSERVERCTS失效的时候，

把它正在处理的事务转到另一个CICSTRANSATIONSERVERCTS，大大增强了系统的可用性。

3、使用标准﹑开放的规范。每个公司为了提高自己的竞争力，都有自己专用的标准和规范，

IBM公司也不例外，为了保证系统的开放性，我采取了一些与规范有关的措施：比如在开发的

过程中我要求开发人员尽量使用标准的SQL语句，以增加系统开放性；使用标准的通信协议

TCP/IP，以确保与其他子系统的通信。

由于采用了VISUALAGEFORJAVA开发平台和以上保证系统措施开放性和先进性的措施，远

期结售汇系统最后按照计划完成并顺利投产，不但取得了良好的社会效益和经济效益，而且我

选用的开发平台和采取的措施得到了领导和同事的认同和称赞。

在总结经验和不断学习新技术的同时，我也看到了近期软件开发平台的发展趋势和主要特

点：近期的软件开发平台朝着集成性﹑开放性﹑分布性和平台无关性发展，主流软件开发平台

是SUN公司的SUNONE和MICROSOFT公司的。.NET开发平台，并有两强并立之势。结合我行综

合业务系统的特点在充分分析比较了两个平台的优点缺点之后我发现：SUN的SUNONE开放平

台最大的优点是操作系统的可移植性，对于我行UNIX﹑OS/390和WINDOWS操作系统共存的局面

非常有利；缺点是只能用JAVA来开发程序，而JAVA对于商业逻辑的开发并不如COBOL那样简

单易用，而且我联机系统大多数都是用COBOL语言来开发或编译成COBOL程序，不能保护原有

的投资；MICROSOFT的。.NET的优点是开发﹑运行程序的成本更低，由于。.NET的语言是完全

中性的，所以可以使用COBOL程序来编程，保护了原有的投资，伸缩能力更强，互操作用性更

强，这些特性对于我行系统都特别重要；缺点是只能在WINDOWS操作系统下运行，对于我行多

操作系统并存的局面又很不利。为了适应软件开发平台的演变，我将在以后工作中不断地加强

学习，了解﹑掌握开发平台的知识，努力适应发展趋势，为我国的软件事业贡献自己的微薄力

量。

论软件开发平台的选择与应用

说明：

本文还存在一些问题，但作为嵌入式的文章，还是提供给大家参考。

批阅意见：

（1）文章内容真实可信。

（2）在讨论选型原则时，建议分原则讨论三个平台的优缺点，这样显得更有条理些。

（3）文章字数稍嫌偏少，可在讨论“特别是为了保持系统的开放性和先进性，采取过什么

45

措施？其效果如何？”时，多花费一些字数。

（4）如果可能，为了避免“项目太小”的嫌疑，可人为“放大”项目。

摘要：

2003年上半年，我作为某电子通信公司的软件开发人员，参与了一款基于嵌入式linux――

uclinux的手持式无线网络通信产品的软件开发工作。该产品提供为无线传输优化的TCP/IP协

议服务，具有自主组网、多跳路由的功能，集成语音通话、数据传输、实时图像传输等应用，

可广泛应用于野外通讯、数据采集等领域。在项目之始，我们根据综合考虑性能、功能、技术

可行性以及成本效益的原则，确定了以uclinux为软件开发平台，并在其应用过程中，通过积

极参与开源运动，解决了不少技术难题，保持了系统的先进和稳定性。在此过程中，我作为项

目的软件设计和实现人员之一，参与了选择软件平台的决策过程以及之后的具体应用。

正文：

我们说沙滩上建不起摩天大厦，这是强调地基对于建筑物的重要性，在软件开发过程中，

开发平台的作用就和地基类似，它对软件的性能、功能、质量、稳定性和可扩展性都有至关重

要的影响。因此，选择和应用合适的软件开发平台，是每个软件开发组织要面临的挑战之一。

作为一个嵌入式软件设计开发人员，2003年，我参与了一款手持式无线网络通信产品项目（下

面简称无线项目）的研发工作，同样也经历了一次这样的挑战。

由于嵌入式软件和硬件平台的密切关系，有必要先简单介绍一下无线项目的硬件情况，由

于有大量音频、视频编码运算，主处理器是美国AnalogDevice公司(下简称AD公司)的一款

DSP+RISC架构的数字信号处理器BF-21533，外扩32MSDRAM＋16MFlash，外围器件有彩色

LCD，键盘，音频、视频以及射频芯片等。应该说，硬件平台的功能还是比较强大的，因此我们

希望找到一个合适的软件开发平台，充分利用硬件资源，并且减少不必要的开发工作，使精力

能够集中到公司核心的业务上来。

我和另外一个软件设计人员经过和硬件设计人员的协商，初步拟定了三个候选方案，一个

是采用AD公司提供的VisualDSP++IDE，另一个是采用风河公司的Vxworks，再有一个是采用

迅速发展的嵌入式linux――uclinux。对这三个方案，我们分析其优缺点，综合考虑性能、功

能、技术可行性以及成本效益，最终选定了第三种方案。

首先来看看是AD公司提供的VisualDSP++IDE，这是一个集成开发环境，其中集成了一

个微内核VDK。作为硬件厂商提供的开发平台，它的优势非常明显，硬件支持度高，几乎不用

做任何移植，开发难度小，价格也是免费的，同时它提供的微内核VDK也具有体积小、实时性

高、硬件优化的优点，但是它的缺点也很明显，那就是功能弱，VDK只提供了简单的任务调度

功能，不支持界面显示和Flash文件系统，这意味着我们要充分发挥硬件的显示和存储功能，

就必须自己在VDK上开发相应的功能模块，这必将带来大量的额外工作，使得我们不能集中精

力在自己的优势上，因此我们首先淘汰了该方案。

再来看看基于风河公司的Vxworks的方案。作为一款优秀的商业性嵌入式RTOS，Vxworks

具有相当多的优点，功能强大，实时性好，稳定性高等，同时风河公司在其基础上开发出各种

板级支持包和大量的可复用的功能模块，开发者采用类似于构件编程的方式，可以快速开发出

高质量的产品。我们初步估计了一下，如果采用基于Vxworks的平台上进行开发，不仅LCD显

示和flash文件系统的开发工作可以省略，甚至如果采用通用音频、射频编码芯片，它们的驱

动也不用开发，整个软件项目的进度可以加快不少。但是，该方案对于无线项目来说，也有一

些不适应的地方，最大的问题是我们采用的处理器BF-21533由于推出时间不长，Vxworks对其

不支持，这意味着如果我们要使用采用Vxworks，就必须重新选择处理器，这增加了硬件设计

的风险；另外Vxworks价格不菲，除去开发工具的费用，它的按模块收费和形成产品后按件收

费的特点使得不仅开发费用较高，而且产品成本也会较高。我们经过多次讨论，并通过与下面

的uclinux方案比较，最终还是淘汰了此方案。

最后来看看基于uclinux的方案。uclinux是linux在嵌入式应用方面的一门分支，与

46

Vxworks相比，它同样具有功能强大，稳定性好等优点，具有我们所需要的界面显示和文件系

统等功能，缺点是实时性稍差，另外缺乏来自平台供应商的技术支持。但uclinux同时也具有

Vxworks所没有的优点，首先它是开放源代码的，可以对其源码进行局部修改以适应所开发软

件的需要，这一特点对于我们的多跳路由算法特别有用；其次它是免费的，这意味着所开发的

产品的成本将会较低。另外，AD公司为发挥BF-21533的强大性能，对uclinux进行了移植工

作，并且推出了相应的toolchain编译工具，这意味着无需重新选择处理器也能进行uclinux

平台上的开发。这些都最终促使我们选择了此方案。

在应用uclinux平台的过程中，为了充分利用linux的硬件平台无关的特点和加快软件开

发进度，我们将系统划分成硬件相关和硬件无关两部分，硬件无关的部分比如音频视频编码和

路由算法等在装有相同linux版本的PC机上开发，硬件相关的比如移植工作和各种driver的

开发则在具体硬件平台上开发。同时为了保持系统的先进性和开放性，我们采取积极参与开源

运动的方法，除了参与uclinux网站上将uclinux移植到BF-21533处理器的项目外，还将系统

中的一些非核心部分（比如音频和视频芯片的driver）分离出来，在开源网站上设立相应的项

目。在遇到技术难题时，我们除了在项目组内讨论外，同时也在开源世界中和来自全世界的开

发者讨论，寻求解决的方法，通过这种方式，我们成功解决了一些棘手的问题比如系统的boot

load，我们也将项目中发现的有关移植一些bug，即时反映给AD公司和相关开源项目，帮助完

善uclinux在BF-21533上的移植。同样，在我们设立的开源项目中虽然绝大部分都是自己的开

发人员在开发，但依然不时会收到热心人发来Email提出一些建议和指出一些bug，其中有一

些bug是我们测试时也没有发现的，这不仅提高了我们的软件质量，同时也让我们充分认识到

开源运动的力量。

目前，在嵌入式软件开发平台占主流的是以vxworks、wince为代表的商业产品，但以linux

为代表的开源运动也将这一潮流带到了嵌入式开发这一领域，显示了它的影响力，而且影响力

有越来越大的趋势，这种趋势的驱动力不仅来自linux内部，而且来自于外部厂商的支持，linux

2.6已经正式支持不少嵌入式处理器，vxworks开发商风河公司也已经丢弃了敌视linux的态度，

转而和redhat公司合作开发嵌入式linux平台。相信未来在嵌入式开发领域linux必将大有作

为。

论软件三层结构的设计

摘要：

我所在的单位是国内主要的商业银行之一，作为单位的主要技术骨干，2003年1月，我主

持了远期结售汇系统的开发，该系统是我行综合业务系统XX2000的一个子系统，由于银行系统

对安全性，可靠性，可用性和响应速度要求很高，我选择了三层C/S结构作为该系统的软件体

系结构，在详细的设计三层结构的过程中，我采用了字符终端为表示层，CICSTRANSATIONSERVER

为中间层，DB2UDB7.1为数据库层，并采用了CICSSWITCH组，并行批量的办法来解决设计

中遇到的问题，保证了远期结售汇系统按计划完成并顺利投产，我设计的软件三层结构得到了

同事和领导的一致认同和称赞。但是，我也看到在三层结构设计中存在一些不足之处：比如中

间层的负载均衡算法过于简单，容易造成系统负荷不均衡，并行批量设计不够严谨，容易造成

资源冲突等。

正文:

我所在的单位是国内主要的商业银行之一。众所周知，银行的业务存在一个“二八定理”：

即银行的百分之八十的利润是由百分之二十的客户所创造。为了更好地服务大客户，适应我国

对外贸易的蓬勃发展态势，促进我国对外贸易的发展，2003年1月，我行开展了远期结售汇业

务。

所谓的远期结售汇就是企业在取得中国外汇管理局的批准后，根据对外贸易的合同等凭证

与银行制定合约，银行根据制定合约当天的外汇汇率，通过远期汇率公式，计算出交割当天的

外汇汇率，并在那天以该汇率进行成交的外汇买卖业务。远期结售汇系统是我行综合业务系统

47

XX2000的一个子系统，它主要包括了联机部分﹑批量部分﹑清算部分和通兑部分，具有协议管

理﹑合约管理﹑报价管理﹑外汇敞口管理﹑帐务管理﹑数据拆分管理﹑报表管理﹑业务缩微和

事后监督等功能。

我作为单位的主要技术骨干之一，主持并参与了远期结售汇系统的项目计划﹑需求分析﹑

设计﹑编码和测试阶段的工作。由于银行系统对安全性，可靠性，可用性和响应速度要求很高，

我选择了三层C/S结构作为该系统的软件体系结构，下面，我将分层次详细介绍三层C/S软件

体系结构的设计过程。：

1﹑表示层为字符终端。我行以前一直使用IBM的VISUALGEN2.0附带的图形用户终端来开

发终端程序，但在使用的过程中，分行的业务人员反映响应速度比较慢，特别是业务量比较大

的时候，速度更是难以忍受。为此，我行最近自行开发了一套字符终端CITE，它采用VISUALBASIC

作为开发语言，具有响应速度快，交互能力强，易学，编码快和功能强大的特点，在权衡了两

者的优点和缺点之后，我决定选择字符终端CITE作为表示层。

2﹑中间层为CICSTRANSATIONSERVER(CTS)。首先，我行与IBM公司一直保持着良好的合

作关系，而我行的大部分技术和设备都采用了IBM公司的产品，其中包括了大型机，由于CICS

在IBM的大型机上得到了广泛的应用，并在我行取得了很大的成功，为了保证与原来系统的兼

容和互用性，我采用了IBM的CTS作为中间层，连接表示层和数据库层，简化系统的设计，使

开发人员可以专注于表示逻辑和业务逻辑的开发工作，缩短了开发周期，减少开发费用和维护

费用，提高了开发的成功率；其次，对于中间层的业务逻辑，我采用了我行一直使用的VISUALAGE

FORJAVA作为开发平台，它具有简单易用的特点，特别适合开发业务逻辑，可以使开发人员快

速而准确地开发出业务逻辑，确保了远期结售汇系统的顺利完成；

最后，由于采用了CTS，确保了系统的开放性和互操作性，保证了与我行原来的联机系统

和其他系统的兼容，保护了我行的原有投资。

3﹑数据层为DB2UDB7.1.由于DB2在大型事务处理系统中表现出色，我行一直使用DB2作

为事务处理的数据库，并取得了很大的成功，在DB2数据库的使用方面积累了自己独到的经验

和大量的人才，为了延续技术的连续性和保护原有投资，我选择了DB2UDB7.1作为数据层。

但是，在设计的过程中我也遇到了一些困难，我主要采取了以下的办法来解决：

1﹑CICSSWITCH组。众所周知，银行系统对于安全性，可靠性，可用性和响应速度要求很

高，特别是我行最近进行了数据集中，全国只设两个数据中心，分别在XX和YY两个地方，这

样对以上的要求就更高了，为了保障我行的安全生产，我采用了CTSSWITCH组技术，所谓的

CICSSWITCH组，就是一组相同的CTS，每个CTS上都有相同的业务逻辑，共同作为中间层，消

除了单点故障，确保了系统的高度可用性。为了简化系统的设计和缩短通讯时间，我采用了简

单的负载均衡算法，比如这次分配给第N个CTS，下次则分配给第N+1个CTS,当到了最后一个，

就从第一个开始；为了更好地实现容错，我采用了当第N个CTS失效的时候，把它正在处理的

业务转到第N+1个上面继续处理，这样大大增加了系统的可用性，可以为客户提供更好的服务；

此外，我还采用了数据库连接池的技术，大大缩短了数据库处理速度，提高了系统运行速度。

2﹑并行批量。银行系统每天都要处理大量的数据，为了确保白天的业务能顺利进行，有一

部分的帐务处理，比如一部分内部户帐务处理，或者代理收费业务和总帐与分户帐核对等功能

就要到晚上批量地去处理，但是，这部分数据在数据集中之后就显得更加庞大，我行以前采用

串行提交批量作业的办法，远远不能适应数据中心亿万级的数据处理要求，在与其他技术骨干

讨论之后，并经过充分的论证和试验，我决定采用了并行批量的技术，所谓的并行批量，就是

在利用IBM的OPC（TivoliOperations,PlanningandControl）技术，把批量作业按时间和

业务处理先后顺序由操作员统一提交的基础上，再利用DB2的PARTITION技术，把几个地区分

到一个PATITON里面分别处理，大大提高了银行系统的数据处理速度，确保了远期结售汇系统

三层结构的先进性。在并行批量的设计过程中，我考虑到批量作业有可能因为网络错误或者资

源冲突等原因而中断，这样在编写批量程序和作业的时候必须支持断点重提，以确保生产的顺

利进行。

48

由于我软件三层结构设计得当，并采取了有效的措施去解决设计中遇到的问题，远期结售

汇系统最后按照计划完成并顺利投产，不但保证了系统的开发性开放性﹑可用性和互用性，取

得了良好的社会效益和经济效益，而且我的软件三层结构设计得到了同事和领导的一致认同与

称赞，为我行以后系统的开发打下了良好的基础。

在总结经验的同时，我也看到了我在软件三层结构设计中的不足之处：

首先，负载算法过于简单，容易造成系统的负荷不均衡：由于每个业务的处理时间不一样，

有的可能差距很远，简单的顺序加一负载分配算法就容易造成负载不均衡，但是如果专门设置

一个分配器，则增加了一次网络通讯，使得系统的速度变慢，这样对响应速度要求很高的银行

系统来说也是不可行的，于是我决定采用基于统计的分配算法，即在收到请求的时候，根据预

先设定的权值，按概率，直接分配给CTS。

;其次，由于批量作业顺序设计得不过够严谨等各种原因，容易造成资源冲突：在远期结售

汇系统运行了一段时间之后，数据中心的维护人员发现了，系统有的时候会出现资源冲突现象，

在经过仔细的分析之后，我发现，由于每天各个业务的业务量大小不一样，顺序的两个作业之

间访问同一个表的时候便会产生资源冲突，另外，在OPC作业运行的过程中，操作员提交的其

他作业与这个时间的OPC作业产生也有可能产生资源冲突。对于第一种情况，可以在不影响业

务的情况下调整作业顺序或者对于查询作业运用DB2的共享锁的技术，而第二种情况则要制定

规范，规定在某时间断内不允许提交某些作业来解决。为了更好地开展系统分析工作，我将在

以后的工作实践中不断地学习，提高自身素质和能力，为我国的软件事业贡献自己的微薄力量。

论软件三层结构的设计

摘要

随着市场的建立和发展，卫生行业面临了很多问题，一些制约卫生事业发展的矛盾和问题

日益显现，因此，国家卫生部要求各医院采用信息化管理。前不久，我所在的部门承担了了一

个医院管理系统的设计和开发，医院希望以此来转变医院现有的运行机制，提高服务质量。该

系统除了目前常见的结费系统、电子病历外，还包括门诊医生工作站、住院医生工作站、护士

工作站等分系统。考虑到需要通过Intranet实现功能，并有部分的Internet功能，本项目平

台最后采用了Java平台。我在项目中主要负责项目的的前期规划，即选择合适的开发方案，并

建立部分的数据流，在系统实施过程中推动其顺利前进。此系统开发成功后投入运行，获得医

院相关工作人员的好评。

正文

前不久，我所在的部门承担了了一个医院管理系统的设计和开发，医院希望以此来转变医

院现有的运行机制，提高服务质量。客户是一个市级医院，医院很早就开始从事信息化管理，

但主要是针对结费这一块，后来，对其进行了改进，加入对病人电子病历的管理和采集，这样

当病人二次就诊时，可以很容易地得到病人的既往病史。但随着系统的运行，院方希望对现有

系统进行改进，为了更好得为病人服务，医院考虑加入一些其它的分系统，比如门诊医生工作

站、住院医生工作站和护士工作站等等。因此我所在的部门承接了该HIS的开发，开发的成果

是一个典型的Java技术在Intranet上的应用。

在开发前期，首先要设计出详细的系统功能规范，这一部分所花费的时间很少，因为卫生

部在2002年曾经颁发了一个有关医院管理系统功能规范的通知，我们参考了该规范，很快确定

了各分系统以及每个分系统的的基本功能。但在选择合适的系统平台上有一番讨论，考虑到医

院原有系统在某些地方运行良好，是否有必要将原有系统淘汰重新设计，另外新的分系统到底

采用何种平台结构也是需要考虑的问题。

医院原有的结费系统和电子病历系统数据流向范围比较固定，主要集中在交费处和挂号处，

一旦引入了新的系统，必然要将数据流向医院的各个部门。医院的Intranet已经实施，因此首

先考虑采用B/S架构体系，旧系统的数据模型尽可能保留。在系统的软件平台上，我们考虑使

用Java平台，可以让数据在整个系统安全、有效地流动；另外现在也有很多的HIS系统可供我

49

们参考，虽然往往是单机版的系统，但其中的数据模型有很好的参考价值。医院的现有网络系

统和操作系统多种多样，这就要求我们选择的软件平台必须具有开放性、平台无关性。而在不

同的系统上安装相应的Java客户端虚拟机并不困难，最后，在项目组的讨论和征求客户意见下，

项目组采用了此方案。

在项目中，我们这样设计Java架构系统，将系统分为三层：

（1）表示层采用Jsp实现页面输出，这也是用户直接访问层，表示层接受来自网络浏览器

的HTTP请求，然后返回给客户端浏览器可以显示的HTML页面；

（2）中间件层用Java实现对数据库的访问，考虑到数据的分布特点，我们使用了数据库

连接池技术；

（3）数据库层用SQLServer实现数据库的管理和存储过程。

JSP以其执行的高效性和使用的方便性，已成为近年来大家首选的因特网开发技术，JSP是

一种页面开发技术，它以Java为其服务器端语言，结合JavaScript作为其客户端语言，能方

便地实现页面的表示。选择Jsp作为前台语言，是考虑到它的平台无关性，能够兼容其他的操

作系统和数据。利用Jsp可以将HTML文件很方便地发送到客户端Web浏览器，同时也可以支持

一些非HTML格式的文档发送。我们在网站中的用户层页面设计中，广泛地参考了现有的一些成

功案例，在节约设计和开发的费用的同时也得到了用户的认可。比起单纯的Servlet技术，Jsp

在页面元素上也更为丰富，在这里，我们为今后客户页面定制做了部分尝试，设计了一个比较

简单的模块，用户可以通过选择控件来动态生成页面提供打印，当然在这部分我们设计中，可

提供的数据库字段是固定有限的，灵活性没有很好体现。

我们大量工作主要放在中间件层，由于系统中的医生工作站分系统是主要部分，因此数据

库的负载成为一个不得不考虑的问题。综合考虑，我们决定采用数据连接池技术，因为基本上

每个医生都对应一个客户终端，无论是病人资料的查讯或录入，或者医嘱的处理，都涉及到对

数据库的频繁读写，服务器对于数据连接的频繁打开和关闭必然导致性能下降。一方面，我们

预先考虑数据库的连接量，在系统初始阶段建立相应的存储空间，当数据库连接打开和关闭时

都对该连接池进行处理；另一面，我们也使用了高速缓存技术，对某些固定的SQL查讯结果，

例如药品查讯、药性禁忌等，将结果采用缓存存储，以加快对数据库的访问，降低了服务器端

的负载，提高性能。值得一提的是，为了尽可能得避免纠纷，医院要求采用医生签名制度，我

们设计了电子签名，采用加密算法保证各环节产生数据的有关人员不能抵赖。

数据库层我们选择了SQLServer，程序员比较熟悉此平台的开发和设计。在前期，我们到

医院做了大量的走访工作，了解整个数据流，同时广泛参考现有的系统，虽然对医院行业不是

很熟悉，但数据层开发遇到的问题的并不是很大。在概要设计阶段，我们使用了一些计算机辅

助开发工具，这也加快了详细设计的进程。比如使用了Sybase的PowerDesigner工具，在概要

设计中规划了E-R图和各个分系统以及分系统之间的数据流图，然后让工具直接生成后台数据

库中的基本表结构，大大提高了开发效率。

整个项目实施完成后，医院相关工作人员反映良好，但其中也暴露出了一些问题，值得改

进。

首先，用JSP编程时容易导致系统信息的扩散。如果有人恶意攻击服务器，程序执行将出

现异常。这时，就会在页面上打印出相应的错误信息。这些信息会暴露出这台服务器的路径信

息。这个漏洞往往会被人利用，程序员对此也一头雾水，下一步我们考虑从服务器入手，采用

通用的异常说明界面，解决该问题。

其次，在设计上，可以使用更多的辅助开发工具和建模工具，比如RationalRose，可以

利用它的代码自动生成功能，来大大提高开发速度；在用户界面定制方面，我们希望通过不断

的实践，加强其灵活性，尽可能把可供选择的字段扩大到整个数据库。

最后，大量使用Java技术，势必对服务器的负载过大，在今后的开发中，除了现有的数据

库连接池和缓存技术，我们考虑使用更多的数据库脚本来替代部分Java代码，来高速实现逻辑，

50

相较而言，数据库脚本的执行速度较有优势，结合结果缓存，应该对服务器的性能有较大的提

高。

上面是我在今后的系统设计和开发中需要注意和加以改进的地方，也是我今后应该努力的

方向。

论软件三层结构的设计

摘要

随着中间件与Web技术的发展，三层或多层分布式应用体系越来越流行。在这种体系结构

中，将应用功能分成表示层、功能层和数据层三部分。

本人在去年参加了一个备件流程管理项目的开发，在此项目中担任需求分析和结构设计等

工作。结合需求分析结果和该单位的实际情况，在该项目中我们采用C/S和B/S的混合模式，

客户端使用的是Delphi和FrontPage进行开发，中间件我们采用的是COM+，使用Delphi进行

开发，后台使用SQLServer数据库。本文详细描述三层结构的设计过程，重点讨论中间件的设

计过程和在设计实施过程中碰到的一些问题以及解决的方法，文章最后说明了采用三层结构带

来的效果，以及可以改进的地方。

正文

2003年8月，我参加了某钢铁公司备件采购项目，主要负责该项目的需求分析和结构设计等工作。

该钢铁公司原先的备件采购全部是人工完成，手续复杂，办事效率低下，更重要的是无法提供

及时有效的信息供企业领导参考。该公司一方面需要通过此项目来缩短采购时间，提高办事效

率，另一方面该公司已经建成比较完善的局域网，需要在内部网上公开采购结果，并要做出统

计分析，供全公司员工和领导查询参考。该项目涉及部门主要包括该集团公司下的仓储公司，

供应公司，招标公司，劳企部等。

根据我们做出的需求分析以及各种体系结构的优缺点，我决定采用C/S和B/S混合的体系

结构来开发。对于仓储公司等部门的需求，需要对数据进行更新处理，采用C/S结构可以更快

更好的开发且数据处理速度更快，可以更好的满足要求。对于领导和员工的查询需求，我们采

用B/S模式。采取这样的结构可以很好的满足用户需求，且容易开发和维护。由于都是在windows

平台上使用，因此在开发工具的选择上，我们使用Delphi来开发仓储公司等部门的客户端和中

间件，使用FrontPage来开发网页，连接在其内部网上提供查询服务。中间件我们采用的是COM+，

进行逻辑处理，数据层使用SQLServer。

以下详细介绍三层结构的功能分配和物理分布，描述三层结构设计的过程，讨论在设计实

施过程中碰到的一些问题以及解决的方法，文章最后说明采用三层结构带来的效果，以及可以

改进的地方。

对于客户端，B/S结构仅提供查询功能，使用InternetExplorer，各个子公司、二级部门

都可以通过内部网使用。C/S结构提供日常操作和管理界面，承担着整个系统的数据录入及数

据维护工作，使用Delphi开发，它是系统数据的入口，使用频繁，安装在仓储公司、供应公司

等单位；中间件和数据库以及Web服务器都放在集团公司的计算机中心，便于维护管理。中间

件负责根据客户端要求从数据库中取得数据，并在进行处理后提交到客户端显示；后台使用SQL

Server数据库，数据集中在数据库服务器进行管理，方便数据管理和分析，保证数据安全。其

物理分布如下图：

51

对于C/S和B/S结构，我们分别使用不同的工具来开发客户端。C/S结构的客户端我们使

用的是Delphi来开发，对于B/S的客户端我们使用的开发工具是FrontPage，采用VBScript

脚本语言来开发。客户端只用来显示结果，所有的逻辑处理我们全部放在中间件中。在客户端

只需引用中间件提供的接口即可，这样一个方面使逻辑处理集中，便于维护，另一个方面只向

客户端提供处理后的数据，可以减少网络流量，加快反应速度。

对于中间件的设计是我们工作的重点。Microsoft的MTS/COM+不但能够稳定地执行应用系

统的企业对象，以服务客户端的请求，更能够提供在分布式环境和异质数据库之间保护数据的

事务管理能力。这让分布式应用系统能够稳定、可靠地在复杂的环境中正确地执行。再加上

MTS/COM+能够有效地利用各种系统资源，增加中介软件的执行效率，因此使用MTS/COM+作为中

介软件的应用系统能够提供合理的执行效率。

经过考虑，我们决定使用COM+作为中间件来开发。如何设计出合理的中间件关系到项目的

成败。根据项目的特点，我决定根据不同的部门以及各个部门的需求来开发COM+组件。因为各

个部门有不同的数据表，中间件主要处理的是每个部门各自数据处理和内部网上的查询以及统

计分析处理，所以为每个部门设计了数个COM+组件，分别用来处理数据维护，查询操作以及统

计分析工作。Delphi提供了MTS的向导可以帮助程序员开发COM+应用系统，程序员可以直接在

COM+数据模块中放入ADOExpress组件来存取数据库，提高了程序员的工作效率。

但在开发过程中，也出现了不少的问题。比如在仓储公司维护更新工作的设计中，使用到

多个数据库表，有些程序员直接使用MTS/COM+数据模块，然后在MTS/COM+数据模块中加入

TADOConnection连接数据库，再分别使用TADOQuery/TADOTable和TDataSetProvider组件连

接到这些数据表。

从功能上说没有什么问题，但我发现这样设计存在一些问题。其中最大的问题就是执行效

率的问题。这可以从数个不同的角度来看，首先程序员把所有的数据存取组件放在一个MTS/COM+

数据模块中，因此当客户端建立这个MTS/COM+数据模块时需要花费许多的激活时间。第二个问

题是如果客户端只需要使用其中的一个数据表的数据，那么客户端仍然需要花费多余的时间建

立不相关的对象。最后，对于MTS/COM+提供的Pooling机制而言，这样设计系统架构也是不好

的，程序员应该尽量利用MTS/COM+提供的数据库连接Pooling的功能。因此最好是把每一个

TADOConnection的连接放在不同的MTS/COM+数据模块中，因为这些数据表都位于一个相同的数

据库中。

为了解决这些问题，我重新设计了这个架构。为充分利用MTS/COM+的数据库连接Pooling

功能，并且避免客户端建立不必要的对象，我使用多个独立的MTS/COM+数据模块，其中分别放

入TADOCOnnection、TADOQuery和TDataSetProvdier以连接到不同的数据表。这样的设计虽然

比直接使用单一的MTS/COM+数据模块来得麻烦，但是无论在执行效率、系统的延展性以及资源

客户端

客户端

客户端

客户端

客户端

客户端

Web服务器

数据库

中间件

52

的共享性上都比单一的MTS/COM+数据模块好得多。

为了更好的设计开发中间件，我对使用COM+做中间件来开发应用系统需要注意的一些问题

做了总结：

1、对于客户端而言，应该尽早取得需要使用的MTS/COM+对象，并且在最后使用完毕之后

再释放取得MTS/COM+对象。

2、避免激活不必要的事务Context。对于MTS/COM+对象而言，应该让事务管理越晚发生

越好，并且在执行完必要的工作之后立刻调用SetComplete/SetAbort和

EnableCommit/DisableCommit方法释放占据的资源。尽量把相关的MTS/COM+对象放在同一个套

件组件中，尽量减少不同套件组件之间MTS/COM+对象的调用。

3、在MTS中使用STA线程模型的对象，在COM+中使用Neutral/Rental线程模型的对象。

4、尽量利用MTS/COM+对于数据库的Pooling，而不要使用主从架构的方式来利用数据库

Pooling。通过使用这些方法在开发过程中我们大大改进了系统的执行效率。

数据层使用一台数据库服务器，通过企业局域，分布在仓储公司等单位的工作站利用客户

端软件进行数据录入及维护工作，在各个二级分厂、单位的客户端都可以通过内部网进行查询

浏览。我们采用的是SQLServer数据库，功能强大，使用方便，完全满足系统的要求。

最后通过项目组成员的努力，我们按期完成了任务。采用这样的体系结构，完全满足要求，

并且安全可靠、容易维护、扩展方便、结构模块化、易操作。经过用户一段时间的使用，基本

上没有什么问题。在后期的维护中，我们对中间件和客户端分别做了少许修改，但二者之间没

有互相影响，这些充分体现出多层结构的优越性。当然在其中也存在一些问题。比如在系统的

执行效率和延展性上，给人的感觉是多层应用系统的执行速度有点慢，还有组件的设计上还存

在些问题。这些问题在了解COM+的设计方法和系统需求后才能更好的解决。

XML在网上银行中的应用

摘要：

网上银行是指在Internet上提供银行服务，即银行的客户无须到银行柜台办理业务，可以

在家庭、办公室等能够连入Internet的任何一处，登录到银行的网站进行交易。这是一种崭新

的银行运营模式，具有方便快捷、成本低廉、不受时间地点限制等优点。

本文通过论述的项目是某银行行网上银行系统的1.0版本到2.0版本的升级和改造，论述了

XML在Internet中的应用。,我有幸参加了这个项目,承担在该项目中担当了部分的分析与设计

的部分任务。

系统的1.0版本存在诸如交易超时、作业比较慢、不能满足客户个性化、技术相对落后等缺

点。在2.0该项目版本的设计和开发过程中，我们基于JAVA技术，采用J2EE构架，使用应用了XML

作为数据交换的标准，。在后台，基于业务数据建立了XML数据库，存放签约客户的历史数据，

同时在Web服务端，我们也应用了XML，读取XML数据库中的数据，同时给客户提供了“个性化”

的服务。这些技术的采用，解决了1.0版中存在的问题。但是，因为XML是一种新的标准，有些

地方还不是很完善，在J2EE架构下，如何使用XML是我们应该一直关注的问题，本文就该问题也

有所论述。

正文：

2002年3月，我参与了的银行某网上银行系统的升级和改造工作。该系统采取总行、分行两

层结构，总行网银中心连接各一级分行，提供信息服务、客户服务、帐务查询和实时交易等功

能。网银中心与客户通过Internet相连，与分行业务主机通过城市综合网相连。网上银行的客

户使用Browser(浏览器)通过Internet连接到网银中心并且发起网上交易请求；网银中心验证后

将交易请求返回；分行业务主机完成交易处理，返回处理结果给网银中心；网银中心对交易结

果进行再处理后返回相应的信息给客户。

原有系统无论从业务上,还是从技术上通过运行一段时间,存在这很多问题,客户和业务人

53

员意见也很多,诸如部分时间交易超时,作业务比较慢,还有无法满足客户的某些个性化的要求,

基于ASP+VB的应用也不合时宜,这些都是系统需要改造的原因.

新系统整个网上银行应用的开发，全部基于JAVA技术，数据的交换采用标准的XML协议，应

用开发采用WebsphereStudio+VisualAgeforJava等工具进行，采用符合国际J2EE标准，系

统采用了业界领先的中间件产品(BEAWebLogic)建立网上网上银行系统的交易平台，该系统的

主控程序应用JSP和servlet编写,很好地发挥了多线程机制，大大提高了系统的性能；主要业务

逻辑采用EJB技术实现，模块化结构利于新业务的开发与布部署；数据库访问符合JDBC标准，利

用WebLogic的Jdbcpool提高了数据库访问的效率。

在这里主要谈谈XML在该项目中的应用.

XML是一种具有描述数据功能的语言，它十分适合作为知识表示语言或作为组件及

文件格式的表示方法。它还可以让数据在不同的来源中，根据通用的语法规则来处理。而

Java则是用于Internet、适合于分布式环境、提供了一个跨平台的语言。XML和Java相结合主要

原因是基于XML的语法提供了一种灵活的、标准的、健壮的Java编程方案。

在该项目中这里，我们统一了XML的报文标准，列举了XML实例,规定了XML头部，XML根节点，

XML二级节点及具体的报文子段。

在接口中的XML报文遵循如下约定：XML头部如实例所示，不得改变；XML根结点、二级节点

如实例，不得改变；报文必须是包含‘0’作为结束符的字符串；接口格式说明中的字段即指

实例中具体的报文字段这一级。对于接口文件，规定所有发送、接收的文件名均为调用方确定，

均带文件路径。

接下来谈谈原有系统存在的问题：

因网上银行业务的特殊性,Web客户端需要连接多个业务种类，多种数据库,跨平台,跨数据

库,环节多,这就是原有系统交易缓慢的重要原因之一,而且随着可提供新业务的种类的增多,问

题暴露的更加明显;其次Web客户端的查询往往对各个应用系统的服务器的负载产生影响,影响

了其他业务;同样，对Web客户无法提供个性化服务,B2B,B2C提供的信息和帐页千篇一律,根本无

法按照其要求定制;客户端无法进行一些运算,一些简单的比如”“还款试算”等还要通过后台

应用服务器来进行运算,加重了主机负担.

在具体应用中，比如查询某客户的所有业务是困难的，这具体体现在，如果某签约客户想

查询或执行信用卡的历史交易，必须向后台相应的业务的数据库服务器提交数据查询请求，而

此时的后台服务器又往往又是银行的实时业务处理机，在高峰期正忙，并且历史交易的数据往

往由于年终转换的原因，存在于其它数据表甚至其他数据库和服务器，都给查询带来了困难，

只能作到有限的查询，或提供的数据项有限，或甚至根本无法提供，比如有关储蓄业务的有关

明细帐务已接近3000万条，在高峰期间在其中取几条记录是困难的。另一方面，由于网上银行

涉及多个对私和对公的业务，甚至包括资金的清算，一笔交易要跨越多个业务的服务器，这又

存在跨不同种类的数据库的问题．

所以，将历史数据分离及整和是必然的，我们也曾考虑过将数据进行归类，建立一个类似＂

历史数据服务器＂（或是数据仓库）上，但该历史数据仍需建立在某种数据库上如INFORMIX-ONS，

仅作到了数据的集合，没有治本，投入大，费时．

所以为了解决原有系统中存在的问题，我们在新系统中我们建立专用的转换服务器，作为＂缓

存＂，目的仅是为了＂脱离＂原有的依赖，减少联机处理，这样，有关历史的交易就不用分别

直接连到所需业务的数据库或服务器，我们采用XML格式进行中间的转换。这种所谓的XML数据

库其实就是文档的集合．我们用了一台IBMPCSERVER来存储XML数据，具体就是用UNIX下的文

件系统来存储和检索。将部分数据转换成XML文件，包括所有以已签约的客户的历史明细帐及全

部卡号（未来新开户时就不用在去信用卡主机进行校验了），同时XML文件的存储按文件系统，

并对B2B和B2C进行了分类。

这里我们使用了InformixWebDataBlade工具，按照我们自己定义的数据结构进行了批量

54

转换，基本与网银后台数据库服务器的数据库表结构相符，这样做的目的是为了便于更新，且

对原有有关调用数据库的数据逻辑改动不大，将数据转换成了XML文件格式，对于其他非

Informmix数据库的数据，我们则采取了先将数据倒入导入至Informix数据库，再进行这种转换。

有关当日的账务，我们在日终将当日发生的流水帐进转换，存入了数据库，作为了历史交

易的追加。在这里InformixWebDataBlade可以通过一个简单的SQL接口产生动态的XML数据和

文档，用于日终更新．这样实际就上在数据库与应用服务器之间采用XML作为信息缓存。

建好了XML数据库，那么又如何来应用呢？接下来我们谈谈这方面的问题。

首先读取XML数据。具体的方法为：一个页面通过服务器端对象与XML数据源相连，将信息

转换成数据抽象，接着用JSP元素显示数据。这样我们就使用了XSLT转换程序转换XML，．在这

里应用到的XSLT技术,XSLT是W3C小组制定的一个转换语言规范，它可以用来将XML数据转换成

HTML、PDF或其它XML格式。具体过程就是首先定义了XSLT模板，然后进行转换，除了模板需要

定义外，这个解析的过程是还是比较容易的。其实XSLT与XML的关系，就好象SQL与表格化的数

据一样。只是在JSP中，需用scriptlet或自定义标签中编程激活一个XSLT处理器来进行转换。

在XML数据源上使用一个转换程序，或者是抽取数据或者是创建新的格式，这个转换程序可以使

用许多不同的机制来实现并且通过自定义标签来访问它。

接下来XML应用就是使同样的数据可以以不同的浏览方式出现在浏览器中，而这些数据并不

需要从再次从Web服务器上下载。其实这类应用的就是早期的Web上的另我们头疼的”动态表

格”。

对于B2B的用户，可根据企业要求的，制定不同的往来对帐单，约十多种，以满足其对帐的

需要，对其所属职工的集体办理的有关代发工资，缴存公积金，还个人贷款的有关帐务，都有

良好的支持，在单位就可了解到，随时的变动，并可随时打印，不用再跑银行进行询问，取帐

页．将来甚至直接提供信息化较高的企业XML数据,这也是未来交换数据的标准,也是应用XML的

美好憧憬.对于B2C的个人用户，可根据其所开办的业务的不同，来对其提供＂个性化＂的服务，

可提供该人名下的所有帐户的信息，如存贷款信息，各种缴费的信息，并可根据其需求方便的

进行排序，筛选，组和，打印．甚至可以自己定制格式，改变了以往显示单一，多业务罗列，

操作复杂的状况。Java提供的JSP为多种基于Web的用户产生基于XML的标记语言的问题，也就是

我们要达到的＂个性化＂界面．

在具体应用中,我们是用从JSP页面产生的XML,XML在Web界面层的应用得益于JSP技术的发

展。同样,也有两种方法,一种直接将XML数据源集成到JSP的界面中去的方法是，将XML加载到

JavaBeans组件中，然后在JSP中直接引用这些JavaBeans组件。最大好处是使我们的程序代码集

中在一个地方（对Java技术而言，一般是指在“类”中），清晰，易于管理和修改。另一种方

法是直接将XML数据转换成Web显示内容的另一种方法是使用XSL和XSLT，将XML数据映射成HTML

（或WML等）的逻辑由XSL样式表（XSLStyleSheet）来定义。样式表描述了每个特定XML数据实

体应该怎样转换成界面数据实体（如HTML表格、内联标记等），采用一套自定义的JSP标记并

引用某个XSLT处理程序,也就是前面提到的模板.

通过比较综合了这两种方案方法,我们作出了选择,选择了后者,XSLT方案的伸缩性要好一些，而

且具有更好的可管理性。在这种情形下，我们的转换逻辑是编写在一个XSL样式表中，而不是在

Java代码中。这意味着当需要修改界面时，大多数情况下只是编辑样式表或者HTML，代码不受

影响,不涉及程序编译的问题,业务人员经过简单的培训就可以修改，这对我们很重要。

在网银项目中由于XML的应用，解决了我们许多历史问题，也使银行的B2B和B2C业务进行了

有效的整合，更好的为客户服务。

尽管XML是未来网上数据格式的标准，可在具体应用中还存在许多问题：

尽管我们由于网上银行所要求的数据格式不是很多，可建立XSLT的模板并不是一件容易的

事，不是很好写,主要是由于表中嵌套太多，尽管是文本形式，阅读和修改很实际上是复杂的。

另外，这种基于文件系统的后台历史数据按XML存储的方案还有待探讨，尽管XML的确与数

55

据库有相似之处，但对于索引、安全机制、数据完整性等特性是不具备的。在实际应用中，我

们目前由于签约的客户的数量不是很多，不足万人，尽管我们只应用了一台服务器来存储数据，

目前还没有什么问题，但随着签约客户的增多，不知会不会有问题。看来XML还是要发展，想取

代数据库还是需要一段时间的。

还有，我们未将XML封装进JavaBean,却将部分应用逻辑由XSLT来实现，这种方法是否合适

还有待探讨，从某种程度来说是不符合惯例的，不仅仅是Web服务器负载的问题，它给编程人员

和维护人员带来的问题有些还是不可预计的。

我想，未来XML会成为数据交换的标准的，我们也考虑逐步将我们现有的数据转换成XML格

式。，接下来，我们还将在这些数据的基础上，建立一个统一的，用XML实现通用WEB报表的系

统，在这方面已有了成功的案例。

现在，大部分数据库支持XML格式的数据查询和转换，包括SQLServer2000,ORACLE,

IBMDB2等大型关系数据库，估计会越来越多，我想以上问题也会很快得到解决的。

论XML技术在Internet平台上的应用

摘要

2002年10月，我参与了一个三层在线商城的项目开发，该项目整合了来自不同商家的信息，

方便在线用户的查询和购买。

在该项目中，我担任系统分析的工作。在分析设计过程中，我借鉴了XML成熟的技术，采用

Java语言，整个系统由三层组成。在数据层，对于不同的数据库，最后都以XML数据的形式来实

行数据间的转换和处理。在业务逻辑层，在联机会话的持续时间内，用户的帐户数据在内存中

以XMLDOM形式表示，在表示层，所以给用户的信息首先都封装成XML数据，然后用服务器或者

客户机附带的XSLT转换，根据浏览器的性能将XML数据转换为HTML在前端显示。

在设计过程中，如设计XML的各个基本元素，我应用域分析的方法，在采用XMLDOM形式

的时候，分析比较了其他的形式，在将XML转换为HTML的设计中，引用了XSLT。

正文

随着Internet信息技术的发展，我所在的公司准备开发一个网上商城，这样各个商家就可

以把自己的产品信息在这个网上商城中发布，并且提供了在线购买。也就是开发一个电子商务

平台，在这个平台上，整合了来自不同商家的信息，方便在线用户的查询和购买。有点类似现

实中的商城，为各个商家提供地方，方便消费者购买。

本人有幸成为这个项目的系统分析员之一，参与了这个系统的设计，并且对系统中的关键

实现技术也进行了一一验证。整个网上商城系统由三层组成。在数据层，由于各个商家自己有

着不同的数据库来存储自己信息，为了实行信息在同一平台上的共享和处理，我们采用XML数

据的形式来实行数据间的转换和处理。在业务逻辑层，在联机会话的持续时间内，用户的账户

数据在内存中以XMLDOM形式表示，在表示层，所有给用户的信息首先都封装成XML数据，然

后用服务器或者客户机附带的XSLT转换，根据浏览器的性能将XML数据转换为HTML在前端显

示。

在数据层，我们面临的第一个的问题就是如何统一认识将要采用的XML数据的元素。刚开始是由

一个人来定义XML数据的元素，但是后来发现，这样定义处理的XML元素很难获得别人的认同，

并且对于不同的商家，所定义的XML元素不具有代表性。于是，在争取到领导的支持后，把以前

的XML元素设计推倒重来，而且借鉴了国外关于类似设计所采用的域分析的方法，该方法就是一

个用于确定网上商城这个域的术语，范围，共性和变性的过程。就这样为了寻求一个统一的XML

元素的定义，我们成立了一个小组来进行的网上商城的域分析，这个小组有商家代表，数据库

设计员，参与多个项目的有丰富经验的程序员和一个专门指导该组域分析的大学专家组成。

在小组会议的开始，我们首先达成一个共识，那就是需要采用一直标准术语来避免交流中

产生的误解。于是，我们在刚开始的一周内先确定的关于网上商城的一下公用术语，比如store

56

（商城），shop（店面），ware（商品）等，作为XML最基本的元素。

在小组讨论的过程中，有成员建议对于域分析，分多个阶段进行，每个阶段提交域分析报

告，比如第一阶段的域分析报告主要为标准术语以及各个商家信息共性和可变性的表格，第二

阶段的域分析报告，对于域分析中的商家可变性的东西进行详细说明。我们采纳这个建议，获

得了很好的效果。就这样，通过3周的域分析，我们小组最终提交一份完整的关于XML网上商城

元素的详细表格，由于这些XML元素是由各个部分和商家代表讨论处理的，所以很快被整个项目

组成员所接收，并且这些XML元素在后来的开发中证明是非常完整，能够清楚地反映数据的结构，

大大提高了整个的系统的开发效率。

在业务逻辑层，由于所有数据库的信息都被转换为XML数据结构，所以在处理数据库信息的时候

还必须对XML数据进行XML语法分析，并且将分析出来的结果送往程序。在这儿我们考虑采用XML

DOM（文档对象模型）来保存这些语法分析出来的XML数据。比如在联机会话的持续时间内，一

个用户的帐户数据首先从传统的关系型数据库中读取出来，转换为XML数据结果，并且通过一个

XML语法分析器，将XML数据转换成为DOM对象保存在内存中，程序通过Java的DOMAPI访问这些

对象。在这儿为了更好地选择处理XML的技术和方法，我还比较其他两种分析XML数据并且保存

的方法。

比较了几种方法，发现DOM有个缺点就是当它保持的数据非常多的时候，将大量占用内存的

存储空间。但是，使用DOMAPI也有一个明显的好处就是简单，它可以通过Java程序直接使用一

些方法调用DOM树上的数据。为此在设计的时候，尽可能地重复调用已经存储在内存中的DOM对

象上面的数据，避免对于相同的数据有多个DOM对象存在。在编码过程中面临的问题不是很多，

关键是让程序员熟悉DOMAPI的各种调用方法。

在表示层，考虑到将大量的运算负荷分布在用户端，既用户可以根据自己的需求选择或者

制订不同的应用程序以处理数据，我们设计把所有给用户的信息首先都封装成XML数据，然后

用服务器或者客户机附带的的XSLT转换，根据浏览器的性能将XML数据转换为HTML在前端显

示。这样的话，服务器只需要准备一次的Web内容，尽可能完善，准确地将数据封装到XML文

件中，而XML的自解释性可以使得用户端在接收到XML文件的同时也理解数据的逻辑结构和含

义，再通过转换程序，XML可转换为用户所需要的个性的多样的HTML显示方式。在设计中我们

所选取的XSLT是一种用于操作XML文档的高级语言，就像SQL是操作关系表的高级语言一样。

一个XSLT规范本事就是一个XML文档，我们通过它的规范，描述出各个用户可以选择的各

个HTML显示模板，这样客户端程序只需选择好模板，再加上接收到的XML数据文件，就可以方

便地生成自己个性化的HTML文件，并且在浏览器中显示出来。当然在开发中遇到了不少问题，

首先由于XSLT是一门起点比较高的语言，也比较烦琐，掌握起来比较慢，使得对程序员的要求

比较高。这样导致使用XSLT语言编写的HTML文件的模板过于冗长，作为设计师我一方面是希

望模板程序尽可能地包含HTML页面所有的功能和美观，一方面又希望模板程序尽可能地短少，

简洁，便于修改。

为了达到两种选择之间的平衡，以达到最佳效果，我对于基本模板的设计，采用有经验的

程序员进行设计，并且要求尽可能多地写全文档，并且频繁地开展小组会议，对页面设计和美

工人员详细讲述模板各个部分和功能。

在Internet平台上采用XML技术，明显的效果之一是对于不同数据库的支持，通过将各种

数据转换为XML文件，可以实行了数据间的转换，共享和处理。效果二是支持了用户的个性化

服务，支持用户在不同的客户端可以个性地选择显示界面。

由于HTML在许多复杂的Web应用中遇到了问题，为了彻底解决这些问题，必须采用功能强

大的XML来代替HTML作为Web页面的书写工具，而XML的广泛使用，必定能够推动Web的不断

发展，开创Web应用的新时代。对于XML技术在Internet平台上的应用，我更关注它的扩展性，

既让XML包含更加丰富更完整的数据信息，目前公司所接触的首先是软件模型的交换和模型信

息的保存，打算在XMI（XMLMetadataIntercharge）展开工作。XMI作为一种试图通过XML语

言为程序员和其他用户提供一种交换元数据信息的标准途径，是作为MDA模型驱动的模型交换

57

的基础，是非常具有意义的工作。

图书馆网络应用体系安全设计

摘要：

某某大学图书馆从85年引进日本富士通的管理系统开始,历经近20年的信息化建设后，逐步

形成了拥有一定硬件规模、软件资源和一批专业技术人才的现代化图书馆。而自从我校进入

“211”以来，建立数字化的图书馆就成为了我们工作的重中之重。我校数字化建设的主要内容

是建立基于千兆主干网络的、提供多种网络服务的网络应用体系。项目建设完成后，我馆成为

该省规模最大的开放式的数字化文献提供和建设中心，为本省的科技、文化、教育事业的发展

提供了强大的资源保障。

2001年3月，我参加了某大学数字图书馆建设，担任技术部主管职务，负责理解学校和省教

委对该项目的要求，根据技术先进、成本适中、充分满足要求为原则，进行应用需求分析，对

整个网络进行设计，提出设计方案。由于该项目规模比较大，提供的服务比较多，作为校园网

络的中心和提供网络服务的核心部门，我馆图书馆的许多业务需要在网上展开，各种特色服务

所用的平台也是五花八门。这对安全方面的设计提出的较高的要求。我们通过采用保障Internet

接入的安全、保证干路畅通和合理划分子网、保证软件系统的安全、健全管理机制等措施来设

计图书馆网络。这种切合实际、低成本、高技术的设计方案实施后的网络，其安全性大大加强

了，同时网络的性能并未受到太多的影响。

正文：

2001年3月，我参加了某某大学数字211建设图书馆数字化建设部分（分为第一、第二、第三期

工程）。第二期工程总额5500万元。该工程建设项目分为网络部分、软件部分以及资源建设部

分。该项目的目标是，将地处该城市的东、西、南、北端的各分校区和总校区的网络联连接成

为一个畅通的宽带、高速、高性能的校园网；建立一个文献信息中心，能为读者提供电子期刊

服务、图书书目数据服务、图书光盘点播、视频点播服务，并且能够拥有部分自己的特色数据

资源；建立一个网络中心提供Web服务、邮件服务、全校的办公自动化服务，它既是全校的应用

服务中心、公共数据存储中心，又是全校网络的管理中心。项目从实现的功能、设备配置的先

进性、网络带宽的规模看，该项目要达到国内一流、省内第一的水平。项目建成后，该数字图

书馆能承担全省的文献检索与开发的重任。我在该项目中担任技术部主管，其任务是充分理解

学校和省教委对该项目的要求，根据技术先进、成本适中、充分满足要求为原则，提出和需求

分析书和项目计划书；监督光纤的铺设和楼宇布线；设备的货到验收；网络调试（交换机调试、

地址分配、访问控制配置、设备网管模块的配置、网络管理平台的配置）；网络应用系统的建

立；数据库的采购；建立特色的数字化资源等等。进行应用需求分析，对整个网络进行设计，

提出设计方案。

由于该项目规模比较大，提供的服务比较多，各种特色服务所用的平台也是五花八门。同

时，影响网络安全的因数比较多，通常有人的因数﹑自然因数﹑病毒因数。如果对这些主要因

数防范不得力，将影响网络硬件﹑网络数据传输﹑数据服务器的安全。因此对其安全设计，单

一的技术或者设备保护难以保证本校网络的安全，效果往往不理想；所以我们采用多层次的防

护体系来保证网络的畅通和网络数据的安全。我们根据业务数据的流动历经的重要环节，来提

出具体的安全方案。

1保证接入的安全

俗话说病从口入，同样一些常有的攻击往往来自外网，同时使用图书馆所购买的外文资料

比如WebScience﹑EBSCO等数据库需要访问外网；同时，外网的授权用户需要能够访问我们的

数据。所以必须保证接入部分的稳定与安全。在外网联接上，我们租用2条光纤线路（100M）分

别接入中国电信和XXX大学，使用Cisco的7500系列路由器接入，然后用一台Sunspark操作系统

为Solaris的服务器做防火墙将外网和内网划分开；同时用其做策略路由服务器，使用校园网内

的用户可以快捷的访问电信网络和教育网络的资源。在外部用户访问上，我们首先用Sunspark

58

服务器防火墙进行IP地址过滤掉非法的IP地址，然后通过用户名+密码模式登陆，才能通过防火

墙访问我们内部资源。

2保证干路畅通和划分子网

网络干路是指各楼的骨干网、骨干网汇接形成的交换中心及联结Internet的接入线路。它

的不畅通必然导致大规模的网络瘫痪，外部付费用户访问不到内部资源，这将造成极坏的影响。

在光纤干路上我们采用光纤连接主校区的各大教学楼、南院校区和XXX校区，主干路使用3

对光纤做冗余。由于其它分校区离主校区比较远，光纤连入费用较高，我们采用拨号接入的方

式联结。我们采用3ComRAS1500作为拨号服务器，分配32个校内电话号码给该服务器，用户只需

要拨这32个其中一个，通过认证后，就可以动态分配一个校内的合法IP来访问校内的资源。在

干路上，安全的隐患往往来自非技术因素，由于本市修建大学城，道路施工比较多，我们的光

纤被人为的挖断;由于，某路段起火烧掉部分光纤。对于这种情况，我们采取紧急修理，租用吉

通的2M微波通讯线路和将策略路由指向电信线路的办法来保障网路的畅通。

由于本校应用点多，地理位置也十分分散，各大单位为相对独立的机构，所以需要进行子网划

分以便管理。我们使用两台3Com的CB9000中心交换机连接各教学单位过来的光纤，并且将华中

分配的16个C类地址分成为32个VLan。子网的划分使安全性得到了很大的提高，同时各单位的网

络独立的虚网。同时，每个教学单位指定专人负责网络地址的分配，这样盗用IP地址的情况大

大的减少了。

我们采用3Com的Transcend作为网管平台，实施对网络干路和各个子网的监控和进行网络

优化。当网络有人恶意下载资源和蠕虫病毒群发邮件时，我们可以立即找出攻击源而进行相应

的措施。

3保证软件系统的安全

由于操作系统是软件系统的基础，所以，保护好操作系统是必须的，对于Windows系统（提

供CNKI和VIP镜像等服务）保护，我们主要采取取消Guest帐号﹑取消不必要的服务（如远程注

册表操作）安装诺顿防火墙和相应的杀毒软件﹑定时查看有无异常的程序运行等方式来保证其

安全。对于Linux或者Unix(提供邮件﹑网络计费﹑主页﹑论坛等服务)，我们关闭许多不必要的

端口﹑定时对系统打包升级等措施来保证其安全。

对于数据库系统的保护，主要集中在保证数据的完整性﹑正确性和安全性方面。在数据存

储介质方面，我们采用磁盘阵列﹑NAS、San结合RAID5(无独立校验磁盘的奇偶校验磁盘阵列)

方式存储数据。

4健全的管理机制

管理安全数字图书馆的工作状态在很大程度上取决于是否有良好的管理机制。如果制度合

理、管理得当、执行得力就能有效的预防和控制安全事故的发生。反之,则会引发各种安全隐患。

我们规定工作人员每日必须检查服务器的日志，通过日志可以清楚的看到有无外来人员登

陆服务器，并且做了何种修改。对重要的数据服务器，每日必须做异地数据备份。同时管理员

的密码必须达到一定的长度并且每周建议修改一次。

一般而言，网络安全是网络服务效率的保障。没有了数据安全，网络服务成为无源之水；

没有网络系统的安全，网络服务将成为无本之木。当然没有效率的网络传输是得不偿失的。所

以，我们要合理的规划好网络及软、硬件的合理利用。

在接入上，由于全校有3，000多台机器也要通过该做防火墙的服务器接入Internet，这将

给该服务器造成较大的负担，同时数据传输量大时，该服务器处理速度相对将成为瓶颈。我们

采取单独使用两台Spark主机做代理服务器，代理服务器同时启动用户认证服务，由于代理服务

器的缓存保证了出校的流量大大减少，同时认证功能使得非法用户无法登陆网络。这样的冗余

设计使得网络的安全性能和效能得到了大幅度的提高。

在子网划分上，连接各教学单位过来的光纤的2台中心3ComCB9000交换机之间用两根光纤

作一个串口，这样跨子网的访问无需通过交换能力不强的Cisco路由器7500，子网间传输数据的

59

瓶颈问题消失了。

在数据存储上，由于我们提供CNKI和VIP等服务，这些服务器的访问量、存储的数据量都十

分庞大，单个的数据检索查询都会占据大量的CPU时间。我们使用SAN和NAS存储大量的数据，当

用户提出一个检索的申请时，检索服务将在服务器上运行，当用户提出一个下载的服务时候，

下载的服务由SAN和NAS去完成，这样使得SAN和NAS的效能比磁盘阵列要高。由于SAN和NAS都可

以做RAID1~5,所以数据安全性能比普通的硬盘要高。采用新技术和冗余使得我们的网络服务效

率和安全性能得到了大幅度的提高。

网络的安全管理不是一个硬件和软件的引进就能得到大幅度的提高的；他是一个长期的、动态

的过程。本项目的网络系统还有许多问题，一次网络发生了大规模的网络风暴，从子交换机扩

散到中心交换机，主机与主机之间的数据传输丢包率达到了75%几乎是不通了，最后我们发现一

个施工的单位将一根漏电的线缆搭在网路上。但是为什么会造成跨虚网的网络风暴，从技术上

我们无法解决，只能是严格检测各子网和主干网络是否达到屏蔽的要求，并且将电路和网路尽

量的分开。

论计算机网络的安全性设计

摘要：

我在一家证券公司信息技术部门工作，我公司在9798年建成了与各公司总部及营业网点的

企业网络，并已先后在企业网络上建设了交易系统、办公系统，并开通了互联网应用。因将对

安全要求不同、安全可信度不同的各种应用运行在同一网络上，给黑客的攻击、病毒的蔓延打

开了方便之门，给我公司的网络安全造成了很大的威胁。作为信息技术中心部门经理及项目负

责人，我在资金投入不足的前提下，充分利用现有条件及成熟技术，对公司网络进行了全面细

致的规划，使改造后的网络安全级别大大提高。本文将介绍我在网络安全性和保密性方面采取

的一些方法和策略，主要包括网络安全隔离、网络边界安全控制、交叉病毒防治、集中网络安

全管理等，同时分析了因投入资金有限，我公司网络目前仍存在的一些问题或不足，并提出了

一些改进办法。

正文：

我在一家证券公司工作，公司在98年就建成了与各公司总部及营业网点的企业网络，随着

公司业务的不断拓展，公司先后建设了集中报盘系统、网上交易系统、OA、财务系统、总部监

控系统等等，为了保证各业务正常开展，特别是为了确保证券交易业务的实时高效，公司已于

2002年已经将中心至各营业部的通讯链路由初建时的主链路64K的DDN和备链路33。.3KPSTN，

扩建成主链路为2M光缆作为主链路和256K的DDN作为备链路，实现了通讯线路及关键网络设备

的冗余，较好地保证了公司业务的需要。并且随着网上交易系统的建设和网上办公的需要，公

司企业网与互联网之间建起了桥梁。改造前，应用系统在用户认证及加密传输方面采取了相应

措施，如集中交易在进行身份确认后信息采用了Blowfish128位加密技术，网上交易运用了对

称加密和非对称加密相结合的方法进行身份认证和数据传输加密，但公司办公系统、交易系统、

互联网应用之间没有进行安全隔离，只在互联网入口安装了软件放防火墙，给黑客的攻击、病

毒的蔓延打开了方便之门。

作为公司信息技术中心运保部经理，系统安全一直是困扰着我的话题，特别是随着公司集中报

盘系统、网上交易系统的建设，以及网上办公需要，网络安全系统的建设更显得犹为迫切。但

公司考虑到目前证券市场疲软，竞争十分激励，公司暂时不打算投入较大资金来建设安全系统。

作为部门经理及项目负责人，我在投入较少资金的前提下，在公司可以容忍的风险级别和可以

接受的成本之间作出取舍，充分利用现有的条件及成熟的技术，对公司网络进行了全面细致的

规划，并且最大限度地发挥管理功效，尽可能全方位地提高公司的网络安全水平。。在网络安

全性和保密性方面，我采用了以下技术和策略：1、将企业网划分成交易网、办公网、互联网应

用网，进行网络隔离。2、在网络边界采取防火墙、存取控制、并口隔离等技术进行安全控制。

3、运用多版本的防病毒软件对系统交叉杀毒。4、制定公司网络安全管理办法，进行网络安全

60

集中管理。

一、网络安全隔离

为了达到网络互相不受影响，最好的办法是将网络进行隔离，网络隔离分为物理隔离和逻

辑隔离，我主要是从系统的重要程度即安全等级考虑划分合理的网络安全边界，使不同安全级

别的网络或信息媒介不能相互访问或有控制的进行访问。针对我公司的网络系统的应用特点把

公司证券交易系统、业务办公系统之间进行逻辑分离，划分成交易子网和办公子网，将互联网

应用与公司企业网之间进行物理隔离，形成独立的互联网应用子网。公司中心与各营业部之间

建有两套网络，中心路由器是两台CISCO7206，营业部是两台CISCO2612，一条通讯链路是联通

2M光缆，一条是电信256KDDN，改造前两套链路一主一备，为了充分利用网络资源实现两条链

路的均衡负载和线路故障的无缝切换，子网的划分采用VLAN技术，并将中心端和营业部端的路

由器分别采用两组虚拟地址的HSRP技术，一组地址对应交易子网，一组地址对应办公网络，形

成两个逻辑上独立的网络。改造后原来一机两用（需要同时访问两个网络信息）的工作站采用

双硬盘网络隔离卡的方法，在确保隔离的前提下实现双网数据的安全交换。

二、网络边界安全控制

网络安全的需求一方面要保护网络不受破坏，另一方面要确保网络服务的可用性。将网络

进行隔离后，为了能够满足网络内的授权用户对相关子网资源的访问，保证各业务不受影响，

在各子网之间采取了不同的存取策略。

（1））、互联网与交易子网之间：为了保证网上交易业务的顺利进行，互联网与交易子网

之间建有通讯链路，为了保证交易网不受互联网影响，在互联网与中心的专线之间安装了

NETSCREEN委托防火墙，并进行了以下控制：a)、只允许股民访问网上交易相应地址的相应端口。

b）、只允许信息技术中心的维护机地址PING、TELNET委托机和路由器。c）、只允许行情发送

机向行情主站上传行情的端口。d）、其他服务及端口全部禁止。并且在互联网和交易网之间还

采用了SSL并口隔离，进一步保证了交易网的安全。

（2））、交易网和办公网之间：对于办公网与交易网之间的互访，采用CISCO2501路由器

进行双向控制或有限访问原则，使受控的子网或主机访问权限和信息流向能得到有效控制，主

要采用的策略主要是对具体IP进行IP地址与MAC地址的绑定。

（3））、办公子网与互联网之间：采用东大NETEYE硬件防火墙，并进行了以下控制：a)、

允许中心上网的地址访问互联网的任何地址和任何端口。b）、允许股民访问网上交易备份地址

的8002端口。c）、允许短消息访问公司邮件110、25端口，访问电信SP的8001端口。d）、其他

的都禁止。

三、病毒防治

网络病毒往往令人防不胜防，尽管对网络进行网络隔离，但网络资源互防以及人为原因，

病毒防治依然不可掉以轻心。因此，采用适当的措施防治病毒，是进一步提高网络安全的重要

手段。我分别在不同子网上部署了能够统一分发、集中管理的熊猫卫士网络病毒软件，同时购

置单机版KV3000和瑞星防病毒软件进行交叉杀毒；限制共享目录及读写权限的使用；限制网上

软件的下载和禁用盗版软件；软盘数据和邮件先查毒后使用等等。

四、集中网络安全管理

网络安全的保障不能仅仅依靠安全设备，更重要的是要制定一个全方位的安全策略，在全网范

围内实现统一集中的安全管理。在网络安全改造完成后，我制订了公司网络安全管理办法，主

要措施如下：1）、多人负责原则，每一项与安全有关的活动，都必须有两人或多人在场，并且

一人操作一人复核。2）、任期有限原则，技术人员不定期地轮岗。3）、职责分离原则，非本

岗人员不得掌握用户、密码等关键信息。4）、营业部进行网络改造的方案必须经过中心网络安

全小组审批后方可实施。5）、跨网互访须绑定IP及MAC地址，增加互访机器时须经过中心批准

并进行存取控制设置后方可运行。6）、及时升级系统软件补丁，关闭不用的服务和端口等等。

保障网络安全性与网络服务效率永远是一对矛盾，在计算机应用日益广泛的今天，要想网

61

络系统安全可靠，势必会增加许多控制措施和安全设备，从而会或多或少的影响使用效率和使

用方便性。如，我在互联网和交易网之间设置了放防火墙的前提下再进行了SSL并口隔离后，网

上交易股民访问交易网的并发人数达到一定量时就会出现延时现象，为了保证股民交易及时快

捷，我只好采用增加通讯机的办法来消除交易延时问题。

在进行网络改造后，我公司的网络安全级别大大提高。但我知道安全永远只是一个相对概

念，随着计算机技术不断进步，有关网络安全的讨论也将是一个无休无止的话题。审视改造后

的网络系统，我认为尽管我们在Internet的入口处部署了防火墙，有效阻挡了来自外部的攻击，

并且将网络分成三个子网较减少了各系统之间的影响，但在公司内部的访问控制以及入侵检测

等方面仍显不足，如果将来公司投资允许，我将在以下几方面加强：

1、在中心与营业部之间建立防火墙，通过访问控制防止通过内网的非法入侵。

2、中心与营业部之间的通讯，采用通过IP层加密构建证券公司虚拟专用网（VPN），保证

证券公司总部与各营业部之间信息传输的机密性。

3、建立由入侵监测系统、网络扫描系统、系统扫描系统、信息审计系统、集中身份识别系

统等构成的安全控制中心，作为公司网络监控预警系统。

论新技术的引进

摘要：

根据国家税务总局对税务系统内所有系统进行集成与整合的需求，我所在的开发单位组织

了全国金税工程防伪税控系统网络版的升级开发工作。该项目工程浩大，要求在具有严格的安

全、可靠性能的基础上，将基于DOS操作系统、Foxpro数据库的原单机版防伪税控子系统集成到

基于网络的、大型数据库的“集中存储、分布操作”的分布式系统中来，并实现与基于AIX等操

作系统和Oracle数据库的稽核协查等其他应用系统的数据共享和互操作。在项目中，我担任项

目主管，主要负责系统规划和组织实施工作。我在将近一年的可行性研究、需求分析、系统研

发与试点工作中，通过引进面向对象设计方法、采用B/S/S三层体系结构、利用群集实现负载平

衡等新技术，使该项目取得了圆满成功，受到了用户的一致好评。但是现在看来，由于新技术

的使用，怎样实现软件开发公司对新技术的渗透、怎样开发自主产权的中间件等问题，需要我

们在今后系统开发中做进一步探索。

正文：

2003年元月，我作为项目主管，有幸参与了全国税务系统金税工程防伪税控系统的升级开发工

作。防伪税控系统主要由基于增值税发票的企业开票、企业发行、报税、认证、发票发售等五

大子系统组成，系统组成模块如图1所示。具体流程是：企业在当地税务机关通过企业发行系统

取得用于开具增值税发票的相关设备（金税卡与IC卡）和权限，再到发票发售系统领取增值税

发票，通过企业开票系统开出发票后产生发票明细和申报纳税数据存入IC卡中，然后、企业持

IC卡到税务机关由报税系统进行报税、并将取得的可抵扣的发票数据通过认证系统进行认证后，

经过Internet上传到税务机关，所有数据经由税务机关处理后，传递到其它系统进行处理。系

统要求具有严格的安全、可靠性能，必须建成基于网络的，分布式实时数据库处理系统，达到

数据共享的目的。在此次开发过程中，我特别强调在认真细致的需求分析的基础上，最大限度

地引进新技术新方法的思想。

一、采用面向对象分析方法

防伪税控系统网络的应用将极为广泛，涉及全国所的有税局和一般纳税人企业，具有基于

增值税发票的开票、认证、报税、传递等业务操作，面对如此复杂的系统，怎样从中理出头绪

来，最大限度满足用户要求要，实现整个开发流程的“无缝”连接，需求分析是最重要的环节。

我在认真研究和分析旧单机版开发文档后，提出采用面向对象的开发方法。系统的主要业务范

围是增值税专用发票的防伪与税控，通过对整个系统流程的分析，我抽象出“发票、操作员、

安全卡”等类，从类出发，建立对象，再通过对象类之间的继承、聚合关系、消息和关联，分

别建立开票、认证、开票、企业发行等子系统和共用的系统管理等模块，并通过操作员类中权

62

限属性实现各子系统的权限控制。通过面向对象分析方法，不仅提高了系统的开发效率，而且

提高了软件的复用性和可维护性。

在工具的选择过程中，我们选择了现在十分流行的系统Rational系统系列工具，包括

RationalRose、Rup、Soda和RequisitePro等。特别的，从防伪税控系统的对于增值税发票的

防伪和税控功能可以看出，整个系统具有很长的生命周期，必须面对税务系统因为经济发展而

出现的多变的需求变更，并且，又必须服务于税务系统其它的如征收管理、稽核协查等应用系

统。所以，要求系统具有很好的可维护性、可扩展性。而公司在原有单机版的升级上，因为没

有统一的、规范的开发文档而吃尽了苦头。所以，我决定采用RequisitePro作为我们现在和未

来的系统需求管理工具。我们在对经过详细的用户调查后，按照我们的基本理解写成了基本需

求，交给用户进行评审和补充，再形成正式的需求录入到RequisitePro中去，并记录需求的变

化情况、需求之间的依赖关系，实现需求的全面管理。公司决策层在认真听我的汇报后，表示

了很高的兴趣并给出支持，使我更加增强引入新技术进行开发的决心。

但是，新技术并不意味着是最好的或是最适合的。在引用新技术中，我特别注意它的负面。

面向对象分析方法虽然有效地表达和描述了现实世界，但有时也会忽略外在的表层的需求，有

些关键需求要等到用户使用后才会提出，然而等到用户使用后再维护是不现实的，作为原型开

发模型中的原型也是收集用户需求，描述与解释需求的一类相当有效的方法工具。在分析过程

中，为了更好让用户了解我们的系统，更完整提出需求，我沿用了公司熟用的原型开发方法。

通过利用Access开发出系统原型，让用户试用，取得很好的效果。所以在新技术引进过程中，

我们熟悉的优秀的开发思想与方法不能丢，这是我们要特别注意的地方。

二、采用B/S/S三层软件体系统结构

瘦客户端设计表示层。进行系统设计时，采用客户/服务器（C/S）模式还是采用浏览器/应用服

务器/数据库服务器的（B/S/S）模式，成为我们开发小组成员争论的焦点。我认为，采用哪种

系统体系结构相当重要，决策时，不但要考虑系统运行成本，还要考虑系统运行的稳定性、可

靠性、可维护性以及业务需求变动时的可扩展性。新系统将所有数据集中到市级税务机关（参

看图1），如果将业务处理逻辑分散到客户端或数据库服务器，虽然可以低成本运行，但是，我

们分析得到，同一时刻，区县级税务机关和企业到服务器的连接可能达到30-1000，在发达地区

可能更多，这显然击中了C/S模式的要害，并且，税务系统的需求经常变更，所以，我们决定采

用应用服务器集中处理实现业务逻辑。事实证明，这个决策是正确的。新系统在沿海五省四市

试运行时，不仅稳定、可靠，易维护，而且，客户端采用IE浏览器，受到了维护人员和广大操

作者的好评。

业务层引入WEBLOGIC应用服务器。众所周知，WEBLOGIC是用于开发、集成、部署和管理大

型分布式WEB应用、网络应用和数据库应用的Java应用服务器。可以说，采用Weblogic的主要理

由有：首先是税务现有应用系统的异构的数据库平台如用于（如用于CTAIS征管系统的Sybase、

稽核协查系统的Oracle、其它的SQLServer）;再有，对多种操作系统的支持，包括NT系列、AIX、

Sco等;并且，税务的系统需求经常变化，比如在我们的开发过程中，因为国家税务总局推出“一

窗式”管理，税局要求我们的报税系统有向征管系统传出某种格式数据的功能，我们利用

WEBLOGIC对XML的支持，很快地解决了这个需求。总之，这要求系统具有很好的可移植性和可伸

缩性，应用服务器能使程序员从常规设计中脱离出来，集中精力组织和优化业务逻辑。我特别

注意了服务器的选型，主要从开发效率、可复用性、可伸缩性和可扩展性等几个方面考虑。

三、利用工作站实现负载平衡

企业将取得的可抵扣的增值税发票经过认证系统认证后，形成加密的认证数据，经过互联

网传到税局的外网WEB服务器，再由WEB服务器传到内网的应用服务器进行解密和税局再认证。

对于一个市级税局，这种发票数据可能非常宠大，如果由应用服务器信中进行解密，很显然，

时间上是不充许的，并且，可能造成应用服务器的死机。我提出采用解密工作站队列处理解密

工作，让应用服务器统一分配各工作站的工作量。这样，大大地减少了应用服务器的工作量。

综上所述，由于采用了面向对象的系统分析方法，B/S/S系统体系结构、解密工作站实现负

63

载平衡等新技术，提高了整个系统的开发效率和质量，使新系统按计划完成，且具有很好的安

全性、可靠性、可维护性、可扩展性和外部接口。但是，由于新技术的采用，也使我们产生了

一些新的问题。

怎样让员工理解、支持和掌握新技术。引进新技术，将打破开发人员习惯的开发方法和程

序设计方式，这种习惯的打破，往往要付出更多的精力和时间，如果靠权力或压力来解决只能

是一种表面现象，我认为，关键是要营造一种引进新技术进行软件开发的文化氛围，让软件公

司开发人员学习并引进新技术到我们的开发中来形成一种习惯，怎样营造这种氛围，是我们管

理领导层常思考的问题。

怎样开发自主产权的中间件。我们的应用服务器采用的是BEA公司的WEBLOGIC中间件，虽然，

它提高了我们新系统的开发效率和安全性和平台无关性，但是，也大大提高了我们的软件开发

成本。中间件在我国具有很大的市场和利润空间，我想基于中间件的开发，首先要把握它的市

场价值，然后在开发上注重它的通用性。

论软件测试方法和工具的选用

摘要：

本文通过某省征管信息系统，讨论了软件测试方法和工具的选用。该项目的目标是建设一

个功能完备、监控严密、安全稳定的新一代税收征管信息系统，系统业务功能多，系统复杂，

性能要求高。项目采用了J2EE应用开发平台，经历了多个测试阶段，根据系统的特点，文章重

点讨论了我们在单元测试和性能测试中所采用的测试策略和测试工具，单元测试中划分了类的

优先级，使用Junit测试框架；性能测试中确定关键用例，使用RationalTestManager2003

工具测试。作为项目负责人之一，我有幸参与了该项目的分析和设计，也参与了测试的整个过

程。

正文：

税收是国民经济的重要环节。今天，在业务需求和信息技术发展的双重交互推动下，税收

征管业务的信息化应用在全球以突飞猛进的速度得到应用。然而，受限于工程进度的要求、IT

技术的发展和观念认识的差距，早期的信息化建设通常缺乏全局规划。为此，2002年10月，某

省税局决定在原有的信息化建设成果的基础上，充分发挥目前先进的计算机网络和通信技术的

强大处理能力，构建全省集中的税收征管信息系统。工程的目标是集中存储和处理全省征管业

务的基础数据，实现信息的高度共享和一致，全面推进信息技术在税收工作中的应用。

作为项目负责人之一，我有幸参与了该项目的分析和设计。

该系统建立在J2EE框架基础之上，其BLH（BizLogicHandler）是J2EE框架中的Domain层的

实现；BPO（BusinessPersistenceObject）是DAO与BO的结合体，对应J2EE中Persistence层

的实现；Web层开发采用Struts框架。系统业务功能多；渠道多，后台前置系统多，系统复杂；

系统性能要求高，并要求系统稳定，质量要求高；采用很多新技术，项目建设时间紧。

根据本项目的这些具体特点和要求，我们在IBM完全生命周期测试模型的基础上，根据项目

时间要求、具体情况和成本效率进行了裁减，形成本项目的测试策略、总体测试计划和详细测

试计划。对于应用系统的测试，我们划分为单元测试、部件组合测试、功能测试、性能测试和

验收测试。其中重点关注了单元测试和性能测试，下面分别介绍。

单元测试阶段，我们采用开发人员自己写测试代码、小组内同级审查和测试组抽查相结合

的测试策略。要求单元测试应紧接在编码编译通过之后，鼓励进行测试先行（即先编写测试用

例，然后用测试驱动代码的实现）。

单元测试工具采用junit测试框架。因为，我们的开发语言是Java，开发工具采用的是

Jbuilder，而junit是当前java自动化单元测试的实际标准，jbuilder对junit提供了很好的支

持。

对Action部分使用StrutsTestCase进行单元测试，StrutsTestCaseforJunit是对标准

64

Junit中TestCase的扩展，可以对Strutsframework的测试提供方便。我们使用了其中的Mock

object方法，测试Actionobjects、mappings、formbeans以及forwardsdeclarations，它不

需要servlet引擎及webapplicationcontainer的环境，而且StrutsTestCase提供了许多

“validationmethods”，方便测试案例的编写。我们采取的原则是，尽可能的把逻辑代码从

jsp/servlet/action中移出，使用Junit作单元测试。该系统单元测试中面临两个脱离，脱离

BizDelegate（封装了对SessionFaçade的调用过程，降低Application层与Services层的耦合

性）对action进行测试，脱离BPO对BLH进行单元测试，为此我们使用EasyMock技术，为一个接

口创建一个模仿对象，将模仿对象作为参数来调用域代码，具体为测试者提供了抽取方法和工

厂方法。

因为该项目涉及的用例非常多，我们对其进行了优先级的划分。在单元测试的时候，我们

同样对类进行了优先级的划分，依据是：类对应的用例的优先级、对系统是否产生严重后果、

潜在的用户数量和使用频度、信息的价值。对于不同优先级的类采用不同的测试方法。高优先

级的类，一定要有相应的测试类，以黑盒测试为主，对典型错误进行一定的白盒测试的方法，

每一步修改都需要进行回归测试；中优先级的类，根据实际情况决定是否需要测试类，对核心

的采取运行测试，其余的通过同级审查；低优先级的类，采用静态测试，所有类通过开发人员

自检和同级审查。

为了保证测试的质量，我们测试之初就设置了专门的测试小组。在单元测试阶段，该小组监控

所有的测试活动和任务的执行情况，对测试的总体进行跟踪、控制和报告。对于类的提交，我

们制定了严格的审核过程。首先，开发人员测试审查自己的类；然后小组内审查人员审查相应

的类，打上已审查标记；最后，测试小组审核和抽查已审查的测试类和代码；测试小组还需要

根据审核和抽查情况进行统计分析，调节测试资源分布。

在性能测试阶段，我们分为四个阶段来实施：启动阶段、准备阶段、实施阶段和分析阶段。

测试工具采用RationalTestManager2003，测试环境包括Localcomputer和Testagent，Local

computer作为测试平台的控制主机，负责整个测试的计划、设计、实现、执行和评估，作为Test

agent的机器，统一接受由Localcomputer发出的脚本指令信息，在一台机子上可以模拟多用户

访问系统，并将执行结果报告给LocalComputer，最后由Localcomputer生成统计报告。在测

试中我们也发现响应时间慢的问题，在经过对服务器的调优，以及相应部分的代码优化、SQL

优化之后，性能得到明显改善。

下面简单介绍性能测试中我们对遇到的问题所采取的策略：

（1）该系统采用的是J2EE架构的一种模式，GUI客户端直接和服务器连接，采用的是BEA

公司独有的T3协议，而目前自动化测试工具能够录制和回放脚本的大都是基于HTTP协议的浏览

器客户端方式。对此，我们采取自动录制和手工编写脚本相结合的方式，对于浏览器客户端的

测试，采用自动测试工具录制脚本；对于GUI客户端的测试，用JAVA配以性能测试工具提供的API

包，手动或半手动编写测试脚本。

（2）该系统业务功能繁多，测试需要准备的数据量大，而测试时间短。我们分析出业务具

有代表性的重要和关键用例，并且利用开发过程已有的客户端程序，减少测试脚本的开发量。

（3）该系统渠道多，与外部系统接口复杂，而且系统采用多家公司产品，如果出现问题分

析和定位困难。对此，我们利用性能测试检验客户和系统之间的交互，包括浏览器和GUI客户端

等方式的连接。同时在进行性能测试的时候，将内部各种系统，与其连接的各外部系统的日志

和监控工具全部打开，记录各部分的处理过程，这样当发现性能问题时，便能及早的定位瓶颈

出现的位置；测试环境准备和测试时，请相关厂家的工程师提供现场支持，进行性能监控和问

题分析。

由于采用了适当的测试方法、测试策略和测试工具，总体来看，我们的测试取得了不错的

效果，有力地保证了项目的质量。但也有不足的地方，具体存在以下几个方面：

（1）开发人员的测试观念还不够强。虽然我们制定了良好的单元测试策略，但开发人员并

没有很好地执行，以至于在以后阶段的测试和运行中受害不浅。

65

（2）每种测试之前，我们都组织力量充分准备了测试案例，但是在测试数据的准备上，由

于系统的复杂性等多方原因，有些数据准备的不太完备。

要解决以上问题，我认为首先还是要树立开发人员的测试理念，只有从具体的开发人员做

起，才能真正提高测试的质量，其次还要坚决贯彻执行项目中确立的测试方法和策略。

我们从实践中领会到，测试确实可以在保证软件质量方面起到很大的作用。但同时我们也

认识到，测试中还有很多领域和知识点需要继续研究和实践，新技术的发展对测试也提出了新

的要求和挑战，我们将在测试领域不断探索，不断实践。

论嵌入式实时软件测试方法和工具的选用

摘要

本文以航天嵌入式实时软件测试的过程，讨论了项目开发中测试所使用的方法和工具。在

该项目中，我担任测试经理工作。

嵌入式实时软件因其特殊性，在测试时有一定的困难。目前国内和军队已就软件产品的质量要

求及其测试制定了多项标准，但缺乏符合国内标准的本土化的测试工具，因而在工具的选取上，

主要考虑的是符合国际上航天或军用行业标准的测试工具，及软件测试工具增强软件测试的自

动化程度，和对文档支持的自动化程度。

在编码过程中，我们选用PC-Lint作为代码静态分析工具，辅助编译器进行代码审查。在进

行单元和集成测试时，我们使用了LDRA公司的Testbed/TBrun工具。

我认为，提高测试技术并不单指使用了测试工具进行测试，测试工具的使用可以提高效率，

但过多的强调工具的使用反而会使项目陷入困境。

正文

众所周知，在航天领域安全是最关键的问题，软件的微小瑕疵就可能造成天文数字的巨额

财产损失，甚至对国家安全造成严重威胁。这就使保证软件的质量，保证软件的高度可靠性，

面临巨大的挑战。

我们单位是航天科技集团某院下属的一个研究所的软件中心，主要从事航天器上的嵌入式

实时软件的研制。我们的软件是典型的嵌入式强实时软件，基于桌面PC为宿主机，x86系列的

386EX为目标机。软件计算量大，任务间时序要求严格，逻辑条件控制复杂，属于大型嵌入式软

件。随着软件工程思想的引入，CMM和RUP模型的推行，测试技术和测试方法也逐渐被重视起来。

近年我一直从事软件测试的工作，在项目中担任测试经理角色一职，主要负责测试计划的制定、

编写测试用例和组织软件测试。

当前我们大部分的测试还处于半手工的方式，没有形成一套自动化系统的软件测试标准和

规范。在软件审查中测试用例简单，不全面。为了尽可能多地找出程序中的错误，生产出高质

量的软件产品，我把测试工作重点放在加强对测试的组织和管理上。

按照软件工程的思想，中间过程产品的高质量，才能导致最终产品的高质量，软件开发过

程中越到后期发现的错误，需要修复而付出的代价就越高。为了确保软件的质量，较理想的做

法是对软件的开发过程，按软件工程各阶段形成的结果，分别进行严格的测试。保证每个开发

过程以最小的缺陷进入下一阶段的开发。为此我们为测试活动的定义了以下的过程：制定测试

计划、设计用例、实施测试、执行测试、评估测试。并使这些过程协同作用、互相促进，主要

目标是在设定的条件限制下，尽可能发现和排除软件缺陷。

在组织软件测试上，我们定义了以下的规程。

1、开发人员负责自己开发模块的代码静态分析；

2、开发人员组成小组，相互之间进行代码检视；

3、开发人员负责自己开发模块的单元测试；

4、开发部内部集成测试；

66

5、独立的测试部门进行系统集成测试；

6、系统测试，较全面的对最终目标系统进行功能验证，做尽可能多地覆盖；

在具体测试过程中，我们分阶段分步骤地采用了一些先进的工具和方法策略。为我们测试

成功奠定了基础。

目前国内和军队已就软件产品的质量要求及其测试制定了多项标准，但缺乏符合国内标准

的本土化的测试工具，因而在工具的选取上，主要考虑的是符合国际上航天或军用行业标准的

测试工具，及软件测试工具增强软件测试的自动化程度，和对文档支持的自动化程度。

在编码过程中，我们选用PC-Lint作为代码静态分析工具，辅助编译器进行代码审查。通过

PC-Lint我们能发现一般的语法错误，检查出那些通过了编译，虽然符合语法要求但不易发现的

潜在错误。如没有被适当检验的数组下标，未初始化的变量，使用空指针，冗余的代码等等。

PC-Lint可以添加用户自定义的检查规则，用来适应新的编码规范。此外还支持命令行和

MAKEFILE方式，可以集成到UltraEdit和Tornado2中开发环境中，或固化到软件开发测试流程中

去，方便开发人员的使用。功能强大，易于使用，性价比高是我们选择PC-Lint的主要原因。我

们发现利用PC-Lint进行代码静态分析，在程序动态测试之前发现编码错误，可以防止低级错误

引入到后期的开发中。通过实践证明这样可以有效的降低软件除错的成本。

在进行单元和集成测试时，我们使用了LDRA公司的Testbed/TBrun工具。我们测试的是航天

器的控制软件，语句逻辑控制结构复杂，进行白盒测试时，测试的输入量大，是一件十分枯燥

且重复性的工作。通过TBrun提供的灵活的测试数据输入方法，测试数据可按范围、最大、最小

及等步长或不等步长方式输入，实现了自动化的环境建立和测试输入。TBrun还提供了可视化管

理用例的方法，我们发现这些方法极大的提高了软件测试人员的积极性，使测试效率有了大幅

度提高。

在测试中我们会常常遇到这样一个问题：在测试初期，一般主要针对功能点语句设计用例，

以检查所期望的功能是否已经实现，这时覆盖率迅速增加，但一般达到70%左右的覆盖率后，要

再提高覆盖率是十分困难的，因为新的测试往往覆盖了相同的测试路径。这时需要对测试策略

做一些改变：从功能性测试转向结构化测试。也就是说，针对没有执行过的路径，构造适当的

用例来覆盖。Testbed有效的解决了这个问题，Testbed通过提供调用图与控制流程图，显示被

测系统的调用关系及每个子程序的控制流程，在测试阶段，实时显示测试覆盖率，提供检查分

析关键因素和优化测试路径的必要信息，帮助用户分析未测试的代码，实现以最少测试用例即

可达到覆盖率要求。

Testbed支持自动隔离测试，可自动产生驱动和桩模块。在我们按组合集成策略进行渐增式

集成测试时，在程序结构的高层使用自顶向下的策略，在下面的较低层试用自底向上的策略时，

自动产生桩模块和驱动模块，让我们把主要精力放在了测试用例的设计上。此外，被测代码修

改后对测试用例自动验证，使得回归测试非常的轻松。实践证明了好的测试工具对于激励测试

人员的积极性和创造性，提高测试效率是非常有效的。

嵌入式实时系统的性能测试，我们使用了CodeTest。CodeTest在真实软硬件环境下使用非

采样性测试，可以精确计算出每个函数或任务的执行时间或间隔，所以其测试具有很高的可靠

性。我们仿真实时系统并按照外部事件的序列检查其行为，使用类似于等价类划分的技术，对

事件如中断，控制信号和数据分类测试，并在测试了每种事件后，以随机顺序和概率将事件传

给系统，检查系统行为是否有行为错误。实现了以往难以进行的系统行为测试。

在隔离了任务内部和系统行为错误后，我们用不同的数据率和处理负载来测试系统中通信的同

步和互斥任务，确定任务时序是否正确，根据CodeTest测出的时间作为对应用程序优化的依据，

使开发人员可以有针对性地优化某些关键性地模块或任务，以及改善整个软件的总体性能。

总之，软件测试方法和工具的使用，可以提高测试技术水平，对软件质量保证起很大的作

用。但是提高测试技术并不单指使用了测试工具进行测试，测试工具的使用可以提高效率，但

过多的强调工具的使用反而会使项目陷入困境。通过这次软件测试，对我启示很大。觉得目前

67

我们的测试活动中存在以下的不足和可改进措施。

让软件测试走向规范，应用过程方法和系统方法来建立软件测试管理体系。其主要目标是

让测试活动中的过程协同作用、互相促进，从而使它们的总体作用大于各过程作用之和。

缺乏对测试工作进行度量，对测试效果进行评估，原因是缺少一个有效的度量数据收集和分析

机制。对测试进行度量和评估会极大的促进软件过程改进的效果。

论分布式数据库的设计与实现

摘要：

分布式数据库系统把应用所需的数据存放在多个数据库服务器上，完成某个数据操作要涉

及到访问多个服务器，这适用于某种特定需要的应用。我在主持设计开发的一个MIS系统中，为

了达到了在低速网络通道下有效提高应用程序性能的目的，使用了Sybase的分布式数据库技术。

我设计的这个系统是采用典型的C/S结构，但许多客户端连接服务器的网络采用电话线拨号，速

度有限，传统Windows界面的客户端应用程序相应速度比较慢。考虑到B/S结构也避免不了大量

数据从服务器端传输到客户端，我认为WEB界面并不能有效解决这个问题，所以采用了优化数据

库结构的方法，把数据分两部分存放，基础数据放客户机，会员资料主要采用键码放服务器，

应用程序再现数据时从服务器取键码，到客户机取对应的解释，由于键码的数据量少，网络传

输便快。在构建这个分布式数据库系统的过程中，我着重研究并解决了数据同步和事务协调的

问题，取得了良好的应用效果。我认为，分布式数据库系统的技术在Intenet时代正当其道，大

有发展前景。

正文：

分布式数据库系统把数据存放在多个数据库服务器上，当应用提取所需数据时，要访问多

个服务器，综合多点数据才能完成。

分布式数据库技术在很多场合得到了应用。譬如某企业随着业务量的扩大，原有数据库服

务器已经达到了容量和性能极限，如果不希望丢弃原有投资，可以建立另外一套新的数据库，

跟原有的系统组成一个分布式数据库系统，给应用提供透明统一的数据访问。还有，如果某企

业分成多个业务部门，而且地域分散，可以在某个部门放置单独的数据库服务器，用于存放该

部门最常用的数据，而部门和部门之间相互引用的数据可以通过分布式数据库技术来方便地完

成。分布式数据库不是简单地把集中数据库分散实现，而是针对某种特定应用需要而诞生，它

必然具有自己特有的性质和特征，需要在上面做许多的工作，来满足应用的要求。

我在设计、开发一个MIS系统时，针对应用的需要而引入分布式数据库技术，取得了良好的

效果。

该系统针对会员资料的管理而设计，用于管理会员入会、缴纳会费、申请资助、办理资助

审批、关系转移、退会和注销手续等等业务流程。分三个级别的应用权限——基层单位级、总

公司级和集团公司级，各个级别只能操作各自范围内的业务数据。该系统采用典型的C/S结构，

后台数据库采用Sybase，前端应用采用PB开发工具来设计标准的Windows操作界面。我在其中任

系统分析和数据库设计的角色，担任了调查业务需求、业务建模和数据库建模、数据库设计以

及指导应用程序测试、优化系统和应用的性能等等一系列工作。

由于客户端地域的分散，遍及多个省境内，许多使用该系统的基层单位连接服务器数据库

的网络采用电话线拨号方式，速度有限，在使用客户端应用程序时感觉界面速度很慢。经过分

析，认识到许多操作都要从服务器中取数据，速度慢就慢在数据访问上。服务器是没有性能瓶

颈的，问题出在网络速度上。不可能要求众多使用客户改善和升级他们的网络，只能充分挖掘

软件的潜力，来适应这种低速网络的使用模式。

经探讨，结合关系数据库的知识，认识到，应用程序的每一次数据库操作，都要访问多个相关

联的表，其中，有会员资料表和基础数据表，会员资料表中存放许多的键码值，在基础数据表

中有键码相应的解释。键码值的数据量比较少，而基础数据是静态的，几乎不会更改。如果考

虑把会员资料放在服务器上，基础数据放在客户端，当应用程序中访问数据时，总是从服务器

68

上存取会员资料，从客户端提取会员资料中键码的相应解释。由于键码的数据量少，便减少了

网络上传递的数据量，从而提高了界面的响应速度。

同时考虑到基层单位总是操作自己所属的部分会员，增删转移操作少，会员列表比较固定，

而每一项业务操作都涉及到要从会员列表中查找定位到某个会员，所以会员列表是最常访问的

数据项。把会员列表从会员资料数据中抽取出来，也放置在客户端，这样，便进一步改善了性

能。

把数据分散存放只是工作的第一步，接下来要考虑应用程序怎样访问这种分布式数据。开

发应用时，如果每一功能都针对两个数据库进行，就带来了很多麻烦。所以，我们研究了Sybase

的分布式数据库技术，决定采用了CIS（组件集成服务）部件，来合并两个数据库成一个统一的

分布式数据库。应用程序只要连接一个数据库，就可以透明统一访问到两个数据库中的数据。

该技术具体实施方法是，在客户端数据库中建立一个对服务器数据库的远程访问服务名，

包含访问地址、登录用户名、登录密码等等关键的连接信息；并且对服务器中会员资料数据表

建立一个本地代理表，结构和服务器中远程表完全一样，它是访问服务器中会员资料的中转和

代理。客户端应用程序访问本地代理会员资料表时，实际上是通过预定义的远程访问服务名中

包含的连接信息到服务器中对应的实际会员资料表中访问数据。这种访问对于客户端完全透明，

感觉不到是从物理上独立的两个服务器中存取数据。所以，这种数据库结构是典型的分布式数

据库。

部署这种分布式数据库不是难事，只要在客户端和服务器上安装12.0版以上的数据库服务

器，在客户端服务器上建立远程服务名和代理表即可。由于Sybase数据库的安装支持脚本方式，

在客户端应用程序的标准安装过程中，嵌入Sybase数据库的安装和配置脚本，就自动化地完成

了所有工作。

在实际使用该分布式数据库系统的过程中，遇到了几个问题。第一，数据同步。客户端基

础数据不是绝对静态的，也有变化，因此在服务器端要设置一个统一的基准，称为主点数据。

客户端总是复制使用，称为复制点数据。如何及时感知到服务器端主点数据的变化，有效率地

复制到客户端，是个难题。Sybase针对这种应用场合，提供了复制服务器技术，但为了避免过

于复杂，我们实际采用应用程序来管理同步。当服务器端主点数据有了更改时，保存一个相应

的标识和时间戳，客户端应用在登录服务器时，检查这种标识，一检测到了数据有更新，就首

先下载，然后再进入系统正常使用。这种方法实现起来，增加了额外的开发量，且不能判别绕

过应用程序对数据的直接修改，但是，是最简单和有效的方法。

第二个问题是事务协调问题。物理上独立的两个数据库，在协同操作时，如果服务器正好

停机或者网络故障，完整的一个事务没能完成，就会“事务崩溃”。虽然SybaseCIS内嵌了两

阶段提交技术，能够自动恢复。但是应用程序在这种情况下，敏感性不够，操作界面会无端凝

固，影响了使用的方便性。我们针对PB对于连接的判断和感知，用了一个小小编程技巧，使应

用程序能够及时感知到数据库连接故障，及时停止和恢复事务，使操作界面表现友好灵活。

以上遇到的这些问题，都找到了解决办法。分布式数据库技术的应用并不是非常复杂，它

往往为解决特定问题、满足特定需要而被采纳，使用得当，会给应用带来了许多便捷。

在当今信息社会里，互联网络带来了相互连通的便捷，而且知识爆炸，数据的分布式访问是个

必然趋势。潮流兴起的XML技术，提供了各种平台数据库之间的一个公共数据访问标准，可能会

用来构建更加灵活、适应性更强的分布式数据库技术。

论基于WEB的系统测试策略

[摘要]

我所在的公司是某省电信公司。2003年初，公司构建了互联网宽带增值业务计费平台。该

系统的目标是利用电信营运网络、用户资源和品牌优势，为各ICP和ISP提供统一门户、统一认

证和统一支付的营运平台。系统业务功能多，与传统的电信业务系统的接口多，性能和安全性

要求高。系统选用了微软公司的.NET开发平台，经历了多个测试阶段。根据系统的特点，本文

69

重点讨论了我们在单元测试、功能测试和性能测试中采取的措施和策略，以及如何保证测试的

充分性，并简要分析了基于Web的系统测试与传统的软件测试的不同之处。

我作为主要的技术负责人之一，参与了系统的技术选型、方案设计、需求分析和系统设计

等工作，也参与了系统的测试过程。

[正文]

随着互联网的发展，一方面ICP（内容提供商）和ISP（服务提供商）有好的内容和服务，

却苦于没有收费渠道；另一方面，用户希望使用有价值的内容和服务，却没有便捷的支付手段。

互联网从免费转向有偿服务已成为一种趋势和必然。为此，我所在的某省电信公司于2003年初

构建了互联网宽带增值业务计费平台，其目标是，利用电信营运网络、用户资源和品牌优势，

为各ICP和ISP提供统一门户、统一认证和统一支付的营运平台，创造互联网用户、ICP/ISP和电

信营运商的多赢价值链。

系统选用微软公司的.NET开发平台，采用了B/S三层架构设计：表示层、业务逻辑层和数据

层。表示层负责处理系统与互联网用户、ICP/ISP以及业务管理人员的交互接口；业务逻辑层负

责系统处理业务逻辑的所有COM+组件组成；数据层是存放用户信息、业务信息和计费信息的关

系数据库，采用微软公司的SQLSERVER。系统业务功能多，与传统的电信业务系统的接口多，

性能和安全性要求高，项目建设时间紧。

根据系统的具体特点和应用要求，我们仔细分析了业务流程和系统的应用环境，确定系统

的测试要素，并据此编制项目测试计划、测试用例和测试脚本，将系统的测试划分为单元测试、

部件组合测试、功能测试、性能测试、安全性测试和验收测试，重点关注了单元测试、功能测

试和性能测试。下面就此作详细介绍。

首先，我们考虑项目测试组的成员不仅限于测试工程师，还请到了相关业务人员加入到测

试队伍中。业务人员可以从实际业务的角度参与到测试数据和测试用例的准备工作中，并帮助

分析测试结果，发现与实际业务相关而测试人员容易忽略的问题。

由于系统复杂、业务功能和接口繁多，因此我们从一开始就非常重视单元测试。在单元测

试阶段，我们采取了开发人员自己编写测试用例、小组人员交叉评审和测试组抽查相结合的策

略，以避免测试用例的片面性，同时要求单元测试应紧接在编码编译通过之后。

单元测试我们采用了NUnit自动化测试框架，用它在.NET类上创建和执行自动的单元测试。

我们知道，.NET引进了一个新的程序开发的概念——Attributes(属性)，让开发人员可以在程

序代码之上再加入Metadata(元数据)。Attributes主要使用在documentingyourcode(注释你

的程序代码)，也可以用来提供有关Assembly的额外信息，NUnit中的TestRunner会扫描已经编

译好的程序代码，并且从Attribute里面知道哪些Classes是TestClasses，哪些Methods是需要

执行的TestMethods。然后，TestRunner使用.NET的Reflection技术来执行这些TestMethods。

这大大减轻了测试人员的工作压力，也有效地保证了单元测试的可靠性，为后续测试的顺利进

行奠定了坚实的基础。

系统的功能测试，我们主要考虑了页面链接测试、表单提交测试和数据库测试。

在系统提供的统一门户上，有互联网用户的网上家园和用户定制服务，也有电信营运商提

供的宽带增值业务，更多的是合作ICP/ISP的产品和服务。为了用户能通过统一门户查询、购买

和使用各项服务，就必须保证站点所有链接的正确有效。我们采用了以前开发互联网智能搜索

引擎项目的一个衍生产品——链接自动测试工具，它能自动检查、分析站点内所有页面链接，

并生成一份详细的清单，报告链接页面是否存在、哪些页面未作链接等。这基本上不会带给测

试人员工作量。

对于表单提交测试和数据库测试，我们采取了运行测试的方法。测试之前，依据系统需求

分析，对每一个交互功能页面设计测试用例，重点关注关键页面的测试用例，如用户注册、登

录、支付、服务目录等页面。测试针对提交操作的完整性来进行，以校验提交给服务器的信息

的正确性，同时检查数据库存取时数据的一致性。例如：用户密码要求长度不低于8位的非数字

70

字符和数字组合，并区分大小写。测试时我们分别用8位以下、8位及8位以上的非数字字符、数

字字符及其混合型进行测试。另外，如果表单只允许接受某些指定值，或使用了默认值，还必

须检验指定值和默认值的正确性。

对系统的性能测试，我们采用了Webstress测试工具，从连接响应速度和负载两个方面来进

行。在连接响应速度测试时，通过测试工具模拟单机访问，我们发现某些组件和页面响应速度

较慢。经过分析，我们进行了相应部份的代码优化、SQL查询优化，并对应用服务器调优，采用

了数据库连接池技术等，系统性能得到了明显改善。负载测试时，通过测试工具模拟多用户访

问系统，检查系统所能承受的极限访问量。测试中，我们将系统各个部份的日志和监测工具全

部打开，在并发用户数逐渐加大的过程中，记录系统在事务处理、CPU负载、内存使用等方面的

变化情况，借助这些数据查找并分析系统的性能瓶颈，采取针对性的改善措施。

由于系统功能多，与外部系统有大量的接口，系统建设时间紧张，而系统又是为互联网用

户和合作ICP/ISP提供统一门户和计费服务。测试是保证系统质量的重要手段，测试的质量直接

关系到项目的成败。为了使系统在功能、性能、兼容性、安全性以及页面风格和整体布局等方

面有更进一步的测试，保证系统在投入运营前测试的充分，我们将系统布暑到实际生产环境，

接入了多家合作ICP/ISP的服务，同时在门户上开通了用户在线反馈系统，通过举办有奖专项活

动鼓励用户使用系统并反馈系统的错误和缺陷，同时安排专人响应并整理用户的反馈，及时交

由开发人员修改。实践证明，这是非常有效的方法。

从系统的实践中，我体会到基于Web的系统测试比传统的软件测试要困难得多。基于Web的

系统在网络环境、用户范围、使用环境等方面都比传统的软件系统复杂，在测试时必须更多的

关注系统的并发性、兼容性、安全性和可用性。同时，基于Web的系统比传统的软件有更短的发

布周期，测试人员和测试管理人员面临着从测试传统的C/S结构和框架环境到测试快速改变的

Web应用系统的转变。

目前，软件开发正在向基于Web的应用发展和转变，这对测试工作提出了新的要求和挑战。

测试技术还有很多领域和知识点需要我们去研究、探索和实践，并在实践中不断总结和提高。

异种数据库集成的主要技术

CIMS是一个综合的计算机应用系统，由多个不同的功能系统组成，如ERP、PDMS等，这些系统

因数据对象的不同有可能使用了不同的数据库系统。另外，企业实施CIMS工程一般都要经历几

个发展阶段，由于技术或市场等原因，在不同时期配置的数据库系统可能会不一样。这样，在

一个企业的CIMS中，难免会包含几种不同的数据库系统。这里所说的不同，可能是基于不同数

据模型的DBMS，如关系型的或对象型的。也可能虽然都是关系型的，但不同商家的产品其SQLAPI

不尽相同。这些就是CIMS中面临的异种数据库的集成问题。异种数据库集成的主要技术有以下

几种：

1)数据的迁移和转换

利用数据转换程序，对数据格式进行转换，从而能被其它的系统接收。这种方法处理简单，

已为大多数用户理解和接受。许多数据库管理系统DBMS都自带有一些数据转换程序，也为用户

提供了方便。但这种方式当数据更新时会带来不同步的问题，即使人工定时运行转换程序也只

能达到短期同步，这对于数据更新频繁而实时性要求很高的场合是不太适用。

2)使用中间件

中间件(middleware)是位于Client与Server之间的中介接口软件，是异构系统集成所需

的粘接剂。现有的数据库中间件允许Client在异构数据库上调用SQL服务，解决异构数据库的

互操作性问题。功能完善的数据库中间件，可以对用户屏蔽数据的分布地点、DBMS平台、SQL

方言/扩展、特殊的本地API等等差异。

使用中间件的异种数据库集成有以下几种方法：

71

（1）通用SQLAPI即在Client端的所有应用程序都采用通用的SQLAPI访问数据库，而

由不同的DBMSServer提供不同的数据库驱动程序，解决连接问题。通用的SQLAPI又可分为

嵌入式SQL(ESQL——EmbeddedSQL)和调用级SQL(CLI——CallLayerInterface)。ESQL是将

SQL嵌入到C、Pascal、COBOL等程序设计语言中，通过预编译程序进行处理，因而SQL的所有

功能及其非过程性的特点得到继承。CLI则采用一个可调用的SQLAPI作为数据存取接口，它

不需要预编译过程，允许在运行时产生并执行SQL语句。由于CLI更为灵活，现在应用较广，

如Microsoft的ODBC、IBM的DRDA、Borland的IDAPI、Sybase的OpenClient/OpenServer

等等。

（2）通用网关网关(gateway)是当前流行的中间件方案。在Client端有一个公共的客户

机驱动程序(GatewayDriver)；在Server端有一个网关接受程序，它捕获进来的格式和规程

(FormatandProtocol，FAP)信息，然后进行转换，送至本地的SQL接口。

（3）通用协议通用协议是指公共的FAP和公共的API，并且有一个单一的数据库管理接

口。公共FAP支持适用于所有的SQL方言的超级设置或容忍全部本地SQL方言通过。

（4）基于组件技术的一致数据访问接口例如，Microsoft推出的UDA（UniversalData

Access）技术，分别提供了底层的系统级编程接口和高层的应用级编程接口。前者定义了一组

COM（组件对象模型）接口，建立了抽象数据源的概念，封装了对关系型及非关系型各种数据源

的访问操作，为数据的使用方和提供方建立了标准；后者是建立在前者基础上的，它提供了一

组可编程的自动化对象，更适合于各种客户机/服务器应用系统，尤其适用于在一些脚本语言中

访问各种数据源。

3)多数据库系统

在CIMS环境下，从系统和规模上来解决异种数据库集成的方法为多数据库系统。所谓多数

据库系统就是一种能够接受和容纳多个异构数据库的系统，对外呈现出一种集成结构，而对内

又允许各个异构数据库的“自治性”。

这种多数据库系统和分布式数据库系统有所不同。多数据库系统不存在一个统一的数据库

管理系统软件，而分布式数据库系统是在一个统一的数据库管理系统软件的管理与控制之下运

行的。多数据库系统主要采用自下而上的数据集成方法，因为异构情况在前而集成要求在后，

而分布式数据库系统主要采用自上而下的数据集成方法，全局数据库是各个子库的并集。多数

据库系统主要解决异种数据库集成问题，可以保护原有的数据资源，使各局部数据库享有高度

“自治性”，而分布式数据库系统是在数据的统一规划下，着重解决数据的合理分布和对用户

透明的问题。当然，两者之间在技术上有很多交叉，可以互相借鉴。多数据库系统一般分为两

类：

（1）有全局统一模式的多数据库系统。多个异构数据库集成时有一个全局统一的概念模式，

它是通过映射各异构的局部数据库的概念模式而得到。

（2）联邦式数据库系统。各个异构的局部数据库之间仅存在着松散的联邦式耦合关系，没

有全局统一模式，各局部库通过定义输入、输出模式进行彼此之间的数据访问。到目前为止，

没有商品化的多数据库系统，在CIMS环境中实施有一定难度。

历年考试论文题分类：

（1）软件工程

年份内容

92

面向对象的需求分析与设计、软件项目进度管理

93

软件的二次开发、软件的质量保证、图形用户界面技术、结构化程序设计

94

软件开发平台的演变与应用、软件的输入输出设计技术

95

软件测试的标准、信息管理系统的C/S结构、论CASE工具的使用、软件

开发范式的选用

72

96

系统的健壮性设计、面向对象开发技术的及其应用

97

信息管理系统的可行性研究、软件需求分析的方法与策略

98

软件的可重用性设计、论项目管理工具的选用

99

软件开发环境的选用和建立、软件开发过程中的配置管理技术

2000

软件测试的策略与环境、软件维护的组织和实施

2001

软件需求分析方法和工具选用

2002

软件质量保证

2003

自由软件的合理使用、软件开发的风险控制

2004

用例的获取方法、软件开发成本估算

（2）数据库技术

年份内容

94

数据库设计技术

97

数据库前端开发工具的选用

98

数据库的安全性设计

99

改进数据库应用系统的性能

2000

基于WEB数据库应用系统的开发

2002

数据仓库的实际与实现

（3）计算机网络

年份内容

97

计算机网络的安全

98

企业内部网Intranet的策略

99

企业内部网Intranet的系统集成技术

2000

企业网络计算的组成与特性

2001

Jave技术在因特网平台上的应用、改进WEB服务器性能的有关技术

2002

2003

WebService技术的应用与发展趋势

（4）系统集成

年份内容

92

系统的安全与保密控制

94

信息系统集成技术

96

系统集成技术的应用、开放系统应用的互操作性技术

2001

实时控制系统与企业信息系统的集成

2002

中间件技术在软件开发中的应用、虚拟现实技术的应用与发展

2003

工作流相关技术

2004

电子商务的安全、ERP系统的开发与应用

2006年系分论文预测

1、论CRM的开发和应用2、论数据挖掘技术的应用

3、论软件变更控制4、论软件外包

5、论灾难备份建设6、论软件复用技术

7、论企业信息系统集成方案的选择8、论项目质量管理

9、论电子商务系统风险评估10、论需求分析工具的选用