商业银行管理信息系统开发方法浅探

我国加入ＷＴＯ后，国家最终将放弃对国有商业银行提供无限量的信用支持，金融机构必然会在市场经济的"大海"中按自然规则"物竞天择"。要想在激励的竞争中立于不败之地，国有商业银行必须加快金融电子化的步伐，采取有效措施，迅速建立以决策支持系统为核心的管理信息系统，高效地处理和利用信息，提高信息化水平，增强竞争实力。如何根据开发系统的规模、技术复杂的程度、管理水平的高低、技术人员的素质及开发时间的要求等不同要素，确定管理信息系统开发方法，确保以较小的投入取得最优的效果，这一直是管理信息系统开发人员所关注的课题。笔者根据开发实践，将管理信息系统的开发方法，归纳为以下几种：


一、周期法 该方法是由结构化系统分析和设计组成的一种管理信息系统开发方法， 图1结构化生命周期法的开发过程 亦称结构化生命周期法。其基本思想是将系统的生命周期划分为系统调查、系统分析、系统设计、系统实施与转换、系统维护与评价等阶段。应用系统工程的方法，按照规定的步骤和任务要求，使用一定的图表工具，完成规定的文档，在结构化和模块化的基础上进行管理信息系统的开发工作。结构化生命周期法的开发过程一般是先把系统功能视为一个大的模块，再根据系统分析设计的要求对其进行进一步的模块分解或组合。基本做法如图1所示。 结构化生命周期法主要特点是：

⑴开发目标清晰化。结构化生命周期法的系统开发以"用户第一"为目标，开发中要保持与用户的沟通，取得与用户的共识，这使管理信息系统的开发建立在可靠的基础之上。

⑵工作阶段程式化。结构化生命周期法每个阶段的工作内容明确，这便于开发过程的控制。每一阶段工作完成后，要根据阶段工作目标和要求进行审查，这使阶段工作有条不紊，也避免为以后的工作留下隐患。

⑶工作文件规范化。结构化生命周期法每一阶段工作完成后，要按照要求完成相应的文档报告与图表，以保证各个工作阶段的衔接与系统维护工作的便利。

