软考项目管理师论文范文

范文：论信息系统项目的整体管理

[摘要]

本文以我主持某市地税银行代理缴税系统项目为实例，探讨了信息系统项目的整体管理，及个人的一些经验教训。在该项目中我受领导委派，担任银行方项目组长。通过实践，对项目整体管理有了更深刻的认识：（1）前期工作很重要，需要与各方进行充分沟通，明确接口，需要制定切实可行的计划；（2）项目管理是一项系统的、动态的工作，不要僵硬化，应保障信息共享，及时根据情况变化进行计划调整；（3）在项目管理中，特别是牵涉部门比较多时，应采用各种方式保证良好的沟通、协调，保证进度。 通过本人及项目组的努力，该项目按计划完成，达到目标要求。

[正文]

项目整体管理是项目管理中一项综合性、全局性的管理工作。它决定在什么时间，在哪些预期的潜在问题上集中资源和基础和工作，在问题变得严重前进行处理，协调项目干系人及各项工作使项目走向成功。整体管理的工作流程主要有制定项目章程、指定项目初步范围说明、制定项目管理计划、指导和管理项目执行、监督和控制项目工作、综合变更控制、项目收尾。项目整体管理是一个项目能否高效、顺利的进行的一项基础性的工作。

20xx年， 根据某市地税部门和我行的代理协议和该市我行的零售业务部门提出的需求，我受省行科技部门指派，担任银行方的项目经理，组织开发了某市地税银行代收项目，该项目20xx年5月中旬启动，20xx年10月1日正式投产。项目涉及我行省行、市行，市地税、市地税方的信息系统外包开发公司四家单位。

在该项目的整体管理中，我在项目管理的五大过程中分别做了以下工作：

（1）在项目启动过程中，我根据业务需求，提出项目开发立项报告，完成项目的启动工作；进行项目的初步范围制定，对项目的目标、范围，项目组织、进度里程、项目费用估算进行分析；

（2）在项目的计划过程中，用project制定项目初步管理计划；

（3）在项目的执行过程中，配置人力资源，调配系统资源，执行项目计划，协调、沟通项目组、市地税方、市中行，确保项目正常、顺利完成；

（4）在项目的监督、控制过程中，收集分析项目周报，举行项目例会，将项目进度与项目计划进行比较；对变更情况进行分析、流程改变、记录分析，跟踪项目风险点，并制定风险应对方案；

（5）在项目收尾过程中，要求业务部门提供项目验收测试报告、项目投产申请；完成运行部门的项目投产单。

该项目业务跨越银行及税务两大行业，并各有自己的信息系统，如何实施双方系统的互联，进行需求的确定是一个比较困难的工作，需要解决税务局和银行，银行业务部门与技术部门的各种冲突，即要满足对方的需求，也要考虑本行的利益。以通过从对方角度考虑问题，进行良好的沟通，最后圆满解决不合理的需求问题。如税务局开始时提出，纳税人在银行交费后，************信息需要在银行保留。而银行系统一般只保留交易的账务信息，对保存************信息需要比较大的代价来实现，为解决该问题，我从税务局的角度进行分析：首先会有其他银行也加入地税代收的工作，其次纳税人可能在就近的银行或税务局打印#5@p，所以，************信息需要集中保存，集中保存的最合适地方是税务局。

在开发工作中，可以把行内业务需求人员加入到项目组中，或者建立紧密的沟通机制，调动业务人员积极性，让其在项目开发的需求确定，业务测试中发挥积极作用，减少需求的反复，开发的重复劳动，减少投入，确保工程进度。对避免不了的需求变更。需要需求方以

文字的形式对该变动进行规范、明确的阐释：如要求地税局或业务部门要提供需求变更说明，填写需求变更申请表等，减少需求提交的随意性，大大减少需求变更的数量。

该项目还有一个特点，涉及的单位和人员比较多，协调工作比较复杂，对此我的解决办法是：

（1）与地税局及业务部门，要充分进行业务流程、交易接口、通讯接口的讨论，确定双方的交易功能，技术接口定义，明确各方的工作职责；

（2）在项目组中，根据明确的需求，及时进行工作分解，根据项目组成员的特点、专长分配各项子任务，做到职责明确，分工合理；

（3）在项目开发过程中，要及时进行信息交流，及时向各方发布项目进度情况，我通过建立文件共享服务器，发布技术协议，需求分析，概要设计，项目计划，项目周报等文件，让项目组成员及配合的业务人员对工作有全面了解，对工作重心及时掌握，尽量减少内部冲突；

（4）在功能开发基本完成后，及时组织双方的系统联合测试，在准生产环境中运行，及时发现问题，解决问题。

（5）建立良好的进度管理机制：在项目启动时就用Project制作计划，统一分发，与其它单位协商计划文档；在项目进行中，及时完善、更新进度；计划前提有变动时要及时调整；建立跨单位的周例会制度，项目周报填报制度等。

该项目历时一个月，顺利完成投产工作，并在生产中，达到要求，为银行创造了效益，为地税部门减轻了负担，为纳税人提供了方便，实现了多赢的结果。同时也锻炼了我的项目管理能力，对项目整体管理有了更深刻的认识：项目管理前期工作很重要，需要制定切实可行的计划，需要充分沟通，明确接口；应对项目管理有是一项系统的、动态的工作的认识，不要僵硬化，应保障信息共享，及时根据情况变化进行调整；在项目管理中，特别是牵涉部门比较多时，应采用各种方式保证良好的沟通、协调。

第二篇：软考高级项目管理师论文范文

论分布式数据库的集成

摘要：

本文讨论了某公司发货系统的分布式数据库集成解、央方案。该公司由于业务的发展，要在另三个城市设立货仓进行发货。为此，需要增加原先的rrtis系统实现这一功能。公司委任我作为项目经理完成系统的设计和开发的工作。我经过分析，使用了Sybase的分布式数据库技术。我设计的这个系统是采用典型的C/S结构，但客户端连接服务器的网络采用电话线拨号，速度有限，传统Windows界面的客户端应用程序相应速度比较慢。于是我采用了优化数据库结构的方法，把数据分两部份存放，基础数据放客户机，销售资料主要采用键码放服务器，应用程序再现数据时从服务器取键码，到客户机取对应的解释。由于键码的数据量少，网络传输便快。在构建这个公布式数据库系统的过程中，我着重研究并解决了数据同步和事务协调的问题，到得了良好的应用效果。

正文：

20xx年3月，由于公司业务的发展，要求在其它三个城市设立货仓，处理发货业务。公司本部运行着一套用Sybase数据库的MIS系统可以实现发货，该系统用的是C/S结构。由于客户端连接服务器的网络采用电话拨号，所以直接把客户端软件直接安装在外地访问本部数据库，速度很慢。于是，公同成立了一个项目，专门解决这个问题。在这个项目中，我担任项目经理。经过对现有系统的分析，裁们、央定利用Sybase提供的技术，采用分布式数据库集成的方法来改造目前的系统使之能适应新的需要。项目分三个阶段进行，一是进行需求分析，确定要增加的功能。二是进行系统设计，改变后数据分布如何，系统架构如何。最后是实现和测试，上线。整个项目历时从分析到实现历时三个月，最后于20xx年6月份系统成功上线。

在分析阶段时我发现由于客户端地域的分敌，遍及三个省境内，连接服务器数据库的网 络采用电话拨号方式，速度有限，在使用客户端应用程序时感觉界面速度很慢。我经过分析， 认识到许多操作都要从服务器中取数据，速度慢就慢在数据访问上。服务器是没有瓶颈的， 问题出在网络速度上。出于成本和业务量方面的考虑，公司不会用专线连接，只能是电话拨 号。这时只能改变目前软件的实现方法，来适应这种低速网络的使用模式。

经和项目组的人员一起探讨，结合关系数据库的知识，我认识到，应用程序的每一故数 据库操作，都要访问多个相联的表，其中，有销售订单表和物料基础数据表．／客户资科表．傥 仓的基础数据等。销售订单表中存放看出销售的订单编号，成品编号等，敦据量少。而基础 数据表就则放着成品的相关信息，有大量的数据。如果考虑把销售订单放在服务器，基础数 据放在客户端，当应用程序中访问数据时，总是从服务器上存取销售订单，从客户端提取成 品/iJ单的详细信息。由于订单的数据量少，便减少了网络上传递的数据量，从而提高了界面的响应速度。

把数据分敌存放只是工作的第一步，接下来要考虑应用程序怎样访问这种分布式数据。 开发应用时，如果每一功能部针对两个数据库进行，就带来了很多麻烦。所以，我通过研究 Sybase的分布式数据库技术，决定采用CIS（组件集成服务）部件，来合并两个数据库成一 个统一的分布式数据库。应用程序只要连接一个数据库，就可以透明统一访问到两个数据库 中的数据。

该技术具体实施方法是：在客户端数据库中建立一个对服务器数据库的远程访问服务名， 包含访问地址，登录用户名，登录密码等关键的连接信息；前且对服务器中销售订单建立一 个本地代理表。结构和服务器中远程表完全一样，它是访问服务器中会员资料的中转和代理。

客户端应用程序访问本地代理销售资料表时，实际上是通过预先定义的远程访问服务名中包 含的连接信息到服务器中对应的实际销售资料表中访问数据。这种访问对于客户端完仝透明， 感觉不到是从物理上独立的两个服务器中存服数据。所以，这种数据库结构是典型的分布式 数据库。

部署这种分布式数据库不是难事，只要在客户端和服务器上安装12．O版本以上的数据库服务器，在客户端服务器上建立远程服务名和代理表即可。由于Sybase数据库的安装支持脚本方式，在客户端应用程序的标准安装过程中，嵌入Sybase数据库的安装和配置脚本，就自动化地完成了所有工作。

在实际使用该分布式数据库系统的过程中，遇到了几个问题，第一，数据同步。客户端 基础数据不是绝对静态的，也有变化，因此在服务器要设置一个统一的基准，称为主点数据。 客户端总是要复制使用，称为复制点数据。如何及时感知到服务器端主点数据的变化，有效 率地复制到客户端，是个难题。Sybase针对这种应用场合，提供了复制服务器技术，但为了 避免过于复杂，我们采用实际应用程序来管理同步。当服务器端主点数据有了更改时，保存 一个相应的标识和时间戳，客户端应用在登录服务器时，检查这些标识，一检测到了数据有 更新，就首先下载，然后再进入系统正常使用。这种方法实现起来，增加了额外的开发量， 且不能判别绕过应用程序对数据的直接修改，但是，是最简单和有效的方法，

第二个问题是事务协调问题。物理上独立的两个数据库，在协同操作时，如果服务器正 好停机或者网络故障，完整的一个事务没能完成，就会“事务崩溃”。虽然Sybase CIS内嵌 了两阶段提交技术，能够自动恢复。但是应用程序在这种情况下，敏感性不够，操作界面会 无端凝固，影响了使用的方便性。我针对PB对劲于连接的判断和感知，用了一个小小编程技巧，使应用程序能够及时感知到数据库涟接故障，及时停止和恢复事务，使操作界面表现友好灵活。

在具体的应用中，我们在三个城市安装了增强的客户端应用程序，同时安装了Sybase数据库。初始化时，把基础数据放从公司本部的数据库导入客户端的数据库中。用户在外地进行发货时，先拨号上网，然后启动客户端程序。在登录过程中，客户端程序会检查服务器上的标识和时间戳检查这些主数据是否有更新，如果有就先下载，下载完成后再进入系统正常使用。在服务器更新的数据比较多的情况下，下载的时间会比较长，这时如果遇到急需发货，则会影响到货物不能及时发出去。为了解决这个问题，我设置了在每天凌晨的某个时刻自动登录和启动客户端程序，在下载更新数据完成后自动关闭。这样可以把一部份数据更新的内容放在非工作时间里完戍，减少了发货登录的时间。用户登录后开始进行发货操作。输入销售订单，通过本地代理表系统自动到服务器获取该销售订单的数据，如发货的数量，客户编号等。而一些基础数据则可以直接从本地的数据库中得到，如销售产品的描述，客户的地址／电话．／传真，发货的库位等。完成出货动作后，会自动更新服务器的库存。而这一更新通过提交事务在后台进行，不影响前台的操作。所以，对用户来讲，能够进行正常的操作，不会因为速度慢而进行不下去。

在当今的信息社会里，互联网带来了相互连通的方便，而且知识爆炸，数据的分布式访 问是个必然的趋势。目前新起的XhtL技术，提供了各种平台数据库之间的一个公其数据访问标准，可以用来构建更加灵活，适应性更强的分布数据库技术。将XML用在分布式数据库中，j备昙未来的一个掐磐。

论软件工程度量

摘要

随着计算机科学技术的不断进步，在教育系统中越来越多的学校开始应用教育管理系统 来实施日常的教育教学工作。我有幸参与了公司《料域廷宇校园》一一中小学学校管理信息系统软件项目的设计开发全过程，并担任项目管理任务。

本文结合本人工作的实际经历，通过对学校管理信息系统软件项目实现过程进行描述， 讨论了软件工程活动中，为了把握软件工程过程的实际情况和所生成产品的质量，需要对进 度、质量、人员等方面进行度量。文中着重分析了在本项目中使用度量方法改进开发过程的 实施手段。

正文

早在20xx年教育部就颁布了在中小学实施“校校通”工程的通知，决定从200 1年起， 用5年到10年左右的时间，在全国中小学基本普及信息技术教育，全面实施“校校通”工程。经过几年的建设，很多学校的网络硬件环境已经形成，但真正在学校教学、研究和管理中发挥作用的高质量软件产品并不多见。我们公司以前曾经为某个学校开发过C/S结构的教育管理系统，当看到目前这个教育信息化的大趋势后，就想以一款技术含量高、可扩展性强并符合国家标准和规范的校园网应用软件《料《毖宇校园》产品进入教育市场。

项目确立之初，我们与两所学校签订了开发意向，并要求茌半年内拿出运行可靠的软件 产品。作为运行在网络系统高速公路上的“车”的应用系统，主要是为校园网群不同层次提 供应用性支撑软件系统，两所学校现阶段的要求是建立学校网络管理信息系统和通信信息服 务系统。于是确定《料《炱字校园》的功能以学校管理信息系统和信息服务系统为主框，其中办公管理信息系统覆盖教育教学管理的各方面，包括：学校基本信息管理、基本教务管理、 计划管理、学籍管理、备课管理、考试管理、成绩管理、排澡系统、学生管理、教职工管理、 教学计划管理、图书信息管理、仪器设备管理、房产管理等；信息服务系统是为丰富校园的 文化生活服务的，包括：学校教育信息服务、校园风貌、教育园地、电子邮件、BBS学生讨论区、教师科研信息等版块。

由于系统的最终交付日期已经确定，如果进度安排落空，会导致市场机会的丧失，用户 会不满意，甚至还会要求赔偿经济损失，从而导致成本的增加。因此在项目真正实施前，我 们就确定了以进行有效的项目估算、产生高质量的系统和按时交付软件产品为目标的软件项 目管理策略。公司在早期做过C/S结构的教育管理系统，对于目前要开发系统的项目任务有 较清楚的认识，并能快速地建立任务之间的相互关系。根据以前项目的开炭过程建立的度量 基线，我们可以较准确地估算各个任务的工作量，分配人员和其他资源，制定进度时序。 下面就谈谈在这个中小学学校管理信息系统项目的资源管理中如何使用的度量方法改进开发过程的。

在此项目中我们采取了以下主要措施和方法：

一、在软件计划和需求分析阶段，综合考虑利用可复用姿源，合理估苒项目工作量，准确度 ：量任务权重，成功降低软件生产威本

在本系统的定义阶段，我们把估算项目工作量作为此阶段的主要度量元素，通过综合考 ．虑利用可复用资源，准确核算任务权重，从而尽量精确地估算出项目工作量，将项目的开发周期尽可能限制在可实现的最短时间内，以达到降低软件生产成本的目的。 我们在项目工作量及技术难度的估算上遵循面向对象技术原则。

本系统采用了面向对象的分析、设计等一系列面向对象技术，在系统工作量估算方面根 据功能点进行。将每个功能模块逐步分解，直至基本模块为止。由于公司以前完成过基于

C/S结构的教育管理系统的成功案例，因此有不少供残们参考的数据和资料。对于本系统的第一部分学校办公管理信息系统我们就是借鉴以前基于C/S结构的教育管理系统。c/s结构的教育管理系统是利用不同的客户端版本，达到区分多用户访问权限的目酌，但综合所有客户端版本，翼在基本功能、数据库结构设计和前台操作，如对数据库进行添加、删除、修改、查询等操作方面都与新项目管理信息系统部分大俸相同。正因为如此，有大量的资源可供我们复用，许多基本功能模块仅作少量修改就能够被复用到新系统中。在工作量的估算上也有很好的比照借鉴作用。以前的数据对工作量的估算是一个重要的参考，为项目进度安排提供了依据。

在技术上，我们重点考虑在基于B/S结构的系统中多用户访问及权限控制模块的设计和 项目第二部分信息服务系统的实现。由于软件工作量的估算首先从软件项目范围抽出软件功 能，接着给出为实现每一软件功能所必须执行的一系列软件工程任务，如需求分析、设计、 编码和测试等。所以对于上述含有技术难度的任务，我们利用历史数据中对不同复杂性和开 发特性的功能模块，分别按最佳地、可能地、悲观的三种情况给出的估计值计算加权平均， 得出较为准确的任务权重度量值。

根据以上分析我们制定了一个详细的项目进度表并定义了相应的里程碑，限定了项目要 在六个月的时间内全部完成。这比我们最初的预计提前了两个月，大大降低了项目开发成本。

二、在软件设计编码阶段，注重人员安捧，确保产品质量

人力资源在考虑各种较件开发资源时，人是最重要的资源。在安排开发活动时必须考虑 在开发过程各阶段中对各种人员的需要。在软件项目设计编码阶段，我们把人员调配确定为 此阶段的主要度量元素，按照人员自身能力状况合理安排，保证了软件产品的高质量。 本系统在软件需求分析和设计阶段，有两名公司的高级技术人员参与对软件系统进行定 义。他们利用自己丰富的实践经验，为系统提出了许多可行的能够高效实现预定任务的方案， 同时在技术难度相对大一点的部分由他们从设计方面把关。而在项目实施阶段他们也负责指 导相关人员对关键任务的理解，并随时监控程序员在具体编码中是否真正实现了他们的设计 思想。这一系列的工作安排，确保了我们的软件产品在关键技术问题上从未出错。尤其是高 级技术人员设计的由超级用户实施的权限控制模块，可以为不同的用户设置每个模块的不同 访问权限，也可以在权限分配中对权限相同的用户进行批量处理。产品交付使用后，用户对 于灵活方便的权限控制模块非常满意。

由于有可复用的资源和高级技术人员的指导，项目开发中大量的编码和调试工作，是由 初级技术人员来实现。根据进度表中各个里程碑的划分，管理人员可以方便地度量每个编程 人员的实际工作情况，同时按照工作时间安摊进行软件测试和验收，从而确保开发的进度和 软件的质量。

三、在软件开发全过程，随时掌握项目进行情况，必要时调罄讲度表

在为项目开发制定的详细进度表中，确切地定义了每一项任务的工作量、开始时间、持 续时间和结束时间。我们让开发小组的每一位成员认真了解自己所承担任务的时间表，并根 据自己的任务制定相应的工作计划。

我们公司里有一个用来管理员工每日工作情况的日志管理系统。为了使教育管理信息系 统项目能够顺利完成开发任务，我们要求参与此项目开发的人员在当日工作结束后都要按照 实际工作情况填写它。例如，一个开发人员今天的工作是对某个功能模块进行编程，在日志 文档中会包含：开发的模块名称、开发目标、使用的方案、新建或修改的文件名称、遇到的 困难、解决的方法以及计划的完成情况等。同时每周要对自己的工作进展做出结论，如：某 某任务已完成80%，能够按照计划时限完成本项任务，并向项目组汇报。

开发小组的每个成员都要对自己做出的结论负责，这样管理人员就可以做到随时了解项 目进度，为调整项目计划提供客观基础。项目小组会在每个里程碑处以会议的形式对本阶段

的工作进行确认、总结，对本阶段的进展情况做出结论，并决定是否调整下一阶段的进度计 则。

本系统在整个项目开发过程中，由于总体工作量估算基本准确，关键任务及人员使用定 位合理，使得开发任务按期高质量的完成了。但是在我们的工作中也有失误的地方。系统特 点决定了项目需要完成不少网络界面设计，因为公司美工人员不足，一个美工同时兼顾几个 项目，造成项目组与美工人员沟通不畅，某些界面设计无法达到要求，险些影响整个项目进 度。在管理人员发现悟况后及时外聘美工，补足人员调配缺陷才使任务顺畅进行。

通过以上的分析和讨论我们可以知道，要想真正在软件生产中实现工程进度的可控性， 就必须在软件项目计划阶段准确确定软件范围、合理调配所需资源，从而获得更接近实际值 的软件任务成本和工作量估算。软件工程度量的估算虽然不可能与工程实际进度完全一致， 但在不断发现导致合理估算的信息的过程中，是可以逐步达到计划目标的。软件工程的度量 随着项目的进展定期更新，从而将软件工程的进度限定在可控范围内，就能使得软件生产任 务按照而常计划实现。

论软件过程的度量

摘要：

本文从软件错误数、缺陷数的角度讨论了软件质量度量的方法、作用和意义。

20xx年2月我作为某大学网络学院技术部的技术骨干，参加了《网络学院2004版远程教育平台》的开发，在该项目中我担任项目负责人。该平台涉及分布全国的重多学生、数学站、教学中心，大量教学资源以及教师、教务管理等多方面，该平台的建设直接关系到学院今后的高效管理、持续发展，因此对我们的软件提出了很高的质量要求。

在该项目中，我启用了软件质量度量，主要计算软件开发各阶段的错误数、缺陷数、错 误清除率，本文重点介绍了需求分析阶段我们按功能点计算错误数的方法，以及计算结果对 我们系统的影响。

对于软件质量度量我们的经验还十分缺乏，本文作者也特别希望大家提出更好的建议帮 助我们改善度量方法。

正文：

本人所在单位为某综合性大学网络学院技术部，从200 1年建院开始我们技术部陆续为 学院自主开发或外购了多种软硬件系统，这些系统的开发是不同时间、由不同开发人员用不 同开发工具、使用不同数据库运行在不同平台上的，比如部分是：asp/Sql server2000/Windows 部分是Php/Jrtys ql/Linux等，子系统之间数据割裂、兖叉、重复现象严重，代码经过几年的 修改再修改已经变的很难修改；服务器的负荷也已经很难满足要求，网络高峰期特别是考试 前后很难访问。因此，学院决定于20xx年2月立项开发《网络学院2004版远程教育平台》， 在该项目中，由我担任项目负责人。

该远程教育平台分2期工程，采用增量模式开发。一期工程主要包括：学生管理、 教务管理、教务管理、教学资源管理、网络题库考评、虚拟社区、毕业论文管理等，其中 教学资源管理中的流媒体澡件系统、虚拟社区中的电子白板利用原有外购产品，此次只进 行升级。二期工程主要包括OLAP联机分析系统，对学生地区分布、年龄分布、专业分布、 成绩分布，教学资源质量、教师工作质量等进行分析和评估；建立自适应学习平台、研究 性学习平台等。

本远程教育平台是一个庞大的体系，是学院高效管理、持续发展的基石。平台涉及

遍布全国各地的3万多学生、15个省自治区级的教学站、教学站下设的200多个教学中 心；教学资源涉及15个专业近400门澡程，学校近400名教师以及我们网络学院各管理 部门（比如财务部、学生管理部、教学资源管理部、教师管理部等）。本平台的开发，学 院领导给予了高度重视，提出该平台至少应满足今后四到五军的规模发展需要；新的教学 技术教学理念的实施应能与本系统无缝集成。

作为本项目的负责人，我深感责任重大。反思我们前几年软件开发管理力度不大造成 一定程度上开发的混乱，我参观学习了本市两家取得CMM4级认证的软件开发，我决定在 本项目的开发中启用软件质量度量，主要度量软件各阶段的错误率、缺陷率，以及上一阶 段对下一阶段缺陷的转播、缺陷的放大。鉴于我们进行软件度量的经验缺乏，我们聘请了 一名CJ/tM4级软件公司的资深项目管理专家做咨询顾问，请他每周至少一次来学院指导工 作。

我们采取的基本度量方案是：度量软件的错误数、缺陷数、计算错误清除率。具体 实施中，我设计了一个错误汇总表和几个分级明细表。在汇总表中，我将纵坐标设计为软 件开发各阶段：计划阶段、需求阶段、设计阶段、代码阶段和测试阶段、使用维护阶段； 横坐标设计为：本阶段发现的错误数、下阶段发现的错误数（此数据作为本阶段的缺陷数）， 错误清除率。汇总表主要从宏观的角度看我们软件的整俸质量。汇总表的数据来自多个明 细表。

我在这里重点介绍我们需求分析阶段错误数的统计，以及通过错误数统计、分析对 我们软件开发的促进和提高。我们部知道软件的质量首先是满足各类需求，不满是需求的 软件就谈不上质量。因此我们对需求分析给予了高度重视。我设计了如下需求分析阶段错 误数统计表：纵坐标是各功能点以及子功能点，功能点和子功能点分级展开；横坐标由各 功能点简单说明（该项链接到需求规格说明书）、业务需求、功能需求、性能需求、安全 需求、数据需求、错误描述、评估人、评估时间等项组成，其中业务需求、功能需求、性 能需求、安全需求、数据需求均由两栏组成，一栏是错误数、一栏是缺陷数，缺陷数由后 续开发阶段填写。

这个需求错误评估表做出来之后，我们技术部做了大量工作来填充这个表。首先是 功能点的划分。我们采用UIKL统一建模工具，用ROSE 2003建模系统各部分。我们将该系 统的参与者分为：网络学院院长、院各管理部门负责人及管理人员、网站数据管理员、教 学站以及教学中心负责人及管理人员、教师、学生等，根据不同参与者确定了大量用例， 并对每个用例编写了：用例目的、前置条件、后置条件、限制条件、基本流程、替换流程 等；在这些用例的基础上，我们划分出了功能点以及子功能点。

建立了各功能点之后，最重要的是评估。学院请来了本系统各类有代表性的用户， 比如学生人数最少的、最多的、离学院距离最近的、最远的教学站以及教掌中心负责人， 进原“网络教室”、原论坛最活跃的、最不活跃的、成绩最好的、最不好的学生，最热门 专业、最冷门专业以及公共澡的教师等等组成的用户代表团，还请来了安全技术专家、服 务器方案专家、教育管理专家、教育技术专家等组成的专家团，与我们学院各部门管理人 员一起组成的评审团对我们的需求进行评估打分。在评估之前，我们技术部讲解了我们的 项目计划、需求说明，有的需求用以前系统的功能演示，有的需求用我们设计的界面原型 演示，使每个参与人员都充分了解本系统。做好这些准备工作之后，我们要求每个参与人 员认真评估需求，特别是与自己相关的那部分，对于需求错误一定要给予详细的错误描 述；对于希望补充的功能，可以另外说明。

技术部通过2周时间的分析、整理这些需求错误统计表，得到了很多有价值的信息。 既有比较重要的功能遗漏：比如考试场次安排。以前我们的考试场谈安排通过手工进行， 只考虑一些粗略的因素，比如考试人数、澡程数等。但实际情况远比这个复杂，这汝的监

考教师、教学站负责人都提出了这个要求，由软件系统综合考虑实考人数、补考人数、座 位数、考场数、监考教师数、试卷数等安排考试场饮。还有一些错误是我们技术部预先想 不到的，比如：通过迎远地区学生和教学站的调查，发现这些地区很多电脑配置很低，运 行的是IE4．O甚至是4．O以下，上网是电话拨号；他们看不到我们技术人员用脚本做出来

的漂亮页面，看到的是很混乱的页面；流媒俸澡件无法点播，其它图片下载也非常的慢。 而且这部分学生大约占总数的10%。这些错误对我们技术部分析人员触动很大，我们的系 统必须给予正确的应对，比如我们准备今后在制作流媒体澡件的同时，制作部分教学光盘 分发到边远地区，我们的界面设计人员一定要在多个浏览器下测试效果。

以上只对软件需求阶段错误数统计进行了介绍。事实上，我们通过对整个项目各个 阶段错误数以及缺陷数的统计分析，大大改进了我们的软件质量；最明显是我们的新系统 20xx年2月投入运行后，各方面的反应部很好。

软件项目度量对我们来说，还明显的经验不足。我们的软件质量度量中，还有一些 重要的影响因素没有考虑和计算。比如错误的权重：修改错误的时间、人力、资源；修改 错误时引起的其它错误；上阶段未发现错误对下阶段开发的影响没有量化等等。希望今后 的软件耳带；寸挥中耢f甜；井；文此问颢．并亏I人事弃；井的窿量青法．

论软件的性能优化设计

摘要：

本人20xx年有幸参加了中国石油集团的高性能数控测井系统项目的开发研制工作。该系

统是在当前测井成套测井装备的基础上，为了满足高精度，高性能，高效率的要求开发的测 井系统。该系统由井下成套仪器，测井遥测系统，测井地面系统，测井软件系统，测井解释 评价系统等子系统组成。本人在其中主要是负责测井软件系统的分析、设计以及部分开发任 务。作为整个系统控制核心的测井软件如何才能保证有整个系统的高性能和高可靠性呢？本 文从系统优化、程序设计优化两个方面来详细讨论如何提高整个测井软件系统的性能。其中 系统优化主要是通过调节软件运行环境来优化软件性能，程序设计优化主要从程序架构设计、 语法、 内存管理、输入输出等方面来讨论如何采取措施提高软件的性能。

正文：

随着当前石油测井技术的发展，为了能更快，更好的得到储层地层信息，解、央目前国内测井系统不统一，测井精度不高，效率低下的缺点，20xx年1月中国石油集团公司科技局成立了高性能数控测井系统项目，目的是为国内测井行业提供一个从井下到地面以及解释评价的整套测井系统。系统的设计目标是一次测井，取得所有合格资料，并且能保证60井故的免维修率。整个系统白井下成套仪器，测井遥测系统，测井地面系统，测井软件系统，测井解释评价系统等子系统组成。我主要是负责测井软件系统的分析，设计和部分开发工作。 整个测井软件系统完成三个主要任务： 测井数据的采集、 测井数据的工程值计算、测井过程的监控。对应于这三个任务，整个系统分为三个系统层：数据驱动层（简称前端），数据处理层（主控）和表象管理层（后端）。数据驱动层的主要目的是封装地面系统和井下遥测系统，为数据的上传和命令下达提供统一的接口。数据处理层的主要目的是按每种仪器的刻度算法计算测井原始数据。表象管理层则负责测井数据的表象处理，主要是曲线和图像的显示与绘图。系统前端运行在Vxworks系统上， 主控程序和后端显示程序运行在

Windowr2000系统中。前端主要是采用Tornad02．O开发，主控程序和后端显示程序采用VisualCH2003开

发。

由于测井软件系统负责着整个井下仪器的数据采集、仪器状态控制和测井资料获取。所 以对测井软件系统的性能要求是非常高的。这主要表现在以下方面：

采集数据的完整性和正确性要求。由于目前井下仪器主要是通过100K的CTS遥测传输数据。要求每80毫秒采集一个完整的数据帧，由于伙器算法的特殊性，要求不能丢掉一帧，也不能采集错误的数据。这就要求数据驱动层有非常好的实时性和高可靠性。

数据显示和打印的实时性要求。由于井下地质情况复杂， 为了保证测井安全以及测井数据质量，需要把测井的数据用曲线和图像的形式实时的显示和打印出来，以便于监控测井过程中井下的各种情况。

在软件分析设计和开发中，我们主要是系统优化和程序设计优化两个方面采取措施来提 高软件的性能并取得了比较好的效果。下面我主要从这两方面进行讨论：

一、系统优化

系统优化主要是从测井软件运行的系统环境角度方面采用措施来提高软件的性能。由于 Window2000操作系统的分时多任务系统，不能保证在80ms时间间隔内测井系统所要求的数据的完整性和正确性，所以裁们采用VxWorks实时操作系统做为前端操作系统，运行数据采集程序，保证测井数据完整和正确。再通过网络连接到主控程序处理数据。为了保证系统网络数据传输的性能，采用千兆网，连接主控和前端。同时为了提高数据10的响应速度，以及数据的可靠，采用SCSI接口的磁盘阵列，提高数据的冗余度来保证系统数据的可靠性。同时，主机系统采用Intel公司P4EE结构的多线程处理器，以及512M酌DDR内存，来满足数据吞吐的要求。

程序设计优化主要是程序设计优化主要从程序架构设计，语法算法和编译， 内存管理， 输入输出，软件测试等方面采取措施提高软件的性能。

1、程序架构设计

由于优化性能并不是个局部的过程，整个程序的性能提高必须在程序设计的开始阶段就 给予考虑和规划，以设计良好的软件架构保证系统的良好性能。本系统采用三层系统结构， 各层之间采用网络连接，实现松散的耦合。即使后端显示程序出现错误，也可以保证测井数 据的完整和正确。同时引入组件对象的开发思想，把每个仪器的算法及控制部做成组件，并 进行单独的测试，从而保证组件的正确性。采用这种办法不仅可以保证错误不会在系统的扩 散，方便系统的调试。同时也可以利用以前成熟的仪器算法和控制代码，不会引入新的风险， 提高系统的成熟度和可靠性。

2、语法算祛伐北和编译优化

在代码开发阶段，可以通过C++语法特点来优化系统，实现更好的性能。例如程序中大量的简单函数，为了提高运行效率，一般都采用内联函数的方式实现。在循环语句中，对各种情况进行度量主要通过把临时变量提出到循环体外，以及设置break和c ontinue语言减少循环次数。在对大内存对象的参数传超上，例如仪嚣服务表结构，基本部是利用引用和指针实现，碱少系统在堆栈上的内存分配。在仪器的刻度计算中经常要用到各种各样的算法，采用在保证测井精度的原则下，根据测井原理优化算法，尽量把一些递归和非线性的算法，转换为非递归的简单运算。同时为了充分发挥Intel CPU的功能，我们选择Intel的C++编译器，做为系统的编译器。Intel编译器对CH错误检查比较严格，这也保证了程序运行时的错误减少。在开发库的选择上，我们也采用了精练的ATL库开发仪器组件，使用WTL库开发用户的界面，同时使用STL库进行数据结构的实现。耵L库的使用使得我们可以抛弃传统的MFC动态库，减少程序的内存占用，也可以减少MFC常见的内存泄漏。STL是经过考验的

C-++标准库，实现的代码精练高效，管理方便。经过我们测试，同样的数据结构如队列、链表等，STL的实现比MFC的实现，STL的速度大约快10%。

3、内存管理的优化

内存管理对系统也很重要，在测井后端显示程序中，由于要分配大量的小对象，例如曲 线和矩形等，通过分析性能测试数据，发现大量的小内存释放和分配，成为后端显示程序的 速度瓶颈，所以我们采用自己的内存管理机制来减少系统的调用。首完根据测试数据度量， 分配一大块内存给应用程序，然后通过管理这块内存，来满足程序对小内存块的请求和释放。 如果内存不足的话，可以另外分配大块内存进行扩充。通过采用自己的内存管理机制后，再 运行测试程序，发现程序的运行速度几乎提高了两倍。

4、输人箱牡砌眦

输入输出在系统的应用非常的多， 特别是本系统采用三层网络的结构，其中的网络输入输出更加的重要。为了系统取的最好的性能，我们对前端和主控之间， 主控和后端显示之间的网络通讯采用的部是多线程异步通讯的方式。与以前采用同步的方式对比，系统的速度提高了一倍，而且网络的故障也碱少了很多，基本没有发生网络通讯中断，和数据掉帧的现象。在本系统中还有一个比较关键的技术难点，就是在如何在显示测井曲线和图像时同步连续的打印出显示的曲线。由于程序的实时性要求，程序在网络通讯和数据计算上已经消耗了大部分的资源。在这方面我们主要采取的技术手段的同步缓存显示数据，然后在安排一个单独的线程专门负责测井曲线的打印。经过测试，打印和显示之间只有一米左右的延迟。在200：1的通常测井显示比例下，这点延迟是在允许范围内的。

5、软僻谈腻

测试并不能直接提高软件的性能，但是测试是提高软件性能酌有效手段。一个好的测试 工具更能提高工作的效率和质量。在本系统的开发过程中，我们主要是使用Rational公司的 Purityplus工具进行测试。特别是用其中的Quantify工具进行系统性能测试，可以精确到代 码行。通过它可以快速发现系统的性能瓶颈在哪儿，在哪儿耗时特别多，以及整个程序的远 行时间。大部份的优化措施都是在测试过程中发现问题，然后在进行具体的优化。

在采用以上各种优化措施后，软件系统的整体运行效率提高了50%右，今年上半年，整 个系统完成了系统联调。在下井实验过程中，在连接井下仪器、地面系统、和测井软件系统 的基础上，软件运行可靠，保证了24小时不断电的情况下，数据帧掉帧率为O，误码率为0的好效果，得到用户的认可。

在整个系统的开发过程中，特别是对软件的性能优化，使我认识到软件开发中采用不同 的设计和措施对软件的性能影响是很大的。好的测试工具对性能的提升有很大的帮助。在目 前对软件性能要求越来越严格的要求下，只有在重视测试方法和测试工具使用的情况下，采 用恰当的优化方法才能提高系统的性能。

论软件设计模式的应用

摘要：

本人20xx年有幸参加了中国石油集团的高性能数控测井系统项目的开发研制工作。该系统是在当前测井成套测井装备的基础上，为了满足高精度，高性能，高效率的要求开发的测井系统。该系统由井下成套仪器，测井遥测系统，测井地面系统，测井软件系统，测井解释评价系统等子系统组成。本人在其中主要是负责测井软件系统的分析、设计以及部分开发任务。设计模式是前人设计面向对象软件的经验和总结，在软件设计中灵活的使用设计模式可以极大的提高系统的稳定性，可扩展性，以及良好的可维护性。本文描述了在测井软件系

统开发过程中，如何分析和发现相关模式，以及如何选择和应用设计模式，特别是介绍了IKVC 模式在软件框架和相关系统模块中的应用和使用效果。在文章的最后，讨论了在实际项目开 发中，设计模式应用的有关想法和数训。

正文：

随着当前石油测井技术的发展，为了能更快，更好的得到储层地层信息，解、央目前国内测井系统不统一，测井精度不高，效率低下的缺点，20xx年1月中国石油集团公司科技局成立了高性能数控测井系统项目，目的是为国内测井行业提供一个从井下到地面以及解释评价的整套测井系统。系统的设计目标是一次测井，取碍所有合格资料，并且能保证60井故的免维修率。整个系统由井下成套仪器，测井遥测系统，测井地面系统，测井软件系统，测井解释评价系统等子系统组成。我主要是负责测井软件系统的分析，设计和部分开发工作。整个测井软件系统完成三个主要任务： 测井数据的采集、 测井数据的工程值计算、测井过程的监控。测井数据采集主要是采集井下仪器通过测井遥测系统传输的测井数据，并保证数据的完整性，正确性。测井数据工程值计算主要是把采集的数据根据不同仪器刻度计算方法进行工程值的计算。测井过程监控主要是把计算的测井数据用曲线和图像的方式实时的显示在屏幕和打印成图，由测井操作员进行实时监控。

设计模式是前人设计面向对象软件的经验和总结，在软件设计中灵活的使用设计模式可 以极大的提高系统的稳定性，可扩展性，以及良好的可维护性。在测井软件系统框架进行分 析和设计时，考虑如何提高系统的稳定性、可扩展性和可维护性时，我们采用了MVC设计模式。

7ltVC模式构架包括三个部分：模型(Model)、视图(View)、控制(Control)。模型主要是对系统的数据和逻辑运算的封装。它独立与系统的界面和1/0。视图把表示模型的数据和逻辑关系用特定的形武展示给用户。控制处理用户和软件之间的交互操作，当模型的数据有所变化时，控制负责通知视图做出相应的更新。模型、视图、控制的相互分离有利于模块之间内聚性的提高，耦合更加松散。一个模型可以对应多个视图，由控制来传播模型的变化从而更新视图。

J[tvc模式如何在测井软件系统实现，我们主要是从如下四个方面进行：

首先根据系统的主要任务进行系统的模块分解。根据测井软件系统数据采集、数据转换 和测井监控三个主要任务，把系统分为三个模块对应于IKVC模式的三个部分。其中模型(Model)对应于数据的采集和工程值的计算。测井视图( View)对应于测井监控功能。测井模型所要实现的功能包括：测井数据的采集、数据的刻度计算、数据的存储、数据的操作。测井数据的采集负责硬件平台的初始化，下井仪器的初始化， 井下仪器数据的中断相应，数据帧的采集，数据帧的重组等。数据的刻度计算主要是根据不同的仪器实现数据的刻度计算，包括刻度系数表的获取、刻度计算、深度延迟计算等。数据存储主要是原始数据的存储和测井数据的存储。这里我们采用的是测井公用的XTF格式做为数据存储格式。数据的操作是视图和模型之间数据交互的接口。它主要是提供数据输入相输出功能。

二、视图的设计与实现

视图主要是提供测井数据的图形显示。通过调用模型中的数据操作方法，提取测井数据， 根据不同的测井数据提供曲线、波列、图像等多种表现形式。在本系统的实现中，为了提高 数据采集的稳定性和程序的健壮性，采用进程间通讯的方式。就是说视图的实现本身一个独 立的程序。它与模型之间的通过TCP/IP网络进行通讯。视图主要包括数据源、数据表象对象、绘图打印模块等部分组成。数据源负责得到模型( Model)的数据，然后把数据分配给每个数据表象对象。数据表象对象是个有层次的类家族，其基类是绘图类（CDrawObj），所有的数据表象包括道( CDrawTrack)、曲线（CDx awCurve）、波列（CDr awWave）、图像（CDrawlmage），数值对象( CDrawData)等都是从其派生的。最后有绘图打印模块提供管理，

负责视图的区域更新，数据表象的绘制和打印等功能。

三、控制的设计与实现

控制主要功能是提供用户的输入输出反馈，同时监控模型的数据变化，通知视图进行更 新。由于控制和视图的耦合非常的紧密，在架构实现中，控制和视图是在一个应用程序中实 现的。控制主要分为井下仪器控制和视图控制两介部分。其中井下仪器控制主要是由操作人 员根据视图中的曲线和图像信息，对仪器发出的状态控制命令，以保证测井过程中数据和仪 器的安全。视图控制则是操作人员对视图显示参数的调整，包括鼠标的响应和键盘的响应以 及用户对测井原始图的特殊要求如道大小，曲线位置的摆放，颜色的调整等。

四、使用可动态添加算法模型

由于每次测井作业中下井仪器串的仪器种类和仪器的数量部是变化的，为了能更好的抽 象出实际的测井模型，提高系统的灵活性，在模型中数据刻度计算部分，我们采用的动态添 加的方式。我们把不同测井仪器的刻度算法封装到动态连接库，然后根据测井作业的不同， 调用用不同的仪器动态库中的刻度算法。由于视图和控制与模型之间的松耦合，当用户添加 算法模块，视图与控制基本不要修改。

在采用MVC模式的软件框架后，整个系统分为两个部分，数据采集管理器和数据实时浏览器。数据采集管理器对应于模型( Model)的实现，数据实时浏览器对应于视图(View)和 控制(Control)的实现。我们采用的是Visual CH -．net基于Window2000平台来进行系统开 发。采用MVC模式给我们带来了如下好处：

1、由于模型( Model)与视图(Vievr)相控制(Control)之间的松耦合，使得我们非常

容易就实现了一个模型运行同时建立多个视图。这在调试仪器时非常有用，当硬件人员调试 仪器时直接连接网线就可以一边看仪器一边看数据。不再需要象以前必须到地面系统控制室 查看数据了。

2、适合多硬件平台的跨接。由于不同的硬件平台上采集数据的方式部不同，有的系统采用的是PCI总线，有的是USB接入，有的是ISA卡接入。由于模型(Jrtodel)和视图(View) 的松耦合，当要移植到不同的硬件平台上是我们只有修改相应的模型( Model)，有可以实现 对不同硬件平台的支持。

3、良好的可维护性和扩展性。由于采用MVC模式，系统模块功能划分明确，代码实现也相对容易。代码的错误不会在系统中扩散，同时由于可以动态添加仪器算法模块，当用户添加新仪器时，不需要更改系统程序，只有添加仪器动态库DLL就可以了。

在整个系统的开发中，我们还应用了一些别的模式， 有些模式是在进行系统设计时，就考虑到而特意实现的， 有些模式是在采用别的方法实现后，效果不太理想，在代码重构时引进的。在应用设计模式进行系统设计和开发后，整个系统各个模块之间逻辑变的相对独立，耦合也很松散，结构的扩展性艮好。而且使得代码的重用的程度变好，减少了错误的发生和错误在代码中的扩散。但是在实际应用模式的过程中，我还发现模式应用的经验越丰富，模式应用的就越好。有时在采用何种模式时，有几种模式方案可以采用，但是具体采用那个模式就需要不断的尝试，看看模式是否满足实际的需要。特别要注意的是不能为了设计模式进行设计，也就是过分设计的问题。这样会导致设计过于复杂，偏离程序设计简约够用的基本原则。

目前设计模式在软件开发中的应用正引起广大开发人员的注意，各大软件开发商也在软 件开发工具中提供了有关设计模式的自动应用的工具，相信设计模式会越来越多应用于软件 的设计和开发中。

论软件的可维护性设计

摘要：

随着软件大型化，复杂化的发展，软件维护所耗费的资源越来越多，软件可维护性设计 日益得到重视。我单位近几年开发综合业务AIl/t交换机，用户对交换机的可维护性要求很高。

我参加了该项目并负责软件的维护性设计工作。根据当前工作中在维护性设计中的不足。通 过在各个软件开发阶段注重软件可维护性的应用，规范文档，使用CASE工具管理软件版本和．成立软件可维护性设计小组等方面，为软件的可维护性设计提供了帮助，并最终开发出具有良好可维护性的交换机软件。但是由于初次实施这方面的工作，大家思想上认识不够，许多操作不习惯，并且单位里不具备专用的测试软件和其它CASE工具，在一定程度上制约了软件可维护性的实施。

．正文：

经过一系列的需求分析、设计、编码和测试之后，软件正式交付用户使用。至此，软件 变进入维护期。软件维护的工作量特别大，随着时间的推移，软件维护对开发商带来的成本 压力也越来越大。许多软件开发商要把70%的工作量用在维护已有的软件上，平均来说，大型软件的维护成本是开发成本的4倍左右。因此，在开发软件时，就应该考虑到可维护性问题，进行软件的可维护性设计。

200 2年底，我单位开始为桌集团开发综合业务ADK交换机。该交换机支持多种业务应用，包括话音、IP数据、图像和视频等；用户可通过维护台或网管对交换机进行配置和管理；由于特殊的应用，用户对该交换机提出了很高的要求，并且提出要求产品交付使用之后，裁单位要有很好的服务支持，鉴于将来要大批量生产交换机，软件的可维护性设计被提上日程。 我有幸参加了该项目，并负责软件的维护性设计工作。

在以前的澡题中，也曾提到过要进行软件的可维护性设计，但在真正实施过程中，还存 在诸多问题，主要表现在：

(1)在软件开发过程中对可维护性设计考虑欠缺，导致软件设计从根本上就忽视了可维 护性的重要性。

(2)软件设计文档不规范，内容不一致。在维护阶段出现问题，根据文档不易得到有帮 助的信息，难以定位错误的类型和根源。

在本交换机软件的设计过程中，我们通过注重软件可维护性的开发过程，规范文档，使 用CASE工具管理软件版本和成立软件可维护性设计小组等方面进行软件的可维护性设计，最

终开发出具有良好可维护性的交换机软件。

一、注重可维护性的开发过程

在整个交换机软件的开发过程中，从软件易于理解、易于测试、易于修改的角度出发，提 高软件的可维护性。

在需求分析阶段，和用户进行兖分的交流和协商，对将来要改进的和可能要修改的部分进 行明确。由于该交换机所涉及的业务种类广泛，并且综合了话音、IP和网管等多种技术，任 何一种技术实现的功能不完善或者扩展性不好，都不会让用户满意。但是，另一方面，又考 虑到用户需求和功能需求并非容易获取，所以通过和用户定期交流，举办各种形式的讨论等 方式尽可能了解当前的需求和以后需要扩展的需求信息，由专人整理记录这些信息，作为以 后的跟踪内容。即使在其它设计阶段对需求的临时变动，也要在这个记录中体现。 在设计阶段，交换机软件被划分为不同模块进行设计，并遵循“高内聚、低耦合刀的设计

原则；这些工作便于将来软件维护工作的进行。同时也已考虑到，对可能要扩展的地方，预 瞽出充足接口。在一些模块中，如网管模块中，根据功能，尽可能使用面向对象的设计方法， 以便维护时的修改和升级。

在编码阶段，我和小组成员制定了统一的编码规范，经过半天的培训，强化编码人员对注 释的使用，并强调要保证注释的质量，对有可能出现误解的地方，注释的要详细。并且，每 个文件都要注明编写者，生产日期和版本号。

在测试阶段，测试组成员已经负责进行测试，我们小组这时的工作是根据测试报告，对照 测试大纲和用例役计，对当前的测试进行总结，比如，何种测试用例发现何种错误，最常见 的错误，如何从测试结果判断是哪种错误，该错误所在的模块是什么。在相关人员修改错误 时，记录排错时的思路和过程。特别是，根据这些总结，我们编写了“ATM交换机软件故障解析刀，这篇总结在后来的维护阶段被证明是最受欢迎的文档之一。

在维护阶段，制定严格的管理要求。每一次维护工作之后，都要按照配置关联，同步更新 维护有关的系统文档和用户文档，包括维护需求、源代码、注释、设计文档、测试文档和用 户使用手册等，保证系统的一致性。维护中所进行的修改要专人记录，生成c ATM交换机维护更新”文档，做为内部文件存档。同时把一些内容扩充到c ATM交换机软件故障解析”中。在用户使用时，做好用户的培训工作，初期由专人和用户一起操作交换机，直到能熟练操作， 以免用户使用交换机时产生不满。

二、规筢＆挡

交换机交付用户使用之后，除了在培训时所了解的内容之外，为了让用户对交换机软件能够更好的理解和使用，向用户提供了多种随机文档，包括功能说明，安装文档，用户使用手册，参考手册，管理员指南等。在文档的编写过程之前，我们编写了cc ATM交换机软件文档编写规范”，对文档格式相一些必要内容进行了规范，保证各文档的风格一致，内容一致。对于一些用户使用中容易出错的地方，比如配置某种功能时，在用户使用手册示例说明。在具体编写文档时，根据设计人员的反馈信息，也及时调整了文档编写规范。

在设计开发过程中，对某个问题进行修改，或者功能增删，要充分考虑到问题所涉及的不同文档，保证前后文档在该问题的一致性。对于所修改的部分，要填写“更改单”，需要写明更改人，更改理由，更改所影响的程序和文档，更改日期，批准人。采用CASE工具在这一方面也起到了事半功倍的作用。

三、使用CASE工胡蝗塞鹦刘牛版本

在软件的设计编码过程中，尤其是在调试阶段，会不断的生成新的程序版本。为了有效 的管理版本问题，采用Ration公司的ClearCase工具，由专人负责进行管理，从而保证软件 版本的一致性。

四、成立软件可雏护性设计小组

为了有效的对软件可维护性设计进行管理，成立了软件可维护性设计小组。我担任小组组长，明确了维护性设计的工作内容和各人的责任，针对不同的模块，又确定四个责任人。在运作过程中，组长对软件开发阶段所需进行的工作进行协调，各负责人对维护性设计所涉及的变动控制进行维护。

因为交换机软件的各个模蛱开发时间有穿插，因此，对开发过程中出现的一些问题，包括 技术方面和管理方面的问题，残们部及时进行了记录，对后面开发的软件模块进行指导，避 免了同样问题的再次发生。现在这份文档已经成为单位新课题启动时的“必修”文档。 按照上面的思路，经过两年多的工作，我们已完成了交换机软件的开发，新的软件运行良 好，交付用户后，用户很满意，受到了业务部门和技术部门高层的赞许。尤其是我们所总结 的c ATM交换机软件故障解析”和<l ATM交换机软件文档编写规范刀等文档，对单位其它课题也起到了很好的指导和规范作用。并且，在提高软件可维护性的同时，也提高了软件产品

的质量，我自己的开发管理水平也得到了很大的提升。单位的高层领导对我们制定的规范和做法也表示认可，正式在其它课题中推广。

然而，由于初次在整个软件开发过程中进行可维护性设计，还有许多要改进的地方。许多 情况下，现有的可维护性设计措施理论性太强，具体实施时可参考的依据少，比如我们测试 小组如何更好的与各课题开发组间进行协调工作，感觉还是有不尽人意的地方。在测试阶段， 单位条件所限，没有采用专业的测试软件进行测试，主要靠人工根据经验生成测试用例，测 试力度不够，隐含的问题较多．这也不利于今后的维护工作。

软件可维护性设计是一个长期的工作过程，我希望今后能够不断的充实自己在这方面的知 i坦世越休台匕卡 晶茧特许让可罐抽●吐沿：牟亡鬲坦世辑的hZ纳田吆

论行业应用软件系统的开发规划

摘醒：

本文通过地震基本参数快速获取与发布系统论述了行业应用软件系统的开发规划。本人 去年有幸参加了《地震基本参数快速获取与发布系统的研制》项目的开发，该系统按功能被 分为三个子系统：地震实时波形数据监控子系统；地震事件处理子系统；数据发布子系统。 该系统具有地震行业的专业背景，需要地震监测中心（用户单位）、地震监测专家和项目开发人员间良好的分工协作；与常规的通用应用软件开发过程相比，具有明显的差异，主要表现在系统的分析、设计、实现、测试和维护均带有明显的行业特点。行业应用软件的成功开发必须遵循行业规范，正确使用专业术语，及时与专家和用户进行交流。

本人在项目中主要负责需求分析和软件系统设计，在实践中我发现，行业应用软件系统 的成功开发是从其规划到诞生起就应从行业中汲取各种营养，才能长出行业特征，具有行业 味道，满足行业应用的需求。

正文：

本人去年参加了《地震基本参数快速获取与发布系统的研制》项目的开发。在项目中担 任组长，负责项目的规划、分析、设计。由于防震碱灾是公共安全的重要内容之一，该项目 主要针对大地震的震前预警和震后消息的快速发布，是防震减灾工作的关键业务系统，是地 霹应急工作的支撑技术系统之一，对公其安全具有重要意义。项目范围包括：地震数据采集、 传输、存储、处理、发布；该系统是一个硬、软件相结合的信息系统；硬件包括：拾震器（地 震波形采集器）、数据传输设备（基带modem和多路复用器）、多用户串口卡、服务器、手机。软件可以安功能分为三个子系统：地震实时波形数据监控子系统；地震事件处理子系统；数据发布子系统。

由于地震行业的专业性强，由开发人员现学领域知识是不现实的，这就需要用户和行业 专家的协助。

聘请行业专家做项目组的顾问是应用软件开发过程中较好的策略。行业专家主要是作为 领域知识源，提供技术文件和已有应用。在地震系统的这个项目中，我们聘请了地震监测系 统的资深专家作为项目的顾问，获取到《地震数据分类和共享指南》等技术文件和部分以前 编写的源代码，该源代码是多个独立运行的、凌乱的、较小的系统，经过整理后可以用到新 系统中，这为领域模型和设计模型的建立打下了良好的基础。

用户是应用软件目前和未来的需求提供者，其对项目成败的重用性是显而易见的。OOA 过程是从对系统将被使用的方式的理解开始的。在需求诱导时需要从用户的观点对系统建模， 需要项目组和用户共同确定使用场景和定叉系统的功能和运行需求；需要用户提供清楚而无

二义性的终端用户和系统如何相互交互的描述；需要用户提供确认测试的基础。在地震项目 中，我们与用户充分合作，请用户给我们讲解地震常识和本项目涉及的专用仪器的功能，将 用户作为项目组成员，作为每个阶段的技术评审的主要成员。

开发者是应用软件系统的建设者，需要从用户方进行需求诱导，建立领域分析模型；需 要将分析模型变换为设计模型，建立软件的构造蓝图；需要完成编码和测试。由于应用软件 具有行业背景，在建立分析模型是需要从各种渠道了解行业知识；在建立设计模型是需要使 用逆向工程技术从现有的系统中得到关键的算法。在进行测试时需要使用用户提供的具有行 业特点的真实的测试数据。开发人员需要随时在涉及到行业知识时向用户或行业专家请教， 必须克服在开发一般应用软件时的问题讨论在相对封闭的范围内进行的特点。

与常规的通用应用软件开发进行比较，专业背景的应用软件开发过程及各个环节的主要 差异有：

(1)在计划阶段，具有行业背景的应用软件系统与普通应用软件的目标与动机一般是不 同的，普通应用软件以给本公司或部门带来经济上的收益为目的，而行业应用软件以更好的 完成某项政府职能为目的。地震行业的应月系统开发目的是为了有效的减少地震灾害造成的 损失。系统方案的制定必须符合行业的特征。地震具有突发性、不可抗拒性、影响面广、广 大群众积极参与、数据量非常大、算法复杂等特征，在系统方案制定时必须针对这些特点进 行。在地震行业的应用系统中，从拾震器（地震波形采集器）、数据传输设备（基带modem和多路复用器）、多用户串口卡、服务器、手机到通信信道均实现冗余备份，当任一环节出现故障时，均能由热备件自动接管任务，应用软件必须支持这种功能。这就增加了应用软件开发的复杂性。

(2)在需求分析阶段，行业背景的应用软件系统与普通应用软件相比一般需求比较明确、 相对固定和有章可寻。必须获得行业的各种技术规范、数据共享资料及现行系统的运行数据。 在此基础上划出应用软件的作用范围和与周围环境进行数据交换的接口，在类的划分时需要 从行业术语中选择类的名称，类的属性需要在专业知识中有明确的定义，类的方法也需要使 用行业内的主流算法；在地震行业的应用系统开发中，分析模型的建立需要从行业中得到基 本素材，从行业知识和管理中得到优化，产生出行业专家认可的类一责任一协作者模型和对象一关系模型。

(3)在设计阶段，行业背景的应用软件系统与晋通应用软件相比，从用户界面设计、数 据管理、任务管理到控制机制均要表现出行业特征。我们在开发地震应用软件时，邀请有专 业知识的用户参加到项目组实施的关德环节中，将设计模型在地震行业进行各种地震知识的 解释。确保设计模型与领域模型保持一致。在描述每个子系统并将其分配到处理器或任务时， 子系统设计需要由行业中完成特定的功能的“层次”来确定；地震实时波形数据监控子系统 需要完成各监控点的数据采集、地震事件识别和生成地震事件数据地震；地震事件处理子系 统需要完成大数据量的传超、进行各种复杂计算和生产地震的各类基本参数；数据发布子系 统需要完成在有新震情时第一时间以web或手机短信的方式对相关用户群进行数据广播；各子系统间通过分布式数据库完成数据复制和保证数据一致性。数据和任务管理的设计策略需要参考与《地震数据分类和共享指南》相类似的行业标准；用户界面设计也要根据地震数据的特点和物理意义来展示数据；为系统设计具有行业特点的控制机制，在地震应用软件中， 我们采用地震触发作为系统的控制机制；通过创建每个操作的过程表示和类属性的数据结构 而完成对象设计，数据结构和算法必须符合行业需要；使用对象间的协作和对象关系完成、捎息设计。在评审设计模型时需要行业专家和用户的参与，从行业的角度提出修改意见。

(4)在集成测试阶段，行业背景的应用软件系统与普通应用软件相比，一般更强调进行 B测试和进行新1日系统对比，需要使用行业的数据作为测试数据，测试案例需要由用户和专家参与制订，行业数据需要由用户和专家提供，测试结果需要由用户和专家确认和解释。

由于地震数据具有突发性，当地震发生时系统的数据量非常大，因此系统测试需要在真实的数据环境中进行。我们在测试地震应用软件时使用的是真实的地震数据，从数据的采集、传输、存储、处理和显示等的各个环节均使用的是地震事件数据，根据测试结果和用户意见进行修改。

从上面的几个主要差别可以看出，具有行业背景的应用软件的开发需要行业中的各类标 准、专业知识、现有相关系统和人员参与到开发过程中，要使行业特点与信息技术有机结合， 在项目管理上还需要包含行业内的相关的人和物。

在地震应用软件的开发过程中，人员、设备、资科等的方方面面的资源均是由项目组与 地震系统共享的，在知识和思想上充分融合，经过双方的共同努力不仅开发出了满足地震行 业需要的应用软件，还丰富了双方的知识面，拓宽了眼界。

本人在项目中主要负责需求分祈和软件系统设计，在实践中我发现，行业应用软件系统 的成功开发是从其规划到运行的全过程中均应从行业中汲取各种营养，才能长出行业特征， 具有行业味道，满足行业应用的需求。

论企业信息化战略规划技术

摘要：

本文通过建立就业服务系统的信息规划，讨论了企业信息化战略规划技术。企业信息化 战略规划在企业信息化建设中占有非常重要的地位，是企事业信息化建设成功与否的关键。 我们采用的方法是，成立信息化建设领导小组，由主要领导担任组长。一、了解就业服务系 统的战略目标，使信息化的战略目标和就业服务系统的战略一致。二、统一部署，进行资料 收集，除考察现有软件系统外，还要考察手工操作，形成资料，制作功能表。三、根据收集 I的资料，我们采用自顶向下规划与局部设计相结合的方法制定出了信息系统的框架。四、加强培训，提高员工素质。

本人在此次战略规划中担任技术层面的工作。

正文：

企业信息化战略规划，在企业信息化建设中占有非常重要的地位，是企业信息化建设成 功与否的关键。

本人有幸参加了市就业服务系统的信息化建设规划，担任系统分析和需求分析等相关工 作，主要负责技术层面的问题。

随着社会的发展，加强信息化建设成为各单位的首要任务。为了建设“数字城市”，加 强就业培训的管理工作，构建信息化的培训管理格局，我们开始着手进行全市的就业培训信 息化建设，根据省里的要求，做到同人同城同库，实现就业培训的“实名制刀。

目莳，就业服务系统的信息化建设缓慢，各单位各自为政，分别开发了不同的信息管理 系统，这些系统的开发，没有统一的标准，系统之间互相不“说话”，无法实现数据共享，浪赞了巨大的人力物力。为了从根本上改变目前的混乱状况，在上级领导的支持下，在20xx年我们开发了就业服务系统的管理软件，实现了资源其享。

就业服务系统管理软件涉及到就业服务系统几个相关单位，包括培训、考核、职业介绍、 就业、财政等单位。就业服务系统管理着全市失业人员的所有信息，要求系统具有从失业人 员登记，发布培训信息，用工信息，到学员参加考核，顺利就业为止等一系列功能。

为了使就业服务系统的信息化建设达到预期的目的，我们进行了战略规划，成立了就业 服务系统信息化建设领导小组，由主管就业服务系统业务的领导担任组长，主抓此项工作。 具俸实施的步骤如下：

一、我们根据全系统发展计划的文件，全面了解本系统的任务，目标和长期发展的战略 规划。我们和上层领导座谈，认真了解全系统的任务和目标，及时，方便，准确，快捷为下 岗失业人员服务，是我们工作的宗旨。认真阅读相关资料，准确理解长期发展的战略规划。 根据需求做好设计，形成报告，请有关的业务专家来进行讨论，并参考就业脆务系统的 发展计划，检讨我们制定的信息化战略规划是否符合战略发展计划。

二、由信息化小组招集各单位各部门的负责人开会，统一布置了全面进行信息化建设的 事宜，要求各部门配合信息化小组的工作，把全系统的信息化建设工作做好。

随后我们紧锣密鼓的展开了调研活动。资料收集是非常重要的，没有详细真实的第一手 资料，要想进行战略规划就是纸上谈兵，建设空中楼阁。

首先，我们考察现有的软件系统。

由于本系统有独立功能的业务部门，他们已有现成的信息系统。为了了解各业务部门现 有软件，我们制定了各业务部门软件系统调查报告。该报告主要要求各部门填写现行系统的 现状，主要内容包括：软件运行的操作系统，使用的数据库管理系统，主要的数据库和表以 及表结构；现行系统运行所占用的空间大小，主要表的大小，软件的业务流程，基本框架结 构等内容。

其次，对各单位的手工业务活动，进行调查。

我们主要采用了“请进来，走出去刀的方法进行工作。

我们根据各单位提交的业务报告，请相关的业务骨干，进行讲解。并对不理解的地方进 行提问，从而把业务流程“吃透吃准”。为进一步形成功能表打下坚实的基础。

我们到各单位进行走访，现场观摩和实习操作，对各业务部门的流程有了更进一梦的理 解。在进行走访活动之前，我们详细研究了各单位的资料，对其中描述的不清楚或者不明确 的地方，做了重点标注，并记录下来，以备走访时使用。除了观摩和操作外，对业务人员和 技术人员，按照事先准备好的问题进行采访。

第三，形成资料，制作功能表。

根据各单位提交的报告和我们走访的结果，对形成的文档资料，我们进行了整理。为了 清楚的表达各业务段的流程，我们使用Visio制作了各种业务流程图，并用Excel制作了所 需的所有表格，对表格的名称进行了统一，把各单位五花八门的表名进行了修改。例如：有 单位把一月一报的表格叫月报，其中的内容为每日的内容，而对每月的累计报表，也叫月表； 我们把表名进行了修改，规定：含有每日数据的报表叫日报表，含有每月数据的表格叫月报 表。如果有多个月表，则能合并的就合并，不能合并的，则叫月表一，月表二，或根据报表 的主要内容进行相应的命名。表格名称统一以后，便于交流，省去了许多解释的时间。 我们根据各部门的业务活动制定出了各部门功能表。

文档制作完成之后，我们进行审查，这次是由我们来讲，各业务单位听，对我们理解不 对的地方进行修正。如此反复几次后，可以基本确保我们获得资料的正确性。

三、根据采集到酌资料，我们采用自顶向下规划与局部设计相结合的方法制定出了信息 系统的框架。将整个就业服务系统的业务分为相对独立的几个部分，失业人员管理系统，培 训管理系统，鉴定考核管理系统，就业管理系统等。对于一些具体的业务采用局部设计的方 法进行，如：报名，分配培训机构等。

我们设计了人员档案主题数据库，主要用于管理失业人员的各种情况，如：就业，培训， 考核，技能等级，家庭住址，所在街道等信息。此数据库由各管理系统进行维护，保证数据 库信息的及时、准确。

四、加强培训，提高人员素质。

在我们的调查过程中，发现各单位使用计算机软件系统的人员素质较低，对信息化几乎 没有什么概念。开发出来的信息系统，需要使用的是“人刀，没有人员素质的提高，盲目的

进行信息化建设，也是很难成功的。

为此，我们组织了多期电脑扫盲班，提高班，加强了员工对信息化建设的认识，以及进 行信息化建设所能带来的各种优点。通过培训，提高了员工的操作水平，为我们与各单位业 务人员进行沟通起到了良好的作用。

总之，就业服务系统的信息化建设起步晚，底子薄，经过信息化建设规划后，为开展信 息化建设指明了方向，为就业服务系统的信息化建设起到了良好的作用。

目前，本系统各单位已经便用了新的软件系统，结束了各单位各自为政的历史。但这仅 仅是完成了信息化战略的第一步，为实现数据仓库，建立决策支持系统提供了基础。

在现阶段，本单位的信息化也仅仅是在业务方面进行的。其它方面的信息化建设依然开 展不够。例如内部办公系统仅有和上级部门相联的一个办公系统，内部办公效率不高，手工 操作还是比较多。对已有系统的利用率还不是很高，领导、央策也没有完全借助计算机的帮助。计算机的使用大部分还停督在打字机的水平。要解决这些问题，我认为主要是领导对信息化建设要有足够的重视（特别是一把手），不能仅仅停督在口头上，要有实际的措施。比如领导要参与培训和计算机的使用，并增加一些物质鼓励。在已有信息系统的基础上，经过若干年的数据积累，构建数据仓库，决策支持系统。建立内部办公系统，邮件系统，使各部门员工自首自愿的使用计笪机来游行工作，娄到信息什．津设带来的好受卜。

论软件产品线技术

摘要

根据公司软件系统开发的需要，我们在软件的开发过程中引入了软件产品线技术，成立 了基于软件产品线的项目组。本人有幸参加了该项目，并在其中担任软件分析与设计、软件 产品线核心资源开发的工作。

在软件产品线的开发过程中，我们使用了ROSE建模工具，有效地完成了产品线中核心资源和产品的建模分析与设计实现；我们使用了国际标准POSC数据模型框架，有效地解决了数据的多样性与可扩展性，实现了统一开放的测井数据访问系统；建立了统一的可扩展的地质绘制组件和统一公用的数据处理模块。最终圆满的完成了公司产品线的建立和各子系统的开发。

正文

我公司是中国西部最大的石油测井服务公司，主要从事测井工程服务、测井仪器与测井 软件的研发工作，在公司内部已经开发了多套测井数据软件，其中包括测井综合地面监控采 集软件、测井数据解释处理系统、测井实时快速处理与解释系统、生产测井解释系统，分别 由多个项目组分别开发。

其中，测井综合地面监控采集软件主要配合公司的综合地面系统，通过与地面硬件系统 的前端计算机的通讯，实现对井下测井仪器状态的实时监视和控制、测井数据的实时采集和 显示。整个软件分为通讯模块、数据采集模块、实时解码棋块、实时简单处理模块、实时显 示模块、实时出图模块和主控界面模块等。

测井数据解释处理系统主要完成测井数据的测后处理，包括测井数据的解码、数据编辑、 环境校正、常规处理、成像处理、成果图绘制、解释报告生成等功能，整个软件按分层架构 开发，包括系统底层（包括数据底层、绘图底层、通讯层）、业务逻辑层（包括各种测井数据处理模块）和应用软件层（包括数据解码程序、数据编辑程序、深度校正程序、综合绘图程序、解释报告生成程序等）。它主要是针对勘探开发测井中产生的新井的测井数据处理，所涉及到的数据主要是按深度采样的连续的测井曲线数据，而成果图主要时一种按深度比例

的连续的测井图。

测井综合地面监控采集软件和测井数据解释处理系统均以推出了多个版本，进行了大范 围的生产运用。而测井实时快速处理与解释系统和生产测井解释系统是我们正在准备开发的 系统，测井实时快速处理与解释系统主要通过通讯卫星与在野外进行工作的测井车上的测井 综合地面监控采集软件进行数据通讯，准实时的获得测井数据，然后由在解释中心的测井解 释专家根据邻井资料和区块经验进行实时分析，整个平台分为实时数据通讯模块、实时解码 模块、实时处理模块、实时深度校正模块、实时坏境校正模块和实时绘图模块等，而生产测 井解释系统主要完成石油开采后期动态监测时的测井数据的数据处理，测井数据主要是离散 的测井曲线数据，在数据绘制上和处理上与测井数据解释处理系统类似。

在以上的各个项目中本人主要负责了测井数据解释处理系统的软件分析与设计、软件构 建的工作。对于以上的各个系统，如果用抽象的视角去观察，我们可以发现，其实他们处理 的对象是一样的都是测井数据，在功能上部是获得数据后，处理数据，然后按规定的绘图格 式展现给测井工程师，所不同时各系统的侧重点不一样，测井综合地面监控采集软件主要是 完成对测井数据的采集工作，和通过数据的曲线图形方式监视井下仪器的工作状态和测井数 据的正确性，对系统的实时性要求比较高；测井数据解释处理系统主要完成测井数据的测后 处理和测井数据的多角度观察分析，对实时性和可靠性要求不是很高；生产测井解释系统与 测井数据解释处理系统基本层次结构相似，只是数据的格式和显示方式不一样；测井实时快 速处理与解释系统对实时性要求稍高一些。通过以上对系统的分析可知，在以往的开发中我 们各个项目组的人员实际在数据的存取、测井曲线的显示、测井数据的处理方面我们做了大 量了重复性工作，各个项曰组都形成了自己的一套软件架构，在资源上造成浪费、且代码质 量不能够得到有效保证。因此，由于数据存储和处理的一致性和绘图方式的一致性，我们可 以引入产品线技术，有效的提高公司的软件系统的复用性和可扩展性，同时能够有效体提高 公司软件的开发效率和质量。

我们给上级领导提出了合并测井综合地面监控采集软件项目组和测井数据解释处理系统软件项目组，成立公司的软件研发部，并将测井实时快速处理与解释系统和生产测井解释系统交由软件研发部来进行开发，在软件研发部，依托测井综合地面监控采集软件项目和测井数据解释处理系统软件项目的软件开发经验建立公司的软件产品线，这个建议得到了上级部门的一致肯定，最终成立了软件研发部，其下根据软件产品线的要求设立核心底层组、产品组。

核心资源的建立。核心资源就是在测井行业软件中能够其享的部分。数据存储与访问部 分、通用测井数据处理方法模块部分和测井曲线绘图部分，在我公司已建立和即将建立的各 系统中部是高度共享的。由于我们的核心开发小组的成员就是原来各系统开发的核心成员， 对原系统部有充分的理解，加上成立统一的核心小组后，更方便程序开发人员的之间的交流 与沟通，我们很快就核心资源的需求达成了其谀，对于需求的分析和核心资源的设计，由于 核心资源涉及到的系统边界较多，特别是测井数据的存储与访问接口，因此我们使用了Rose 建模工具，通过对原有系统的逆向工程和UML建模分析，理出了核心资源的接口设计和核心资源子系统的划分和子系统内各设计类，最终有利于我们建立合理的核心资源软件架构。 在数据存储与访问部分，由于设及的测井数据格式较多，难以形成统一的数据存储格式 和访问接口。通过采用国际石油软件组织的POSC行业标准有效的解、央了这一问题，使用POS(的Epicentre数据模型实现测井数据的统一化存储，而POSC的DEA标准描述了数据的存取交换的方法，使用DEA使我们的系统具备了数据访问的标准接口。另外由于采用了国际通行的POSC标准，使我们的软件具备了开放性，能够支持满足POSC-Epicentre数据模型的所有数据格式和对外提供基于POSC-DEA的标准数据访问接口，使得我们能够方便实现与第三方软件的数据交换。

测井数据处理部分，根据处理的通用性，将处理包分为通用数字信号处理包和测井专用 处理软件包，将数据滤波等通用数字信号处理方法放到一个包中，将测井行业专用的POR处理方法等放到一个包中．实现了方法模块的高效复用。同时使用简单工厂模式实现了处理模块的动态加载。另外在构建测井数据处理构件时，由于测后处理和测时处理模块的处理方式不一样我们很难进行统一接口的设计，测时处理主要是基于深度点的单点处理模式，而测后处理是基于深度段的处理方式，测后处理由于处理的复杂性可能会用到历史数据，在实现处理模块核心资源时，我们以单点处理模块为主，使用模块聚合方式实现了基于深度段的处理模块。而核心绘图资源的建立过程中也遇到了同样的问题，主要是实时系统和测后解释系统之间的绘图方式的不同，一个时基于深度点的行模式一个基于深度段的绘图模式，数据对象绘制图件较多，实时系统注重绘图的实时性，测后处理系统更关注绘图的效果。但是在图头的绘制上具有相同性对实时性要求不高，且图头的绘制要求基本一致，因此通过建立了一套图头绘制子系统和两个版本的绘图子系统，以应对不同的时间响应需求和绘图质量。 通过使用软件产品线技术，最终有效地提高了公司软件生产效率和质量、缩短了开发时 间、降低了总体开发成本。但是也遇到了一些问题：1）核心人员原先都没有从事软件产品线的开发，往往只关注自己熟悉领域的软件设计，没有全局的观念，为此我们通辽加强团队人员间的淘通，互相了解彼此的领域，使开发人员的全局观念加强，另外通过软件架构设计培训，提高软件人员的架构观念；2）没有合适的构件集成工具，处理流程的建立主要依靠代码来实现，因此在未来的开发迭代周期里有必要开发集成工具。

论软件产品线技术

摘要：

本人作为某软件公司负责人之一，通过对位于几个省的国家甲级、乙级、丙级设计院的 考查和了解，我决定采用软件产品线方式开发系列《设计院信息管理平台》产品。

该产品线开发主要有如下功能：1）知识、资源管理平台； 2）内部管理平台； 3）基于WEB的办公平台。软件产品线最难开发的是核心资产的分析与建模，如何从用户重多不同需求中抽象出共性的东西，如何使得核心资产通过继承、参数化等方式能够组装成用户实际需要的产品，我以及我们公司的系统分析员做了大量工作。概括起来我们用了如下三种方式：

(1)加强核心资产开发的灵活度，部分产品作成用户能够自定义的功能，彻底免除产品化时的问题，但这样做难度很大，实施周期长；

(2)说服客户微调管理模式，以使得管理适应我们的产品线功能。这样做无疑是“双鬲 的刀，但是实际不见得会行得通；

(3)根据流程最长的需求开发所有需要的构件，构件间的接口做成松藕合。演化成产品 时进行构件组装。

正文：

本人所在软件公司于20xx年6月承接了某《化工乙级设计院管理平台》工作，主要功 能包括：1）知识、资源管理平台： 2）内部管理平台： 3)基于WEB的办公平台。该项目于20xx年2月成功授入运行，得到客户的肯定。该项目的开发成功以及通过与该设计院员工的接触，对我触动很大。我作为公司主要负责人与其他负责人研究后，决定进入“设计院信息工程”这样的一个行业领域做深度软件产品开发。理由有如下几点：

1)设计院是一类知识技术密集型单位，员工素质较高，管理比较规范，有完善的硬件设 施一性能良好的局域网平台，具备了实施信息化管理的基础；

2)设计院的图形工作站所用的二维、三维软件或其它工程计算软件部用正版软件且价格 比较昂贵，高层领导他们有支付软件费用的观念；

3)设计院开发一个项目，从可行性分析到项目实施、项目交付、到项目后期支持往往需 要几年的时间，这期间产生巨量的、非常重要的各类文档（比如可行性分析报告、进度计划、 项目条件、变更记录、会议纪要、计算书）和大量工程图，在整个项目开发期间这些资料要 提供给项目开发人员查阅或使用、修改，这些资料的安全性、完整性部是至关重要的，这些 资料既是知识、技术的承载俸、又是法律的承载俸；这些资料保存年限是30年或更长。目前

设计院大部设立专门的部门，但基本部是采用手工管理。

4)设计院的客户在项目开发期间以及项目上线以后一段时间部希望得到良好的技术服 务。技术支持骶包括现场技术服务，也包括远程服务。现在的远程技术支持是很被动的接听 客户电话、传真或EMAIL，没有建立专门的平台也没有进行规范管理。

有了对设计院内部运作的一般了解后，我们将已经开发成功的某《化工乙级设计院管理 平台》精简做成演示原型，我带着这个原型以及对《设计院信息管理平台》的设想来到本市 各类设计院：省级建筑设计院、市级建筑设计院、省级电力设计院、省级化工设计院、大型 企业内部设计院等大大小小20家，征求他们的意见和建议，了解他们对该管理平台的认可度。我感到很欣慰的是80%的设计院高层领导对我们的产品设想有兴趣，并提出了针对自己单位的需要扩充或压缩的功能。随后的一个多月我带着补充修改后的原型产品，来到另外几个省会的设计院征求意向，结果：1）大部分的设计院目前没有完善的管理平台；2）如果我们真能设计出满足他们需要的产品，他们有兴趣购买。

通过持续2个月的调查我们公司于20xx年5月决定投入这个行业的软件开发，因为要开发大量类同的软件产品，公司决定采用软件产品线开发。我们的对该系列产品的设想是： 这样划分的理由是：不同级别的设计院规模大小、管理模式、职能部门、待管理的资源 区别非常大，国家甲级设计阮除了设计以外，还能做技术咨询、工程总承包、建设监理、设 备材料供货等工作，承接国际性工程。而丙级设计院一般隶属于相关厂矿企业，只能做本单 位的项目开发，所以管理规模、管理资源相对较少，乙级设计院则界于两者之间。在同级别 的设计院中，则因为设计院的性质不同，开发所采用的步骤和侧重点不同。该系列产品主要 功能：

1)知识、资源管理平台：管理内容包括工程图纸、各类文档（可行性研究报告、项目计 划、条件变更单、项目会议纪要、来往传真等）、标准图库、标准及规范、招投标书、合同等；

2)内部管理平台：包括项目管理、人力资源管理、供应管理、客户关系管理、员工绩效管理 等3）基于WEB的办公平台：用于对客户的远程技术支持、保持与关键设备供应商、国家级研究机构的快速联系、快速获取新技术新行业信息、推广公司形象。

确立了产品线开发的基本思路以后，我采用一种动态的组织结构进行开发，初始阶段将 公司主要技术力量集中起来进行核心资产开发；计划当我们的核心资产开发已经有几个实际 产品之后，逐步将重点放到产品开发上并不断演化我们的核心资产。我、央定核心资产的开发先重点考虑“乙级设计院”级别，这样做的好处：将来开发丙级设计院产品，只需做遁当的功能裁剪；另外避免了开发甲级设计院管理平台的技术风险和项目风险。

建模我们采用ROSE 2003，对需求分析的评估则采用RequisitePro，软件开发平台选用 J2EE，数据库选用ORACLE，这样做主要考虑J2EE的平台无关性。在开发平台的选择中我们曾经考虑选用．NET，因为。NET开发相对简单和快捷，但。NET限制服务器在WINDOWS平台上运行，考虑我们今后客户中的“甲级设计院”，服务器一般部采用UNIX系统，为便于今后产品的移植，我们选择了J2EE。版本控制工具选用ClearCase。

核心资产开发最主要的是如何从众多不同需求中抽象出相同部分，并进行概括或分类。 比如我们对员工绩效管理分析时就发现，相同的部分是：输入均为图纸量、其它文档、项目 总利润、职工职称等，输出则为与项目相关的奖金。但是对奖金的算法，基本每个单位有自 己的一套公式：有的对图纸量分专业计算复杂度系数；有的按本专业计算复杂度（比如关键 技术、新技术或普通技术）；有的按复用度（该图纸与原有图纸的相似度）计算折扣；有的不分职称只计算单纯的图纸量；有的则考虑职称或工龄；有的将计算书折算为图纸进行考核； 有的专门对计算书或其弛文挡考核、有的计算考虑加班有的不考虑。

面对我们从20来个设计院收集不同的考核方法，我以及我们的系统分析员确实伤透了脑筋。如果全部采用抽象类或接口来实现，那么抽象的层次肯定比较多，产品开发人员今后很难理解核心构件的意图，而通过组装类构造的话，组装类的开发工作量比较大。而最大的问题则是如何适应用户考核方法的变更。我们最终的做法是：收集和整理20来个设计院的考核方案中所有考虑因素的全集，对这些全集进行分类，然后使用J\tvc设计模式设计成用户自己可以控制的控件，在控件间设定一定的逻辑表达，由用户自定义计算公式计算奖金。这种设计虽然核心资产的开发周期相对较长，但我觉得是值得的。因为大大缩短了今后产品的开发周期，并减少了产品定制时的错误。

本汝核心资产开发中公用部分较多的是对“知识、资源管理平台“的开发，虽然最初我 们也了解到不同设计院管理方法也有所不同，我们在研究几家管理比较好的设计院方案后， 拿出了一套比较规范的管理流程方案，这几个设计院表示愿意改进他们的管理措施以适应我 们的方案。这一点是我本故产品线开发最值得骄傲的地方，实现了“双鬲”?一客户改进了 他们的管理，我们节约了开发成本。

我觉得最为困难酌是在众多不同需求中如何抽象出相同部分，而对不同部分进行灵活的 组装或构造比如本汝设计的核心模块：“项目管理”的流程：项目开发-可行性研究报告-可 行性评审-初步设计斗初步设计评审．施工图设计斗施工图交底斗项目后期支持；但有的项 目由生产厂家进行可行性研究，那么同样省略的就有可行性研究评审；还有的小型项目，不 需要做初步设计，项目开工后直接进入施工图设计。这种情况下我根据流程最长的需求开发 所有需要的构件，构件间的接口做成松藕合。演化成产品时进行构件组装。

因为目前我们通过核心资产演化的产品还不多，所以很难评价核心资产开发的整体质量。 这个问题的解决有赖于更多实际产品的开发以及更多的用户反馈。本故软件产品线开发，我 觉得有如下一些收获：1）对我们公司员工的素质是一个大锻炼，2）在开发过程中我们也与 设计院一些高层领导及部门领导结下了深厚的友谊，加深了对该类技术密集型单位的认识， 非常便于我们今后推广最终产品；3）通过核心资产的更多开发，我们今后产品开发的工作量、立旦耳警南罟害R△右猗罟揶的耐姜

论软件产品线技术

摘要

本人在测井行业的一个国有企业软件开发部工作，从20xx年初开始，我陆续参加了多 个测井软件开发项目，这些项目部是测井行业资料处理解释软件，具有很强的行业特征，其 开发方向和应用范围部非常相似，从“测井资料处理集成软件刀项目，开始我实施了软件产 品线技术，虽然在开始阶段，由于经验不足和管理不善，遇到了一些问题，但是随着逐步实 施，部得到的纠正和有效控制，目前这几个软件项目部非常顺利的完成，实施工期明显缩短， 极大的提高了产品质量，本文就在这些项目中为什么实施软件产品线？在实施过程中遇到哪 些问题？产品线开发支持工具选用情况和产品线实施带来的益处等进行论述，并分析总结在

目前本单位产品线技术应用中存在的不足。

正文

本人在测井行业的一个国有企业软件开发部工作，在近几年来内，藐陆续参加了几个的 软件开发，20xx年初参加“测井资料处理集成软件”项目，此项目的目的是集成本单位重点实验室研究成形的测井资料处理方法，提供一体化的应用，服务于各个测井公司，我负责底层平台设计和开发，20xx年初参加“阵列感应实时分析软件”项目，主要针对单位自行研制测井仪器一阵列感应仪器MIT的现场资料实时处理，总俸费责软件的设计和实现；20xx年中，参加国家级项目“山地地震和矢量地震勘探研究”的“成像勘探开发处理软件”子项目，本项目的目的是实现国内勘探解释方法和仪器的大整合，“成像勘探开发处理软件”子项目完成成像勘探部分的软件开发，我负责成像勘探部分软件架构设计和分析实现；20xx年初，参与总公司科技局“测井综合应用平台”项目，性质与“测井资料处理集成软件刀类似，但集成范围扩大到整个测井行业，我参与了总体架构组，并完全负责底层平台的设计。 这几个项目都是测井行业资料处理解释软件，具有很强的行业特征，其开发方向和应用 范围都非常相似。几个项目表现了很多共性特征，如数据录入接口方面，部采用测井行业标 准的数据格式CIF、LIS和KIF等；数据表现方面，采用图件可视化方式；数据管理方面，除 了第二个实时解释项目采用文件系统外，其他均采用数据库存储，使用测井国际化标准组织 POSC的EPICentry规范，不仅如此，处理流程也大致相似，首先获取数据、进行数据转换， 按照用户指定的方法进行资科处理，然后以形象化的方式反馈给用户一些处理特征，进行处 理结果输出，各种资料归档等。除了这些其性外，几个项目也表现了一些个性特征．如“阵 列感应实时分析软件”要求的实时性比较高，性能要求较高，采用文件系统，“测井资料处理集成软件”项目用于实验室方法集成，分析功能和研究性质略强于其他三个项目等，虽然存在个性，但是我认为几个项目更多地表现为一致性。

在这几个项目中我部实施了软件产品线技术。主要原因有以下几个：1、本部门长期承 接测井行业软件开发，开发范围清晰，且容易界定，在多个连续的项目中，一直存在一些共 性开发。在早期项目中，由于构架和开发接口不统一，造成重复开发的弊端，实施产品线可 以有效节省人力、物力和财力。2、测井行业目前出现的软件部是层次架构，80町是用采用C/S模式，主要应用在测井资料处理上，其余采用B/S模式或者两种组合方式进行简单数据查询和处理结果显示，有利于产品线架构设计。3、由于行业特点，开发的软件很难适合所有的测井公司，而多数情况是量身定做，因此同一个项目可能出现多种软件版本，如华北油田专版，重点挂接生产测井解释功能，而长庆油田对斜井校正等方法较为重视，采用软件产品线可以方便解、央这些问题。4、同时，测井行业中，方法的更新较快，但是一般的软件使用的方法都相同，如“测井资料处理集成软件”项目和“测井综合应月平台”项目使用同样的软件处理方法和图件绘制方式（测井行业特征，方法永远采用最新的），一旦解释方法和绘制方式改变，所有的软件要求能统一改变。

我在接手“测井资料处理集成软件”项目后，与其他开发人员向单位建议了软件产品 线的开发技术，得到同意并开始实施。由于是新项目开始，而且软件规模不算很大，因此， 我们直接采用了革命的方式，项目直接实施全新的软件产品线方式，我将团队分为两路，一 路总结分析1日项目的软件，一路进行当前项目的分析界定，同时聘请行业专家和技术专家结合本项目从大局进行规划，首先进行行业分析，对行业分析结果与单位的规划进行整合，最后在形成的领域架构基础上进行当前系统的需求分析和设计界定，其中开发重点在核心资源库上，然后当前项目的软件直接复用资源库上的产品线构架和构件。这几个项目完成后，本单位的核心资源库得到了丰富和充实，由这几个项目直接构成的核心资源包括两套产品线架构，分别适用于测井资料处理和测井资料检索管理两种开发类型；数据格式转换构件组，能够进行十几种测井原始数据进行转换和录入；测井图件绘制构件组，数据按照四十多种图

形方式显示在通用的桌面系统、浏览器，并能以位图、矢量元文件、SVG釉CG进行输出；还有文件系统和数据库操作标准和一些商业构件库和中间件等。

几个项目完成的非常顺利，除了第一个项目的出现短暂延期外，其他项目大幅度缩短了 开发周期，而且软件维护和版本升级非常方便，但在实施过程中我们也遇到了一些问题：1、 在第一个项目实施期间，经验不足，人员分工与过程组织不合理，核心构件与应用系统开发 混淆，导致了开发设计的反反复复，延迟工期。2、部分核心资源设计不合理，某些构件在老项目方便使用，但没有充分考虑新项目的特点，在新项目无法充分利用，如果直接修改冲突构件满足新项目，老项目的维护和更新又无法与新项目配套，在一段时间内存在同时维护多套多版本构件的情况。3、资源管理不利，因为产品线实施需要非常强大的构件管理和配置管理，我的四个项目针对不同油田的应用每个项目部生成了多个软件产品，维护还包括了核心资源维护和应用系统维护，实施前期经常出现管理不善带来的负面影响。

到目前，我们逐步解决了这些不利情况，主要是加强人才培训、资源管理和组织管理。 在资源管理上，我们主要通过自动化工具来解、央。目前支持产品线的工具不多，大多是构件的管理和组装工具，在系统分析设计和建模方面一直采用Rational酌ROSE，软件配置管理采用cvs，核心资源管理方面从初始的利用cvs转变到北大音鸟的公共软件构件库管理系统，它是采用了B/S的多层体系结构，分布式的应用架构，基于EJB技术，具备较强的灵活性和扩充性，支持刻面分类等多种分类模式，并提供基于角色的用户管理机制，使系统具有灵活的权限分配和安全的控制方式。在选择这些工具的选择上最重要的是核心资源管理工具选择，因为其他工具相对成熟且熟悉，而核心资源库是产品线最重要的部分，并须能进行统一的管理和识别，如关键词分类、枚举分类和刻面分类方法等，因此我们选择了北大音鸟的公共软件构件库管理系统来进行核心资源库的维护，它不仅满足上述要求，而且完全支持UDDI V2.0标准规范，而且支持构件统一、描述、发现和集成。

产品线技术在本单位不断扩充与发展，到目前为止，形成了采集、通讯、解释处理等多 方面的产品线架构和构件库，利用这些资源，可以方便快速地“组装”一个测井实用软件系 统。通过实施软件产品线，本单位测井软件的开发模式逐渐规范，不同项目复用同一个或多 个产品线架构，做到组件复用的最大化，实施工期明显缩短，极大的提高了产品开发过程和 产品质量。虽然有了几年的技术和资泺积累，我认为在本单位的产品线开发上还存在一些不 足，如在领域工程方面，缺乏具备深厚行业经验的领域分析人员，需要在不断的实践培养过 程中，辅以本行业外部专家的咨询和辅导；在核心资源方面，缺乏高效的管理，虽然使用了 较为方便的构件管理工具和其他辅助工具，但是其智能化欠缺，不是很成熟，同时构件的组 装上，还是采用人工代码方式，缺少智能组装工具应用；还有就是管理和过程方面，传统单 兵作战思想影响依然深远，国有企业开发人员或多或少有一定技术封闭性，不利于核心资源 积累，而且向团队开发和多部门协同开发转变存在一个阶段，需要更好的管理和更多时间的 磨合。

论基于构件的软件开发

摘要：

基于构件的软件开发是提高软件生产效率和软件产品质量的有效途径，本文结合我们的 实践，以“在线学习支持服务平台刀项目为例，讨论了基于构件的软件开发的技术的应用。 由于我校现有的各级软件系统部是基于微软Windows系列平台，因此我们确定使用微软的COh'l组件技术来开发该平台，并介绍了该平台所使用的几种COM组件，主要采用VB6语言编写通用模块并生成DLL文件及注册成为COJrt程序，客户端用ASP语言来实现并通过ADO

技术来调用SQL SERVER 2000和COM组件。

在本项目中的开发过程中，我担任了系统设计工作。

正文：

“在线学习支持服务平台”是面向我校开放教育学生进行远程学习教学辅导，经过多 年的远程教育模式的探索，确立了成熟完善的远程教育教学模式一利用先进的网络数字信息 技术，为广大的学生提供开放的教育平台和最优秀的教育资源，突出个性、学生自主学习的 教学。

“在线学习支持服务平台”是一个综合性的在线式基于WEB的远程教学平台，存储着核心信息数据，提供网上澡程、信息发布、查询、BBS、VOD视频点播等教学服务，该系统的开发技术主要集软件复用、企业级应用程序开发等技术于～体的“基于构件的软件开发”。系统运行于WINDOWS SERVER 2000，用SQL SERVER 2000为后台数据库，用ASP+IIS5.0来架构网站。

由于COM组件既可以被嵌入动态Web页面，还可以在LAN或桌面环境的VB、vc等 应用中使用。另外该组件之间是彼此独立的。当应用需求发生变更时，可能需要更换中间层 的个别COJlt组件，但并不影响其他组件的继续使用。组件具有若干对外接口（属性和方法）， 可以根据不同的应用需求，有选择地使用不同的接口。即使不再使用某些接口时，COM组件本身仍然可继续使用。同- COM组件可以在不同的应用环境中重复使用。因此，结合拢校的实际情况，我校现有的各级软件系统都是基于微软Windows系列平台，且开发人员对COM组件技术也较熟悉，对开发语言VB6也很熟悉，因此我们确定使用微软的COM组件技术来开发该平台。

该平台采用B/S结构进行设计，把整个系统分为三个层：数据库层，应用逻辑层，用户 界面层。用户界面是浏览器（如IE等），并通过ASP语言来实现同应用逻辑层构件交互。应 用逻辑层负责事务处理，应用逻辑层用主要通过使用COht组件方式来实现，数据库层用SQL Server。

我们依据平台的主要功能，在平台开发中，如果采用传统的方法来开发，则每实现一个 功能都要编写同样的代码，为了节省开发时间和提高维护效率，我们把共用的代码模块部做 成组件，例如我们把记录操作（如记录的删除、增加、修改等）、数据库操作、查询做成用户管理组件，把用户身份认证和用户类型识别做成用户管理组件，把所有实现与数据库的连接做成连接组件，把用户的错误操作、与系统的交互出错等做成错误处理组件。对于各组件我们采用VB6语言进行编写并生成DLL文件，通过注册成为COM程序，供各个组件调用。在数据库连接方面，我们采用了ADO技术。由于ADO采用了OLE-DB技术，使能访问各式各样的数据并提高了访问性能。

在该平台的开发过程中，主要设计和实现了以下一些COM组件：

(1)用户管理组件，包括身份认证功能

我们主要定制COM组件用户管理组件UserCheck．dll进行用户管理处理。该组件主要完成两个功能：一是身份认证功能，主要是提供用户登录时验明身份，保证应用的安全性。二是根据用户所输入的账户名确定该用户的类别。

因此，该组件具有三个接口，每个接口代表组件的某个属性或方法。对用户的登录请求 做出相应的处理：如杲是学生登陆则转入学生学习平台，如果是教师登陆则转入教师平台， 如果是管理员登陆则转入管理员平台。

(2)查询和提交信息组件

我们主要定制COM组件QuerySys．dll进行查询和提交信息处理。该组件主要完成两个功 能：一是供学生用于查询学生成绩和查询澡程信息；三是提交学生注册信息。

该组件具有两个接口，每个接口代表组件的某个属性或方法。如果学生的请求是查询功

能(Querylnfo方法)，则将查询信息请求做出相应的处理，并将查询结果集返回给出学生。如 果学生的请求是提交注册信息（Submitinfo方法），则将提交信息请求做出相应处理，并将信息提交提示返回给用户。

(3)连接组件

我们主要定制COM组件Conector．dll，该组件主要完成与数据库的连接。该组件具有一个接口，那就是确定数据源，以便自动连接后台数据库。

(4)错误处理组件。

我们主要定制COM组件Cerror．dll，该组件主要确定错误类集，该组件具有一个接口， 主要是输出错误信息，方便用户排错。

我们把编译好的组件，将其在MST中注册，并将其分布在服务器上，这样就可以在设计平台过程中进行调用这些组件了。在本系统中，我们通过以下几种方式把组伴集成到系统中来：

一是连接集成，即残们将组件直接嵌入ASP主页中，即在ASP脚本中通过SET对象名 =Server．CreateObj ect（?类名”）来引用，使此二进制组件可以运行于服务器端。

二是容器集成，即如果一个组件需要调用另一个组件时，就在需调用的组件中引用另一 个组件的方法。例如在使用查询和提交信息组件时就需要先调用连接组件。

我们结合连接集成和容器集成两种方式来组装系统，以登陆界面为例，在客户端我们只 提供两个输入项和一个提交信息的功能按钮，主要通过ASP来实现。在服务器端，主要根据用户输入的信息来进行相应的处理，这就要调用各种组件。如果学生以错误的学号和用户名登陆，则系统调用用户管理组件、错误处理组件和连接组件，返回非法用户的信息。如果学生以合法的身份登陆进入学生平台，这就要调用用户管理组件、连接组件。如果教师以合法的身分登陆进入教师平台，也要调用用户管理组件、连接组件。

目前，该平台运行收到良好的效果，我们采用COJrt组件技术进行开发，碱少了重复输入代码的工作，缩短软件的开发周期。同时，在进行系统维护时，我们只关心组件的接口参数，而不用再考虑组件内部的具体实现，提高了系统的可维栌性。在以后的工作中，如果我们要扩展某些功能时，也可以重复利用这些组件，提高了系统的可复用性。目前该平台运行存在的缺点是：由于在ASP中运行的COIK组件是二进制代码，当COM组件工作出错时，ASP不能指出COM组件发生错误的具体位置，只能简单显示对象创建不成功。这样就给我们在调试该平台过程中增加了难度。

论基于构件的软件开发

摘要

去年初，单位承担了新立的“测井资料处理与解释集成软件刀项目，目的是集成目前 国内零敌的测井解释方法，莪有幸参加该项目，并负责软件系统平台设计和部分开发工作， 在项目的实施过程中，我充分进行基于构件的软件开发，复用成熟的商业构件和本单位的构 件资源库，同时考虑了本项目开发资源的进一步复用，形成了绘制组件包，数据交换组件和 数值计算组件包等。基于构件开发，大大提高了软件的质量，缩短软件的开发周期。开发的 软件目前在石油测井几个油田现场使用，并得到用户的好评。本文就在本项目中如何进行基 于构件开发进行描述，并在复用构件的使用和丰富方面谈一些自己看法。

正文

20xx年3月，我有幸参加了单位软件开发项目一一“测井资料处理与解释集成软件”， 并负责系统平台设计和部分开发工作，本项目是由中国石油天然气集团公司科技部的测井软

件类项目，在项目立项之前，国内测井行业为了提高石油解释的分析和决策能力，在解释方 法方面广泛与各大高校进行合作，经过长时间的积累，形成的非常多而且实用的方法和处理 模型，并开发了简单的使用系统，但这些应用非常零敌，不统一，无法协调工作，处理效率 低，多个解释系统之间没有必然联系．而且数据格式多种多样，不利于测井的精细解释和综 合应用。本项目的目的是为了综合决策能力，提高石油解释的准确率，考察了解国内流行的 测井资料处理解释方法，将成形和半成形的解释方法进行筛选和整理，集成到统一的系统平 台上，增强一体化处理功能和商业化能力，并有偿反馈给石油测井现场用户使用。

在本项目立项前，单位承担了较多的软件开发项目，软件开发方法一直在改进更新。单 位早期的软件以数值计算为主，主要采用面向过程开发方法，但随着软件的复杂度增加，可 视化要求和开发效率，在面向过程方法不能满足要求的情况下，开发方法转为面向对象方法， 实现界面编程，可视化操作交互，开发效率得到大幅度提升，但是这种方法也存在一些不足， 无法有效实现资源复用，多个项目之间的资源复用仅限于部分开发过程和偶尔可以复用的模 块类，新项目很少能借鉴老项目，即使存在明显类似的项目也无法有效复用，出现了多个项 目组软件界面不统一，操作习惯不一致等情况，因为新项目只注重眼前效率和操作适应性， 根本没有考虑以后的复用，导致重复开发，浪费人力物力。因此，在面向对象开发方法的基 础上进行改进，采用基于构件的开发方法，在每一次项目中，尽可能地考虑以后可重用的部 务，以构件形式进行设计开发，虽然在单部分的开发工作可能增加，但是多项目综合考虑， 大大提升软件的开发效率。而且，本单位大部分项目为测井类软件项目，在软件的设计思路 和最终成品上看，很多部分非常相似甚至雷同，几个连续项目存在联系，基于构件开发的软 件方法在本单位更能体现作用。

在“测井资料处理与解释集成软件”项目的设计和实施过程中，我使用了基于构件开发 的方法，充分利用公认的构件技术-COM/DCOM和ADO等，使用已有的商业构件-Xtreme和 Esstentails等，复用单位的构件资源一数据转换组件，并开发了新的构件，如绘制组件包， 数据交换组件和数值计算组件包等。

本软件系统以测井解释分析为主，主要包括图件绘制、用户交互操作、数值处理和数据 存储等几个部分，我将软件设计为C/S四层体系架构。客户端应用程序采用hticrosoft Visual c++开发，本单位已经购买了Xtreme的使用权，Xtreme是基于vc的MFC框架的界面构件，它是微软的合作伙伴，能经过简单的几步向导就能产生美观的软件界面，它生成的界面具有一致性，对于测井解释集成应用，统一的界面可以降低软件的学习难度，增强软件的易用性， 使用Xtreme．我非常方便地实现了界面设计和开发工作。

图件绘制基于GDI和GDI+开发，每个绘制对象采用单独的一个类进行封装，绘制的载俸对象派生于MFC的窗口类，其他对象派生于同一个基类，基类设计足够的消息响应函数，对象采用重载虚函数或者操作自动定向，实现鼠标响应，属性修改和递归型子对象管理。绘制载傩类和基类封装在一起，形成绘制核心库，其他对象单独以MFC扩展动态库实现，一个或者几个对象设计成一个扩展对象库，如果要增加和删除某个对象，只需修改相应的扩展动态库。这样，只需要绘制核心库与必要的绘制对象扩展库，就可以提供相应的绘制功能，而且绘制的对象可以定制并进行二次开发。在某些绘制图件的设计中，考虑到算法的难度，直接利用较为成熟的绘制构件-Gigasoft Pro Essentials，如等值线图，区块三维分布图和多井 连通图等图件的绘制算法，核心绘制部分直接由Essentials完成，用户交互响应由对象封装。 测井解释的核心部分是解释方法，每种测井项目有多种解释方法，而每种解释方法又有 多个解释模块，因此解释方法的设计是相对复杂的。在考虑到测井解释的流程化处理和模块 动态增减的要求，采用COM组件技术避行了模块设计。例如常规测井解释项目，包含POR、 CLASS、SAND和CRA等多种解释方法，而这些解释方法部包含几个解释过程，如POR包含泥质含量计算，渗透率计算、孑L隙度计算和含水饱和度计算，将上面的每个过程设计为功

能完整封装的COht组件，当用POR解释方法进行资料处理时，依次调用处理过程完成解释。由于采用组件方法设计，方法模块可以动态添加，如果在POR的基础上需要添加含油饱和度计算模块，只需要设计相应模块，动态添加到POR的管理队列中。在解释方法分解设计的同时，将多种相同的数值计算方法进行提取抽象，形成满足自己需求的数值计算组件包，方便多种解释方法的复用，并为新的解释方法研究提供强大的计算能力。

在软件设计开发中，数据的存储最为繁琐，由于测井解释面对多种数据格式，如国内 Forward软件使用WIS（WeIILogging Information Sysetm测井信息系统）数据文件，国外 Ge oFrame使用的Lis( Log Inf ormation Standard)、eXpress使用的XTF( eXchange Tape Format 可交换帝格式)格式和DPP使用的Clis格式等，这些测井软件便用相当广泛，如果本项目软 件能进入市场，这些格式部需要兼容，但是将这些格式部作为应用对象很难实现或者不可能 实现。在数据储存方面，我直接采用Sql Server数据库存储，存储结构设计采用国际标准结 构，国际石油标准化组织POSC制定了一套EPICENTRY石油数据存储标准，这种结构被石油系统广泛采用，可以存储石油系统多行业数据，如测井、录井、钻井和开发类数据等，直接采用已有标准可以满足复杂的存储要求，避免重新设计格式的存储能力限制。数据访问采用ADC数据访问组件，实现数据通讯和交换。在数据库的数据录入方面，我充分利用了本单位其他项目开发的数据格式转换组件，用于支持多种测井数据的解码和编码，由于以往项目的数据操作是基于文件系统（CIF格式），内部封装了固定CIF文件格式转换功能，我将组件进行了适当修改，将基于CIF文件格式的操作改为内存操作方法，实现向数据库录入。

在数据库和解释模块之间，我设计了数据交换组件，因为测井解释的特殊性，一次解释 需要获得数据非常多，一次解释处理至少需要二三条曲线，测井采样间隔一般为0. 01米左右，2000米井段每条曲线传输数据量就有100多K，如果需要处理成像数据，敦据量更大，可能有几十兆，甚至上百兆，由解释模块或测井图件直接采用ADO进行数据库访问，每次解释会多次访问数据库，势必会降低软件的执行效率和处理的稳定与连续性。数据交换组件将一次解释数据全部读出，打成固定格式的数据包GDS(Global Data Storage)，GDS可以以文件形式存放和内存形式交换，应用模块只处理GDS数据包，完成各种应用后，按照同样的格式传回数据库，优化处理性能，而且基于GDS构件的应用还可以扩展开来，GDS不一定只与我们设计的数据库进行交换，如果需要增加其他存储方式敝据库，只要知道详细的存储结果，开发访问组件，GDS就能与其相联进行信息处理，新的数据格式也是一样，只要提供了访问组接口也能够进行测井解释。

开发过程中，我充分利用已有的构件，也充分地考虑了本项目开发资源的进一步复用， 开发了绘制组件包、数据交换组件和数值计算组件包等构件，完善单位的可供复用的构件库， 积累和固化知识财富。到目前为止，绘制组件包和数据交换组件已经在新项目测井数据采集 平台使用，效果非常好。

基于构件的软件开发，可以缩短软件产品的开发周期，提高软件质量，但是如果构件选 择不当或使用方法不当，也会带来～些麻烦，在构件的使用上，我也走了一些弯路，如在使 用Xtreme上，由于购买了它的源代码，曾将某些绘制模块建立在其源代码级别的紧密耦合， 当Xtreme提供的新的版本后，这些紧密耦合的模块无法适应新版本，如果想继续应用，必须再进行同样的开发工作，最后我放弃了某些紧密耦合的功能，将绘制交互与Xtreme完全隔离开，后续的版本升级再没有带来任何问题，类似的教训还有很多，总结分析后，我认为在基于构件的开发中主要注意一些问题：如项目开发不要与已有构件紧密耦合，防止构件升级带来的影响；构件的使用一定要进行严格的测试与审核；不要勉强应用某些构件，如使用巨大构件的其中某个微小部分，虽然功能很适合应用，但可能影响软件效率；新项目必须注意构件库的积累，只有这样才能充分体现基于构件开发的便利；新构件功能一定要完整，文档及接口定义明晰，否则难以复用。

在本项目的开发工作完成后，相比以往的开发项目，开发周期明显缩短，软件的质量明 显提高，用户软件维护要求也减少了，而且其扩展性非常强大，目前该解释软件已经在华北 油田、长庆油田和土哈地质研究院进行了现场应用，得到了用户的一致认可。通过这次案例， 我认为在软件系统的复杂性不峤增长的情况下，基于构件的开发能有效提高软件质量、积累 和固化知识财富，并有效地缩短软件产品的开发周期，提高了软件生产效率。

论软件项目计划的制定

摘要：

本文讨论了一个作者参与的软件项目的项目计划制订的若干问题。项目所开发的产品是 一种智能电子教学设备，该设备可以实时同步地将用户在硬件端的书写内容显示在计算机屏 幕上，并可以保存、编辑、打印用户输入的数据，联网的计算机也可以实时观看用户的书写 过程，并且用户还可以通过投影在硬件端的PC机画面交互操作PC机。

作者是该项目的软件开发组负责人兼软件架构师。作者针对项目计划的制定采取了：分 而治之，逐步求精，经验数据三个主要策略，从而得到较好的效果。

正文：

20xx年6月，作者所在公司启动了一个项目，该项目开发出来的产品是一种智能教学 设备，该设备可以实时同步地将用户在硬件端的书写内容显示在计算机屏幕上，用户可以保 存、编辑、打印通过硬件端输入到计算机的书写内容，联网的计算机也可以实时观看用户的 书写过程。另外，用户还可以通过投影在硬件端的PC机显示画面交互地操作PC机。

作者有幸全程参与该项目的开发，并且担任了项目PC机软件开发组的负责人兼软件构 架师的角色。对于这种实时通信且具有联网功能的软件项目，我认为首先需要制定一个良好 的项目计划，才可以保证项目开发的成功。

总结这次项目的经验，我讣为行之有效的策略有三个，分别是分而治之、逐步求精、 经验数据。下面就结合这三个策略详细讨论本次项目计划的制订。

一、分而治之

将一个过于复杂的问题分解成若干复杂度不那么高的小问题来依次解决，这种方法人类 已经采用了几千年。这里我们也可以用于项目计划的制定。因为整个考虑项目的方方面面来 制定计划其复杂度已经超过了人类处理问题的能力。为了解、央这个问题，可以将整个项目分解为一些更小的组织俸，逐一进行处理，这项工作也就是项目管理中的WBS（工作分解结构）。比如针对这次项目中采取的RUP开发过程模型，我在完成需求管理计划时我就将计划内容分解成初始、细化、构建、移交四个阶段来分别制定，最后合到一块儿就是完整的需求管理计划。

除了按时间段分解的角度来制定项目计划，我制订软件开发计划时同时按照了RUP过程方法的工作流的概念来分解项目计划的制定工作，根据每个工作流在四个阶段业界通用的工作量估计来制定计划，安排工作人员以及相应的软件资源。因为软件开发计划涉及到多个工作流，我认为以这种方式分解是合理的。同时因为本项目的特点，我省略了业务建模工作流，这是因为这次的产品是以硬件为主，软件为辅的消费类产品，所以业务建模不昱那么必要了。 以不同的方式分解项目，可以从多个不同的角度来制定整个项目计划，有利于全面、深入地了解项目，避免“瞎子摸象”的情况发生。

二：、逐凶日讳葺

计划工作其实是一种管理未来、管理未知的工作，而未来是变化莫测的，还存在许多自 身无法掌握的因素，因此存在很大的难度。而解决这一困难的法宝就是逐步求精。按照先框

架后细节，先粗后细地进行项目的计划。

比如在这个项目中，在接受这个项目后就开始了做了一个初步计划，这个计划的内容主 要是做出时间上的安排。因为打算在2003的5月需要用这个项目的产品申请国家中小企业创新基金的支持，所以完成时间就定在了20xx年的4月，预督一个月用于写申请报告。总的时I间进度确定后，大概分配了三个时间段：系统工程分析、软件开发模型确定、软件产品制造时间段、项目总结。

等到确定这次项目后的RUP开发模型后，就可以继续对项目计划进行第二次求精了。其实RUP过程中出出体现了逐步求精的理念，比如在初始与细化两个阶段都要产生出项目计划的制品。这样我就可以在这个两个阶段对项目计划逐步求精，比如在初始阶段只是将我需要完成的项目计划分为了需求管理计划、软件开发计划、实施计划，然后在细化阶段我再县体地制定每类计划的详细内容。

比如在初始阶段时架构设计考虑以JctFC为平台，根据这个决定软件开发计划的制定是比较粗略的，在细化阶段架构设计进一步详细，这时已经清楚各个模块和MFC的Doc/View主结构的接口定义，以及各模块之间的接口定义，这时我就可以根据所需开发的模块制定计划。比如这时我就计划了特效界面模块开发分两次迭代，第一次迭代计划一个月时间，第二次迭代两周时间，第一次迭代需要完成放大和缩小、树形选择、缩略显示等主要的界面效果，第二次迭代的主要任务是根据用户反馈进行修改调整。

三、经验数据

要制定一个良好的计划离不开精确的估尊。不过项目计划是在项目开发的早期制定的， 而在早期要完成精确的估算是非常困难的。要解决这个问题的关键就在于“经验数据”。由于整个软件产业部还十分年轻，经验数据的积累部普遍不足，才导致这一现象的出现。 但是因为这次项目开发的产品在国内还没有开发过，在加上公司没有积累深厚系统的项 目历史数据。针对面临的困难，我选用了FP功能点分析做为项目主要的估算方法。因为FP 方法中有大量项目经验数据可以从网络上获得，同时其数据功能ILF、EIF,以及事务功能EI、 EO、EQ的计算对经辁数据依赖不强，只需对概念理解正确一般就可以正确估算了。在估算成本的时候，因为公司以前的生产率数据是以LOC为单位的，我利用软件工程书籍中的“逆火刀经验数据，将LOC转换为功能点单位，当然，这里必然导致一些误差。为了降低估算误差，最后使用Delphi专家分析法对估算结果进行了调整。

Delphi方法是一种集策法，也就是通过多名专家对估计值的不断校正的方法。当然，请 专家增加了项目成本，不过最后得到高质量的项目计划还是值得的。比如，在某专家的建议 下我们改变了自行开发网络层组件的计划，而是采购现有的完全可以解决项目需求的成熟的 中间件产品，这个策略的调整在后来证明是正确的。一开始犯错误的原因是由于我们网络开 发经验不足把用户需求想复杂了。

最后谈一下使用的工具软件。在制定项目计划过程中我采用了Microsoft的Project 2003 绘制甘特图。因为项目的进度安排是和项目中每个人部是息息相关的，所以在做甘特图前我 首先征集了大家对文字和条形图效果的意见，然后按大家的意见进行了美化，比如用鲜艳的 颜色标识关鼹任务，放大任务摘要信息，突出里程碑信息等。这在有些项目管理看看来似乎 是小事，不过我认为一个赏心悦目酌甘特图可以带给观看看好的心情，而好的心情可以大大 提高工作效率。

同时，考虑创新基金支持的项目在交互期限上有很大压力，所以在定义甘特图任务的依 赖关系时我采取了业界惯用的“时间盒”的技术，也就是在每个任务的任务信息对话框中“前 置任务”一栏中的“延隔时间”我填入s9 -is%，也就是说当任务完成90%左右时就可以 结束转而执行下一个任务。因为本项目中的所有人员几乎是全程参与，所以我不是很担心每 个任务遗督的少量问题在下一阶段没有负责人去解、央。

配合Project 2003使用的估算软件是Sof tvrare Productivity Research的

KnowledgePlan。这款工具软件的最新版加强了对Microsoft Project 2003以及RUP开发模 型的支持，而且其中的Proj ect Template功能允许用户采用自己定制的WBS来进行估算，这 些因素使得KnowledgePlan对本项目的项目计划成功制定带来很大的帮助。

在上述三个策略的指导下，以及合适工具的辅助下，使最后形成的计划有效地指导了后 期的开发活动。项目开发出来的产品通过了专家的鉴定，获得了国家中小企业创新基金的支 持。

项目完成后发现的间题是早期计划的估算结论偏差还是较大，看来还是受到缺乏经验数 据或者经验数据不够精确的影响，所以在以后的工作中需要开展有效的度量的工作，为公司 积累霜羔而广日尽量精确的经骀数据。

论信息系统监理中的组织协调

趣：

20xx年7月我所在的单位承接了料市城市综合地下管线信息系统建设项目的监理，监理工作的范围包括：系统设计；GIS数据库系统和地下管线综合管理系统的开发；地下管线勘测数据加工入库的质量控制。裁作为总监理工程师代表参与了该监理项目。

在监理的过程中我感到良好的组织协调是实现“四控三管”等监理目标的重要方法和手 段。应当在项目的监理规划中细致地分析项目运作的模型，准确地定义各个项目干系人的角 色和活动，以便让各个干系人部清楚项目的运作过程，并且认同监理的工作。在此基础上， 我们参照mL的方法分析项目活动过程，本着公平、公正、独立的原则在参与项目的各方之 间组织协调，加强信息管理和信息交流，顺利地完成了监理工作。

正文：

城市地下管线是城市的重要基础设施。运用地理信息系统（GIS）等信息技术实现对地下管线的现状以及其建设和维护情况的动态管理，对整个城市的建设和发展有着重要的意义。 20xx年7月我所在的单位承接了料市综合地下管线信息系统建设项目的监理，我作为总监理工程师代表参与了该监理项目。

该项目是料市地下管线普查和地下管线管理机制建设的一部分，是一个大型的项目。项 目内容包括：绵制勘测规程和数据标准、建设地下管线数据库系统、开发地下管线综合管理 信息系统、开发数据处理模块和CAD插件发、地下管线勘测成果数据的处理和入库。该项目采用GIS技术建设城市地下管线的三维空间数据库，要求实现动态管理和、央策支持等功能。监理工作的范围包括：系统设计；GIS数据库系统和地下管线综合管理系统的开发；地下管线勘测数据加工入库的质量控制。

该项目采用螺旋式的过程模型。首先勘测0.6平方公里范围的数据作为实验数据。分析 实验结果制定详细设计方案和一系列的规程及数据标准，并开发系统原型。其故，按照定义 的勘测规范和数据标准重新勘测1平方公里的测试范围，评估测试原型。并且改进原型开发 试用系统。然后，在5平方公里范围内试用，完善整个地下管线的管理业务流程。信息系统 通过确认测试后，展开全市范围的地下管线普查勘测，并完成数据处理和入库的工作。 参与该项目除了发包方、承建方、监理方，还有软硬件平台建设的分包方、管线勘测单 位、管线数据使用单位、数据库基础资料提供单位、管线建设单位等多个干系人。他们各自 处于不同的专业和行业环境，完成不同的工作内容，但是每一个干系人的作为和态度部对项 目的开发具有重要的影响。茌项目的每一个迭代阶段中部必须充分地调动各方的资源，组织 良好的多方协调配合，才能保证项目的顺利开展。这其中监理就起到了重要的组织协调作用。

可以说在多方之间良好地组织协调，是促进项目的进展、实现项目目标的最重要的方法。因 此，我在项目的启动阶段就充分地认识到组织协调的重要性和存在的困难，并采取了如下的 措施。

一、参照Ⅲ的方祛分析项目活动过理

由于该项目不仅仅是软件开发，而且还包括有应用集成、工程勘测、数据生产等内容。 并且在项目的开发过程中要新建一套政府对地下管线实施管理的机制和数据动态更新的业务流程，其中涉及到多方利益关系的协调。因此项目的管理过程具有复杂性和独特性。为了应对这一恬况，我们在编制监理规划的时候就认为必须详细地分析整个项目的管理和实施的过程，根据项目的特点建立一套项目活动过程的模型，解释项目各方干系人在项目活动中的相互关系和行为方式。这一模型最重要的要求和作用是要让各方都能够充分地理解模型表达的内涵，进而接受和确认这种关系和行为要求。以便建立起共同的项目目标和协调一致的行为准则。

我们参照了UML的分析方法和表达方法，设计项目管理的模型。比如，使用顺序图和协作图表示各方之间消息传递酌顺序和关系；使用一系列带泳道的活动图表示出各项活动的过程中各方之间的联系和流程；最重要的是，建立信息管理和文档管理的模型，通过类图定 义了针对GIS工程的各种技术文档和管理文档的属性、功能要求，设计这些文档

在本项目过程中产生和使用的活动图，以及相互联系。

在监理规划对项目管理模型分析的基础上，我们得以在监理实施计划中制定具体的信息 管理、信息通信、配置管理、组织协调的有效机制。

二、建童雨效的信艚理机制

信息管理机制是保证我们设计的项目管理mtL模型得以实现的重要手段。我们规定三方 的工作人员都要按照U札模型中的要求编制文档，并提交给信息管理员编号集中归档。每一个项目阶段或者里程碑的检查验收部以是否完成文档编制要求作为第一指标。未能完成文档要求的不予签署监理意见，总监还要追求专业监理工程师和监理员的责任。

另外，我们也制定了信息管理员需要及时发布的信息和文档类别。包括监理周报、会议 纪要、监理专题报告、项目变更文件等文档由信息管理员立即发布到三方的各个小组联系人 的邮箱中。

我们使用IKicrosoft Proj ect建立了项目管理的网站，作为资源共享和信息通信的平台。 三方以及工程勘测单位部可以及时地发布淌息，并且了解项目的进展情况，增进沟通协调。 在本项目中，工程勘测单位与信息系统承建方之间没有直接的合同关系，各自只需要对 发包方负责，但是在实际的开发中，两者之间的联系是非常关键的环节。因此我们需要着力 协调两方之间的沟通和通信。在信息传递的活动图上，勘测单位也是其中一个执行者。一些 重要的环节，比如数据标准和原型的评测，更需要两方密切合作。因此我们在发包方的授权 下，协调监督两方之间的协调配合。

裁们一方面必须以科学、规范的方法组织项目的监理工作，以得到项目有关各方的认可。 还必须以公平、公正、独立的原则在多方之间组织协调，以藐们诚恳、守信的处事态度和实 际的行动获取合作方的信任和支持。

在folc市还没有启动本项目的时候，地下管线的管理实际上是采用了一种不规范的流程。 某工程勘测院就处在流程的一个环节中。项目实施过程中，按照新的管理模式，该工程勘测 院应当完全退出管理的环节，并移交所有的历史资料。这时该工程勘测院对管理模式以及本 项目提出了一些意见和建议。但是遭到发包方的反对，引发了矛盾。我们为了促成项目的成 功，从技术的角度独立公正地分析了这些意见和建议，有理有据地指出其中合理的和不合理 的部分，为发包方捉供了参考意见并从中协调。发包方最终接受了部分的建议解决了矛盾。 在监理过程中的组织协调包括有项目参与人之间的协调和项目外部因素的协调，有合同

因素的协调和非合同因素的协调。比如以上的例子中的协调工作就超出了监理合同的范围。 但是很多意外的因素部有可能影响项目的质量和效果，因此必须加以积极的引导。

我们规定每周组织一次监理会议，会上主要讨论监理报告、研究项目实施中的问题。并 且要求专业监理工程师在会上报告与发包方和承建方人际沟通的情况，评价项目管理的过程 是否按照我们设计的模型运作。

在本监理项目中，由于采用了以上的方法，使得发包、承建、监理三方以及工程勘测单 侍等彤成了韩捍的合作*藜，俺币日得IXlll币禾iI亮成．并日；大到而常的庸置和；井寓尊求．

论软件开发成本管理

摘要

20xx年8月，我作为项目经理开始参与某某银行授信业务系统的开发项目，主要工作职责为需求分析、系统设计和项目管理。系统基本功能包括：业务操作、业务提醒、基础资料、查询统计和权限管理等五个模块。系统采用Struts+Hibernate主流Web应用框架，实现Web应用程序服务器WebSphere与协作应用程序服务器Lotus Domino的高度集成。

项目的成功很大程度上归功于在项目过程中各个阶段对进度和成本的有效管理和控制。 本文以该项目为例，结合作者实践，讨论了信息系统项目中的成本管理问题，主要通过在计 划阶段做好工作量估算，有效管理和控制风险因素，在实施阶段进行成本跟踪和控制等方法 来有效管理和控制项目成本。实施结果。。。。

正文

20xx年8月，我作为项目经理开始参与某某银行授信业务系统的开发项目，主要工作职责为需求分析、系统设计和项目管理。当然也做一些编码工作，主要是基础性公用代码和关核心代码的编写与维护。授信是指银行以自身信用向客户提供贷款（包括项目贷款）、担保、开票信用证、汇票乘兑等业务，授信业务是商业银行资金运作中最为重要的业务之一。开发授信业务系统，提高授信址务的管理水平和运行效率、充分利用共享的信息资源、碱小各种风险、运用各种科学的金融分析模型指导业务开展具有十分重要的意义。系统基本功能包括：业务操作、业务提醒、基础资料、查询统计和权限管理等五个模块。系统全面实现授信业务的网上操作，实现流程的上报，审批和管理，大大提高了授信业务工作效率。提供了强大的业务查询和统计功能，便于对授信业务工作的管理和监督。其中业务操作模块实现授信业务工作流程，主要包括正常类授信业务申报、问题类授信业务申报、特殊类授信业务申报和授后监控业务等工作流程。

系统采用Struts+Hibernate主流Web应用框架，开发工具采用WebSphere Studio Application Developei 5.0 (WSAD 5.0)，WSAD5.0集成并扩展了Eclipse 2.0的功能。硬件

配置方面：IBM P610小型机用于安装WebSphere 5．O，DELL服务器用于安装Domino磁和SQLServer 2000。实现Web应用程序服务器WebSphexe与协作应用程序服务器Lotus Domino的高度集成，并使用Single Sign On(SSO)实现单点登陆。总体架构思想．将表单数据的生成和分析采用关系型数据库来实现，通过WebSphere架构实现业务逻辑的处理，而表单的审核流程由Domino进行驱动。将基于业务为主的J2EE服务系统和基于协作为主的DOMINO流程处理系统有效的结合起来，确保整个业务流程的有效运行和各种数据查询分析统计的有机结合。

由于考虑到银行帐户年度等因素，客户要求系统在20xx年1 2底前交付，项目开发周期为4个月。项目人员配备情况，项目经理1人，开发人员4人，测试人员3人，界面美工

人员1人，项目行政秘书1人，配置管理人员1人，质量管理人员1人。其中开发人员小张来自某某银行科技处。项目行政秘书、配置管理、质量管理等人员为兼职人员，为多项目共享。由于公司属于大型软件企业，在项目基础设施方面包括开发服务器、开发机、测试服务器、配置管理服务器、开发工具等配备状况较好。

软件成本管理是软件项目管理的一个重要组成部分，也是一个十分容易被忽视但却又是 十分重要的内容。成本管理的目的是通过执行项目成本管理过程和使用一些基本项目管理工 具和技术来改进项目成本绩效。项目组整体上把按进度和预算交付项目作为我们最大的挑战， 因此我们十分重视对项目进度和成本的控制相管理。该项目中我们借助项目管理软件 Microsoft Project 2003来辅助进度和成本的计划和管理。我们主要通过在计划阶段做好工 作量估算，有效管理和控制风险因素和在实施阶段进行成本跟踪和控制等方法和策略来有效 管理和控制项目成本。

项目需求分析阶段结束，《软件需求说明书》得到客户正式签字确认后，裁们开始创建工 作分解结构WBS和制定详细项目进度计划。我们认为工作量估算是成本估算的基础，对于项目成本管理十分关键。由于对代码行(LOC)估算、功能点(FP)估算等估算方式研究不是很 深入，工作量估算主要采用基于公司项目历史绩效数据库和个人经验的估算方法。对于部分 涉及流程的活动单位一般比较难一次性把握其活动的历时，事实上流程调试的工作量在页面 基本功能（增加／删除膨改）的3倍工作量以上。例如业务操作模块一一问题类授信业务申 报一一问题类客户行动计划申请流程页面提交工作量为2日从，而流程调试需要涉及20多 个角色和8条路径。对于估算把握不是很好的任务，我们一般通过提供一个乐观估算A、悲观估算B、正常估算M进行3故估算然后利用PERT公式[1(4堋【+A+B) /6]计算取整。每项活动我部先确定具体人员，然盾需要对活动本身进行详细分析，必要时查看公司项目历史绩效数据库。最后需要为各项活动建立了依赖关系，明确各项活动的前置任务，活动开始时间和结束时间。总体上讲活动历时估算工作量较大，我花费了数个工作日。

项目组人员流动率较低，在J2EE和Struts架构下的WEB应用开发已经有一定的项目积 累和团队合作基础。如项目组自行开发了功能完善的Struts-config．xml统一维护工具，实 现了FormBe an和ActionBean方便管理。有大量可供复用的东西，如公共基础代码包，权限管理模块等。这些也是在我们工作量估算中需要考虑的因素。

项目中残们对项目风险进行了必要的管理，以避免风险事件的发生引发项目成本增加或 超支。公司项目管理部门提供了风险管理计划的模板和风险事件列表模板。为了让项目组整 体在各个阶段保持良好的风险意识，我尝试采用了“十大风险事项跟踪’’，把项目中各主要风险事项按照排名张贴在公告栏上。由于当时有部分未明晰的需求包括：①问题类客户行动计划申请流程；②查询统计部分需求；③客户方面可能提出的新需求。需求和范围界定不清、 计划不充分、用户参与不足、缺乏领导支持、技术问题等为我们项目计划阶段主耍风险事件。 事实表明，这种做法效果是非常明显的。特别是客户方面，我定期把风险事件列表Email给 客户方项目负责人方某。为了能尽快落实未明晰的需求部分，我与客户方主要项目负责人方 某进行了面对面的沟通。通过一番利弊关系的陈述，达成尽快明晰悬督部分需求的其识。需 求问题很快得到解决。项目组整体信心十足，积极性和责任感增加。公司领导方面对项目组 也表现出特别的关心，特别是公司赵总开始频繁出现在项目组的每周进度评审会议上，他们 也开始担心因为对项目支持不够而导致项目的失败。

3、实描鳓骨翘行成本蹋踪和控制

实施阶段需要进行成本的跟踪和控制。Project 2003中需要设定各项资源（人员）的工 时标准费率，即人员每小时的工作成本。项目组成员每周五下班前通过内网B/S项目管理信 息系统PIKIS提交《项目周报》，把各自本周内完成的任务进度情况和下周任务计划进行汇报。 报告要求按百分比严格量化任务完成情况，PJrtIS只提供具体百分比的选择。项目经理（我）

把各项任务实际完成数据输入到进度计划中，Project 2003自动成本统计表，清楚显示任务 基准和实际成本信息。通过查看跟踪甘特图就可以较好把握项目总体的进度绩效。

授倍业务系统在20xx年12月下旬正式上线，提前1周完成了项目。目前系统运行正常， 受到客户方各有关部门的一致好评，对项目满意度较高。项目的成功很大程度上归功于在项 目过程中各个阶段对进度和成本的有效管理和控制。没有成本管理，项目也可能成功。但没 有成本管理的项目，对于项目管理质量、时间、成本三大目标的实现导具有巨大冈．险。 论企业级信息系统项目管理体系的建立 摘要：

20xx年8月，我作为项目经理开始参与某某银行授信业务系统的开发项目，主要工作职责为需求分析、系统设计和项目管理。系统基本功能包括：业务操作、业务提醒、基础资料、查询统计和权限管理等五个模块。系统采用Struts+Hibernate主流Web应用框架，实现Web应用程序服务器WebSphe工e与协作应用程序服务器Lotus Domino的高度集成。本文结合作者项目实践，以该项目为例，讨论了如何建立企业级信息系统项目管理体系的问题，

第一阶段工作重点为普及项目管理知识，第二阶段工作重点为建立项目管理体系，推行“项目经理负责制刀。后继阶段的工作重点为项目管理改进与提高。项目管理体系的确立为项目提供了良好的支持环境。

正文

20xx年8月，我作为项目经理开始参与某某银行授信业务系统的开发项目，主要工作职责为需求分析、系统设计和项目管理。当然也做一些编码工作，主要是基础性公用代码和关键核心代码的编写与维护。授信是指银行以自身信用向客户提供贷款（包括项目贷款）、担保、开票信用证、汇票乘兑等业务，授信业务是商业银行资金运作中最为重要的业务之一。开发授信业务系统，提高搜信业务的管理水平和运行效率、充分利用共享的信息资源、碱小各种风险、运用各种科学的金融分析模型指导业务开展具有十分重要的意义。系统基本功能包括：业务操作、业务提醒、基础资料、查询统计和权限管理等五个模块。系统全面实现授信业务的网上操作，实现流程的上报，审批和管理，大大提高了授信业务工作效率。提供了强大的业务查询和统计功能，便于对授信业务工作的管理和监督。其中业务操作模块实现授信业务工作流程，主要包括正常类授信业务申报、问题类授信业务申报、特殊类授信业务申报和授后监控业务等工作流程。

系统采用Struts+Hibernate主流Web应用框架，开发工具采用WebSphere Studio

Application Developer 5.0 (WSAD 5.0)，WSAD5．O集成并扩展了Eclipse 2．O的功能。硬件 配置方面：IBM P610小型机用于安装WebSphere 5.0，DELL服务器用于安装Domino R6和SQL Server 2000。实现Web应用程序服务器WebSphere与协作应用程序服务器Lotus Domino的 高度集成，并使用Single Sign On(SSO)实现单点登陆。总体架杓思想，将表单数据的生成和 分析采用关系型数据库来实现，通过WebSphere架构实现业务逻辑的处理，而表单的审核流程由Domino进行驱动。将基于业务为主的J2EE服务系统和基于协作为主的DOMINO流程处理系统有效的结合起来，确保整个业务流程的有效运行和各种数据查询分析统计的有机结合。

当时公司为某大型软件（上市）公司在该省的分公司和研发中心，成立不到一年。企业 管理和项目管理总体上比较混乱，项目管理中出现了很多问题如项目管理缺乏系统性，项目 管理俸系不健全，项目风险防范意识缺乏，不注重项目经验总结，项目组之间缺乏合作与交 流等。项目组间人员流动频繁，甚至出现分配下去的任务完成一半就改派到一个新的项目组

的情况。部分人员同时参与两个或多个项目，双重甚至多重领导。用我们比较形象的说法是 “消防队一一救火”，管理随意性大，员工整体缺乏稳定的工作环境。为改变这一糟糕的现状，我向公司高层领导提出了建立和完善企业项目管理体系的建议，逐步建立与推行“项目经理负责制”。

对项目管理知识俸系的良好把握和过去几年项目实践中积累的丰富经验，使我很快说服 了公司领导赵总。当天召开了一汝由公司项目经理以上职位人员参加的高效翠会议，赵总主 持了会议。会上大家总结了公司项目管理中存在的一些问题，对在公司内建立和推行项目管 理体系有了很好的认识，很快达成了一致意见。最后落实了人员和责任，由公司技术总监陈 某总体负责该项工作，小刘负责“项目经理负责制”相关制度和文档的起草，我负责该项工 作的进度计划控制和人员安排等。高层领导的支持和参与对项目管理体系在公司内的成功建 立意义重大。

第一阶段工作重点为普及项目管理知识，通过周末集中培训在公司范围内普及项目管理 知识。考虑到成本问题，我们采用外派培训的方式。由于我以前参加过PMI的项目管理知识培训与认证又是当初工作的提议人，所以就被选中参加了一次为期3天的软件企业项目管理方面的专业培训。当然对我来说外派回来任务很重，要对全公司的人员进行2天的培训。我对公司研发人员和行政人员进行了分析，发现很多研发人员进入公司前是又项目管理意识的，但慢慢就被整个混乱的组织环境同化。我对培训内容做了5天充分的准备，采用多选择图片、多举例子、多讲案例的方式。尽可能增加澡程的实质性内容，以项目范围管理、时间管理、费用管理、质量管理为重点，也涉及风险管理、人力资源管理、采购管理、沟通管理和项目整体管理等知谀领域。事实证明那汝培训是很成功的，公司员工参与程度比较高，很多员工当场提出了很多实际问题和一些好的建议。在我看来，澡程最后的一段时间就是一次集思广益的“头脑风暴会议”。

第二阶段工作重点为建立项目管理体系，即“项目经理负责制”。公司整俸有了基本的项目管理知识，就正式开始推行“项目经理负责制”。首先是对组织机构进行了调整，我们采用了项目型组织结构，以避免之前双重甚至多重领导而导致管理纷乱的局面。项目经理对项目组人员控制权加大，项目组人员受项目经理单独领导，明确规定部门经理不能对各项目组人员随意调动。如测试部门人员安排到项目的测试阶段，受项目经理的全权控制，测试部经理对相关人员没有控制权。部门存在的意义只是方便相关人员技术交流和问题探讨。公司设立了项目管理办公室(PMO)，主要职能包括：①提供公司项目管理的支撑环境；②公司内多项目的管理与监督；③项目管理制度、规范、文档模板等的建立与维护；④人员绩效考核与绩效数据库的建立与维护；⑤提高公司整俸的项目管理能力。我作为项目管理办公室成员主要职责为各项目管理制度、规范、文档模板等的建立与维护，我把项目组中采用的比较完整的《项目管理计划》、《工作分觯结构wBS》《进度计划》等文档模板作了适当的修订供公司各项目组共享。PMO参考软件产品生命周期模型-IS0 15504建立了项目过程模型，对模型中主要过程包括软件开发过程、支持过程、组织过程进行了完整的定义。确立了项目组成员、项目经理、项目管理层(PMO)、项目客户四级项目管理控制体系，明确项目范围、进度与费用控制权限在不同角色之间的分配。

后继阶段的工作重点为项目管理改进与提高。公司在形成基本的项目管理体系后，也特 别注重实际项目经验及项目历史数据的积累，及时优化项目管理流程与规范。聘请了外部的 项目管理顾问帮助诊断现行项目管理中存在的问题并提供了有价值的意见。

建立了项目管理体系后，公司总体项目管理状况有了较大的改善。各项目组团队凝聚力 较强，混乱状态逐渐消失。企业级项目管理俸系的建设需要一个逐步完善的过程，企业在关 注项目管理体系建设的同时，应注重项目管理知识的普及、人员培养与项目经验积累，逐步 提高组织的项目管理水平和能力，最终提高项目管理绩效。

论项目中的质量管理与企业质量管理的异同

摘要

20xx年8月，我作为项目经理开始参与某某银行授信业务系统的开发项目，主要工作职责为需求分析、系统设计和项目管理。系统基本功能包括：业务操作、业务提醒、基础资料、查询统计和权限管理等五个模块。系统采用Struts+Hibernate主流Web应用框架，实现Web应用程序服务器WebSphere与协作应用程序服务器Lotus Domino的高度集成。本文结合作者项目实践，以该项目为例，讨论了信息系统项目中的质量管理问题，主要包括配置管理、技术评审和软件测试等质量保证方法和策略。项目的成功很大程度上归功于在项目过程中各个阶段对质量的有效管理和控制。文章最后结合ISO和CMM分析了信息系统开发中的质量管理与企业质量管理联系与区别。

正文

20xx年8月，我作为项目经理开始参与某某银行授信业务系统的开发项目，主要工作职责为需求分析、系统设计和项目管理。当然也做一些编码工作，主要是基础性公用代码和关键核心代码的编写与维护。授信是指银行以自身信用向客户提供贷款（包括项目贷款）、担保、开票信用证、汇票乘兑等业务，授信业务是商业银行资金运作中最为重要的业务之一。开炭授信业务系统，提高授信业务的管理水平和运行效率、充分利用共享的信息资源、减小各种风险、运用各种科学的金融分析模型指导业务开展具有十分重要的意义。系统基本功能包括：业务操作、业务提醒、基础资料、查询统计和权限管理等五个模块。系统全面实现授信业务的网上操作，实现流程的上报，审批和管理，大大提高了授信业务工作效率。提供了强大的业务查询和统计功能，便于对授信业务工作的管理和监督。其中业务操作模块实现授信业务工作流程，主要包括正常类授信业务申报、问题类授信业务申报、特殊类授信业务申报和授后监控业务等工作流程。

系统采用Struts+Hibernate主流Web应用框架，开发工具采用WebSphere Studio Application Developer 5.0 (WSAD 5.0)，WSAD5．O集成并扩展了Eclipse 2.0的功能。硬件 配置方面：IBM P610小型机用于安装WebSphere 5．O，DELL服务器用于安装Domino硒和SQLSeiver 2000。实现Web应用程序服务器WebSphere与协作应用程序服务器Lotus Domino的高度集成，并使用Single Sign On(SSO)实觋单点登陆。总体架构思想，将表单数据的生成和分析采用关系型数据库来实现，通过WebSphere架构实现业务逻辑的处理，而表单的审核流程由Domino进行驱动。将基于业务为主的J2EE服务系统和基于协作为主的DOMINO流程处理系统有效的结合起来，确保整个业务流程的有效运行和各种数据查询分析统计的有机结合。

在该项目中，我们主要通过配置管理、技术评审和软件测试等质量保证方法和策略来保证 系统的质量。

配置管理是项目中实施软件质量管理的关键，公司为项目组配备了一名兼职配置管理员 辅助我完成配置管理工作。同时根据公司项目管理部门的要求项目设立了变更控制委员会 CCB，主要由技术总监、我（项目经理）、用户代表、质量管理员、配置管理员等5人组成。 在公司里变更控制委员会是处于尝试阶段新生事物，所以具体的配置管理和变更控制主要由 我和配置管理员完成。公司主要采用Visual SourceSafe 6.0(VSS 6.0)作为配置管理的工具， 主要考虑到VSS操作简单，界面友好，版本控制功能强大和比较常用等原因。项目一启动，

我们就在公司配置管理服务器上建立了项目开发库，开发库主要供项目组开发人员使用，变 更比较频繁。我为项曰组每个成员建立了访问帐户和权限，项目开发库主要由我负责管理和 控制。配置管理员负责管理和控制项目受控库，用于保存项目各阶段结束时发布的阶段性文 档。如需求分析阶段结束《软件需求规格说明书》，概要设计阶段《概要设计说明书》等。

2、定期开展技术评审

项目各阶段进行必要的技术评审活动，如在软件需求分析阶段结束后进行软件需求评审， 以确保在《软件需求规格说明书》中所规定的各项需求的合适性。详细设计阶段制定了java文件包的命名规则，如问题类客户行动计划申请相关类包含于com. opr. question.plan以下，其下统一细分为Dao、Action, ActionForm相关类。这些规则必须在编码阶段得到很好的遵循和执行。评审活动一般由项目经理（我）和质量管理人员分别进行。项目组每周五下午召开进度审查会议，对本周各任务完成情况进行总结。对已完成的任务进行验收，验收包括对功能和代码质量的总体把关，对出现进度延迟的任务进行分析及时解决问题。如评审中发现小邵完成的正常类授信业务一完全现金保证额度申请功能没有采用项目组规定的统一的页面处理方式，即先提交数据后根据返回的状态标识或异常情况统一关闭提交页面或返回到锗误提示页面。这种页面处理方式的优点是当用户数据提交不成功时，已经输入信息的不会丢失， 同时给予必要的提示。实践表明，即使在数据提交前页面校验很完整的情况下，也存在一定 出现提交不成功事件发生的概率。特别是在财政、金融、银行等行业的应用系统中一般页面 输入数据量较大，出现数据提交不成功而需要第二故重新输入将严重影响用户对系统的兴趣 和态度。我们认为健壮性和可使用性是比较关键的质量指标。

3、充分做蛔钡腻工作

测试作为保证软件质量的重要手段，在该项目中地位非常明显。编码阶段我们主要进行 单元测试，采用编码人员自己测试和项目组内部交叉测试向接合的方式。如正常类授信业务 模块与问题类授信业务模块的编码人员相互交换进行测试。交叉测试的优点在于能够发现很 多编码人员自己测试自己的程序不能发现的问题，所谓“傍观者洁’’！集成测试和系统测试由测试小组单独负责，主要采用测试管理工具IBM Rational TestManager和有“最佳功能测试工具刀之称的功能测试工具Rational Robot。测试人员负责测试脚本的编写，Rational Robot 根据事先记录的页面数据输入（或操作），执行脚本自动实现功能测试。测试人员把洌试中发现的Bug和问题提交到TestManager，由TestManager负责统一管理和控制。项目经理（我） 对各Bug进行分类并设定修复优先级，分配给具体项目组编码人员进行修复。编码人员修复 Bug后，通过TestMa nager反馈修复信息给测试人员，测试人员进行测试直到没有发现问题。 TestManager可以用来从测试计划、测试设计、测试实现、测试执行和结果分析等多个方面进行测试管理，管理和控制功能将大，还提供图形化查询和统计图表。对于基于B/S GUI技术的应用程序自动进行功能和性能测试，Rational Robot是主流的和推荐的选择。TestManage 和Rational Robot等测试工具的综合运用大大提高了项目组的测试效率，有效和有力保证的 软件系统的质量。

授信业务系统在20xx年12月下旬正式上线，提前1周完成了项目。目前系统运行正常， 受到客户方各有关部门的一致好评，对项目满意度较高。项目的成功很大程度上归功于在项 目过程中各个阶段对质量的有效管理和控制。没有质量管理，项目也可能成功。但没有质量 管理的项目，无论从质量、时间、成本任何一个方面看部是有巨大风险的。

信息系统开发中的质重管理与企业质量管理联系比较密切但两者的区别也是很明显的， 两者不可简单的互相替代。前看属于项目管理层面，而后者属于企业管理层面。信息系统开 发中的质量管理重点是通过执行必要的质量管理过程如质量计划、质量保证和质量控制等来 保证项目最终交付的成果对客户需求和期望的一致性，主要涉及软件研发过程中的细节内容， 如必要的配置管理、单元测试活动等。如CMJK强调的是软件开发过程的管理。而企业质量

管理的任务是企业级质量管理体系的建立、管理与维护，主要涉及企业质量规范、制度的制定和宏观支撑环境等内容。如IS0 9001侧重于”机构保证在设计、开发、生产、安装及服务过程中与指定的要求一致”。ChtM和IS0 9001两者的最大相似之处在于两者部强调“该说的要说到，说到的要做到’’。对每一个重要的过程应形成文件，包括指导书和说明，并检查交货质量水平．两者者B{吕调椿续甜；#．

论软件开发的风险管理

摘要：

本文讨论了某公司实施SAP系统的风险管理。该公司原先运行着一套ERP系统，现在要转到SAP上，需要完成新系统的流程的重新定义，数据的切换，用户的培训等工作。项目要求在11个月的时间内完成。实施一个大型的ERP系统有着各种的风险，这些风险如果不加分析和控制，将会给整个项目造成致命的影响。我作为项目经理，主要从控制进度风险，人员流动风险和系统功能风险三个方面去进行风险的管理。最后这三方面的风险部得到了有效的控制，从而使项目顺利完成。

正文：

20xx年1月，我参与了西门子集团下某公司的SAP系统的实施，提任项目经理。该公司之前运行着另一套ERP软件：QAD的l/tFG/PRO系统。由于集团总部的要求，要用SAP系统替换原先的MFG/PRO系统，并且要在20xx年11月前完成。整个项目完成以下阶段，首先是项目的引进，包括成立项目小组，由顾问对项目小组成员进行初步的培训，让小组成员对SAP的标准流程有个大概的认识。接下来是要分模块进行讨论，制定出各模块的实施蓝图 (bluepiint)。该公司实施了以下的模块：SD（销售与分销），肌（物科管理），C0（成本控制）， QM（质重管理），PP（生产控制），FI（财务核算），co（成本控制）等。在Blueprint完成后， 由顾问根据定下的流程配置一个测试的系统，用户在该测试环境下进行练习和测试。测试完 成后就是数据的准备和切换了，要从MFG/PRO系统把需要的数据下载下来然后你上传到SAP 系统。完成数据的切换，SAP系统正式上线，同时不再使用原先的系统。

因为整个项目要在11个月的时间内完成，时间是非常紧迫的。如何在如此短的时间内使项目能顺利进行，控制各种可能出现的风险是必要的。为此，在项目的初始阶段，我召开了小组成员开会，专门针对项目的风险进行了讨论。会上，大家把想得到的风险部提了出来。 经过分析筛选，我最后确定了三个重点进行控制的风险，并采取了相应的措施进行控制。

1、控制进度贝脸

ERP的实施是一个大型的项目，涉及到企业的流程改造和其它方方面面的东西。而该项目的上线时间不能改变，所以，项目进度在这里是个潜在的风险，如果不能如期上线，则公司将的运作将会受到重大的影响。为此，我在项目启动后，召集了项目小组成员开会制定项目计划。我首先用Microsoft Proj ect制定了项目的总体计划，在这个总体计划中，明确了各 个阶段酌任务和完成时间。如什么时候完成设计蓝图( Blueprint)，什么时候进行关键用户 的培训，什么时候进行测试和练习，什么时候进行数据的切换等。总体计划制定出来后，各 顾问在总体计划下制定各模块的实施计划，把每个模块在每一阶段的问题细化。各模块的实 施计划要在总体计划的基础上进行，在任务和时间上不能滞后于总俸计划。无论是总体计划 和实施计划，都要求明确各步完成的时间，要精确到哪一天，而不能用模糊的描述，比如“3 月初完成Blueprint”这样的低描述是不充许的。为保证项目照进度进行，每周五都要召开项 目会议，检讨项目的进展情况，发现有超期的任务，分析原因，及时解决。在进度的控制方 面，还要应付突发的事件造成的影响，及时地调整计划以适应新的情况。20xx年4月-5月，

由于受到“非典刀的影响，外部顾问不能出差来我公司，这使项目的进度受到了很大的影响。 为了把这种影响降到最低，我即时调整了项目计划，把这段时间安排为关键用户的培训和对 系统的熟悉。因为之前顾问已对关键用户进行了一些培训，所以用户对SAP系统有了一定的 认识。通过上机的操作，更进一步了解系统。有问题我们通过E-Mail与顾问联系。通过这种方法，把顾本以后进行的用户练习提到了前面。虽然没有顾问的现场指导，但通过自己的摸索对系统的印象更加深刻，为之后的工作打好的基础。

2、控铂¨圃碲陕的网脸

在实施SAP过程中，有两种可能会导致人员的离职，一是工作繁重乏味，压力大；二是 积累了一定的SAP经验后找工作相对比较容易，这时如果有其它更好的机会，员工会考虑跳 槽。而项目小组人员流动将会对项目造成很大的影响，甚至导致项目的失败。所以如何控制 这些风险，是作为项目经理要考虑的问题。为此，我首先与人力资源部一起，制定了一套有 效的激励机制。包括，把参加SAP项目作为年终的一个绩效考核内容；因为项目需要加班加 点的，公司免费提供晚餐；设立项目基金，对表现突出的小组成员进行物质上的奖励；在整 个公司的范围内大力宣传SAP，让项目小组成员感觉到SAP的重要性和实施项目的价值等。其次，为了避免出现某个项目小组成员离职导致项目不能进展的情况出现，我在每个模块部安排了两个人员负责，一个是主负责，一个是次要负责。这样，可以减少人员流失造成的损失。在这里，我没有采用让项目小组成员签合同的方法，即实施项目后要在公司工作多少年。我觉得这种方法会给小组一种压抑的感觉，而公司主要要霏企业文化来吸引员工。事实证明， 我所采用的措施是有效的：在整个项目的实施过程中，没有一个小组成员退出或是离职。在 项目运行一年多来，只有两个当时的关键用户离职，而他们离职后后备人员可以马上顶上来， 对系统没有造成什么影响。

3、控制系统的功能

有人戏称SAP是“Stop All Production"，这也从一个方面反映了实施SAP的风险所在。 而造成上了系统后停产的一个原因就是系统功能不能满足物流和生产的需要，这也是我担心 的一个问题。因为切换后1日系统不能再使用，如果这时候新系统满足不了需要，就真的会造成停产。为此，我在项目中采用了演化型的原型开发方法，用演化型的开发方法，可以让用户针对已配置好的原型进行测试，发现不能实现的功能及时提出来，改进后再测试，再改进。在这里，测试工作显得很重要。为此，我强调要一定要做好测试工作。在系统测试阶段，我把所有的项目成员集中在会议室中进行系统测试。在测试中，我要求用真实的数据，模拟真实的环境进行。系统测试通过后，我还特别做了一次上线前的演习，即把所有相关的数据都导致SAP，配置一个上线后要用的系统，在此系统上进行操作。这次演习成功后，坚定了大家使用系统的信心。系坑上线后也没有出现什么大的问题。

通过以上措施，使把SAP的主要风险基本上部控制在萌芽状态，项目没有因为这些风险 受到影响，最后项目如期上线，受到了管理层和用户的肯定。

在项目进行过程中，有些风险并没有事先预计出来。比如说顾问的问题。有的顾问水平 高，但项目也多。用在我们这个项目上的时间就比较少，这给项目带来了不利影响。为此， 我通过和该项顾问所在的公司签定合同，注明顾问在我们公司的工作时间，否则将属违约， 通过这一方式使顾问的管理得到改善。

论信息系统开发的变更控制

摘要

20xx年8月，我作为项目经理开始参与某某银行授信业务系统的开发项目，主要工作

职责为需求分析、系统设计和项目管理。系统基本功能包括：业务操作、业务提醒、基础资料、查询统计和权限管理等五个模块。系统采用了Web应用程序服务器WebSpheie与协作应用程序服务器Lotus Domino的高度集成的技术构架，基于Struts架构实现IKVC模式。信息系统项目由于目标不明确、需求变化频繁等原因，开发过程中发生变更在受难免。为了保证项目有序进行，实施强有力的变更控制和管理非常必要。本文对项目中采用的变更管理方法、措施和工具VSS，以及变更控制的主要步骤进行了较详细的介绍。最后对项目变更管理过程的一些实际问题进行了总结。

正文

20xx年8月，我作为项目经理开始参与某某银行授信业务系统的开发项目，主要工作职责为需求分析、系统设计和项目管理。当然也做一些编码工作，主要是基础性公用代码和关踺核心代码的编写与维护。授信是指银行以自身信用向客户提供贷款（包括项目贷款）、担保、开票信用证、汇票乘兑等业务，授信业务是商业银行资金运作中最为重要的业务之一。开发授信业务系统，提高授信业务酌管理水平和运行效率、充分利用共享的信息资源、碱小各种风险、运用各种科学的金融分析模型指导业务开展具有十分重要的意义。系统基本功能包括：业务操作、业务提醒、基础资料、查询统计和权限管理等五个模块。系统全面实现授信业务的网上操作，实现流程的上报，审批和管理，大大提高了授信业务工作效率。提供了强大的业务查询和统计功能，便于对授信业务工作的管理和监督。其中业务操作模块实现授信业务工作流程，主要包括正常类授信业务申报、问题类授信业务申报、特殊类授信业务申报和授后监控业务等工作流程。

授信系统采用了Web应用程序服务器WebSphere与协作应用程序服务器Lotus Domino的高度集成的技术构架，并使用Single Sign On(SSO)实现单点登陆。总体架构思想，将表单数据的生成和分析采用关系型数据库来实现，通过WebSphere架构实现业务逻辑的处理，而表单的审核流程由Domino进行驱动。将基于业务为主的J2EE服务系统和基于协作为主的 DOMINO流程处理系统有效的结合起来，确保整个业务流程的有效运行和各种数据查询分析统计的有机结合。系统基于Struts架构实现腻模式。

考虑到银行帐户年度等因橐，客户要求系统在20xx年12底前交付，项目开发周期为4 个月。由于我和项目组部分成员都有一些失败项目的经历，所以整体上对项目管理比较重视。 需求分析阶段我们的一贯目标是采用文字或图形化（该项目中主要采用Rational rose和 Visio工具）的方式清晰正确地描述了至少80%的实际需求，并在完成系统设计完成或编码阶段开始前明确剩余需求，高质量的需求分析为项目范围管理奠定了基础。基于对客户需求的良好把握，综合使用类比法、自上而下法和自下而上法创建高质量的工作分解结构( WBS)。 通过工作分解结构把项目范围分解开来，使项目组人员对项目一目了然，能够使项目的概况 和组成明确、清晰、透明、具体。

进入项目实施编码阶段，可能引发范围变更的需求因素主要为部分未明晰的需求包括： ①问题类客户行动计划申请流程；由于该流程涉及风险处、授信处、风审会和贷审会等部门， 对于流程是否要简化和参考总行的相关做法存在较大分歧，没有能短时间达成一致意见。② 查询统计部分需求：该部分需求系辅助性功能需求，需要综合和汇总全分行各部门及下属支 行用户的需求。③客户方面可能提出的新需求。

变更是信息系统开发项目的一个突出特点，也是信息系统顼目最为普遍的特点。变更管 理的目的是对于复杂、无形的软件，防止在其多变的情况下失控，出现混乱，最终造成工作 的损失。因此在该项目中，我们十分重视对项目变更的控制和管理，项目中主要采用了配置 库、变更控制委员会、变更评审会议等方法和措施。

公司为项目组配备了一名兼职配置管理员辅助我完成配置管理工作。同时根据公司项目 管理部门的要求项目设立了变更控制委员会CCB，主要由技术总监、我（项目经理）、用户

代表、质量管理员、配置管理员等5人组成。在公司里变更控制委员会是处于尝试阶段新生事物，所以具体的配置管理和变更控制主要由我和配置管理员完成。公司主要采用Visual SourceSafe 6．O(VSS 6.0)作为配置管理的工具，主要考虑到VSS操作简单，界面友好，版本 控制功能强大和比较常用等原因。项目一启动，我们就在公司配置管理服务器上建立了项目 开发库，开发库主要供项目组开发人员使用，为项目组每个成员建立了访问帐户和权限等， 项目开发库主要由我负责管理和控制。配置管理员负责管理和控制项目受控库，用于保存项 目各阶段结束时发布的阶段性文档。

当我完成项目管理计划好，配置管理员基于项目管理计划和公司项目管理部门文档雏护 的模板完成了《配置管理计划》，主要包括了配置项计划、《配置项管理表》、《变更请求申请 表》、基线计划、交付计划和备份计划等。提交项目管理部门审批同意，然后召开了一次由项目组全俸人员参加的配置管理专题会议，明确工作流程，落实责任人等相关事项。

由于每年最后几个月为银行业务旺季和客户方部分人员交叉出差等原因，需求分析阶段 的遗瞽问题一直没有得到解决。需求说明书也一直没有得到正式签字确认，为了不影响项目 总俸进度，同时考虑到主要的需求是确定的，项目组直接进入了分析设计阶段和后继的编码 I阶段后。为了能尽快落实未明晰的需求部分，我与客户方主要项目负责人方某进行了面对面的沟通。通过一番利弊关系的陈述，达成尽快明晰悬瞽部分需求的共识。当然主要由方某负责内部协调，统一风险处、授信处、风审会和贷审会等部门对问题类客户行动计划申请流程的意见。第二周星期一上午刚上班，就接到了方某的电话，告诉我各部门对问题类客户行动计划申请流程已经达成了一致意见，查询统计部分需求也整理完毕。根据客户方面提供的意见，我对《软件需求说明书》作了必要的修订，并提交客户方项目关键负责人方某正式签字确认。《软件需求说明书》的变更相应的也带宋了《概要设计说明书》、《详细设计说明书》和《数据库设计说明书》等关键性项目文档的变更，并对开发库和受控库内相应文档进行了版本升级。

20xx年11月中旬，当主题编码阶段完成进入测试阶段。客户方提出了新的需求，由于在正常类授信业务申报、问题类授信业务申报、特殊类授信业务申报和授后监控业务等20多个工作流程中部涉及客户资料（如《企业法人营业执照》复印件、《税务登记证》复印件、《组织机构代码证》复印件等）的上传，客户要求系统中增加一个功能实现对扫描仪的直接调用。由于考虑到该功能最终用户（各支行客户经理）处扫描仪型号不统一等问题，项目组没有批准这一变更，当然向客户提供了充分的理由。

事实证明，需求分析阶段工作必须要做到位，就好像摩天大楼的地基一定要保质保量。 需求分析图形化工具如Rational rose和vlslo等的采用，以及原型方法和快速原型方法的 采用将有效地帮助项目组整体对项目范围和产品需求的把握，从而从项目早期就开始尽可能 避免不必要的变更。

变更控制委员会存在一些缺点：比如变更的决策过程可能要花费较长的时间。变更控制 委员会通过一次会议可能无法做出决策。因此我们对该过程进行了简化，以便可以就次耍的 项目变更做出快速决策。公司项目管理部门采用了"48小时政策”，可以由项目小组核心成员在其技能和权限范围内对关键、央策或变更达成其识。受决策影响或变更影响严重的人员只有48小时向高层管理人员汇报并获得批准。如果某些原因，相关高层经理可以在48小时内修改决策，否则项目团队的决策则视为被批准。

VSS的项目组织管理使得项目组的协调变得简单容易且很直观，当一个和一组文件发放给另一个成员、小组、Web站点或是任何其他的地址，VSS确保他们之间的真正共享及所选的一组文件的不同版本的安全性。

授信业务系统在20xx年12月下旬正式上线，提前1周完成了项目。目前系统运行正常， 受到客户方各有关部门的一致好评，对项目满意度较高。项目的成功很大程度上归功于在项

目过程中各个阶段对变更的有效管理和控制。没有变更管理，项目也可能成功。但没有变更 管理的而日．弄；参从席量、时n、瞄杰仟何一个青而看者B旱有巨女冈除的． 论软件需求分析方法和工具的应用

【摘要】

本文讨论《企业人事信息系统》项目的需求分析方法与工具的选用。该系统的建设目标 是帮助该企业管理好企业内部的人员和人员的活动，人事信息管理指的是企业员工从招聘面 试到离职退休的全过程，涉及的主要活动包括面试、报到、培训、升职、离职或其他的人事 变动，也包括电子化考勤、工资性收入的计算与分发、使用其他公司资源的有关记录（如宿 舍、保险、证件办理等等）。此外，本系统也涉及到企业在全国各地的人事信息管理，企业的组织架构的设置，级别与职务管理，人力申请直至人力需求报表，从而形成一个对企业真正有用的人事信息管理应用系统。在本文中首先讨论了选用而向对象方法与工具的主要理由与策略，进一步通过一个简例说明该方法与工具使用的效果，也讨论了使用多种工具与方法在需求分析中的必要性，最后简要小结了选用正确工具与方法的意义和作用。

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

【正文】

人事信息管理系统是一个有着广泛应用面的实用性系统，但是，我国各个企业有着自身 的体制、机制、特点与不同的要求；在开发这类系统时，系统需求分析是极为重要的一环。 在整个分析过程中，我们都采月了面向对象的分析方法，这是因为我们在近几年的实践中已 坚信这种方法能够更加有效地表达和描述现实世界。软件要具有适用性和扩展性，就必须更 接近于现实世界本身的发展规律。

以一个简单的例子来看，假设要求设计关于引进人才评估的一个系统，按我们过去的做 法，先会要求提供给我们一份相关的引进人才评估表，然后依葫芦画瓢地设计相应的表单与 界面，在短期来说，这样做是简便而实用的，但并不能够符合现实世界的长远目标，这套设 计方法不具有扩展性，因为任何一份评估表的结构都会有可能生许多改变的。要用面向对象 的方法，可以从中提取出表类型、表结构、评分方法以及能考虑继承等各方面的要素，这样 就可以保证软件的通用性，可配置性与可维护性。

在工具的选择过程中，我们选择了现在已十分流行的Rational系列，包括Rational Rose, RUP、SoDA等，为什么选取这个系列工具呢？这是基于我们对软件需求分析目标的看法，我们

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

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

(2)用户理解或明白我们所描述的内容吗？

(3)分析是否会和设计相脱节？

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

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

(1)详尽地获取用户的需求。

用户的需求可分为显式的需求与隐性的需求，用户的倾向往往只顾及到当前的与明显的 需求。要达到需求理解的全面性，不仅仅只是依靠有效的用户谈话和调查，因为我们所面对 的用户需求往往会有些片面的，采用Rational Rose（基于UML）提供的用例，以及多种图的 联合使用，可以使我们发现其中的遗漏。

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

软件需求分析规格说明书通常会是冗长而枯燥的，一般的用记不容易深入理解，这样就 削弱了分析的正确性。通过支持面向对象及mrtL语言的RationaIRose可以更好地和用户交流，

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

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

这是我们选择面向对象的方法及RationaIRose工具的重要原因，系统分析要向用户描述 的不仅仅是用户的需求，而且包括解、央方法，解决方法当然应包括设计（程序）、数据库与系统配置，我们当然不希望用户得到的是一个与需求规格说明不相同的软件，也不可能要求程序员完成一个不可胜任的任务。然而我们在以前的多项工作中经常发现这类情节，因灼系统分析与设计相互脱节，导致一头扎在分析中不顾设计有关的事宜。

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

因为不可能成功地完成设计而使分析需要重来，就会造成巨大的浪费与损失。一个好的 工具可以使分析与设计更紧密地连结起来，甚至于一一对应。面向对象的分析方法使对象之 间相对而言有独立性，减少了任何影响到全局的改动，能避免因需求变化而导致全盘皆动的 被动局面。

(4)使程序员明白我们的设计。

一个好的设计应该让程序员感到清晰是白，更少疑问。一个疑问很多的设计加上沟通不 畅，绝对会出现在应用环境下所不需要的另一个软件，所以设计规格说明书务必清楚、形象 与明确，当然RationalRose具有足够的图形与其他形式，能使程序员更加明确，甚至能细微 到每一个语句（事实上如果使用VB，程序架构部有可能直接生成了）。

(5)选择UML可能会有更多的理由。

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

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

在分析中，面对考勤班次的问题时，由于过去一直使用纸卡方式考勤，使用户对班次形 成了固定的概念，而现在的讦多考勤软件也采用多次刷卡的方法来形成一天的记录。经过面 向对象的分析可以发现，事实上每天的上班记录是由多个时段所形成的，时段的多少在各个 公司，各个工种与部门都不尽相同，每个时段可能有不同的属性，时段与时段组合可形成为 班次，这更适合于现实的情况，使之能更加灵活与更有扩展性。其实，在天与天之间也都有 相互之间的关系。在这一点上，我们又发现必须在考勤与薪金工资中加入与htRP中相似的期段(Periods)的基本概念，比如可以称之为考勤期段，允许为用户更加方便地设置考勤期段， 可能使之不一定与自然年月日相同等等。

Rational Rose使我们更方便地把上面的想法在类上去实现，更进一步地设计好我们的高 效率的数据库。

当然，使用单一的一个工具去完成一个中大型的应用系统的需求分析，是不可能成功的， 因为社会在发展，用户的需求也在改变，如何把握住用户的需求是需要时间的，而向对象的 方法有时也会忽略外在的与表层的要求，不仅仅是要获得关键的需求，其他更多的需求往往 要等到用户在使用后才知识，然而等到用户使用是不现实的，作为原型开发模型中的原型也 是收集用户需求，描述与解释需求的一类相当有效的方法与工具。

在我们的开发过程申，为了更好地让用户了解我们的系统和我们的设计方案，让用户在 见面会上更有方向性与针对性，我们首先用Access开发出原型，让用户先试用。这样，我们在真正的分析与设计时就能更加符合用户的要求。

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

效能的正确的方法与工具，可以使我们的软件更加正确地反映现实需求，更加具有可用性、 可扩展性和可维护性；降低了软件项目的风险。

论需求分析方法和工具的应用

【摘要】

本文以某个IT产品销售公司的信息系统项目的开发为背景，讨论了一个信息系统需求分析的整个过程，其重要特征是：所涉及的项目是原有系统的一个升级替换版本。因此，需求分析过程不同于建立一个全新的系统，大俸上可分为三个阶段；(1)实施逆向工程获得对系统的初步了解；(2)在第1步与客户交流，最终获得基本需求，交由客户评审补充；(3)在 第2步的基础上开发原型，利用原型与客户交流，最终获得基线需求。针对上述三个阶段， 本文论述了所使用的分析方法与工具以及所遇到过的一些典型问题和措施，最后对需求分析 中使用的工具，谈一些自己的初步体会。

【正文】

我于19xx年8月至20xx年7月参加了某个大型集团的企业信息系统的开发工作，该大型集团的业务主要涉及到IT类产品的进销存。本人在项目中负责系统分析的工作，该集团企业原先已委托某个电脑公司开发过一套IT类产品管理系统，但是该老系统存在两个主要的问题：（一）系统运行速度非常慢，如商品销售开单时，从确定开单到开单完成有时需要1~2分：钟左右的响应时间，让客户无法忍受。（二）系统数据不准确，经常出现实物库存与电脑库存严重不相匹配的情况，使铛售数据的统计产生一些混乱，有关财务的数据因此无法有效使用，只能采用人工录入方式补充进行。在这种情况下，该集团的总经理决定参考原有系统重新开发一个系统，以便解决原系统所存在的上述两个难以克服的难题。注：原系统要用PB6.5开发，数据库采用SYBASE，服务器采用Windows 2000Srever，客户端采用Windows 98。程序架构采用的是传统的C/S结构。

鉴于该集团业务操作复杂，流程多，涉及人员多等特点，以及项目完成时间短，经费有 限，人员有限等限制约束条件，再考虑到必须避免前一系统出现过的结构混乱与难于维护等 问题，我们、央定要对原系统的需求做一个比较彻底的和切实可行的分析，由于原有系统已经开发了近两年，并且客户也有了一定的使用经验，业务基本流程本身也并没有太大的变化， I因此，我们把需求分析的过程分为三步：(1)分析原有系统的结构，主要是数据库结构和程 序结构，(2)在获得第(1)步结果的基础上写出基本需求，交由客户评审补充，(3)在第(2)

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

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

由干原有系统在功能上大俸上能基本满足客户的需求，并且两年多的开发中也积累了不 少经验，因此，从中可以获得一些有益的参考，也可以避免多走弯路。在这一阶段，我们采 用的主要工具是PB自带的Power Designea:和PB Doclunents;前者主要用来分析数据库结构， 后者主要用来分析程序结构，便于开发人员与高级用户理解程序，采用这两个工具的原因是： ．原系统过于庞大，模块多，数据库模式多，表格量很大，仅靠人工的方法很难从中获得一个．比较完整的、明确的系统结构以及整体构成，而且原有系统未能提供一套正确完整有效的设计文档，于是我们只能依靠工具辅助来进行。在使用Power Designer分析数据库，并且PBDo clunents分析原程序中的PBL以后，我们对原系统的结构有了一个初步的了解，再结合对原系统的使用，基本明确了功能与流程的需求，并在此基础上用人工录入方式，产生了初步需求的自然语言文档。这里指出，使用Power Designer的一个不足之处是：如果一个表

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

第二步是在第一步的基础上进行的，即丐出系统基本需求，交由客户评审和补充。 通过第一步的逆向工程，我们获得了系统的基本需求。为了充分记录需求的变化及需求 之间的依赖关系，我们决定选用Rational公司的Requisite PRO作为我们的需求管理工具， Rational公司有一整套用于需求管理的工具，功能非常强大，包括Requisite Pro, Cle ar Qust 等等，这些需求分析工具可以对需求进行全面的管理，包括记录需求的变化情况，需求之间 的依赖关系等等，但是，残们考虑到Rational的一套工作全面实施会非常昂贵与复杂，需要 j E常强的项目管理能力才能全面实施，因此，裁们只要用了其中最简单的一部分功能，那就是记录需求变更，记录需求之间的依赖关系，其他跟RUP关的功能部给略去了。之所以这样做，主要是考虑到项目的经费人、人力以及国内软件开发的实际情况，正如前面所说，我们根据自己的理解并写出基本需求后，交由客户做评审并做适当补充，我们将经过补充整理后的需求作为正式需求记录人Requisite Pro所维护的数据库中，并对各个需求进行分类，设定优先级等，这些工作完成后，就可以从数据库中直观地了解客户到现在为止提出了哪些需求，哪些需求是必颁优先考虑的，哪些是难度较大的等等。在这个过程中，我们遇到了一些问题，譬如：用户对我们用自然语言书写的需求文档有许多地方不理解，往往在花了较长时间阅读之后，仍不明白我们所描写的需求过程与他们所完成的业务之间的对应关系，另外是由于首次采用Requisite Pro进行需求管理，在类型划分，属性值的在确定上，部分开发人 员没有经验，造成了不少反复，对于前者，我们在方法是想办法增加一些示意图，将大的流 程分解为小流程，再与客户反复交流与沟通，最终达到双方理解一致的目的。对第二个问题， 则参考了一些例子，再结合实际中属性的使用情况，给予取舍或者选择，经过这一阶段工作， 我们建立了基本的需求库，定出了基本需求规格说明。

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

在这一阶段的工作是在对第二步任务进行报告交流的基础上进行的，我们用PB开发了一个原型系统，就具体的业务流程与客户进行交流与沟通，通过原型，客户发现了许多我们与他们的理解相互不协调的地方，我们在修改需求的同时，也在Requisite Pro需求数据库中 记录不修改的历史。事实证明，这种记录历史的作用是很有赦的，如曾经有客户在两个不同 的时间对同一需求提了相反的需求，我们根据历史记录很快证实了该客户的提法有错误，在 事实面前无需再作争论，同时利用Requisite Pro，我们还发现了一些需求相互之间有矛盾， 经过这一阶段工作，我们终于获得了经过用户认可的需求基线，即是可用于下一步进行详细 设计的基线需求。

在这个项目中，我们利用了Power Desing、PB Doclunents等逆向工程分析工具和

Requisite Pro需求管理工具，这些工具的使用，使我们提高了工作效率，起到了一定的辅助 作用。但是，就需求分析工具方面而言。我们觉得国内应用得还是太少了，这一方面是因为 对需求分析不够重视，另一方面是因为管理水平还达不到相应的层次。Rational公司的一整 套需求分析工具，其功能是非常强大的，国外已在普遍地使用，在国内也逐渐开始普及，特 别是那些通过CMM二级以上评审的单位，部必须使用工具对需求进行管理。在本项目中，我们仅仅利用了Requisite Pro功能的一些小方面，已经体会到该工具对于项目管理的诸多好 处。如果一个有实力的公司能够全面实施RUP，那么需求管理这个老大难的问题会变得不再那么棘手了，项目的赝量也会得到相应的提高。目前国内由于ChtM热潮的兴起，已经逐渐重视需求分析，也逐渐使用需求分析工具，这是非常可喜的，当然，更希望在不久的将来，能用卜国产的需求分析T且，羽BB叶糟fi'l的软件产、ll，巾．许会直下恤陛飞了。

论软件需求分析方法和工具的应用

【摘要】

本文以某通信公司的业务报表系统开发为例，讨论了软件需求分析工具与方法的选用。 我们认为，软件需求分析是软件工程中重要的一步，直接关系到后继工程进行以及最终的产 品能否满足用户的需求，因此在整个工程中起着关键性的作用。采用适当的工具，有可能显 著减少需求阶段的错误，也可大幅度提高需求分析的质量和工作效率。当然工具的选用应当 与实际的项目相结合，充分地发挥工具的作用。本文结合我们工作的实际经历，简要讨论了 开发系统时选用的工具及其应用，选用时所考虑的原则以及所碰到的问题。在文中也结合多 种开发方法（即传统的瀑布法、信息工程法、而向对象的方法）的比较，指出各种方法的不 足之处，说明我们所采用的工具对软件需求分析所起的作用，以及相应产生的效果。

【正文】

我在某市一家通信公司工作，作为一名技术骨干，受领导委托，参与了开发本公司的业 务报表系统，我担任系统的需求分析，总体设计和部分代码的编写工作。

我所在的企业作为一家通信运营公司，分为总部、省级公司和地市级分公司三级，各级 公司之间部有数据报表的要求，但是，每一个地市分公司因所处的地方不同，经营环境不同， 所面临的问题也不一样，因比形成了各各具特色的数据报表（除地市分公司向省公司汇报的 之外）。公司又分设了许多部门，这些部门也都会需要数据，作为分析决策的依据。因此，了解各个部门的需求就成了业务报表系统的关键。

在调研的过程中，我选用了一种工具叫PlayCASE，可以从网上免费下载，有很强的功能。 下面就介绍一下，在需求分析阶段，我是如何使用这一工具的。

第一步，了解业务组织结构。公司内部的数据实际上是在部门之间流动的。业务部门需 要知道在本地覆盖区内各基站的话务量、当天的话务量（即话务量的时空分布）。财务部门需要知道本月各类用户的话费收入、预交款收入、与其他电信运营商的网间结算等。计划部门需要各部门的分析数据。计费部门需要提供本月的账单统计数据、话单统计数据分布（比如分别按照基站分布、时段分布以及按用户类别分布）、预交款统计数据、当前的欠费总额分布、催缴情况等等。这些部门时常为了数据而产生了大量无谓的争议。在使用Play CASE工具时，先要将这些部门录入到Play CASE的“业务部门”中，构成了一个信息源的接收点（或发送点）；而Play CASE通过图示表示了这些部门的关系，并转换成了相应的软件结构。实际上，这是一种系统建棋的方法，即把业务系统中的各个组织，转变为软件功能中的各个结构。这样，在需求分析阶段，明确哪些部门需要数据，从而保证了需求分析对整个公司的全面性，而不会忽略掉某一个部门，导致需求分析的不完整。

第二步，了解各个业务部门中的业务流程，使之通过PlayCASE转换成软件的运行过程， 这是一种动态建模的方法。在上一步的基础上，追踪各个部门的行为，录入到PlayCASE中， 并以形式化的语言描述各过程。对于复杂的过程，该工具不提供了进一步细化的方法，并且 形成了业务流程图和业务状态图。根据这些流程图、状态图与实际业务部门的业务相结合比 较，还是较为吻合的。在此步的实施过程中，运用了动态建模技术，使各部门业务流程的情 况在软件的运行过程反映出来，从而保证了需求分析阶段中运行过程的描述能真实地反映实 际情况，防止在后继的程序编写过程中，可能会经常发生的一类情况：程序员因为没有理解 业务流程而出现“闭门造车”的现象，从软件的功能角度上保证了软件的正确性。 第三步，将业务数据转变为软件数据，这一步工作实际上就是收集各部门所需要的数据。 分析各部门需要的数据部有哪些：以及数据是如何转换的，这可以归入“功能建模刀的范畴。 将这竺相应数据录入到PlayCASE中，选定所属的部门。这时就自动地建立了DFD图（数据

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

第四步，将业务上的数据关系转为成软件中的数据关系，这里采用了面向对象的方法， 把业务部门所需要的数据看作一个实俸，部门间的数据关系就是实俸之间的关系，比如：经 营部门所需要的用户资料、用户话费，实际上就是用户这一实俸与账单这一实体间的关系。 Play CASE提供了构件（不过我觉得是部件更为合适一些），来表示对应的数据，并提供了三 种构件的表示关系即组装关系、分类关系与相连关系。这三类关系基本上反映出了现实世界 中的业务数据之间的关系。例如现实世界中的用户资料与用户话费，在Play CASE中，可将 用户构件与账单构件和相连关系表示，这种方法，实际上是借鉴了OOA面向对象的分析方法中的类、聚集、继承、封装等概念，能较好地反映出现实中的业务；同时，这一步的工作也为总体设计中数据库的概念模式设计奠定了很好的基础。

经历了上述四个步聚以后，利用Play CASE工具自动行成了软件需求规格说明书、初步 的DFD图和业务流程图，为下一步的总体设计打好了基础。

使用Play CASE工具，使需隶分析既能继承传统的结构化分析方法，又能吸收面向对象 设计方法的优点。比如能把业务流程转变成为运行过程，业务组织转变成了软件的结构等部 体现了这一点。而在运行过程中，对复杂过程的细分以及追踪则反映了传统方法中的自上到 下分解的分析思想，这对于解决复杂系统的分析是很有帮助的。

通过使用，我觉得这个工具还是很不错的，因为它实际将以下四个方面的问题结合起来 了：软件、业务、开发人员和用户。对于用户而言，Play CASE用图形化的方式显示出业务流程，使用户了解业务在软件中的运行过程，提供了将来验收软件时的依据，对于开发人员来说，使开发人员能更清楚地了解业务流程，不会再发生“因为不理解用户的需求而出现的闭门造车情况，从而导致开发出来的产品不符合用户需要”的现象。因此，Play CASE所自动提供的需求说明书能够很好地沟通用户与开发人员之间的理解，使他们都能对需求有共同的理解。

使用Play CASE工具后，使我们的需求分析取得了很好的效果，不但能自动地提供许多 结果，如需求说明书等；还使需求的质量有限很大的提高受到领导的赞扬（领导不是学计算 机的，但对公司的业务十分熟悉）；在后继的设计与维护工作中，我们感到工作似乎轾松了很多。

当然，该软件工具也有不足之处，一个突出问题是灵活性不够，一旦公司的部门或者组 织机构发生变化时，整个设计都要重新来过。因此，在改进的过程中，我们在第一步过程预 鼙了好多个虚拟的部门，以备j辑来i井一步的扩充或者蛮动。

论软件需求分析方法和工具在IC行业内部的CAD应用

【摘要】

本文通过一个集成电路设计有关的软件项目，讨论了该项目的主要特点和本人所担任的 工作，着重讨论了在项目需求分析过程中采用的具体方法和工具以及选用的理由。

由于项目的专业领域特殊性，分两类不同的需求讨论了需求分析中遇到的问题及解决方 法，在这个过程中给出了对选用的具俸工具和方法的效果的描述。接着本文讨论了对使用方 法的改进的一些想法以及具体的实现过程。最后提出了我对需求分析的某些看法，强调了与 客户沟通的重要性。

【正文】

近年，我一直从事某企业中有关IT项目的开发，有一个系统是用于计算机辅助电路设计的，包括了从上流设计到下流设计的所有流程，如用于可设计百万门数量级的逻辑门电路。 有关方面把电路中路径的提取、过滤以及表示的某软件开发任务交给我公司，我有幸担任了 该部分的需求分析以及设计。

我所设计部分为一单独可启动的软件，主要是解析文件中的莲线路径，以列表视图和用 直方图等把它们显示出来，还可以执行诸如查找与过滤等功能。

委托方对此提供了很初步的需求说明，把一些基本功能及性能要求描述了一下。我在需 求分析时的工作主要有两点：第一，对该软件的界面等详细需求要白己重新进行分析提取。 第二，对于已提供的功能要求需要深化和细化，以形成真正完整的需求分析文档。 在接到需求分析任务后，我分析了一下所要完成的工作。发现由于是专用领域的软件，对专业领域要求相当高，所以准备把此项目分成两部分：

(1)界面所受专业领域影响几乎没有，但由于全部没有任何要求，反而会感到风险和改 动可能是最大的。

(2)功能方面由于委托方的许多功能都可以调用相应模块来得到，并且已有了相应的书 面的简单需求，相应来说只是完成深化，对界面，我采用了部分RUP的思想迭代与渐进。而对功能需求采取了分层细化，每细化一层就要求委托方确认、修改和补充。

首先把风险较大的部分完成，这是现代软件开发的基本常识。我选择先进行界面的需求 分析，第一步是根据功能描述抽取出逻辑模型，并使逻辑模型与界面元素及功能一一对应， 大俸上决定了界面应有的功能，然后根据该界面功能描述，确定具体的控件，这时，我参考 了委托方已初步完成的主窗口的界面布局及控件的使用规律，然后根据需要完成的功能从Qt（由于要支持Windows和Unix双平台，所以控件库采用Qt）的类库中选择相应的控件，在提取和抽象逻辑模型时，我采用了Rose2000中的用倒图，即以USE-CASE图来描述与外部的关系。之所以采用Rose，我是基于以下的原因：第一，在已开发的部分中，委托方统一要求我们使用Rose进行类和顺序图等的设计和代码生成。第二，Rose提供了标准的图来描述系统与：外部的关系，在全球范围已是一种标准结构。第三，使用上的方便性。我用Rose的USE-CASEI图，理清了我们的软件窗口与委托方主窗口以及外部角色（操作者）之间的相互关系。

在确定了界面元素后，考虑到文档的可理解性不是很强，我采用Visi0 2000把界面的外 观绘制出来，写上了基本的控件作用，随后送给委托方评审，幸运的是除了几个小功能的修 i改，委托方基本批准了我的方案。

下面的工作是为控件的行为及状态变化制定相应的状态迁移图，我选用的工具仍是Rose，我用了状态图和时序图，把重要的控件状态变化及相应顺序进行了描述，随后的几天把相应的DOC文档建好写明，基本上界面设计就完成了。

下面的需求是针对功能需求的。虽然委托方技术部门有初步的需求文档，但由于领域的 专门化不对，我不清楚其中复杂的路径提取关系及较深入的专业术语，一直有一种举步维艰 的感觉。只能采用分层细化的原则，从最初的几条深入一层交成十几条，这样的话，不会一 下子碰到太深的专业问题，可以循序渐进从委托方与文献的解答中不断学习，深化自己对专 业领域的了解，这样在设计中自己始终是层层推进的。不至于一下碰到无法逾越的专业障碍。 在这一阶段的开发中，由于一直是与自己不熟悉的专业领域打交道，所以我觉得一些辅 助设计工具似乎无法发挥应有的功能。在这期间，对我帮助最大的应是公司物E-mail系统， 所有不清楚的问题提出，以及对问题的解答都通过它进行周转。换句话说，在需求分析阶段， 它起到了一个与客户的交流沟通和客户需求的提取作用。所以，我认为在这一阶段，E-mail 系统是对我帮助最大的工具，其次是Excel，我用它建立了问题跟踪图表，对每一个提出的

问题，均需要记录上去，把问题结果（可分为已清楚、仍不太清楚、不清楚、尚未回答）均记录下来，根据这些表，我可以很好地了解自己作中的核心问题，并有了解决它的方向，提高了工作效率。

每进行一层的细化，我部把结果交付委托方审核，由他们进行提出何时能终止细化，大 约在八层细化后，对方认为已达到效果，确认可以结束，至此，分析工作全部完成，项目的 需求分析基本成功了。

在这故需求分析中，我认为取得成功的原因主要是方浍和工具选择得正确。在界面设计 中采用了流行的辅助工具，对需求及逻辑模型的建立提供很大的帮助，可以更方便帮助自己 理清思路。选用了迭代法，把一些错误的影响在功能分析和界面分析的不断迭代过程中加以 改正，在后期，以功能需求为主时，我主要依赖的是沟通工具和表格工具，这也说明辅助工 具不是万能的，需求分析的关键之关键，应是客户的交流与沟通。

通过这汝案例，我认为在软件的需求分析工作中，方法的重要性应远超过工具的使用， 应当首先确定分析中的风险，把风险分类，用不同的方法去解、央各类风险，而工具的选择不仅是要看影响力和名气，而是要真正为我所用，应把握其精髓，即是此工具到底可以对开发有什么帮助，而不是仅限于如何使用，我认为在需求分析中工具的作用不外乎两个：一是实际系统与环境模型等的抽象工具，二是需求表达工具，第一类的代表是Rose，第二类的代表是Word, WPS，vlsl0等，在这次项目中由于地理上的限制还用到了沟通工具，Web浏览与E-mail日B冬不缔．

论Java技术在因特网平台上的应用

【摘要】

根据某类企业的迫切需求，我所在的信息技术公司组织了一个企业资源计划(ERP)项目 I的开发，希望推进我国ERP应用的发展，也希望更深入有效地运用Java技术。该项目的内容涉及到某类行业的企业生产经营的全过程，其基本目标是为了提高企业的劳动生产率，增加企业的利润，优化配置企业的资源，使企业的整俸运营水平能上一个台阶。这是一个基于Java技术的Intranet典型应用项目。

在该项目中，我承担项目负责人的重要职责，比如在项目的准备阶段，我曾组织了对项 目组的成员进行该类企业业务流程方面的培训，在项目需求分析和设计阶段，我着重考虑了 架构好系统的框架和原型，为项目组及其他分析员进行下一步的细化分析奠定了坚实的基础。 同时我还组织好项目总体组，把握住各模块之间的接口分析，保持各个分析员之间实现密切 I的沟通。在系统的开发阶段，做好开发、测试方面的协调和同步工作，保证系统的可靠性， 在系统的实施阶段能够顺利地推进项目，此项目开发后的应用已得到了用户们的一致好评。

【正文】

与国际上ERP项目的广泛应用相比，我国的ERP应用水平尚有相当大的差距。根据某类企业的实际迫切需求．我公司组织了对一类ERP产品的开发，残有幸参与了该项目的分析与设计，开发的成果是一个典型的Java技术应用于Intr anet的实际项目。

在选择具体的技术方案时，我们曾经进行了认真的思考和研究。对于选择普遍采用的微 软模式的平台方案，还是跨平台式的Java方案，我们曾举棋不定，这是因为微软的VB+ASP 已成为大家在校长时间工作后认可而熟悉了的方案。而J ava由于其环境要求高与执行效率低I的老大难问题，成为我们担心害怕的重要因素。但是Java的跨平台特性越来越成为人们的关注点，尤其是许多大中型的企业，他们现有的网络系统都是基于多种平台的，对跨平台的要求和呼声极为强烈，而对软件公司来说，软件的跨平台特性有可能会节约开发成本，降

低维护量，也能获得更多客户的认可。综合考虑了诸多市场行恬与行业发展因素，最终、央定一定要用J ava。所幸的是现在Java用于因特网的开发隔壁已经越来越便利了。

目前J ava在因特网上的开发技术已呈百花齐放之势态，有最初的Java Servlet，有与数 据库联系在一起的SQL-J，还有可与ASP和PHP相媲美的JSP。尤其是JSP技术的迅速发展， 使得J ava的网络应用不再是少敦人的专利，JSP以其执行的高效性和使用的方便性，已成为 近年来大家首选的因特网开发技术，JSP是一种页面开发技术，它以Java为其服务器端语言， 结合Java Sc:ript作为其客户端语言，能方便地实现页面的表示。

选择好了后端的Java和前端的JSP，还有一项重要的任务，那就是前后的联接。由于JSP 主要用于页面表现，需要表现的内容要封起来，这样，为了保证主要商务逻辑的安全性，我 们采用了Java Bean作为桥梁，即客户端JSP通过其中Java Bean的使用，完成主要的商务 逻辑功能。在后台，将Bean构造好，形成一个强大的Bean库，再由前台JSP进行使用。 在进行Java Bean的规划时，我们下、夹心作出很大的投入，因为这些不仅是我们当前项目中所需急用的，而且还应成为公司长期积累使用的一个强大的资源库，能实现一定程度的资源共享和软件复用，为其他项目开发打好基础。因此，此次规划的目标是形成公司Java技术的Java Bean的平台库。

我们根据Java Bean所体现的类的用途，将这些类分成几个层次。最底部的一层就是参 数化类的构造，这一层的类所实现的主要功能包括通用访问机制，对数据库等其他层次访问 接日和公其处理系统等。中间一层是实俸类的构造，这些实俸类包括与数据信息相关的结构 及其处理方法，其中的重点是包含了一些重要的商务逻辑的处理。这一层类与系统各部分相 关，并且其安全性要求很高，直接影响到系统主要功能的体现因为系统的主俸是对一些逻辑 进行处理，这就要求这层实俸类的规划需要十分认真，做到细节准确。最上面的一层可以称 为接口类，这一层类主要用于实现底层的类与前台之间的关系。也只有这层类才能由前台JSP进行Java Bean调用而加以使用，只有这层具有开放性，这一层类除了上述的接口功能外， 还应当有一项重要的实用内容，即包括用于实现前台JSP的页面自动构造程序。

这里所说的页面自动构造程序可以认为是本系统的一个重要特点，目的是为了让用户可 以方便地自定义界而，而不需要由程序员修改程序，这样能够极大地满足了用户的要求。页 面自动构成程序的主要内容包括对界面元素的定制与修改、位置的修改、动作的触发、行为 的控制以及报表设计和计算汇总等功能。页面自动构成程序的设计主要采用上述的接口类JSP相结合的方式，用类实现元素的定制、控制及关联，并将重要信息加以保存，以利于用户的多汝反复修改。该自动构造程序提供了强大功毹，已成为我们的一个独立产品。能应用于各个项目的界面制作，实现了我们原先制定的共享资源的目标。

前台JSP的应用中，做到了尽可能最简化的程度，这样可以提高系统的安全性。当然在 我们的系统中，还存在一些客户端控制比较复杂的情况，为保护这段比较复杂的控制脚本， 我们采取了用Servlet的方法，保护这段脚本，从而保证了一定程度的安全性。

在系统的登录过程中，我们采取了相当严格的登录键检查操作，和户没有供应商提供的 相应的键，就无法通过验证而进入系统。对于试用版的用户则提供了一种有效期限约束。这 些加密或安全措施，通过在Java Bean中封装了严格而有强大功能的加密算法，在客户端申 请验证后才能准予通过。

在使用这套技术方案的过程中，我们曾经遇到过许多的困难。比如：前面曾提到过要求 JSP中代码能够尽量简化，以提高安全性。由JSP中仍有一些容易让人可能猜测到处理方法的语句及处理的过程，为进一步提高安全性，我们通过查阅大量的网上资源，才形成了一套较好的措施，比如制作JSP的标记库，将有可能被猜测的处理进一步加以规划，对应地生成一套行之有效的实用标记库，这样就又增加了一道很有效的防护墙，大幅度地提高了安全保密性，井且使页面结构的分离达到了一定的水准。又如：在对数据的处理上，刚开始时也总

是遇到系统运行会变得越来越慢的情况，最后追查其原因，发现原来是数据的连接过多，我们及时地采用了数据连接池等技术解、央了此类问题。

该系统采用Java平台，提供了深入地使用JavaBe an和JSP的方案，其效果是相当显著 的，在用户真实使用环境中受到了一致好评，运行也较为稳定。由于采用了统一而方便的页 面自动构造程序，用户的界面非常友善，并且可以按用户需求进行定制，满足了用户的适应 性需求。而在我们公司的内部，也开始建立了一套基于此平台的资源库，成为公司的今后开 发使用的宝贵财富。

必须指出的是，在此系统中，还存在着很多的不足，比如实俸类的组装程度尚不尽如人 意，根据多种商务逻辑的一些其同点，可以进一步加以抽象封装，使这部分内容能满足多种 系统对类似逻辑的处理过程。我将会在今后的工作中进一步加强各方面的分析能力，带领团 队不断地超越现在的层次与水准，加强我们的队伍建设，希望有更多优秀的软件产品上写着 Made In China.

Java技术在因特网平台上的应用

【正文】

数据通讯是不前十分活跃与热门的计算机与信息技术的应用领域。某大型通信公司开发 了其业务的主要支撑平台，在这里，我们简称之为“通信信息服务平台”，用于在全国与全球

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

作为信息技术公司中的一名技术骨干，我有幸参加了该系统的分析与设计工作，承担了 相当多的J ava应用开发任务。此系统中的软件部分大多由Java来实现，在全系统中我们是 这样来用J ava构架系统的：

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

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

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

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

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

(1)使Java Script尽量简单，因为Java Script在我们系统中是放在服务器端执行的， 该语言是通过一个解释器解释执行的，相对速度很慢，我们要用了两台HP前置机来运行 JavaScript．但是其运行速度还是不理想，所以我们在设计中把Java Script仅用来显示从 中间件层所得到的数据，生成动态页面。在最初的设计中表示层(Java Script)曾承担了一 些业务逻辑处理操作，导致效率不理想，因此，我们不得不尽量地减少Java Script的程序 量。

(2)用Java实现CORBA时，应尽量考虑共享和复用，在本系统中，最初的设计是让Java 在实现Component时，只是执行一些数据库表的操作，导致表示层的负载较大。后来，我们重新设计时，总结归纳了所有的Use Case，找出了其中可供共享和复用的接口，把相同的业务逻辑操作封装到一个接口中去。因为Java的执效率比Java Script要高，因此提高了系统 效率。

(3)在别的项目中，我们曾大量地使用过Java中的JSP技术和Servlet技术，一般人 可能不能区分这两种Java技术的区别。为了得到系统的一些执行速率的数据，我们采用了一

个著名的压力测试软件-Load Runner来测试这两种技术的差别。测试表明：用JSP和

Servler完成同样的一个操作，并且保证是在相同的测试环境中（相同服务器、压力测试工作站与数据库环境】，得到测试数据却有着很大差别，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虚 拟机中使用了一个垃圾收集器，专门用来回收内荇。但是该垃圾收集器在给编程人员带来方 便的同时，也隐埋下了隐患。在程序设计中，并不能强制执行垃圾收集器，所以，开发人员 不能确定某对象是否已释放，常常让编程人员养成依赖自动收集的坏习惯，因此我们要求： 在Try, Catch之后必须明确要求回收内存（当然，也只能是通知垃圾收集器来回收垃圾），这 样可以有效地提高系统稳定性。

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

当然，在使用J ava作为解决方案时，也会遇到很多让我们头疼的问题，这些问题导致同时执行的并发性比较差，系统速度慢等等。归纳起来看，我们曾遇到过的主要具体的问题有：

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

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

(3)用JSP编程时容易导致系统信息的扩散。比如：如果有黑客攻击一台运行JSP程序 的服务器，他可以故意地输入一些非法字符或异常信息给JSP程序，于是程序执行将出现异 常。这时，就会在页面上打印出相应的错误信息。很不幸的是，这些信息极有可能暴露出这 台服务器的JDK的版本号与路径信息等内容。这往往容易让黑客们有机可秉，有可能去抓住 系统的漏}同。

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

(1)既然用Java实现Component比较慢，我们就尽量减少Component所执行的业务逻 辑量。争取把能够放在存储过程中实现操作，尽可能在存储过程中加以实现。众所周知，数 据库的存储过程操作，比起在Java程序中执行数据库操作要快得多。

(2)既然用Java建立数据库连接比较慢，我们就可以把数据库连接封装成连接池 (Connect Po01)，从而能非常有效地提高系统效率。我们也曾经用"Load Runner"作过压 力测试，使用连接池比不使用连接池的速度要快上3~5倍。

(3)为了对付JSP程序与Servlet程序会打印出异常信息的问题。我们曾查阅了很多JSP 或Servlet的资科，最终是毫无头绪。但是我们可以换另一种思路，即是不从程序下手，而 从Web Server着手，我们可以把Apache配置成为使这类异常信息不再打印出来，而是使之 仅出现一个通用的异常说明的页面，这样，就能十分有效地解、央这个问题。

在我们使用Java作为编程语言的这么多项目中，绝大多数是比较成功的。Java语言作为一种快捷、稳定的汁算机语言，开发基于因特网应用的项目大多是相当稳定和比较适用的。

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

(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在数据传输和异构网络通信方面有着很大的优势。 就我个人而言，我将会在相当长一段时期内致力于J ava在无线互联中的应用，为我国的移动通信事业开发出更多的优秀实用的项目。

论Java ：在因特网平台上的应用

【摘要】

因特网上应用的日益普及与深化，为Java技术的运用提供了广阔的活动舞台，也大大推进了Browser/Server模式的企业内联网应用与网络计算。

作为某信息公司中的技术骨干，我有幸承担了某银行信贷管理与查询系统等的开发任务， 独立地完成了其中的系统设计、类设计、部分开发及测试工作。

整个系统完全按照J2EE的标准来设计。前台界面应用了JSP技术，控制部分采用了 Servier来开发，业务逻辑应用了EJB技术来封装，应用服务器用了支持J2EE标准的BEA公 司的Weblogic，后台的数据库选用的是Inf ormix7.3，目的是为了与银行中其他业务系统数 据库保持一致。在硬件平台上，我们选用的是HP公司的某台中型服务器机器，操作系统是 ：HP-UXa

该系统界面运用的是IE，它不仅兼容性较好，而且已为广大用户所熟悉。系统运行后， 各个支行部普遍反映界面友善，功能强大，开发的效果令人满意。

【正文】

在银行应用中私人的储蓄、企业的会计、国际业务、信贷、财务管理都十分重要的，它 们构成银行的基础业务系统。我从事开发的信贷业务更是银行利润来源的重要部分，与储蓄， 对公等以交易事努为主的业务模式所不同的是，尽管信贷也是交易，但需要更多其他辅助信 ．息的支持。如客户基本资料，在本行内业务发生状况、信用等级、是否有逾期贷款未能归还等。只个支行的有关业务人员及分行管理人员都希望能方便及时地了解这些信息，传统的基于终端的用户界面难以传递这么多信息给用户，所以我们决定采用基于浏览器IE的用户界面，一方面IE使用方便，不需要专门培训，另外它是与Windows操作系统捆绑在一起的，也可节省前台费用，在开发技术上有ASP、JSP可供选择。

由于考虑到J ava技术在Internet上的迅速发展，J2EE更是提出了全新的用语言来统一 平台的思路，于是我们、央定采纳J2EE标准，并选用了JSP。在设计上，基本上是采用了一个交易画面对应于一个JSP程序，充分发挥JSP动态处理页面的长处。

为了使设计有更好地可扩性、灵活性与逻辑性，能为以后扩展奠定坚实的基础，我采用 了( Modelu, View, Controller)的MVC设计模式，vlew全部由JSP实现，面Controller则是 设计了一个berv Ler程序，它负责处理前台浏览器传送来的所有请求，并按事先定义好的路 径．腥序关系，分发给相应的JSP裎序去处理，由于Servlet本来就是为Java服务器端编程 来设计的，因此由它来负责服务器端的处理是相当合适的。

在开始设计时，我运用了构件技术，由EJB承担起设计模式的Modelu角色，具体的贷款开户，放款，结算逾期贷款，归还贷款等交易都对应一个具体的EJB，为了将这些处理逻辑与相应的数据操作分离开，能更加便于维护，我将处理业务的EJB设计成Seesion Bean,而为每个Session Bean再配备一个相对应的Entity Bean,用于访问后台的数据库，贷款管理中有很重要的一点是进行查询，我按照需求分析的结果，为每类查询都设计了相对应的Bean，其目标是尽可能地提高查询的速度。

在对数据库的存取中，我本来的设计应用Inf ormix JDBC所带的Driver Manaegr，这样， 在存取数据库中的Bean中就要把Driver及ServeT写入，后来考虑到应尽量提高应用的平台 独立性，在参阅了J2EE中JDBC部分的说明后，改用了Data Resource的处理方法，这样， 即使以后数据库换成Oracle或其他产品，程序也不用修改，只需要在配置时进行变动即可。 在这次信贷管理系统的开发过程中，Java酌平台无关性优势，在开发人员从事开发的活 动中体现得淋漓尽致。由于经费相对紧缺，我们的开发环境是各个项目组共用一台HP机器， 虽然每个开始小组都搭建了自己的环境，但项目一多，特别是遇上结息与批量测试等场合， 机器就显得不堪重负，使开发与测试工作的效率大为下降。我们小组由于采用的是Java技术，大家可以在自己的NT机器上搭建相同的环境。这样一来，大家平时的开发工作，包括JSP，Servlet，EJB的程序，都可以在本地完成，只是到测试或展现阶段才需放到HP开发机器上进行。

以前我们开发的Web应用，往往只是应用了部分的Web技术，如采用Apache WebServer, ASP开发语言等。整个体系的集成与组合往往不够理想，这次由于我们采用的一整套符合J2EE标准的组件，整个系统的协同性与一致性非常之好。再加上有一个支持J2EE的应用服务器一-BEA Weblogic，以往我们做得不理想的复杂配置，模块间的连结，如今部用不到再操心了，只需在图形化的配置工具中，输入系统所需要配置，如路径与实际应用程序的关系，组件中的EJB引用，Dat aResource的属性等：全部配置完成后，Weblogic会替莪们完成项目的部署，并将这一切有关的程序都封装起来。

原来，我们开发小组的文档编制任务显得非常之繁重，因为整个系统既有交易部分，又 有管理查询部分，交易、数据与源程序都很多，为了解、央这个问题，我们直接应用了Java源程序中的Javadoc导出文档，这样不仅文档美观，而且能够保持与源程序的一致性，实乃一石二乌之举。

整个项目完成后，用户使用下来都觉得界面友好，操作简便。但是我心里知道，这个系 统还有很多可以加以改进的地方。

首先，基于Java系统的开发需要资金较多的投入，由于该系统受到经费的限制，只申请到一台生产用机，这样，Web Server, Application Server, DB Sever只能被挤放在一起。 虽然Weblogic能实现部分负载平衡，但在将来的业务发展时，这样的分布肯定不是最理想的。好在我们在设计时已经考虑过尽量有良好的扩展性，在以后条件许可时，只需进行在不同机器之间的进一步部署即可，应用程序大俸上无需改动。

其故，在设计上，可以采用mKL的产品，如Rational Rose，另一方面，Rational Rose 具有自动代码生成功能，也可以大大节省开发的成本。

最后，目前的信贷管理系统相耐用户数目量不多，当推广类似系统需要拥有大批用户时， 基于J ava的系统的响应时间与系统分布都会有效为突出的矛盾出现。

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

匝当努力的方向。

论改进Web服务器性能的有关技术

【摘要】

基于Web技术的数据库应用是当前应用的一个热点，在用户数目与通信负荷很大的场合，提高Web服务器性能是一个迫切的澡题。本文从笔者参与某个银行系统项目开发的经历出发，阐述了提高Web服务器的性能应渗入到项目论证、选型、开发、运行和管理的各个环节，只有各个环节都能充分考虑到性能与质量的需要，系统的性能才是真正可保证的和可扩充的。

文章从系统的实际运行与相应的经验出发，阐述了性能改进方面的一些具体措施。 比如：在本文中讨论了Web服务器平台的选型考虑；Web服务器的配置管理；应用系统布身的优化与预先设计系统时可扩性的性能保障等具体内容。

通过技术上的分析与改进，综合性地运用多类措施与手段，在实际系统中，Web服务器运行的性能得到了一定程序的保证。

【正文】

我所在的单位是把目标定位于金融领域开发IT应用的一家信息技术公司。随着金融电子化建设的发展和商业银行之间市场竞争的加剧，各主要商业银行不断通过信息技术提供新的金融产品，并且希望整合市场渠道。比如主要的商业银行不断推出形形色色的网上银行服务。在这种背景下，本人参与了开发新一代风上银行产品，涉及提供网上个人理财脲务、网上外汇买卖服务、网上企业服务等具有市场竞争力的产品。作为项目开发的组织者之一和主要的技术骨干，在整个项目开发过程中始终要处于第一线，从而在改进Web服务器性能、提高整个网上平台系统性能方面收获良多，在本文中简要讨论如下，希望与读者们其享经验。在Wet归艮务器配置与优化方面，我有如下几方面主要的体会：

第一方面是Web服务器选型考虑。

在Web服务器选型及网上平台搭建这初，我们就已充公考虑整个网上平台的性能及可扩展性问题，这一考虑为该系统的稳定性及扩展性能力方面打下了坚实的基础。 某银行原有的一些网上产品由于开发较早，故而采用的是老式的-rrIP Server+CGI程 序调用的方式。这时，每一客户请求需要对应于后端系统的系统进程来运行CGI程序来处理， 系统的开销相当大，系统的扩展能力也很差，性能已不能满足业务处理的需要，故而在为此 银行系统具体选型的时候，我们一开始就否决了这种方案。

通过市场上同类产品的比较选择，我们选择了国际商业机器有限公司IBM的Web Sphere 产品系列作为该行网上银行系统的建立平台。作出这样选择是因为Web Sphere基于使m耶 Server和应用服务器相分离的整体架杓，同时支持JSP、Servlet和企业级Java Bean等轻量 级线程规范，所有的请求对应于应用服务器上的处理线程，系统的开销低，效率非常高，同 时Web Sphere整个体系结构相当的灵活，为适应扩展需要可以作不同的横向和纵向扩展，从而可以满足各银行未来的扩展需要。

正是因为在一开始选型的时候我们就已考虑到未来的扩展需要，整个系统在接下来的几 次性能改进方面，我们大俸上都能相对顺利地达到了预期目标。

第二方面是Web服务器的性能配置。

在一开始系统上线的时候，由于系统的负荷不是很大，为了节省系统总拥有成本TCO投资，我们在一台较低配置的IBM RS6000上投产了该系统。整个系统的I-rrrP服务器、应用服务器、通信服务器等均位于该台机器上，由于初始投产时用户不多，所以系统的性能基本上能令人接受。

但随着业务的发展和用户访问量的增大，我们发现该服务器的响应变慢，系统的CPU

利用率和内外存交换显著增大。经过跟踪，我们发现关键原因之一是系统的内存不足的缘故。 由于网上服务器把大量用户的会话信息保存在内存中供给应用系统使用，当内存不足时，大 量Session信息被迫交换至硬盘，大量CPU时间消耗在等候内外存的爽换上，系统效率迅速 下降。

鉴于这种情况，我们把该服务器的内存由2GB扩充为4GB，同时相应调整用户会话信息的保存时间，这样整个系统的效率又回到较为理想的状况。

由于新应用的不断投产及数据库操作的日益增加，我们后来逐渐监控到系统的数据库处 于繁忙状态，系统的错误日志也记录下了供应用服务器使用的数据库连接处出现资源不足的 情况。在这种背景下，我们认为整个系统由于硬件配置所限，应该进行横向扩展，因此我们 把数据库服务器分离出来，配置到另一较高性能的服务器上，相应定义的数据库资源也大幅 增加，这样整个系统的性能又处于较为理想的状况。

第三方面是对应用系统进行相应的优化以提高性能。

Web服务器配置及相应的硬件扩展不失为解、央系统性能问题的一条捷径，但应用系统的优

化也是应该重点加以考虑的，毕竟它能够在投入较少的情况下提高系统的运用效率。

在开发的初期，我们就已经十分注意系统的利用效率，比如提醒程序员尽量不要利用用 户会话信息( Session)来传递大的对象，对于内存要注意回收等。同时，通过内部的交流会 推广与介绍一些小的，有用的编程技巧来提高开发人员的水平，通过代码的抽查，希望能在 早期就发现问题等。

在系统运行期间，残们通过监控发现，应用服务器所基于的J ava虚拟机，其内存堆的空闲空间有不断下降的趋势，每隔若干天导致空间消耗殆尽，无法分配新对象空间，从而导致系统重启。在排除了系统本身问题的原因外，我们确定为应用系统的开发有问题。通过从网上下载IBM公司检测J ava虚拟机的相关工具对JVht进行监控后终于发现系统内部存在着不能回收内存的对象，再通过查找相应的程序发现在该程序中有“环状”的对象引用，从而导致对象使用后不能被垃圾收集器所回收。这个问题的解决过程虽然十分艰苦，但由于该问题不能通过升级硬件或增加资源配置而得到根本解、央，会给系统带来很大的隐患。所以，整个过程的分析与解、央是完全值得的，更何况通过查找故障原因的过程，给整个项目组上了生动的

一堂软件质量保证澡，对项目组的质量意识起了很大的促进作用。

所以说改进Web服务器的性能并不单纯是系统管理方面的工作，它渗透到开发以及系统运行第一系列环节中。

第四方面预先考虑未来的扩展与性能需要。

随着系统的发展及成熟，考虑到用户访问量的不断上升，为了预瞽系统的发展空间，我 们最近又对整个系统作了一个系统性的升级。通过引入多台r-rnP服务器及应用服务器并行工作提高鏊个系统吞吐量及单点故障克服能力。由于在一开始选型的时候就已经充分考虑到动态负载均衡及横向扩展方面的需要，这一项的升级无需对整个系统的体系结构作根本的变革，对应用程序来说，更是没有造成任何影响。

整个项目历时近两年，从这两年的系统情况来看，整个系统是成功的。根据我亲身的经 历，系统性能并不单纯是系统运行与管理阶段的问题，而是渗透在项目论证、开发以及运行 的各个阶段。只有各个阶段都能充分考虑性能方面的需要，在实际运行时，整个系统的性能 才可能真正有保障。在技术方面来看，可以综合利用选型评估、硬件扩展、应用优化和系统 配置优化等一系列的手段；比如在硬件扩展方面，又可以分为主要部件扩容，纵向升级、横 向升级等方面。在我们的项目实践中，曾综合地利用了上述的各种手段。比如某银行的整个 系统日访问量不足1万至现在的每日超过10万故以上的点击的发展情况来看，整个系统的

性古}保障碍撂高方案导比较成功的。

改进Web服务器性能的有关技术

【摘要】

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

本人有幸作为项目负责人之一参与了某大型图书馆数字化信息系统的设计和基于Web应用软件的开发工作。由于在数字化图书馆信息系统中流通着的大多是数字化的索引、文摘、 全文、图像或音频视频等多媒体信息，对Web服务器性能有着较高的要求。

结合实际工程经验，本文将从硬件实现手段（缓存服务器、均衡负载设备、Web双机镜像、CPU和网卡的提升、网络带宽扩充）和软件实现手段（三层C/S软件结构设计、应用程序部署）等两个大方面论述如何提高Web服务大路的性能，以便使用户能够更快捷、高效、安全地使用应用系统。

【正文】

随着Intranet信息技术的发展，图书馆为了更好地发挥其图书流通、资料检索和学术交 流的职能，图书馆的数字信息化工程也势在必行。某图书馆为了尽快地步入世界先进图书馆 的行列，已经启动了一部分的数字图书馆工程。

该数字图书馆工程主要包括对外信息Web发布系统，交互式检索网，后台馆藏信息管理系统、多媒体资料采集制作以及外VOD点播系统等。本人有幸作为项目负责人之一，参写了整个数字化信息系统的总体设计，并参与了基于Web的一些应用（如对外信息发布系统、图像．／全文混合系统、VOD点播系统的）开发。

某图书馆数字化信息系统从网络环境上讲，主要划分为多个网段：（一）Intranet接入部 分，采用2M的DDN专线；（二）公共网段（非军事区），主要包括前台发布数据库服务器、Web服务器、E-mail/FTP/DNS服务器、检索服务器及SAN网络区域存储设备；（三）是内部局域网，包括内网Web服务器、后台馆藏数据库服务器、OA服务器等。（四）是VOD点播专用网，包括音频视频点播服务器等。由于制定了严格的网络级和应用级访问权限，通过具有三层交换能力的高性能交换机和安全授权认证系统等，有效地控制了访问权限，确保了数据的安全性和完整性。考虑到经费和人员素质及今后的维护管理运营等方面，操作系统采用WindowsNT平台，服务器选用DELL高端的系列，数据库采用IBM的DB2。主干网为千兆快速交换式以太网，局域网百兆到桌面，VOD点播网十兆到桌面。

在该网络环境下应用主要分为三大部分：（一）对外Web发布系统、对外图书辅助检索系统；（二）后台馆藏信息管理系统和图像．／全文混台检索系统；（三）VOD点播系统。由于绝大部分应用采用Browser/Server方式结构，最终用户在本地只需安装IE或者Netscape Web浏览器，在后台数据库服务器的支持下通过网页方式请求和访问各类应用服务。另外，由于在图书馆信息系统中流通的多为索引、摘要、全文或音频视频等多媒体信息，对Web服务器性能与网络带宽等有更高的要求。

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

(1)缓存服务器和均衡负载设备使用可以缓解访问瓶颈，提高网络带宽、实现均衡负载。 缓存服务器也称为cache服务器，可以存储cache静态的内容如网页、多媒体点播资源 和会议实况（已压缩的、有一定格式要求的）等。此外，目前美国cashflow缓存服务器，已

经可以存储cache数据库、ASP等动态内容。cache服务器通常放到防火墙之外，外网Web服务器之前，因此Inrternet用户点击网页不再直接访问网站Web服务器，而是访问cache服务器。

由于cache服务器具有多个CPU和高速大容量I/10通道，独立的OS，因此能大大缓解 Internet访问瓶颈，而且也具有一定的抗黑客攻击酌能力。

目前某图书馆采用这种方式，把大数据量的静态图片、点播资源、虚拟三维应用等部事 先置放在cache服务器中，即使现今只有2M internet的接入带宽，以上应用的播放速度和 效果仍能让用户满意。

另外一种方式采用均衡负载设备或Web双机镜像。这种方式通过负载均衡的方法达到Web访问性能最优。Web双机镜像是较早以前流行的方式，虽能使系统可靠性提升，但由于双机总是在互相询问对方状态，将会影响一定的访问性能。均衡负载设备是独立于Web服务器的硬件，它和Web服务器及网站中其他服务器接在同一交换机上，通过负载调度程序为各个服务器分配工作量，从而，能达到充分利用资源，提高访问性能的目的。只是由于某图书馆目前对外发布资源相对仍较少，只有用了三台Web服务器，因此目前的均衡负载设备作用还不显著。

(2)从Web服务器的配置来看，Web服务器自身CPU个数及速度、网卡数量、Web服务 器与防火墙的位置关系等，都会影响到Web服务器的性能。

从Web服务器硬件本身来讲，CPU个数的增加、网卡个数的增加、1/0信道的扩展无疑可以直接地提高Web服务器性能。此外，由于千兆口的防火墙目前较少且费用较高，如果把Web脲务器放置防火墙之后，一定会大大影响Internet访问性能。某图书馆采用IDS（入侵侦测）+Web服务器（服务器防火墙，较低端，不会影响流量）邯翌用服务器《乏据库服务器（防火墙，高端），分层次的安全模式，既保证了系统的安全模式，既保证了系统的安全性，又提升了网络访问性能。

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

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

将业务逻辑、通用访问接口与数据等相互分离、分别置放于Web服务器、应用服务、数据库服务器上，通过过程序功能和逻辑的合理部署，也能大大改进Web服务器性能。 一般的原则是，Web服务器只需接受Internt http访问请求，使Web只有最少的任务， 把实际处理交给各个应用服务器处理，然后返回结果给Browser。某图书馆采用这种方式专门开发了搜索引擎应用服务器和混合检索应用服务器等，达到了良好的应用效果。

事实上，Web服务器的性能提升还存在很多手段和方法，比如CPU与存储之间关系，Web 交换机等等，有待干袋们浒一步的实践、分析和讨论。

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

【摘要】

近年来，在应用需求的强大驱动下，我国通信业有了长足的进步。现有通信行业中的许 多企业单位，如电信公司或移动集团，其信息系统的主要特征之一是对线路的实时监控要求 很高，数据量庞大，如何将实时控制与信息系统集成在一起便成为系统实施的一个关键部分。 在参与了某个通信公司的一套网管系统以及决策支持系统的设计后，我们分析了两者的 集成与应用工作，深切地感受到有一个良好的设计策略以及重视所选用的工具是一个关键。 这个项目主要是对下属各分站的子网以及有关链路的莲通情况进行实时监控、实现报警、路 由控制和授权等功能，其关键在于提供一个实时显示情况地地图界面，并将数据汇总和组织， 建立起数据仓库以及进一步实施数据挖掘分析，从而能支持企业的、央策分析。税作为设计人

员之一，着重在本文中讨论控制系统与信息系统集成时的策略。

【正文】

众所周知，通信行业需要有一整套监控通信网络手段，其工作特点是涉及到的各分站与 基站的在地理位置上的分布性，更加需要有在更高一级提供检测不同分站链接情况的手段。 一般来讲，由于数据都是海量的，所以如何将整个网络系统所得的数据及时处理，以便和、央策部门的分析相结台，也成为迫切需要解、央的重要课题。简言之，分布性、实时性以及数据海量性是解决整个系统设计和集成的核心问题。

首先，让我来讨论一下“网管监控系统”。由于我参与设计与开发的这个系统并不是位 于基层的分站，翼定位在将不属各分站的主机通信数据（包括数据流量、链路负荷、通往其 他结点即主机的连通情况等）加以收集，所以对于具体通信事务的底层操作要求并不很高。 考虑到上述原因，我们采用了一个理理信息系统开发平台Mapinfo并采用Delphi编程， 后台用SQL Serven-数据库（这里由于考虑到决策所需要用到的7Kicrosoft公司的OLAP

Service）。在分析和计划之前，残们先对Iffr801标准做了详细的探讨，这只是一个有关子网和链路定义以及分层等描述的标准，在听取了许多分站人员的建议后，将MAPINFO公司提供的一个相关的MAP X的Active X控件嵌入到Delphi程序中，利用MAPX中提供的丰富的类以及操作，比如Object、Layer等实现网管界面，并且加入了子网和链路的概念，对属下的分站可以随意地组合成为不同子网，而且实现了放大与缩小的功能，大致可以将整个地区的分站集中在一张地图中，毹显示在屏幕上，这时，只是显示出各个分站在概要，小到可以显示出某台主机的机柜、机框直到插件板（因为这些都要实时监控）。我们采用了分层的方法来实现以上缩放。对于一些静态的数据，如分站，主机的位置等则先用Mapinfo公司提供的一套编制地理信息的工具（MAP X是其提供给编程工具的一个Active X控件）做成静态的层次图放置于数据库中。

我们新做成的这套系统通过与各分站的专用线路加以连接，能实时地得到数据，显示于 地图上，反映出各站、各子网、各链路的实时状态，并能将控制命令传回分站（如强制链路 中断、路由转换等）。

现在，让我们来讨论其中最为关键的问题，即是要将实时控制系统与企业信息系统加以 集成，我们的设想和体系结构大俸上可以用一条简图表示（此处暂略）。

在这个俸系结构中，由各分站保驾着详细的数据，网管系统则在一定时间间隔内将汇总 到的数据作少量统计，抽取其中需要保存的内容放入数据库，如每每分钟流量，某分站与其 他分站每分钟通信流量，在该分站中某个链路的负荷（这些链路有可能是动态分配的，也可 能是固定分站之间的通信链路），尽管如此，数据仍然是海量的，因此，如果要把这些数据都直接送到各个决策部门，比如送给市场都门是不现实的。所以，我们在数据库的基础上建立了数据仓库，确定了客户、时间、通信量、计费和故障等几个数据仓库的主题，每隔一定时间对数据库中的原始数据进行清理与抽取等预处理工作，建立好数据仓库。这里的预处理包括了许多方面的内容，比如有建立计算时间，但是无计费的（计费值为零）的数据，应视为建立失败的无数数据，需要予以剔除，某些企业租用的是专用线路按月计费，中间的通信因此无计费的一些有关记录也应剔除等。

在预处理之后，再利用OLAP SAervice的分析将数据融合与汇总，按照决策部门的需要 提供相应数据（比如：市场部门需要每一分站的收益，客户分布情况以及客哀悼费用等）。这些都可以由OLAP Servlce对数据作预先处理，此时处理完的数据在逻辑上是以立方傩(CUBE)形式存在的，其占用的存储空间便能显著地降低，如19xx年8月有2000万条通讯记录，即使形成作为备份的文本部需要4G空间，经过OLAP Servlce处理后仅需200M左右空间，因此，经处理后的数据主要存放于另外的相关部门的机器中，而不能与主服务器放在一起。

最后，再来讨论由决策人员所使用的系统，由于这些部门并不分散，我们就没有采用OLAPServlce酌Web发布方案，采用Delphi编制了访问OLAP Servlce的客户端软件，用了OLAPService提供的、Cube Browser控件，用相似于网页的界面提供了数据立方俸的各种操作，如上钻（观察角度从月转到季度甚至年），切片，旋转等操作，为了便于输出打印数据，还内嵌了Microsoft的Excel数据透视表，可以将在Cube Browsen-上所看到的数据转化为Excel 的表格形式，或者转换成饼形图、柱形图和曲线图等，比如可以观察每天24小时通信流量的分布曲线图，可以发现在夜间1 2点以后明显能信流量减少，而、央策部门便可制定某些优惠或减价措施吸引更多客户在12点之后使用网络。

另外，在采用OLAP Servlce中的数据挖掘功能时，其中提供的两类算法分别是基于决策 树的分类和基于、央策树的聚类，市场部门的聚类算法将客户根据费用情况加以聚集，以期发现处于同一消费水平的客户的共同特征，便于制定政策、吸引客户。这方面的努力残们将会进一步持续进行，以保证有足够的海量数据而发现其中的规律。

整个系统运行后，其数据采集，数据处理等一系列工作部由程序定期地自动进行，该系 统应用已有一段时间．受到了不少好评。当然，也发现了其中有不少问题，比如：主服务器 数据库的容量问题，主站与分站的通信效率问题，还有在网管系统中，网络故障的确定还不 够细致，需要由分站再具体化加以确定，决策系统与网管系统之间还缺少直接通信手段等， 这些都有待于进一步的解、央与改进。

实时控制系统与企业信息系统集成化是推动从事生产制造、测量与监控等业务的企事业 单位真正迈向信息化，提高工作效率的一个重要动力。如果是大型企业，更需要有一整套的 系统，支持Web发布，智能查询，自动识别如用于故障预测和数据挖掘等技术，从而能够将

底层的实时监控与高层的决策更好地集成在一起。展望其前景，无疑是十分美好的，但是我 们认为相应的工作量很大，在技术上仍然需要有所提高和有所突破。

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

【摘要】

本文以一个信息化改造项目的为例讨论了实时系统与信息系统的集成。我曾参加了一个 中等规模的现代化生产企业的数字化改造项目，该企业拥有4座自动化连续式工作的富炉， 以及8座自动化间隙式工作的富炉以及多台半自动的中大型辅助机器。该企业希望能将这些 设备实现数字化，并且重点要建立起一个中央监控室，能实现对设备的运行状态参数的监督 和记录两大任务，前者用于防止意外事故，后者可用于向该企业决策人员和技术开发部门提 供信息。

通过我们的开发组与该企业相关人员一起努力，分四个步骤共同完成了这一工作。 第一步是实现设备状态参数的数字化输出；第二步是建立中央监控室的监督和记录功能； 第三步瞧全监控室的控制功能及相应信号的输出；第四步则是实现生产设备自动化控制的数 字信号接入功能。

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

(1)作为公司开发组和企业间联络桥梁；

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

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

【正文】

现代化企业发展生产与提高效率的根本途径之一是加速信息化的进程。在所从事的专业 生产领域中，残参与开炭项目的这家企业可以认为已经具有相当程度的现代化的基础了，比 如它已拥有4条自动化连续式工作的窖炉、8座自动化间隙式工作的容炉和多台半自动的中大型辅助机器。但是这些设备的自动化控制在改造前还主要依靠模拟量控制，也不具备信息与数据的记录、汇总与分析功能。该企业一方面出于对今后发展的需要，希望记录下这些设备在工作过程中连续的状态参数的变化情况，有运行的日志与历史记录，以提供给其技术开发部门，作为产品质量改进研究中的参考；进一步还可提供给企业管理部门决策分析时的参考。另一方面，企业希望能够对设备生产状态有全面的监督和一定的紧急控制与应度的能力，能对生产设备的操作意外和设定不当，或者发生突然的未预料到的事件，防止造成事故与损失。

我们根据该企业的要求，结合项目的资金、时间、人员等现实状况，再三考虑了该企业 的经营情况、产品的市场和前景、项目开发所面临的风险等诸多因素，经过仔细分析，得出 了如下的4条意见：

(1)由于资金的限制，切实地在相应各个环节上节约成本是相当重要的，因此要尽可能 地在原有设施与条件的基础上进行改造，而不是进行根本性的替换；

(2)此企业需要的是“实时控制系统和企业信息系统的初步集成”，丽不是一个功能相 当丰富和完善的系统，该企业现阶段既不具备开发这样一个系统的能力和条件，也不具备管 理维护和应和高级集成系统的相关人员，所以，项目的目标应当切合于目前条件下企业的总 体要求。这样既有利于控制成本，也有利于减少项目风险；

(3)由于该企业的生产情况和资金、人员的限制，项目必须分阶段地进行。大体上可划 分为如下四个阶段：①实现设备状态参数的数字化输出；②建立中央监控室的监督和记录功 能；③健全中央监控的控制功能和相应信号的输出；④实现生产设备自动化控制的数字信号 接入功能。

(4)参与本项目涉及到的双方的大多数人员部不精通对方的专业领域，因此必须在加强 互相沟通的同时，确定明确的分工关系。

上述四条意见在经过双方的磋商与研究后，获得了双方全体项目参与人员的一致认同， 成为这个项目开发过程中双方必须理解与遵循的准则。

在第一阶段，莪们开展了对半自动的中大型辅助机器的自动化改造。事实上，该企业早 在这类打算，并且已做了相应的技术储备，因而这一部分的工作由该企业自身的技术人员全 权负责并加以实施。项目中所涉及到的所有自动化生产设备部已具有依据状态参数模拟信量 进行控制的能力，对于所采集到的状态参数模拟量，企业苔计划采用一类以模拟信号远程地 传至中央监控室，再进行模数转换的方案。此方案对企业来说实现比较简单，但存在着成本 较高、远传过程易受到干扰等不利因素。随着模数转换设备成本的显著下降和可靠性提高， 经我们建议和双方讨论，企业有决心在生产设备的控制设备上就地实现现场模数转换，再远 传数字信号至监控室，这一工作同样地由熟悉这项技术的企业技术人员实行。

第二阶段的工作主要由我方开发组成员负责。我们将人员大俸上分为3组，第一组主要 是根据企业长期累积资料以及公开发表的相关技术，建立起一个合理有效地模型，其中包括 诸如数据采样记录的间隔时间，不同生产阶段的数据处理时所采用的数学模型等数据处理的 相关内容；第二组负责监控记录软件的输入输出接口，用户图形界面的选定和设计等软件外 围功能的实现；第三组则集中力量编写一简单实用、针对性强和小巧的相关数据记录的专用 数据库。这一阶段是控制质量和成本的关键性阶段。出于对成本的考虑，以及根据数据的流 量不很大，对数据的实时性处理要求不是很高（通常情况下，设备的实时控制仍由原来的自 动化系统所承担）的实际情况，中央监控室采用了一套有双机备份的服务器作为数据处理用 的服务器，另一套同样有双机各份的服务器作为数据库服务器，并且没有使用价格昂贵的商

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

第三阶段可以看成是第二阶段的自然延伸，在第二阶段成功的基础上，利用第二阶段模 块处理后所获得的数据，依据设备的多种临界指标，进行相应的判断，允许在紧急情况下， 发出相应的警报，并同时依据设备本身的相应紧急情况处理办法，发出控制信号加以处理实 现。这一阶段的关键有两方面内容：一个问题是要求数据转换设备拥有相对较高的可靠性与 可用性，另一个问题是要注意做好与自动化设备原有控制系统的自我保护功能的配合协调工 作。

第四阶段则仍然由该企业的技术人员为主实施，在实现过程中主要是解决好第三阶段所 遇到的上述两个关键问题。对于第一个问题，使用了更好地设备和部件来实现数模转换和动 态控制；对于第二个问题，则在控制设备中设立了优先级判断，使自我保护装置的启动优先 级离开中央监控室（由于自我保护启动速度更快，但是功能较弱）而加以解决。

从总的项目实施进行上来看，一、四两个阶段相连贯，二、三两个阶段相连贯，而它们 之间则可并行地进行，从而满足了时间进度上的要求。

今后，本项目所采用的这类技术可能要走向全自动化。项目中涉及到酌数据量将会更大 得多，实时性要求也会更高。我们应注意使现有成熟的商业系统与产品如何应用到其中去， 俺夕音旨展·障恤清早仓、I I，的尊求，节约瞄杰，并日准／卜耳寿的冈B厶．

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

【摘要】

本文通过“工控组态软件”项目的开发，着重讨论实时系统与信息系统的集成。近年来， 国内外的组态软件取得了很大的发展，已广泛应用于企业生产。组态软件以实时数据库作为 核心技术，综合了工控、网络、图形处理与数据库访问接口等技术，是技术含量较高的一类 软件产品，具有良好的应用前景和市场潜力，因此，有多家信息技术公司部在开发工业组态 软件。

我有幸参与了该项目，在该项目中担当了分析与设计的部分任务，该软件采用Windows 2000操作系统，主要采用VC6．O进行开发。以下本文将从我所开发的组态软件的特征、软件的俸系结构设计、实时数据库设计、可扩充性与可维护性设计以及项目实施管理等几方面加以论述。

【正文】

工业控制组态软件在工业界着相当广泛的应用，此类软件允许用户在图形界面下对控制 系统的各种采样点、过程输出点、设备、生产车间、控制回路、文件报警、生产报表、控制 策略、网络设备和生产工艺画面进行定义与组态。使用该类软件时，用户甚至可以不写一行 程序就能够构成自己的控制系统，有些功能强大的组态软件还可提供与网络、Internet、数 据库访问接口等的连接功能，使现场控制系统能桕对方便地和企业的信息管理系统加以集成， 某信息技术公司决定开发新的具有一定通用性的工业组态软件，作为技术骨干，我在该项目 中担当了分析与设计的部分任务，该软件采用了Windows 2000操作系统，主要采用VC6.0进行开发。

本文将从我们所开发的组态软件的基本特征、软件的体系结构设计、实时数据库设计、 可扩充性与可维护性设计以及项目实施管理等几方面加以论述。

1、我所从事开发的组态软件的基本特征

通过分析国内外的组态软件的特点和当前的技术发展情况，我认为我们着手开发的组态 软件应当突出下述三个特征。

(1)“实时与可靠”是此类软件赖以生存应用前提，但是目前还是有很多的组态软件做 不到这一点。

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

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

这个项目在技术上，应着重于组态软件的体系结构设计与实时数据库的设计，需求分析 则应着重分析国内外同类软件的功能，通过比较与鉴别，才能产生真正优秀的软件。

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

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

(1)软件的底层是硬件访问控制层。这一层所采用的是前几年才推出来酌OPC (OLEfor Process Control)技术，采用该技术的好处是OPC是微软参与制定的标准接口技术，有众多 的硬件厂商支持，所采用的OLE技术使软件具有良好的适应性和扩展能力。

(2)中间层是实时数据库。该层是整个系统的核心，在设计上除了具有一般实时数据库 具有的特性之外，应当为应用层提供了两类接口：一是应用编程接口API（比如以DLL的方式实现），二是ODBC接口，该接口使系统具有很好的开放性，便于系统集成。

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

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

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

(1)实时数据库的基本功能：实时数据库完成实时数据库的采集、输出、报警文件等的 管理，也进行历史数据的管理。

(2)实时性设计：由于本系统所采用的操作系统是Windows 2000，它的实时性较差，因 此要求任务管理定时器必须具有良好的实时性，在系统设计时，我们采用了抢占式服务的高 精度定时器，在一定程序上保证了系统具有良好的实时性。

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

(4) ODBC揍口设计：即开发相应的驱动程序，实现ODBC功能，使之完全遵守SQL约定， 这样能允许应用程序的开发手段和开发工具多样化，允许可以采用VC、VB或Delphi等作为 开发语言，也使数据库具有很好的开放性。但SQL语句不能实现数据发生时间方面的选择， 影响了实时性，因此，系统自动给每个数据库加上时戳，soL可通过时戳进行时间控制来选择（读取）数据，从而满足了实时性方面的基本要求。

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

组态软件综合了多种技术，其体系结构与数据结构部较为复杂，再加上我们又希望能适 应的实际应用场景有着复杂多变性，因此要求系统必须具有良好的可扩展性与可维护性，以 满足功能与性能上不断变化的要求。在系统的设计技术上，我们大量地采用组件技术，如OPC、COM/DCOM与3D图彤控件等，组件技木的采用使糸统具有厂艮好的O扩展性与口J维护性，降低了系统的复杂度。而且也使我们较方便地获得第三方支持，例如，请经验丰富的图形处理专家编写图形处理控件，就能加快软件开发的进度。

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

组态软件的需求在当前工业控制领域中是较成熟的，基本能满足一般用户的功能上需求， 通过比较多家组态软件，可似发现：在它们之间有80%的功能是相同的或雷同的，由于我们项目开发的起步较晚，在自控领域里，我们处于劣势，因此我们提出了“重技术分析，轻需求分析”的思路，即把重点放在组件设计与俸系结构的实现上。

在人员的配备上则根据组态软件的技术组成特点，组织一批在自控、网络、组件、实时 系统设计和硬件上各有所长的vc高手组成一支精干高效的队伍。

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

在我们的项目实施中，可靠性作设计的首要原则，要求项目组成员养成良好的编制程习 惯，每天必须完成认真的工作日志，每周要写工作总结，完成一段程序代码之后，即应自己 先进行从里到外的测试，只有从基础抓起，才能保证组态软件的质量。

通过本项目的开发成功，我深切地俸会到要使组态软件在企业实时控制与信息系统集成 中发挥其应有的作用，必须注意以下各点：先进的体系结构，支持ODBC的实时数据库；强大的网络功能；功能日益强大的脚本语言等。我期待着本人通过在这个领域中的辛勤耕耘，将会结出更多更丰硕的IT成果。

论软件质量保证的方法和策略

【摘要】

软件质量的优劣已经直接关系到软件项目的成败。这里总结了作者在软件系统开发中为 了保证软件质量而采用的方法和策略，主要包括：坚决贯彻工程化开的原则；重视文档建设， 以及文档和代码的一致性以及版本控制和跟踪管理；重视工程每一阶段的质量控制，包括计 划、评审、变更管理、责任制的明确；重视人员的管理机制；以及在软件质量的量化控制方 i面的努力。软件工程的科学理论在不断地发展，要提高软件质量，需要从整俸的软件过程和管理模式入手，采用科学的工具。

【正文】

软件作为一种产品，现在已经有了规范化的方法以工程化的思想去“生产刀，它再也不 是个人智慧的小产物，它经常是以若干人年的大投入去生产，而且它运作的性能和可靠性往 往有着至关重要的意义和后果。所以提高软件质量已经成为整个软件开发过程中的关键问题 之一。

我曾经主持开发了一个大型连锁经营的贸易企业的MIS系统的开发，参加了从最初的需求分析到最终的运行维护的全过程，主要担任开发方的项目负责人，负责项目开发的管理， 人员调配，进度控制以及与客户方的联系和沟通工作。一个大型的MIS系统的开发，要保证最终的软件产品成功地实际运行，达到需求的目标，首先我就坚定一个信念，要以工程化规范的SQA来把握每一个步骤，自始至终，绝不马虎。最终我们的系统成功地替换掉1日系统，至今已经基本正常地运行。

这里在保证软件质量方面有一些做法总结如下：

1．坚决以工程化的方法，按部就班地开展每一步工作，绝不急于求成。从最初的需求获取阶段开始，首先是双方决策人员和技术人员的沟通，尽量在战略目标上统一，在总俸的资金投入、人员投入和系统目标上达成一个尽量明确的其识；然后进行可行性研究（在资金、 时间和人员的限制之下是否可以达到系统目标）；在此基础上再进行需求分析和开发。经过不断的修正，得到一个适当的原型。然后开始总体设计和详细设计，以及代码设计和各级测试。先产生一个可试运行的产品，再不断地完善它。在每一个步骤中，部保证每个步骤的工作质量。

2．重视每一个步骤中的文档建设，以及文档版本管理和文档与代码的一致性管理。这里

我们采用了需求变更矩阵来控制和记录文档的变更路线和一致性。每一个步骤的文档和代码 部有明确的版本代号，每一个版本的文档和代码的变更原因、提出变更的人员、对于变更请 求的讨论意见记录、最后是否采纳变更请求部有相应的记录。如果采纳，则选择实现的相应 措施、变更梅要影响到的模块有哪些、相关的人员有哪些，全部都要记录在案；然后每个相 应模块的实现情况以及相应的后续跟踪情况全部记录在案。对于那些已经接受的功能请求，

它的完成情况、可能出现的潜在问题全部都在专门的会议上作确定，并有详细的文档记录。 每一项决定的负责人都有记载。对于文档和代码的版本部有一个矩阵来跟踪和管理。

3．重视工程每一阶段的质量控制。每个阶段都有详细的计划，包括此阶段的目标，工作内容，参加人员，每个人员的工作内容和目标，以及每个阶段的时限，每个人员的每项工作的时限。一般计划到每人每天。每三天有一故小组碰头会，总结计划完成情况，及时发现问题，尽量解决。影响较大的问题就要及时召开项目会议，作讨论，给出解决的方案。每周有一个开发会议，作周汇报，及时审核计划的完成情况。在有突发事件时，要求当天召集人员解决，绝不“瞽待以后”，造成祸患。每个阶段完成时的阶段总结是非常重要的，要求开发方和客户方的领导和技术人员都要参加，尤其对于有变更和有分歧的问题，务必要达成明确的共识。这样，每个阶段每个人员的计划、目标、工作内容，出现的问题，解决的情况，还可能会有潜在问题以及给予的评价全部都有详细明确的记录以供跟晾。这样一切都尽量做到有章可循，并且在有人员变动的情况下，可以把对开发工作的影响程度降低到最小。

4．重视人员的管理。软件产品毕竟是由人生产出来的。人员管理直接关系到软件本身的质量。我要求每个人都要就自己的工作负责任。人员管理按照总负责人到项目负责人，到下层的开发人员，协调人员划分，既有从上到下的责任层次，又按照系统本身的功能模块分块。每一个人既对上级领导负责，又对横向的分块的项目组长负责。责任明确到人，到天，按照完成情况进行考核。以人员的责任感来保障软件的质量。

5．在保障软件质量的量化方面做努力。尽量采用当前先进的软件质量度量方式，以科学的方法试题和检测软件的质量，而不仅仅是从定性的方面来衡量。无论是需求开发的产品， 还是设计阶段的产品，当然也包括代码，以及相应的文档，每个阶段的产物都要在阶段总结 的时候给予定量的质量考核和评估，然后对质量评估的结果给予分析和评价。对于不达标的 阶段产品要给予处理意见，力争做到步步为营。

为了提高软件质量，与那种无章可循、个人说了算、没有严格的进度控制、没有严格的 质量审查的老观念作斗争，我在这次系统开发的整个过程中，自始至终以工程化的SQA的观点出发，使得这次杀统开发无论是资金分配、进度把握、系统功能的变更控制；以及人员调配部优于以往的系统，最终能够按协议中确定的目标和资源限制成功地完成。不过，软件质量在开发的各阶段的量化上还是需要进一步采用先进的方法，努力在软件过程管理上按照 CMM的规范，从而有效地提高软件的质量。而且还要在采用相应的先进管理工具方面做努力。我们已经开始使用Rational公司的软件工程管理套件，争取在过程管理和质量控制方面更上一层楼。

利用测试提高软件质量

【摘要】

本文以某证券公司Intemet应用开发中的软件质量保证实施的过程，讨论了项目实施过程中为保证软件质量所采用的主要技术和方案。

众所周知，测试是提高软件质量的一个重要途径，也是提高软件系统可靠性的重要方法。 自中国加信WTO之后，该证券公司加强自身在Inteynet领域的竞争力，决定升级其软硬件系统平台。其软件平台是J2EE为构架的应用，升级的前提是尽可能和系统原有的软硬件平台兼容，最大限度地保护企业原有的投资，升级的目标是用户提供一个更加快速的交易平台，该平台具有更大的系统吞吐量，并发用户数量和更高的效率。为此我们制定了以下六个步骤完成对系统的测试：测试计划的制定、测试数据的准备、测试环境的建立和测试前数据的备份、测试、测试记录和结果分析、测试验收和试运行。

我在项目中担任了测试计划的制定，测试具体操作的进行等工作，下面就以这两个方面 在正文中展开阐述。

【正文】

对以证券行业为代表的关键领域而言，其基本特点是：实时性强、交易不允许停机、瞬 时数据量大。如陴出现服务器或柜台机停机，或者数据丢失，则无论在声誉或经济上部将 造成巨大的损失。所以在系统测试之初，我们就把确保系统酌可靠性、安全性和效率放在了 首位。证券企业的业务流程、工作方式有箕自身的特点，因此为了确保软件质量，我们要求 测试人员对相关的业务流程要了如指掌，这样在确定故障点时才能“胸有成竹”。

新的升级平台包含了硬件平台，而证券企业内部的网络测试工具和技术力量较薄弱，为此 我们将硬件平台的测试任务让省外某知名网络测试实验室来负责，实施从网卡、交换机、路 由器、外接设备、防火墙等全线产品测试，并且还对网络数据流量模型、网络性能以及优化、 网络安全性等方面进行了较全面的测试评估。而基于J2EE构架的软件平台的测试则由我们企业内部人员和聘请的专家顾问完成，主要测试EJB的性能和负载、Web站点的网页链接、Web站点安全性等诸多方面的问题。

通过仔细分析业务流程和企业自身的特点，我们根据相应的环境确定了软件测试的工作 量；再由测试要素确定测试用例和测试脚本。这里所说的测试要素是指诸如系统环境、类的 接口和类型，程序的规模和复杂度，程序语言选择等方面的内容。测试范围主要是软件平台。 在实践过程中，我们将测试人员的队伍不仅着眼于测试工程师中，而且将相关业务人员、监 督人员也邀请到我们的测试行列中。这样做的原因是，业务员是功能模蛱的最终使用者，他 们可以参与到测试数据和测试用例的准备工作中，并且可以分析相应的测试结果，发现一些 和业务相关但被测试人员忽略的问题。而监督人员则是部门负责人，他们能够在测试进行之 时协调好相关部门人员的关系，并监督测试工作进展。如同ERP系统要由一把手来协调上下关系一样，测试工作也要领导的支持才能顺利完成相关进度规定的任务，为测试和软件质量保证打下良好的基础。

在具体测试过程中，我们分阶段分步骤地采用了一些先进的工具和方法策略。为我们测试 成功奠定了基础。

软件测试指出我们选用的是JUnit测试工具，用于测试EJB模块组件，主要任务是检查EJf是否能完成其所对应的逻辑业务功能。在测试过程中，我们发现所需使用的测试用例中不仅包含普通类型的数据，而且还包含对象类型的数据，对象类型的数据输入仅靠人工来进行是非常低效的。为解决这个问题，我们测试小组成员经过和软件开发人员探讨，决定将美四人小组提出的“设计模式”中的生成器( Builder)模式应用到测试中去。具体的做法是，使用导向器(Director)将要生成的对象类型数据-TestCaseObj ect所拥有的属性和数据从

文件中用Director类中的readFromFile()疗法读出，放到AxrayList中，然后传递给类Buildei 中的子类-builderTestCaseObj ect中去，由该子类生成相应的对象并返回给Director。

由于对象的创建过程代码由Director类负责，而生成由Builder的具体对应的子类蛋黄，这样我们就可以重用对象类型的数据。这个程序不长，但将测试人员从繁重的手工机械重复的录入工作中解放出来，并且将软件开发复用领域里的模式引入到测试领域，激励了测试人员的积极性和创造力。

在完成初步的单元测试之后，我们又使用了美国ISA的Panorama软件工程和自动化测试工具。一个良好的测试工具不仅能发现软件中的错误，而且能够定位这些错误，而修正这些错误并确保这类错误不再引入则是测试人员所渴望的。我们面对的是一个有近千个EJB组件的软件框架，每个组件的方法调用或多或少和其他组件有着联系。我们若改动一个方法调用、全局或者局部变量，势必将引起方法调用和变量在其他模块中的不一致性。如果仅靠人工搜索定位语句统一更改将是十分枯燥的工作，同时会产生较大的反复性。P anorama在这一方

面相当的出色，测试人员不仅能够精确得到寻致软件故障的语句代码，更能从P anor am撷0试工具中得到修正后的方法调用会影响到哪一个位置的一份清单。这样我们测试人员可以提交一份相当详细的测试结果报告给软件开发人员修正，这样就确保同类型的问题在软件构架的大范围下统一解决，保证回归测试中不再出现同类问题，减少了反复性。而在测试用例方面，我们使用P anorama的测试覆盖功能从类、函数、块、段、边界循环条件、判定等诸因素多层次地确定测试覆盖能力。我们在实践中发现，面向对象系统测试用例大约只有100Xv--15贿壬效的，当测试覆盖在段中达到50%～6096时，随机生成的所有测试用例都是重复的。而利用Panor ama提供的最小化测试用例，则有助于我们在修改模块之后，避免重新生成新的测试用例这一重复性劳动，由P anor ama自动调用先前的最小化测试用例来进行回归测试。实践证明这是非常有效的。

基于站点的性能、负载测试，我们使用了WebLoad0试工具，对EJB分别进行了性能和负载测试。这两个测试看上去相似，但有区别。性能测试是由测试工具模拟单机检查Bean的响应性能如何，即从开始调用Bean或Bean中的方法到调用结束所花的时间。测试中我们炭现一些Bean的响应性能较差，在经过了代码整理或优化算法后性能往往有了显著的提高，因此这一阶段的修正主要是代码的审查。测试中发现的一些问题，诸如一些没有必要创建的对象被创建了，一些线程要等待其它线程结束才能结束等，这些问题都由测试人员仔细记录到测试文档中，交由软件开发人员进一步处理。对于负载测试，使用测试工具模拟多用户访问站点，以检测站点所能容纳的极限访问量，或检查在用户开发数目增大的情况下，系统的事务处理能力、吞吐量、内存利用率等数据的变化及其原因。测试之初，系统自然不可避免地存在响应较慢的问题，我们知道这是由于客户机或线程争用系统资源（如代码中的资源，数据库后台资源等）而导致的。我们采用逐个隔离、逐一排除的方式找出平均响应最慢的组件以确认其为瓶颈。此类测试的体会是在访问之初，不要将测试的时间作为衡量的基准，因为此时Web服务器中的内容没有缓存到内存，且测试响应时间要多项取平均值作为标准。限于篇幅，Web站点网页链接测试，安全测试不再叙述。

此故软件测试，对确定软件质量保证起了很大的作用，也使我受益匪浅，让我对质量的 概念有了深层次的认识。但同时，我也认为自己还有很多领域和知识点要继续砑究和实践。 随着UML的流行，面向对象的测试要求也越来越高，一些新的领域，如软件复用领域等对测试提出了新的要求和挑战。理论和实践结合，不断探索和突破自己，应该是每一个工程技术人员内在的要求。

应用CMM保证软件质量

【摘要】

本文论述了如何在一个规模较大的网上管理系统的开发中结合c删二级的框架要求，以及软件工程学的质量保证策略进行项目的软件质量保证工作。

本项目的特点有：

(1)开发人员多，有40人左右；

(2)采用面向对象分析与建模技术，JAVA语言，WebLogic应用服务器等以前项目中未采 用过的开发模式和技术。因此不确定性因素很多，急需采用有效的质量保证策略。

公司为了提高软件开发能力，已经于近期全面引入了当今软件界正在流行、且行之有效 的CMM质量保证体系，并在顾问公司和主评审员的帮助下，由公司的SEPG结合公司实际，制定了初步的规范俸系和模板文件，并决定将本项目作为试点项目。

本文详细论述了作为SEPG负责人之一，并且担任本项目质量保证人员的笔者，是如何

在本项目中有效推行C唧二级质量保证措施的，并指出了其中的经验教训和有关的建议。

【正文】

本项目是一个面向政府管理部门，全市房地产企业和个人用户的网上管理系统，它既是 一个电子商务项目，又是一个电子政务项目。本系统采用了B/S结构，融合了政府部门和房地产企业的内部网上管理系统于一身，同时作为全国建设系统信息化的一部分而实现Inter -net乎台上的上下集成。它还提供信息发布、房屋交易等电子商务功能。

本项目对系统的安全以及可靠性等方面有着较高要求，公司决定采用三层架构模式的 J2EE环境作为运行环境。另外，本项目参与人员众多，面临着新技术、工期紧等影响软件质 量的不利因素，对软件质量保证工作提出了很高的要求。本人作为公司CMM实施工作的负责人之一，以质量保证人员的角色参与到项目的开发和管理工作中，主要负责质量保证策略的建立以及实施工作。

一、以CIIj眨理论为指导，采取措施保证开发过程与开发规范的符合性，以过程腥的 攫霜-爿硼氐D与品的高鼹

1、建立起明确的权责制度，减少因权责不明而产生的混乱

为确保质量保证人员有独立的途径向公司反映开发中的问题，同时为了避免质保经理与 项目经理、软件配置经理之间过分隔阂，本人在项目启动阶段，起草了《项目管理人员责任 节》，行由相天人员讦审通过；行提议公司设立了高级经理交涉，以快速处理纠纷。

为防止开发人员与项目管理人员在规范化开发过程中过度依赖规范而主动性不高，以及 可能产生的相互埋怨，制定并实施了《项目开发人员守则》，由各项目级每个成员在参加项 目之初进行签名式确认，以解决开发过程中应规范滞后和实施不尢而引起的混乱问题。

2、以制定的《质量保证计划》为纲，全程监控各开发工作的过程建立和符合性问题 在项目启动阶段，就依据CMM-级要求和公司发布的项目开发规范，制定并基线化《X X 项目质量保证计划书&，在计划书中详细地制定了质量保证工作的内容和进度安排。 计划书中主要有职责、培训工作、检查评审及组织工作等四方面的内容。

职责方面详细说明本人作为质量保证人员在项目中的全责以及主要活动，澄清了与各开 发角色的关系，主要起到项目成员监督质量保证人员的作用。

培训方面指明了为有效推行CMM质量体系而进行的有关培训，有CMM基础理论方面的，也有本项目特色的规范方面的培训内容。

检查评审方面指出了要检查评审的过程及提交产品，并列举了相应的通过准则，目pCHECK-LIST。比如要评审的过程有项目规划阶段；检查项目经理和配置经理是否按有关规范制定了各自的计划书；项目组的技术评审活动是否符合评流程和规范；风险分析过程和任务分解过程是否符合规范的执行。对提交的工作产品，如需求文档和设计文档，是否经过了正式技术评审并基线化。这些都指明了切入时间和建议人员。

组织工作方面指明QA（质保人员的简称）在开发过程要做的组织工作，如按术评审工作、测试工作、估计和工作细分等工作。这些组织工作主要是为了协助项目经理开展工作并能有效且及时地获得第一手质量方面的资料。

对项目开发过程中的跟踪和检查，主要采取了现场参与、分析项目成员日报和周报、个 别交流以及项目周例会的形式。

一、以邱cr软件工程方面的理论为指导，制订了行之有效的技术规范文件

CMM质量体系更多的关注软件开发过程方面的事情，也就是建义由谁在什么时候做哪些工作，但没有指明各个工作如何开展，也就是偏重于管理，偏轻于技术指导。为了避免在框架方面很有效，但应实现细节不明确而出现的“一条腿走路”的现象，特在项目启动之初就制定了要建立的技术规范，如需求文档编写指南、界面设计规范等。这些都列入QA的计划中了。

考虑到本项目采用了面向对象的分析和设计技术，急需mrtL和Rose技术方面的指导性文档，因此将与mrtL高度相关的RUPCNt4t系为主要参考，其他软件工程理论为辅助参考，组织资源开发人员制定了各个开发阶段的规范性和指导性文档。

实践证明，项目组成员有了CMM过程方面的规范，又有了指导开发工作的详细技术文档后，开发质量有了质的提高。主要体现在以下几点：

1、各个过程的效率提高了．从而保证了各个交互成功的质量。

比如，人员的选择，时间的必备，开展的流程方面真正按照CMM的建议做了，这些都保证了开发过程的高效。一个显著的例子就是技术评审过程。如果选择的人员资格不够，所花的评审时间很少，开展的时机不对，就很难保证提交成果的质量。

2、人员之间的交流变得有效，自信心更强了。

三、不足磺待改进之处

由于是初次按照CMM的要求在项目中实践QAI作，因此不可避免地有一些不足之处，主要有：

● 因培训工作的不及时、不全面，导致Q店∈施工作遇到了一些麻烦。

● 质量度量数据的收集和分析工作做得还不够。仅仅有少量的度量数据，分析工作也很 少。总的原因是缺少一个有效的度量数据收集和分析机制。

总之，这次项目的质量保证工作基本达到了CMhL级的框架要求，证明了过程质量是产品 质量的重要因素，为本项目顺利地、高质量地完成做出很大的贡献。但也有很多教训值得吸 取．需尊存培训T作和0A霄量数据U々童和剩田青而下事六宁力．

护士工作网站系统中的质量保证

【摘要】

软件的质量就是软件的生命，是软件项目得失成败的关键。本文从一个真实的开发项目 《护士工作网站系统》中描述软件质量保证的方法和策略。本文认为保证软件质量主要狠抓 三个方面：有效控制软件开发的过程；内部有角色职责的组织；对开发过程和开发人员的恰 当管理。这三个方面需要有机结合才能有效地保证软件质量。护士工作网站系统是医院信息 管理系统的重要部分，本人在总结以前的经验教训的前提下，根据以上三方面工作，有效地 控制了软件的质量，成功地使系统上具，得到用户的肯定。

【正文】

本人所属的公司是开发医院信息管理系统的，我担任该项目的负责人，具体工作包括开 发人员的管理、系统分析及软件质量控制。

在系统开发的初期，我们开发了门诊系统，其中包括挂号、收费、门诊药房等子系统。 我们当中不乏技术过硬的开发人员，但当系统上线时，软件的质量并不理想，其中包括一些 明显的错误。如挂号重号、收费累计出错等；而且文档不齐全，造成软件维护比较困难。之 后，我们开发护士工作站时，本公司几个技术骨干总结了以往的经验教训，得出以下结论：

1、在开发的过程中缺乏对开发人员的控制，如技术控制、文档控制、测试的控制以及舨 本控制。

2、开发人员的角色功能没有细分，即各开发人员职责不明确。如需求分析、设计、编码 和测试的角色没有详细划分。

针对以上结论，本人提出，要保证软件的质量必须要做到以下两方面：加强对开发过程 的控制；要有清晰的人员分工。这是根据ISO标准和CMM的指导精神，软件的质量存在于软件开发过程的质量，对软件生产过程进行改进，就是对软件质量的改进；提高对软件开发

过程的控制能力，就能控制软件的质量。基于这个原理，本人公布了以上两项措施，得到广泛的支持，并共同制定了具体的实现方案和人员组织方法。

首先定义出开发中最主要的过程：系统的计划、需求分析、系统设计（包括概要设计和 详细设计）、编码、系统测试，并对每个过程参考软件工程继续筛选，以适应本公司的实际 需要，确定每个过程的具体工作内容。

其次确定了软件开发的具体开发方法，如采用面向对象的方法和结构化的方法。最后确 立了面向对象的开发方法，并对每个开发过程定义了相应的具体文档，如系统计划必须提交 《系统开发计划进度》，需求分析过程必须提交《软件需求规格说明书》等。并定义了文档 的格式和必须提交的内容。

最后对每个过程发生相应的人员职责，即指定人员，人员的过程中扮演的角包及相应的 工作要求，人员需要的相关知识及具俸工作内容。

但制定这些实施方法和规章制度并不是一朝一夕可以完成的，残们总结了以往失败的经 验教训，进行了、认真的思考和论证，历时三个月，而这这套方案和制度制订出来，并实际实施我们开发的住院系统中，取得较好的效果。以下以开发护士工作站为例说明运用这套方法取得的效果。

我们在实施过程中改变了我们的方法，就是加强了对开发人员的管理。在开发的初期， 我们和医院方面取得联系，并初步了该系统的功能目标，根据本公司的实际情况制定了系统 开发计划。然后按照我们制定的过程，需求分析一一系统分析一一编码一一测试一一实施一 一维护进行开发。在整个过程中，我们得到所有的文档，并根据文档反映的内容对每个过程 进行了检查。基本上可以按照我们预定的目标进行。虽然最后进度有所延误，软件的实施过 程中还有错误，但所有这些都在我们的控制范围之内。

在实施这个质量过程中，我认为比较有独到之处的是加强了对人的管理。其实，开始实 施的时候，我并未十分注意。在需求分析的时候，系统分析员虽然按照预定的方法和内容进 行了工作，但对文档不够重视而且没有得到用户的确定后就马上进行设计，这样在设计过程 中遭到用户异议，井造成了设计人员的概念模糊。我们马上回到需求分析过程，对分析员的 工作认真检查，对文档进行严格的审核，终于完成了一份较完整的《软件需求规格说明书》。 自此以后残对每个开发人员和每个过程进行认真管理和检查，确保文档的质量和人员的工作 质量。最后软件完成后，其质量也得到了用户的肯定。由此我得出了以下体会：别人的工作 质量控制也应该是过程质量控制的一个重要组成部分，而且是关键。开发人员的工作质量有 了保证，过程质量也有根本的保障。光有制定的方案是远远不行的，关键是人的实施，把人 实施过程的质量控制好了，过程中产生的文档质量也有了保障，软件质量也相应地有所保证。 总之，软件质量在于过程质量，过程质量在于工作人员的工作质量，这是我在实施软件质量 过程中最大的体会。

软件质量保证是一个很大的问题和实践方向，这是我在实施过程中的一些体会和方法， 还有许多改进和完善地方，在以后的工作中，只要抓原则，逐步实施，我相信我们开发的系 统有更进一步的质量提高。

论中间件在SIM卡应用开发中的作用

【摘要】

我曾于近期参与过一个基于SI胩应用的开发项目，并在项目中担任系统分析的工作。 在分析过程中，我们依据面向对象方法对系统进行了划分，其中许多的模块已有成熟的 中间件产品可供使用。我们选择中间件产品的标准是：功能、性能、封闭性、独立性、可扩

充性、是否标准化等（或是否是主流产品）、跨平台性、话语言性，以及中间件的大小和价 位，并且面向对象的优于面向功能的。

由于复用了大批的中间件，使得项目工作量大大减少，开发周期明显缩短，并且在项目 I的编码部分，我们也尽量制作自己的中间件，以便在以后复用，或以恰当的形式销售，增加公司的利润。

自己设计中间件，首先要做领域分析，以确定其价值，并依据上述原则开发。产品形成 后，要由管理系统负责中间件产品的存储、描述、查询、发布以及动态维护、版本控制等。

【正文】

中间件技术是近几年随着软件工程技术的发展，网络应用的普及而迅速发展起来的，其 在软件开发中最突出的贡献在于资源复用。随着分敌的、作坊式的、独立的软件开发方式向 集中地、大型的、协作式的软件开发方式的转换，软件的划分向着高内聚、低耦合的方向前 进。类似的，重复性的、独立的软件部分被抽职出来，被做成模块、对象以及中间件。我们 利用中间件拼装产品，共享着人力资源和时间资源，减少了重复劳动，减少浪费，增加了价 值。由于中间件的出现，软件开发可以变得十分专业化。例如通信中间件、数据库中间件，??， 他们屏蔽了许多繁琐的细节，使得应用程序开发人员质量与优化业务逻辑。各种不同的劳动 量得以在自己熟悉的领域得到发展，不用分散精力，这就是分工带来的优势，专业化带来的 好处。如今，在计算机软件科学中，这就是中间件带来的好处。

我曾经参与过的某个项目在这方面带给我深深地感触。这是一个关于SI胩的应用，其功胄邕要求是：在SIM卡上存储信息并与计算机内的信息同步；利用SI咔的信息实现网络安全控制。

我作为系统分析人员，采用面向对象方法进行分析，这里只作简要概述。

在该项目中，我抽象出的一个核心对象是“信息对象”。通过读取SIM卡/j+算机内信息， 可构造出该对象实例，通过将该对象实例更新入计算机/SIhl【卡 -完成信息同步的功能。而实现I网络安全控制的功能则通过验证对象属性来完成。

其中读出SIM卡、写入SIM寻的这部分，已经存在大量的中间件产品，我们选择了微软公司的系列产品，带给我们极大的便利。因为我们不苒花费精力去考虑如何编写代码以及与SIM卡读写设备驱动程序进行通讯，如何将信号转换为二进制数，或转化为字符。它使我们摆脱了对设备物理细节的考虑。

此外，在读写计算机内数据时，利用了数据库中间件，此处选择的是微软的ODBC、ADO系列。在进行用户界面设计时，也应用了许许多多各具体特色的图形控件。

而在实现SIM寻网络安全控制时，选择了smrt公司的基于JAVA的SIMJ亚用套件、SSL网络安全协议的辅助构造我们的项目。

在这样的选择之后，遗督给我们的仅是一些信息管理以及在各中间件进行协调、调度的 工作，整个项目因此而显得异常轻松。

如果在没有中间件可供使用，一切需要从零开始的境遇中，这样一个小项目将会变得多 么可怕！除了劳动力资源的严重消耗，还带来了许多隐患，例如与别人的产品的协作性问题。 因为如果对硬件设备的处理不同，网络传输的各自构件的协议不同，根本不存在互通性。 因此中间件在软件模块标准化、软件复用性、跨异构系统协作方面也功不可没！

在我们选择中间件产品的时候，最先考虑的是功能性。因为只有项目缺少的功能，才有 被使用的价值。而且中间件产品性能也是可以影响项目的因素。此外中间件是否采用标准和 通用的接口形武，其封闭性、独立性、扩充性、跨平台跨语言的能力，也是影响我们项目的 稳定性、可扩充性的关键因素。另外产品的大小、运行环境以及价位也是我们考虑的因素， 这影响到项目的成本和效益。

如今的主流开发技术部支持面向对象和中间件（组件、控件、服务）。大家部意识到了

复用的重要性。如果由我来、央策，我会选择在开发项目同时开发中间件产品。虽然这样的开发模式在单个项目中所耗资源较大，因为要考虑中间件的各种特性，如独立性、通用性等。 但就长远目光来看其复用带来的成本节约以及项目周期短、开发模式标准化、通用化等利益， 将极大地提升企业利润。

为了能够开发出有价值的中间件并同时进行高效地利用，我们注意以下方面：

一、在决策开发中间件时，一定要做好领域分析。在相关领域内通用的中间件才有可复 用性，才有价值。

二、对于中间件的策划，要注意其独立性，封闭性（接口清晰、标准），最好是以对象 的形式开发，提供继承功能，可以提高中间件的可扩充性。

三、最好做到跨平台、跨语言，以增强通用性。

除了这些原则，对于中间件产品有也应有相应的管理工具，应建立系统对中间件产品进 行存储以及描述、查询、定位该产品，对于产品的升级也应用CUS等版本控制工具来管埋。此外，发布产品也应遵循业界的标准。

当前的Web Servlce其实也是一种广义的中间件，公司应尽早投入到该领域，现有产品有微软的的．NET，IBMJWebSphere等。

这些方案的益处是能够提高产品的可复用性，应用Web Servlce技术则提供了更远大的网络廊用发展窄间。

论虚拟现实技术的应用与发展

【摘要】

本文介绍了虚拟现实技术的主要技术和应用，并结合作者本人参加的国家重点实验室的 自然科学基金项目，重点讨论了基于图像的建模与绘制在虚拟现实中的重要地位与应用，详 细分析了近15年来国际上基于图像的建模与绘制技术的发展状况与当今世界上最先进的研究热点，并详细阐述了作者在国家重点实验室精心基于图像绘制技术科研工作中所参与的系统开发。文章最后，说明了作者所参加的科研项目的开发成果，并简单介绍了作者在试验项目中所发表的论文，对未来几年中虚拟现实技术的发展趋势作出了较为科学的预测并提出了作者本人独到的见解。

【正文】

虚拟现实技术是当前科学研究的热点，同时也是国家大力支持发展的核心技术之一。所 谓虚拟现实，就是通过计算机等虚拟手段来构造一个非常接近真实世界的虚拟环境，它主要 体现在视觉、触觉、嗅觉等方面的逼真模拟来达到高度的沉浸性，也就是如残们通常所说的 “身临其境刀。它涉及的领域非常广泛，包括仿真技术、多媒体技术、传感器技术以及计算 机图形学等多个科学领域。同时，随着科技的发展特别是网络、计算机硬件等领域技术的完 善，虚拟现实也得到了越来越多的应用。包括军事、医疗、航空航天、旅潇业、建筑业、娱 乐业等众多行业中，虚拟现实技术部具有广阔的应用前景。

我作为浙江大学CADLCG国家重点实验室的一名科研人员，有幸参加了多个关于虚拟现实方面的科研项目，其中国家自然科学基金项目《虚拟现实中的基于图形的建模与绘制技术》 中，我投入了大量的精力，进行了广泛的学习与探索，参读了国外很多相关领域的文献，特 别是近15年来SIGGRAPH大会中的精采论文，并与实验室的其他人员进行了大量的讨论，和国内外领域中的专家学者进行了多方面的交流，取得了很多实质性的进展。同时，我结合该澡题在理论的探索中进行了大量的编程模拟实验，开发了一些虚拟现实系统。

我们知道，虚拟现实的一个最主要的方面就是视觉效果上的真实性，例如虚拟漫游系

统。可以说，视觉上的问题解决了才能进行考虑触觉、嗅觉等方面，否则就是本末倒置，因 而目前世界上大部分的科研工作都是基于视觉上的真实性进行研究的。同时，随着网络技术 的发展，网络的带宽不断增加，其于Web方式的虚拟现实系统越来越成为主流，而且在美国很多先进的企业中已经得到了广泛的应用。而网络上虚拟现实的一个关键性问题就是速度，因为网络带宽相对于本地运行来说速度还是很小的，那么如何解决应拟现实中图形的绘制速度，以达到网络显示的实时性就是一个非常重要的澡题。我们也了解到，传统的建模是基于几何的，这导致当场景较为复杂时计算量过大，特别是要处理物体表面材质时，几何贴图一来真实性不高，二来速度过慢，几乎没有达到网络实时性的可能。对于大部分P C机客户，更是不能在网上欣赏到逼真的虚拟现实场景。因此，世界上一些科研人员就提出了使用基于图像的建模与绘制的方法。因为图像是真实世界的拷贝，逼真度高，而计算量又很小，可以满足普通PC机的用户以及当今网络带宽的需要，很好地达到虚拟现实场景的实时绘制。 基于图像的绘制技术( image-based rendering，IBR)最早由Apple Company的Eric Chen 提出，他早在80年代初就在SIGGRAPI-LL发表论文介绍了他的图像拼接理论，次年又基于该理论开发出了Apple著名的Quick Time VR系统，并在当年的SIGGRAPFLL发表论文详细地介绍了该系统，在当时的计算机领域引起了极大的轰动。该系统的主要手段是用多点拍摄的8张图片，进行无缝拼接算法整合成一张3600的环视图像。我在实验室进行相关的科研时，参与了一个类似的系统开发，刍然，时隔多年，我们又在原来的Eric Chen的理论基础上，结合最新的科研成果，使用更好的算法开发我们的系统。关于该系统的开发方法，本文后面将有详述。在EricChen之后，又有很多世界顶级的科研人员不断在SIGGRAPH上发表论文，以向世人告知他们的最新研究成果，现在IBR已经成为每年SIGGRAPH中一个重要议题，每年都有4～6篇论文发表。例如基于特殊点之间进行转换的Jrtorphing技术，基于全光场理论的光场建模绘制技术，基于图像拼图的拼接技术，基于人机交互的辅助技术等，都在一段时间内取得了巨大的成功。特别是拼图技术和全光场理论带来的各种基于光场的技术，在最近的3年内主导了国际上IBR领域甚至虚拟现实领域的主要发展方向。

我在实验室从事相关领域的科研工作之时，主要是进行了大量的理论学习与研究，当然 也开发了一些虚拟现实系统。例如本文前面提到的类似于Quick Time VR的系统。在此系统的开发中，基础的理论已经比较成熟，而且已经有产品化的实物供我们参考。我们的主要工作就是结合理论，使用逆向工程的方法，导出软件系统的设计思路，并融合后来几年中国际上对Quick Time VR系统提出的改进诒，开发出一套自主知识产权的虚拟现实系统。

我们首先以理论为基础，结合逆向工程工具导出原始的设计模型，加以改进，采用合理 的分层结构重新设计了系统。在讨论完系统高层模型后，我们的人员需要分成3个组来进行开发。一组开发算法，一组开发系统界面，一组开发底层控制部分。我被分在系统界面开发组。虽然不是核心算法组，我们在对待界面交互设计时仍然进行了大量的分析与策划。我们抛弃了传统的MVC模型来工作，而是采用了国际上最先进的TaskMaster模型来作为我们的界面部分的驱动模型。TaskMast er模型是MVC模型的改进，它使用有限自动机来控制状态驱动，将原来的MVC模型作了更加彻底的分离，使得软件系统的各个模块之间独立性更强，增加了内聚，减少了耦合。它将系统界面对用户的响应分成多个Task，每一个Task使用一个有限自动机来驱动，有限自动机接收消息，执行Implement ation，并完成状态转换。同时，TaskMaster模型不但结构清晰，还具有代码自动生成工具，使用该工具，可以快速自动地实现自动机模型。总之，使用TaskMaster模型，我们解决了传统MVC模型的不足，取代了MFC消息响应机制的下完善性，大大加速了系统的开发。后来的开发成果也证明了我们使用较少的人力物力开发出了优质、美观、高效、高可靠性及高移植性的系统（TaskMaster模型很容易移植到Linux系统下，并且Linux系统下也有TaskMast er自动代码生成工具。） 另外，在开发过程中，我们的测试文档也做得相当成功。坚持使用了单元测试、集成测

试，确认测试每一个步骤部到位，特别是单元测试和集成测试，我们小组做了大量的工作。 先是个人测试，然后进行组内交换测试，最后全组讨论，再进行集成测试。文档也和测试一 样，是每一天部跟着来的。

在项目管理上，我采用了Microsoft Source Soft来进行控制。因为小组有6人，大家分 别在不同的机器上开发，进度不同，加上我们小组内模块相关性高，传统分开开发最后集成 的方法肯定不行，而使用了Source Soft之后，管理开发就轻松许多，并且大大碱少了最后进行模块集成的工作量。

总之，在本饮科研活动中，我们不但顺利、高效地完成了模拟系统的开发任务，而且大 量实践了软件工程方法，引进了国际最优先的TaskMaster模型等，得到了很好的效果。更重要的是，我们出色地完成了实验室的国家自然科学墓金项目，为实验室争得荣誉，为国家填补了科技空白。我个人而言，不但在组织本小组进行系统开发的过程中，实践了项目管理、 进度管理、质量管理、人员分配、合作能力、文档管理以及测试管理等软件工程方法，并引 进了国际先进的开发模式，取得了良好的实践效果；同时，本人还有一篇关于基于图像的绘 制技术的论文被第八届联合国际计算机大会录取。

当然，我在科研工作中以及相关系统开发中也遇到一定的困难，比如模型选择、人员分 配等都走了一些弯路。而且TaskMas t er模型虽然清晰高效，但代码量比传统7rtVC要大得多，文件数也多，给管理造成了一定的困难。

再回到虚拟现实领域，我觉得目前在视觉方面已经较为成熟，例如IBR领域，未来的扩展需要依靠硬件辅助计算、网络分布式、人工智能技术的结合。而整个虚拟现实领域将更多地开始从事触觉和嗅觉等方面的研究，而且为了达到更真实的效果和更高的实时性，我预计将会有更多的整合人机界面学、人工智能、分布式计算、数据库等技术，其同来创造一个完美的虚拟现实世界。

论软件项目的进度管理

摘要

本文讨论了《电力行业工作票、操作票系统》的项目管理，在本项目中我作为项目负责 人，承担了项目管理工作。

在本项目管理中，我主要采用了面向对象技术同传统技术相结合的原则，在估算项目的 工作量这方面尤为突出，面向对象技术对传统技术有所改进，传统技术能弥补面向对象技术 的不足。

本文从合理的估算项目的工作量及技术难度；识别关键任务；随时了解项目进度，必要 时调整进度表等方面讨论了《电力行业工作票、操作票系统》项目管理的基本活动与方法， 有效地控制开发进度，确保项目如期按质量完成。本系统在电力系统已经运行，状况良好， 受到一致好评。

正文

20xx年2月，我参加了《电力行业工作票、操作票系统》的开发，担任项目管理工作。 电力系统有关部门在对电力设施进行检测、维修、试验等一系列活动时应按照我国电力行业 相关标准进行工作，《电力行业工作票、操作票系统》就是按照国家有关标准及电力行业操作规程设计的仿真系统。工作人员在施工前按照工作流程在此仿真系统上进行操作，严格遵守电力设施的逻辑闭锁关系，顺序执行。有效地防止不规范操作，确保电力设施及现场工作人员的安全，提高安全意识。

本系统由系统图编辑平台和工作票，操作票签发系统两大部分组成，其中系统图编辑平

台主要是编辑变电站、用电系统及变电站控制系统图，每一个电力设施对应一个对象，在系 统图上都有相对应的部分，系统图真实地反映电力设施的布局及相互关系，生动形象又合乎 技术标准，同时为第二部分提供操作对象。工作票、操作票签发系统主要是在系统图的基础 上进行点击操作，每次点击对应一个对象即一个电力设施，根据电力设施的逻辑闭锁关系自 动生成相应的工作票或操作票或提示操作不规范。

在本系统的开发过程中，我通过合理的估算项目工作量及技术难度；识别关键任务；随 时了解项目进度，必要时调整进度表等方面对项目进行管理，确保本系统如期按质量完成。

1、合理的估舅项目工作童蛹跬枣商睚霞

我们在项目工作量及技术难度的估算上采用面向对象技术同传统技术相结合的原则。 本系统采用了面向对象的分析、设计等一系列面向对象技术，在本系统工作量的估算上 根据功能点进行估算。将每个功能模块逐步分解，直至基本模块为止。我们将系统分为系统 图编辑与工作票、操作票签发两个大的功能分别进行估算。系统图编辑部分主要是一个图形 编辑系统。一种电力设施对应一个类，电力设施的技术参数及其操作对应相应类的属性和方 法，电力役施图是由线段、圆、曲线、折线、多边形等基本图形组成，这些基本图形分别对 应一个类，这些类又继承一个最基本的类。系统图编辑部分的工作量也就是这些类的实现， 工作票、操作票签发部分用到了编辑平台的系统图，因此由大量的功能可以复用，这部分的 功能划分同系统图编辑部分一样也是采用类作为基本结构，这样就此较准确的进行工作量的 估算。

同时我们开发的这个系统是基于C/S结构的，由于C/S结构的系统我们公司有不少成功 的案例，因此有不少的案例供我们参考。对于本系统的第二部分我们就是借鉴以前我们做过 的基于C/S结构的系统，基于c/s结构的系统的框架基本上是一致的，数据库的设计、前台 操作如对数据库进行添加、删除、修改、查询等一系列活动大俸相同。正是如此，有大量的 东西可供我们复用，如权限控制模块我们就是复用以前的案例，仅作少量修改。在工作量的 估算上也有很好的借鉴作用。这对工作量的估算也是一个重要的参考，为工作进度安排提供 了依据。

在技术上，我们重点考虑本系统与其他C/S结构的系统的不同之处，相同或相似之处我 们认为没有技术难点。系统编辑平台主要是绘图，我们知道MFC的绘图功能确实强大，但是过于繁琐，功能封装不是十分完美．我们采用了Form++这个MFC扩展类库，这个扩展类库对图形操作封装得很好，大大降低了系统图编辑部分的难度，在界面设计上我们采用了BCG这个扩展类库，使得VC应用程序界面设计得如同Delphi等工具一样完美。同时减少了工作量，在工作安排上，技术难度相对大一点的部分我们安排经验丰富的程序员，同时也同其他工作组的成员商讨技术细节问题，同他们进行技术探讨。这样不至于因为某一技术细节而影响整个工程进度。

根据上述分析我们制定一个详细的进度表并定义相应的里程碑。

2、识别关键任务

系统图编辑部分是整个系统的基础，因为工作票、操作票签发部分是建立在该部分的基 础之上，系统图编辑部分直接影响到整个项目。因此该部分是整个系统的关键部分，在这部 分中每种电力设施所对应的类及其父类的定义是关键，因为所定义的类必须完整、准确地反 映该电力设施的技术参数和操作。

工作票、操作票签发部分，是用户明确提出的要求实现的功能，直接面对用户，这部分 的成功与否直接影响到该系统的质量，因此也是不容忽视的。

如果上述两部分任务的进度受到影响，则整个项目的完成将受到威胁。因此是本项目的 关德任务。在进度控制时我们将其作为重点对象进行控制。

3、隆时了解项目进度，必要时调罄讲麟

在确定项目开发计划时，我们制定了详细的进度表。我们在确定每一项任务时部确定该 任务的工作量、开始时间、持续时间、结束时间。同时让每个小组成员知道自己所承担任务 的时间表，小组成员根据自己的任务制定自己的详细工作计划。

工作日志是了解每个小组成员工作情况的很好的方式，我们要求每个小组成员对自己的 工作都要做工作日志，对自己每天的工作做详细记录。每周对自己的工作进展做出结论，向 项目组汇报。在做结论时，不得使用“差不多”、“大概刀、“完成了90%”?等模糊字眼。 而 是采用某任务 “已经全部完成”、或者"90%的工作全部完成”或者“再过1天全部完成}> - - -等方式。每个小组成员对自己做出的结论负责，这样可以做到随时了解项目进度，为调整项目计划提供客观基础。

同时我们在项目进度计划中根据项目设计定义了相关的里程碑，在每个里程碑我们都采 取小组会议形式对本阶段的工作进行确认、总结，对本阶段的进展情况做出结论，并、央定是否调整下一阶段的进度计划。在系统图编辑部分我们认为各电力设施所对应的类（包括其父类）定义完成为一个里程碑，每个类是否具备了相对应的电力设施的技术参数及操作是该里程碑的栎准，这些类（包括其父类）的实现完成又为一个里程碑，??整个系统图编辑部分完成也是一个里程碑。每个里程碑的标准在系统设计时已经定义好。

结束语

《电力行业工作票、操作票系统》目前已经开发完毕，运行状况良好，受到一致好评。 在本系统开发的整个过程中采用了面向对象技术同传统技术相结合的原则，因为小组成员的 各有特长，面向对象技术不是每个小组成员部熟练掌握，加之面向对象技术在我们公司还不 是很成熟，必须有一个过渡，不能一下子转型，因此采用这种策略符合我们公司的现实情况。 由于项目进度管理得当，项目按期完成，我们小组鬲得公司的好评，其他小组也研究我 们的管理方式。当然项目管理方式多种多样，根据项目不同、人员不同管理模式应做调整而 不是一成不变。适合本项目的管理模式才是最好的模式，先进的管理方法在不同的项目组中 取碍的妁翼昙不同的．；文有待千耢们去研京．{婴索．宰麟．.b结．

论软件项目的进度管理

摘要

20xx年10月，我参与xx市农村信用联社综合业务信息系统的开发工作，该系统面向 交易、以客户为中心、采用大会计模式，并以会计核算为核心，实现本外币合一，将柜员管 理与柜面业务有机地结合起来，以业务种类码来划分整个业务系统。该项目分为二期：第一 期为柜面业务，为期14个月，已于20xx年底完成；第二期为卡业务，为期一年，尚在开发中。

在该系统的开发中，我主要担任可行性分析、需求分析、概要设计和第一期项目的项目 管理工作。我采用PERT计划评审技术，标识关键任务的同时，允许一些任务并行进行；着重考虑人员在整个项目开发过程中的安排；重视文档规范、命名规范，为减少员工之间的通讯障碍，还启用了Notes系统；跟踪和控制项目计划的执行等措施，保证了项目按期完成。但是，由于对人员流动估计不足，复用力度不够，给项目的进度管理带来了一定的困难。在以后的项目中，我们把限制人员流动率将作为一项合同约束。

正文

20xx年10月，我参加了XX市农村信用联社综合业务信息系统（以下简称xx系统）的 分析和开发，该系统由残联社与乙集团公司联合开发，系统采用C/S体系结构，主机采用两 台IBM RISC/6000 S杀列机，操作系统为IBM的AIX4.3.3，数据库选用IBM的DB2 UDB 6.1，

磁盘阵列选用IBht的7133 SSA串行存储体系结构，前台为SCO UNIX 5.0.5，中间件采用IBM Txseries CICS，编程语言采用SQL和C。

xx系统面向交易、以客户为中心、采用大会计模式，以县级联社为单位设立一个帐务系统，改变原来的储蓄、对公等总帐分开的做法，并以会计核算为核心，把整个帐务系统融合在一起，实现本外币合一，将柜员管理与柜面业务有机地结合起来，以业务种类码来划分整个业务系统，打破传统的业务品种和业务部门的界限。

XX系统分两期实现，第一期为期14个月，已于20xx年年底完成并投入运行，主要完成农村信用社柜面业务，包括储蓄（对私）、对公、信贷、系统内电子联行、通存通兑、与人行的天地对接、中间业务等；目前系统内共设机构87个，柜组415个，业务操作员三千余名。第二期为期一年，尚在开发中，主要为卡业务（包括与人行的一卡通、自办农信卡业务等）及客户自助业务（包括ATM、电话银行、网上银行等）。

在XX项目中，作为联合开发的甲方主要代表，我担任项目的可行性分析、需求分析、概要设计和一期项目酌项目管理，跨地区通存通兑接口模块的详细设计与实现等工作。 软件开发项目进度管理是软件开发项目管理的一个重要内容，有效的进度管理是保证软 件开发项目如期完成的重要环节。在XX -期项目软件的开发过程中，为保证软件按时完成， 我采用PERT计划评审技术及一系列的方法和策略。

1、采用PERT计划评审技沭枥话9镏炸肖}

采用PERT计划评审技术标识关德任务。XX项目计划中规定了一期项目的的交付期限为 20xx年年底。整个一期项目长达14个月。在一期项目的开发过程中，采用的是“改进型瀑 布模型”，我们从可行性分析结果出发，使用快速原型方法来补充和完善需求说明，还对信贷部分的需求进一步细化。从设计阶段起的各阶段基本采用了传统的开发方法，各阶段的结束标志比较明显。所以在软件的开发过程中，我采用了PERT计划评审技术对开发过程中的各关键任务加以标识，允许关键任务以外的其他任务在机动期内伸缩。而关键任务的伸缩不得超过一周。当遇到关键任务延期时，我召集大家寻找原因，并由主要责任人签字。把这种责任作为业绩考核的一部分与收入挂钩。

在标识关键任务的同时，根据PERT图，允许某些任务的并行。在概要设计阶完成并通过评审后，允许爸子系统在详细设计阶段及实现阶段任务上的并行进行。我把系统划分成储蓄对公、信贷、联行三个子系统，在概要设计阶段的任务一完成，就将开发人员分成三个小组，分别进行上述三个子系统的详细设计与实现。实现了在这两个阶段上任务的并行，也确保了项目的如期完成。

2、着重奠琅已U是在耋所嗵题目开泼变疆己中的安掉

着重考虑人员在整个项目开发过程中的安排。我从各具联社抽调业务骨干，作为业务分 析人员，提出并确认需求。考虑到本项目完成后的维护需要，在乙方开发人员大部分撤离后， 维护任务将主要由莪社一方承担，所以从概要设计阶段开始，我方派出了三名高级程序员， 分别参与储蓄对公、信贷、联行子系统的设计，继而参与详细设计、编码实现，也为后来的 维护作准备。

3、谒抄川踢己U是之间的通词暇嚼，捏蔼湛乎嗵匪

、减少开发人员之间的通讯障碍，提高生产率为了确保项目的如期完成，我们事先规定了文档编写规范、命名规范，重视文档的编写、保管等工作。重视文档与设计的一致性，先修改文档，再修改程序，不至于因为文档与设计的不一致而影响工期，对跨越里程碑的文档修改设置严格评审。为了减少开发人员之间的通讯障碍，还启用了Notes系统，开发人员可以通过内部Mail避行交流，及时沟通，减少误解。

4、跟昔钢控崩颐目计划的执行

跟踪和控制项目计划的执行。为确保本项目的如期完成，在项目开始后，我们定期召开

各组长会议，让组长们报告各自小组的进展情况及遇到的问题。通过交流开发过程中遇到的 问题，共同探讨解决方法。我对照计划，跟踪实际执行情况，如果项目进展顺利，在预算范 围内，我会适当放松一些控制；但只要一有问题，我会尽可能帮助排解。例如，在编码及单 元测试时，因为时间比较紧，尤其信贷组，按揭贷款和跨社多头贷款控制的编码过程中遇到 些阻挠，测试也不够充分，加之个别人员流动，我只好调整计划，适当调整人员，还让信贷 组开发人员加斑加点。有时我也找个别开发人员交谈，以了解他们对开发进展情况的评价， 以及他们个人遇到的一些问题。尽我所能帮他们解、央问题。

在本项目的开发过程中，所有由于以上采取了以上的技术和方法，在很大程度上保证了 项目的如期交付（一期项目按计划已于20xx年年底交付并投入运行）。其中采用PERI'计划评

审技术，标识各阶段的关键任务，允许一些任务的并行执行是比较成功的，划分的储蓄对公、 信贷、联行三个组在详细设计与编码阶段的并行执行，缩短了整个项目的开发周期。重祝文 档的编写，效果也比较好，内部Notes的启用减少了通讯障碍，提高了生产率。安排本系统 员工的积极参与也是成功的一面，参与过需求分析和确认测试的我方人员在系统上点过程中 对培训辅导帮助很大，而参与概要设计起各阶段任务的三名高级程序员更为系统投入运行后 的维护提供了方便。一方面，这些人员参与了从概要设计阶段起的各个阶段，熟悉了整个的 实现过程；另一方面，这些员工熟悉业务，在后来的改正性、完善性维护方面起了很大的作 用。

但是对人员的流动把握不足，尤其对乙方人员的流动更显得无可奈何。很大程度上帝走 了经验，也影响了进度。同时，也没有充分考虑到本系统内参与设计人员的流动。项目初期， 本想增加候补人员的，但考虑到那样做还得培训，同时也增加通讯、交流的时间，担心反而 会影响进度，所以未安排充分的候补人员。致使人员离去时只好再作调整，显得有些被动。 所以对于人员的流动，现已作为一项约束，限制人员流动率不得高于某个百分点而在二期的 开发合同中明确规定，相信会带来好处。

另外，在项目设计过程中未充分考虑代码的复用，复用程度比较低，三个组间复用的只 是本项目公用的如记帐部分等，还有就是各自组内的代码积蓄了。开发效率比较低，也正困 如此，不但延长了编码时间，而且还必须加强测试。如果能加大复用力度，在保证项目的进 彦和系统的庸量方而会事弃善甚。

论软件过程的改进

摘要

20xx年8月，我参加了公司一个对原有产品进行升级的项目，担任项目经理一职。这个项目是在原有的产品上进行升级，系统架构由二层改为三层，并在功能上对原有系统进行扩充。同时考虑到以前我们做开发时，软件过程不规范，原有系统在设计、开发、维护、实施上存在一些弊端，开发出来的软件总存在这样那样的问题。我们在这个项目进行过程中，对软件过程进行了改进。以前我们做开发时，软件过程不规范，开发出来的软件总存在这样那样的问题，在这个项目里，我们努力做好项目规划、加强版本控制，采取了一些质量控制手段，如同行评审、专家评审、加强测试等，使软件的质量得到保证，同时也降低了开发成本。现在看来，这个项目在一定程度上是取得了成功，但还是存在一些问题，如采用工具方面，过程改进制度化方面，过程标准化与工程进度方面的矛盾等部有不如意的地方，后来公司部对这些问题有所认识，也在不断地进行改进，公司的软件过程已日渐成熟，并于去年顺利地通过了CMM3认证。

正文

软件过程的改进是一项需要长期不断地进行下去的工作。以我们公司来说，做为一家软 件公司，过去对软件的开发过程并不重视，接到项目后首先考虑的是如何用尽量短的时闾来 完成，而忽略了软件的质量，结果也往往是欲速则不达，甚至因为产品的不成熟使工期一拖 再拖。

在20xx年8月，我们要对公司原有的《城镇职工基本医疗保险》产品进行升级。这个产品是为了配合国家的公费医疗制改革，由公费医疗改为基本医疗保险而开发的。产品由各地劳动部门下属的医疗保险管理中心组织建设，中心机房设在医保中心，通过城域网连接到各定点医疗机构（医院和药店），参保职工可持医保卡在定点医疗机构直接消费，由医疗机构关病人垫付费用，事后再与医保中心结算。原产品为两层C/S结构，各定点医疗机构的前台关脱机消费，定时传送数据。这次产品升级首先将系统架构由原来的两层c／S升级为三层c/s，中间层采用比较流行的Weblogic或SilverStreajn做应用服务器，用J2EE实现业务逻辑，并采用标准的程序接口与各前台程序连接，以方便与第三方软件与我们的系统集成。网络传输也由原来的定时传送改为实时连接，软件功能上也需要突破由于原产品设计时没考虑周全而带来的限制，如原系统为实现脱机消费，采用了IC卡帝金方式，但系统设计时没有考虑到IC卡本身可能存在质量问题，而经常发生医保个人帐户透支问题，在新系统中我们就栗用了个人帐户在医保中心统一管理，IC卡只是作为一个身份识别的工具来解决这个问题。因此在项目起动时，对这个产品的定位就是一个全新的产品，而不是对原有产品进行修改。在这个项目里，我担任了项目经理一职。

1、做好项目规划

在项目的规划阶段，我们意识到公司原有的软件过程存在很大的弊端，首先，原来的软 件过程中，设计与开发职责不分，甚至存在分析、设计、开发、测试全由一个人承担的做法， 这样做不但是对人力资源的浪费，同时软件质量也得不到保证。开发和测试由一人承担，不 利于测试出软件中存在的错误，整个过程由一个人来做，做出来的软件究竟对不对，没有一 个说法，只有到最后程序拿给用户去用时问题才能暴露出来。再者在这样的过程中，开发人 员往往会忽略文档的重要性，这对后期的维护也会带来一些问题。针对这一点，裁们首先将 项目组分为设计、开发、测试三个组，设计和开发组由系统总设计师负责，测试组有一个专 门的组长。设计组负责软件的分析和设计，形成设计文档，设计文档首先要做同行评审，评 审内容一般是文档的规范性以及对开发人员的指导性方面，同行评审后由系统总设计师来做 专家评审，评审的内容是设计是否符合业务需求。开发组负责根据设计人员的役计文档编写 出代码，代码编写出来后要通过同行评审，评审内容是代码的编写是否符合编码规范、是否 具有可读性和可维护性。测试组负责根据需求和设计文档编写测试用例，并对开发出来的代 码进行测试。通过这样的改进，我们充分调动了各员工的积极性，也明确了各自的责任，使 得整个过程处于受控状态。

2、加强版本控制

在原来的软件过程中，我们对软件的版本控制不严密，没有采用必要的工具，而是完全 由版本控制员手工进行操作，且版本控制员还要兼一部分开发任务。在这种情况下，版本控 制经常出问题，有时同一代码被不同的人员同时修改，有时将本应发给甲用户的程序发给了 乙用户，又或者开发人员自以为自己手上的代码是最新的，而出现已改过的BUG又重复出现的现象。这样做的另一个问题是版本的历史很难追踪，由什么人在什么时候做了什么样的修改完全没法掌握。在这个项目里，我们意识到这一点，首先，设立了专门的版本控制人员， 同时使用了ClearCase版本控制软件，所有对文档和代码的修改必须先从版本控制服务器上 Check Out，改完后再Check In。这样做就杜绝了版本的覆盖问题，而且版本历史也是一目 了然，任何修改都会形成日志，这也为问题责任的追究提洪了依据。

3、加强测试．工作

在这个项目里，我们特别加强了测试人员的作用。在这之前，公司也设立过测试部，但 由于存在部门之间的沟通问题，测试部很难参与到项目中来，即使参与进来也发挥不了应有 的作用，测试部曾一度被徽消。这一次参与测试的是新成立的测试部，而测试人员加入到项 目组，业务上测试组是受项目经理领导，人事上仍受测试部领导并考核。这样做，首先消除 了测试与开发之间的沟通隔阂，而测试人员也少了其他项目的打扰，可以专心只为一个项目 做测试。而以前出现的因部门间隔不让测试人员参与直接由开发人员自己测试的情况也就不 存在了。

由于以前的软件过程存成那么多的问题，使我们的产品不是一个成熟的产品，不成熟的 产品后期施工的成本是很高的，因为存在太多的问题，维护人员要做大量的维护，而前期开 发并没有瞽下什么文档，也给后期的维护带来很多困难，维护人员每修改一段代码首先需要 读懂原来的程序，往往读不懂时就直接在原来的程序上加上一段通过设置条件来跳过原来的 代码，这样使得程序越来越难读懂，问题也越改越多。这样的产品拿到一个点去施工时往往 需要二个月甚至更长的时间。在这次的升级中，由于采用了较好的软件过程，产品的成熟度 得到了很大的捏高，而设计文档也是我们这一次重点控制的对象。这样的产品为后期的施工 提供了很好的条件，现在，产品在一个点的实施时间可以缩短到四十天以内，大大地减少了 施工成本。

而好的设计文档也为产品的本地化修改提供了好的条件，维护人员读懂设计文档比读懂 程序要容易得多，在这样的基础上做修改出现的问题也越来越少。

尽管在这个项目里我们做了这么多的改进，但也存在不少的问题，首先我们使用的 ClearCase版本控制软件存在问题，这个软件要求所有开发人员将自己的机器加入到由服务 器控制的域里，否则，就只能取到版本快照而不能进行版本更新。由于这样做，域管理员具 有比本机超级用户更高的权力来控制每台机器，使得开发人员不愿意这样做，于是出现了多 人用服务器超级用户远程控制服务器来取版本的现象，使得版本的责任追究出现问题。而我 们使用的ClearCase版本不支持WindoWs XP，也使这个版本控制软件的使用出现了问题。 另外，我们的软件过程制度化方面也没做好，在项目的早期，各项工作流程都被很好的 执行，各种文档也非常完整。由于我们这一次的升级只是针对的整个产品的一个部分进行的， 在这之后我们又对这个产品进行了一次更大的升级，使得我们的户品能覆盖更大的范围。但 后面的这次升级由于规模比这一次大，人员也大量的增加了。而新加入进来的人员并没有很 好地进行规范培训，好的软件过程标准也没有形成有效的制度，再加上项目工期非常紧，包 括同行评审、专家评审这样的流程部开始有些流于形式甚至被忽略。开发组编码时也没有完 全按制定的规范进行。因此，产品质量上就出来了一些反复。我们这个产品是个可分可合的 产品。因些在后来的产品实施上出现了这样一种情况：如果一个点只实施前一次升级的那部 分，施工难度很小，能在短期内完工，本地化开发工作也很好完成。而要全面实施整个产品 的话，工期就会被拖得很长，本地化开发工作也存在很大的问题。

针对出现的这种情况，我们公司意识到了软件过程改进的重要性，针对版本控制软件问 题，我们改用了功能虽然没有ClearCase强，但更适合于我们的VSS。而在制度化方面，更 是下了大力气，从印度请来了专家为我们的改进做参谋，现在公司的情况已有很大改观，各 项制度已不再流于形式，而公司更是在并在去年年底顺利地通过了CIIM3的认证。软件过程改进的路还很长，但有一点是不变的，只有通过软件过程的改进，我们的产品才能不断地走向成熟。巾，只有产品成熟了，戮们才智匕I在音争中永沅寺干不败夕批。

应用CMM改进银行软件过程

摘要

我在某银行软件开发科室工作，长期从事商业银行中间业务应用的开发。在以往的中间 业务产品开发过程中，存在许需求不明确；开发人员有章不循，依靠个人智慧，开发处于低 水平的重复状态；项目的进度、质量难以保证等问题。

我们从20xx年底开始着手解决中间业务产品的整合和综合发展问题，经过项目分析和论证，我们提出了要开发一套具有良好扩展性、通用的中间业务平台系统。为了避免在新平台的开发过程中继续出现上述问题，作为该项目的主要负责人，我在中间业务开发团队引入CMM，采取了一些有效的策略和方法，主要包括：进行CMM培训和咨询工作；重新制定中间业务开发规范；做好需求管理；加强过程的跟踪和监督等。我们成功实施了银行中间业务软件过程的改进，开发了高质量的中间业务平台。CJrtM是全面持续的过程改进，笔者从定量过程管理和人员组织管理方面，提出了今后的努力方向。

正文

中间业务是指银行利用自己的网点、设备、网络、信息等优势，以中间人的身份接受客 户委托，提供各类金融服务并收取相应手续费的业务。作为银行业务新的利润增长点及重要 的吸收存款手段，中间业务正日益受到国内各商业银行的重视。近年来，我所茌银行根据业 务发展的需要，通过陆续推出代发工资、代收电话费、代收水电费、代收学费、行政事业代 收费等一系列代收代付的中间业务，在提高自身服务水平的同时，增强了在同业中的竞争能 力。

一、中间业务开发过程中存在的问题

随着中间业务品种的增多和市场对中间业务要求的提高，中间业务系统越来越庞大与复 杂，尽管我们中间业务开发团队不乏技术过硬的开发人员，还是经常出现项目不能按时完成； 新的中间业务项目上线时，软件质量不理想，其中包括一些明显的错误，如客户不能交费、 重复扣或少扣客户的费用，客户交费后打印不了#5@p等；而且文档不齐全，造成维护比较困 难。作为中间业务开发团队的主要负责人，我召集了几名技术骨干总结了以往的经验教训， 找出了存在的一些主要问题：

1、随意性、央策较多。往往软件产品从立项阶段开始就成了“实验田”一一软件产品做与不做，什么时候交付等多是凭个人的主观意愿，没有参考以往经验，也没有充分考虑资源的有效投入，导致开发的产品维护成本较高，“打补丁刀现象较多，用户使用不方便。

2、有章不循。尽管我们科技部门比较注重规章制度的建设，也针对软件开发过程制定了大量的程序性文件，但由于没有严格的后续跟踪与监督机制，使较件开发的质量控制大打折手口。

3、依赖个人智慧。我们开发团队中不乏一些具有相当才干的项目经理和骨干人员，他们为研发银行软件产品做出了较大贡献。然而，由于他们的经验没有被很好地总结、归纳，并上升为整个开发团队的财富，致使有的项目负责人一走，开发质量就会下降，这说明软件产品的研发依赖于个人而不是整个开发团队。

4、“可视性刀低。软件开发过程不透明，上级不了解下面在做什么，无法实时监控项目 进展；下面的开发人员“报喜不报忧刀。由此导致产品缺陷被慢慢积累起来，等看到结果为时已晚。

二、应用(lI改进中间业务平台开发过程

由于传统的中间业务系统产品开发平台多样化、缺少统一规范、产品分敌、功能不足， 大大影响了开发效率和增加了维护难度。为解决传统中间业务开发模式存在的诸多弊端，我

们从20xx年底开始着手解决中间业务产品的整合和综合发展问题，经过项目分析和论证，我们提出了要开发一套具有良好扩展性、通用的中间业务平台系统。为了避免在新平台的开发过程中继续出现上述问题，作为该项目的主要负责人，我考虑在中间业务开发团队引入CM M，试图把个人的脑力劳动规范为有纪律的智力产品。

1、培训与开发过程规范的制定

在项目启动前，莪们请了一家知名的培训机构，培训了CMM的基础理论，并结合一些软件开发公司实施CMht的案例讲解，促进了团队成员对CJolt的认识和对软件过程实行规范管理的理解和支持。

然后，我们分析开发部已有的规章制度存在的问题和缺陷，重新制定了中间业务开发规 范。

首先定义出软件开发中的主要过程，参考CMM并针对中间业务开发的实际需要，确定了每个过程的具俸工作内容。

其次确定了软件开发的具体方法，我们确立了面向对象的开发方法，并对每个开发过程 定义了相应的具体文档，如系统计划阶段必须提交《系统开发计划》，需求分析阶段必须提交

《软件需求规格说明书》。并定义了文档的格式和必须提交的内容。

最后，对每个过程划分相应的人员职责，即按照工作要求，进行人员分工，并确定具体 的工作内容。

2、努力做好需求管理

在银行的软件研发过程中，需求管理是一个“老大难刀问题。技术部门抱怨业务部门提 出的需求不清晰，甚至提不出需求；业务部门抱怨技术部门对需求理解有偏差，开发的产品 与初衷相去甚远。从CMM的角度来说，业务部门提出的需求只是顾客需求，而在顾客需求 中既有技术层面，也有非技术层面的，即便是技术层面的需求，也并非面面俱到都要开发， 比如一些按术上不可行或者资源要求不能满足的需求就必须剔除。只有适合软件产品研发的 需求才会被最终制作成规格说明。

在中间业务平台需求的制定过程中，我采取了以下措施：

(1)组成业务部门与技术部门共同参与的需求组，需求提出后经过上级领导的评审和业 务部门确认才实施开发。

(2)制定技术部门必须和业务部门商定需求变更流程和跟踪监督的机制，需求变更如何 提出、由谁进行评审、由谁决定做与不做、对项目进度及对资源的影响如何等部应事先考虑。

3、加强过程的跟踪和监控

软件开发过程中，我们按照软件开发过程规范严格实施。在项目启动的初期，开发人员 要花很大一部分时间写文档资料，工作压力比以前大多了，工作流程的改变，也导致一段时 间内效率降低。大家逐渐习惯后，感觉文档是研发人员劳动成果最好的记录，工作比以前清 晰，规范的文档减少了对某个人的依赖，使软件研发过程的上下环节紧密衔接。在整个过程 中，我们得到所有的文档，并根据文档的内容对每个过程进行了检查。在进度控制方面，裁 首先制定了系统开发计划，要求开发人员填写工作量周报，并据此绘制项目进度图，随时了 解项目进展，并适当调配人手，整个项目比计划略早完成。

在质量保证方面，银行软件产品质量对业努的开展尤为重要，它涉及银行的资金安全和 自身信誉，因此必须确保软件开发产品质量。现在我国各银行并没有成立单独的质量保证机 构，对质量的控制主要掌握在项目研发人员手中，为此CMM建议成立专门的SQA组，检 查软件开发过程标准、规程的合理性。鉴于人手问题，我们没有成立专门的SQA小组，采用测试小组兼做SQA工作，对项目组的监督“对事不对人”，并定期公布监督结果。

三、经验和不足之处

经过近一年工作，我们完成了中间业务平台的开发，新的中间业务平台运行良好，受到 了业务部门和技术部门高层的赞许。在该项目的开发中，由于引进了CMM，加强了软件过程管理，很好地解决了以前存在的四个问题。中间业务产品的开发目标更明确，提高了产品开发过程的可视性和可控性，从而在提高产品开发能力的同时提高了产品的质量；我的开发管理水平也得到了很大的提升。高层领导尤其对我们的开发流程和开发规范表示认可，并、央定在整个开发部门推广。我将这次软件过程改进的成功实践归功于两个原因：一是基于我们长期中间业务开发的基础上总结出来的经验和数训，二是CMM原则与我们团队和项目本身的特点的有效结合。

然而，由于我们初次应用CJrtM，还有许多需要改进酌地方：

1、我们仅运用了CMM的基本原则，整个软件过程的管理基本是定性的。过程改进的趋势是定量管理，必须采用合适的工具，如采用项目管理工具JitS PROJECT控制项目进度，使用RATIONAL ROSE对需求分析和系统设计进行辅助设计，可预测和监控整个过程性能和产品质量，及时纠正偏差。

2、鉴于人手的问题，我们团队成员往往身兼设计、开发、测试、SQA数职，组织结构不合理、人员分工不清显然制约过程改进的实施，我们最近打算成立一个独立于开发部的质量控制部，分清设计、测试和质量保证的责任、界限和权限，使其在更高的层次上控制软件质量。

软件过程的改进是一个很大的澡题和实践方向，在今后的工作中，我们将争取向CMh'l更富的孵驯躯巾一

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

摘要

我校教务管理系统是在根据我校原来的教务管理系统不再适应现在发展的要求而立项开

发的。目的是为数务工作有关部门提供优质、高效的业务管理和事务处理，建立完备、可靠 和开放性的教务管理系统。

我有幸参加了新的教务管理系统的开发，担任项目管理、系统分析与设计等工作。本文 结合工作的实际经历，简要讨论了软件开发平台的选择与应用。在软件开发平台的选择与应 用过程中，我们本着平台的开放性、分布性和平台无关性的原则，根据我校的具体情况，通 过对目前两种主流平台：J2EE和．NET的比较分析，和俸系结构、应用平台的无缝集成、开发成本及易开发性的思考与研究，选择了．NET作为开发平台。使用Microsoft全新的集成开发环境Visual Studo．NET，采用ASP．NET、Web Service, ADO．NET和XML等技术进行系统开发。

正文

随着我校规模的不断扩大，计算机科学技术的进步，我校原来的教务管理系统已不适应 现在发展的要求。以前单机版的VFP教务管理软件，被分散的安装于全校的14个系部和教务

处，各系部之间、系部与教务处之间信息不能共享，而且对教学计划、教学考核等功能不完 善或根本下支持。教务处是学校主管教育教学工作的职能部门，也是学校领导在教学业务方面的参谋机构。教务工作直接影响学校教育教学改革和数育教学质量。因此，学校决定由教务处立项重新规划建设教务管理系统。整个系统包括教学计划子系统，教学资源子系统，网上选澡子系统，智能排澡子系统，教学考核子系统，学生学籍子系统，学生成绩子系统，教

学实践子系统，教材管理子系统等。

我有幸参加了新的教务管理系统的开发，担任项目管理、系统分析与设计等工作。 由于我校分南北两个校区，教务处和14个系部分布较敌，另外随着Internet的迅速发 展，部分信息需要通过网络向全校师生及外部用户发布，例如网上选澡信息、学生基本信息 及成绩等。基于传统的C/S模式体系可维护性和发布性差等原因难以满足新系统的要求，有 效的采用基于B/S体系的Web应用能很好地解决这方面的问题。

基于互联网的应用要求软件平台具有开放性、分布性和平台无关性。从而相继出现了RPC、COht和CORBA等技术，但这些技术在实际应用中存在着许多不足和局限．它们的特定协议难以通过防火墙，因而不适应于Web上的应用开发。为了进一步开发基于Web的应用，出现了Sun公司的J2EE和Microsoft岔司的．NET两种主流的软件开发平台。

在J2EE和．NET两者之间进行选择时，我们曾举棋不定。随着面向对象技术的兴起，Java 语言应用的迅速发展，以Java为程序设计语言的J2EE具有平台无关性。同时J2EE已成为 Web应用开发的标准平台。以及它的相关技术EJB、JSP、Java Servlet等的迅速发展，J2EE 平台已成为Java技术企业级应用的理想平台。但我校原有的大部分操作系统、数据库和Web 服务器都是采用J/ticrosoft的系列产品，并且在hticrosoft系列产品的使用和开发方面积累 了较丰富的经验。．NET支持多种程序设计语言如：C++．NET、VB．NET、ASP．NET、C#等，实现了语言互用性。而J2EE只能使用Java，这是J2EE所不及的。并且Visual Studo．NET使 得．NET的开发较J2EE的易用性好。

在最后具俸的软件开发平台与应用的技术方案选择时，我们采用了．NET开发平台。其原因主要基于对开发平台选择原则如下的认真思考和研究。

一、体系结构方面的考虑

随着Internet的迅速发展，传统的C/S体系结构已显示出了它在异构的、分布式的网绪 环境中的不足。可维护性和可安装性差、并且不利系统扩展。从而新的体系结构B/S模式迅 速发展了起来。B/S模式有利于系统的扩展性、维护性。

在校园网发展逐步完善的今天，考虑到教务管理系统安装、维护的方便和部分信息的向 外发布，以及传统的C/S模式技术的成熟性。我们采用了C/S和B/S相结合的模式。．NET开发平台正是为进一步开发基于Web的应用而出现的，是一组用于建立Web服务器应用程序和Windows桌面应用程序的软件组件。．NET支持多种编程语言，使各种语言可以自由地在整个．JIET平台内互用，很好的发挥各种语言的特性。例如：我们对c/s结构程序使用执行效率高的VCH．NET和快速开发的VB．NET，B/S结构程序使用．NET专门为Web应用定制的ASP．NET和C聋。再加上功能强大的Visual Studo．NET集成开发环境，．NET为C/S和B/S相结合的模式提供了很好的解决方案。

基于此原因，我们把系统的教学计划子系统，智能排澡子系统，教学考核子系统，教学 实践子系统，教材管理子系统等设计为c/s结构，网上选澡子系统，学生学籍子系统，学生 成绩子系统，教学资源子系统等设计为B/S结构。

二、应用平台的无缝集戚性

由于我校使用的操作系统都是Microsoft的Windows系列，同时．NET是与Windows操作系统紧密捆绑在一起，使得．NET在Windows上的应用开发更为容易。并且以前的数据库是VFF的。考虑到数据的平稳过渡以及我们对数据库的熟悉程度，再加上．NET提供的ADO．NEr数据访问组件是对ADO的改进，分为三组：ODBC、OleDB、SqlClient。其中SqlClient是专门为SQL Server设计的，性能明显优于其它的数据访问组件。我们在新系统的后台数据库服务器的选择上采用了hticrosoft soL Server2000。

选择Microsoft的操作系统Windows，数据库服务器SQL Server2000和开发平台．NEr应用平台，充分利用无缝集成平台的优势，使．NET应用开发更容易，运行更可靠、更安全。

这是J2EE所不及的。

三、节约开发．威本

由于我校在以前的信息化建设过程中培养了一批经验较丰富的C+l-、VB、ASP等开发人员，熟悉Windows上的开发，同时在数据库管理系统Microsoft soL Serv-上的设计与开发方面有一定的经验。而在Java丹发方面的经验相对不足。如果我们选择J2EE则意昧着开发人员资源的浪费，并且要重新培养Java开发人员，并且新培养的开发人员由于缺乏经验，很难保证开发效率和质量。选择．NET，则我们的开发人员便能轻松的转变到C++．NET、VB．NET、ASP．NET及C聋的开发当中来。再加上以前在Windows上的开发经验，最终有利于我们的开发速度加快质量提高，从而很好的节约了开发成本。

四、易开发性

就．NET开发平台的容易使用性来看，在如下几点得到了很好的体现。

1．．NET的重要部件ASP．NET使Web应用程序的开发和部署更为容易。．NET相对较新，它拥有Java所缺乏的改进，例如，ASP．NEr使开发者可以用比Java开发者在J2EE平台上更少的代码来实现Web Servlces。在教务管理系统中，我们对学生成绩查询、学生网上选澡和教学资源调配等交互较多的逻辑模块，部设计成Web servlce结构的中间组件。轻松的节省了花在用户界面编程上的开发时间、同时Web servlce完全可以在应用程序集成等场合下被重用。

2．ADO．NET数据访问组件较以前的ADO更方便的访问各种类型的关系数据库和非美系数据库，获取本地和远程数据源，并对XML提供了强大的支持。这对以后的后台数据库的扩展也提供了很好的支持。

3．Visual Studio．NET为．NET提供了一个统一的集成开发环境及工具，大大提高了开 发者的效率j集成了多种语言支持j简化了服务器端的开发；提供了高效地创建和使用网络 服务的方法等等。

通过对上述四个主要方面的思考，所以我们选择了．NET平台作为开发与应用。

目前软件开发平台主要向Web的应用方向发展。由于Web的应用是基于分布和异构的网络环境的，所以要求开发平台应具有开放性、分布性和平台无关性。现在流行的软件开发平台主要有Microsoft的．NET和Sun的J2EE。在实际应用当中，我们具体选择那种方案应根据具体情况而定，很多情况可能会综合使用两种开发平台。在适应技术发展的过程中，快速的蹁卜薪桔术旱协骊的．

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

摘要

我所在的单位是国内主要的商业银行之一，作为单位的主要技术骨干，20xx年1月，我主持了远期结售汇系统的开发，该系统是我行综合业务系统XX2000的一个子系统，在选择IBM的VISUALAGE FOR JAVA作为软件开发平台的过程中，我主要遵循了保证与原有系统的互用性；保证开发人员快速而准确开发出应用程序；延长应用的生命力的原则。在选定了软件开发平台后，我还采用了三层c/s的软件体系结构；利用CICS的SWHITCH组技术；使用标准、开放的规范等措施，保证了远期结售汇系统的按计划完成并且顺利投产，确保了该系统的开放性、互用性、可用性、先进性和稳定性，特别是我所选用的VISUALAGE FOR JAVA开发平台和为了保证系统开放性和先进性所采用的措施得到了领导和同事的一致认同和称赞。目前，但是，我也看到了近期软件开发平台的主流是SUN公司的SUN ONE和MICROSOFT的．。NET两大阵形，我认为，而软件开发平台将朝着集成性、开放性、平台无关性的方向

发展。

正文

我所在的单位是国内主要的商业银行之一。众所周知，银行的业务存在一个< -八定理”： 即银行的百分之八十的利润昱由百分之二十的客户所创造。为了更好的服务大客户，适应我 国对外贸易的蓬勃发展态势，促进残国对外贸易的发展，20xx年1月，我行开展了远期结售汇业务。

所谓的远期结售汇就是企业在取得中国外汇管理局的批准后，根据对外贸易的合同等凭 证与银行制定合约，银行根据制定合约当天的外汇汇率，通过远期汇率公式，计算出交割当 天的外汇汇率，并在那天以该汇率进行成交的外汇买卖业务。远期结售汇系统是我行综合业 务系统XX2000的一个子系统，它主要包括了联机部分、批量部分、清算部分和通兑部分，具有协议管理、合约管理、报价管理、外汇敞口管理、帐务管理、数据拆分管理、报表管理、 业务缩微和事后监督等功能。

我作为单位的主要技术骨干之一，主持并参与了远期结售汇系统的项目计划，需求分析， 设计，编码和测试阶段的工作。在选择使用VISUALAGE FOR JAVA作为软件开发平台的过程中

我主要采用了以下几个原则：

1、保证与原有系统的互用操作性和兼容性。由于远期结售汇是我行综合业务系统的一个子系统，必须保证与原有业务系统的互用性，以确保我行业务的正常开展。我行以前的联机系统一直都是使用IBM的VISUALGEN 2．O来开发的，编译后生成COBOL裎序，由于COBOL特别适合用来表示商业逻辑，所以在我行的联机系统取得了很大的应用。我主要选择使用 VISUALAGE FOR JAVA开发平台的VISUALGEN部分的功能，程序编译后也是生成COBOL程序， 确保了与原有系统的互操作用性和兼容性。这样，以前开发的应用程序可以不经过任何修改， 方便快捷地移植到VISUALAGE FOR JAVA开发平台上，这样既保护了以前的投资，又消除了因为移植而可能导致的错误，为我行的安全生产打下了良好的基础。

2、保证开发人员快速而准确开发应用程序。首先，VISUALGEN 2.0是我行一直使用的开 发平台，外汇部的开发人员能够用它快速而准确地开发出联机系统的应用程序，而VISUALAGEFOR JAVA的VISUALGEN部分和VISUALGEN 2．O只有很小的区别，只要进行很短时间的简单培训，开发人员便可以快速而准确地得开发应用程序；其次，VISUALGEN 2．O只支持IBM的OS/2操作系统，而大部分的文档，办公软件和NOTES等部是安装在WINDOWS操作系统之上的，这样开发程序的时候需要在两个操作系统之间不断地切换，不但浪费了开发人员的时间，降低开炭效率，还给开发工作带来了很多的不便，容易造成错误，比如开发人员在开发的过程中需要对照详细设计文档的时候，需要切换到WINDOWS操作系统，当数据比较多的时候，切换的次数也多，这样便浪费了开发时间，容易造成错误。而VISUALAGE FOR JAVA则支持WINDOWS操作系统，大大地方便了开发人员，提高了开发效率，减少了开发错误，得到了领导和开发人员的一致好评。最后，VISUALAGE FOR JAVA集成了很多软件管理的技术，增强了对项目的管理，比如它支持团队开发，良好的团队开发管理为外汇部的开发工作带来了很大的方便，使得各个部分有条不紊地进行。又比如它良好的版本管理功能，使得开发工作可以更加高效而准确地进行，极大地支持了开发工作的顺利进行。

在选定了VISUALAGE FOR JAVA作为远期结售汇系统的开发平台之后，我还采用了以下几个措施来保证系统的开放性和先进性：

1、采用三层的c/s软件体系结构。根据银行联机系统对开放性、可用性和伸缩性的要求特别高的特点，我采用了三层C/S软件体系结构，三层C/S软件体系结构是目前比较先进和流行的软件体系结构，按照它所建立的分布式应用系统有很好的开放性、可月性、伸缩性和互用操作性，很好地适应了银行应用系统的特点，其中：表示层我采用了我行自行研发的

CITE字符终端，由于字符终端在运行速递上比图形终端更快，很好地适应了我行对联机系统高速的要求；中间层我采用了IBM的CICS IRANSATION SERVER（以下简称CTS），用来连接CITE和数据层，这样做的好处是屏蔽了通信，安全，线程管理等最重要而又最耗时的功能开发，使得开发人员可以专注于应用逻辑的开发，缩短了开发周期，减少了开发，维护和集成费用，增加了开发的成功率，极大地增强了系统的开放性，互用性和安全性；数据层采用了IBM的DB2 UDB7.1数据库，它的数据库连接池、，方便快捷的索引等众多的技术能很好地适应了强调吞吐量和速度的银行系统。

2、利用CICS的SWITCH组技术。我行今年实现数据集中，全国设了南北两个数据中心， 分别位于XX和XXYY两地，而两个数据中心的数据传输显得尤其重要。比如我行的外汇报价 管理采用总行集中统一报价，各个地区再根据各自的业务量大小设置相应的优惠点数来进行 远期结售汇的外汇买卖。由于总行在北方中心，这样就涉及到两个数据中心通信的问题，为 了实现两个数据中心通信的负栽均衡和容错，我采用了CICS的SWHITCH组技术，所谓的CICS 的SWHITCH组技术就是在南北中心之间架设一组的CICS IRANSATION SERVERCTS，每个CICS TRANSATION SERVERCTS都是相同的，起到了连接南北中心的作用，消除了单点故障。该SWHITCH组不但具有开放性：每个CICS TRANSATION SERVERCTS与具体的应用逻辑无关，意昧着所有的应用逻辑也可以其有该SWHITCH组。，而且具有先进性。：为了简化系统的设计，缩短通信时间，我采用了简单的负载均衡算法，比如这次分配给第N个CICS PIRANSATION SERVERCTS，下故则分配给第N+1个；为了实现更好的容错，我采用了当某个CICS TRANSATION SERVERCTS失效的时候，把它正在处理的事务转到另一个CICS TRANSATION SERVERCTS，大大增强了系统的可用性。

3、使用标准、开放的规范。每个公司为了提高自己的竞争力，部有自己专用的标准和规范，IBM公司也不例外，为了保证系统的开放性，我采取了一些与规范有关的措施：比如在开发的过程中我要求开发人员尽量使用标准的soL浯句，以增加系统开放性；使用标准的通信协议TCP/IP，以确保与其他子系统的通信。

由于采用了VISUALAGE FOR JAVA开发平台和以上保证系统措施开放性和先进性的措施， 远期结售汇系统最后按照计划完成并顺利投产，不但取得了良好的社会效益和经济效益，而 且我选用的开发平台和采取的措施得到了领导和同事的认同和称赞。

在总结经验和不断学习新技术的同时，我也看到了近期软件开发平台的发展趋势和主要 特点：近期的软件开发平台朝着集成性、开放性、分布性和平台无关性发展，主流软件开发 平台是SUN公司的SUN ONE和htICRO SOFT公司的。．NFr开发平台，并有两强并立之势。结合我行综合业务系统的特点在充分分析比较了两个平台的优点缺点之后我发现：SUN的SUN ONE开放平台最大的优点是操作系统的可移植性，对于我行UNIX、OS/390和WINDOWS操作系统其存的局面非常有利；缺点是只能用JAVA来开发程序，而JAVA对于商业逻辑的开发并不如COBOL那样简单易用，而且我联机系统大多数部是用COBOL语言来开发或编译成COBOL程序，不能保护原有的投资；MICROSOFT的。．NET的优点是开发、运行程席的成本更低，由于。．NFr的语言是完全中性的，所以可以使用COBOL程序来编程，保护了原有的投资，伸缩能力更强，互操作用性更强，这些特性对于我行系统部特别重要；缺点是只能在WINDOWS操作系统下运行，对于我行多操作系统并存的局面又很不利。为了适应软件开发平台的演变，我将在以后工作中不断地加强学习，了解、掌握开发平台的知识，努力适应发展趋势，为我国的软件事

、II，罱赫白尸．的徽渣力量．

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

摘要

20xx年上半年，我作为某电子通信公司的软件开发人员，参与了一款基于嵌入式 linux - uclinux的手持式无线网络通信产品的软件开发工作。该产品提供为无线传输优化 的TCP/IP协议服务，具有自主组网、多跳路由的功能，集成语音通话、数据传输、实时图像传输等应用，可广泛应用于野外通讯、数据采集等领域。在项目之始，我们根据综合考虑性能、功能、技术可行性以及成本效益的原则，确定了以uclinux为软件开发平台，并在其应用过程中，通过积极参与开源运动，解决了不少技术难题，保持了系统的先进和稳定性。在此过程中，我作为项目的软件设计和实现人员之一，参与了选择软件平台的决策过程以及之后的具俸应用。

正文

我们说沙滩上建不起摩天大厦，这是强调地基对于建筑物的重要性，在软件开发过程中， 开发平台的作用就和地基类似，它对软件的性能、功能、质量、稳定性和可扩展性部有至关 重要的影响。因此，选择和应用合适的软件开发平台，是每个软件开发组织要面临的挑战之

一。作为一个嵌入式软件设计开发人员，20xx年，我参与了一款手持式无线网络通信产品项目（下面简称无线项目）的研发工作，同样也经历了一次这祥的挑战。

由于嵌入式软件和硬件平台的密切关系，有必要先简单介绍一下无线项目的硬件情况， 由于有大量音频、视频编码运算，主处理器是美国Analog Device公司（下简称AD公司）的一款DSP+RISC架构的数字信号处理器BF-21533，外扩32M SDRAM+16M Flash，外围器件有 彩色LCD，键盘，音频、视频以及射频芯片等。相应的软件方面涉及到从底层硬件驱动、开 发平台移植、核心路由模块到顶层应用等多层次的开发工作，不仅系统功能复杂，而且其中 有一些实时的应用需求，在性能上也有较高的要求，整个项目开发难度较大，因此我们希望 找到一个合适的软件开发平台，充分利用硬件资源，并且减少不必要的开发工作，使精力能 够集中到公司核心的业务上来。

我和另外一个软件设计人员经过和硬件设计人员的协商，初步拟定了三个候选方案，一 个是采用AD公司提供的Visual DSPH IDE，另一个是采用风河公司的Vxwor-ks，再有一个是 采用迅速发展的嵌入式linux - uclinux。对这三个方案，我们分析其优缺点，综合考虑功 能、性能、可行性以及成本效益，最终选定了第三种方案。

首先从功能方面看，这是残们重点考虑的方面。vlsual DSP++ IDE申集成的VDK功能最 弱，只提供了简单的任务调度功能，不支持界面显示和Flash文件系统，这意昧着我们要充 分发挥硬件的显示和存储功能，就必须自己在VDK上开发相应的功能模块，这必将带来大量的额外工作，使得我们不能集中精力在自己的优势上，从这一点上考虑，我们就首先将VDK置于淘汰之列。再看vxworks，Vxworks功能强大，稳定性高，风河公司在其基础上已经开发出各种板级支持包和大量的可复用的功能模块，开发者采用类似于构件编程的方式，可以快速开发出高质量的产品。我们初步估计了一下，如果采用基于Vxworks的平台上进行开发，不仅LCD显示和flash文件系统的开发工作可以省略，甚至如果采用通用音频、射频编码芯片，它们的驱动也不用开发，整个软件项目的进度可以加快不少，因此采用Vxworks方案无疑是蒲人的。最后看uclinux，它也有我们所需要的界面显示和文件系统等功能，但是缺乏来自平台供应商的技术支持，应用资源没Vxworks齐全，开发的工作量肯定要比Vxworks大一些，不过uclinux也具有yxyrorks所没有的优点，它是开放源代码的，可以对其源码进行局部惨改以适应所开发软件的需要，这一特点对于我们的核心多跳路由算法特别有用。从这些方面考虑，Vxworks和uclinux部各有千秋，不易取舍。

其故从性能方面来看。嵌入式系统对性能的评价主要从代码空间、数据空间、执行速度、 中断响应速度等方面进行考虑。在这方面，作为硬件厂商提供的嵌入式内核，VDK优势明显， 其内核体积小，所需内核代码、数据空间只有十几K字节，同时厂商对其实行的硬件优化， 使得响应速度快，实时性高；而uclinux和Vxworks所需的代码、数据空间是以兆字节来计 算的，执行和响应速度也不及VDK;如果uclinux和vxworr<s进行比较，Vxworks实时性要占 优一些，因其是专门的嵌入式抢占式内核，而uclinux只是通用linu<内核稍作修改而来的， 且为非抢占式。但由于无线项目的硬件平台性能较为强大，代码数据空间稍大和相应时间稍 长这些部不是特别棘手的问题，

再故从可行性方面考虑。由于VDK方案所需开发工作量太大，在项目规定的时间内难以完成，因此又一次首先被淘汰；Vxwork s同样也存在可行性问题，主要是我们采用的处理器BF-21533由于推出时间不长，Vxworks对其不支持．这意味着如果我们要使用采用Vxvrorks， 就必须重新选择处理器，这增加了硬件设计的工作量和修改的风险；相反，AD公司为发挥 BF-21533的强大性能，对uclinux进行了移植工作，并且推出了相应的toolchain编译工具， 这意昧着无需重新选择处理器也能进行uclinux平台上的开发，这一点促使我们开始倾向于 ucliunx平台。

最后从成本效益方面考虑。VDK和uclinux部是免费的，而VXWoiks作为商业软件，价 格不菲，除去开发工具的费用，它的按模块收费和形成产品后按件收费的特点使得不仅开发 费用较高，而且产品成本也会较高。这再一次将我们推向了uclinux平台。

综合上面四个方面的考虑，我们最终选择了uclinux开发平台。

在应用uclinux平台的过程中，我们充分利用linux的硬件平台无关的特点，将系统划 分成硬件相关和硬件无关两部分，硬件相关的比如移植工作和各种driver的开发则在具俸硬 件平台上开发，硬件无关的部分比如音频视频编码和路由算法则采取灵活的措施，先在 windows平台下开发测试，然后在装有相同linux版本的PC机上进行必要的移植修改。这样 做的目的是使得各部分较件可以并行开发，不至于受硬件方面的影响，同时也是针对linux 平台下开发工具和测试工具比较缺乏的弱点，充分利用公司在windows平台下的积累的工具资源，从而提高软件质量。

在保持系统的先进性和开放性方面，我们采取从哪里来，就到哪里去的方法，积极参与 开源运动，充分发挥开源运动的力量。

首先我们加入了uclinux网站上将uclinux移植到BF-21533处理器的项目组，不仅关注 和及时更新uclinux在BF-21533上的移植的最新版本、工具和补丁，而且在相关新闻组上通 过电子邮件的方式与来自全世界的开发者交流，讨论在开发中遇到的各种问题及解决方法， 通过这种方式，我们成功解决了一些棘手的问题比如系统的boot load，同时我们也将发现 的bug即时反映给AD公司和相关开源项目，帮助完善uclinux在BF-21533上的移植。

其次，我们将简化后的系统公开，在网上建立开源项目，发布硬件设计图和在其上移植 的uclinux内核、工具、部分硬件驱动以及相关指引，使得有兴趣的人可以组建和裁们类似 的平台，项目发布后的近一年中，收到了很多开发者的电子邮件，或者指出硬件设计上的瑕 疵和修改意见，或者指出某些躯动程序上的bug和设计不合理的地方，有的甚至将自己修改 后的系统设计图和相关驱动寄来供我们参考，通过这些热心人的帮助，我们发现了不少测试 时没有发现的bug，提高了软件质量，使得我们的uclinux平台日趋稳定，同时也对平台的 扩展也有了一些的想法和把握，这些部为我们将来在其基础上进行新的项目开发提供了有利 的条件。

目前，在嵌入式软件开发平台占主流的是以vxworks, wince为代表的商业产品，但以 linux为代表的开源运动也将这一潮流带到了嵌入式开发这一领域，显示了它的影响力，而 且影响力有越来越大的趋势，这种趋势的驱动力不仅来自linux内部，而且来自于外部厂商

的支持，linux 2.6已经正式支持不少嵌入式处理器，vxworks开发商风河公司也已经舍弃了 敌视linux的态度，转而和redhat公司合作开发嵌入式linux平台。相信未来在嵌入式开发 领域linux必将大有作为。

论软件开发平台的选择和应用

摘醒

本文从一个行业IKIS系统的开发实践，讨论了软件开发平台的选择和应用。首先，作者 从项目的实际情况确定了软件开发平台的一些原则：技术成熟兼一定先进性、高效集成的开 发工具、开方人员熟练掌握等，随后就系统平台、软件开发平台、数据库平台的选择作了详 细论述。之后，作者就开发过程中就保持系统开放性，对数据导入导出、与P3软件集成、WEB查看权限采取了相关措施；就保持系统先时性，提到了多种软件技术合成及VPN技术两项措施。最后，作者对近期商业应用软件开发平台的主流一微软的．net及J2ee进行了介绍，比较了其优缺点，对今后本部门在软件开发平台的发展方向作了一定的评估。 正文

我公司是大型电源建设项目的专业建设公司，曾以总承包方式承建设了多个电厂，在工程 建设过程中逐步建立了一系列完整、科学的工程管理体系，与此相应的是逐步建立电力建设 项目工程管理信息系统（简称电建MIS），原版本的不足之处是应用模块不多，且多以简单文本为主．

20xx年，浙江省某规模为4台60万千瓦机组的发电厂二期工程建设上马。该工程作为一 个大型能源投资项目，将有力地拉动地方经济的增长，并且将为浙江和华东地区的弪济和社 会发展提供强大的能源支持和保障。工程由多方共同出资建设，由我公司承担工程总承包建 设任务。借此工程建设的契机，我公司、央定重新开发电建JrtIS 3.0版。主要模块拟包括办公自动化、施工总平管理、合同管理、物资管理、质量管理、安全管理、图档管理、公用信息管理、综合查询（包括WEB查询）、系统维护，基本涉及我项目部的各个职能部门。 软件采用二层C/S与三层B/W/S相结合的方式。其中，B/W/S方式用于查询和浏览，C/S方式用于主要数据录入和维护，采用c/s和B/S结合的混合体系结构，较好地满足系统功能的需求，并符合可持续发展的原则，使系统有较好的开放性和易扩展性。

软件采用我公司和外部软件公司合作开发的形式，版权由我公司独家所有。因多种原因， 与我们合作开发的软件公司有2个。我是软件开发的负责人。

在开发平台的选择上，税们考虑了本MIS项目的特点：该项目要求在规定的时间（6个月） 内完成，并要求有较高的质量，且要为以后的进一步开发提供基础。

基于此，我们对选择开发平台的原则达成共识：

一、技术上成熟且具有一定的先进性；

一、有高效、集成的开发工具；

三、应为开发人员熟练掌握。

四、软件平台提供商对该软伴平台的后续支持能力。

首先，在系统平台的选择上，有两点考虑：1、公司现有的各级软件系统都是基于微软 Windows系列平台的，且公司没有在日后使用其它平台的打算；2、微软的Windows平台完全能满足开发、运行该类htIS系统的要求。因此确定新开发的MIS系统也就是基于此平台的。 对二层C/S在开发平台的选择，考虑采用微软的VB6.0或Sybase的Powerbuilder8.0。 前者是公司前两版MIS系统的开发平台，后者则更为现有的开发人员所熟悉。两者在开发上

技术部很成熟。在开发界面的亲和性上，VB做得较好；而对从数据库设计到编程的全过程而言，Povrerbuilder具有更好的集成性，用其集成工具Powerdesign设计的逻辑数据库可以很方便地生成物理数据库。从当时情况看，无论是微软，还是Sybase，对各自软件平台的后续支持能力都较好。最后综合各种情况，选择了Powerbuilder，其最重要的一点是开发人员的熟悉程度。

对三层C/S在开发平台的选择，考虑采用的比较方案是微软的IIS+ASP组合及Ap ache+ PHP组合。开发人员的经验还是在IIS+ASP上，对于Apache+PHP步有实践，基于此，选用 第一种方案。

在数据库平台的选择上，有微软的SQL Server和甲骨文的Oracle可以选择。前者是前两 版MIS的数据平台。而Oracle数据库是目前公认的最优秀的大型数据库，和微软的SQL SERVER相比，它具有更好的稳定性和安全性?一这通常是企业用户最关心的两个特性。开发人员对两种数据库都有相应的开发经验。最终选用了Oracle数据库平台。

在开发中考虑了系统的开放性和先进性。在开放性方面，有以下措施。

1．针对原有大量已积累数据（大多是EXCEL格式的）的导入，及系统中数据可能的导出， 设计了专门的导入导出模块。使得操作人员一方面从繁重的初始数据录入工作中解脱出来， 一方面随时可以导出系统中的数据作个别分析。并预瞽了与公司总部及其它协作单位进行数 据交换的接口。

2．MIS系统与P3软件（大型项目管理软件）要求做到集成。为此设计了专门的模块，通 过ODBC方式进行后台的数据交换，使得两套软件做到无缝集成：在P3软件中操作的结果可以在MIS软件中反应出来，而在MIS软件中相应模块中输入的数据也能在P3软件中反应出来。这样做的好处是大多数工程师无须操作P3软件即可输入有关工程进庋的数据，并通过P3软件的功能自动计算出相应的数据并得到横道图；而少数工程师仍可在P3环境工作，而工作结果同样反应在MIS中。

3．B/S部分的使用对象不仅仅局限于项目部的员工，还包括公司本部人员及众多协作单 位的人员。而由此相关的权限及安全问题必须考虑，即不同身分的人员能查看的权限是不一 样的。ASP在此方面的功能相对较弱，为此在B/S的服务器端专门设计了基于COJr't技术的身份认证ActiveX组件。

在先进性方面，有以下措施。

1．采用了多种软件技术的合成，如在MIS系统中合成了工作流技术，在工作流技术中调用了微软OFFICE的宏技术。工作流技术上考虑与系统更好地集成，采取了基于数据库的方案，自行开发了相关的模块。其最终效果是在JrtIS中实现了办公自动化的功能，极大地方便了使用者。

2．采用了先过的VPN技术，使得部分外出员工可以通过Internet，借助VPN访问内部的 MIS系统，从而完成远程办公。

系统运行后收到了良好的效果，用户对该软件的满易度较前两版有较大的提高。该系统随 后应用于多个电厂建设项目的管理中。

近期商业应用软件开发平台的主流越来越集中在微软的．net及J2ee，其共同特性悬更 多地支持面向Internet的开发。．net的优势是支持多种开发语言，开发人员容易掌握，产 品集成好，总体成本较低，不仅在开发的时候容易介入，在日后维护时也更能掌握主动权， 其缺点是事实上只支持Windows平台。J2ee的优点是跨平台，可以选择多家公司的相关产品，但开发相对复杂，且只支持JAVA语言。Powerbuilder虽然有最新的面向分布式及三层B/s结构的新版本推出，但终不及前两者。对于象我们在非软件企业的IT部门，在开发新的软件军熔时．hn霉雨白G-r耳学击E苜古朴件扒司-作耳学的音千． 。。+商：玄旱}．}．妨杯的；靠坯

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

摘要

本文讨论选择新软件开发平台用于重新开发银行中间业务系统。银行中间业务系统是指 银行通过与企事业单位、机关团体的合作，为客户提供金融服务的系统。X省农行银行的原 中间业务系统软件开发平台是以UNIX系统为操作系统，使用的数据库是Sybase，采用二层 的C/S结构，使用DB-Library，T-SQL编程。随着业务的不断发展和软件开发维护工作的 剧增，该软件开发平台表现出工作效率低，开放性差，开发出的产品不易管理等突出性的问 题。为了解、央原软件开发平台的不足之处和基于该银行长远发展目标的要求，我们引入新的软件开发平台OSP PrejPbranch。在文中阐述了选择软件开发平台的原则：要求开放性好，可复用性高、开发出的软件易于管理、风险可控、技术能与发展主流趋势相一致并易于掌握， 并总结了应用新软件开发平台开发银行中间业务系统所带来的优势。 正文

银行的中间业务系统是指银行依托自身的电子化平台、网点网络和人员等资源，通过与 企事业单位、机关团体的合作，为客户提供代收代付、资金转帐结算、业务代理和咨询、增值理财等金融服务的平台。X省农业银行的中间业务系统主要包括由五大类业务组成．即批量业务，如代发工资、国库统发工资、批量代收代付；单笔缴费业务，如柜台代收学费、行政管理费等；通信类业务，主要是指要与外单位进行实时通信的业务，如固定电话缴费系统， 手机缴费系统等；增值服务业务，如代客理财、银证资金转帐和结算；其他业务，如业务咨 询和代理等。

该行原中间业务系统是C/S结构，采用DB-Library/C编程，使用的数据库是Sybase， 以UNIX作为操作系统。该开发平台在开发中间业务系统是工作效率比较低，开发周期比较长，复用性差。针对上述开发平台的实际情况和存在的主要问题我们引入新的国内某公司的基于中间件技术的软件开发平台"OSP PrePbranch"用于重新开发该银行的中间业务系统。在整个项目期间我参与了软件开发平台的选型，系统的分析，开发和设计，测试的工作。 在选择OSP PrePbranch平台时，我们主要遵循了以下原则：利用选择的平台开发出的新 系统能和基础业务系统有机集成的原则，选择的开发平台易于掌握的原则，选择的开发平台 开放性好、复用率高的原则，选择的平台易于管理的原则。

应用新软件开发平台开发出来的系统要能够和基础业务系统有机集成是引入软件开发平台的基本条件，它也昱选择软件开发平台的原则之一。OSP PrePbranch软件开发平台是一个独立的开发平台，使用该软件开发平台开发的中间业务系统能方便通过基础系统的接口直接调用，不需要另外开发接口调用中间业务系统，而且OSP PrePbranch厂商进行了现场演示和提供了正式的书面文档。这样，通过简单的调用能实现基础业务系统和中间业务系统的有机集成。

选择的开发平台要遵循易掌握性原则。引入一项过于复杂或难以掌握的软件开发平台是 毫无意义的。基于中间件技术的OSPRePbranch软件开发平台采用的操作系统是unix，使用 C／C++和嵌入式的T-SQL语言为开发工具。C／C++、SQL它们都是该银行软件工程师比较熟 悉的编程语言，因此该软件开发平台易于掌握。使得该银行选用该软件开发平台在较短的时 间就能掌握它，应用它。

选择的开发平台要遵循开放性好、复用率高的原则。OSP PrePbranch系统提供的每个原 子交易都定义了规范的接口说明，调用时入参、出参的类型、个数、顺序方面部有明确的定 义，使用的场合范围；如文件的上传．，下传服务就有详细的定义，上传文件名，传输方式，存放的目录等方面部有详细的说明。在开发时只要根据实际恬况和应用说明文档就可以实现

透明调用了。OSP PrePbranch软件开发平台在应用层提供了网关(GateWay)服务，使得中间 业务系统与协作单位的通信不需要银行开发人员自己开发，而由OSP PrePranch直接提供； OSP PrePbranch还提供了通信的包格式的定义，通信连接方式的定义，通信格式加包头，通 行打包，通信格式去包头，通信格式解包等原子交易。

除了上述OSP PrePbranch系统本身具有良好的开放性，提供大量可复用的原子交易外。 在此次开发新系统时根据银行中间业务系统的特点还自制作了大量可复用的原子交易，如帐 户的入帐、帐户明细的查询、帐户性质的判断、卡折之间的转帐、各人帐户和对公帐户之间 的转帐等，把这些模块加载到OSP PrePbranch系统的构件库中，与OSP PrePbranch本身的 原子交易一起提供服务。对自制的原子交易也提供了规范的接口说明，参数调用说明，应用 场合等规范性文档。它们和OSP PrePbranch软件开发平台本身直接提供的原子交易对于所有 的程序员是透明的，程序员使用时只要查阅规范文档就可以直接使用，而根本不需要了解它 们的具体实现的细节。有了这的开发平台，在丹发新系统时只要根据不同的业务品种编写必 需银行核心功能模块，然后从OSP PrePbranch构件库中选择所需的原子交易就可以快速开发 出金融交易。这样提高了软件的复用率，该变了过去重复开和重复测试的大量工作，极大地 缩短了开发地周期，大大加快了研制进程。因此，无论OSP PrePbranch软件开发平台本身， 还是后继的开发部保持了良好的开发性，较高的复用率。

选择的开发平台要遵循易于管理的原则。该银行中间业务系统改造之前客户端前台软件升级 时，采用手工作业方式，工作量大，不便于管理。新系统中把各网点终端信息收集在一起， 保存中间业务系统应用数据库中；若软件需升级更新时，把升级软件放在中间业务平台的指 定目录下，每天网点开启中间业务系统时，前台软件自动执行版本更新升级程序，保证网点 及时、自动地从后台取回最新版本软件并投入生长运行。因此，新系统极大地减少了软件升 级所带来地工作量，使得中心机房可对各网点运行的软件进行统一升级、版本控制、集中管 理、方便管理。

由于选用的软件开发平台OSP PrePbranch是基于中间件技术的，它由前台开发子系统， 主控守护进程ubridge，后台开发子系统和数据库连接与管理子系坑组成的。中间件技术是当前信息技术发展的一种主流技术，因此OSP PrePbranch软件开发平台在相当长的一段时期内保持技术领先的优势。

OSP PrePbranch软件开发平台具有良好的开放性，复用性高，它所采用的是先进的中间 件技术。特别是OSP PrePbranch系统的开放性好，可复用性高方面在应用该软件开发平台开 发中间业务系统时，可以方便的使用OSP PrePbranch提供的开放的接口，大量现成的原子交 易，在具俸开发时只要根据业务需要编写必须的核心代码就可以快速开发出金融交易，缩断 了软件开发的周期，提高了工作的效率，提高了软件的复用性，加快了研制开发的进程。使 得该银行能在较短的时间内开发出新的金融产品，提高了银行的市场竞争力。

任何一种软件开发平台的选用都具有一定的风险，特别是在金融业中引入新的软件开发 平台要谨慎从事。首先，它是一个基于中间件技术的成熟的产品，在此之前已经在国内金融 业有多个成功应用的先例；其次，该软件开发平台大部分是采用C／C++语言开发的，它易于掌握，因此就不存在选用一个不易掌握或不能掌握的平台；再次，该软件开发平台实施成本低。因此我们从软件开发平台的成熟性，易掌握性．实施成本等多方面进行了论证和考察， 它所带来的风险是在可以控制的范围之内的。当然，我们在选择OSP PrePbranch软件开发平台主要是基于该银行的实际情况的需要。在不同的应用领域有不同的选择，如企业应用集成可以选择EJB规范的J2EE平台，它具有开放性，平台应用的无关性等特点。但是无论那种软件开发平台，它们部应该朝着开放性、平台无关性、可移植性、能够实现异构集成等方向发展和演变，同时它们应该代表着先进的技术蚩匣音向

论软件三层结构的设计

摘要

我所在的单位是国内主要的商业银行之一，作为单位的主要技术骨干，20xx年1月，我主持了远期结售汇系统的开发，该系统是我行综合业务系统XX2000的一个子系统，由于银行系统对安全性，可靠性，可用性和响应速度要求很高，我选择了三层C/S结构作为该系统的软件体系结构，在详细的设计三层结构的过程中，我采用了字符终端为表示层，CICS 'IRANSATION SERVER为中间层，DB2 UDB 7.1为数据库层，并采用了CICS SWIT(:H组，并行批 量的办法来解、央设计中遇到的问题，保证了远期结售汇系统按计划完成并顺利投产，我设计的软件三层结构得到了同事和领导的一致认同和称赞。但是，我也看到在三层结构设计中存在一些不足之处：比如中间层的负载均衡算法过于简单，容易造成系统负荷不均衡，并行批量设计不够严谨，容易造成资源冲突等。

．正文

我所在的单位是国内主要的商业银行之一。众所周知，银行的业务存在一个“-八定理”： 即银行的百分之八十的利润是由百分之二十的客户所创造。为了更好地服务大客户，适应我 国对外贸易的蓬勃发展态势，促进我国对外贸易的发展，20xx年1月，我行开展了远期结售汇业努。

所谓的远期结售汇就是企业在取得中国外汇管理局的批准后，根据对外贸易的合同等凭 证与银行制定合约，银行根据制定合约当天的外汇汇率，通过远期汇率公式，计算出交割当 天的外汇汇率，并在那天以该汇率进行成交的外汇买卖业务。远期结售汇系统是我行综合业 务系统XX2000的一个子系统，它主要包括了联机部分、批量部分、清算部分和通兑部分，具有协议管理、合约管理、报价管理、外汇敞口管理、帐务管理、数据拆分管理、报表管理、 业务缩微和事后监督等功能。

我作为单位的主要技术骨干之一，主持并参与了远期结售汇系统的项目计划、需求分析 、设计、编码和测试阶段的工作。由于银行系统对安全性，可靠性，可用性和响应速度要求 ：很高，我选择了三层c/s结构作为该系统的软件体系结构，下面，我将分层次详细介绍三层lc/S软件体系结构的设计过程。

1、表示层为字符终端。我行以前一直使用IBJK的VISUALGEN 2．O附带的图形用户终端来开发终端程序，但在使用的过程中，分行的业务人员反映响应速度比较慢，特别是业务量比较大的时候，速度更是难以忍受。为此，我行最近自行开发了一套字符终端CITE，它采用VISUAL BASIC作为开发语言，具有响虚速度快，交互能力强，易学，编码快和功能强大的特点，在权衡了两者的优点和缺点之后，我、央定选择字符终端CITE作为表示层。

2、中间层为CICS IRANSATION SERVER(CTS)。首先，我行与IBM公司一直保持着良好的 合作关系，而我行的大部分技术和设备部采用了IBM公司的产品，其中包括了大型机，由于CICS在IBM的大型机上得到了广泛的应用，并在我行取得了很大的成功，为了保证与原来系统的兼容和互用性，我采用了IBM的CTS作为中间层，连接表示层和数据库层，简化系统的设计，使开发人员可以专注于表示逻辑和业务逻辑的开发工作，缩短了开发周期，减少开发费用和维护费用，提高了开发的成功率；其次，对于中间层的业务逻辑，我采用了我行一直使用的VISUALAGE FOR JAVA作为开发平台，它具有简单易用的特点，特别适合开发业务逻辑可以使开发人员快速而准确地开发出业务逻辑，确保了远期结售汇系统的顺利完成； 最后，由于采用了CTS，确保了系统的开放性和互操作性，保证了与我行原来的联机系 统和其他系统的兼容，保护了我行的原有投资。

3、数据层为DB2 UDB7.1．由于DB2在大型事务处理系统中表现出色，我仔一直使用

DB2作为事务处理的数据库，并取得了很大的成功，在DB2数据库的使用方面积累了自己独到的经验和大量的人才，为了延续技术的连续性和保护原有投资，我选择了DB2 UDB7.1作为数据层。

但是，在设计的过程中我也遇到了一些困难，我主要采取了以下的办法来解决：

1、CICS SWITCH组。众所周知，银行系统对于安全性，可靠性，可用性和响应速度要求 很高，特别是我行最近进行了数据集中，全国只设两个数据中心，分别在xx和YY两个地方， 这样对以上的要求就更高了，为了保障我行的安全生产，我采用了CTS SWITCH组技术，所谓的CICS SWITCH组，就是一组相同的CTS，每个CTS上都有相同的业务逻辑，共同作为中间层，消除了单点故障，确保了系统的高度可用性。为了简化系统的设计和缩短通讯时间，我采用了简单的负载均衡算法，比如这次分配给第N个CTS，下汝则分配给第N+1个CTS，当到了最后一个，就从第一个开始；为了更好地实现容错，我采用了当第N个CTS失效的时候，把它正在处理的业务转到第N+1个上面继续处理，这样大大增加了系统的可用性，可以为客户提供更好的服务；此外，我还采用了数据库连接池的技术，大大缔短了数据库处理速度，提高了系统运行速度。

2、并行批量。银行系统每天都要处理大量的数据，为了确保白天的业务能顺利进行，有一部分的帐务处理，比如一部分内部户帐务处理，或者代理收费业务和总帐与分户帐核对等功能就要到晚上批量地去处理，但是，这部分数据在数据集中之后就显得更加庞大，我行以前采用串行提交批量作业的办法，远远不能适应数据中心亿万级的数据处理要求，在与其他技术骨干讨论之后，并经过充分的论证和试验，我决定采用了并行批量的技术，所谓的并行批量，就是在利用IBM的OPC (Tivoli Operations，Planning and Control)技术，把批量

作业按时间和业务处理先后顺序由操作员统一提交的基础上，再利用DB2的PARTITION技术， 把几个地区分到一个PATITON里面分别处理，大大提高了银行系统的数据处理速度，确保了 远期结售汇系统三层结构的先进性。在并行批量的设计过程中，我考虑到批量作业有可能因 为网络错误或者资源冲突等原因而中断，这样在编写批量程序和作业的时候必须支持断点重 提，以确保生产的顺利进行。

由于我软件三层结构设计得当，并采取了有效的措施去解、夹设计中遇到的问题，远期结售江系统最后按照计划完成并顺利投产，不但保证了系统的开发性开放性、可用性和互用性，取得了良好的社会效益和经济效益，而且我的软件三层结构设计得到了同事和领导的一致认同与称赞，为我行以后系统的开发打下了良好的基础。

在总结经验的同时，我也看到了我在软件三层结构设计中的不足之处：

首先，负载算法过于简单，容易造成系统的负荷不均衡：由于每个业务的处理时间不一 样，有的可能差距很远，简单的顺序加一负载分配算法就容易造成负载不均衡，但是如果专 门设置一个分配器，则增加了一故网络通讯，使得系统的速度变慢，这样对响应速度要求很 高的银行系统来说也是不可行的，于是我决定采用基于统计的分配算法，即在收到请求的时 候，根据预先设定的权值，按概率，直接分配给CTS。

j其次，由于批量作业顺序设计得不过够严谨等各种原因，容易造成资源冲突：在远期结售汇系统运行了一段时间之后，数据中心的维护人员发现了，系统有的时候会出现资源冲突现象，在经过仔细的分析之后，我发现，由于每天各个业务的业务量大小不一样，顺序的两个作业之间访问同一个表的时候便会产生资源冲突，另外，在OPC作业运行的过程中，操作员提交的其他作业与这个时间的OPC作业产生也育可能产生资源冲突。对于第一种情况，可以在不影响业务的情况下调整作业顺序或者对于查询作业运用DB2的其享锁的技术，而第二

种情况则要制定规范，规定在某时间断内不允许提交某些作业来解；央。为了更好地开展系统分析工作，我将在以后的工作实践中不断地学习，提高自身素质和能力，为我国的软件事

业罱赫白尸．C徽蒲巾罱一

论软件三层结构的设计

搦度

随着市场的建立和发展，卫生行业面临了很多问题，一些制约卫生事业发展的矛盾和问 题日益显现，因此，国家卫生部要求各医院采用信息化管理。前不久，我所在的部门承担了 了一个医院管理系统的设计和开发，医院希望以此来转变医院现有的运行机制，提高服务质 量。该系统除了目前常见的结费系统、电子病历外，还包括门诊医生工作站、住院医生工作 站、护士工作站等分系统。考虑到需要通过Intranet实现功能，并有部分的Internet功能， 本项目平台最后采用了J ava平台。我在项目中主要负责项目的的前期规划，即选择合适的开发方案，并建立部分的数据流，在系统实施过程中推动其顺利前进。此系统开发成功后投入运行，获得医院相关工作人员的好评。

正文

前不久，我所在的部门零担了了一个医院管理系统的设计和开发，医院希望以此来转变 医院现有的运行机制，提高服务质量。客户是一个市级医院，医院很早就开始从事信息化管 理，但主要是针对结费这一块，后来，对其进行了改进，加入对病人电子病历的管理和采集， 这样当病人二次就诊时，可以很容易地得到病人的既往病史。但随着系统的运行，院方希望 对现有系统进行改进，为了更好得为病人服务，匮院考虑加入一些其它的分系统，比如门诊 医生工作站、住院医生工作站和护士工作站等等。因此我所在的部门承接了该HIS的开发， 开发的成果是一个典型的Java技术在Intr anet上的应用。

在开发前期，首先要设计出详细的系统功能规范，这一部分所花费的时间很少，因为卫 生部在20xx年曾经颁发了一个有关医院管理系统功能规范的通知，我们参考了该规范，很快确定了各分系统以及每个分系统的的基本功能。但在选择合适的系统平台上有一番讨论，考虑到医院原有系统在某些地方运行良好，是否有必要将原有系统淘汰重新设计，另外新的分系统到底采用何种平台结构也是需要考虑的问题。

医院原有的结费系统和电子病历系统数据流向范围比较固定，主要集中在交费处和挂号 处，一旦引入了新的系统，必然要将数据流向医院的各个部门。医院的Intranet已经实施， 因此首先考虑采用B/S架构体系，1日系统的数据模型尽可能保瞽。在系统的软件平台上，我们考虑使用Java平台，可以让数据在整个系统安全、有效地流动；另外现在也有很多的HIS系统可供我们参考，虽然往往是单机版的系统，但其中的数据模型有很好的参考价值。医院的现有网络系统和操作系统多种多样，这就要束我们选择的软件平台必须具有开放性、平台无关性。而在不同的系统上安装相应的Java客户端虚拟机并不困难，最后，在项目组的讨论和征求客户意见下，项目组采用了此方案。

在项目中，残们这样设计Java架构系统，将系统分为三层：

(1)表示层采用Jsp实现页面输出，这也是用户直接访问层，表示层接受来自网络浏览 器的I-rrTP请求，然后返回给客户端浏览器可以显示的HTML页面；

(2)中间件层用Java实现对数据库的访问，考虑到数据的分布特点，我们使用了数据 库连接池技术；

(3)数据库层用SQL Server实现数据库的管理和存储过程。

JSP以其执行的高效性和使用的方便性，已成为近年来大家首选的因特网开发技术，JSP 是一种页面开发技术，它以Java为其服务器端语言，结合Java Script作为其客户端语言， 能方便地实现页面的表示。选择Jsp作为前台语言，是考虑到它的平台无关性，能够兼容其

他的操作系统和数据。利用Jsp可以将HTML文件很方便地发送到客户端Web浏览器，同时也可以支持一些非HTML格式的文档发送。我们在网站中的用户层页面设计中，广泛地参考了现有的一些成功案例，在节约设计和开发的费用的同时也得刭了用户的认可。比起单纯的 Servlet技术，Jsp在页面元素上也更为丰富，在这里，我们为今后客户页面定制做了部分尝 试，设计了一个比较简单的模块，用户可以通过选择控件来动态生成页面提供打印，当然在 这部分我们设计中，可提供的数据库宇段是固定有限的，灵活性没有很好体现。

我们大量工作主要放在中间件层，由于系统中的医生工作站分系统是主要部分，因此数 据库的负载成为一个不得不考虑的问题。综合考虑，我们、央定采用数据连接池技术，因为基本上每个医生都对应一个客户终端，无论是病人资料的查讯或录入，或者医嘱的处理，都涉及到对数据库的频繁读写，服务器对于数据连接的频繁打开和关闭必然导致性能下降。一方面，我们预先考虑数据库的连接量，在系统初始阶段建立相应的存储空间，当数据库连接打开和关闭时部对该连接池进行处理；另一面，我们也使用了高速缓存技术，对某些固定的SQL查讯结果，例如药品查讯、药性禁忌等，将结果采用缓存存储，以加快对数据库的访问，降低了服务器端的负载，提高性能。值得一提的是，为了尽可能得避免纠纷，医院要求采用医生签名制度，我们设计了电子签名，采用加密算法保证各环节产生数据的有关人员不能抵赖。

数据库层我扪选择了SQL Server，程序员比较熟悉此平台的开发和设计。在前期，我们 到医院做了大量的走访工作，了解整个数据流，同时广泛参考现有的系统，虽然对医院行业 不是很熟悉，但数据层开发遇到的问题的并不是很大。在概要设计阶段，我们使用了一些计 算机辅助开发工具，这也加快了详细设计的进程。比如使用了Sybase的PowerDesignfn-工具， 在概要设计中规划了E-R图和各个分系统以及分系统之间的数据流图，然后让工具直接生成 后台数据库中的基本表结构，大大提高了开发效率。

整个项目实施完成后，医院相关工作人员反映良好，但其中也暴露出了一些问题，值得 改进。

首先，用JSP编程时容易导致系统信息的扩散。如果有人恶意攻击服务器，程序执行将 出现异常。这时，就会在页面上打印出相应的错误信息。这些信息会暴露出这台服务器的路 径信息。这个漏}同往往会被人利用，程序员对此也一头雾水，下一步我们考虑从服务器入手，采用通用的异常说明界面，解、央该问题。

其次，在设计上，可以使用更多的辅助开发工具和建模工具，比如Rational Rose，可 以利用它的代码自动生成功能，来大大提高开发速度；在用户界面定制方面，我们希望通过 不断的实跋，加强其灵活性，尽可能把可供选择的字段扩大到整个数据库。

最后，大量使用Java技术，势必对服务器的负载过大，在今后的开发中，除了现有的数据库连接池和缓存技术，我们考虑使用更多的数据库脚本来替代部分Java代码，来高速实壬贝逻辑，相较而言，数据库脚本的执行速度较有优势，结合结果缓存，应该对服务器的性能有较大的提高。

上面是裁在今后的系统设计和开发中需要注意和加以改进的地方，也是我今后应该努力 的青向．

论软件三层结构的设计

摘要

随着中间件与VVeb技术的发展，三层或多层分布式应用体系越来越流行。在这种俸系结

构中，将应用功能分成表示层、功能层和数据层三部分。

本人在去年参加了一个备件流程管理项目的开发，在此项目中担任需求分析和结构设计等 工作。结合需求分析结果和该单位的实际情况，在该项目中我们采用C/S和B/S的混合模式， 客户端使用的是Delphi和FrontPage进行开发，中间件藐们采用的是COM+，使用Delphi进 行开发，后台使用SQL Server数据库。本文详细描述三层结构的设计过程，重点讨论中间件 的设计过程和在设计实施过程中碰到的一些问题以及解决的方法，文章最后说明了采用三层 结构带来的效果，以及可以改进的地方。

正文

20xx年8月，我参加了某钢铁公司备件采购项目，主要负责该项目的需求分析和结构设计等工作。该钢铁公司原先的备件采购全部是人工完成，手续复杂，办事效率低下，更重要的是无法提供及时有效的信息供企业领导参考。该公司一方面需要通过此项目来缩短采购时间，提高办事效率，另一方面该公司已经建成比较完善的局域网，需要在内部网上公开采购结果，并要做统计分析，供全公司员工和领导查询参考，该项目涉及部门主要包括该集团 公司下的仓储公司，供应公司，招标公司，劳企部等。

根据我们做出的需求分析以及各种体系结构的优缺点，我决定采用C/S和B/S混合的体 系结构来开发。对于仓储公司等部门的需求，需要对数据进行更新处理，采用c/s结构可以 更快更好的开发且数据处理速度更快，可以更好的满足要求。对于领导和员工的查询需求， 我们采用B/S模式。采取这样的结构可以很好的满足用户需求，且容易开发和维护。由于部 是在windows平台上使用，因此在开发工具的选择上，我们使用Delphi来开发仓储公司等部门的客户端和中间件，使用FrontPage来开发网页，连接在其内部网上提供查询服务。中间件拢们采用的是COM+，进行逻辑处理，数据层使用soL Server。

以下详细介绍三层结构的功能分配和物理分布，描述三层结构设计的过程，讨论在设计 实施过程中碰到的一些问题以及解决的方法，文章最后说明采用三层结构带来的效果，以及 可以改进的地方。

对于客户端，B/S结构仅提供查询功能，使用Internet Explorer，各个子公司、二级部 门部可以通过内部网使用。c/s结构提供日常操作和管理界面，承担着整个系统的数据录入 及敦据维护工作，使用Delphi开发，它是系统数据的入口，使用频繁，安装在仓储公司、供应公司等单位；中间件和数据库以及Web服务器都放在集团公司的计算机中心，便于维护管理。中间件负责根据客户端要求从数据库中取得数据，并在进行处理后提交到客户端显示；

后台使用SQL Server数据库，数据集中在数据库服务器进行管理，方便数据管理和分析，保 证数据安全。其物理分布如下图：

对于C/S和B/S结构，我们分别使用不同的工具来开发客户端。C/S结构的客户端我们 使用的是Delphi来开发，对于B/S的客户端我们使用的开发工具是FrontPage，采用VBScript 脚本语言来开发。客户端只用来显示结果，所有的逻辑处理我们全部放在中间件中。在客户 端只需引用中间件提供的接口即可，这样一个方面使逻辑处理集中，便于维护，另一个方面 只向客户端提供处理后的数据，可以减少网络流量，加快反应速度。

对于中间件的设计是我们工作的重点。hticrosoft的Jrrrs/COht+不但能够稳定地执行应用系统的企业对象，以服务客户端的请求，更能够提供在分布式环境和异质数据库之间保护数据的事务管理能力。这让分布式虚用系统能够稳定、可靠地在复杂的环境中正确地执行。再加上MTS/CO晰邕够有效地利用各种系统资源，增加中介软件的执行效率，因此使用1rtTS/COM+作为中介软件的应用系统能够提供合理的执行效率。

经过考虑，我们决定使用COM+作为中间件来开发。如何设计出合理的中间件关系到项目的成败。根据项目的特点，我决定根据不同的部门以及各个部门的需求来开发COM+件。因为各个部门有不同的数据表，中间件主要处理的是每个部门各自数据处理和内部网上的查询以及统计分析处理，所以为每个部门设计了数个COh'l+组件，分别用来处理数据维护，查询操作以及统计分析工作。Delphi提供了rrrs的向导可以帮助程序员开发COM+应用系统，程序员可以直接在COM+数据模块中放入ADOExpress组件来存取数据库，提高了程序员的工作效率。

但在开发过程中，也出现了不少的问题。比如在仓储公司维护更新工作的设计中，使用 到多个数据库表，有些程序员直接使用rrrrs/coM+数据模块，然后在htTS/COM+数据模块中加入TADOC onnec tion连接数据库，再分别使用TADOQuery/TADOTable和TDataSetProvider纽件连接到这些数据表。

从功能上说没有什么问题，但我发现这样设计存在一些问题。其中最大的问题就是执行 效率的问题。这可以从数个不同的角度来看，首先程序员把所有的数据存取组件放在一个 MTS/CO:rrt+数据模块中，因此当客户端建立这个JrtTS/COJ/t+数据模块时需要花费许多的徽活时间。第二个问题是如果客户端只需要使用其中的一个数据表的数据，那么客户端仍然需要花费多余的时间建立不相关的对象。最后，对于MTS/COM+提供的Pooling机制而言，这样设计系统架构也是不好的，程序员应该尽量利用MTS/COhll+提供的数据库连接Pooling的功能。因此最好是把每一个TADOConnection的连接放在不同的htTS/COM+数据模块中，因为这些数据表部位于一个相同的数据库中。

为了解决这些问题，我重新设计了这个架构。为充分利用MTS/COM+的数据库连接Pooling功能，并且避免客户端建立不必要的对象，我使用多个独立的MTS/COM+数据模块，其中分别放入’rADoconneCtion、TADOQuery和TDataSetProvdier-以连接到不同的数据表。这样的设汁虽然比直接使用单一的MTS/COM+数据模块来得麻烦，但是无论在执行效率、系统的延展性以及资源的共享性上都比单一的JrtTS/COM+数据模块好得多。

为了更好的设计开发中间件，我对使用COM+做中间件来开发应用系统需要注意的一些问题做了总结：

1、对于客户端而言，应该尽早取得需要使用的rrrs/co脚寸象，并且在最后使用完毕之 后再释放取得htTS/CO腓寸象。

2、避免激活不必要的事务Context。 对于MTS/COM咻寸象而言，应该让事务管理越晚发生越好，并且在执行完必要的工作之后立刻调用SetComplete/SetAbort和

EnableCommit/DisableCojrunit方法释放占据的资源。尽量把相关的MTS/CO腓寸象放在同一个套件组件中，尽量减少不同套件组件之间MTS/COM咏寸象的调用。

3、在rrrrs中使用STA线程模型的对象，在COM+中使用Neutr al/Rent al线程模型的对象。

4、尽量利用Jrrrs/coM寸于数据库的Pooling，而不要使用主从架构的方式来利用数据库

Pooling。通过使用这些方法在开发过程中我们大大改进了系统的执行效率。

数据层使用一合数据库服务器，通过企业局域，分布在仓储公司等单位的工作站利用客 户端软件进行数据录入及维护工作，在各个二级分厂、单位的客户端部可以通过内部网进行 查询浏览。我们采用的是SQL Server数据库，功能强大，使用方便，完全满足系统的要求。 最后通过项目组成员的努力，我们按期完成了任务。采用这样的体系结构，完全满足要 求，并且安全可靠、容易维护、扩展方便、结构模块化、易操作。经过用户一段时间的使用， 基本上没有什么问题。在后期的维护中，我们对中间件和客户端分别做了少许修改，但二者 之间没有互相影响，这些充分体现出多层结构的优越性。当然在其中也存在一些问题。比如

在系统的执行效率和延展性上，给人的感觉是多层应用系统的执行速度有点慢，还有组件的 沿；+}-{不在右此I匍斯 ；々此I匍斯寿了翩r'n¨的沿；+音津翔夏熔垂书}井音譬百杯的翩浊

论XML技术在Inte rnet平台上的应用

摘要

20xx年10月，我参与了一个三层在线商城的项目开发，该项目整合了来自不同商家的 信息，方便在线用户的查询和购买。

在该项目中，拢担任系统分析的工作。在分析设计过程中，我借鉴了XML成熟的技术， 采用Java语言，整个系统由三层组成。在数据层，对于不同的数据库，最后部以XML数据的形式来实行数据间的转换和处理。在业务逻辑层，在联机会话的持续时间内，用户的帐户数据在内存中以XML DOM形式表示，在表示层，所以给用户的信息首先部封装成XML数据，然后用服务器或者客户机附带的XSLT转换，根据浏览器的性能将XML数据转换为HTML在前端显示。

在设计过程中，如设计XML的各个基本元素，我应用域分析的方法，在采用XML DOM形式的时候，分析比较了其他的形式，在将XML转换为HTML的设计中，引用了XSLT。 ．正文

随着Internet信息技术的发展，我所在的公司准备开发一个网上商城，这样各个商家就 可以把自己的产品信息在这个网上商城中发布，并且提供了在线购买。也就是开发一个电子 商务平台，在这个平台上，整合了来自不同商家的信息，方便在线用户的查询和购买。有点 美似现实中的商城，为各个商家提供地方，方便、俏费者购买。

本人有幸成为这个项目的系统分析员之一，参与了这个系统的设计，并且对系统中的关 键实现技术也进行了一一验证。整个网上商城系统由三层组成。在数据层，由于各个商家自 己有着不同的数据库来存储自己信息，为了实行信息在同一平台上的共享和处理，我们采用 ：XML数据的形式来实行数据间的转换和处理。在业务逻辑层，在联机会话的持续时间内，用户的账户数据在内存中以XML DOM形式表示，在表示层，所有给用户的信息首先部封装成XML数据，然后用服务器或者客户机附带的XSLT转换，根据浏览器的性能将)OrtL数据转换为HTML在前端显示。

在数据层，我们面临的第一个的问题就是如何统一认识将要采用的XML数据的元素。刚开始是由一个人来定义XML数据的元素，但是后来发现，这样定义处理的XML元素很难获得别人的认同，并且对于不同的商家，所定义的XML元素不具有代表性。于是，在争取到领导的支持后，把以前的XML元素设计推倒重来，而且借鉴了国外关于类似设计所采用的域分析的方法，该方法就是一个用于确定网上商城这个域的术语，范围，共性和变性的过程。就这样为了寻求一个统一的XML无素的定义，我们成立了一个小组来进行的网上商城的域分析，这个小组有商家代表，数据库设计员，参与多个项目的有丰富经验的程序员和一个专门指导该组域分析的大学专家组成。

在小组会议的开始，我们首先达成一个其识，那就是需要采用一直标准术语来避免交流 中产生的误解。于是，我们在刚开始的一周内先确定的关于网上商城的一下公用术语，比如 store（商城），shop（店面），ware（商品）等，作为XML最基本的元素。

在小组讨论的过程中，有成员建议对于域分析，分多个阶段进行，每个阶段提交域分析 报告，比如第一阶段的域分析报告主要为标准术语以及各个商家信息其性和可变性的表格，

第二阶段的域分析报告，对于域分析中的商家可变性的东西进行详细说明。我们采纳这个建

议，获得了很好的效果。就这样，通过3周的域分析，我们小组最终提交一份完整的关于XML网上商城元素的详细表格，由于这些XML元素是由各个部分和商家代表讨论处理的，所以很快被整个项目组成员所接收，并且这些XML元素在后来的开发中证明是非常完整，能够清楚地反映数据的结构，大大提高了整个的系统的开发效率。

在业务逻辑层，由于所有数据库的信息都被转换为XML数据结构，所以茌处理数据库信息的时候还必须对XML数据进行XML语法分析，并且将分析出来的结果送往程序。在这儿我们考虑采用XML DOht（文档对象模型）来保存这些语法分析出来的ⅫL数据。比如在联机会话的持续时间内，一个用户的帐户数据首先从传统的关系型数据库中读取出来，转换为XML数据结果，并且通过一个XML语法分析器，将XML数据转换成为DOM对象保存在内存中，程序通过Java的DOM API访问这些对象。在这儿为了更好地选择处理XML的技术和方法，我还比较其他两种分析XML数据并且保存的方法。

比较了几种方法，发现DOM有个缺点就是当它保持的数据非常多的时候，将大量占用内存的存储空间。但是，使用DOM API也有一个明显的好处就是简单，它可以通过Java程序直接使用一些方法调用DOM树上的数据。为此在设计的时候，尽可能地重复调用已经存储在内存中的DOM对象上面的数据，避免对于相同的数据有多个DOM对象存在。在编码过程中面临的问题不是很多，关踺是让程序员熟悉DOM API的各种调用方法。

在表示层，考虑到将大量的运算负荷分布在用户端，既用户可以根据自己的需求选择或 者制订不同的应用程序以处理数据，我们设计把所有绐用户的信息首先部封装成XhtL数据， 然后用服务器或者客户机附带的的XSLT转换，根据浏览器的性能将XML数据转换为HTML在前端显示。这样的话，服务器只需要准备一次的Web内容，尽可能完善，准确地将数据封装到XML文件中，而XML的自解释性可以使得用户端在接收到ⅫL文件的同时也理解数据的逻辑结构和含义，再通过转换程序，XML可转换为用户所需要的个性的多样的I-m{L显示方式。在设计中我们所选取的XSLT是一种用于操作XML文档的高级语言，就像SQL是操作关系表的高级语言一样。

一个XSLT规范本事就是一个XML文档，我们通过它的规范，描述出各个用户可以选择的各个HTML显示模板，这样客户端程序只需选择好模板，再加上接收到的XML数据文件，就可以方便地生成自己个性化的HTML文件，并且在浏览器中显示出来。当然在开发中遇到了不少问题，首先由于XSLT是一门起点比较高的语言，也比较烦琐，掌握起来比较慢，使得对程序员的要求比较高。这样导致使用XSLT语言编写的I-mrtL文件的模板过于冗长，作为设计师我一方面是希望模板程序尽可能地包含HTML页面所有的功能和美观，一方面又希望模板程序尽可能地短步，简洁，便于修改。

为了达到两种选择之间的平衡，以达到最佳效果，我对于基本模板的设计，采用有经验 的程序员进行设计，并且要求尽可能多地写全文档，并且频繁地开展小组会议，对页面设计 和美工人员详细讲述模板各个部分和功能。

在Internet平台上采用XML技术，明显的效果之一是对于不同数据库的支持，通过将各种数据转换为XML文件，可以实行了数据间的转换，其享和处理。效果二是支持了用户的个性化服务，支持用户在不同的客户端可以个性地选择显示界面。

由于HTML在许多复杂的Web应用中遇到了问题，为了彻底解、夹这些问题，必须采用功能强大的XML来代替HTML作为Web页面的书写工具，而XML的广泛使用，必定能够推动Web的不断发展，开创Web应用的新时代。对于XML技术在Internet平台上的应用，我更关注它的扩展性，既让XML包含更加丰富更完整的数据信息，目前公司所接触的首先是软件模型的交换和模型信息的保存，打算在)Ortl (XMI Metadata Intercharge)展开工作。XMI作为一种试图通过XML语言为程序员和其他用户提供一种交换元数据信息的标准途径，是作为MDA模型驱动的模型交换的基砒，是非常具有意义的工作。

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

摘要

某某大学图书馆从85年引进日本富士通的管理系统开始，历经近∞年的信息化建设后， 逐步形成了拥有一定硬件规模、软件资源和一批专业技术人才的现代化图书馆。而自从我校 进入" 211"以来，建立数字化的图书馆就成为了我们工作的重中之重。我校数字化建设的主 要内容是建立基于千兆主干网络的、提供多种网络服务的网络应用体系。项目建设完成后， 裁馆成为该省规模最大的开放式的数字化文献提供和建设中心，为本省的科技、文化、教育 事业的发展提供了强大的资源保障。

20xx年3月，我参加了某大学数字图书馆建设，担任技术部主管职务，负责理解学校和省教委对该项目的要求，根据技术先进、成本适中、充分满足要求为原则，进行应用需求分析，对整个网络进行设计，提出设计方案。由于该项目规模比较大，提供的服务比较多，作为校园网络的中心和提供网络服务的核心部门，我馆图书馆的许多业务需要在网上展开，各种特色服务所用的平台也是五花八门。这对安全方面的设计提出的较高的要求。我们通过采用保障Internet接入的安全、保证干路畅通和合理划分子网、保证软件系统的安全、健全管理机制等措施来设计图书馆网络。这种切合实际、低咸本、高技术的设计方案实施后的网络，其安全性大大加强了，同时网络的性能并未受到太多的影响。

正文

20xx年3月，我参加了某某大学数字211建设图书馆数字化建设部分（分为第一、第

二、第三期工程）。第二期工程总额5500万元。该工程建设项目分为网络部分、软件部分以及资源建设部分。该项目的目标是，将地处该城市的东、西、南、北端的各分校区和总校区的网络联连接成为一个畅通的宽带、高速、高性能的校园网；建立一个文献信息中心，能为读者提供电子期刊服务、图书书目数据服务、图书光盘点播、视频点播服务，并且能够拥有部分自己的特色数据资源；建立一个网络中心提供Web服务、邮件服务、全校的办公自动化服务，它既是全校的应用服务中心、公共数据存储中心，又是全校网络的管理中心。项目从实现的功能、设备配置的先进性、网络带宽的规模看，恢项目要达到国内一流、省内第一的水平。项目建成后，该数字图书馆能承担全省的文献检索与开发的重任。我在该项目中担任技术部主管，其任务是充分理解学校和省教委对该项目的要求，根据技术先进、成本适中、充分满足要求为原则，提出和需求分析书和项目计划书；监督光纤的铺设和楼宇布线；设备的货到验收；网络调试【交换机调试、地址分配、访问控制配置、设备网管模块的配置、网络管理平台的配置）；网络应用系统的建立；数据库的采购；建立特色的数字化资源等等。进行应用需求分析，对整个网络进行设计，提出设计方案。

由于该项目规模比较大，提供的服务比较多，各种特色服务所用的平台也是五花八门。 同时，影响网络安全的因数比较多，通常有人的因数、自然因数、病毒因数。如果对这些主 要因数防范不得力，将影响网络硬件、网络数据传输、数据服务器的安全。因此对其安全设 计，单一的技术或者设备保护难以保证本校网络的安全，效果往往不理想；所以我们采用多 层汝的防护体系来保证网络的畅通和网络数据的安全。我们根据业务数据的流动历经的重要 环节，来提出具体的安全方案。

1保钶舅移L的安全

俗话说病从口入，同样一些常有的攻击往往来自外网，同时使用图书馆所购买的外文资 料比如Web Science、EBSCO等数据库需要访问外网；同时，外网的授权用户需要能够访问我们的数据。所以必须保证接入部分的稳定与安全。在外网联接上，我们租用2条光纤线路 (100M)分别接入中国电信和xxx大学，使用Cisco的7500系列路由器接入，然后用一台

Sun spark操作系统为Solaris酌服务器做防火墙将外网和内网划分开；同时用其做策略路 由服务器，使用校园网内的用户可以快捷的访问电信网络和数育网络的资源。在外部用户访 问上，我们首先用Sun spark服务器防火墙进行IP地址过滤掉非法的IP地址，然后通过用 户名吨窨码模式登陆，才能通过防火墙访问我们内部资源。

2保证干器耨趱啪划分子网

网络干路是指各楼的骨干网、骨干网汇接形成的交换中心及联结Internet的接入线路。 它的不畅通必然导致大规模的网络瘫痪，外部付费用户访问不到内部资源，这将造成极坏的 影响。

在光纤干路上我们采用光纤连接主校区的各大教学楼、南院校区和xxx校区，主干路使 用3对光纤做冗余。由于其它分校区离主校区比较远，光纤连入费用较高，我们采用拨号接 入的方式联结。我们采用3ComRAS1500作为拨号服务器，分配32个校内电话号码给该服务器，用户只需要拨这32个其中一个，通过认证后，就可以动态分配一个校内的合法IP来访问校内的资源。在干路上，安全的隐患往往来自非技术因素，由于本市修建大学城，道路施工比较多，我们的光纤被人为的挖断j由于，某路段起火烧掉部分光纤。对于这种情况，我们采取紧急修理，租用吉通的2M徽波通讯线路和将策略路由指向电信线路的办法来保障网路的畅通。

由于本校应用点多，地理位置也十分分敌，各大单位为相对独立的机构，所以需要进行 子网划分以便管理。

我们使用两台3Com的CB9000中心交换机连接各教学单位过来的光纤，并且将华中分配的16个C类地址分成为32个VL an子网的划分使安全性得到了很大的提高，同时各单位的网络独立的虚网。同时，每个教学单位指定专人负责网络地址的分配，这样盗用IP地址的情况大大的减少了。

我们采用3Com的Transcend作为网管平台，实施对网络干路和各个子网的监控和进行 网络优化。当网络有人恶意下载资源和蠕虫病毒群发邮件时，我们可以立即找出攻击源而进 行相应的措施。

3保躅舅衅I=系统的安全

由于操作系统是软件系统的基础，所以，保护好操作系统是必须的，对于Windows系统（提供CNKI和VIP镜像等服务）保护，我们主要采取取消Guest帐号、取消不必要的服务（如远程注册表操作）安装诺顿防火墙和相应的杀毒软件、定时查看有无异常的程序运行等方式来保证其安全。对于Linux或者Unix（提供邮件、网络计费、主页、论坛等服务），我们关闭许多不必要的端口、定时对系统打包井级等措施来保证其安全。

对于数据库系统的保护，主要集中在保证数据的完整性、正确性和安全性方面。在数据 存储介质方面，我们采用磁盘阵列、NAS、San结合RAID5（无独立校验磁盘的奇偶校验磁盘阵列）方式存储数据。

4键}全的色码坩慵栅

管理安全数字图书馆的工作状态在很大程度上取决于是否有良好的管理机制。如果制度 合理、管理得当、执行得力就能有效的预防和控制安全事故的发生。反之，则会引发各种安 全隐患。

我们规定工作人员每日必须检查服务器的日志，通过日志可以清楚的看到有无外来人员 登陆服务器，并且做了何种修改。对重要的数据服务器，每日必须做异地数据备份。同时管 理员的密码必须达到一定的长度并且每周建议修改一次。

一般而言，网络安全是网络服务效率的保障。没有了数据安全，网络服务成为无源之水； 没有网络系统的安全，网络服务将成为无本之木。当然没有效率的网络传输是得不偿失的。 所以，我们要合理的规划好网络及软、硬件的合理利用。

在接入上，由于全校有3，000多台机器也要通过该做防火墙的服务器接入Internet， 这将给该服务器造成较大的负担，同时数据传输量大时，该服务器处理速度相对将成为瓶颈。 我们采取单独使用两台Sp ark圭机做代理服务器，代理服务器同时启动用户认证服务，由于 代理服务器的缓存保证了出校的流量大大减少，同时认证功能使得非法用户无法登陆网络。 这样的冗余设计使得网络的安全性能和效能得到了大幅度的提高。

在子网划分上，连接各教学单位过来的光纤的2台中心3Com CB9000交换机之间用两根光纤作一个串口，这样跨子网的访问无需通过交换能力不强的C lSCO路由器7500，子网间传输数据的瓶颈问题消失了。

在数据存储上，由于我们提供CNKI和VIP等服务，这些服务器的访问量、存储的数据量部十分庞大，单个的数据检索查询都会占据大量的CPU时间。我们使用SAN和NAS存储大量的数据，当用户提出一个检索的申请时，检索服务将在服务器上运行，当用户提出一个下载的服务时候，下载的服务由SAN和NAS去完成，这样使得SAN和NAS的效能比磁盘阵列要高。由于SAN和NAS都可以做RAID1～5，所以数据安全性能比普通的硬盘要高。采用新技术和冗余使得我们的网络服务效率和安全性能得到了大幅度的提高。

网络的安全管理不是一个硬件和软件的引进就能得到大幅度的提高的；他是一个长期的、 动态的过程。本项目的网络系统还有许多问题，一故冈络发生了大规模的网络风暴，从子交 换机扩散到中心交换机，主机与主机之间的数据传输丢包率达到了75%几乎是不通了，最后 我们发现一个施工的单位将一根漏电的线缆搭在网路上。但是为什么会造成跨虚网的网络风 暴，从技术上我们无法解、央，只能是严格检测各子网和主干网络是否达到屏蔽的要求，并且q垒士陂翱丽陂日鲁酗△Ⅱ

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

摘要

我在一家证券公司信息技术部门工作，我公司在9798年建成了与各公司总部及营业网点的企业网络，并已先后在企业网络上建设了交易系统、办公系统，并开通了互联网应用。因将对安全要求不同、安全可信度不同的各种应用运行在同一网络上，给黑客的攻击、病毒的蔓延打开了方便之门，给我公司的网络安全造成了很大的威胁。作为信息技术中心部门经理及项目负责人，我在资金投入不足的前提下，充分利用现有条件及成熟技术，对公司网络进行了全面细致的规划，使改造后的网络安全级别大大提高。本文将介绍我在网络安全性和保密性方面采取的一些方法和策略，主要包括网络安全隔离、网络边界安全控制、交叉病毒防治、集中网络安全管理等，同时分析了因投入资金有限，我公司网络目前仍存在的一些问题或不足，并提出了一些改进办法。

正文

我在一家证券公司工作，公司在98年就建成了与各公司总部及营业网点的企业网络，随着公司业务的不断拓展，公司先后建设了集中报盘系统、网上交易系统、OA、财务系统、总部监控系统等等，为了保证各业务正常开展，特别是为了确保证券交易业务的实时高效，公司已于20xx年已经将中心至各营业部的通讯链路由初建时的圭链路64K的DDN和备链路

33。．3K PSTN，扩建成主链路为2M光缆作为主链路和256K的DDN作为备链路，实现了通ij1线路及关键网络设备的冗余，较好地保证了公司业务的需要。并且随着网上交易系统的建设和网上办公的需要，公司企业网与互联网之间建起了桥梁。改造前，应用系统在用户认证及加密传输方面采取了相应措施，如集中交易在进行身份确认后信息采用了Blovrf ish 128位加密技术，网上交易运用了对称加密和非对称加密相结合的方法进行身份认证和数据传输

加密，但公司办公系统、交易系统、互联网应用之间没有进行安全隔离，只在互联网入口安装了软件放防火墙，给黑客的攻击、病毒的蔓延打开了方便之门。

作为公司信息技术中心运保部经理，系统安全一直是困扰着裁的话题，特别是随着公司 集中报盘系统、网上交易系统的建设，以及网上办公需要，网络安全系统的建设更显得犹为 迫切。但公司考虑到目前证券市场疲软，竟每十分激励，公司暂时不打算投入较大资金来建 设安全系统。作为部门经理及项目负责人，我在投入较少资金的前提下，在公司可以容忍的 风险级别和可以接受的成本之间作出取舍，充分利用现有的条件及成熟的技术，对公司网络 进行了全面细敢的规划，并且最大限度地发挥管理功效，尽可能全方位地提高公司的网络安 全水平。。在网络安全性和保密性方面，我采用了以下技术和策略：1、将企业网划分成交易 网、办公网、互联网应用网，进行网络隔离。2、在网络边界采取防火墙、存取控制、并口隔离等技术进行安全控制。3、运用多版本的防病毒软件对系统交叉杀毒。4、制定公司网络安全管理办法，进行网络安全集中管理。

一、网络安剑蔫言

为了达到网络互相不受影响，最好的办法是将网络进行隔离，网络隔离分为物理隔离和 逻辑隔离，我主要是从系统的重要程度即安全等级考虑划分合理的网络安全边界，使不同安 全级别的网络或信息媒介不能相互访问或有控制的进行访问。针对我公司的网络系统的应用 特点把公司证券交易系统、业务办公系统之间进行逻辑分离，划分成交易子网和办公子网， 将互联网应用与公司企业网之间进行物理隔离，形成独立的互联网应用子网。公司中心与各 营业部之间建有两套网络，中心路由器是两台CISC07206，营业部是两台CISC02612，一条通讯链路是联通2JK光缆，一条是电信256K DDN，改造前两套链路一主一备，为了充分利用网络资源实现两条链路的均衡负载和线路故障的无缝切换，子网酌划分采用VLAN技术，并将中心端和营业部端的路由器分别采用两组虚拟地址的HSRP技术，一组地址对应交易子网，一组地址对应办公网络，形成两个逻辑上独立的网络。改造后原来一机两用（需要同时访问两个网络信息）的工作站采用双硬盘网络隔离卡的方法，在确保隔离的前提下实现双网数据的安全交换。

二、网络边．界安全控制

网络安全的需求一方面要保护网络不受破坏，另一方面要确保网络服务的可用性。将网 络进行隔离后，为了能够满足网络内的授权用户对相关子网资源的访问，保证各业务不受影 响，在各子网之间采取了不同的存取策略。

(1)、互联网与交易子网之间：为了保证网上交易业务的顺利进行，互联网与交易子网 之间建有通讯链路，为了保证交易网不受互联网影响，在互联网与中心的专线之间安装了 NETSCREEN委托防火墙，并进行了以下控制：a）、只允许股民访问网上交易相应地址的相应 端口。b）、只允许信息技术中心的维护机地址PING、TELNET委托机和路由器。c）、只允许行恬发送机向行恬主站上传行情的端口。d）、其他服务及端口全部禁止。并且在互联网和交易网之间还采用了SSL并口隔离，进一步保证了交易网的安全。

(2)、交易网和办公网之闾：对于办公网与交易网之间的互访，采用CISC02501路由器 进行双向控制或有限访问原则，使受控的子网或主机访问权限和信息流向能得到有效控制， 主要采用的策略主要是对具体IP进行IP地址与心地址的绑定。

(3)、办公子网与互联网之间：采用东大NETEYE硬件防火墙，并进行了以下控制：a）、 允许中心上网的地址访问互联网的任何地址和任何端口。b）、允许股民访问网上交易备份地 址的8002端口。c）、允许短消息访问公司由5fiio、25端口，访问电信SP的8001端口。d）、 其他的都禁止。

三、赭防治

网络病毒往往令人防不胜防，尽管对网络进行网络隔离，但网络资源互防以及人为原因，

病毒防治依然不可掉以轻心。因此，采用适当的措施防治病毒，是进一步提高网络安全的重 要手段。我分别在不同子网上部署了能够统一分发、集中管理的熊猫卫士网络病毒软件，同 时购置单机版KV3000和瑞星防病毒软件进行交叉杀毒；限制共享目录及读写权限的使用；限制网上软件的下载和禁用盗版软件；软盘数据和邮件先查孝后使用等等。

四、集中网络安全管理

网络安全的保障不能仅仅依靠安全设备，更重要的是要制定一个全方位的安全策略，在 全网范围内实现统一集中的妄全管理。在网络安全改造完成后，我制订了公司网络安全管理 办法，主要措施如下：1）、多人负责原则，每一项与安全有关的活动，部必须有两人或多人 在场，并且一人操作一人复核。2）、任期有限原则，技术人员不定期地轮岗。3）、职责分离 原则，非本岗人员不得掌握用户、密码等关键信息。4）、营业部进行网络改造的方案必须经 过中心网络安全小组审批后方可实施。5）、跨网互访须绑定IP及MAC地址，增加互访机器时须经过中心批准并进行存取控制设置后方可运行。6）、及时升级系统软件补丁，关闭不用的服务和端口等等。

保障网络安全性与网络服务效率永远是一对矛盾，在计算机应用日益广泛的今天，要想 网络系统安全可靠，势必会增加许多控制措施和安全设备，从而会或多或少的影响使用效率 和使用方便性。如，我在互联网和交易网之间设置了放防火墙的前提下再进行了SSL并口隔 离后，网上交易股民访问交易网的并发人数达到一定量时就会出现延时现象，为了保证股民 交易及时快捷，我只好采用增加通讯机的办法来消除交易延时问题。

在进行网络改造后，我公司的网络安全级别大大提高。但我知道安全永远只是一个相对 概念，随着计算机技术不断进步，有关网络安全的讨论也将是一个元休无止的话题。审视改 造后的网络系统，珑认为尽管裁们在Internet的入口处部署了防火墙，有效阻挡了来自外部 的攻击，并且将网络分成三个子网较减少了各系统之间的影响，但在公司内部的访问控制以 及入侵检测等方面仍显不足，如果将来公司投资允许，我将在以下几方面加强：

1、在中心与营业部之间建立防火墙，通过访问控制防止通过内网的非法入侵。

2、中心与营业部之间的通讯，采用通过IP层加密构建证券公司虚拟专用网(VPN)，保 证证券公司总部与各营业部之间信息传输的机密性。

3、建立由入侵监测系统、网络扫描系统、系统扫描系统、信息审计系统、集中身份识别系统等构成的害伞{牵制中，I、-、，作为公司网络临榨衙馨系统。

论新技术的引进

摘要

根据国家税务总局对税务系统内所有系统进行集成与整合的需求，我所在的开发单位组 织了全国金税工程防伪税控系统网络版的升级开发工作。该项目工程浩大，要求在具有严格 的安全、可靠性能的基础上，将基于DOS操作系统、Foxpro数据库的原单机版防伪税控子系统集成到基于网络的、大型数据库的“集中存储、分布操作”的分布式系统中来，并实现与基于AIX等操作系统和Oiacle数据库的稽核协查等其他应用系统的数据共享和互操作。在项目中，我担任项目主管，主要负责系统规划和组织实施工作。我在将近一年的可行性研究、 需求分析、系统研发与试点工作中，通过引进面向对象设计方法、采用B/S/S三层体系结构、 利用群集实现负载平衡等新技术，使该项目取得了圆满成功，受到了用户的一致好评。但是 现在看来，由于新技术的使用，怎样实现软件开发公司对新技术的渗透、怎样开发自主产权 的中间件等问题，需要我们在今后系统开发中做进一步探索。

正文

20xx年元月，我作为项目主管，有幸参与了全国税务系统金税工程防伪税控系统的升级开发工作。防伪税控系统主要由基于增值税#5@p的企业开票、企业发行、报税、认证、#5@p发售等五大子系统组成，系坑组成模块如图1所示。具体流程是：企业在当地税务机关通过企业发行系统取得用于开具增值税#5@p的相关设备（金税卡与IC卡）和权限，再到#5@p发售系统领取增值税#5@p，通过企业开票系统开出#5@p后产生#5@p明细和申报纳税数据存入IC卡中，然后、企业持IC卡到税务机关由报税系统进行报税、并将取得的可抵扣的#5@p数据通过认证系统进行认证后，经过Internet上传到税务机关，所有数据经由税务机关处理后，传递到其它系统进行处理。系统要求具有严格的安全、可靠性能，必须建成基于网络的，分布式实时数据库处理系统，达到数据共享的目的。在此故开发过程中，我特别强调在认真细致的需求分析的基础上，最大限度地引进新技术新方法的思想。

一、采用面向对象分析方法

防伪税控系统网络的应用将极为广泛，涉及全国所的有税局和一般纳税人企业，具有基 于增值税#5@p的开票、认证、报税、传递等业务操作，面对如此复杂的系统，怎样从中理出 头绪来，最大限度满足用户要求要，实现整个开发流程的“无缝刀连接，需求分析是最重要 的环节。我在认真研究和分析1日单机版开发文档后，提出采用面向对象的开发方法。系统的主要业务范围是增值税专用#5@p的防伪与税控，通过对整个系统瀛程的分析，我抽象出“发 票、操作员、安全卡’’等类，从类出发，建立对象，再通过对象类之间的继承、聚合关系、 消息和关联，分别建立开票、认证、开票、企业发行等子系统和共用的系统管理等模块，并 通过操作员类中权限属性实现各子系统的权限控制。通过面向对象分析方法，不仅提高了系 统的开发效率，而且提高了软件的复用性和可维护性。

在工具的选择过程中，我们选择了现在十分流行的系统Rational系统系列工具，包括 Rational Rose, Rup、Soda和Requisite Pro等。特别的，从防伪税控系统的对于增值税发 票的防伪和税控功能可以看出，整个系统具有很长的生命周期，必须面对税务系统因为经济 发展而出现的多变的需求变更，并且，又必须服务于税务系统其它的如征收管理、稽核协查 等应用系统。所以，要求系统具有很好的可维护性、可扩展性。而公司在原有单机版的升级 上，因为没有统一的、规范的开发文档而吃尽了苦头。所以，我、央定采用Requisite Pro作 为犹们现在和未来的系统需求管理工具。莪们在对经过详细的用户调查后，按照莪们的基本 理解写成了基本需求，交给用户进行评审和补充，再形成正式的需求录入到Requisite Pro 申去，并记录需求的变化情况、需求之间的依赖关系，实现需求的全面管理。公司决策层在 认真听我的汇报后，表示了很高的兴趣并给出支持，使我更加增强引入新技术进行开发的决 心。

但是，新技术并不意味着是最好的或是最适合的。在引用新技术中，我特别注意它的负 面。面向对象分析方法虽然有效地表达和描述了现实世界，但有时也会忽略外在的表层的需 求，有些关键需求要等到用户使用后才会提出，然而等到用户使用后再维护是不现实的，作 为原型开发模型中的原型也是收集用户需求，描述与解释需求的一类相当有效的方法工具。 在分析过程中，为了更好让用户了解我们的系统，更完整提出需求，我沿用了公司熟用的原 型开发方法。通过利用Access开发出系统原型，让用户试用，取得很好的效果。所以在新技术引进过程中，我们熟悉的优秀的开发思想与方法不能丢，这是我们要特别注意的地方。

二、采用B/S/S三层软件体系统结构

瘦客户端设计表示层。进行系统设计时，采用客户／月艮务器( C/S)模式还是采用浏览器／应用服务器厂数据库服务器的(B/S/S)模式，成为我们开发小组成员争论的焦点。我认为， 采用哪种系统体系结构相当重要，决策时，不但要考虑系统运行成本，还耍考虑系统运行的 稳定性、可靠性、可维护性以及业务需求变动时的可扩展性。新系统将所有数据集中到市级 税务机关（参看图1），如果将业务处理逻辑分敌到客户端或数据库服务器，虽然可以低成

本运行，但是，我们分析得到，同一时刻，区县级税务机关和企业到服务器的连接可能达到 30-1000，在发达地区可能更多，这显然击中了C/S模式的要害，并且，税务系统的需求经常变更，所以，我们、央定采用应用服务器集中处理实现业务逻辑。事实证明，这个决策是正确的。新系统在沿海五省四市试运行时，不仅稳定、可靠，易维护，而且，客户端采用IE浏览器，受到了维护人员和广大操作者的好评。

业务层引入WEBLOGIC应用服务器。众所周知，WEBLOGIC是用于开发、集成、部署和管理大型分布式WEB应用、网络应用和数据库应用的Java应用服务器。可以说，采用Weblogic 的主要理由有：首先是税务现有应用系统的异构的数据库平台如用于（如用于CTAIS征管系 统的Sybase,稽核协查系统的Oracle,其它的SQL Server）j再有，对多种操作系统的支持， 包括NT系列、AIX、Sco等：并且，税务的系统需求经常变化，比如在我们的开发过程申，因为国家税务总局推出“一窗式刀管理，税局要求我们的报税系统有向征管系统传出某种格式数据的功能，我们利用WEBLOGIC对XML的支持，很快地解决了这个需求。总之，这要求系统具有很好的可移植性和可伸缩性，应用服务器能使程序员从常规设计中脱离出来，集中精力组织和优化业务逻辑。我特别注意了服务器的选型，主要从开发效率、可复用性、可伸缩性和可扩展性等几个方面考虑。

企业将取得的可抵扣的增值税#5@p经过认证系统认证后，形成加密的认证数据，经过互 联网传到税局的外网WEB服务器，再由WEB服务器传到内网的应用服务器进行解密和税局再认证。对于一个市级税局，这种#5@p数据可能非常宠大，如果由应用服务器信中进行解密， 很显然，时间上是不充许的，并且，可能造成应用服务器的死机。我提出采用解密工作站队 列处理解密工作，让应用服务器统一分配各工作站的工作量。这样，大大地减少了应用服务 器的工作量。

综上所述，由于采用了面向对象的系统分析方法，B/S/S系统体系结构、解密工作站实 现负载平衡等新技术，提高了整个系统的开发效率和质量，使新系统按计划完成，且具有很 好的安全性、可靠性、可维护性、可扩展性和外部接口。但是，由于新技术酌采用，也使我 们产生了一些新的问题。

怎样让员工理解、支持和掌握新技术。引进新技术，将打破开发人员习惯的开发方法和 程序设计方式，这种习惯的打破，往往要付出更多的精力和时间，如果靠权力或压力来解决 只能是一种表面现象，我认为，关键是要营造一种引进新技术进行软件开发的文化氛围，让 软件公司开发人员学习并引进新技术到我们的开发中来形成一种习惯，怎样营造这种氛围， 是我们管理领导层常思考的问题。

怎样开发自主产权的中间件。我们的应用服务器采用的是BEA公司的WEBLOGIC中间件， 虽然，它提高了我们新系统的开发效率和安全性和平台无关性，但是，也大大提高了我们的 软件开发成本。中间件在我国具有很大的市场和利润空间，我想基于中间件的开发，首先要 Hrl.堰官的市场价值．蚨后存耳考卜滓重官的涌田性．

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

摘要

本文通过某省征管信息系统，讨论了软件测试方法和工具的选用。该项目的目标是建设 一个功能完备、监控严密、安全稳定的新一代税收征管信息系统，系统业务功能多，系统复 杂，性能要求高。项目采用了J2EE应用开发平台，经历了多个测试阶段，根据系统的特点， 文章重点讨论了我们在单元测试和性能测试中所采用的测试策略和测试工具，单元测试中划 分了类的优先级，使用Junit测试框架；性能测试中确定关键用例，使用Rational Test Manager

2003工具测试。

作为项目负责人之一，我有幸参与了该项目的分析和设计，也参与了测试的整个过程。 正文

税收是国民经济的重要环节。今天，在业务需求和信息技术发展的双重交互推动下，税 收征管业务的信息化应用在全球以突飞猛进的速度得到应用。然而，受限于工程进度的要求、 IT技术的发展和观念认识的差距，早期的信息化建设通常缺乏全局规划。为此，20xx年10 月，某省税局决定在原有的信息化建设成果的基础上，充分发挥目前先进的计算机网络和通 信技术的强大处理能力，构建全省集中的税收征管信息系统。工程的目标是集中存储和处理 全省征管业务的基础数据，实现信息的高度共事和一致，全面推进信息技术在税收工作中的 应用。

作为项目负责人之一，我有幸参与了该项目的分析和设计。

该系统建立在J2EE框架基础之上，其BLH (BizLogicHandler)是J2EE框架中的Domain 层的实现；BPO (Business Persistence Object)是DAO与BO的结合体，对应J2EE中

Persistence层的实现；Web层开发采用Struts框架。系统业务功能多；渠道多，后台前置 系统多，系统复杂；系统性能要求高，并要求系统稳定，质量要求高；采用很多新技术，项 目建设时间紧。

根据本项目的这些具俸特点和要求，我们在IBM完全生命周期测试模型的基础上，根据项目时间要求、具体情况和成本效率进行了裁碱，形成本项目的测试策略、总体测试计划和详细测试计划。对于应用系统的测试，我们划分为单元测试、部件组合测试、功能测试、性能测试和验收测试。其中重点关注了单元测试和性能测试，下面分别介绍。

单元测试阶段，我们采用开发人员自己写测试代码、小组内同级审查和测试组抽查相结 合的测试策略。要求单元测试应紧接在编码编译通过之后，鼓励进行测试先行（即先编写测 试用例，然后用测试驱动代码的实现）。

草元测试工具采用junit测试框架。因为，我们的开发语言是Java，开发工具采用的是 Jbuilder，而junit是当前j ava自动化单元测试的实际标准，jbuilder对junit提供了很 好的支持。

对Action部分使用StrutsTestCase进行单元测试，StrutsTestCase for Junit是对标 准Junit中TestCase的扩展，可以对Struts framework的测试提供方便。我们使用了其中 的Mock object方法， 沏0试Action objects, mappings,form beans以及forwar ds declarations，它不需要servlet引擎及web application container的环境，而且

StrutsTestCase提供了许多"validation methodsn，方便测试案例的编写。我们采取的原

则是，尽可能的把逻辑代码从j sp/seivlet/action中移出，1尉羽Junit作单元测试。该系统 单元测试中面临两个脱离，脱离BizDelegate（封装了对Session Fa9ade的调用过程，降低 Application层与Services屡的耦合性）对action进行测试，脱离BPO对BLH进行单元测 试，为此我们使用EasyMock技术，为一个接口创建一个模仿对象，将模仿对象作为参数来调用域代码，具体为测试者提供了抽取方法和工厂方法。

因为该项目涉及的用例非常多，我们对其进行了优先级的划分。在单元测试的时候，我 们同样对类进行了优先级的划分，依据是：类对应的用例的优先级、对系统是否产生严重后 果、潜在的用户数量和使用频度、信息的价值。对于不同优先级的类采用不同的测试方法。 高优先级的类，一定要有相应的测试类，以黑盒测试为主，对典型错误进行一定的白盒测试 的方法，每一步修改都需要进行回归测试；中优先级的类，根据实际情况、央定是否需要测试类，对核心的采取运行测试，其余的通过同级审查；低优先级的类，采用静态测试，所有类通过开发人员自检和同级审查。

为了保证测试的质量，我们测试之初就设置了专门的测试小组。在单元测试阶段，该小

组监控所有的测试活动和任务的执行情况，对测试的总体进行跟踪、控制和报告。对于类的 提交，我们制定了严格的审核过程。首先，开发人员测试审查自己的类；然后小组内审查人 员审查相应的类，打上已审查标记；最后，测试小组审核和拙查已审查的测试类和代码；测 试小组还需要根据审核和抽查情况进行统计分析，调节测试资源分布。

在性能测试阶段，我们分为四个阶段来实施：启动阶段、准备阶段、实施阶段和分析阶 段。测试工具采用Rational Test Manager 2003，测试环境包括Local computer和Test agent， Local computer作为测试平台的控制主机，负责整个测试的计划、设计、实现、执行和评估， 作为Test agent的机器，统一接受由Local computer发出的脚本指令信息，在一台机子上 可以模拟多用户访问系统，并将执行结果报告给Local Computer，最后由Local computer 生成统计报告。在测试中我们也发现响应时间慢的问题，在经过对服务器的调优，以及相应 部分的代码优化、SQL优化之后，性能得到明显改善。

下面简单介绍性能测试中我们对遇到的问题所采取的策略：

(1)该系统采用的是J2EE架构的一种模式，GUI客户端直接和服务器连接，采用的是 BEA公司独有的T3协议，而目前自动化测试工具能够录制和回放脚本的大部是基于FrnP协 议的浏览器客户端方式。对此，我们采取自动录制和手工编写脚本相结合的寿式，对于浏览 器客户端的测试，采用自动测试工具录制脚本；对于GUI客户端的测试，用JAVA配以性能测试工具提供的API包，手动或半手动编写测试脚本。

(2)该系统业务功能繁多，测试需要准备的数据量大，而测试时间短。我们分析出业务 具有代表性的重要和关键用例，并且利用开发过程已有的客户端程序，减少测试脚本的开发 量。

(3)该系统渠道多，与外部系统接口复杂，而且系统采用多家公司产品，如果出现问题 分析和定位困难。对此，我们利用性能测试检验客户和系统之间的交互，包括浏览器和GUI 客户端等方式的连接。同时在进行性能测试的时候，将内部各种系统，与其连接的各外部系 统的日志和监控工具全部打开，记录各部分的处理过程，这样当发现性能问题时，便能及早 的定位瓶颈出现的位置；测试环境准备和测试时，请相关厂家的工程师提供现场支持，进行 性能监控和问题分析。

由于采用了适当的测试方法、测试策略和测试工具，总体来看，我们的测试取得了不错 的效果，有力地保证了项目的质量。但也有不足的地方，具体存在以下几个方面：

(1)开发人员的测试观念还不够强。虽然我们制定了良好的单元测试策略，但开发人员 并没有很好地执行，以至于在以后阶段的测试和运厅中受害不浅。

(2)每种测试之前，我们都组织力量充分准备了测试案例，但是在测试数据的准备上， 由于系统的复杂性等多方原因，有些数据准备的不太完备。

要解、央以上问题，我认为首先还是要树立开发人员的测试理念，只有从具体的开发人员做起，才能真正提高测试的质量，其次还要坚决贯彻执行项目中确立的测试方法和策略。 我们从实践中领会到，测试确实可以在保证软件质量方面起到很大的作用。但同时我们 也认识到，测试中还有很多领域和知识点需要继续研究和实践，新技术的发展对测试也提出 了新的耍求和捌k肚．势们j鲁存测滞骊域不陕芹{娶毒．不陕芹空腾一

论ERP系统测试方法和工具的选用

摘醒

本文讨论了某报业的ERP系统项目的测试方法和工具的选用。

该系统是为了引进先进的管理理念，全面提升企业的管理水平为目标而开发实施的。系

统包括企业财务会计、管理会计、生产管理、采购、库存、发行及广告管理等功能，全面实 现报业经营管理的集成。我们的测试包括单元测试、集成测试、确认测试和系统测试，根据 不同阶段分别进行。在本文中首先讨论了采用的测试方案，分析了如何使用工具来完成各种 测试以及产生的效果，然后详细描述了权限测试。最后，讨论了存在的不足之处以及改进的 办法。

在本项目的实施开发过程中，我担任了系统的蓝图设计、系统配置和测试工作。 正文

作为一家大型的媒俸行业，某报业的各项经营业务飞速发展，但同时也存在经营业务缺 乏一个统一、集成的平台，各项业务信息难以集成的状况，同时原有的管理系统已无法满足 线是的需要，不利于领导的、央策，制约了企业的发展。如果不建立与企业规模相适应的管理信息系统，就很难在这个竞争日趋激烈的时代获胜。因此，为了引进先进的管理理念，全面提升企业的管理水平，进一步提高竞争力，、央定实施Ⅱ诤系统项目。

经过较长时间的调研和论证，拢们决定引进SAP公司的RJ3累统。报业不同于传统的制 造业，有特定的经营方式，有自己独特的业务、客户、供应商；有独特的企业文化、政策规 范和经营理念，还有一些重要的成功经验。这些部是无法与线涉及到既诤软件中去的。因此， 在引进R/3时，我们考虑将企业的“个性刀与Ⅱ心软件的“共性”结合起来，走二汝开发的 道路。我们请专业顾问公司协助完成实施，二敞开发基本上由自己的队伍来完成。

SAP的实施项目是个复杂的系统工程，因此我们采用三个阶段逐步实施的方法。第一阶段以 财务管理为主，并与其它系统进行整合，实现SAP系统与业务运作系统无缝的集成。系统涵 盖企业的财务会计、管理会计、生产管理、采购、库存、发行及广告等部门的业务管理。我 有幸参与了该系统的开发与实施，担任蓝图设计、系统配置和测试工作。

ERP系统相当复杂灵活，因此在系统正式上线前做好测试，选择合适的测试工具，尽可 能多的发现各种错误和缺陷，对系统的正常运行至关重要。在项目准备阶段，我们制定了详 细的测试计划，确定测试的进度安排、使用的工具以及这些测试的内容和目的。对标准系统 的测试和二次开发部分方案有所不同。

我们的测试包括单元测试、集成测试、确认测试和系统测试，根据不同阶段分别进行， 在测试前做好各种测试用例。用例清单中包括：交易代码（在RJ3系统中，每个功能分配一 个交易代码，用户输入后进入界面）、步骤说明、测试数据（输入数据）、期望结果、实际结 果和测试状态。

根据系统特点，我们建立了生产系统和测试开发系统，所有设置、开发和测试（除系统 测试）都在测试开发系统进行，确定没问题再通过传输系统传入生产系统。两个系统具有相 同的环境配置。

在测试开发系统中我们建立了三个“client"（是SAP系统中的最高等级），分别为1 00、 200、300，测试流程是：在1 00中配置并测试业务场景和案例；在200中配置，并生成传输请求传到300，在300中测试业务场景和案例。

我们在集成测试和系统测试中的压力测试中采用了SAP ABAP/4开发工作台提供的计算 机辅助测试工具( CATT)。(:ATT具有良好的集成功能和报表功能，使用(:ATT可以减少人

工测试的次数，由系统自动完成测试，并使测试更加系统化（即事先定义测试过程中的输入 值以及预期的测试结果），从而提高系统的质量。所有测试部有日志，根据所使用的测试模块和测试过程的不同，日志中记录按层次结构组织起来，显示成为带节点的结构。日志可以从客户端下栽保存，便于以后查阅。

在集成测试中，我们在CATT中根据实际需要，编制测试过程，测试过程包括任意数量 的测试模块。例如为了测试一个发行过程，我们建立了一个测试过程，包括创建客户、创建 物料（报纸）、报数、生成标准销售订单、发货和开票过账几个测试模块。定义好参数和变

量。其中客户和物料数据在系统外根据测试用例建立文本文件。测试时系统读取文本文件中的数据，每一步生成的数据作为下一模块的输入数据。最后系统生成日志，记录了详细结果。用此结果与预期的结果比较，查找问题。

在压力测试中，我们在文本文件中装入大量数据让系统处理，查看其性能下降的幅度是 否在允许的范围内。

另外，我们在测试中比较有特点的是权限测试。既诤系统是一个高度集成的系统，从生 产、销售到财务，所有的处理和数据都集中管理，因此合理的授权管理是系统安全性实施的 一个重要部分，保证合法用户拥有需要的权限，避免用户使用不应该拥有的权限使用系统的 功能或查看数据。系统采用授权参数文件生成器来进行授权管理，授权参数文件将针对交易 代码及组织结构两个层次。我们对生产系统中的所有用户进行授权，对所有模块及功能进行 授权。上线前所有用户参数文件将传至生产系统。

我们制定丁有效的权限测试策略，每个用户帐号在授权的组织结构中测试能否正常使用 授权的交易代码对应的功能；对于重要的交易和数据着重进行是否有错误授权的测试，主要 分两种：对同一交易，不同组织权限不同，所以特别测试跨组织结构的权限，防止某组织的 用户访问其他组织的数据；有些交易，如某些订单的创建，操作人员可创建订单，但必须由 领导确认释放，特别测试确认释放的权限是否正确授权。对公司的重要统计数据，只能领导 有查看分析的权限，各部门只能看到本部门的数据，所以要特别测试这些部门的用户是否误 分配了权限。

我们利用CATT管理工具中的统计功能查看状态分析报表，以及图形化的测试历史记录。 并将所有测试日志下载到文件中保存下来，特别是有问题的地方，详细登记问题出处、问题 原因和解决方法等。最后根据测试的各种资料完成测试报告，对测试进行概要说明，列出测 试的结论，并作为软件配置保存。

通过各阶段的测试，发现了系统存在的缺陷、局限性，对比较严重的缺陷及时作了修改， 对系统影响不大的缺陷作了修改安排。保证了系统正式上线后的稳定运行。另外，对系统性 能影响的局限在测试报告中作了详细说明。例如，我们通过压力测试，发现当销售订单很多 时，一些统计振表的查询性能会下降，而根据实际业务的情况，在3年的时间订单数会接近 测试时的数。因此，我们建议系统使用到一定阶段，应该做归档处理，这为之后的维护人员 对系统的维护提供了很大的帮助。

当然，还存在需改进的地方。比如我们在确认测试时，用户用日常工作中出现的一些特 殊数据来测试，发现了功能上一个小问题。虽然影响不大，但也说明我们在单元测试和集成 测试中选择的用例还不够，还应该更接近实际，选择一些更真实案例来测试。另外，我们只 用到CATT的部分功能，如果更好的利用它，将会使测试更加便利有效。因此，在以后的项 日中覃特-5~iIX音育A-fil田T且案坦喜T作妁，室．

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

本文以航天嵌入式实时软件测试的过程，讨论了项目开发中测试所使用的方法和工具。 在该项目中，我担任测试经理工作。

嵌入式实时软件因其特殊性，在测试时有一定的困难。目前国内和军队已就软件产品的质量 要求及其测试制定了多项标准，但缺乏符合国内标准的本土化的测试工具，因而在工具的选 取上，主要考虑的是符合国际上航天或军用行业标准的测试工具，及软件测试工具增强软件 测试的自动化程度，和对文档支持的自动化程度。

在编码过程中，我们选用PC-L:int作为代码静态分析工具，辅助编译器进行代码审查。在进行单元和集成测试时，裁们使用了LDRA公司的TestbecVTBrun工具。

我认为，提高测试技术并不单指使用了测试工具进行测试，测试工具的使用可以提高效 率，但过多的强调工具的使用反而会使项目陷入困境。

正文

众所周知，在航天领域安全是最关键的问题，软件的微小瑕疵就可能造成天文数字的巨 额财产损失，甚至对国家安全造成严重威胁。这就使保证软件的质量，保证软件的高度可靠 性，面ira巨大的挑战。

我们单位是航天科技集团某院下属的一个研究所的软件中心，主要从事航天器上的嵌入 式实时软件的研制。裁们的软件是典型的嵌入式强实时软件，基于桌面PC为宿主机，x86系列的386EX为目标机。软件计算量大，任务间时序要求严格，逻辑条件控制复杂，属于大型嵌入式软件。随着软件工程思想的引入，CMM和RUP模型的推行，测试技术和测试方法也逐渐被重视起来。近年我一直从事软件测试的工作，在项目中担任测试经理角色一职，主要负责测试计划的制定、编写测试用例和组织软件测试。

当前我们大部分的测试还处于半手工的方式，没有形成一套自动化系统的软件测试标准 和规范。在软件审查中测试用例简单，不全面。为了尽可能多地找出程序中的错误，生产出 高质量的软件产品，我把测试工作重点放在加强对测试的组织和管理上。

按照软件工程的思想，中间过程产品的高质量，才能导致最终产品的高质量，软件开发 过程中越到后期发现的错误，需要修复而付出的代价就越高。为了确保软件的质量，较理想 的做法是对软件的开发过程，按软件工程各阶段形成的结果，分别进行严格的测试。保证每 个开发过程以最小的缺陷进入下一阶段的开发。为此珑们为测试活动的定义了以下的过程： 制定测试计划、设计用例、实施测试、执行测试、评估测试。并使这些过程协同作用、互相 促进，主要目标是在设定的祭件限制下，尽可能发现和排除软件缺陷。

在组织软件测试上，我们定义了以下的规程。

1、开发人员负责自己开发模块的代码静态分析；

2、开发人员组成小组，相互之间进行代码检视；

3、开发人员负责自己开发模块的单元测试；

4、开发部内部集成测试；

5、独立的测试部门进行系统集成测试；

6、系统测试，较全面的对最终目标系统进行功能验证，做尽可能多地覆盖；

在具体测试过程中，我们分阶段分步骤地采用了一些先进的工具和方法策略。为我们测 试成功奠定了基础。

目前国内和军队已就软件产品的质量要求及其测试制定了多项标准，但缺乏符合国内标 准的本土化的测试工具，因而在工具的选取上，主要考虑的是符合国际上航天或军用行业标 准的测试工具，及软件测试工具增强软件测试的自动化程度，和对文档支持的自动化程度。 在编码过程中，我们选用PC-Lint作为代码静态分析工具，辅助编译器进行代码审查。通过 PC-Lint我们能发现一股的语法错误，检查出那些通过了编译，虽然符合语法要求但不易发 现的潜在错误。如没有被适当检验的数组下标，未初始化的变量，使用空指针，冗余的代码 等等。PC-Lint可以添加用户自定义的检查规则，用来适应新的编码规范。此外还支持命今 行和MAKEFILE方式，可以集成到UltraEdit和Tornad02中开发环境中，或固化到软件开发 测试流程中去，方便开发人员的使用。功能强大，易于使用，性价比高是我们选择PC-Lint 的主要原因。我们发现利用PC-Lint进行代码静态分析，在程序动态测试之前发现编码错误， 可以防止低级错误引入到后期的开发中。通过实践证明这样可以有效的降低软件除错的成本。 在进行单元和集成测试时，裁们使用了LDRA公司的Testbed/TBrun工具。我们测试的

是航天器的控制软件，语句逻辑控制结构复杂，进行白盒测试时，测试的输入量大，是一件十分枯燥且重复性的工作。通过TBrun提供的灵活的测试数据输入方法，测试数据可按范围、 最大、最小及等步长或不等步长方式输入，实现了自动化的环境建立和测试输入。TBrun还 提供了可视化管理用例的方法，我们发现这些方法极大的提高了软件测试人员的积极性，使 测试效率有了大幅度提高。

在测试中我们会常常遇到这样一个问题：在测试初期，一般主要针对功能点语句设计用 例，以检查所期望的功能是否已经实现，这时覆盖率迅速增加，但一般达到70%2E右的覆盖率后，要再提高覆盖率是十分困难的，因灼新的测试往往覆盖了相同的测试路径。这时需要对测试策略做一些改变：从功能性测试转向结构化测试。也就是说，针对没有执行过的路径，构造适当的用例来覆盖。Testbed有效的解决了这个问题，Testbed通过提供调用图与控制流程图，显示被测系统的调用关系及每个子程序的控制流程，在测试阶段，实时显示测试覆盖率，提供检查分析关键因素和优化测试路径的必要信息，帮助用户分析未测试的代码，实现以最少测试用例即可达到覆盖率要求。

Testbed支持自动隔离测试，可自动产生驱动和桩模块。在我们按组合集成策略进行渐 增式集成测试时，在程序结构的高层使用自顶向下的策略，在下面的较低层试用自底向上的 策略时，自动产生桩模块和驱动模块，让我们把主要精力放在了测试用例的设计上。此外， 被测代码修改后对测试用例自动验证，使得回归测试非常的轻松。实践证明了好的测试工具 对于激励测试人员的积极性和创造性，提高测试效率是非常有效的。

嵌入式实时系统的性能测试，我们使用了CodeTest。CodeTest在真实软硬件环境下使用 非采样性测试，可以精确计算出每个函数或任务的执行时间或间隔，所以其测试具有很高的 可靠性。我们仿真实时系统并按照外都事件的序列检查其行为，使用类似于等价类划分的技 术，对事件如中断，控制信号和数据分类测试，并在测试了每种事件后，以随机顺序和概率 将事件传给系统，检查系统行为是否有行为错误。实现了以往难以进行的系统行为测试。 在隔离了任务内部和系统行为错误后，我们用不同的数据率和处理负载来测试系统中通信的 同步和互斥任务，确定任务时序是否正确，根据CodeTest测出的时间作为对应用程序优化的依据，使开发人员可以有针对性地优化某些关键性地模块或任务，以及改善整个软件的总体性能。

总之，软件测试方法和工具的使用，可以提高测试技术水平，对软件质量保证起很大的 作用。但是提高测试技术并不单指使用了测试工具进行测试，测试工具的使用可以提高效率， 但过多的强调工具的使用反而会使项目陷入困境。通过这次软件测试，对我启示很大。觉得 目前我们的测试活动中存在以下的不足和可改进措施。

让软件测试走向规范，应用过程方法和系统方法来建立软件测试管理俸系。其主要目标 是让测试活动中的过程协同作用、互相促进，从而使它们的总体作用大于各过程作用之和。 缺乏对测试工作进行度量，对测试效果进行评估，原因是缺少一个有效的度量数据收集和分 析木n．制．叉寸测浩；并行弯量和；平估全杩六的促；井软件讨程曲；井的她里． 论分布式数据库的设计与实现

摘要

分布式数据库系统把应用所需的数据存放在多个数据库服务器上，完成某个数据操作要 涉及到访问多个服务器，这适用于某种特定需要的应用。我在主持设计开发的一个MIS系统中，为了达到了在低速网络通道下有效提高应用程序性能的目的，使用了Sybase的分布式数据库技术。我设计的这个系统是采用典型的C/S结构，但许多客户端连接服务器的网络

采用电话线拨号，速度有限，传统Windows界面的客户端应用程序相应速度比较慢。考虑到B/S结构也避免不了大量数据从服务器端传输到客户端，我认为WEB界面并不能有效解、央这个问题，所以采用了优化数据库结构的方法，把数据分两部分存放，基础数据放客户机，会员资料主要采用键码放服务器，应用程序再现数据时从服务器取键码，到客户机取对应的解释，由于键码的数据量少，网络传输便快。在构建这个分布式数据库系统的过程中，我着重研究并解、央了数据同步和事务协调的问题，取得了良好的应用效果。我认为，分布式数据库系统的技术在Intenet时代正当其道，大有发展前景。

正文

分布式数据库系统把数据存放在多个数据库服务器上，当应用提取所需数据时，要访问 多个服务器，综合多焦数据才能完成。

分布式数据库技术在很多场合得到了应用。譬如某企业随着业务量的扩大，原有数据库 服务器已经达到了容量和性能极限，如果不希望丢弃原有投资，可以建立另外一套新的数据 库，跟原有的系统组成一个分布式数据库系统，给应用提供透明统一的数据访问。还有，如 果某企业分成多个业务部门，而且地域分散，可以在某个部门放置单独的数据库服务器，用 于存放该部门最常用的数据，而部门和部门之间相互引用的数据可以通过分布式数据库技术 来方便地完成。分布式数据库不是简单地把集中数据库分散实现，而是针对某种特定应用需 要而诞生，它必然具有自己特有的性质和特征，需要在上面做许多的工作，来满足应用的要 求。

我在设计、开发一个MIS系统时，针对应用的需要而引入分布式数据库技术，取得了良好的效果。

该系统针对会员资料的管理而设计，用于管理会员入会、缴纳会费、申请资助、办理资 助审批、关系转移、退会和注销手续等等业务流程。分三个级别的应用权限一一基层单位级、 总公司级和集团公司级，各个级别只能操作各自范围内的业务数据。该系统采用典型的C/S 结构，后台数据库采用Sybase，前端应用采用PB开发工具来设计标准的Windows操作界面。 我茌其中任系统分析和数据库设计的角色，担任了调查业务需求、业务建模和数据库建模、 数据库设计以及指导应用程序测试、优化系统和应用的性能等等一系列工作。

由于客户端地域的分敌，遍及多个省境内，许多使用该系统的基层单位连接服务器数据 库的网络采用电话线拨号方式，速度有限，在使用客户端应用程序时感觉界面速度很慢。经 过分析，认识到许多操作都要从服务器中取数据，速度慢就慢在数据访问上。服务器是没有 性能瓶颈的，问题出在网络速度上。不可能要求众多使用客户改善和升级他们的网络，只能 充分挖掘软件的潜力，来适应这种低速网络的使用模式。

经探讨，结合关系数据库的知识，认识到，应用程序的每一次数据库操作，都要访问多 个相关联的表，其中，有会员资料表和基础数据表，会员资料表中存放许多的键码值，在基 础数据表中有键码相应的解释。键码值的数据量比较少，而基础数据是静态的，几乎不会更 改。如果考虑把会员资料放在服务器上，基础数据放在客户端，当应用程序中访问数据时， 总是从服务器上存取会员资料，从客户端提取会员资料中键码的相应解释。由于键码的数据 量少，便减少了网络上传递的数据量，从而提高了界面的响应速度。

同时考虑到基层单位总是操作自己所餍的部分会员，增删转移操作少，会员列表比较固 定，而每一项业务操作都涉及到要从会员列表中查找定位到某个会员，所以会员列表是最常 访问的数据项。把会员列表从会员资料数据中抽取出来，也放置在客户端，这样，便进一步 改善了性能。

把数据分散存放只是工作的第一步，接下来要考虑应用程序怎样访问这种分布式数据。 开发应用时，如果每一功能都针对两个数据库进行，就带来了很多麻烦。所以，我们研究了 Sybase的分布式数据库技术，决定采用了CIS（组件集成服务）部件，来合并两个数据库成

一个统一的分布式数据库。应用程序只要连接一个数据库，就可以透明统一访问到两个数据 库中的数据。

该技术具俸实施方法是，在客户端数据库中建立一个对服务器数据库的远程访问服务名， 包含访问地址、登录用户名、登录密码等等关键的连接信息；并且对服务器中会员资料数据 表建立一个本地代理表，结构和服务器中远程表完全一样，它是访问服务器中会员资料的中 转和代理。客户端应用程序访问本地代理会员资料表时，实际上是通过预定义的远程访问服 务名中包含的连接信息到服务器中对应的实际会员资料表中访问数据。这种访问对于客户端 完全透明，感觉不到是从物理上独立的两个服务器中存取敦据。所以，这种数据库结构是典 型的分布式数据库。

部署这种分布式数据库不是难事，只要在客户端和服务器上安装12.0版以上的数据库服务器，在客户端服务器上建立远程服务名和代理表即可。由于Sybase数据库的安装支持脚本方式，在客户端应用程序的标准安装过程中，嵌入Sybase数据库的安装和配置脚本，就自动化地完成了所有工作。

在实际使用该分布式数据库系统的过程中，遇到了几个问题。第一，数据同步。客户端 基础数据不是绝对静态的，也有变化，因此在服务器端要设置一个统一的基准，称为主点数 据。客户端总是复制使用，称为复制点数据。如何及时感知到服务器端主点数据的变化，有 效率地复制到客户端，是个难题。Sybase针对这种应用场合，提供了复制服务器技术，但为 了避免过于复杂，我们实际采用应用程序来管理同步。当服务器端主点数据有了更改时，保 存一个相应的标识和时间戳，客户端应用在登录服务器时，检查这种标识，一检测到了数据 有更新，就首先下载，然后再进入系统正常使用。这种方法实现起来，增加了额外的开发量， 且不能判别绕过应用程序对数据的直接修改，但是，是最简单和有效的方法。

第二个问题是事务协调问题。物理上独立的两个数据库．在协同操作时，如果服务器正 好停机或者网络故障，完整的一个事务没能完成，就会“事务崩溃”。虽然Sybase CIS内嵌 了两阶段提交技术，能够自动恢复。但是应用程序在这种情况下，敏感性不够，操作界面会 无端凝固，影响了使用的方便性。我们针对PB对于连接的判断和感知，用了一个小小编程技巧，使应用程序能够及时感知到数据库连接故障，及时停止和恢复事务，使操作界面表现友好灵活。

以上遇到的这些问题，部找到了解决办法。分布式数据库技术的应用并不是非常复杂， 它往往为解、央特定问题、满足特定需要而被采纳，使用得当，会给应用带来了许多便捷。 在当今信息社会里，互联网络带来了相互连通的便捷，而且知识爆炸，数据的分布式访 问是个必然趋势。潮流兴起的XML技术，提供了各种平台数据库之间的一个公共数据访问标准．可音旨A田实构建事加习活、活廓忡事{昌的4>-布寸射堤匿桔术．

论分布式数据库的设计和实现

摘要

本文论述《金蚕工程》的分布式数据库的设计和实现。该项目的设计目标是实现企业间 茧、丝等的合同交易（交易规则和期货交易一样）、实时行情和成交数据的发布、茧丝质押和质押数据的发布。所有功能均要求既能在企业局域网交易大厅和Intemet上进行，许多功能又要在苏州和成部分中心进行。系统从设计时就把基于分布式数据库应用的可用性和可靠性作为系统一个关键目标。为了达到系统的上述要求，系统分别从数据库设计、应用数据集成和测试以及分布式数据库部署等做了大量工作。针对上述各部分，本文论述了分布式数据库的设计和实现及遇到过的典型问题和措施，最后对系统改进，谈一些自己的体会。

在项目开展期间，我担任了系统分析、系统设计与关键模块的编程等大量工作。该项目 在20xx年通过了浙江省软件评测中心的评测。

．正文

我于20xx年底到20xx年6月组织了中国茧丝绸市场由国家经贸部资助的《金蚕工程》

一、二期项目的开发。由于原有系统存在如下问题：（一）原有系统采用传统C/S结构，客 户端运行在DOS平台，后台使用Foxpro数据库。系统处理慢，前后台数据一致性，并且 IFoxpro服务器在交易高峰经常莫名翼妙的死锁和Down机。（二）市场是中国最大的茧丝交 ．易市场，由于会员单位不断增加，原有远程电话拨入设备严重不够用，系统又不能通过 Internet连接访问，进行合同交易和行情的及时查询，严重限制了市场的发展。（三）原有 系统只部分实现了合同交易和资金清算，功能和企业发展不相适应。（四）由于会员在地区上分布不均匀，为了更好地服务于会员要求在满足一定条件下建立分中心交易系统。在这种情况下，市场、央定开发基于Internet B/S结构和基于Xnetserver通讯中间件（类似IBM :MQSeries的通讯中间件）的4-Tier结构的综合软件，分中心采用基于分布式数据库地应用 系统。一期项目包括：基于4-Tier的合同交易系统和资金清算系统，基于Internet的行 n睛查询和信息发布的企业网站。二期项目包括：茧丝质押、仓库管理系统、 Internet质押查询系统和分中心交易和资金结算系统。

鉴于该项目业务比较复杂，流程比较多，系统要兼顾企业交易大厅会员、远程Interne．t 交易的会员和分交易中心会员，项目完成时间短等特点，为了既要项目的按期投产又要实现 基于分布式数据库的分中心交易和资金结算系统，我从敦据库选型、数据库设计、应用数据 集成和测试以及分布式数据库部署如下工作。

(1)数据库选型。现在的主流数据库一般部可以按分布式进行部署，例如：SQL Server, Or acle, Inf ormix和DB2等。由于一期项目的数据库平台是选择了Oracle 7.0，经过了近 一年的运行，其数据自动备份、多用户并发处理性能、磁盘表空间管理、Web数据发布等表现良好。我公司又由于开发过基于该平台的分布式应用系统，公司对其分布式实施也有相当的经验，所以经我们开发部相关人员的讨论，我决定在各分交易中心继续采用Oracle数据库来实现，其分布功能主要基于 S Q L大NET来完成。

(2)分布式数据库设计。由于各交易品种的每节交易价格由市场的交易大斤决定，所阱 各分中心必须在每节交易开始前取得相关的交易数据。各分交易中心必须保瞽其会员已经交 易成功的买入和卖出交易数据，并根据会员需要进行资金结算。经对分交易中心充分业务需 求分析后，我觉得分交易中心的主要功能还是和主市场交易中心（简称：主中心）功能是一 致的，只不过分交易中心的会员数比较少和无需保留各节的历史交易行情，所以，分中心的 主要数据库中的各表还是照搬主市场数据库的各表．分中心只保留各自的会员基础数据和成 交数据，保瞽会员历史交易数据，只保瞽当前的各节的交易行情，不保督历史行情。主中心 必须保督各分中心的各项明细数据，主中心也必须及时计算分中心会员的汇总资金，所以主 中心必须增加分中心汇总资金表。

(3)数据集成。为了保证分中心及时下单，必须保证每节的交易行情要及时的传送到各 交易分中心。节处理最后一步必须把下一节的交易行情传送送各交易分中心。同时下发给分 中心的数据还有，分中心本节各会员的成交数据。由于主中心保瞽各分中心的各项数据，所 以，分中心有新的会员加入必须同时更新分中心和主中心数据库；分中心会员资金有变动时 也必须同时更新主数据库。由于各会员只能在当日交易结束后才能进行数据平仓，所以分中 心平仓数据汇总后同意发送到主中心进行平仓。在上述设计的数据库到数据库操作的数据完 整性和一致性由数据库的二阶段提交(2 Phase Comit)来保证。由于Oracle是一个比较

成熟的数据库平台，又由于每次事务部不大，所以运行到现在也没有发现数据不一致现象， 没有出现“单边帐刀，数据处理也比较快。为了近一步保障各中心数据的一致性，我还做了

一个同步程序，由主中心发起，对主中心和分中心敦据进行比较。该程序可定期进行。

(4)测试。由于一期项目已经运行了相当长的一段时间，系统已经相当稳定了。由鉴于 2 Phase Commit出色表现，所以基于分布式的测试没有觉得和集中数据库有太大的区别。唯 一的感觉是在第一次建立远程数据库连接时，连接速度比较慢（有时超过20秒）。为了提高 测试速度，我在同一个局域网中安装了三套Oracle，分别充当主中心和两个分中心进行测试。

(5)部署分布式数据库。和集中时式的数据库不同，采用分布式系统，必须配置SQL kNET。其他的Oracle组件和子系统安全同本地安装数据库一样。

分布式数据库在逻辑上属于同一系统，使得应用不必关心远程数据库的物理位置，就可 以像访问本地数据库一样访问远程数据库。采用分布式数据库可充分提高系统的处理能力、 均衡网络负载，所以该分布式数据库应用方案在银行代收、代付业务处理、保险代理点等单 位和机构中大量采用。但由于近些年来通信基础建设比较迅速，特别是2M、10M和100rt光纤的推广（100M广电月租费仅为800元），又为了节省下属网点的机房费用，各单位又不约而同的采用的集中方案。

【缺点I和需要磅瞪￡的ltllh】

(1)分中心或主中心白于不明原因而Down机后，由于Oracle有自动恢复功能，可能造成对 方数据库会收到过时的垃圾数据。该问题现在通过手工方式解决。

(2)由于分中心没有收到下一节的交易行悟，可能会造成分中心会延时交易。分中心的主控 系统可通过主动拉取数据来解决。

【结瓣】

《金蚕工程》项目是成功的，年交易量已经有100多亿人民币。通过该项目的顺利投入 运行，中国茧丝绸市场不仅牢牢把握住了中国的茧丝行情，随着我国进入WTO，中国茧丝绸市场在世界上也有举足轻重的分量！总之，中国的软件产业应该走自己的路，只有通过“已过程为核心，以度量为基础，已人为本”的管理政策；根据我国的国情、软件业和公司的现状，只有通过“干刀，才能有实绩，才能实现“以信息化带动工业化的大思路”！ 论分布式数据库的设计与实现

摘要

本文通过xxx高速公路收费系统（以下简称收费系统），来论述分布式数据库的设计与实 现。收费系统是我公司近年来接的较为大型的项目，管理结构为三层结构：公司级、收费中 ·心级、收费站级，各级之间即可独立的完成自身业务，又有自上而下的管理关系。收费中心、收费站均为三层C/S结构，公司级采取B/S结构。该系统的数据库也按照三层来设计，收费站存放本站的所有流水数据，收费中心存放所有数据，公司本部存放查询用汇总数据，收费站与收费中心使用事务复制来同步数据，而收费中心与公司本部使用快照复制来同步数据，并且使用分级的方法来测试收费站、收费中心与公司本部之间的数据同步。 在本项目的开发过程中，我担任了数据库的设计工作。

．正文

20xx年10月-20xx年12月我公司开发了高速公路收费系统（以下简称收费系统），收 费系统项目从管理层面分为三层结构：公司级、收费中心级和收费站级。

公司本部：供领导、运营部、财务部等业务部门了解业务情况、检查工作。B/S结构各 部门通过Web服务器查询数据库服务器，而公司数据库服器定时要求中心数据库服务器复制汇总数据。

收费中心：收费系统的管理中心下达管理制庋，管理数据到收费站，接收统计收费站的

I收费数据，上报汇总数据到公司，负责日常的管理工作。

收费站：具俸进行收费的单位，收费车道的数据通过通信系统实时上传到收费站数据库 保存、分类、汇总，并且实时传送收费中心下达的数据库管理，并通过通信子系统下载到车 道收费机上具体实施。

系统采用三层C/S与B/S的混合结构，收费中心与收费站为三层C/S结构，而公司级为 IB/S结构。我在项目中担任了数据库的设计工作，负责数据库的设计、测试及实施。 i数据库.设计

此收费系统的结构较为复杂，分为公司级、收费中心、收费站三级管理结构，既可独立工作，又有管理的联系。数据实时传送到收费站数据库服务器，再实时传送到收费中心数据库服务器。 在数据库设计方面我们按物理的分布也分为三层结构。

在收费站，根据系统的需求分析的结果，一辆车通过收费站时产生的最基本的数据有：通过日期、时间、车型、收费类型及收费金额，因为收费标准不轻易改变，考虑到我们采用的是专用的车道收费机，存储量较小，所以收费金额项在此处不计入数据库，上传至收费站数据库服务器后，可以用车数乘以此类车型的收费标准而得到。当车道收费机上传数据到数据库时，还要加上工班、车道及收赛员信息，保证数据的唯一性，所以我们把日期、时间、工班、车道、收费员、收费类型、车型设为组合主键，为车辆流水数据。收费员下班后还要上缴实收金额，因此还要保存实收金额，包括日期、工班、收费员及实际收费金额，为工班收费数据。在此基础上，分析、汇总数据，得到以下几类数据：

业务类型数据：车辆流水数据、工斑收费数据、车道开通情况、收费员上班情况；

扩展的数据：为了查询、打印的方便、高效，流水表经过分类汇总，产生了以车道分类统计 的车流量表（日、月）、以收费员来分类统计的收费金额表（日、月）及不收费 车辆统计表；

管理类型数据：收费标准、收费员信息、收费站信息、车道信息、工斑信息、收费类型信息； 从全局应用的角度出发，各收费站存放本站的数据，收费中心的数据库则存放所有数据， 并对数据进行完整性和一致性的检查，这种做法虽然有一定的数据冗余，但在不同场地存储 同一数据的多个副本，能提高系统的可靠性、可用性，使系统易于扩充，也提高了局部应用 的效率，减少了通讯代价，同时也使得各处理机之间的相互干扰降到最低。

公司总部存放所有收费站的汇总数据，通过浏览器进行查询。

数据的分布

(1)在收费中心数据库服务器与收费站数据库服务器的敦据关系中，由于收费站的数据 是收费中心数据的子集，我们采用了水平分片的方式，通过并运算实现关系的重构。

(2)在收费中心数据库服务器与公司总部数据库服务器的数据关系中，数据是按照其应 用功能来划分的，所以我们采用了垂直分片的方式。

公司本部

收费中心

收费站

管理

据

┏━━━━━┳━━━━━━━┓

┃ J ┃L ┃

┃ ┃汇总数i ┃

┣━━━━━╋━━━━━━━┫

┃ ┃ ┃

┣━━━━━┻━━━━━━━┫

┃中心服务器 ┃

┣━━━┳━━━━┳━━━━┫

┃ ┃ 一 ┃L ┃

┃型数 ┃ ┃业务； ┃

┣━━━╋━━━━╋━━━━┫

┃ 1 ┃r ┃ ┃

┣━━━┻━━━━┻━━━━┫

┃收费站服务器 ┃

┗━━━━━━━━━━━━━┛

数据同步的方式

（快照复制）

据 （事务复制）

数据分布在多个地点，为了保证数据的一致性及完整性，我使用了事务复制和】快照复制两种数据同步的方式，在收费中心与收费站之间使用事务复制，而在收费中心和公·司总部之间使用快照复制。

对于业务类型的数据，收费站在本地存放收费车辆的实时数据，而用户也要球刈史费中心 也要实时的收费车辆数据，延迟不超过2秒，所以我采用事务复制进行业务数据的同步，收 费站只需将更新的数据发送到收费中心的数据库即可。具体过程如下，把收费站的数据库作 为出版者和分发者，收费中心的数据库作为订阅者，对收费站的数据建立快照代理，并在分 发数据库中记录同步状态的信息。每一个使用事务复制的收费站数据库均有自己的日志读取 代理，运行在分发者上并连接出版者。分发代理的任务是将分发数据库中保持的事务任务直 揍推动到订阅者。当推订阅被创建时，每个为立即同步而建立的事务出版物通过自己的分布 代理运行在分发者上并与订阅者相连。

而管理型的数据是在收费中心设置，虽然修改的频度不是很大，但在修改后即要发生作 用，所以也采用事物型复制，收费中心为出版者，收费站为订阅者。将管理型的数据发布到 各收费站。

由于公司总部不需要实时更新，所以收费中心数据库服务器与公司总部服务器之间的数 据同步设置为快照复制，公司总部数据库中建立收费中心表的快照，对这些数据的修改在收 费中心进行，把收费中心数据库服务器设置为出版者，出版物为汇总数据，公司总部数据库 服务器设置为订阅者，快照代理将准备包含有被出版数据表的结构与数据的快照文件，在分 发者上存储这些文件，并在分发者的分发数据库中记录同步任务。在收费中心数据库服务器 上建立一个作业，设置为每天早上8点更新一故（收费日的天为8点到第二天8点），公司总部就能得到截止到前一天所有收费站的汇总数据。

测试

数据库设计好了，就要对它进行测试。我们的测试策略为分步测试：首先测试收费站数 据的正确性及完整性，在多台收费机上同时输入几组车型、收费类型的数据，查询数据库的 流水数据是否正确，再看汇总数据是否正确：收费站正确后，再测试收费中心的数据的正确 性、完整性及延时；再测试公司总部的数据正确性、完整性。

一开始我们把所有的表部建立在一个出版物中，但在测试中转们发现，由于收费站一个表 的错误而造成的复制的中断，经常要重新配置复制，所有的表都要重新选择及设置一遍，非 常繁琐，我们采取一个表建立一个出版物的方法来简化操作，只要恢复出错的复制，其他的 复制仍然能正常执行，而且哪一个表的复制发生中断也很明确，不仅简化了操作，也加快了 处理时间，就是日后用户维护起来也简单明了。

在设计过程中，基于查询及安全性的需要，我们大量的使用了视图，第一加快了查询速

度；第二也防止了人为因素造成的数据的更改。

总结

按照以上的设计方案实施后，完全满足高速公路系统对数据实时性和完整性的要求，系 统目前只在内部使用，而以后全省的高速公路收费系统实行联网，在外网上发布信息，那时 持埋的害全幛碍杏；句的晌商；童窿，皇旱势们若由的雷占一

论基于WEB的系统测试策略

摘要

我所在的公司是某省电信公司。20xx年初，公司构建了互联网宽带增值业务计费平台。 该系统的目标是利用电信营运网络、用户资源和品牌优势，为各ICP和ISP提供统一门户、 统一认证和统一支付的营运平台。系统业务功能多，与传统的电信业务系统的接口多，性能 和安全性要求高。系统选用了微软公司的．NET开发平台，经历了多个测试阶段。根据系统的特点，本文重点讨论了我们在单元测试、功能测试和性能测试中采取的措施和策略，以及如何保证测试的充分性，并简要分析了基于Web的系统测试与传统的软件测试的不同之处。 我作为主要的技术负责人之一，参与了系统的技术选型、方案设计、需求分析和系统设 计等工作，也参与了系统的测试过程。

正文

随着互联网的发展，一方面ICP（内容提供商）和ISP（服务提供商）有好的内容和服务， 却苦于没有收费渠道；另一方面，用户希望使用有价值的内容和服务，却没有便捷的支付手 段。互联网从免费转向有偿服务已成为一种趋势和必然。为此，我所在的某省电信公司于20xx年初构建了互联网宽带增值业务计费平台，其目标是，利用电信营运网络、用户资源和品牌优势，为爸ICP和ISP提供统一门户，统一认证和统一支付的营运平台，创造互联网用户、ICP/ISP和电信营运商的多鬲价值链。

系统选用微软公司的．NET开发平台，采用了B/S三层架构设计：表示层、业务逻辑层和数据层。表示层负责处理系统与互联网用户、ICP/ISP以及业务管理人员的交互接口；业务逻辑层负责系统处理业务逻辑的所有COM+组件组成；数据层是存放用户信息、业务信息和计费信息的关系数据库，采用微软公司的SQL SERVER。系统业务功能多，与传统的电信业务系统的接口多，性能和安全性要求高，项目建设时间紧。

根据系统的具体特点和应用要求，我们仔细分析了业务流程和系统的应用环境，确定系 统的测试要素，并据此编制项目测试计划、测试用例和测试脚本，将系统的测试划分为单元 测试、部件组合测试、功能测试、性能测试、安全性测试和验收测试，重点关注了单元测试、 功能测试和性能测试。下面就此作详细介绍。

首先，我们考虑项目测试组的成员不仅限于测试工程师，还请到了相关业务人员加入到 测试队伍中。业务人员可以从实际业务的角度参与到测试数据和测试用例的准备工作中，并 帮助分析测试结果，发现与实际业务相关而测试人员容易忽略的问题。

由于系统复杂、业务功能和接口蘩多，因此我们从一开始就非常重视单元测试。在单元 测试阶段，我们采取了开发人员自己编写测试用例、小组人员交叉评审和测试组抽查相结合 的策略，以避免测试用例的片面性，同时要求单元测试应紧接在编码编译通过之后。

单元测试我们采用了NUnit自动化测试框架，用它在．NET类上创建和执行自动的单元测试。我们知道，,NET引进了一个新的程序开发的概念-Attributes(属性)，让开发人员可 以在程序代码之上再加入Metadata(元数据)。Attributes主要使用在documenting your code(注释你的程序代码)，也可以用来提供有关Assembly的额外信息，NUnit中的Test

Runner会扫描已经编译好的程序代码，并且从Attribute里面知道哪些Classes是Test: Classes，哪些Methods是需要执行的Test Methods。然后，Test Runner使用,NET的

Reflection技术来执行这些Test Methods。这大大减轻了测试人员的工作压力，也有效地 保证了单元测试的可靠性，为后续测试的顺利进行奠定了坚实的基础。

系统的功能测试，我们主要考虑了页面链接测斌、表单提交测试和数据库测试。

在系统提供的统一门户上，有互联网用户的网上家园和用户定制服务，也有电信营运商 提供的宽带增值业务，更多的是合作I(:P/ISP的产品和服务。为了用户能通过统一门户查询、 购买和使用各项服务，就必须保证站点所有链接的正确有效。我们采用了以前开发互联网智 能搜索引擎项目的一个衍生产品一一链接自动测试工具，它能自动检查、分析站点内所有页 面链接，并生成一份详细的清单，报告链接页面是否存在、哪些页面未作链接等。这基本上 不会带给测试人员工作量。

对于表单提交测试和数据库测试，我们采取了运行测试的方法。测试之前，依据系统需 求分析，对每一个交互功能页面设计测试用例，重点关注关键页面的测试用例，如用户注册、 登录、支付、服务目录等页面。测试针对提交操作的完整性来进行，以校验提交给服务器的 信息的正确性，同时检查数据库存取时数据的一致性。例如：用户密码要求长度不低于8位

的非数字字符和数字组合，并区分大小写。测试时我们分别用8位以下、8位及8位以上的 非数字字符、数字字符及其混合型进行测试。另外，如果表单只允许接受某些指定值，或使 用了默认值，还必须检验指定值和默认值的正确性。

对系统的性能测试．我们采用了Webstress测试工具，从连接响应速度和负载两个方面来进行。在连接响应速度测试时，通过测试工具模拟单机访问，我们发现某些组件和页面响应速度较慢。经过分析，我们进行了相应部份的代码优化、SQL查询优化，并对应用服务器调优，采用了数据库连接池技术等，系统性能得到了明显改善。负载测试时，通过测试工具模拟多用户访问系统，检查系统所能承受的极限访问量。测试中，我们将系统各个部份的日志和监测工具全部打开，在并发用户数逐渐加大的过程中，记录系统在事务处理、CPU负载、 内存使用等方面的变化情况，借助这些数据查找并分析系统的性能瓶颈，采取针对性的改善 措施。

由于系统功能多，与外部系统有大量的接口，系统建设时间紧张，而系统又是为互联网 用户和合作I(:P/ISP提供统一门户和计费服务。测试是保证系统质量的重要手段，测试的质 量直接关系到项目的成败。为了使系统在功能、性能、兼容性、安全性以及页面风格和整体 布局等方面有更进一步的测试，保证系统在投入运营前测试的充分，我们将系统布暑到实际 生产环境，接入了多家合作I(:P/ISP的服务，同时在门户上开通了用户在线反馈系统，通过 举办有奖专项活动鼓励用户使用泵统并反馈系统的错误和缺陷，同时安排专人响应并整理用 户的反馈，及时交由开发人员修改。实践证明，这是非常有效的方法。

从系统的实践中，我俸会到基于V/eb的系统测试比传统的软件测试要困难得多。基于 V/eb的系统在网络环境、用户范围、使用环境等方面部比传统的软件系统复杂，在测试时必须更多的关注系统的并发性、兼容性、安全性和可用性。同时，基于VVeb的系统比传统的软件有更短的发布周期，测试人员和测试管理人员面临着从测试传统的(:/S结构和框架环境到测试快速改变的Web应用系统的转变。

目前，软件开发正在向基于Web的应用发展和转变，这对测试工作提出了新的要求和挑战。测试技术还有很多领域和知识点需要我们去研究、探索和实践，并在实践中不断总结和提高。

企业应用集成的实践

摘要

为了向铁路各部门用户提供高可用、整合的信息，受铁道部科技司委托，裁单位承担了 “信息应用集成的研究”这一项目的研究和开发工作。本人作为该项目的负责人之一，担任 了方案设计师的职务。该项目的目标是实现现有系统中的数据共享，有机的结合相关联的数 据，搭建统一的使用平台，为今后铁路信息化更大规模应用集成建立可行、可靠的依据。本 文主要从以下三个方面描述作者在该项目中的工作：确立企业应用集成的解、央方案；选择应用集成规范和平台；在现有的铁路信息系统中选择二至三个，对应用集成的方案进行实践， 分析并改进方案。

正文

近年来，铁路信息化建设取得了突飞猛进的发展，特别是正在建设实施中的“铁路运输 管理信息系统（以下简称llKIS）’’工程。nKis是实现铁路运输管理现代化的一项重要工程， 覆盖了铁路运输组织管理的各个环节。从功能上来看，1lKIS以货运管理为核心，分为列车预确报系统、货票系统、车号自动识别系统、货运营销和技术计划系统等多个子系统。从组织结构上看，nKis由铁道部、14个铁路局、50个铁路分局和2000多个车站四级组成。目前， TMIS已经成为一个由多个子系统构成的、庞大的多级分布武应用系统。

在部、局、分局的数据库中，已经建立了能够实时接收数据的货票库、确报库和车号自 动识别库。货票库主要用于货物运费清算、确报库主要用于实时掌握调度行车信息、车号自 动识别库主要用于车辆位置查询管理。为了实现列车、机车、车辆的实时追踪管理，必须共 享各子系统数据；同时为了实现各级子系统的应用集成，必须选择一个开放式的应用集成规 范和平台。为此受铁道部科技司委托，我单位承担了“信息应用集成的研究”这一项目的研 究和开发工作。由于在TMIS工程建设中的多年工作经验，特别是在货票子系统中担任系统设计师的工作经验，本人有幸成为“信息应用集成的研究刀项目的负责人之一，担任了项目方案设计师的职务。

经过分析，我对该项目的目标总结如下：为实现现有各系统中的数据共享，有机的结合 相关联的数据，应确立企业应用集成的解、央方案；为实现各级子系统的集成，建立统一的应用平台，应选择一个开放式的应用集成规范和平台；为建立今后铁路信息化大规模企业应用集成可行可靠的依据，应在现有的铁路信息系统中选择二至三个，对应用集成的方案进行实践。

下面我就从三个方面对企业应用集成的实践进行描述。

一、确亩仆_怀讲丑集威的謦秧方案

从集成的深庋上来说，本方案包含了数据的集成，同时也包含了应用系统的集成。企业 应用集成常用的方法有：基于客户端／月艮务器的方法、基于消息代理的方法、基于应用服务器的方法等。在这里我选择了基于应用服务器的方案，即通过建立独立的底层架构来连接企业的异构系统、应用数据等。如图所示：不同的子系统通过不同的适配器连接到应用集成服务器，应用集成服务器内部通过消息传递实现不同应用之间的交流。

从集成的广度上来说，本项目涉及部门之间的系统集成，同时也涉及了企业不同级（部、 局、分局、站段）的系统集成。为了保证各级系统的数据一致，加强各级之间的交流，应该 从整体来考虑企业的集成方案。较好的方法是选择一个开放的集成平台，把不同级的应用纵 向的结合起来，通过统一的门户信息网站向外发布信息。

目前，开放式企业应用集成规范和平台的主流技术有两种：微软公司的COIK+规范和 Windows DNA平台；SUN公司的EJB规范和丁2匝平台。由于J2IE架构的与操作系统无关的

特性，为了更好的支持现有的不同级的系统，我选择了EJB和J2EE的组合。如图所示：系统采用IKVC的设计模式。Jsp所在为表示层，提供数据的展示功能；Servlet所在为拉制层，处理表示层与业务层的关系；业务层由多种Bean组成，Session Bean处理交互相关的信息， Transaction Bean处理具体的业务逻辑；Entity Bean与数据层交互。

三、应用集．舫案的实哉

为了实现列车、机车、车辆、货物的实时追踪管理，需要在现有的几个系统中提供近乎 实时的系统集成和数据集成。这些系统包括：货票系统提供了货物的名称、重量、装货车辆、 发送人、收货人等信息；车号自动识别系统提供了车辆的位置等信息；确报系统提供了列车 的车次、机车号、车辆号等信息。应用服务器通过编写各自适用的适配器连接这些系统。 应用服务器上有一个匹配作业，当车号自动识别数据入库时启动的该作业，通过车号和 通过时间，在确报库中匹配该车所在的列车、机车等信息，然后在货票库中匹配货物的名称、 收发货人等信息，匹配后的信息写入动态追踪库，至此一次作业完成。同一时间段内，应用 服务器上有可能有n个等待匹配的作业，依次放在消息队列中，通过编码实现的应用集成程 序统一调度，消息队列的实现选用IBM的htQ series。

企业不同级（部、局、分局）的系统之间的数据更新不同步，造成各级之间的矛盾，通 过数据同步服务器的加入，买现三级数据的有机整合，保证数据的一致性。

数据同步后写入中央数据库，由三台集群的web服务器向外发布信息。同时满足铁道部、路局、分局用户的使用，包括货票信息应用、确报信息应用、车号自动识别信息应用和动态追踪综合应用。编码工作量相对较少，系统响应时间快。

企业应用集成后，实际的效果证明本项目的系统方案设计到达了项目目标的要求，横向 能够集成不同系统的相关数据，纵向能够提供统一的应用平台。并且扩展方便，通过编写新 的适配器，可以集成新的应用系统；通过广域网和局域网的建设，能够加入更多的用户。同 时，集成后的新增的动态追踪系统也成为越来越多用户的热点应用。

应用系统集成后，信息通过相对统一的界面向外发布。由于用户的部门和级别不同，因 此主要关心信息的角度各不相同，所关心信息的内容也有所不同，用户可能需要多次选择或 点击才能得到想要的信息。引入XMI．技术，实现个性化的展示层，方便用户的使用，是我在

；玄而日CtlC#i下一个T4E日标一

论软件需求分析方法和工具的选用

【摘要】

本文通过一个集成电路设计有关的软件项目，讨论了该项目的主要特点和本人所担任的 工作，着重讨论了在项目需求分析过程中采用的具体方法和工具以及选用的理由。 由于项目的专业领域的特殊性，分两类不同的需求讨论了需求分析中遇到的问题及 解、央方法；在这个过程中给出了对选用的具体工具和方法的效果的描述。接着本文讨论了对使用方法的改进的一些想法以及具体的实现过程。最后提出了我对需求分析的某些看法，强调了与客户沟通的重要性。

【正文】

近年，我一直从事某企业中有关IT项目的开发，有一个系统是用于计算机辅助电路设计的，包括了从上流设计（注：日式说法）到下流设计（注：日式说法）的所有流程，如用于可设计百万门数量级的逻辑门电路。有关方面把电路中路径的提取、过滤以及表示的某软件开发任务交给我公司，我有幸担任了该部分的需求分析以及设计。

我所设计部分为一单独可启动的软件，主要是解析文件中的连线路径，以列表视图和用 直方图等把它们显示出来，还可以执行诸如查找与过滤等功能。

委托方对此提供了很初步的需求说明，把一些基本功能及性能要求描述了一下。我在需 求分析时的工作主要有两点：第一，对该软件的霁面等详细需求要自己重新进行分析提取。 第二，对于已提供的功能要求需要深化和细化，以形成真正完整的需求分析文档。

在接到需求分析任务后，我分析了一下所要完成的工作。发现由于是专用领域的软件， 对专业领域要求相当高，所以准备把此项目分成两部分：

(1)界面所受专业领域影响几乎没有，但由于全部没有任何要求，反而会感到风险和改 动可能是最大的。

(2)功能方面由于委托方的许多功能都可以调用相应模块来得到，并且已有了相应的书 面的简单需求，相应来说只是完成深化。对界面，我采用了部分RUP的思想迭代与渐进。而

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

首先把风险较大的部分完成，这是现代软件开发的基本常识。我选择先进行界面的需求 分析。第一步是根据功能描述抽取出逻辑模型，并使逻辑模型与界面元素及功能一一对应， 大俸上决定了界面应有的功能，然后根据该界面功能描述，确定具体的控件，这时，我参考 了委托方已初步完成的主窗口的界面布局及控件的使用规律，然后根据需要完成的功能从Qt（由于要支持Windows和Unix双平台，所以控件库采用Qt）的类库中选择相应的控件。在提取和抽象逻辑模型时，我采用了Rose 2000申的用例图，即以USE-CASE图来描述与外部的关系。之所以采用Rose，我是基于以下的原因：第一，在已开发的部分中，委托方统一要求我们使用Rose进行类和顺序图等的设计和代码生成。第二，Rose提供了标准的图来描述系统与外部的关系，在全球范围已是一种标准结构。第三，使用上的方便性。我用Rose的USE-CASE图，理清了我们的软件窗口（日式说法，即：沟通人员）与委托方主窗口（日式说法，同上）以及外部角色（操作者）之间的相互关系。

在确定了界面元素后，考虑到文档的可理解性不是很强，我采用Visi0 2000把界面的外 观绘制出来，写上了基本的控件作用，随后送给委托方评审，幸运的是除了几个小功能的修 改，委托方基本批准了我的方案。

下面的工作是为控件的行为及状态变化制定相应的状态迁移图，我选用的工具仍是Rose，我用了状态图和时序图，把重要的控件状态变化及相应III页序进行了描述，随后的几天把相应的DOC文档建好写明，基本上界面设计就完成了。

下面的需求是针对功能需求的。虽然委托方技术部门有初步的需求文档，但由于领域的 专门化不对，我不清楚其中复杂的路径提取关系及较深入的专业术语，一直有一种拳步维艰 的感觉。只能采用分层细化的原则，从最初的几条深入一层变成十几条。这样的话，不会一 下子碰到太深的专业问题，可以循序渐进从委托方与文献的解答中不断学习，深化自己对专 业领域的了解，这样在设计中自己始终是层层推进的，不至于碰到无法逾越的专业障碍。 在这一阶段的开发中，由于一直是与自己不熟悉的专业领域打交道，所以我觉得一些辅 助设计工具似乎无法发挥应有的功能。在这期间，对我帮助最大的应是公司的E-Mail系统， 所有不清楚的问题的提出，以及对问题的解答都通过它进行周转。换句话说，在需求分析阶 段，它起到了一个与客户的交流沟通和客户需求的提取作用。所以，我认为在这一阶段，E-Mail系统是对我帮助最大的工具，其次是Excel，我用它建立了问题跟踪图表，对每一个提出的问题，均需要记录上去，把问题结果（可分为已清楚、仍不太清楚、不清楚、尚未回答）均记录下来，根据这些表，我可以很好地了解自己工作中的核心问题，并有了解、央它的方向，提高了工作效率。

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

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

在这次需求分析中，我认为取得成功的原因主要是方法和工具选择得正确。在界面设计 中采用了流行的辅助工具，对需求及逻辑模型的建立提供很大的帮助，可以更方便帮助自己 理洁思路。选用了迭代法，把一些错误的影响在功能分析和界面分析的不断迭代过程中加以 改正。在后期，以功能需求为主时，我主要依赖的是沟通工具和表格工具，这也说明辅助工 具不是万能的，需求分析的关键之关键，应是与客户的交流与沟通。

通过这次案例，我、认为在软件的需求分析工作中，方法的重要性应远超过工具的使用， 应当首先确定分析中的风险，把风险分类，用不同的方法去解决各类风险，而工具的选择不 仅是要看影响力和名气，而是要真正为我所用，应把握其精髓，即是此工具到底可以对开发 有什么帮助，而不是仅限于如何使用。我认为在需求分析中工具的作用不外乎两个：一是实 际系统与环境模型等的抽象工具，二是需求表达工具。第一类的代表是Rose，第二类的代表是Word，WPS，Visio等，在这次项目中由于地理上的限制还用到了沟通工具，Web浏览与E-Mail服务系统。

最后我还是总结一下，在需求分析中工具方法部只是辅助项目成功的因素，真正的决定 因素还是一“与容户的沟通刀。

基于W．eb的医院管理系统的开发

【摘要】

随着市场的建立和发展，卫生行业面临了很多问题，一些制约卫生事业发展的矛盾和问 题日益显现，因此，国家卫生部要求各医院采用信息化管理。前不久，我所在的部门承担了 了一个医院管理系统的设计和开发，医院希望以此来转变医院现有的运行机制，提高服务质 量。该系统除了目前常见的结费系统、电子病历外，还包括门诊医生工作站、住院医生工作 站、护士工作站等分系统。考虑到需要通过Intranet实现功能，并有部分的Internet功能， 本项目平台最后采用了J ava平台。

我在项目中主要负责项目的的前期规划，即选择合适的开发方案，并建立部分的数据流， 在系统实施过程中推动其顺利前进。此系统开发成功后投入运行，获得医院相关工作人员的 好评。

【正文】

前不久，我所在的部门承担了了一个医院管理系统的设计和开发，医院希望以此来转变 医院现有的运行机制，提高服务质量。客户是一个市级医院，医院很早就开始从事信息化管 理，但主要是针对结费这一块，后来，对其进行了改进，加入对病人电子病历的管理和采集， 这样当病人二次就诊时，可以很容易地得到病人的既往病史。但随着系统的运行，院方希望 对现有系统进行改进，为7更好得为病人服务，医院考虑加入一些其它的分系统，比如门诊 医生工作站、住院医生工作站和护士工作站等等。因此我所在的部门承接了该HIS的开发， 开发的成果是一个典型的Java技术在Intr anet上的应用。

在开发前期，首先要设计出详细的系统功能规范，这一部分所花费的时间很少，因为卫 生部在20xx年曾经颁发了一个有关医院管理系统功能规范的通知，我们参考了该规范，很快确定了各分系统以及每个分系统的的基本功能。但在选择合适的系统平台上有一番讨论，考虑到医院原有系统在某些地方运行良好，是否有必要将原有系统淘汰重新设计，另外新的分系统到底采用何种平台结构也是需要考虑的问题。

医院原有的结费系统和电子病历系统数据流向范围比较固定，主要集中在交费处和挂号

处，一旦引入了新的系统，必然要将数据流向医院的各个部门。医院的Intranet已经实施， 因此首先考虑采用B/S架构体系，1日系统的数据模型尽可能保督。在系统的软件平台上，我们考虑使用Java平台，可以让数据在整个系统安全、有效地流动；另外现在也有很多的HIS系统可供我们参考，虽然往往是单机版的系统，但其中的数据模型有很好的参考价值。医院的现有网络系统和操作泵统多种多样，这就要求我们选择的软件平台必须具有开放性、平台无关性。而在不同的系统上安装相应的Java客户端虚拟机并不困难，最后，在项目组的讨论和征求客户意见下，项目组采用了此方案。

在项目中，莪们这样设计Java架构系统，将系统分为三层：

(1)表示层采用Jsp实现页面输出，这也是用户直接访问层，表示层接受来自网络浏览 器的IrnP请求，然后返回给客户端浏览器可以显示的HTML页面；

(2)中间件层用Java实现对数据库的访问，考虑到数据的分布特点，我们使用了数据 库连接池技术；

(3)数据库层用soL Server实现数据库的管理和存储过程。

JSP以其执行的高效性和使用的方便性，已成为近年来大家首选的因特网开发技术，JSP 是一种页面开发技术，它以J ava为其服务器端语言，结合Java Script作为其客户端语言， 能方便地实现页面的表示。选择Jsp作为前台语言，是考虑到它的平台无关性，能够兼容其 他的操作系统和数据。利用Jsp可以将HTML文件很方便地发送到客户端Web浏览器，同时也可以支持一些非HTML格式的文档发送。我们在网站中的用户层页面设计中，广泛地参考了现有的一些成功案例，在节约设计和开发酌费用的同时也得到了用户的认可。比起单纯的 Servlet技术，Jsp在页面元素上也更为丰富，在这里，我们为今后客户页面定制做了部分尝 试，设计了一个比较简单的模块，用户可以通过选择控件来动态生成页面提供打印，当然在 这部分我们设计中，可提供的数据库宇段是固定有限的，灵活性没有很好俸现。

我们大量工作主要放在中间件层，由于系统中的医生工作站分系统是主要部分，因此数 据库的负载成为一个不得不考虑的问题。综合考虑，我们决定采用数据连接池技术，因为基 本上每个医生都对应一个客户终端，无论是病人资料的查讯或录入，或者医嘱的处理，都涉 及到对数据库的频繁读写，服务器对于数据连接的频繁打开和关闭必然导致性能下降。一方 面，我们预先考虑数据库的连接量，在系统初始阶段建立相应的存储空间，当数据库连接打 开和关闭时部对该连接池进行处理；另一面，我们也使用了高速缓存技术，对某些固定的SQL查讯结果，例如药品查讯、药性禁忌等，将结果采用缓存存储，以加快对数据库的访问，降低了服务器端的负载，提高性能。值得一提的是，为了尽可能得避免纠纷，医院要求采用医生签名制度，我们设计了电子签名，采用加密算法保证各环节产生数据的有关人员不能抵籁。

数据库层我们选择了soL Server，程序员比较熟悉此平台的开发和设计。在前期，我们 到医院做了大量的走访工作，了解整个数据流，同时广泛参考现有的系统，虽然对医院行业 不是很熟悉，但数据层开发遇到的问题的并不是很大。在概要设计阶段，我们使用了一些计 算机辅助开发工具，这也加快了详细设计的进程。比如使用了Sybase的PowerDesignei工具， 在概要设计中规划了E-R图和各个分系统以及分系统之间的数据流图，然后让工具直接生成 后台数据库中的基本表结构，大大提高了开发效率。

整个项目实施完成后，医院相关工作人员反映良好，但其中也暴露出了一些问题，值得 改进。

首先，用JSP编程时容易导致系统信息的扩散。如果有人恶意攻击服务器，程序执行将 出现异常。这时，就会在页面上打印出相应的错误信息。这些信息会暴露出这台服务器的路 径信息。这个漏洞往往会被人利用，程序员对此也一头雾水，下一步我们考虑从服务器入手， 采用通用的异常说明界面，解决该问题。

其次，在设计上，可以使用更多的辅助开发工具和建模工具，比如Rational Rose，可 以利用它的代码自动生成功能，来大大提高开发速度；在用户界面定制方面，我们希望通过 下断的实践，加强其灵活性，尽可能把可供选择的宇段扩大到整个数据库。

最后，大量使用Java技术，势必对服务器的负载过大，在今后的开发中，除了现有的数据库连接池和缓存技术，我们考虑使用更多的数据库脚本来替代部分Java代码，来高速实王贝逻辑，相较而言，数据库脚本的执行速度较有优势，结合结果缓存，应该对服务器的性能有较大的提高。

上面是我在今后的系统设计和开发中需要注意和加以改进的地方，也是我今后应该努力 的方向。

证券系统网络的安全性

【摘要】

我在一家证券公司信息技术部门工作，我公司在19xx年建成了与各公司总部及营业网点的企业网络，并已先后在企业网络上建设了交易系统、办公系统，并开通了互联网应用。因将对安全要求不同、安全可信度不同的各种应用运行在同一网络上，给黑客的攻击、病毒的蔓延打开了方便之门，给我公司的网络安全造成了很大的威胁。

作为信息技术中心部门经理及项目负责人，我在资金投入不足的前提下，充分利用现有 条件及成熟技术，对公司网络进行了全面细致的规划，使改造后的网络安全级别大大提高。 本文将介绍我在网络安全性和保密性方面采取的一些方法和策略，主要包括网络安全隔 离、网络边界安全控制、交叉病毒防治、集中网络安全管理等，同时分析了因投入资金有限， 我公司网络目前仍存在的一些问题或不足，并提出了一些改进办法。

【正文】

我在一家证券公司工作，公司在19xx年就建成了与各公司总部及营业网点的企业网络， 随着公司业务的不断拓展，公司先后建设了集中报盘系统、网上交易系统、OA、财务系统、 总部监控系统等等，为了保证各业务正常开展，特别是为了确保证券交易业务的实时高效， 公司已于20xx年已经将中心至各营业部的通讯链路由韧建时的主链路64K的DDN和备链路

33. 3KPSTN，扩建成主链路为2ht光缆作为主链路和256K的DDN作为备链路，实现了通讯线路及关键网络设备的冗余，较好地保证了公司业务的需要。并且随着网上交易系统的建设和网上办公的需要，公司企业网与互联网之间建起了桥梁。

改造前，应用系统在用户认证及加密传输方面采取了相应措施，如集中交易在进行身份 确认后信息采用了Blovrf ish 128位加密技术，网上交易运用了对称加密和非对称加密相结合 的方法进行身份认证和数据传输加密，但公司办公系统、交易系统、互联网应用之间没有进 行安全隔离，只在互联网入口安装了软件放防火墙，给黑客的攻击、病毒的蔓延打开了方便 之门。

作为公司信息技术中心运保部经理，系统安全一直是困扰着我的话题，特别是随着公司 集中报盘系统、网上交易系统的建设，以及网上办公需要，网络安全系统的建设更显得犹为 迫切。但公司考虑到目前证券市场疲软，竞争十分激励，公司暂时不打算投入较大资金来建 设安全系统。

作为部门经理及项目负责人，我在投入较少资金的前提下，在公司可以容忍的风险级别 和可以接受的成本之间作出取舍，充分利用现有的条件及成熟的技术，对公司网络进行了全 而细致的规划，并且最大限度地发挥管理功效，尽可能全方位地提高公司的网络安全水平。 在网络安全性和保密性方面，我采用了以下技术和策略：

(1)将企业网划分成交易网、办公网、互联网应用网，进行网络隔离。

(2)在网络边界采取防火墙、存取控制、并口隔离等技术进行安全控制。

(3)运用多版本的防病毒软件对系统交叉杀毒。

(4)制定公司网络安全管理办法，进行网络安全集中管理。

为了达到网络互相不受影响，最好的办法是将网络进行隔离，网络隔离分为物理隔离和 逻辑隔离，我主要是从系统的重要程度即安全等级考虑划分合理的网络安全边界，使不同安 全级别的网络或信息媒介不能相互访问或有控制的进行访问。

针对我公司的网络系统的应用特点把公司证券交易系统、业务办公系统之间进行逻辑分 离，划分成交易子网和办公子网，将互联网应用与公司企业网之间进行物理隔离，形成独立 的互联网应用子网。公司中心与各营业部之间建有两套网络，中心路由器是两台CISC07206， 营业部是两台CISC02612，一条通讯链路是联通2M光缆，一条是电信256K DDN，改造前两套链路一主一备，为了充分利用网络资源实现两条链路的均衡负载和线路故障的无缝切换，子网的划分采月VLAN技术，并将中心端和营业部端的路由器分别采用两组虚拟地址的HSRP技术，一组地址对应交易子网，一组地址对应办公网络，形成两个逻辑上独立的网络。改造后原来一机两用（需要同时访问两个网络信息）的工作站采用双硬盘网络隔离卡的方法，在确保隔离的前提下实现双网数据的安全交换。

2、网络．边舅圬当兰控制

网络安全的需求一方面要保护网络不受破坏，另一方面要确保网络服务的可用性。将网 络进行隔离后，为了能够满足网络内的授权用户对相关子网资源的访问，保证各业务不受影 响，在各子网之间采取了不同的存取策略。

(1)互联网与交易子网之间：为了保证网上交易业务的顺利进行，互联网与交易子网之 间建有通讯链路，为了保证交易网不受互联网影响，在互联网与中心的专线之间安装了 NETSCREEN委托防火墙，并进行了以下控制：

·只允许股民访问网上交易相应地址的相应端口。

-只允许信息技术中心的维护机地址PING、TELNET委托机和路由器。

·只允许行情发送机向行恬主站上传行悟的端口。

·其他服务及端口全部禁止。并且在互联网和交易网之间还采用了SSL并口隔离，避一 步保证了交易网的安全。

(2)交易网和办公网之间：对于办公网与交易网之间酌互访，采用CISC02501路由器进 行双向控制或有限访问原则，使受控的子网或主机访问权限和信息流向能得到有效控制，主 要采用的策略主要是对具体IP进行IP地址与心地址的绑定。

(3)办公子网与互联网之间：采用东大NETEYE硬件防火墙，并进行了以下控制： 一允许中心上网的地址访问互联网的任何地址和任何端口。

·允许股民访问网上交易备份地址的8002端口。

·允许短消息访问公司邮件110、25端口，访问电信SP的8001端口。

·其他的都禁止。

3、病毒防治

网络病毒往往令人防不胜防，尽管对网络进行网络隔离，但网络资源互防以及人为原因， 病毒防治依然不可掉以轻心。因此，采用适当的措施防治病毒，是进一步提高网络安全的重 要手段。我分别在不同子网上部署了能够统一分发、集中管理的熊猫卫士网络病毒软件，同 时购置单机版KV3000和瑞星防病毒软件进行交叉杀毒；限制其享目录及读写权限的使用；限制网上软件的下载和禁用盗版软件；软盘数据和邮件先查孝后使用等等。

4、集中网绍未．全管哩

网络安全的保障不能仅仅依靠安全设备，更重要的是要制定一个全方位的安全策略，在

全网范围内实现统一集中的安全管理。在网络安全改造完成后，我制订了公同网络安全管理 办法，主要措施如下：

(1)多人负责原则，每一项与安全有关的活动，部必须有两人或多人在场，并且一人操 作一人复核。

(2)任期有限原则，技术人员不定期地轮岗。

(3)职责分离原则，非本岗人员不得掌握用户、密码等关罐信息。

(4)营业部进行网络改造的方案必须经过中心网络安全小组审批后方可实施。

(5)跨网互访须绑定IP及MAC地址，增加互访机器时须经过中心批准并进行存取控制 设置后方可运行。

(6)及时升级系统软件补丁，关闭不用的服务和端口等等。

在进行网络改造后，我公司的网络安全级别大大提高。但我知道安全永远只是一个相对 概念，随着计算机技术不断进步，有关网络安全的讨论也将是一个无休无止的话题。审视改 造后的网络系统，我认为尽管我们在Internet的入口处部署了防火墙，有效阻挡了来自外部 的攻击，并且将网络分成三个子网较减少了各系统之间的影响，但在公司内部的访问控制以 及入侵检测等方面仍显不足，如果将来公司投资允许，我将在以下几方面加强：

(1)在中心与营业部之间建立防火墙，通过访问控制防止通过内网的非法入侵。

(2)中心与营业部之间的通讯，采用通过IP层加密构建证券公司虚拟专用网(VPN)， 保证证眷公司总部与各营业部之间信息传输的机密性。

(3)建立由入侵监测系统、网络扫描系统、系统扫描系统、信息审计系统、集中身份识 别系统等构成的安全控制中心，作为公司网络监控预警系统。

保障网络安全性与网络服务效率永远是一对矛盾，在计算机应用日益广泛的今天，要想 网络系统安全可靠，势必会增加许多控制措施和安全设备，从而会或多或少的影响使用效率 和使用方便性。如，我在互联网和交易网之间设置了放防火墙的前提下再进行了SSL并口隔 离后，网上交易股民访问交易网的并发人数达到一定量时就会出现延时现象，为了保证股民 泰扁B时．№埯．势日挥耍田增加几涌；习木n的机津辜消除亦扁；正时问斯一 电子报税系统的质量保证

【摘要】

20xx年5月，我担任某省国税局电子申报系统开发部的负责人，主要负责系统规划与组织实施开发。该系统工程浩大，业务需求多变，外部运行环境复杂，具有严格的安全、稳定、可靠性能要求，是一个基于网络的，大型数据库实时分布式系统。该系统主要由电子申报与电子完税两部分组成，电子申报部分由微机点对点申报、电话语音申报、Internet网上申报、专用报税机申报四个子系统组成，并统一在电子申报服务器端软件模块下，电子申报服务器作为总个系统核心模块，还与银行前置机、税务各征管应用系统进行数据交换。我在将近两一年的可行性研究、需求分析、系统研发与试点工作过程中，我们采用了UML/Rationl软件工程方法、系统研发与试点同步进行的软件开发模式，而且还提出了独有的“流程编辑器”和“万能造表’’的设计理念，有效地来提高了软件开发的质量和与效率。但仍然存在不能快速切换应用系统，进行故障屏蔽或系统恢复的容错性要求，缺少适应系统研发与试点同步进行的系统测试方法与工具等问题。

【正文】

20xx年5月，我开始担任某省国税局电子报税系统(以下简称HNlqT-EF)开发部的负责 人，主要工作是对HNNT-EF迸行规划并实施开发。HNNT-EF系统分为电子申报与电子完税

两部分，电子申报部分能够按税务局给定的内容和格式提供各种税种的申报表格和数据，为方纳税人，还提供给各类型的纳税人使用“多元化”的申报纳税设备与手段，如“电话语音 申报”、“微机点对点申报”、" Ineternet"等。纳税人利用各种终端，将自己的申报数据在经 系统逻辑审核后传递到税务申报中心进行处理。电子完税系统是税务局、银行和国库间的税 款划缴专用系统，应具有安全保障机制和可靠性措施，保证传递与存储税款信息安全可靠。 而且，系统要求要具有较高的灵活性，能适应各种数据库开发软件接口，能连接多种数据库。 我带队在经过将近一年的可行性研究、总体规划、可行性形究、需求分析后，于20xx年6月正式立项建设。我主要负责HNNT-EF服务器端软件设计，服务器端软件是整总个系统的核心程序，包含四个功能模块，其中税局模块实现税局工作人员的申报功能控制和二次开发，接线模块用于电话、传真机、电脑及及Internet的接入服务、后台处理实现催报等功能、流程解释器主要用于解释二次开发的流程。

选择UltL/Rational。从项目开始建设起后，我给公同提出放弃用Wor d、用Visio来写文 档和设计结构图的原始做法，我拿着系统需求分析报告，向公司负责人提出如下看法：随着 经济的发展，国地两税的业务需求将会不断发生变化，引发电子申报系统的申报格式与内容 发生变化，系统的可维护性要求极高；j并且，不断产生新的业务需求，、夹定系统要求有很好的可扩展性j电话语音申报子系统、Ineternet申报子系统等决定需要进行分布式的小组开发，更需要清晰，易理解和共享的文档管理，如果系统不能满足这些需要，不采用完善的软件工程方法，公司将耗费大量的人力、财力去进行系统的后期维护。我建议公司采用Rational Rose进行需求分析与设计，并提出，在公司财力允许充许的情况下，逐步采用Rational RequestPro来管理需求，采用Rational ClearCase来记录变更需求。虽然，公司后来只采用了RationalRose进行系统分析与设计，但是，这在提高软件开发质量与效率起到了很大的作用。回顾软件开发过程，我总结出有以下优点：详尽地获取用户需求，这是软件质量保证的关踺。基于UML的Rational Rose提供的用例，交互图、顺序图的使用，使人们更容易发现具中的遗漏：使用UML/Rational Rose描述需求分析说明书，以“看图讲故事”的形式向用户讨论需求，用户更容易理解系统的操作，尽早发现隐性需求：并且，统一的系统分析设计语言，使程序员更容易理解系统分析师的设计意图，避免程序产生功能上的错误：这给系统的后期维护带来极大的便利，因为图形总比文本容易理解，规范的文档与版本控制便于程序员快速理解设计代码。所以，选择UML/Rational，对提高系统的可维护性，可理解性，可扩展性，起到很大的作用。

采取系统研制与试点推广同步进行的工作开发模式。HNNT-EF在该省两市进行了系统的 总俸规划、可行性研究、需求分析等前期工作后，我带领开发组提出“应用与完善同步，积 极稳妥推进”的开发模式，制定了相应的短、中、长期技术方案各及各阶段的具俸目标以及 对应措施。因为HNNT- EF的服务端软件除作为电话语音申报、Int ernet申报等子系统的统一处理平台外，还必须与银行基于OricaleOracle的前置机系统，税局基于Sybase的征管系统进行数据交换。象银行的前置机，系统要求银税联网的连接成功率大于>99%，数据准确率为100%，平均响应时间少于<10秒．我们在该省两个市进行试点过程中，发现大约有2%的纳税户在进行电话申报纳税时因为响应时间过长而中断，通过大量的研究发现，这是银行前置机接口软件有问题，从而较快地得到解决，从这一实例可发现，边研发边试点，并跟据实际的应用情况对系统进行不断调整各完善，极大地提高了软件测试的效率和准确性，能较好地达到了预期的试点目标和应用效果。并且，这样与”用户打成一片“的开发模式，更容易使用户产生共鸣，尽早发现系统的隐性需求，最大地提高了系统的可用性。这为面对复杂的外部运行环境，采取系统研发与试点同步运行的开发模式积累了经验。当然，这种开发模块并不是通用的，需要有良好的关系处理和特殊的应用需求。

“流程编辑器”与“万能造表”的设计理念。在前期的需求分析中，莪发现税务业务组

人员经常提及申报表（内容、格式、审核公式）变动的说法，我经过分析得到证实，比如国 家适应税率就经常更改，这就得修改申报表程序，这种后期经常修改源代码是软件开发的大 嫉，我在经过大量的技术论证后，我提出了“万能造表“的概念，其原理是：将软件实现与 表格彻底分离开来，建立申报表模板（与Word文字处理模板类似）的概念，与申报表程序分离开来。这样，如果榄局的申报表发生了变动，我们不必修改源代码，只要按照规格修改申报表模块，并且，系统实现了将模板通过远程网络分发到纳税户微机上，实现模板的自动更新，这样，大大增加了系统的可维护性，做做到纳税户客户端的零维护，并且这种修改可由税务局相关工作人员进行，减少了公司的维护工作量。另外处，我考虑到，税务局随着经济发展，不但业务处理流程经常发生变动，而且还要不断时地增加业务处理子系统，怎样利用先期的开发成果与经验，较快速度地开发新的业务处理子系统，并在电子申报服务器端得到统一呢？我当时提出了与“编译原理”类似的流程编辑器。所谓流程编辑器是在vc语言的开发平台上，通过扩展功能函数，开发出针对数据库管理、串行通讯功能等组成的可视化的流程编辑语言，并以此为核心，开发出可视化的流程编辑器。这样，系统的处理流程可根据业务变化进行自定义，毋需重复写源代码，方便系统的维护和升级，并保证系统的稳定可靠。

完备的外部鉴定与审计。经过两年多的开发和试点工作，HNNT-EF基本实现了技术开发 和试点的目标和任务，为进一步完善和提高系统的技术应用水平，我提出了请该省信息厅进 行外部鉴定与审计工作，进一步确定系统的先进性、可推广性．实用性。同时，通过对提供 的项目资料是否齐全且合乎规范的审查，给各阶段系统开发人员按照软件工程开发方法，文 档为先的开发思想形成一种压力。

综上所述，面对HNNT-EF复杂多变的用户需求与外部环境，采用先进的软件工程方法规范我们的开发过程、研发与试点同步进行的开发模式、独特的“流程编辑器“与”万能造表“设计理念等思想，保证了HNNG-EF系统开发的高效率与高质量，但是，在系统研发与试点过程中出现的一些问题，也值得我们思考：

软件开发的容错性。系统必须具有快速切换应用系统，进行故障屏蔽或系统恢复的容错 性要求，这一点，我们在研发试点过程中有所忽视。HNNT-EF系统的电话申报方式在某市开 通使用的第二个征收期，由于使用户数由800户突增到4000户，突出地暴露了银行的税款扣缴系统处理并发请求的能力较差的缺陷，由此引发了20xx年4月10下午系统在2个多小时无响应的事故。面对这种事故的发生，HNNT-EF竟然竟然没有故障处理和应急措施，最可怕的是，这将大大降低纳税户的信任度。而造成的原因不得而知。为了使软件能带故障运行，我考虑采用中央存储库和对服务器进行备份的方案。但是，怎样发现外部系统带给软件的影晌，我在这方面的经验很少。

缺少与系统研发与试点同步进行的系统测试的方法与工具。特别是缺少压力测试方法和 自动测试工具。我原来思考引进XP开发思想，先开发测试程序，后开发软件模块，但因实施

环堵的每丑而前盔．；女旱一个转有待；#一舟堂习研窖的1' 96．

远程虚拟实验室的建设

【摘要】

本文首先概述了虚拟现实技术的产生、特征和应用，研究了我国计算机辅助教学的发展 现状和存在的问题，以及虚拟现实技术在计算机辅助教学中应用的重要意义。

然后通过实例，介绍了虚拟现实技术在计算机辅助教学中的应用。20xx年，本人所在

的单位组织开发了一个用于远程教学的计算机辅助教学(CAI)系统。在该项目的开发中，我担 任技术总监的职务，主要负责系统架构设计和方案选型的工作。

在该系统中，我们将虚拟现实的理论和技术引入到教学过程中。这样，不仅可以拓宽多 媒体计算机的应用，为办学兴教节约大量资金，同时提高教学水平。

【正文】

计算机辅助教学就是利用功能强大的多媒体计算机作为媒体，开展教与学的一种教育培 训手段。就全球范围看，我国的计算机辅助教学研究起步较晚，是在80年代后期展开研究的，但发展很快。20xx年，本人所在的单位组织开发了一个用于远程教学的计算机辅助教学(CAI)系统。在该项目的开发中，裁担任技术总监的职务，主要负责系统架构设计和方案选型的工作。

在该系统中，我们将虚拟现实的理论和技术引入到教学过程中。这样，不仅可以拓宽多 媒俸计算机的应用，为办学兴教节约大量资金，同时提高教掌水平。我们以电子表格软件Excel为蓝本，运用虚拟现实的理论，设计开发了具有虚拟机制的澡件“跟我学习”。

虚拟现实是一种支持多维空间信息技术的关键技术，是计算机技术的又一研究和应用热 点。虚拟现实技术的主要内容是：实时三维图形生成技术、多传感器交互技术和高分辨率显 示技术。

虚拟现实的理论和技术的应用非常广泛，特别是近年来三维图形、声音定位与合成、传 感器、环境建摸等技术的日趋成熟，为虚拟现实技术的研究提供了物质和技术基础。除了有 许多专用的虚拟现实装置和系统投入使用，越来越多的研究人员将虚拟现实技术与各自领域 的研究机制相结合，促进了高新技术的发展。目前虚拟现实技术应用已在通讯、医学、交通、 商业和文化娱乐等方面初见成效。比如在娱乐领域，利用虚拟现实技术创造的虚拟环境，如 星球大战，太空舰队等，不仅逼真，而且生动，具有极强的趣味性。虚拟现实技术与通讯技 术相结合已经显示出诱人的前景。

计算机辅助教学就是利用功能强大的多媒俸计算机作为媒体，开展教与学的一种教育培 训手段。就全球范围看，我国的计算机辅助教学研究起步较晚，发展从浅到深，从研究到应 用普及，从教育到培训，表明了CAI在我国的广阔前景。我国的计算机辅勋教学虽然发展较 快，但长期以来，在教育这个大舞台上，具有强大功能的计算机只能扮演电子黑板或电子图 书的脚色。辅助教学软件设计多以澡本内容为剧本，顺序地在计算机上展示书本内容；而且 表现形式简单，图形少且单调；动画和声音几乎没有，更不用说实践环节的联系了，基本上 就是教材或习题集的翻版。这是CAI技术发展中的一个大误区。学习与应用是紧密关联的。 要想掌握一门澡程，特别是实践性强的课程，除了必须学习一定的理论知识以外，更重要的 是实习。研究设计CAI澡件的主要目的之一是实现个别化教学。为不同目的和起点的用户提 供一个边学边做的实践学习环境。

虚拟现实技术即直接把计算机合成的信息通过声音、图像等多种信息作用于人的各种感 官，包括听、看、嗅、触等感官，从而在人的周围形成一种人造空间，达到一种超模拟效果。 这种效果也是教育与培训最为重要的，它无疑会极大的提高教育与培训的效果，特别是在学 习迁移方面尤为如此。可以毫不夸张地说，虚拟现实技术就是为教育培训而创建的。利用虚 拟现实技术可以使得对宇航员、飞机和舰船的驾驶员、指挥员以及各种复杂系统的操作人员 的仿真培训更加生动、逼真，培训内容更丰富，效果更佳。在医学领域中利用虚拟觋实技术 开展外科手术的操作培训和实验，不但节约了大量的资金，而且比用活俸进行培训和实验更 加安全和方便。现在国际上正在研究一种利用虚拟现实技术进行遥控手术的技术，它的实施既可以作为医疗手段，也可以作为培训手段。此外，在幼儿的启蒙教育中，虚拟现实技术被用来作为开展寓教寓乐教育基本方式。

虚拟现实环境是一种和谐的人机界面。利用虚拟现实技术的合理、夸虚构的特点，

使我们能够去完成传统的教育培训任务，能够去解决前人所未能解决的问题，能够去创造前所未有的教学环境。比如，虚拟实验、虚拟测试、虚拟培训等等。将虚拟现实的理论和技术引入教学过程中，不仅可以拓宽多媒体计算机的应用，为办学兴教节约大量资金，同时提高教学水平。

笔者以电子表格软件Excel为蓝本，运用虚拟现实的理论，设计开发了具有虚拟机制的 澡件“跟我学习Excel"，为学习者提供了一个多功能的虚拟学习环境。用户在学习过程中， 不但能够学习Exce197的各种编辑的理论和方法，而且能够身临其境地进行实际操作。该软 件集文字、图表、图形、图像、动画和声音于一体，引入人工智能和超链接机制，人机界面 友好，为用户提供了一个边学边做的开放式学习环境。

该澡件由以下大个模块组成：

第一部分“学习向导”。主要向用户介绍各个模块的功能和澡件的使用方法，并给出几 点学习建议。

第二部分“认识Excel"配合轻松的画面，简单扼要地向用户介绍Excel的性质，功能 和主要应用范围。

第三部分“理论学习”。根据Excel的主要功能特点，结合文字，图形等的显示，按类 分块的进行理论学习指导。还可以结合以后的模块进入演示或练习过程。

第四部分“实例演示”。结合Excel的主要功能进行实例操作演示。用户可以任意选择 观看虚拟教师的操作演示。

第五部分“实战练习”结合Excel的主要理论和功能设计练习，并提供虚拟现实的操作 界面，用户可以任意选择练习。

第六部分“测试训练”。综合Excel的理论和功能，配以虚拟现实的操作环境，设置不 同类型的测试练习为用户选做。

虚拟现实技术日趋完善和提高，预期该领域未来的发展趋势为：

(1)硬件技术的发展。虚拟现实所要求的超级计算、图形图像处理、图像投影及交互等 虚拟环境构建硬件技术将得到持续的发展，成本大幅度下降，从而促进虚拟现实技术的应用 和普及。

(2)开放平台虚拟现实技术的发展。利用Intel微机硬件平台+Linux自由软件平台+中 低档图形、数字投影设备构窿经济型中低档VR系统，是虚拟现实技术的一个重要发展方向和

现实途径。

(3)协同分布式虚拟现实技术的发展。虚拟现实系统已经由单机系统发展到分布式虚拟 现实系统，现在人们正在向支持协同工作的分布式虚拟现实系统即协同虚拟现实(CVR)系统 发展。

(4)可视化区域网络技术的发展。可视化区域网络(VAN)的目标是实现全球化用户用

各种设备对可视化系统的交互访问以及可视化协同工作。VAN由高性能的可视化服务端（负 责数据的存储管理、可视化计算等任务）、宽带网络和客户端组成。

(5)多感知能力的发展。未来理想的虚拟现实系统将提供人类所具有的一切感知能力， 甸．括视常、听赏、衲常，其军昧赏和嗅常。

ERP在商业管理中的应用

摘要

ERP已突破了原来只管理企业内部资源的方式，把客户需求和企业内部的制造活动，以

及供应商的资源融合在一起，更适合市场经济的需要。

我在一个上市公司的信息中心工作，20xx年4月，公司高层决定实施ERP系统，并委任我为实施部经理。对于如何系统地实施ERP系统，我们经过反复研究、权衡，最终决定采用“商品化软件+次开发”的方式进行建设。在具体实施时，主要考虑以下问题：系统结构、 系统集成、可扩展性、操作系统。

由于采取了合理的开发方式，且领导重视，真抓实干，系统顺利地上线运行，并取得了 预期的效果。我认为，ERP的发展趋势主要是：系统更加柔性化，应用范围广泛化，功能深 度化，对供应链管理提供更好的支持，朝着Internet技术靠拢等。

【正文】

ERP虽然是以MRP II为基础发展而来的一种管理思想，但是在功能和技术上已超越了传统的制造业并延伸到其他各行各业。在管理理念上，ERP已突破了原来只管理企业内部资源的方式，把客户需求和企业内部的制造活动，以及供应商的资源融合在一起，更适合市场经济的需要。

ERP在企业中的应用涉及到企业的生产经营机制、传统管理方法和管理基础等一系列实 际问颢，因此引进ERP系统的企业普遍出现了实施难度大、周期长、反复多、见效慢等现象。 我在一个上市公司的信息中心工作，该公司成立于19xx年4月，由原来的国营大中型企业改制而成。公司以百货、钟表、眼镜、金银首饰等名、特专业商店和老字号企业为龙头， 在全国各地开设专业特色分店、专柜。19xx年进一步调整经营结构，资本运行向优质企业靠拢。公司的十几家子公司的地理位置比较分散，而且子公司性质复杂，包括酒店、超市、房地产等行业，业务复杂、业务量大、跨地区经营是公司面临的最大问题。

20xx年4月，公司高层决定实施ERP系统，并委任我为实施部经理。公司所需要的ERP 系统是一种能更好地满足企业多行业、跨地区、多供应商和销售渠道经营管理模式的信息管 理系统，这种系统应该充分利用先进的计算机技术，为用户提供灵活性和可配置功能。 对于如何系统地实施ERP系统，我们经过反复研究、权衡，最终决定采用“商品化软件+二次开发”的方式进行建设，即购买符合要求的商品化软件，再与专业软件公司合作，根据实际需求进行二汝开发。我们根据当时的计算机技术、行业特点等进行了可行性论证，最后达成一致意见，确定了“技术要顺应潮流，投资要受到保护．管理软件要强壮，合作公司要有实力刀四项基本原则，保证ERP系统的顺利应用。

经过初步调研，我们、夹定ERP系统主要由以下几大部分组成。

(1)供应商关系管理模块。本模块可以方便地加强与供应商的交流，降低公司的采购成 本，它让供应商能查询与公司的业务往来情况和对帐单。

(2)客户关系管理模块。为帮助公司最大程度地实施以客户为中心的战略思想，为客户 提供更快更好的服务，本模块对客户信息进行收集与分析，提供客户注册、客户查询、客户 社区、精品推荐、营销指南、服务宝典等功能。

(3)销售管理模块。此模块用于管理销售业务，可以打印报价单、销售定单、#5@p等多 种单据。

(4)采购管理模块。本模块提供跟踪请购单和采购定单，定单收货确认与定单列印等 一系列功能，帮助公司执行采购、安排生产计划、对于有效降低库存成本，保持产供销平衡， 提高预测、、央策的能力具有重要意义。

(5)库存管理模块。本模块具备库存与仓库管理的多种功能，提供各式库存报表及产品 目录，并与销售管理模块、应收款管理模块、采购管理模块与应付款管理模块紧密结合，其 享库存资料。

(6)应付款管理模块。本模块着重于公司业务预算和应付款项的管理和控制，便于平衡 收支，提供妄排付款，列印电脑支票，手写支票及更新库存数量，并自动生成财务凭证，更

新到总帐中等多种功能。

(7)应收款管理模块。本模块通过对客户、销售和应收款进行智能化的管理和控制，使 得公司能够及时全面了解资金回收和应收款情况，此外还提供了多方面的销售、客户、产品 和服务等分析报告。

(8)总帐管理模块。本模块是一个可快速审核与分析总帐，自动完成从凭证汇总到报表 生成的一系列财务核算过程。

(9)网上商店。本模块将公司所售商品一一陈列在网上，让客户可以随时随地直接在网 上快速浏览并选购商品，所生成的网上定单能够自动转入销售管理模块进行处理。

(10)、央策分析系统。本模块可按照用户需求，统计打印出各种财务、库存、应收、应 付等统计报表，为管理决策提供依据。

基于以上需求，我们开始挑选合作伙伴。对上海、北京、深圳等一些软件公司分别进行 了考察，最后选定了北京某集团软件公司作为实施ERP的合作伙伴。

在具体实施时，我们主要考虑了以下问题：

(1)系统结构。我们在设计ERP系统结构时采用了三层机构，整个系统分为表示层、应 用层和数据库层。表示层、应用层与数据库层分离。这样一来，用户可以从数据库服务器中 装载可执行的应用，从而简化对虚用的管理，同时在需要时，每个服务器还可以请求它自己 的可执行模块。同时，为了确保ERP实施以后拥有足够的性能，项目实施小组在规划ERP项目时认真了解了网络的速度并且详细理解应用结构的网络性能需求，在此基础上决定公司总部和分公司之间的通信采用拨号方式。

(2)系统集成。由于子公司多，且采用了来自多个不同厂商的管理信息系统，不同的数 据库和硬件平台。我们将这些分离的ERP子系统相互集成起来，同时还将现有的应用同已有 的应用和、央策支持系统集成起来，最大限度地发挥了ERP项目的作用。在具体集成方法上， 我们采用在一个单一的操作系统和数据模型上运行多个应用，减少了集成相关应用的复杂性。

(3)可扩展性。因为我们的公司发展比较快，所以，在实施ERP时，残们充分考虑了系 统的可扩展性。

(4)操作系统。我们在实施ERP项目时考虑到操作系统的可移植性，因为有些服务器只 能在某些硬件平台上实施。现在最常用的两种操作系统就是Unix和Windows NT。Unix宝刀 不老，保持它在高端市场的领先地位。因为它能够支持高可伸缩的数据库服务器，使用基于 Unix的方案将提供更大的可伸缩性，所以，我们选择了Unix。

由于采取了合理酌开发方式，且领导重视，真抓实干，系统顺利地上线运行，并取得了 预期的效果。系统实施后，将公司的内部资源和外部资源整合在一起，有效地安排的产、供、 销活动，满足公司利用全社会一切市场资源快速高效地进行生产经营的需求，实现了对公司 的动态控制和各种资源的集成和优化，提升了公司的管理水平，进一步提高了效率和获得市 场竞争优势。

通过ERP的实施，我认为，ERP的成功确实是“三分靠技术，七分靠实施”， ERP作为一概念系统，管理到了企业的方方面面，这不只是一个简单软件系统所能解、央的，它与企业的整个意识、理念、管理水平都有着密切的联系，需要一个循序渐进的过程。

ERP也随着管理思想、技术的提高而随之发展。我认为，ERP的发展趋势主要是：系统更加柔性化，从而更灵活地适应企业变化的需求；应用范围广泛化，渗透到了各行各业；功能深度化；对供应链管理提供更好的支持；朝着Internet技术靠拢；组件技术应用更加深入； 安全保密性更高；成本更低、易用性更好；以及系统自助化。

【摘要】

与通用操作系统相比，嵌入式系统由于其代码小，高度自动化，稳定，响应速度快等特 点使之应用领域越来越广泛。我所在的单位是国内主要的医疗仪器研发单位，作为单位的主

要技术骨干，20xx年5月，我主持了CTS - XXXX的软件系统的开发，该系统是我单位的新一

代数字B超诊断仪器的软件控制系统。在选择嵌入式操作系统时，我综合考虑了功能要求、 开发难度、研发生产成本、运行稳定性、兼容性五个方面，在windows ce\ windows xp enbad、 linux,自行开发操作系统等方案中选择了linux 2.4内核作为单片机的操作系统。

该系统及其硬件系统已于200 3年10月底顺利完成并在全国秋季医疗仪器博览会上展出，获得同行和客户的认同与称赞。但是，在开发过程中，由于对linux开发不够熟悉、与linux配套的应用软件和软件开发包较少等原因，为开发增加了不少难度。

【正文】

随着应用的范围不断扩大、需求日益复杂化、计算机技术不断发展，嵌入式系统的软、硬 件资源也比以往更多起来，嵌入式系统开始逐渐承担更多更复杂的工作。比如，智能移动终 端、机顶盒等等。这时，监控程序就不能满足需要了．嵌入式操作系统应运而生了。

通用操作系统由于是面向所有的计算机用户，而且所使用的内存、外存等硬件资源非常丰 富，所以往往设计的比较庞大、复杂，功能上几乎无所不包，尽可能的适应所有用户的需求。 嵌入式操作系统相比较于普通操作系统而言，只相当于最基本的内核部分，或者说只具备操 作系统最基本的功能，比如中断处理、进程调度、存储管理等。这也是与嵌入式应用的体积 小、重量轻的特点相适应的。一般来说，嵌入式操作系统具有如下特点：

(1)稳定性：嵌入式系统常常需要在几乎没有人工干预的情况下完成高度专业化和实时 的工作，这就要求嵌入式操作系统能必须性能非常稳定。

(2)精炼高效：嵌入式系统中的硬件条件一股比较苛刻，可用资源很少，要在如此紧张 的资源下很好地完成预定功能，要求嵌入式操作系统必须尽可能的精练、高效。而一些嵌入 式环境中用不到的复杂功能则应该取消，以减小系统开销。

(3)可裁剪：嵌入式操作系统作为操作系统，当然具有一定的通用性，能够适应多种平 台和多种硬件环境。但是为了适应不同用户的不同应用环境而又能够避免冗余，就需要具有 很好的可裁剪性能，使用户可以根据需要对各个组件进行裁剪和优化，得到一个有针对的操 作系统。

(4)伐码固化：嵌入式系统没有外存，其操作系统的代码需要固化在ROM中，系统加电 后自动运行。

此外，嵌入式操作系统还常常具有其他一些特点。包括：启动速度快；具有实时性；能 够适应多种处理器平台；一般提供配套的开发环境等等。

20xx年，我单位开发了新一代的数字B超诊断仪器CTS - XXXX，作为单位的技术骨干之 一，我主持并参与了CTS - XXXX软件系统开发的项目计划、需求分析、设计和测试阶段的工 作。在选择嵌入式操作系统时，我综合考虑了功能要求、开发难度、研发生产成本、运行稳 定性、兼容性等五个方面，在Windows CE、Windows XP Enbad、Linux,自行开发操作系统 等方案中选择了linux 2.4内核作为单片机的操作系统。

1、功能要求

首先是图像的实时显示，CE在图像显示上显然比较薄弱，但是如果通过额外加入辅助硬件也可以达到要求，XP Enbed和linux可以各自搭配Dirext d-aw和Open GL，应付图像的 实时显示绰绰有余，自行开发操作的系统功能比较简单，同样需要加入辅助硬件才可以达到 要求。DICOM 3.0方面，目前已经有了与CE、XP Enbed和Linux配套的开发包，自行开发操 作系坑只能通过Dicom标准里的算法自行开发或者购买辅助芯片来实现。工作站和数据库方面，CE、XP Enbed、Linux显然都很容易实现，自行开发造作系统可以通过开发简单的文本数据库系统来实现数据库。CE、XP Enbed、Linux部可以支持多种存储媒体，自行开发操作系统仍然需要开发存储媒体支持，并且还要符合现行各种媒体存储标准。四种方案对复杂

的计算测量部可以实现。如果要考虑到以后加入三维成像功能，ce和自行开发操作系统还是要加入辅助硬件才能实现。

2、开发滩度

在开发难度上，CE的图像显示由于要由硬件辅助，所以软件的开发难度降低，虽然增加了硬件的开发难度，但是由于以前单片机十程序的时候，图像实时显示也是由硬件承担，积累了丰富的开发经验，所以整体开发难度反而降低，而且由于CE的开发工具和软件包非常多，所以CE的开发难度是四个方案中最低的。XP Enbed的难度主要是在Direct d-aw上，虽然微软一直推崇DiretX、Direct d工aw，但是实际情况却是Open GL无论在网络资源、开发人员还是开发培训都要比Direct draw容易获得。Linux的难度是对内核的裁剪以及开发习惯上。自行开发操怍系统明显是难度最大的，不必赘述。

3、研发成本和生产成本

研发成本与开发难度密不可分，CE的研发成本最低，自行开发操作系统难度最大，研发成本当然最高。XP Enbed和Linux由于各自需要进行开发培训，二者研发成本不会相差很多，都居于中间。

在生成成本方面，CE和XP Enbed部需要支付版权费用，CE和自行开发操作系统都要加 入辅助的硬件，而Linux既不需要支付版权费用也不需要额外的辅助硬件，所以生产成本是 最低的。

4、运行稳定性

医疗仪器是否能正确稳定运行关乎患者的生命安全，CE、XP Enbed部是微软公司专门用于嵌入式开发的操作系统，其稳定性和微软桌面操作系统系列不可同日而语，在工控开发同行中享有不错的口碑，Linux其桌面操作系统就非常稳定，所以它的内核的运行稳定性更加不必质疑，在工控开发同行中一样享有不错的口碑，自行开发操作系统由于开发难度大，而且开发经验不足，所以难以保证产品运行的稳定性。

5、兼蔫牲

实现同一功能的元器件，国产进口的价格相差很大，不同厂商之间价格相差很大，而且 有的时候还会遇到器件停产和限制出口的问题，兼容性其实也是隐形的生成成本，所以，在 选择元器件的时候，当功能性能稳定牲符合要求的情况下我们会优先选择国产元器件。而目 前我们使用的单片机处理器是日立公司的SH4处理器，可是如果国产的“龙芯”在功能性能稳定性上能达到我们的要求，我们会改用国产芯片来替代进口芯片。如果将来采用“龙芯刀的话，CE和XP Enbed就难以保证可以支持，自行开发的操作系统当然必须经过修改才可以支持不同的芯片，而Linux，由于开放源代码，所以残们可以对其源代码进行修改以支持不同的芯片，而且，在北京和东北的一些高校实验室里，已经在这方面有了初步的结果。 该系统及其硬件系统已于200 3年10月底顺利完成并在全国秋季医疗仪器博览会上展出，获得同行和客户的认同与称赞。但是在开发过程中也遇到不少问题。

首先是Linux的开发经验不足，特别是Linux内核的裁剪和Linux驱动程序的开发，在 我单位开发历史上是一片空白，各种网络资源也相对缺乏，为了让开发人员更快入手，缩短 项目开发时间，在我的建议下，单位以不菲的价格聘请了工业控制界的其他公司、国外知名 培训机构和高校教授为我们进行培训，在项目结束后，裁还组织了参与本项目的软件人员根 据本故的开发文档和开发经验，编写了单位内部的嵌入式Linux开发教材，防止曰后因为人 员的流动造成经验的流失。

然后是Linux的配套软件太少，比如书写文档的办公软件，各种分析设计的辅助软件， 各种自动测试软件，版本控制工具软件，这些软件并不是没有，但使用的效果不够理想，而 且有一些我们在Windows下习惯使用的软件并没有Linux的版本，使用同类软件的话需要花 费额外的学习时间。于是我们部采用在Windows上安装VM- WARE仿真Limn:的运行，通过

虚拟网络将Linux和Windows互联，在Linux仅进行程序的运行调试和编译，其他工作部在 Windows下进行。

最后是可用软件开发包极为缺乏，除了C语言的标准运行库和Open GL，其他任何过程 函数部需要动手编写，我们通过修改一些以前在C51下编写的函数和雇请软件公司为我们编 写小型的过程模块，以减少开发工作量，确保的按时完成任务。

最后是可用软件开发包极为缺乏，除了C语言的标准运行库和Open GL，其他任何过程 函数部需要动手编写，我们通过修改一些以前在C51下编写的函数和雇请软件公司为我们编 写小型的过程模块，以减少开发工作量，确保的按时完成任务。

以Linux内核作为嵌入式操作系统的作法在工业控制领域已经初露锋芒，由干其功能强 大、生产成本低廉、可靠稳定、兼容性，必将拥有广阔的前景。希望能够在工控开发领域普 及Linux，增加Linux的交流与培训，而且，在开发过程中遵循开放源代码的思想，将自己 开发和改进的应用软件和软件开发包、类库共享出来，共同促进以Linux为代表的免费、开 衙派仲码的济入苛操作不统的考犀．

论企业应用集成

摘要：

本文讨论了某公司的应用系统集成项目。某公司为了应对市场变化的需要，决定把公司 几个主要的应用系统ERP系统，PDJK系统，E-mail系统集成在一起，系统集成完成后，ERF 系统可以与PDM系统交换数据，大大减少了重复工作。通过ERP系统与E-mail系统的集成， 可以把ERP出来的报表自动发送给相关人员。我作为该项目的主要负责人之一，担任了系统 分析和设计的工作，通过分析需求，设计三层体系结构，选择合适的平台等措施使项目能Ⅲ贡利完成。在项目实施过程中，我发现XML作为新的WEB开发语言，应是今后选择的一个方向，并且企业应用集成是一个不断发展的过程。

正文：

企业的应用集成（EAI）是指在企业范围内将多个应用系统的过程，软件，标准和硬件集成起来，使其成为无缝运作的整体。目前企业应用集成正越来越受到人们的重视。我在200<年1月参加了公司应用系统集成项目，作为项目的主要负责人，我担任了系统分析和设计的工作。项目首先是和相关部门的用户一起讨论系统集成的内容，用户希望完成系统集成后能提供给什么样的功能和服务。确定了这些需求后，就进行软件开发平台的选择和集成方案的设计。最后进行开发测试，测试完成后上线正式使用。整个项目用了五个月的时间完成，在20xx年6月交付使用。

该企业的信息化程序比较高，主要的应用系统有：ERP系统，实施了物流和财务模块，把公司的采购，财务集成到了一起；PDM系统，产品的设计和开发在该系统上进行；E-mail系统，主要是收发内部和外部的电子邮件。但是，随着企业的发展和市场竞争的激烈，问题也逐渐暴露出来。因为三个系统是独立的，没有数据的交换和共享，这样，大量相关的数据不得不重复输入。象PDJrt系统负责产品数据的的维护。当一个产品的BOJrt（Bill ofmaterial， 物料清单）成熟后，要把该BOM导入到ERP系统。因为两个系统没有关联，这样就需要安j9}人员专门负责数据的录入，往往要加班加点，且容易出错，很不利于产品快带地生产并推向市场。为此，要考试应用集成，把企业的这些“信息孤岛”联系起来实现信息的交流。我在分析了企业应用系统的现状后，分以下几个步骤来实现该企业应用集成。

一、仔细研贸觋有的系统．之间的关系，确硅要鹭釉毳J内容拼蔫毽芝实现的方祛

首先是是ERP系统和PDM系统的数据的交换，要求在PDM系统开发出来的BOJK下达

后，要自动导入ERP泵统。因为两者针对的是BOM，结构是一致的，实现两者的数据集成，只需定义统一的数据接口和格式即可。其次是E-mail系统和ERP系统的集成。用户希望有ERP系统批准的采购订单能自动发送给供应商而不必手工要从ERP系统中下载下来整理后再发给供应商。驻外地的销售人员要求能每天收到关于成品库存的E-mail。通过分析，发现公司用的E-mail系统是Microsoft Exchange Server．而Exchange提供了与外界的API接口，只要照接口规定的格式填写，如发件人，收件人，信件标题，内容等，进行填写的文件，转送到了Exchange Server后，Exchange Serve:r就可以把将其发送到指定的收件人邮箱。利用这一功能，可以在ERP上开发接口程序，下载符合要求的文件到Exchange Server上实现E-mail自动发送。

二、设计制坼拥集成帕体系结构

为了避免传统的点到点的系统集成的缺点，我提出了三层的系统集成体系结构，即把企 业应用系统分成表示层，中间层和企业信息系统层（包括数据系统），企业信息系统层由该企业的ERP系统，PDJK系统和E-mail系统组成，它们通过一个面向消息的申间件来实现数据的交换。中间层主要实现应用的业务逻辑和各种服务支持，它可以访问企业信息系统层运行且与应用相联系的数据和函数。比如前面说的ERP系统与PDht的数据交换，ERP系统与E-mail系统的接口就在中间层实现。数据从底层进入中间层，在这一层完成数据交换和集成的功能。这样通过中间层就可以实现三个系统数据的共享。客户层则包括不同类型的客户端应用，之前三个系统部是c/s结构，各自有自己的客户端程序运行在个人计算机上，集成后， 要开发出基于WEB的客户端程序，统一界面，方便访问。实现B/S与c/s共享。这样，通过中间层实现不同系统的协调工作和对企业各种事务活动的支持，屏蔽了低层的接口和技术细节，使数据能方便地交流。

三、选择合适的应用集成平台

目前，可作为开放式企业应用集成的规范和平台的主流技术有两种：一种是微软公司的 COM+规范和Windows．NET平台，另一种是SUN公司的EJB规范和J2EE平台。在平台的选择上我进行了反复的比较，最后选择了J2EE平台。因为J2EE平台的开放性与支持异构性，可移植性，支持的广泛性。对企业现有遗产系统的继承性和技术优势等。更重要的是它具跨平台的功能。公同的ERP系统是运行在HP Unix服务器上的，PDM系统用的则是Microsoft NT 操作系统，E-mail是lticrosoft的Exchange Server，这些应用使用不同的操作系统和平台， 而微软的．NET只能用在Windows的操作系统的。所以基于公司的实际，J2EE平台是合适的选择。选择J2EE平台存在的问题在于，一是成本相对比较高。二是公司的IT人员对JAVA还不熟练。为此，我在确定选用该平台后，先了解该平台的软件构成，只购买了我们需要的开发软件，从而节省了成本。对JAVA则安排了几次培训，使IT人员能很快地上手用JAVA开发程序。

在J2EE平台上，我通过JAVA在业务逻辑层的开发，实现了以下的业务流程。首先，在 PDM系统的产品结构成熟后将会有一个下达的动作，然后BOM数据通过中间层的处理自动导入到ERP系统，这能过之前已定义好的接口规范和数据格式可以很空易地实现。ERP接收到产品结构数据后，即可以运行MRP产生采购订单和生产订单，投入产品的生产。此外，通过业务逻辑层，在ERP系统上下达PO后，采购订单的数据会自动传到Exchange服务器，然后通过E-mail自动发送给供虚商。产品库存的数据也可以从ERP系统传到E-mail发给驻外地的销售人员。该应用系统集成后，用户不必再加斑加点在地在ERP系统中维护产品数据，并且保证了ERP的产品结构与PDM中的是一致的。由于实现了ERP与E-mail系统的集成，用户也不用担心哪张PO没有发送给供应商了。

项目上线后，满足了用户的需求，运行半年多来，系统基本稳定，大大提高了工作效率， 得到用户和管理层的肯定。

但也存在着一些问题。 在项目实施的后期，我们发现用JAVA编写代码效率比较低，运行速度慢，并且取数据还是不太方便。于是引入了XML技术进行数据的抽取，组织和表现，结果大大增加了开发的效率。通过该项目我认识到XML将会是今后WEB开发和实现企业集成的主要技术之一。此外，现在仅是实现了PDM系统和ERP系统的集成，之后随着企业的发展，ERP将运行在更开放的平台上。会从企业的内部应用转为一个连接到WEB上的分布式应用系统。目口ERPII,这将是以后的发展方向。

论企业应用集成

摘要：

20xx年10月，我参加了料蜒#站综合信息平台项目的开发，承担项目的方案设计任务。 该项目力图通过对车站现有信息子系统的集成，以达到共享各子系统的数据，优化企业运输 作业流程，提高企业经营管理水平之目的。

本文结合笔者的实践，以该综合信息平台建设项目为例，讨论了企业应用集成技术。在 本着集成、开放标准、管理配套的原则下，提出了基于Java技术的J2EE应用服务器作为统 一的应用集成平台，以集成适配器作为系统集成架构模式的总体设计思路，并着力介绍了该 项目关键部件一一集成适配器的构建过程。还就项目的具体实施作了详细叙述。最后，提出 了企业应用集成的持续性，并确定了下一步集成的目标。

正文：

20xx年10月，我单位承接了料彩车站综合信息平台的建设任务。由于我具有多年的铁路行业软件项目开发经验，所以我有幸被单位指定为该项目的负责人，主要负责项目的方案设计工作。

该车站是一等客货运编组站，车站所在地是矿区，有规模不等的国有煤矿及个体煤矿敦 十个，车站主要以煤炭运输为主。近些年来，随着铁路TMIS系统（铁路运输管理信息系统） 建设的逐步深入，该车站建立了若干相应的应用子系统，主要有列车确报系统、丰站现在车 系统、货票制票系统、车号红外线自动识别系统、货运计划系统、货运安全系统及货车轨道 衡计重系统等。车站希望通过综合信息平台的建设达到以下几个目标：(1)实现各子系统间 数据共享。(2)能够实时地向企业客户（货主）发布请车、承认车及货物运价调整等相关信 息。(3)通过各子系统的应用集成，使车站运输作业流程得以优化。

在设计综合信息平台建设总体方案时，我充分考虑了下面三个原则：

集成原则：综合信息平台最主要的目标是整合车站的信息资源，在考虑最大化集成各个 信息子系统时，应该避免产生新的“信息孤岛’’。

开放标准原则：在综合信息平台建设时，应该站在整个系统宏观的高度，采用开放的标 准和统一的架构来集成各信息子系统，避免各子系统“点到点’’的低效落后的集成方式，以利于将来其他新的系统能够便利、无缝的整合。

管理配套原则：建设综合信息平台的目的是通过信息共享，达到业务流程的优化，以提 高车站各方面整体管理水平。因此项目设计之时，应充分考虑企业管理方面的需求。

在遵循上述原则的基础上，经过对企业需求的认真分析，结合当今成熟的EAI技术，我 提出了以基于J ava技术的J2EE应用服务器作为统一的应用集成平台，以集成遁配器作为系 统集成架构模式的总体设计方案。如下图所示：

本设计方案从集成的广度来说，既包括了数据的集成，也包括了应用的集成；在集成的 方法论方面来讲，大部分系统采用可白盒集成方法，少数系统采用的是黑盒集成方法。 根据综合信息平台的总体设计方案，集成适配器是该信息平台的最关键部分，它负责不

I同子系统之间数据的采集、转换和交流。因此，集成适配器的选型或设计的合理与否，是项目成败的关键。由于车站各信息子系统存在操作系统平台和数据库的异构性，无法从现有的中间件中找到完全适合的产品，因此我们决定自行开发此中间件。由于铁路各车站的业务领域和业务流程存在高度相似性，所以，此中间件有较高的复用价值。

对于集成适配器的设计，我采用了一种“可插拔”的设计理念。即为每个需要集成的子 系统单独设计一个插接件，该插接件负责为与之相连的子系统提供数据及应用接口。各插接 件通过XML格式的装配文件，自由组装到集成适配器这个容器中。集成适配器为所有插接件提供一个统一的调度模块，来协调和指挥所有插件，使之能够协同运作。

在集成适配器的开发中，我选用了开源的集成开发环境Eclipse作为开发平台。对于集 成适配器调度模块的开发，我们采用7Eclipse提供的Jobs API，Jobs API封装了JDK (Java IDevelopment KitTools)的定时及同步方面底层API，降低了编程的复杂性，提高了开发效率。 在插接件的开发过程中，我们充分利用Eclipse的高度可扩展特性，在因特网上搜集该项目 可用的插件，以这些插件为扩展点，来扩展我们自己的插接件。最后我们利用Eclipse提供 的RCP(Rich Client Platf orm)技术，集成裁们的功能插件，并生成独立于Eclipse平台的、 可独立执行的集成适配器。

各信息子系统具体集成过程及效果如下所述：

(1)轨道衡计重系统

该车站的轨道衡设在矿区与车站之间，距车站站场大约2公里左右，从矿区到车站的重 车要经过轨道衡检斤，对于超重货车，要通知车站相关部门处理。由于该系统是个独立的单 机系统，计重软件采用的是VFP编制，数据库是单机的DBF。因此，我们首先从网络方面进行了集成：利用一对网桥将该系统接入车站TMIS系统。重车通过轨道衡会产生结构为：（车辆顺位、车号、车种、铁重、计重）数据，与轨道衡相连的插件会通过JDBC--ODDC桥，将数据转换为两个不同格式的副本，一份写入中心数搪库，一份作为矿区站发来的确报报文，写入确报系统的到确报库中。

通过该系统的集成，轨道衡工作人员免去了每天去车站递送过衡报表的工作，车站相关 部门可随时通过浏览器查询过衡数据，并能方便的生成各种统计数据；车站的车号员通过查 收确报报文，即可掌握过衡列车的组成内容，碱去了每列车都要到现场抄车号，回去录入的 工作流程，大大减轻了劳动强度，提高了工作效率。

(2)货票制票系统

该系统的集成我们采用了批量文件传输( FTP)方式。货票制票机在制票完成后，会自动 向分局传输货票数据。因此我们在货票传输地址表中增加一个条目，使货票数据在传送分局 的同时也传送到集成适配器，与之相应的插件将到达的80列格式货票数据进行解析，形成结构为：（票号、车号、车种、计重、运价、发货人、收货人）的数据，利用JDBC，一份写入中心数据库，另一份通过车号与现车系统的车辆库匹配，写入相应信息。

通过该系统的集成，减轻了编制出发列车确报的工作量，因为输入车号后，与该车号相 关的货票信息会自动生成，免去了去查阅货票步骤。另外，该系统的集成，使货主通过因特 网查询货票信息成为了可能。

其他的信息子系统如确报、现车系统、货运计划系统、车号识别系统等等，乜部通过各 自的接口插件进行了数据或应用的集成，在此不再祥述。

(3) OA系统和企业信息发布平台

通过TMIS各子系统集成而建立的中心数据库，是办公自动化和企业信息发布平台的数据基础。通过设在货服大斤的大屏幕显示系统，能够实时动态地发布与货运业务相关的系统， 方便了货主，提高了办公的透明度。

通过项目组成员努力工作，车站高层领导的高度重视，以及车站相关人员的通力合作，

历时四个月，该车站的综合信息平台初步完成，达到了建设之初的需求目标，得到车站的一 致好评。系统到目前为止运行稳定。

我们应该知道，企业应用集成是一个持续集成过程，是一项长期、不断进行的工程，不 能指望短时间内达到深度集成。随着铁路信息化建设的深入，还会有新的应用需要整合。我 们下一步的目标是建立该企业的企业门户，使我们前期的后台整合成果，能够在Internet上 碍I）^犀王曰．

论基于Web服务的企业应用集成

摘要

去年，裁所在的公司承担了一项为X卷烟厂建立企业应用集成的项目。主要目标是将该 厂原使用的办公系统、人力资源系统、生产管理系统等系统进行集成，使之成为一个无缝连 接的整体。我有幸参与了该项目，并担任主要的规划设计工作。

针对该项目，我们综合运用了J2EE平台构架、Web servlce\ IBM WebSphere等技术， 来实现基于Web Servlce的企业应用集成，其效果相当显著。而且如果今后有新的系统加入， 也能够很容易地添加。用户在使用该系统后，生产、经营效率有了大幅度的提高，得到了用 户的一致好评。

正文

去年，我公司承担了X卷烟厂的企业应用集成项目。该卷厂是一家大型国有企业，经迢 多年的发展和积累，形成一套行之有效的管理机制，并实施了一系列的管理、生产自动化系 统，如LOTUS的Domino办公自动化系统、人力资源管理系统、CRM客户关系管理系统、用友财务软件等商品化软件，也有该厂与一家软件公司合作开发的生产管理软件（具有源代码）。 这些软件实施于不同时间，也为各部门的生产、管理效率的提高起到了巨大的推动作用。但 是各个分散独立的系统也给企业的发展造成了瓶颈，生产第一线酌数据不能随时反馈给决策 层领导，供应链、销售链不能与生产管理系统衔接，只能用手工方式将数据输入生产管理系 统，不仅速度慢，而且经常容易出错。

随着企业的发展，这些系统也成为了一个个信息孤岛，给企业的进一步发展造成了瓶颈。 为彻底消除这些限制企业发展的因素，该厂决定实施企业应用集成，将各个独立的系统集成 起来，成为一个无缝连接的整体，使各种信息在整个企业范围内流动起来，促进企业的进一 步发展。

我公司成立了项目组，我有幸参与了该项目，并担任主要的规划设计工作。

根据以往项目的经验，我们首先进行了技术方案的选择。目前企业应用集成目前通行的 做法有三种：数据层集成、业务层集成和表示层集成。数据层集成需要修改大量的应用程序， 而使用的系统中一些是商业软件，我们无法得到源代码。而表示层集成只是集成了各个应用 程序的显示界面，就好像只是做一层外装修，无实质性的改变，而且有可能成为整个集成系 统的瓶颈。业务层集成则克服数据层、表示层集成的这些缺点，而程序代码的修改量不大， 且只是针对没有API（应用程序接口）的应用程序。因此，我们根据企业目前系统使用的状况

及残们以往开发类似项目的成功经验，经项目组讨论、央定采用业务层集成方武来完成该项目。

我们采用了J2EE的平台构架，并为企业将来在企业间和电子商务的进一步集成，采用了基于Web服务的集成方案。Web服务具有各个应用程序之间松敌耦合、位置透明、协议独立

的特点，某个应用程序的增碱变动不会影响到其它应用程序的运行，并且它所使用的SOAP、 XML等协议和技术也不被某一家公司所控制。

选定了实现平台，我们开始对各个系统进行封装、组合。各个系统的接口的异构性带来 了访问上的麻烦。为了屏蔽接口上的差异性，我们采用了将这些接口映射为统一的虚拟组件。 虚拟组件一边通过J2EE低层接口显示现有应用程序的功能，另一边通过现有应用程序接口 API和它们进行连接。这样用户就可以用统一的方式访问虚拟组件而获得应用程序的功能。我们通过采用J2EE的JCA方式实现虚拟组件对各个应用程序的访问，为每一个应用程序定制一个资源适配器，并插入J2EE的应用程序服务器中。资源适配器拿有一个指定的原系统库（用Java写的或带有自身接口单元的库），这个库同它描述的原系统具有连通性。通过J2EE平台的JCA这样一种方式，我们向用户提交了一个统一的调用接口。

解决了接口问题，接下来就要将各应用程序提供的服务通过WSDL措述服务，并且注册到企业内部的UDDI中心。我们采用了Apache axis l.0来开发Web服务，IBM的WebSphere作为消息服务器。根据该厂的要求，将各应用程序提供的服务分为5个种类来提供Web服务，分别是销售、人事、生产、供应、办公五个部分，再将各应用程序提供的Web服务具体细分如生产部分提供了物料需求计划服务、库存服务、产品目录更新服务等。并WSDL实用程序生成代理代码，发布Web服务程序；在统一的服务发布服务器上，通过UDDI服务实现发现Web服务功能，便于查询系统各模块提供的Web Servlce服务。服务请求者按照标准接口构造XML格式的SOAP Request并通过rrTP方式向IIDDI注册中心发出请求。当有一个新的物料需求计划生成时，我们通过使用JMS中间件来发布物料需求计划，使得订阅该主题的供应商得到消息。

企业信息门户EIP我们采用了IBM WebSphere Portal Server来实现。对用户帐号采用 统一管理，统一授权，用户登录系统时采用统一认证服务调用接口以实现用户身份的认证过 程，并通过单点登录SSO，从根本上改变了现有各应用程序帐号之间进行漫游，不需耍进行重新登录，给用户提供了极大的便利，并减少了不法用户利用认证攻击应用程序的可能，极大地提高了系统的安全性和可用性。

在系统实施过程中，我们也遇到了一些困难。

生产部门使用的生产管理系统是由该厂与一家软件合作开发的，没有预督API，我们便 对该系统进行了改造，由于该软件公司已找不到，而且该系统文档难以找到，因此我们对接 口改造会对原应用程序造成的兼容性、稳定性的问题估计不足，改造完成后只进行了接口改 造的回归测试，使得该应用程序一直不稳定。于是我们重新对该系统进行了深入透彻的了解， 决定采用CORBA规范的接口定义语言IDL描述接口，而J2EE与CORBA又有极大的相关性，便于今后的封装、组合。接口改造完成后，我们进行了反复的回归测试和稳定性测试，才使系统又恢复原来的运行水平。

还有就是与各应用程序供应商的协调，大家都站在各自的立场上，设想对方的系统接口 应该如何改，以适应自己的接口。经过我们和该厂的努力，最终大家部同意以最有利于集成 系统的角度进行改造。

在本项目中，我们综合运用了J2EE平台构架、Web servlce\ IBMWebSphere等技术， 来实现基于Web Servlce的企业应用集成，其效杲相当显著。而且如果今后有新的系统加入， 也能够很容易地添加。用户在使用该系统后，生产、销售、供应、办公成为一体化的无缝连 接的一个整俸，生产、经营效率有了大幅度的提高，得到了用户的一致好评。

我从实践中领会到，企业应用集成是一项技术复杂，工程繁杂的工程，但也是企业目前 最急需解决的问题。同时我也认识到，企业应用集成还有很多领域和知识点需要继续研究和 实践，新技术的应用也带来了新的要求和挑战，我将在企业应用集成领域不断探索，不断实 跬．

论软件需求分析方法和工具的应用

【摘要】

本文以某通信公司的业务报表系统开发为例，讨论了软件需求分析工具与方法的选用。 我们认为，软件需求分析是软件工程中重要的一步，直接关系到后继工程进行以及最终的产 品能否满足用户的需求，因此在整个工程中起着关键性的作用。采用适当的工具，有可能显 著减少需求阶段的错误，也可大幅度提高需求分析的质量和工作效率。当然工具的选用应当 与实际的项目相结合，充分地发挥工具的作用。本文结合我们工作的实际经历，简要讨论了 开发系统时选用的工具及其应用，选用时所考虑的原则以及所碰到的问题。在文中也结合多 种开发方法（即传统的瀑布法、信息工程法、而向对象的方法）的比较，指出各种方法的不 足之处，说明我们所采用的工具对软件需求分析所起的作用，以及相应产生的效果。

【正文】

我在某市一家通信公司工作，作为一名技术骨干，受领导委托，参与了开发本公司的业 务报表系统，我担任系统的需求分析，总体设计和部分代码的编写工作。

我所在的企业作为一家通信运营公司，分为总部、省级公司和地市级分公司三级，各级 公司之间部有数据报表的要求，但是，每一个地市分公司因所处的地方不同，经营环境不同， 所面临的问题也不一样，因比形成了各各具特色的数据报表（除地市分公司向省公司汇报的 之外）。公司又分设了许多部门，这些部门也都会需要数据，作为分析决策的依据。因此，了解各个部门的需求就成了业务报表系统的关键。

在调研的过程中，我选用了一种工具叫PlayCASE，可以从网上免费下载，有很强的功能。 下面就介绍一下，在需求分析阶段，我是如何使用这一工具的。

第一步，了解业务组织结构。公司内部的数据实际上是在部门之间流动的。业务部门需 要知道在本地覆盖区内各基站的话务量、当天的话务量（即话务量的时空分布）。财务部门需要知道本月各类用户的话费收入、预交款收入、与其他电信运营商的网间结算等。计划部门需要各部门的分析数据。计费部门需要提供本月的账单统计数据、话单统计数据分布（比如分别按照基站分布、时段分布以及按用户类别分布）、预交款统计数据、当前的欠费总额分布、催缴情况等等。这些部门时常为了数据而产生了大量无谓的争议。在使用Play CASE工具时，先要将这些部门录入到Play CASE的“业务部门”中，构成了一个信息源的接收点（或发送点）；而Play CASE通过图示表示了这些部门的关系，并转换成了相应的软件结构。实际上，这是一种系统建棋的方法，即把业务系统中的各个组织，转变为软件功能中的各个结构。这样，在需求分析阶段，明确哪些部门需要数据，从而保证了需求分析对整个公司的全面性，而不会忽略掉某一个部门，导致需求分析的不完整。

第二步，了解各个业务部门中的业务流程，使之通过PlayCASE转换成软件的运行过程， 这是一种动态建模的方法。在上一步的基础上，追踪各个部门的行为，录入到PlayCASE中， 并以形式化的语言描述各过程。对于复杂的过程，该工具不提供了进一步细化的方法，并且 形成了业务流程图和业务状态图。根据这些流程图、状态图与实际业务部门的业务相结合比 较，还是较为吻合的。在此步的实施过程中，运用了动态建模技术，使各部门业务流程的情 况在软件的运行过程反映出来，从而保证了需求分析阶段中运行过程的描述能真实地反映实 际情况，防止在后继的程序编写过程中，可能会经常发生的一类情况：程序员因为没有理解 业务流程而出现“闭门造车”的现象，从软件的功能角度上保证了软件的正确性。 第三步，将业务数据转变为软件数据，这一步工作实际上就是收集各部门所需要的数据。 分析各部门需要的数据部有哪些：以及数据是如何转换的，这可以归入“功能建模刀的范畴。 将这竺相应数据录入到PlayCASE中，选定所属的部门。这时就自动地建立了DFD图（数据

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

第四步，将业务上的数据关系转为成软件中的数据关系，这里采用了面向对象的方法， 把业务部门所需要的数据看作一个实俸，部门间的数据关系就是实俸之间的关系，比如：经 营部门所需要的用户资料、用户话费，实际上就是用户这一实俸与账单这一实体间的关系。 Play CASE提供了构件（不过我觉得是部件更为合适一些），来表示对应的数据，并提供了三 种构件的表示关系即组装关系、分类关系与相连关系。这三类关系基本上反映出了现实世界 中的业务数据之间的关系。例如现实世界中的用户资料与用户话费，在Play CASE中，可将 用户构件与账单构件和相连关系表示，这种方法，实际上是借鉴了OOA面向对象的分析方法中的类、聚集、继承、封装等概念，能较好地反映出现实中的业务；同时，这一步的工作也为总体设计中数据库的概念模式设计奠定了很好的基础。

经历了上述四个步聚以后，利用Play CASE工具自动行成了软件需求规格说明书、初步 的DFD图和业务流程图，为下一步的总体设计打好了基础。

使用Play CASE工具，使需隶分析既能继承传统的结构化分析方法，又能吸收面向对象 设计方法的优点。比如能把业务流程转变成为运行过程，业务组织转变成了软件的结构等部 体现了这一点。而在运行过程中，对复杂过程的细分以及追踪则反映了传统方法中的自上到 下分解的分析思想，这对于解决复杂系统的分析是很有帮助的。

通过使用，我觉得这个工具还是很不错的，因为它实际将以下四个方面的问题结合起来 了：软件、业务、开发人员和用户。对于用户而言，Play CASE用图形化的方式显示出业务流程，使用户了解业务在软件中的运行过程，提供了将来验收软件时的依据，对于开发人员来说，使开发人员能更清楚地了解业务流程，不会再发生“因为不理解用户的需求而出现的闭门造车情况，从而导致开发出来的产品不符合用户需要”的现象。因此，Play CASE所自动提供的需求说明书能够很好地沟通用户与开发人员之间的理解，使他们都能对需求有共同的理解。

使用Play CASE工具后，使我们的需求分析取得了很好的效果，不但能自动地提供许多 结果，如需求说明书等；还使需求的质量有限很大的提高受到领导的赞扬（领导不是学计算 机的，但对公司的业务十分熟悉）；在后继的设计与维护工作中，我们感到工作似乎轾松了很多。

当然，该软件工具也有不足之处，一个突出问题是灵活性不够，一旦公司的部门或者组 织机构发生变化时，整个设计都要重新来过。因此，在改进的过程中，我们在第一步过程预 鼙了好多个虚拟的部门，以备j辑来i井一步的扩充或者蛮动。

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

摘要

本文通过xxx高速公路收费系统（以下简称收费系统），来论述分布式数据库的设计与实 现。收费系统是我公司近年来接的较为大型的项目，管理结构为三层结构：公司级、收费中 ·心级、收费站级，各级之间即可独立的完成自身业务，又有自上而下的管理关系。收费中心、收费站均为三层C/S结构，公司级采取B/S结构。该系统的数据库也按照三层来设计，收费站存放本站的所有流水数据，收费中心存放所有数据，公司本部存放查询用汇总数据，收费站与收费中心使用事务复制来同步数据，而收费中心与公司本部使用快照复制来同步数据，并且使用分级的方法来测试收费站、收费中心与公司本部之间的数据同步。 在本项目的开发过程中，我担任了数据库的设计工作。

．正文

20xx年10月-20xx年12月我公司开发了高速公路收费系统（以下简称收费系统），收 费系统项目从管理层面分为三层结构：公司级、收费中心级和收费站级。

公司本部：供领导、运营部、财务部等业务部门了解业务情况、检查工作。B/S结构各 部门通过Web服务器查询数据库服务器，而公司数据库服器定时要求中心数据库服务器复制汇总数据。

收费中心：收费系统的管理中心下达管理制庋，管理数据到收费站，接收统计收费站的 I收费数据，上报汇总数据到公司，负责日常的管理工作。

收费站：具俸进行收费的单位，收费车道的数据通过通信系统实时上传到收费站数据库 保存、分类、汇总，并且实时传送收费中心下达的数据库管理，并通过通信子系统下载到车 道收费机上具体实施。

系统采用三层C/S与B/S的混合结构，收费中心与收费站为三层C/S结构，而公司级为 IB/S结构。我在项目中担任了数据库的设计工作，负责数据库的设计、测试及实施。 i数据库.设计

此收费系统的结构较为复杂，分为公司级、收费中心、收费站三级管理结构，既可独立工作，又有管理的联系。数据实时传送到收费站数据库服务器，再实时传送到收费中心数据库服务器。 在数据库设计方面我们按物理的分布也分为三层结构。

在收费站，根据系统的需求分析的结果，一辆车通过收费站时产生的最基本的数据有：通过日期、时间、车型、收费类型及收费金额，因为收费标准不轻易改变，考虑到我们采用的是专用的车道收费机，存储量较小，所以收费金额项在此处不计入数据库，上传至收费站数据库服务器后，可以用车数乘以此类车型的收费标准而得到。当车道收费机上传数据到数据库时，还要加上工班、车道及收赛员信息，保证数据的唯一性，所以我们把日期、时间、工班、车道、收费员、收费类型、车型设为组合主键，为车辆流水数据。收费员下班后还要上缴实收金额，因此还要保存实收金额，包括日期、工班、收费员及实际收费金额，为工班收费数据。在此基础上，分析、汇总数据，得到以下几类数据：

业务类型数据：车辆流水数据、工斑收费数据、车道开通情况、收费员上班情况；

扩展的数据：为了查询、打印的方便、高效，流水表经过分类汇总，产生了以车道分类统计 的车流量表（日、月）、以收费员来分类统计的收费金额表（日、月）及不收费 车辆统计表；

管理类型数据：收费标准、收费员信息、收费站信息、车道信息、工斑信息、收费类型信息； 从全局应用的角度出发，各收费站存放本站的数据，收费中心的数据库则存放所有数据， 并对数据进行完整性和一致性的检查，这种做法虽然有一定的数据冗余，但在不同场地存储 同一数据的多个副本，能提高系统的可靠性、可用性，使系统易于扩充，也提高了局部应用 的效率，减少了通讯代价，同时也使得各处理机之间的相互干扰降到最低。

公司总部存放所有收费站的汇总数据，通过浏览器进行查询。

数据的分布

(1)在收费中心数据库服务器与收费站数据库服务器的敦据关系中，由于收费站的数据 是收费中心数据的子集，我们采用了水平分片的方式，通过并运算实现关系的重构。

(2)在收费中心数据库服务器与公司总部数据库服务器的数据关系中，数据是按照其应 用功能来划分的，所以我们采用了垂直分片的方式。

公司本部

收费中心

收费站

管理

据

┏━━━━━┳━━━━━━━┓

┃ J ┃L ┃

┃ ┃汇总数i ┃

┣━━━━━╋━━━━━━━┫

┃ ┃ ┃

┣━━━━━┻━━━━━━━┫

┃中心服务器 ┃

┣━━━┳━━━━┳━━━━┫

┃ ┃ 一 ┃L ┃

┃型数 ┃ ┃业务； ┃

┣━━━╋━━━━╋━━━━┫

┃ 1 ┃r ┃ ┃

┣━━━┻━━━━┻━━━━┫

┃收费站服务器 ┃

┗━━━━━━━━━━━━━┛

数据同步的方式

（快照复制）

据 （事务复制）

数据分布在多个地点，为了保证数据的一致性及完整性，我使用了事务复制和】快照复制两种数据同步的方式，在收费中心与收费站之间使用事务复制，而在收费中心和公·司总部之间使用快照复制。

对于业务类型的数据，收费站在本地存放收费车辆的实时数据，而用户也要球刈史费中心 也要实时的收费车辆数据，延迟不超过2秒，所以我采用事务复制进行业务数据的同步，收 费站只需将更新的数据发送到收费中心的数据库即可。具体过程如下，把收费站的数据库作 为出版者和分发者，收费中心的数据库作为订阅者，对收费站的数据建立快照代理，并在分 发数据库中记录同步状态的信息。每一个使用事务复制的收费站数据库均有自己的日志读取 代理，运行在分发者上并连接出版者。分发代理的任务是将分发数据库中保持的事务任务直 揍推动到订阅者。当推订阅被创建时，每个为立即同步而建立的事务出版物通过自己的分布 代理运行在分发者上并与订阅者相连。

而管理型的数据是在收费中心设置，虽然修改的频度不是很大，但在修改后即要发生作 用，所以也采用事物型复制，收费中心为出版者，收费站为订阅者。将管理型的数据发布到 各收费站。

由于公司总部不需要实时更新，所以收费中心数据库服务器与公司总部服务器之间的数 据同步设置为快照复制，公司总部数据库中建立收费中心表的快照，对这些数据的修改在收 费中心进行，把收费中心数据库服务器设置为出版者，出版物为汇总数据，公司总部数据库 服务器设置为订阅者，快照代理将准备包含有被出版数据表的结构与数据的快照文件，在分 发者上存储这些文件，并在分发者的分发数据库中记录同步任务。在收费中心数据库服务器 上建立一个作业，设置为每天早上8点更新一故（收费日的天为8点到第二天8点），公司总部就能得到截止到前一天所有收费站的汇总数据。

测试

数据库设计好了，就要对它进行测试。我们的测试策略为分步测试：首先测试收费站数 据的正确性及完整性，在多台收费机上同时输入几组车型、收费类型的数据，查询数据库的 流水数据是否正确，再看汇总数据是否正确：收费站正确后，再测试收费中心的数据的正确 性、完整性及延时；再测试公司总部的数据正确性、完整性。

一开始我们把所有的表部建立在一个出版物中，但在测试中转们发现，由于收费站一个表 的错误而造成的复制的中断，经常要重新配置复制，所有的表都要重新选择及设置一遍，非 常繁琐，我们采取一个表建立一个出版物的方法来简化操作，只要恢复出错的复制，其他的 复制仍然能正常执行，而且哪一个表的复制发生中断也很明确，不仅简化了操作，也加快了 处理时间，就是日后用户维护起来也简单明了。

在设计过程中，基于查询及安全性的需要，我们大量的使用了视图，第一加快了查询速 度；第二也防止了人为因素造成的数据的更改。

总结

按照以上的设计方案实施后，完全满足高速公路系统对数据实时性和完整性的要求，系 统目前只在内部使用，而以后全省的高速公路收费系统实行联网，在外网上发布信息，那时 持埋的害全幛碍杏；句的晌商；童窿，皇旱势们若由的雷占一

改进Web服务器性能的有关技术

【摘要】

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

本人有幸作为项目负责人之一参与了某大型图书馆数字化信息系统的设计和基于Web应用软件的开发工作。由于在数字化图书馆信息系统中流通着的大多是数字化的索引、文摘、 全文、图像或音频视频等多媒体信息，对Web服务器性能有着较高的要求。

结合实际工程经验，本文将从硬件实现手段（缓存服务器、均衡负载设备、Web双机镜像、CPU和网卡的提升、网络带宽扩充）和软件实现手段（三层C/S软件结构设计、应用程序部署）等两个大方面论述如何提高Web服务大路的性能，以便使用户能够更快捷、高效、安全地使用应用系统。

【正文】

随着Intranet信息技术的发展，图书馆为了更好地发挥其图书流通、资料检索和学术交 流的职能，图书馆的数字信息化工程也势在必行。某图书馆为了尽快地步入世界先进图书馆 的行列，已经启动了一部分的数字图书馆工程。

该数字图书馆工程主要包括对外信息Web发布系统，交互式检索网，后台馆藏信息管理系统、多媒体资料采集制作以及外VOD点播系统等。本人有幸作为项目负责人之一，参写了整个数字化信息系统的总体设计，并参与了基于Web的一些应用（如对外信息发布系统、图像．／全文混合系统、VOD点播系统的）开发。

某图书馆数字化信息系统从网络环境上讲，主要划分为多个网段：（一）Intranet接入部 分，采用2M的DDN专线；（二）公共网段（非军事区），主要包括前台发布数据库服务器、Web服务器、E-mail/FTP/DNS服务器、检索服务器及SAN网络区域存储设备；（三）是内部局域网，包括内网Web服务器、后台馆藏数据库服务器、OA服务器等。（四）是VOD点播专用网，包括音频视频点播服务器等。由于制定了严格的网络级和应用级访问权限，通过具有三层交换能力的高性能交换机和安全授权认证系统等，有效地控制了访问权限，确保了数据的安全性和完整性。考虑到经费和人员素质及今后的维护管理运营等方面，操作系统采用WindowsNT平台，服务器选用DELL高端的系列，数据库采用IBM的DB2。主干网为千兆快速交换式以太网，局域网百兆到桌面，VOD点播网十兆到桌面。

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

统；（二）后台馆藏信息管理系统和图像．／全文混台检索系统；（三）VOD点播系统。由于绝大部分应用采用Browser/Server方式结构，最终用户在本地只需安装IE或者Netscape Web浏览器，在后台数据库服务器的支持下通过网页方式请求和访问各类应用服务。另外，由于在图书馆信息系统中流通的多为索引、摘要、全文或音频视频等多媒体信息，对Web服务器性能与网络带宽等有更高的要求。

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

(1)缓存服务器和均衡负载设备使用可以缓解访问瓶颈，提高网络带宽、实现均衡负载。 缓存服务器也称为cache服务器，可以存储cache静态的内容如网页、多媒体点播资源 和会议实况（已压缩的、有一定格式要求的）等。此外，目前美国cashflow缓存服务器，已经可以存储cache数据库、ASP等动态内容。cache服务器通常放到防火墙之外，外网Web服务器之前，因此Inrternet用户点击网页不再直接访问网站Web服务器，而是访问cache服务器。

由于cache服务器具有多个CPU和高速大容量I/10通道，独立的OS，因此能大大缓解 Internet访问瓶颈，而且也具有一定的抗黑客攻击酌能力。

目前某图书馆采用这种方式，把大数据量的静态图片、点播资源、虚拟三维应用等部事 先置放在cache服务器中，即使现今只有2M internet的接入带宽，以上应用的播放速度和 效果仍能让用户满意。

另外一种方式采用均衡负载设备或Web双机镜像。这种方式通过负载均衡的方法达到Web访问性能最优。Web双机镜像是较早以前流行的方式，虽能使系统可靠性提升，但由于双机总是在互相询问对方状态，将会影响一定的访问性能。均衡负载设备是独立于Web服务器的硬件，它和Web服务器及网站中其他服务器接在同一交换机上，通过负载调度程序为各个服务器分配工作量，从而，能达到充分利用资源，提高访问性能的目的。只是由于某图书馆目前对外发布资源相对仍较少，只有用了三台Web服务器，因此目前的均衡负载设备作用还不显著。

(2)从Web服务器的配置来看，Web服务器自身CPU个数及速度、网卡数量、Web服务 器与防火墙的位置关系等，都会影响到Web服务器的性能。

从Web服务器硬件本身来讲，CPU个数的增加、网卡个数的增加、1/0信道的扩展无疑可以直接地提高Web服务器性能。此外，由于千兆口的防火墙目前较少且费用较高，如果把Web脲务器放置防火墙之后，一定会大大影响Internet访问性能。某图书馆采用IDS（入侵侦测）+Web服务器（服务器防火墙，较低端，不会影响流量）邯翌用服务器《乏据库服务器（防火墙，高端），分层次的安全模式，既保证了系统的安全模式，既保证了系统的安全性，又提升了网络访问性能。

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

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

将业务逻辑、通用访问接口与数据等相互分离、分别置放于Web服务器、应用服务、数据库服务器上，通过过程序功能和逻辑的合理部署，也能大大改进Web服务器性能。 一般的原则是，Web服务器只需接受Internt http访问请求，使Web只有最少的任务， 把实际处理交给各个应用服务器处理，然后返回结果给Browser。某图书馆采用这种方式专门开发了搜索引擎应用服务器和混合检索应用服务器等，达到了良好的应用效果。

事实上，Web服务器的性能提升还存在很多手段和方法，比如CPU与存储之间关系，Web 交换机等等，有待干袋们浒一步的实践、分析和讨论。