款总量受三个因素影响:银行自有资金、中央银行再贷款和再贴现额、组织存款的数量。由于前两个因素非专业银行内部所能决定,因此专业银行贷款总量/管理的主要内容是组织存款数量问题。为有效进行贷款总量控制,需要解决历史规律的统计与未来趋势的预测两大问题,从而有的放矢地组织吸收存款。
(2)贷款结构管理
根据各个时期经济发展的目标要求,决定贷款支持什么,限制什么及期限长短。本系统所需解决的是A银行内部对不同期限贷款的控制,即贷款的期限性结构管理,也就是银行贷款的期限结构应当与银行信贷资金来源的期限结构相适应,长期性的贷款可用长期性的资金来源,短期性的贷款可用短期性的资金来源。要保证贷款的期限性结构合理,需对历史发生的存款按期限进行分类统计,对已发生和计划中的贷款按期限进行分类统计,从而判断一段时期内的贷款结构是否合理,如不合理,则还要决定调整方向。
3.3提高工作效率,为银行微观决策提供基础的信息依据
由于目前A银行内部各单位信贷员和统计人员使用传统的手工记账工具,经常要翻阅大量的台帐,运用计算器等辅助工具进行计算、统计、制作报表。采用这种工作方式工作量大,效率低,易出错,准确性差,及时性差。同时这种方式提供的信息量也不够大,且比较单一,不能满足现代信贷管理工作对大量数据和经济信息进行分析的需求,从而也就难以满足微观决策所需的数据和信息要求。而且任何历史信贷信息是对信贷活动进行分析的重要依据,缺少了这些数据和信息,分析结果就没有说服力。而本系统的建立,不仅可以提高银行工作人员的工作效率,降低银行工资成本和管理费用等,而且可为信贷管理微观决策提供大量数据信息,为决策提供准确、及时、高质量的依据。
可行性研究
4.1经济可行性
A银行目前由于完全采用纯人工方式完成业务,进行报表制作,对数据进行综合分析等,所以耗用工时较多,且效率低下。目前银行内部的日人工成本为:(**)人*(**)元/人日-(*)元。还不能计算出因效率低下而给银行带来的无形经济损失,如果把这一部分也看作成本,那将远远超出目前的计算数额。而如果开发出一个能满足业务要求的信贷管理系统,在采用生命周期法的前提下,从问题识别到系统实施、评介、维护,开发周期如以两年计,其需人工成本(**)元,略高/低于两年的人工费用总和。同样,也无法估算出由于系统的开发应用使银行运营效率提高而带来的无形的巨额经济效益。由此可见,开发此系统在经济上是完全可行的。而且,由于系统能在未来较长的一段时期内稳定地发挥作用,这对于银行提高信贷管理水平有很大的帮助,并能使A银行早日接入到总行的更高层次的网络体系中,可以更加广泛地吸收各方面的信息资源,可为银行业务在将来的扩张打下坚实的基础,其经济效益将更上一层楼。
4.2操作可行性
如前所述,A银行内部大多数员工从未使用过类似的信贷管理系统,但是Windows友好的用户界面和本系统良好的安全性设置,可以使其内部员工在系统实施人员的指导帮助下很快掌握系统的使用方法,而无因操作失误而引起系统出错之虞。不仅如此,还可以编写出详尽的"用户操作说明书",为用户的正确操作给以图文并茂的形式加以说明。同时,在开发过程中,还可以尽量经用户以方便,考虑到用户需求的实际情况,在输入界面、查询界面等部分添加解释或提示,帮助用户尽快掌握本系统的使用方法。
4.3技术可行性
4.3.1开发的软件可行性
从目前的市场上比较流行的数据库开发管理软件来看,对于相对比较简单的中小型数据库,MicrosoftVisualFoxpro6.0它自带的数据库的结合是在实际应用中较为成功的一种解决方案。用JAVA和Oracle开发管理软件也是比较成功的一种结合。
在结合本系统来看,并没有采取上述两个方案。因为银行信贷管理系统它对安全性、数据保密性的要求非常高。如果采用了VF6+ACCESS的解决方案,它对银行以后的发展将形成一个制约;如果选择了JAVA和Oracle的解决方案,那它的数据保密性就会有所降低,而且这种中小型系统它的使用也不可能说就一定要用到Oracle这种大型数据库。
为此,选择了VF提供的自带数据库开发环境来进行本系统的开发与研制。在.集成开发环境中,它实现了平面设计与数据库之间的无缝连接。以确保数据的安全性。所以这个解决方案是可行的。为此,采用了VF做前台及界面设计,用它自带的数据库做后台的数据库支撑。
4.3.2硬件可行性
开发本系统所使用的软件对于计算机硬件有一定的要求,VF对计算机的硬件要求:由以上经济、技术、操作三方面的分析可以看出,本系统的开发时机成熟,从多种角度考虑,都是可行的。
5总体设计(GeneralDesign)
5.1系统模块的划分
根据实际业务中银行的管理体系和完成功能,并对其进行抽象处理后,根据如前所示的数据流程图,可得到如下的系统结构功能图,它大致表示出了本系统的功能模块情况,如图1所示。
图1系统功能模块图
对图1中的各个功能模块分别细分为图2至图6。
图2基本数据维护功能模块示意图
图3数据处理功能模块示意图
图4数据查询功能模块示意图
图5图形显示功能模块示意图
图6报表打印功能模块示意图
在对本系统进行模块划分的时候,有几个原则标准是必须遵循的,主要有:
(1)模块独立性最大原则
使模块具有最大的独立性,是划分模块的最重要、也是最基本的原则或标准。要达到这个标准,一是要求模块的内聚性最大,二是要求模块之间的耦合性最弱。
(2)恰当地掌握好模块的大小原则
究竟划分多大的模块最合理,很难给出绝对的标准。通常认为,一个模块的程序最好能写在一张纸上,程序行数在50~100行的范围内比较合理。
(3)尽可能把与硬件相关的部分集中在一起放在一个或几个模块内的原则
尽可能把可能变动的部分集中在一起,以便在确有变动时候能方便地处理,减少影响范围。
(4)尽可能消除重复的工作,建立公用模块,以减少冗余的原则
这对程序的编写、高度乃至维护都是十分有益的。
(5)保持合理的模块扇入数据和扇出数原则
一个模块直接控制的下属模块的个数,称为该模块的扇出数/跨度;一个模块可能被多个模块所调用,例如公用模块,其上级模块个数称为该模块的扇入数。
通过对系统进行结构化分析和设计,可将系统模块化,其总体目标是以较少的代价获得高质量的产品。例如本系统中所应用的查询模块,便可以设计成一个通用的模块,从而比较充分地体现出模块化设计的优点。
通过本系统的设分析设计,体会到,系统的模块化设计(按自顶向下、逐步求精的方法把系统逐层分解成各级模块)有如下优点:
(1)由于将一个复杂的系统划分成了若干个单一功能、相对独立的模块,从而把原来的复杂问题简化了,使复杂的多方面需求逐个得到满足。
(2)可以独立到进行模块的编码和测试,能够灵活方便地对这些工作进行组织和安排。一个程序员可以完成若干个模块,也可以把各模块分配给多个程序员去完成,平行地展开工作,以缩短系统开发周期。
(3)通过模块的划分,把每个模块要解决的问题局限在有限的范围之内,处理一个模块的问题时不必考虑模块边界以外的问题,减少了出错的机会。即使出现了错误,在局部范围内也容易解决。
(4)模块中一部分程序的修改,完全不影响模块以外的程序,极大地减少了修改产生的副作用或连锁反映的可能。程序员个人的差错所造成的影响范围一般只限于模块之内,不会影响到全局。
(5)可对关键模块
上一篇:
VFP成绩计算(论文和程序)
下一篇:
ASP小区停车管理系统(Access)(含录像)