⑷设计方法结构化。结构化生命周期法采用自上而下的结构化、模块化分析与设计方法，使系统间各个子系统间相对独立，便于系统的分析、设计、实现与维护。 结构化生命周期法被广泛地应用于银行管理信息系统的开发中。该方法适合于银行业务工作比较成熟、定型的系统，如作为银行管理信息系统信息采集的自助银行、企业银行、电话银行、销售点服务系统、多媒体查询系统等为客户提供金融服务、信息咨询的系统。在管理系统开发方式上，银行根据系统的复杂程度以及自己的人力、资金等状况，可在独立开发、合作开发、委托开发、购买现成软件这四种模式中选择其一。 二、原型法 该方法是一种根据用户需求，利用系统快速开发工具，建立一个系统模型，在此基础上与用户交流，最终实现用户需求的快速管理信息系统开发方法。 原型法开发过程包括系统需求分析、系统初步设计、系统调试和系统转换、系统检测与评价等阶段。用户仅需在系统分析与系统初步设计阶段完成对应用系统的描述，开发者在获取一组基本需求定义后，利用开发工具生成应用系统，快速建立一个目标应用系统的最初版本，并把它提交给用户试用、评价、根据用户提出的修改补充，再进行新版本的开发，反复这个过程，不断地细化和扩充，直到生成一个用户满意的应用系统。 原型法的开发过程如图2所示。 目前,我国市场上的管理信息系统快速开发工具有：ＰＯＷＥＲ ＢＵＩＬＤＥＲ、ＶＩＳＵＡＬＢＡＳＩＣ、ＶＩＳＵＡＬＦＯＸＰＲＯ、ＤＥＬＰＨＩ等。利用这些面向对象的开发工具，可使开发者的精力和时间集中于分析应用问题及抽取反应应用系统实质的事物逻辑上，而不再拘泥于应付处理繁琐的开发实现细节，节省了大量的编程工作，并且使系统界面美观，功能较强。 原型法具有开发周期短、见效快、与业务人员交流方便的优点，被广泛地应用于银行的财务报表系统、信贷管理系统、工资人事管理系统、固定资产管理系统等的开发中。 三、综合法 综合法是将周期法和原型法两者结合使用，采用结构化生命周期法的设计思想，在系统分析与系统初步设计上采用原型法作出原始模型，与用户反复交流达成共识后，继续按结构化生命周期法进行系统详细设计及系统实施与转换、系统维护与评价阶段的工作。 综合法的优点是它兼顾了周期法开发过程控制性强的特点以及原型法开发周期短、见效快的特点。商业银行在管理信息系统开发中，可针对不同的实际情况，合理采用综合法，使开发过程更具灵活性，往往会取得更好的开发效果。 四、实例 今年上半年笔者采用原型法，开发了交通银行南通分行计划信息管理系统，下面就以该系统为例具体介绍一下原型法的主要开发过程。
（ 1）系统需求分析、系统初步设计。通过与计划处交流，明确了本系统的设计目标，即通过对财会处人民币和国外部折美元会计月报表、资产负债表、损益表及计划处信贷收支表数据进行收集、存储、检索、传输、加工、分析，为计划处及其它管理部门的科学决策服务。并根据确定的设计目标初步完成系统基本数据流图、主要功能模块图、网络结构图的设计。
（2）系统模型的确定。为实现不同部门间信息资源的共享，本系统的基本模式设计为典型的Client/Server体系结构，在分行计划处设立数据库服务器，作为数据处理中心，计划处及其它管理部门的客户机，通过局域网与服务器相连，进行操作。Server端采用Sybase数据库作为数据库系统，Client端采用PowerBuilder 6.5作为开发工具，网络协议采用TCP/IP的通讯协议。
（3）系统模型的实现。使用面向对象的PowerBuilder 6.5设计界面快速且美观，因此本系统的Client端设计重点不是在界面设计上，而是在提高系统的通用性上。由于计划处报表统计条件改变频繁，这给生成报表数据带来一定的难度。本系统设计上采用?quot;参数表驱动法"，使数据与程序相分离，即基于通用报表结构的报表程序，极大地减轻了报表的编程工作量。Server端设计主要是建立帐务类、字典类、控制类系统数据库表。
（4）用户审核。将本系统的最初版本提交给计划处使用，笔者根据计划处在使用过程中提出的修改意见，不断完善系统，如此重复，直至计划处满意为止。
（5）系统维护与评价。本系统提交给计划处正式投入使用，为维护方便，笔者建立系统开发档案，至此，本系统的开发过程基本结束。 电子商务网站访问量的统计 南通航运职业技术学院 王建华 内容提要：作者就电子商务网站建设中的一个实际问题--网站访问量统计，介绍了电子商务网站访问量统计信息和方法。 关键词：点击数；页读数；访问人数；访问量 我们的主页的页读数是多少？有多少人在访问我们的网站？这往往是电子商务网站迫切需要知道的实际问题。 遗憾的是，大多数电子商务网站建立初期，往往只考虑网站的内容和版面，并没有想到某一天会要跟踪网站的访问量。当广告客户询问网站的访问量，想知道有多少人访问网站，浏览网页时，为跟踪访问量忙得疲惫不堪的工作人员往往拿不出令人信服的统计资料。本文就此问题，谈谈电子商务网站访问量的统计信息和方法，目的在于抛砖引玉。

一、点击数和页读数 Web服务器能记录它得到的每次请求的信息。对我们有用的请求的信息包括：点击的日期和时间 、主机名 、请求 、被授权的访问者的登录名、Web服务器的反应码、涉及者、访问者的user agent、访问者的IP地址、访问者的主机名（如果其IP地址可以被翻译出来）、传输的字节数、被访问的文件的路径、访问者发送的Cookies 、Web服务器发送的Cookies 。 上述能收集到的访问量数据不多，而且得到的信息也不可靠。可用的信息不准确，但不是完全不可用。虽然数据不精确，但仍然可以知道有多少人在用我们的网站。正如我们知道的，用计数器可以很容易地知道有多少点击数，但对于更精确的分析，我们将不得不存储得到的点击数。一个简单的办法是把信息存储在Web服务器的log文件中，然后定期地加载数据库的table或直接把信息写到数据库的table中。 点击是我们的服务器收到的任何文件请求，包括图像、声音文件和任何出现在页面上的东西。如果直接加载数据到数据库中，我们需要一个已经实现这种功能的Web服务器（如Microsoft腎IS），或需要源代码。也可以用第三方的API，如Apache的DBILogger。实现了这样的功能，就可以收集失败点击的次数（只需计算状态码为4xx的点击的数量）。 页读数更准确些，因为它把一页当作一个整体 ，而不是它的各个部分。计算点击数不如计算页读数得到的信息量大，而且点击数计算的结果与其它网站很难进行比较。页读数就不同了：按时间块的页读数，可以查看每5分钟的页读数变化；按访问者的域名分类的页读数，可以确定他们是在工作时，工作前还是工作后访问我们的网站；按登录用户的页读数和非登录用户分类的页读数，可以确定允许用户登录是否值得；按信息来源分类的页读数 ，可以确定访问者进入页面是通过一个连接还是一个旗帜广告？他们从哪里来？这些信息可以帮我们了解访问者的兴趣，可以确定往哪儿投资，与哪些人合作；按访问者的硬件平台、操作系统、浏览器及其平台统计的页读数 ，可以确定 Mac用户和PC用户的比例各为多少？Netscape和IE的用户各为多少；按访问者主机统计的页读数 ，可以确定访问者中有多少人用AOL？有多少人用Earthling? 总之，页读数的统计，也就电子商务网站访问量的统计鼻子

