国内加入ＷＴＯ后，国家最后将舍弃对国有商业银行提供无限量的信用支持，金融机构势必会在市场经济的"大海"中按自然规则"物竞天择"。要想在勉励的角逐中立于不败之地，国有商业银行需要加快金融电子化的节奏，采取有效手段，飞速打造以决策支持系统为核心的管理信息管理软件，高效地处置和借助信息，提升信息化水平，增强角逐实力。怎么样依据开发系统的规模、技术复杂的程度、管理水平的高低、技术职员的素质及开发时间的需要等不同要点，确定管理信息管理软件开发办法，确保以较小的投入获得最佳的成效，这一直是管理信息管理软件开发职员所关注的课题。笔者依据开发实践，将管理信息管理软件的开发办法，总结为以下几种：

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

⑴开发目的明确化。结构化生命周期法的系统开发以"用户第一"为目的，开发中要维持与用户的交流，获得与用户的共识，这使管理信息管理软件的开发打造在靠谱的基础之上。

⑵工作阶段程式化。结构化生命周期法每一个阶段的工作内容明确，这便于开发过程的控制。每一阶段工作完成后，要依据阶段工作目的和需要进行审察，这使阶段工作有条不紊，也防止为未来的工作留下隐患。

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

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

1、点击数和页读数 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? 总之，页读数的统计，也就电商网站访问量的统计鼻子

2、页读数的统计 为了计算页读数，需要拟定一些把页读数从点击数中区别出来的办法。下面是电商网站常常考虑到的一些原因：文件名、文件种类（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服务器的访问日志中计算访问记录，而不少请求从不在访问日志中留下痕迹。由于没十全十美的策略，所以用哪种统计办法取决于网站的实质状况。

3、计算访问人数 计算访问人数比计算页读数难得多，而且没绝对靠谱的计算访问者人数的办法。 基本上有三种信息可以用来跟踪访问者：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。