二、页读数的统计 为了计算页读数，需要制定一些把页读数从点击数中区分出来的方法。下面是电子商务网站经常考虑到的一些因素：文件名、文件类型（HTML、GIF、WAV等）、Web服务器的反应码、访问者的主机。一旦确定了哪些点击是页读数，哪些不是，就可以计算网站的页读数了。我们按照文件的路径确定页读数算在哪个具体部分，如http://www.hotw.com/web/99/13/index0a.html算做Web的页读数；http://www.hotw.com/sys/99/12/index3a.html则算做Sys的页读数。如果这种标准在网站的各个层次上实行，可以得到网站的详细统计。我们有时希望把一个页读数算在某一部分，在其它部分算在另一部分。 电子商务网站页读数的统计方法通常有如下几种。
1．远程数据跟踪 页读数增长的速度是多少？年底的时候我们期望的页读数是多少？网站的哪部分页读数增长得最快？哪部分最慢？ 各种浏览器的比例随着时间变化的趋势是怎样的？ 人们过多久访问我们的网站一次？ 从其它网站的旗帜广告第一次进入我的网站的人，他们随后读了多少页？ 一旦我们看到可用的各种类型的信息，我们就会得到需要长距离回答的各种问题。如果我们对回答这些问题感兴趣，那么多天的跟踪就会有用。 进行远程数据跟踪，可以考虑使用数据库。我们可以编写程序从点击数日志中提取想要的信息。如果数据库设计得合理，查询信息的时间比用程序从日志文件中提取信息快好多倍。数据量越大，这种差别越明显。 如果只存储感兴趣的点击，可以节省大量的数据空间。 也可用SQL从数据库中提取数据。SQL是一种小型的、简练的只需学很少的命令和语法的语言。而且，其命令结构简单明晰，好的程序员建立一个SQL查询比编程做同样的事快得多。而且其结果错误更少，更容易理解。 如果不想用SQL，可以用一种数据库访问工具如MS Access 或 Excel。这些工具都很好用，而且是图形界面。
2．计算访问时间 电子商务网站的市场部和广告部都喜欢统计访问时间，即某人在离开我们的站点前停留了多长时间。但是，用HTTP是不可能确定这个数值的。 假设一个客户在正午时访问Hot的一个页，然后该客户在12:28 p.m.访问Hot的另一页，那么该客户对Hot的访问时间是多长呢？该客户可能在这28分钟内一直盯着第一个Hot页，但是该客户也可能在这28分钟内新开了一个窗口，浏览另一个网站。 但是，我们的用户确实需要这种信息，那么该怎么告诉他们呢？ 我们可以去Internet Advertising Bureau，它定义了一个访问为"没有连续30分钟的不活动的访问者的一系列页面请求 "。当有人问起我们的网站的访问时间时，我们也可以在IAB的定义的基础上告诉他们。
3．计算访问来源 如果访问者点击某个连接或某个旗帜广告到达我们的网站，他的浏览器会随着这个请求发送他刚离开的站点的URL，这个URL称为"referer"。 Netscape和IE对访问的来源的处理方式不同。如果我们点击原始页到一个有frame的页，Netscape将把原始页作为对包含frame的页和每个frame中的页的来源；IE把原始页作为包含frame的页的来源，这个包含frame的页反过来把它本身作为各个frame页的来源。进一步，我们可能还会得到每页的页读数的数据。如果把网站分成频道或部分，则可能得到每部分的数据。 需要注意的是，上述方法计算出的页读数不是我们的网站的实际页读数。这是因为我们统计的是在Web服务器的访问日志中计算访问记录，而很多请求从不在访问日志中留下痕迹。因为没有十全十美的方案，所以使用哪种统计方法取决于网站的实际情况。

三、计算访问人数 计算访问人数比计算页读数难得多，而且没有绝对可靠的计算访问者人数的方法。 基本上有三种信息可以用来跟踪访问者：IP地址、成员名（如果网站使用成员注册）和cookie。 最简单的办法是计算log文件中的唯一IP地址的数量。但是，最容易的办法通常不是最好的办法。这种方法是可用的最不准确的办法。大多数人在每次连接时得到不同的IP地址。这是因为很多ISP为用户赋予动态的IP地址，例如，当一个AOL用户上网时，AOL给他一个IP地址，当他断开连接时，AOL把这个地址赋给另一个用户。这样，当我们进行统计时，我们不知道这是两个用户。 如果要求用户使用成员身份登录，统计将很容易和准确。但很多人不喜欢需要登录的网站，这就使得跟踪成员名的统计没有实际意义。 最后，可以使用cookies。为每个访问者定义一个包含唯一值的cookie，我们把它称为机器ID。如果某人访问我们的网站时没有提供机器ID（可能她是第一次访问，或者她的浏览器不接受cookies），把她当作新用户，并为她访问的页发送一个cookie。 使用这种方法要注意的是：
1． 很多人关掉了cookies的功能；
2． 可以用浏览器删除旧的cookies；
3． cookie存储在访问者的机器上（ 访问者可能用不只一台机器访问我们的网站）；
4． 多人公用一台机器；
5． 代理服务器对cookies的处理不同。 考虑到以上因素，我们在电子商务网站这样做： 如果计算一天的访问者数量，我们计算成员名；对于没有成员名的点击，我们计算cookies； 对于既没有成员名，也没有cookies的点击，我们计算IP地址；如果计算多天的访问者数量，我们只用cookies；如果只关心某一天的数据，可以用处理log文件的程序，如果希望得到多天的数据，应该把它存储在数据库中。 如果不能准确记录每个单一请求，当然就不能得到网站的访问者的完整数量。 前面没有讨论的一个问题是cookie和新的访问者。假设我们想计算昨天的访问者人数，就要用我们前面讨论的方法。当某人第一次访问我们的网站时，他还没有cookie，我们的Web服务器随着被请求的页发送给他一个新的cookie。现在，假设这个访问者然后请求第二页，这时的请求有一个cookie，访问者的点击记录将有一个cookie。 当我们用Perl脚本（或别的什么）计算访问者数量时，如果允许认证，我们首先计算成员名；对于没有成员名的点击，可以计算cookie；对于没有成员名或cookie的点击，可以计算远程IP地址。但这种方法重复计算了新的访问者。一个访问者的第一次点击没有cookie或成员名，所以IP地址被计算在内。这个访问者的随后的点击将用成员名或cookie计算。 在电子商务网站中，我们记录cookie被发送的次数，虽然我们没有收到cookie。每一个夜晚，我们寻找包含被发送cookie的点击。对于每一个，我们检查等于那个被发送的cookie的被接收的cookie的其它点击。如果能找到，我们在把这些点击数装载到数据仓库之前把发送的cookie值转移到接收的cookie的字段。当使用我们的计算方法时，此人将只被计算一次。注意我们不只是简单地把发送的cookie和接收的cookie进行合并。这么做会重复计算屏蔽cookie的人。 假设我们有不止一个计算点击数的域，例如，123.com和abc.com。我们可以计算到123.com和abc.com的访问者数量，但是总数肯定不会与这两个数的和相等。 为什么会这样呢？假设一个访问者访问123.com，他没有cookie，于是我们的Web服务器发送一个给他。然后他又访问abc.com，访问者的浏览器不会发送123.com的cookie给xyz.com的Web服务器。这样，abc.com的Web服务器发送另一个cookie给访问者，对于一个访问者有两个不同的cookie。解决这个问题的办法是使用一个主域名，如123.common.com和abc.common.com，这样可以有一套cookie。