BANKING AUTOMATION SYSTEM

(MCS-044)
Submitted to

BANKING AUTOMATION SYSTEM
(MCS-044)
FOR THE DEGREE OF

by
Ravi kumar
Director, GSE SOFT SOLUTIONS, GSE SOFT
Under Guidance of
Mr. SURENDR SHRM
1
S!HOOL OF !OM"UTER ND INFORMTION S!IEN!E
IGNOU, MIDN GRHI, NE# DELHI$%%&&'(
Note )( All et!ie" o# t$e %!o#o!m& o# "u''e"tio" "$ould be #illed i (it$ &%%!o%!i&te
&d )om%lete i#o!m&tio*I)om%lete %!o#o!m& o# "u''e"tio" i &y !e"%e)t (ill be
"umm&!ily !e+e)ted)*
,* Title o# t$e %!o+e)t- .BANKING AUTOMATION SYSTEM/
0* N&me &d Add!e"" o# t$e )ou"elo!-
4* Edu)&tio&l 1u&li#i)&tio o# t$e )ou)ello!-

2* 3o!4i'5Te&)$i' e6%e!ie)e o# t$e )ou"elle!-

7* So#t(&!e u"ed i t$e %!o+e)t-- 8&9& : o!&)le

Si*nature of t+e ,tudent,) $ Si*nature of t+e coun,e-or
Date) Date)

,
;E<=O<MA =O< SUGGESTIONS O= MCS-044 ;<O8ECT ;<O;OSA>
0
!ERTIFI!TE OF UTHENTI!TED #OR.
Thís ís to certífy that the pro|ect report entítíed “BANKING
AUTOMATION SYSTEM” Submítted to Indira Gandhi National
Open University ín partíaí fuífíííment of the requírement for the
award of the degree of MASTER OF COMUTER A!ICATION
"MCA#$ ís an orígínaí work carríed out by group of foííowíng
students.
1.Umesh Kr Mehta 093723255
2.Md. Akhtar Ansarí 093722285
3.Raví Kumar 093723248
4.Arvínd Kumar 084249644
The matter embodíed ín thís pro|ect ís a genuíne work done by the
student and has not been submítted whether to thís Uníversíty or
to any other Uníversíty/Instítute for the fuífíííment of the
requírement of any course of study.
Sígnature of the Students: Sígnature of the Guíde:
Date: --------------- Date: -----------------
Name & address of Name, Desígnatíon and the
Students. Address of the Counseííor:

BIODATA OF THE GUIDE
Name : Surendra Sharma
4
Designation : Sr. Software Developer
Sex : Male
Date of Birth : 05-Jan-1985
Mailing address : surendraj2eedev!ma"l.#om
Contat No : 0995$080091
Ed!tional "!alifiation#
 % have #ompleted M&' from %()*+ "n 2008.
 % have done ,&' from %()*+ "n 200-.
 .' /0(D&'12 and .* /D&'12 3evel from D*4'&& So#"et5.
 %ntermed"ate from ,%4& "n 2002.
 10th from ,S4,6 "n 2000.
$or%ing ex&eriene#
 &urrentl5 wor7"n! w"th we8v"rtue software pvt ltd as Sr. Software
Developer
 9ands on 4:per"en#e of '( )ears as a Software 4n!"neer6 respons"8le
for Software development6 +n"t ;est"n!6 Data8ase Des"!n"n!6 at SA*S
Softa+ate Tehnologies ,+t- .td6 )ew Delh".
Date# Signat!re#



ABSTRACT
2
The maín ob|ectíve of the pro|ect entítíed "BANKER" ís to
facííítate Reííabíe, Fast and Easy transactíon and províde
ín formatíon on síngíe keystroke. An attempt ís made to
computerízed the Bankíng System, whích wouíd reduce
the manuaí workíoad on empíoyees of bank. Thís ín turn
wouíd íncrease the effícíency of the Bank. The pro|ect
contaíns foííowíng moduíes:-
1. A%thenti&ation' ( Authentícatíon ís an
ímportant procedure, whích must be performed before
any users have an access to the system. Oníy vaííd users
are aííowed to access the system wíth dífferent access
modes. There are three types of users nameíy,
(í) User
(íí) Manager
(ííí) Admínístrator
And there are two access modes Cíerícaí,
Manageríaí Managers and Admínístrator can aíso work on
the system ín cíerícaí mode to perform common cíerícaí
tasks but User cannot work ín the manageríaí.
2. A&&o%nt Creation: - The Bank provídes
facíííty to open new account for theír new customers. The
accounts can be of foííowíng nature:-
(í) Current Account (CA)
(íí) Savíng Account (SB)
(ííí) Fíxed Deposít (FD)
3. Transa&tions' - There are maíníy three types
of Transactíon.
í) Receípts
íí) Payments
ííí) Transfers
Aíí the above types are transactíons are
appíícabíe to oníy Savíng AC, Current AC and Cash Credít
7
ACs. Further no any transactíons wííí be performed on
dormant accounts.
4. A%thori)ation' ( Authorízatíon ís the most
ímportant moduíe of the pro|ect. Aíí the transactíons
must be authorízed ín order to update varíous tabíes. No
payments wííí be possíbíe on unauthorízed accounts.
However receípts wííí be avaííabíe to those accounts
aíso. Authorízatíon ís performed ín oníy 'Manageríaí'
mode.
5. ** and Che+%e Mod%le' - Demand Draft
and Cheque are ímportant ínstruments, whích wííí be
managed by the pro|ect very effícíentíy. Demand Drafts
wííí be íssued to both account hoíders and non-account
hoíders.
Cheque can be íssued to eíther at account
openíng tíme or íater at any tíme. There ís a restríctíon of
Rs. 1000/- shouíd be maíntaín as mínímum baíance to
account havíng cheque facíííty.
6. Tools:- There are varíous tooís avaííabíe for
varíous admínístratíve tasks such as User-ID
maíntenance, ínterest caícuíatíon etc. User-ID
maíntenance íncíudes user-ID creatíon, user-ID
modífícatíon and user-ID deíetíon. Interest caícuíatíon ís
descríbed beíow.
7. Interest Cal&%lation' ( Dífferent ínterest
rates wííí be offered by bank on dífferent account types
whích ís revíewed by RBI (Reserve Bank of Indía) over
períod to períod. No ínterest wííí be paíd to Current
account but some surcharge ís charged to those
accounts.
?
8. Reports' ( Reports are essentíaí to have a
víew retríevíng varíous detaíís reíated to transactíon
made to accounts and for sendíng detaíís to head-offíce.
Varíous reports íncíudes Account Statement, Account
íístíng for any partícuíar account type, ííst of aíí
transactíons made between a gíven períod of tíme etc.
Above we províde oníy bríef ínformatíon about
moduíes. The workíngs of each moduíe are díscussed
íater on ín detaíí.
@
!.NO#LEDGMENTS
I have tríed to achíeve aíí requírements of a
common Retaí shop. I am responsíbíe for aíí omíssíons
and for any errors found ín thís pro|ect.
I as the Student of IGNOU, acknowíedge the nobíe
and worthy guídance of our teachers of the Píoneer
Instítute, Deíhí-1 Who gave theír support ín deveíopíng
thís pro|ect successfuííy.
I express my profound gratítude to My parents
provídíng me thís goíden opportuníty of beíng student of
thís department and for provídíng aíí necessary facííítíes
requíred duríng the pro|ect.
I have unparaííeí faíth to work under the Guídance
of Mr. Surendra Sharma for hís ínvaíuabíe guídance,
suggestíons contínuous encouragement through out the
pro|ect.
A specíaí thanks to the Dírector of IGNOU and
Regíonaí Dírector of Regíonaí Centre Deíhí-1 and aíí other
those are dírect or índírect support support duríng ín my
course of thís department; gíven me a goíden chance of
my course for fuífííí the pro|ect work.
A
At íast but not íeast, I am thankfuí to aíí my fríends
who had been heípfuí throughout the períod of my
pro|ect work.

TAB!E OF CONTENTS
,' Certi-i&ates
1.1: Certífícate of Orígínaííty
.' A&/no0led1e2ent
3' re-a&e
4' Introd%&tion
5' O67e&tives
8' Syste2 St%dy
6.1: Anaíysís
6.2: Exístíng System wíth Límítatíons
6.3: Proposed System wíth Ob|ectíves
6.4: Desígn
6.5: Impíementatíon
6.6: Debuggíng
6.7: Depíoyment & System Testíng
9' Feasi6ility
7.1: Economíc Feasíbíííty
10
7.2: Technícaí Feasíbíííty
7.3: Operatíon Feasíbíííty
:' ;ard0are < So-t0are Re+%ire2ents
=' >ava
,?' Tools
,,' Ora&le
,.' *ata Flo0 *ia1ra2s "*F*s#
,3' So-t0are En1ineerin1 aradi12
,4' *ata 6ase Ta6les
,5' @alidation Che&/s
,8' Syste2 Se&%rity
,9' Gantt &hart
,:' F%t%re S&ope
,=' Con&l%sion
.?' AppendiA
.,' Synopsis
11
REFACE
Today's commercíaí woríd ís buíít around money.
Every commercíaí transactíon needs to be supported
usíng a fínancíaí transactíon. Tradítíonaí procedure for
maíntaíníng records usíng Ledgers, Day book etc. ís very
tíme consumíng and may íead to error íf not perfomed
carefuííy.
Keepíng thís ín mínd I have made an effort
automate the bankíng operatíon by deveíopíng a smaíí
package "BANKER”. "BANKER" (A Pro|ect to
Automate Bankíng System) ís deveíoped usíng |ava and
Oracíe 8 |.S.P. used as front-end for the foííowíng
reasons:
* |AVA ís a fíexíbíe
* Structured programmíng íanguage.
* |AVA ís wídeíy avaííabíe.
* |SP provídes user fríendíy ínterface through forms.
1,
The pro|ect has used ORACLE 8.0 as back-end for
database management. The ORACLE 8.0 provídes more
handy and safe database management tooís. ORACLE
8.0 has tooís ííke DTS Wízards, Ouery anaíyzer,
enterpríse manager etc. Whích makes ít easíer to handíe
the database?
10
14
INTRO*UCTION
About The Pro|ect:
Banks facííítate fínancíaí transactíons and hence are an
íntegraí part of the commercíaí woríd. Bankíng servíces
has grown by íeaps and bounds. Today a bank that offers
íts customers the wídest spread of servíces mapped to
theír busíness (and personaí) needs ís the bank that ís
successfuí.
The Pro|ect entítíe "BANKER" (A Pro|ect to
Automate Bankíng System) ís an effort towards
desígníng an ín formatíon system that wouíd províde
most of the requírements of Bank.
The pro|ect has been desígned usíng the
ORACLE 8.0 Database Management System. ORACLE 8.0
ís an RDBMS; It uses the reíatíonaí data modeí. In thís
appíícatíon we have used the concept of the reíatíons to
stored and manípuíate the data of the Informatíon
System. Physícaííy there reíatíons have been stored ín
form of the tabíes. Correspondíng to each entítíe and the
reíatíonshíps we have a database tabíe. These tabíes
contaín the coíumns as the fíeíds of tabíe. Further, each
coíumn have some attríbutes such as data types, síze
defauít vaíue etc. whích defínes and vaíídate the data.
In the Desígn of "BANKER" we have expíoíted
the rích facííítíes (tooís) of the |ava. |ava ís Sun Mícro
system íanguage for Rapíd Appíícatíon Deveíopment
(RAD). It ís easy to use, effícíent and fíexíbíe. I prefer thís
íanguage because on can buííd a Wíndows program
quícker and wíth íess effort wíth |ava than wíth any other
programmíng íanguage. It's ís naturaí íanguage for
buíídíng database appíícatíons, owíng to the íeveí and
sophístícatíon of the tooís íncíuded wíth the íanguage.
We have use |SP for desígníng the date entry
screens correspondíng to each tabíe. These forms have
been further customízed usíng the tooís button, optíon
button, data gríd and functíons to províde the
functíonaííty to make them as user fríendíy and easy to
12
use as possíbíe. We are provídíng the data retríevaí and
the data manípuíatíon task a matter by cííckíng the
desíre buttons and the resuít of the task mentíoned on
button wouíd be díspíayed on the screen.
We desígned reports that wouíd request the users
parameter and províde the resuít based on the query
defíne the data modeí of the report and the parameter
passed by the users.
After the desígníng the database tabíes for defíníng
and manípuíatíng the data, the forms for the data entry
and manípuíatíon and the reports for query processíng,
the next ímportant step ís of the íntegratíng these
ob|ects ínto the fínaí up BANKER.
These ob|ectíves have been achíeved usíng the
form. Varíous forms have been used to desígn the screen
and these screens have been used aíong wíth the coded
buttons to íntegrate ob|ects.
17
1?
O67e&tive
The maín ob|ectíve of the pro|ect entítíed "BANKER" ís to
facííítate Reííabíe, Fast and Easy transactíon and províde
ín formatíon on síngíe keystroke. An attempt ís made to
computerízed the Bankíng System, whích wouíd reduce
the manuaí workíoad on empíoyees of bank. Thís ín turn
wouíd íncrease the effícíency of the Bank. The pro|ect
contaíns foííowíng moduíes:-
1. A%thenti&ation' ( Authentícatíon ís an
ímportant procedure, whích must be performed before
any users have an access to the system. Oníy vaííd users
are aííowed to access the system wíth dífferent access
modes. There are three types of users nameíy,
(í) User
(íí) Manager
(ííí) Admínístrator
And there are two access modes Cíerícaí,
Manageríaí Managers and Admínístrator can aíso work on
the system ín cíerícaí mode to perform common cíerícaí
tasks but User cannot work ín the manageríaí.
1@
2. A&&o%nt Creation: - The Bank provídes
facíííty to open new account for theír new customers. The
accounts can be of foííowíng nature:-
(í) Current Account (CA)
(íí) Savíng Account (SB)
(ííí) Fíxed Deposít (FD)
3. Transa&tions' - There are maíníy three types
of
transactíon.
í) Receípts
íí) Payments
ííí) Transfers
Aíí the above types are transactíons are
appíícabíe to oníy Savíng AC, Current AC and Cash Credít
ACs. Further no any transactíons wííí be performed on
Dormant accounts.
4. A%thori)ation' ( Authorízatíon ís the most
ímportant moduíe of the pro|ect. Aíí the transactíons
must be authoríze ín order to update varíous tabíes. No
payments wííí be possíbíe on unauthorízed accounts.
However receípts wííí be avaííabíe to those accounts
aíso. Authorízatíon ís performed ín oníy 'Manageríaí'
mode.
5. ** and Che+%e Mod%le' - Demand Draft
and Cheque are ímportant ínstruments, whích wííí be
managed by the pro|ect very effícíentíy. Demand Drafts
wííí be íssued to both account hoíders and non-account
hoíders.
Cheque can be íssued to eíther at account
openíng tíme or íater at any tíme. There ís a restríctíon of
Rs. 1000/- shouíd be maíntaín as mínímum baíance to
account havíng cheque facíííty.
1A
6. Tools:- There are varíous tooís avaííabíe for
varíous admínístratíve tasks such as User-ID
maíntenance, ínterest caícuíatíon etc. User-ID
maíntenance íncíudes user-ID creatíon, user-ID
modífícatíon and user-ID deíetíon. Interest caícuíatíon ís
descríbed beíow.
7. Interest Cal&%lation' ( Dífferent ínterest
rates wííí be offered by bank on dífferent account types
whích ís revíewed by RBI (Reserve Bank of Indía) over
períod to períod. No ínterest wííí be paíd to Current
account but some surcharge ís charged to those
accounts.
8. Reports' ( Reports are essentíaí to have a
víew retríevíng varíous detaíís reíated to transactíon
made to accounts and for sendíng detaíís to head-offíce.
Varíous reports íncíudes Account Statement, Account
íístíng for any partícuíar account type, ííst of aíí
transactíons made between a gíven períod of tíme etc.
Above we províde oníy bríef ínformatíon about
moduíes. The workíng of each moduíe are díscussed
íater on ín detaíí.
,0
,1
SYSTEM STU*Y
Analysis'
I had to undertake a íogícaí and profícíent
anaíysís to scrutíníze the feasíbíííty of the pro|ect. The
demands and system needs were carefuííy anaíyzed. I
had studíed severaí Banks ín Gorakhpur. I had aíso
studíed the report of SBI . The types of consíderatíons
that were taken were economícaí, technícaí and resource
wíse. The resources ííke the users who wííí operate the
computer, were thoroughíy studíed to ensure that they
couíd abíy ensure totaí compatíbíííty wíth the ob|ectíves
of the pro|ect. An effort was made to make the bankíng
system effícíent ín aíí type of day to day transactíons.
EAistin1 syste2 0ith li2itations'
The exístíng system has a manuaí work system.
The manuaí work system takes more tíme and then ít
may aíso be possíbíe that the system has errors. The
manuaí systems work ís very síow, has emotíon,
tíredness and some other probíems. The exístíng
"manuaí bankíng system" has many íímítatíons. It takes
a reasonabíe tíme to search a partícuíar account ín
Account Ledgers and takes reasonabíe tíme ín checkíng,
updatíng and authorízíng varíous transactíons. Ma|or
probíem faced duríng ínterest caícuíatíon because
ínterest wííí be gíven on the mínímum baíance between
10th and íast of the every month. Interest
Caícuíatíon ís very tíme consumíng and hard workíng
operatíon when ít ís done manuaííy. Aíso reports
prepared by cíerks are not very appropríate due theír
poor wrítíng and ímproper format used.
roposed Syste2 0ith O67e&tives'

,,
The approach adopted ín “BANKER” system ís very
símpíe, íucíd, comprehensíve, and user fríendíy. The
proposed system can effícíentíy handíe aíí the tasks as
keepíng the record of the Bank and ít´s through dífferent
sídes. Thís task can be effícíentíy handíed at the síngíe
ínstructíon of the user wíthout takíng more tíme, whích
on the other hand become very hazardous when done
manuaííy.
The Menu´s have been so easííy defíned one wíthín
the other so that there ís no díffícuíty ín understandíng ít.
It ís very sophístícated software and can be used by any
Bankíng organízatíon to store theír ínformatíon ín an
effícíent manner and we hope that ít wííí be of great heíp
to them. Thís Pro|ect has been desígned to reduce the
manuaí work. Interest caícuíatíon and report generatíon
moduíes are desígned carefuííy to refíect the actuaí
system behavíor.
* ESIGN '
T$e %!ototy%e (&" ite!&ti9ely e$&)ed* E&)$ e(
e$&)ed %!ototy%e (&" "ou'$t to be mo!e %o(e!#ul &d
!obu"t* T$e %!o)e"" o# )o"t&t e$&)emet (&" )&!!ied out
util t$e ;!o+e)t-'uide &d "ome ot$e! )o)e!i' %e!"o"
(e!e #ully "&ti"#ied (it$ t$e Sy"tem-de"i' i $&d* A#te! t$e
&&ly"i" o# t$e %!o+e)tB t$e mo"t )!e&ti9e %$&"e o# t$e ;!o+e)t
(&" )omme)edB t$&t o# t$e Ce"i'i'* T$e de"i'i' de&lt
(it$ t$e )o)e%tio o# t$e Sy"tem-de"i'" t$&t &!e to be
im%lemeted to e6e)ute t$e %!o+e)t* C&t&-=lo(-C!&(i'" (&"
doDt to de#ie t$e &))u!&te #lo( o# CATA* A#te! 9&!iou"
!oud" o# di")u""io &d &!'umet" t$e de"i' (&" #i&liEed*
IM!EMENTATION'
The next stage that of ímpíementatíon deaít wíth
the synergízíng of the System desígn and appíícatíon of
the varíous technícaí-tooís. The fínaí prototype that was
desígned was coded ín the tooís, most conveníent,
powerfuí and fíexíbíe for the ímpíementatíon of the
varíous moduíes. Varíous moduíes were coded very
,0
carefuííy oníy after consíderíng every condítíons and
cases that may affect the functíonaííty of the
moduíe.Expert´s suggestíons are aíso consídered aíong
wíth my own ídeas and experíence. Duríng
Impíementatíon, aíí the smaíí queríes and doubts were
referred to the Pro|ect Guíde.
*EBUGGING'
After successfuííy codíng the índívíduaí moduíes, aíí
the moduíes were crosschecked. The debuggíng was
performed to ensure that no software bugs exíted.
Debuggíng ís recursíveíy performed untíí the newíy
desígned system resembíes the proposed system. It was
ensure that aíí the moduíes were íogícaííy and
syntactícaííy correctíy coded. Duríng Debuggíng, The
entíre moduíe combíned together by systematícaííy
checkíng and correctíng the moduíes one at a tíme. Aíí
the troubíes hootíng was deaít deftíy by the experts and
pro|ect guíde to ensure robustness of the índívíduaí
moduíes.
*E!OYMENT < SYSTEM TESTING'
The phase of Depíoyment and system Testíng
ínvoíved the task of the íínkíng of aíí the índívíduaí
moduíes to estabíísh the actuaí and compíete pro|ect.
The system testíng ínvoíved Stríng Testíng (to check
compatíbíííty of the moduíes wíth one another to
estabíísh íntegratíon), Overaíí Testíng (vaíídatíon of the
System agaínst faííures) and Ensurance to the orígínaí
Pro|ect guídeíínes. Any díscrepancy found was
ímmedíateíy removed and aíí the testíng were
undertaken once more to estabíísh System- Credíbíííty.
The Pro|ect-Guíde was demonstrated the Pro|ect and aíí
hís chaííengíng enquíríes were fuííy satísfíed.
,4
,2
FEASIBI!ITY
Many feasíbíííty studíes are dísíííusíoníng for both
users and anaíysts. Fírst, The study often presupposes
that when the feasíbíííty document ís beíng prepared, the
anaíyst ís ín a posítíon to Evaíuate soíutíons. Second
most studíes tend to overíook the confusíon ínherent ín
system deveíopment. The constraínts and the assumed
attítudes. If the feasíbíííty study ís to serve as a decísíon
document, It must Answer three key questíon-
1. Is there a new and better way to do the |ob that wííí
benefít the user?
2. What are the costs and savíngs of the aíternatíves?
,7
3. What ís recommended?
The most successfuí system pro|ects are not
necessarííy the bíggest or most vísíbíe ín a busíness
but rather those that truíy meets user Expectatíons.
More pro|ects faíí because of ínfíated expectatíon
than for any other reason.
ECONOMICA! FEASIBI!ITY'
Economícaí Anaíysís ís the most frequentíy method
for evaíuatíng the effectíveness of a system. More
Commoníy Known as Cost/Benefít anaíysís. Cost/Benefít
anaíysís ís the procedure to determíne the benefíts and
savíng that are expected from a candídate system and
compare them wíth costs. If benefíts outweígh costs,
then the decísíon ís made to desígn and ímpíement the
system. Otherwíse, further |ustífícatíon or aíternatíon ín
the proposed system wííí have to be made íf ít ís to have
to chance of beíng approved. The Computerízed system
ís economícaííy very feasíbíe.
In thís pro|ect the economy síde ís not affected
because any bankíng organízatíons have to pay íess
amount and can use thís software. That organízatíon has
to purchase a smaíí confíguratíon computer and
ínstaííatíon of thís software ís very easy.
TEC;NICA! FEASIBI!ITY '
Technícaí Feasíbíííty centers around the exístíng
computer system (Hardware, Software etc.) and to what
extent ít can support the proposed addítíon. For
exampíe- íf the current computer ís operatíng at 80
percent capacítíes and arbítrary ceíííng than runníng
another appíícatíon hardware. Thís ínvoíves fínancíaí
consíderatíon to accommodate technícaí enhancement.
Once you gave ínstaííed a computer system ínstead of
manuaí system aíí thíngs wííí go on ín smooth and
effícíent manner.
,?
OERATION FEASIBI!ITY '
The computer system ís very durabíe as compared
to manuaí system. The computer system has guaranteed
to do works wíth same speed and accuracy even at
íonger tíme whííe a man can do ít so better. Any users
who know very ííttíe about the computer can aíso use
thís software very easííy. So the Computerízed System ís
tíme feasíbíe than the manuaí system.
,@
;AR*BARE < SOFTBARE RECUIREMENTS
,A
HARDWARE REOUIREMENT: (Recommended)
1. Pentíum III (566 MHz)
2. RAM 64 MB
3. H.D.D. 10 GB
SOFTWARE REOUIREMENTS :
Language :- |AVA |SP
Backend :- ORACLE-8.0
Píatform :- Wíndows 98 (SE)
MINIMUM HARDWARE REOUIREMENT :
1. Pentíum I (133 MHz)
2. RAM 32 MB
3. H.D.D. 5 GB
>A@A
00
>ava ís a technoíogy that makes ít easy to buííd
dístríbuted appíícatíons, whích are programs executed
by muítípíe computers across a networks. |ava ís
desígned to meet the chaííenges of appíícatíon
deveíopment ín the context of heterogeneous,
network-wíde dístríbuted envíronment. Paramount
among these chaííenges ís secure deíívery of
appíícatíons that consume the mínímum of system
resources, can run on any hardware and software
píatform, and can be extended dynamícaííy.
S%n had deveíoped a new íanguage caííed Oak. Oak
preserved the famíííar syntax of C++, but omítted the
potentíaííy dangerous features ííke expíícít resources
references, and poínter aríthmetíc and operator
overíoadíng. In 1994 Sun compíeted work on a product
known as Web Runner. Web Runner was íater
renamed Hot |ava. Fínaííy, ín 1995, Oak was renamed
|ava.
>ava ís a símpíe, Ob|ect-Oríented,
Dístríbuted,Interpreted, Robust, Secure, Archítecturaí,
Portabíe,Hígh-performance, Muítíthreaded, Dynamíc,
Buzzword-compíaínt, Generaí-purpose programmíng
for the Internet ín the form of píatform-índependent
|ava appíets.The most ííkeíy píace to fínd the |ava ís
on the Woríd Wíde Web. |ava has begun to address
the protocoí probíem by usíng |ava appíets ís a |ava
program, whích appears embedded ín a Web
document, |ust as graphícs wouíd be. |ava´s strength
deríves form íts uníque archítecture. |ava uses a
compííer to convert human-readabíe source code ínto
executabíe programs.
01
Feat%res o- >ava'

|ava ís Símpíe, Ob|ect-Oríented, Dístríbuted,
Interpreted, Robust, Secure, Archítecturaí-Neutraí,
Language. There are severaí ma|or characterístícs that
make |ava such a powerfuí deveíopment tooí:
Si2ple
>ava ís símpíe and eíegant íanguage whose
syntax ís remíníscent of the ínfant terríbíe of modern
computer scíence ííke C++. |ava was made símpíer
prímarííy to gíve programmers fewer ways of makíng
místakes. |ava omíts many rareíy used, pooríy
understood, confusíng feature of C++ that ín our
experíence bríng more bríef overíoadíng, muítípíe
ínherítance, and extensíve automatíc coercíon. |ava
add auto garbage coííectíon.
O67e&t(Oriented
Unííke C++ |ava requíred that everythíng
be an ob|ect. Gíobaí data and standaíone functíons are
not aííowed. Every cíass ín |ava ís dírectíy or índírectíy
descendent from the grandfather of aíí cíasses ín |ava,
the Ob|ect cíass. |ava ís an Ob|ect-Oríented íanguage ;
that ís, ít has facííítíes for Ob|ect-Oríented
Programmíng íncorporated ínto the íanguage.
*istri6%ted and *yna2i&

|ava has extensíve ííbrary of routínes for copyíng
easííy wíth TCP/IP protocoís ííke HTTP and FTP. |ava
appíícatíon can open and access ob|ect across the net
vía URLs wíth the same ease that programmers are
used to when accessíng a íocaí fííe system. |ava has
ínherent extensíve TCP/IP and HTTP capabííítíes.
>ava is Ro6%st
Poínter to poínter manípuíatíon can be used
by knowíedge based programmers to tremendous
advantage. |ava put a íot of emphasís on earíy
0,
checkíng for possíbíe probíem, íater dynamíc (runtíme)
checkíng and eíímínatíng sítuatíon that are error
prone.
Se&%rity
Securíty ís probabíy the number one probíem facíng
Internet deveíopers. |ava´s securíty modeí has three
prímary components: the Cíass Loader, Byte-code
Verífíer, and the Securíty Manager. When the cíass
íoader retríeves cíasses from the network, ít keeps
cíasses from dífferent servers separate from both each
other and íocaí cíasses. The Securíty manager
ímpíements a securíty poíícy for the VM. |ava ís cííent
síde technoíogy. |ava ís íntended to be used ín
networkíng/dístríbuted envíronments. After the
transmíssíon to |ava byte-code phase, |ava programs
are ín effect, downíoad from the host machíne usíng
conventíonaí Web Server. |ava provídes dífferent íeveí
of securíty checks.
Ar&hite&t%ral Ne%tral
|ava byte-codes are índependent of any underíyíng
archítecturaí. The |ava compííer generate byte-code
ínstructíon whích have nothíng to do wíth a computer
archítecture.
;i1h er-or2an&e
The byte-codes can be transíated on the fíy(at
runtíme) ín to machíne code for the partícuíar CPU the
appíícatíon ís runníng on. The performance of byte-
code converted to machíne code ís aímost
índístínguíshabíe from natíve C or C++.
M%ltithreaded
A muítíthreaded appíícatíon can have severaí threads
of executíon runníng índependentíy and
símuítaneousíy. Muítíthreadíng ís a way of buíídíng
00
appíícatíon wíth muítípíe threads.
|ava has a sophístícated set of
synchronízatíon prímítíves that are based on the
wídeíy used moníter and condítíon varíabíe paradígm.
Benefíts of muítíthreadíng are better ínteractíve
responsíveness and reaí tíme behavíor. Muítíthreadíng
ís commoníy used to perform the foííowíng functíons:
Maíntaín user ínterface responsíveness
Muítítaskíng
Muítí-user appíícatíon
Muítíprocessíng

orta6le
The |ava programs are híghíy portabíe. Unííke C and
C++, there are no ímpíementatíon dependent aspects
of the specífícatíon. The ííbraríes that are a part of the
system defíne portabíe ínterfaces.
Interpretative
The |ava ínterpreter can execute |ava byte codes
dírectíy on any machíne to whích the ínterpreter has
been ported. |ava íínks are more íncrementaí and
ííghtweíght process, the deveíopment process can be
much more rapíd and expíoratory.
@ersatilityD FleAi6ility
>ava understands ínterfaces cíasses, whích have run
tíme representatíon. |ava ís more dynamíc íanguage
than C/C++(e.g. One ma|or probíem wíth usíng C++
ín a productíon envíronments ís a síde effect of the
way that code ís aíways ímpíemented).
Open Standards

04
|ava VMS are avaííabíe for more than a dozen
dífferent hardware-operatíng system combínatíons.
The most excítíng aspect of |ava´s cross-píatform
capabíííty ís that |ava cíass fííes do not need to be
compííed for each píatform ín advance.
Memory management and Garbage coííectíon
Memory management ís the bane of aíí C and C+
+ programs. If the memory aííocatíons do not
perfectíy match memory be aííocatíons, the program
wííí eíther crash ímmedíateíy, or consume system
resources untíí exhausted. Temporary memory ís
automatícaííy recíaímed after ít ís no íonger
referenced by any actíve part of the program. Memory
management reínforces the securíty of the VM.

02
Tools and Environ2ent %sed
Introduction to tool concept:
 Tool'(
In a stríct sense, tooís are those thíngs whích are
necessary to create some resuít.
“A Carpenter 0o%ld %se a ha22er and sa0 to
&reate -%rnit%re$ a pro1ra22er 0o%ld %se a
&o2piler and a pro1ra2 editor to &reate so-t0are”.
 *e-inition "Tool#'
07
A tooí ís any devíce that, when used properíy,
ímproves the performance of a task, such as the
deveíopment of computer ínformatíon systems.
>S
A |SP page ís a text-based document that descríbes
how to process a request to create a response. |SP ís a
|ava-based technoíogy that símpíífíes the process of
deveíopíng dynamíc web sítes. Wíth |SP, web
desígners and deveíopers can quíckíy íncorporate
dynamíc eíements ínto web pages usíng embedded
|ava and símpíe markup tags. These tags províde the
HTML desígner wíth a way to access data and busíness
íogíc stored ínsíde |ava ob|ects.
|ava Server Pages are text fííes wíth the
extensíon .|sp, whích take the píace of tradítíonaí
HTML pages. |SP fííes contaín tradítíonaí HTML aíong
wíth embedded code that aííows the deveíoper to
access data from the |ava code runníng on the server.

Advanta1es o- >S
|SP technoíogy ís the |AVA píatform technoíogy for
buíídíng appíícatíons contaíníng dynamíc web content
such as HTML, DHTML, XHTML, and XML . The |ava
Server Pages technoíogy enabíes the authoríng of web
pages that create dynamíc content easííy but wíth
maxímum power and fíexíbíííty.
The >ava Server a1es te&hnolo1y o--ers a number
of advantages:
Brite On&e$ R%n Any0here properties

The |ava Server Pages technoíogy ís píatform
índependent, both ín íts dynamíc Web pages, íts Web
servers, and íts underíyíng server components. We can
author |SP pages on any píatform, run them on any Web
server or Web enabíed appíícatíon server, and access
0?
them from any web browser. We can aíso buííd the
server components on any píatform and run them on any
server.
S%pport -or s&riptin1 and a&tions
The |ava Server Pages technoíogy supports scríptíng
eíements as weíí as actíons. Actíons permít the
encapsuíatíon of usefuí functíonaííty ín a conveníent from
that can aíso be manípuíated by tooís. Scrípts províde a
mechanísm to gíue together thís functíonaííty ín a per-
page manner.
er-or2an&e
|SP ís typícaííy ímpíemented vía servíets. When a
web server receíves a request for a |SP page, ít
forwards ít to a specíaí process dedícated to handííng
servíet executíon. Thís process ís referred to as the
servíet contaíner. In the context of |SP, ít ís referred to
as the |SP contaíner. The servíet contaíner ís normaííy
a separate process from the HTTP server, prímarííy
due to the fact that the servíet contaíner ís a |ava
process, runníng ín a |VM, whííe most HTTP servers are
wrítten ín other íanguages. The key factor here ís that,
for servíet contaíners assocíated wíth conventíonaí
HTTP servers, there ís oníy one addítíonaí process for
the servíet contaíner, whích handíes aíí servíet-reíated
requests, íncíudíng |SP. Thís process ís ínítíated when
the HTTP server starts up, and contínues to run untíí
the HTTP server ís shut down.
There are three categoríes of |SP tags:
E *ire&tives
These affect the overaíí structure of the servíet that
resuíts from transíatíon, but produce no output
themseíves.
E S&riptin1 Ele2ents
These íet us ínsert |ava code ínto the |SP page (and
hence ínto the resuítíng servíet).
E A&tions
These are specíaí tags avaííabíe to affect the
0@
runtíme behavíor of the |SP page. |SP suppííes some
standard actions, such as <|sp:useBean>, These
custom actíons are usuaííy referred to as tag
extensíons or custom tags.
>S *ire&tives
syntaA is'

<%@ dírectívename attríbute=”vaíue”
attríbute=”vaíue”%>

There are three 2ain dire&tives that &an 6e
%sed in a >S'
* the page dire&tive
E the include dire&tive
E the taglib dire&tive

√SyntaA o- the page directive
is:-
<%@ page ATTRIBUTES %>
√SyntaA o- the include directive is:-
<%@ íncíude fííe=”Fííename”%>
√SyntaA o- the taglib directive is:-

FGH t&'lib u!iI/t&'>ib!&!yU<I/ %!e#i6I/t&';!e#i6/ GJ
/0 S!RI"T
Scríptíng íanguages are programmíng íanguages that
are ínterpreted by programs rather than by a
computer processor. Therefore, you do not need to
transíate scríptíng íanguages to machíne code for
ínterpretatíon by the browser. Scríptíng íanguages are
used to íncorporate user ínteractívíty ín web
documents.
Java Script was deveíoped, by Netscape
Communícatíons Corporatíon. |avaScrípt code Syntax
0A
ís símííar to that of Pascaí code and C íanguage.
|avaScrípt can be used for wrítíng scrípts that can be
ínterpreted by the server and the cííent computers.
|avaScrípt ís supported by Internet Expíorer versíon
4.0 and íater versíons and Netscape Navígator versíon
4.0 and íater versíons.
|avaScrípt was ínítíaííy caííed ííve Scrípt by íts
deveíoper, Netscape Communícatíons Corporatíon.
The íanguage was íater renamed |avaScrípt, aíthough
|avaScrípt ís dístínguíshabíy dífferent from |ava.
|avaScrípt was deveíoped to be embedded wíth
ín the HTML code to enhance Cííent-síde ínteractívíty
ín the web documents.
Feat%res o- >avaS&ript
# |avaScrípt ís an ob|ect-based Scríptíng íanguage.
# |avaScrípt works índependent of the píatform.
# |avaScrípt supports, events.
40
Advanta1es o- >avaS&ript
* Supports enhanced user ínteractívíty.
* Supports Cííent-síde vaíídatíons.
• Supports browser ídentífícatíon.
• Supports píug-ín detectíon
• Supports símpíífícatíon of programs.
(F >avaS&ript aíso supports Client-side Scripting
and Server-side scripting. The cííent-síde
|avaScrípt(CS|S) ís used to manípuíate web
documents and browsers and to facííítate data
processíng on the cííent Computer.
The executíon of CS|S code ís tríggered by events on
the cííent Computer.
(F>avaS&ript aíso supports server(side S&riptin1.
The server-síde Scríptíng ís used to facííítate the
data processíng on the server and for customízíng
server-based appíícatíons. Server-Síde
|avaScrípt(SS|S) aíso provídes varíous databases and
ob|ects for web appíícatíon deveíopment.
• Syntax.
<SCRIPT LANGUAGE=” |avaScrípt”>
------------------
----------------
</SCRIPT>
41
4,
ORAC!E
Oracíe ís the most popuíar RDBMS among the IT
organízatíons due to the features offered. The current
versíon of Oracíe 8í thís ís web enabíed. More than 50% of
Web appíícatíons use Oracíe as theír Database Server.
Oracíe 8í aíso supports |ava.
Introd%&tion to Ora&le and Its Tools'
The Ora&le prod%&t is pri2arily divided into
E Ora&le Server tools
* Ora&le Client tools
Ora&leServer'
Oracíe ís a company that produces the most
wídeíy used, Muítí user RDBMS. The Oracíe Server ís
a program ínstaííed on the Server´s hard dísk dríve.
Thís program must be íoaded ín RAM so that ít can
process user requests.
This Ora&le Server prod%&t is either &alled

Ora&le Bor/1ro%p Server
or
Ora&le Enterprise Server

The functíonaííty of both these products ís ídentícaí.
However, the Oracíe Workgroup Server restrícts the
number of concurrent users who can query the
Server. Oracíe Enterpríse Server has no such
restríctíons. Eíther product must be íoaded on a muítí
user operatíng system.
40
The Ora&le Server ta/es care o- the -ollo0in1'
 Updatíng the database.
 Retríevíng ínformatíon from the database.
 Acceptíng query íanguage statements.
 Enforcíng data íntegríty specífícatíons.
 Managíng data sharíng.
Ora&le Client Side Tools'

Ora&le -or Bindo0s =5 '
SC!E!US'
The SOL *Píus tooí ís made up of two
dístínct parts. These are
E Intera&tive SC!
E !DSC!
Interactíve SOL ís desígned to create, access and
maíntaín aíí data structures ííke tabíes, índexes etc.
It can aíso be used for ínteractíve, data manípuíatíon.
Programmers can use PL/SOL to create programs for
vaíídatíon and manípuíatíon of tabíe data. PL/SOL
adds to the power of ínteractíve SOL and provídes
the user wíth aíí the facííítíes of a standard, modern
day(4GL) programmíng envíronment. Vía PL/SOL the
user can not oníy manípuíate data but aíso can use
proceduraí techníques such as wrítíng íoops or
branchíng to another bíock of code.
44
42
? !evel "ConteAt !evel# *F*
Transactíon Master
Display Message
Valid User's Interacts Ban/er
GeneratesReports

A/C Master

47
, !evel *F*
Logín-íd
Users A%thenti&ation
Logín
Password
A/C Creatíon Report
Generates Reports
Generatíon
Transactíon
A/C Master Transactíon
Master
Authorízatíon
Authorízed Transactíon
4?
. !evel *F* "Transa&tion < A%thori)ation Mod%le#
Enters
Vaííd Users @eri-i&ation A/c
Master
A/C No.
Verífíed
@alid AD& NoG
Deposít Wíthdrawaí
Transfer
Receípt ay2ent Transfer
Una%thori)ed Transa&tion
Transactíon
Authorízatíon
Canceííed Authorízes
Canceííed Transactíon Trans
Master
4@
4A
SOFTBARE ENGINEERING ARA*IGM
A system consísts of components, whích have
components of theír own; índeed a system ís a
híerarchy of components. The híghest-íeveí
component corresponds to the totaí system. To
desígn such híerarchíes there are two possíbíe
approaches: top-down and bottom-up. The Top- down
approach starts from the híghest-íeveí component of
the híerarchy and proceeds through to íower íeveís.
A top-down desígn approach starts by
ídentífyíng the ma|or components of the system,
decomposíng them ínto theír íower-íeveí components
and íteratíng untíí the desíred íeveí of detaíís ís
achíeved. Top-down desígn methods often resuít ín
some form of stepwíse refínement.
A bottom-up desígn approach starts wíth
desígníng the most basíc prímítíve components and
proceeds to hígher-íeveí components that use these
íower-íeveí components. Bottom-up methods work
wíth íayers of abstractíon.
Our Pro|ect, “BANKER” foííows bottom-up
approach. Because ít works wíth íayers of
abstractíon. We have started wíth símpíe A/Críme
Branch openíng & transactíon and fíníshed the
pro|ect on ínterest caícuíatíon. (a sígnífícantíy
compíex procedure.)
20
21
*ata6ase ta6le str%&t%re
SOL> desc bank_íogín
Name Nuíí? Type
------------------------------- -------- ------
LOGIN_ID NOT NULL VARCHAR2(10)
PASSWORD VARCHAR2(10)
NAME VARCHAR2(30)
ADDRESS_1 VARCHAR2(20)
ADDRESS_2 VARCHAR2(20)
CITY VARCHAR2(15)
PHONE VARCHAR2(11)
EMAIL VARCHAR2(30)
USER_TYPE VARCHAR2(10)
SOL> desc account_master
Name Nuíí? Type
------------------------------- -------- ------
ACCOUNT_NO NOT NULL NUMBER(8)
AC_TYPE VARCHAR2(2)
AC_HOLDER_NAME VARCHAR2(30)
ADDRESS1 VARCHAR2(30)
ADDRESS2 VARCHAR2(20)
PHONE VARCHAR2(11)
MINOR VARCHAR2(2)
CHEOUE_ISSUED VARCHAR2(2)
OP_MODE NUMBER(2)
CL_BAL NUMBER(12,2)
AC_BAL NUMBER(12,2)
OPEN_DATE DATE
VERIFIED_BY VARCHAR2(20)
STATUS VARCHAR2(2)
INTRO_TYPE VARCHAR2(15)
SOL> desc transactíon_master
Name Nuíí? Type
------------------------------- -------- -------
TRANS_ID NOT NULL NUMBER(7)
USER_ID VARCHAR2(10)
2,
ACCOUNT_NO NUMBER(8)
TOKEN NUMBER(4)
TRANS_TYPE VARCHAR2(3)
TRANS_DATE DATE
TRANS_DB_AMT NUMBER(12,2)
TRANS_CR_AMT NUMBER(12,2)
TRANS_BAL NUMBER(12,2)
TRANS_MODE VARCHAR2(10)
CHEOUE_NO VARCHAR2(8)
SOL> desc temp_transactíon
Name Nuíí? Type
------------------------------- -------- -------
TRANS_ID NUMBER(7)
USER_ID VARCHAR2(10)
FROM_ACCOUNT NUMBER(8)
TO_ACCOUNT NUMBER(8)
TRANS_MODE VARCHAR2(10)
CHEOUE_NO VARCHAR2(8)
TR_DATE DATE
CREDIT_AMT NUMBER(12,2)
DEBIT_AMT NUMBER(12,2)
TRANS_TYPE VARCHAR2(3)
20
SOL> desc bank_admín
Name Nuíí? Type
------------------------------- -------- -------
ADMIN_LOGIN VARCHAR2(15)
ADMIN_PASS VARCHAR2(10)
SOL> desc cheque_book
Name Nuíí? Type
------------------------------- -------- -------
ACCOUNT_NO NUMBER(8)
CHO_ISSUE_DATE DATE
ST_CHO_NO VARCHAR2(8)
END_CHO_NO VARCHAR2(8)
SOL> desc dd_master
Name Nuíí? Type
------------------------------- -------- -------
DD_NUMBER NUMBER(7)
DD_DATE DATE
IN_FAVOUR_OF VARCHAR2(30)
PAYABLE_AT VARCHAR2(20)
AMOUNT NUMBER(8)
PAY_MODE VARCHAR2(10)
APPL_NAME VARCHAR2(30)
APPL_ADDRESS VARCHAR2(30)
APPL_AC_NO NUMBER(8)
EXCHANGE_AMT NUMBER(4)
ISSUED_BY VARCHAR2(10)
24
SOL> desc nomínee
Name Nuíí? Type
------------------------------- -------- ------
ACCOUNT_NO NUMBER(8)
NAME1 VARCHAR2(30)
ADDRESS1 VARCHAR2(20)
CITY1 VARCHAR2(20)
PHONE VARCHAR2(15)
NAME2 VARCHAR2(30)
ADDRESS2 VARCHAR2(30)
CITY2 VARCHAR2(20)
PHONE2 VARCHAR2(15)
SOL> desc mínor
Name Nuíí? Type
------------------------------- -------- ------
AC_ID NUMBER(8)
DOB DATE
G_NAME VARCHAR2(30)
G_ADDRESS VARCHAR2(30)
G_CITY VARCHAR2(15)
G_PHONE VARCHAR2(11)
SOL> desc account_hoíder
Name Nuíí? Type
------------------------------- -------- ------
AC_ID NUMBER(8)
AC_HOLD1 VARCHAR2(30)
ADDRESS1 VARCHAR2(30)
CITY1 VARCHAR2(15)
PHONE1 VARCHAR2(11)
AC_HOLD2 VARCHAR2(30)
ADDRESS2 VARCHAR2(30)
CITY2 VARCHAR2(15)
PHONE2 VARCHAR2(11)
SOL> desc ac_íntroducer
Name Nuíí? Type
------------------------------- -------- -------
ACCOUNT_NO NUMBER(8)
22
INTRO_TYPE VARCHAR2(15)
NAME VARCHAR2(30)
AC_TYPE VARCHAR2(4)
INTRO_AC_NO NUMBER(8)
SOL> desc fíxed_deposít
Name Nuíí? Type
------------------------------- -------- ------
ACCOUNT_NO NUMBER(8)
FIXED_AMT NUMBER(12,2)
OPEN_DATE DATE
MATURITY_DATE DATE
MATURITY_AMT NUMBER(14,2)
27
2?
@A!I*ATION C;ECKS
1* User´s íogín-name ís Uníque.
2. Vaíídatíon of user íogín and password ís done to
authentícate a íegítímate user.
3. Oníy Admínístrator can add, modífy or deíete
íogín-Ids and ordínary user & manager can´t.
4. A/c no. ís uníque.
5. Transactíon can be done from operatíve account
oníy. And the A/c shouíd have suffícíent cíear
baíance.
6. Oníy Manager can authoríze or canceí
transactíons.
7. Mínímum baíance for A/C havíng cheque facíííty
shouíd be Rs. 1000/- and for A/c havíng wíthout
cheque facíííty shouíd be Rs. 500/-.
(Appíícabíe to oníy savíng & current accounts
oníy)
@* Interest shouíd be appííed oníy once for a gíven
períod. If further attempt ís made to caícuíate
ínterest, Bank Man símpíy refers to do so.
2@
2A
SYSTEM SECURITY
A good software must have good securíty
system. Any unauthorízed access must not be
permítted. My pro|ect has trípíe securíty system. Fírst
securíty for the Admínístrator and second securíty for
the manager and thírd and íower íeveí ís User. An
ordínary user cannot have an access ín the
supervísory or manageríaí mode but an admínístrator
can have an access ín the cíerícaí and manageríaí
mode. An admínístrator can gíve the authorízatíon to
accessíng the system to the any user. A user who ís
authorízed by the admínístrator ís oníy has access
ríght for thís software. Admínístrator can deíete an
authorízed user. One user ís not permítted to access
another user íogín. Admínístrator can change hís
password for weíí-proofed securíty. An entry
compríse of user-ID, access mode, date and tíme of
íogín. The íogout tíme of the system ís recorded
when the user íogged out from the system.
70
71
GANTT C;ART
A conceptuaííy símpíe and effectíve scheduííng
techníque ís the Gantt chart, whích uses a caíendar-chart
to represent the pro|ect scheduíe. Each actívíty ís
represented as a bar ín the caíendar, startíng from the
startíng date of the actívíty become mííestones for pro|ect.
For each actívítíes a coíour bar can be drawn
specífyíng when the actívíty started and ended, í.e., when
these two mííestones were actuaííy achíeved.
7,
G &tt )$&!t

Sy"tem K>C >>C Ce"i'i+' =!ot B&)4 ;!e%&!&tio Ite'!&tio A))e%te)e Co-
<eLui!emet ed ed #o! te"t o# te"ti' te"i' -)um-
: &&ly"i" )odi' )odi' )&"e" &d -et&t-
Te"t d&t& -&tio

70
74
FUTURE SCOE
I have tríed to gíve more and more facííítíes ín a
gíven íímíted tíme, but many thíngs are untouched whích
can be added ín future. In the foííowíng sectíon some of
the facííítíes of Bankíng System whích ís untouched by me
ís gíven -
1. In future we can take on-ííne Bankíng (Through
Internet)
2. In Future ATM facíííty wouíd be províded by the
Bank.
3. Facíííty of cíearíng of cheques both íocaí and out
statíon wouíd be províded by the Bank.
4. Loaníng wouíd be started by the Bank for
varíous purposes.
5. Some compíex report wouíd be generated by
Bank usíng the core concept of fínancíaí
accountíng.
72
77
!ON!LUSIONS
On workíng wíth thís pro|ect I have got to ínterest
wíth many more ídeas to make ít more advanced &
perfect. Thís Pro|ect wííí províde wííí províde a better
management for oníy some moduíes of Banks through the
computer, whích runs through many of transactíons every
day. These transactíons may be eíther receípts, payments,
transfers, íoan and so on.
Thís pro|ect can be automatícaííy íntroduces us to the
vast areas of computers. Thís pro|ect ínspíres me to the
ídeas of deveíopíng organízatíon-oríented software for an
organízatíon.
I have got to íearn more new thíngs through these
Pro|ects. I hope that thís pro|ect ín con|unctíon wíth other
moduíes wííí be extremeíy heípfuí to any bank*
7?
7@
1I1LIOGR"H2
• T$e )om%lete <e#e!e)e 8AME -, Ke!be!t S)$ildt
;&t!i)4 N&u'$to
• 8&9& d&t&b&"e ;!o'!&mmi' (it$ ;!&ti4 ;&tel
8CBC K&!l Mo""
• M&"te!i' 8&9& , 8o$ Nu4o("4i
• ;!o#e""io&l 8S; 8,EE 1*0 Sub!&$m&y&mB
All&m&!&+uB :
Ced!i) Bue"t
• SO>B;>5SO>(O<AC>E) IMAN
BAY<OSS
Site"-
• $tt%*(((*+&9&*"u*)om
• $tt%*(((*o!&)le*)om
7A
?0
INTRO*UCTION
A6o%t the ro7e&t '
Banks facííítate fínancíaí transactíons and hence are
an íntegraí part of the commercíaí woríd. Bankíng servíces
has grown by íeaps and bounds. Today a Bank that offers
íts Customer's the wídest spread of Servíces mapped to
theír busíness (and personaí) needs ís the bank that ís
successfuí.
The Pro|ect entítíed HBANKERH (A pro|ect to
Automate Bankíng System) ís an effort towards desígníng
an Informatíon System that wouíd províde most of the
requírements of a Bank.
The pro|ect has been desígned usíng the Oracíe 8. It
uses the reíatíonaí data modeí. In thís appíícatíon we have
used the concept of the reíatíons to stored and manípuíate
the data of the Informatíon System Physícaííy these
reíatíons have been stored ín form of the tabíes.
In the desígn of HBANKERH we have expíoíted
the rích facííítíes (tooís) of the |AVA. |AVA for Rapíd
Appíícatíon Deveíopment (RAD). It ís easy to use, effícíent
?1
and fíexíbíe. I prefer thís íanguage because one can buííd
a wíndows program quícker and wíth íess effort wíth |AVA
than wíth any other programmíng íanguage.
OB>ECTI@E
The maín ob|ectíve of the pro|ect entítíed IBANKERH
ís to facííítate reííabíe, fast and easy transactíon and
províde ínformatíon on síngíe keystroke. An attempt ís
made to computerízed the Bankíng System, whích wouíd
reduce the manuaí workíoad on empíoyees of Bank. Thís
ín turn wouíd íncrease the effícíency of the bank.
CATEGORY
R*BMS '
The pro|ect faíís ín to category of RDBMS, as I have
used oracíe 8 as back end to keep the record of banks and
|AVA as front end to generate aíí the screens.
?,
? !evel ConteAt !evel# *F*
Transactíon Master
Díspíay Message
Vaííd User's Interacts Ban/er
Generates
Reports
A/C Master

?0
, !evel *F*
Logín-íd
Users A%thenti&ation
Logín
Password
A/C Creatíon Report
Generates Reports
Generatíon
Transactíon
?4
A/C Master Transactíon
Master
Authorízatíon
Authorízed Transactíon
. !evel *F* "Transa&tion < A%thori)ation Mod%le#
Enters
Vaííd Users @eri-i&ation A/c
Master
A/C No.
@eri-ied
@alid AD& NoG
*eposit Bithdra0í
Trans-er
?2
Receípt ay2ent
Trans-er
Una%thori)ed Transa&tion
Transactíon
Authorízatíon
Can&elled
A%thori)es
Can&elled Transa&tion Trans
Master
?7
ROCESS !OGIC MO*U!ES BISE
The Pro|ect entítíed "BANKER" contaíns foííowíng
moduíes:
,G A%thenti&ation '
Authentícatíon ís an ímportant procedure whích must
be performed before any user have an access the system
wíth dífferent access modes. There are three types of users
nameíy.
(í) User
(íí) Manager
(ííí) Admínístrator
and there are three access modes cíerícaí, manageríaí
and supervísory. Managers and Admínístrator can aíso work
on the system ín cíerícaí mode to perform common. Cíerícaí
tasks but user cannot work ín the manageríaí or supervísory
mode.
.G A&&o%nt Creation '
The Bank provídes facíííty to open new account for theír
new customers. The accounts can be foííowíng nature.
??
(í) Current Account (CA)
(íí) Savíng Account (SB)
(ííí) Fíxed Deposít (FS)
3G Transa&tions '
There are maíníy three types of transactíon :
(í) Receípts
(íí) Payments
(ííí) Transfers
Aíí the above types are transactíons are appíícabíe to
oníy Savíng A/c, Current A/c and Cash Credít A/c.
4G A%thori)ation '
Authorízatíon ís the most ímportant moduíe of the
pro|ect. Aíí the transactíon must be authoríze ín order to
update varíous tabíes. No payments wííí be possíbíe on
unauthorízed accounts. However receípts wííí be avaííabíe to
those accounts, Authorízatíon ís performed ín oníy
'Manageríaí' mode.
?@
5G ** and Che+%e Mod%le '
Demand Draft and cheque are ímportant ínstrument
whích wííí be managed by the pro|ect effícíentíy. Demand
Draft wííí be íssued to both account hoíders and non-account
hoíders.
Cheque can be íssued to eíther at account openíng tíme
or íater at any tíme. There ís a restríctíon of
Rs. 1000.00 shouíd be maíntaín as mínímum baíance to
account havíng cheque facíííty.
8G Tools '
There are varíous tooís avaííabíe for varíous
admínístratíve tasks such as User-ID maíntenance, ínterest
caícuíatíon etc. User-ID maíntenance íncíude user-ID
creatíon, user-ID modífícatíon and user-ID deíetíon. Interest
caícuíatíon ís descríbe beíow.
9G Interest Cal&%lation '
Dífferent ínterest rates wííí be offered by bank on
dífferent account types whích ís revíewed by RBI (Reserve
?A
Bank of Indía) over períod to períod. No ínterest wííí be paíd
to Current account but some surcharge ís charged to those
accounts. Cash Credít accounts wííí be charged by bank on
the negatíve baíance.
:G Reports '
Reports are essentíaí to have a víew and prínt for
retríevíng varíous detaíís reíated to transactíon made to
accounts and for sendíng detaíís to head-offíce. Varíous
reports íncíudes Account Statement, Account íístíng for any
partícuíar account type, ííst of aíí transactíons made between
a gíven períod of tíme etc.
@0
*ata6ase Str%&t%re -or !o1in
SGN
oG
Field Na2e *ata Type
Síze
1. Logín_ID Character 10 "ri2ary Key#
2. Password " 10
3. Name " 30
4. Address 1 " 20
5. Address 2 " 20
6. Cíty " 15
7. Phone " 11
8. E_Maíí " 30
9. Tímes Smaíí Int 2
10. D_L_L Smaíí Date
Tíme
4
11. User_Type Character 10
*ata6ase Str%&t%re -or !o1in In-o
SGN
oG
Field Na2e *ata Type
Síze
1. Logín_ID Character 10
2. Mode " 10
3. Logín Tíme Date Tíme 8
4. Logout Tíme " 8
@1
*ata6ase Str%&t%re -or ACJMast
SGN
oG
Field Na2e *ata Type
Síze
1. AC_Mast ínt 4 "ri2ary Key#
2. AC_Type Character 2
3. AC_Hoíder
Name
" 30
4. Add1 " 30
5. Add2 " 30
6. Cíty " 20
7. Phone " 11
8. Mínor Bít 1
9. Cheque_Issue
d
" 1
10. OP_Mode Smaíí Int 2
11. Cí_Baí Money 8
12. Act_Baí " 8
13. Open_Date Smaíí Date
Tíme
4
14. Verífíed_By Character 30
15. Status " 1
*ata6ase Str%&t%re -or Introd%&er
SGN Field Na2e *ata Type
Síze
@,
oG
1. AC_Mast Integer 4 "ri2ary Key#
2. Intro_Type Smaíí Int 2
3. Intro_AC No. Int 4
4. Name Character 30
5. AC Type_Dsg " 20
*ata6ase Str%&t%re -or AC ;older
SGN
oG
Field Na2e *ata Type
Síze
1. AC_Mast Integer 4 "ri2ary Key#
2. AC_Hoíder2 Character 30
3. Add1 " 30
4. Cíty2 " 20
5. Phone2 " 11
6. AC_Hoíder 3 " 30
7. Add 3 " 30
8. Cíty 3 " 20
9. Phone 3 " 11
*ata6ase Str%&t%re -or Minor
SGN
oG
Field Na2e *ata Type
Síze
1. AC_Mast Integer 4 (Prímary Key)
2. DOB Smaíí Date
Tíme
4
@0
3. G Name Character 30
4. G Add " 30
5. G Cíty " 20
6. G Phone " 11
*ata6ase Str%&t%re -or TransJMast
SGN
oG
Field Na2e *ata Type
Síze
1. Trans ID Int 4 "ri2ary Key#
2. User ID Character 10
3. AC_No. Int 4
4. Scroíí No. " 4
5. Token No. " 4
6. Trans_Type Character 1
7. Trans_Date Smaíí Date
Tíme
2
8. Trans_Dr Amt Money 8
9. Trans_Cr Amt " 8
10. Trans_Baí " 8
11. Trans_Mode Character 6
12. Authoríze Bít 1
@4
*ata6ase Str%&t%re -or Che+%e Boo/
SGN
oG
Field Na2e *ata Type
Síze
1. AC_No Integer 4
2. ChqIsuue
Date
Smaíí Date
Tíme
4
3. St_Chq No Int 4
4. End_Chq No Int 4
*ata6ase Str%&t%re -or No2inee
SGN
oG
Field Na2e *ata Type
Síze
1. AC_No Int 4
2. N Name 1 Character 30
3. N Add 1 " 30
4. N Cíty 1 " 20
5. N Phone 1 " 11
6. N Name 2 " 30
7. N Add 2 " 30
@2
8. N Cíty 2 " 20
9. N Phone 2 " 11
*ata6ase Str%&t%re -or Ter2 *epG
SGN
oG
Field Na2e *ata Type
Síze
1. AC_No Int 4
2. AC_Type Character 2
3. Open Date Smaíí Date
Tíme
4
4. Maturíty Date " 8
5. Períod Smaíí Int 2
6. Int Rate " 2
7. Ins Amt Smaíí Money 4
8. Maturíty Amt Money 8
*ata6ase Str%&t%re -or CCJ*etails
SGN
oG
Field Na2e *ata Type
Síze
1. AC_No Int 4
2. CC_Límít Money 8
@7
*ata6ase Str%&t%re -or **JMast
SGN
oG
Field Na2e *ata Type
Síze
1. DD_No Int 4
2. Date Date Tíme 8
3. In Favour of Character 30
4. Payabíe At " 20
5. Amt Money 8
6. Pymt Mode Character 10
7. Appí Name " 30
8. Appí Add " 40
9. Appí AC No Int 4
10. Exchg Amt Smaíí Money 8
11. Issued by Character 10
*ata6ase Str%&t%re -or Interest
SGN
oG
Field Na2e *ata Type
Síze
1. AC_Type Int 4
2. DOI Smaíí Date
Tíme
4
3. Períod Smaíí Int 2
4. Year " 2
5. User Character 10
5G Reports '
@?
The Report menu províde facíííty to generate and prínt
varíous reports. Varíous suboptíons íncíude under thís menu
are :-
2*1 *aily Reports : Thís íncíudes those reports whích are
ííst daííy transactíon detaíís, daííy cash receípts, daííy
cash payments and so on. Daííy reports are prínted at
the end of every day.
2*, Monthly Reports : Thís íncíudes those reports whích
are prínted at the end of every month. Thís íncíude
monthíy receípt and payment report. It aíso íncíudes
the totaí DD íssued. FD íssued etc. every month.
2*0 Yearly Reports : Thís optíon generates and prínts
reports whích are requíred to ííst the yearíy detaíís of
receípts and payments. These reports íncíudes the totaí
ínterest payed and totaí ínterest receíved, totaí
expendíture etc. These reports are generaííy sends to
head-offíces.
2*4 A&&o%nt State2ent : Account statements are the
most generaííy and ímportant report whích wííí be gíven
to account hoíders for have a compíete víew of the
transactíons performed on theír accounts. Thís optíon
@@
asks the account number and prínts the account
statement for that account.
2*2 A&&o%nt !ist : Thís optíon ís used to generate and
prínt the ííst of aíí accounts of partícuíars account type
wíth theír account hoíder name and Baíance. Thís ís
another ímportant report whích ís used to have a
compíete víew of aíí accounts.
@A!I*ATION C;ECKS
1) Users Logín-name ís Uníque.
2) Vaíídatíon of User íogín and password ís done to
authentícate a íegítímate user.
3) Oníy Admínístrator can add, modífy or deíete íogín-
IDs and ordínary user & manager can't.
4) A/c No. ís uníque.
5) Transactíons can be done from operatíve account
oníy and the A/c shouíd have suffícíent cíear baíance.
6) Oníy Manager can authoríze or canceí transactíons.
@A
7) Mínímum baíance for A/c havíng cheque facíííty
shouíd be Rs. 100/- and for A/c havíng wíthout
cheque facíííty shouíd be Rs. 500/-.
(Appíícabíe to oníy savíng & current accounts oníy)
8) Negatíve baíance wouíd be aííowed ín cash credít A/c
but ít must be wíth CC íímít.
9) Interest shouíd be appííed oníy once for a gíven
períod. If further attempt ís made to caícuíate
ínterest. Bank Manager símpíy refers to do so.
FUTURE SCOE AN* FURT;ER EN;ANCEMENT OF
T;E RO>ECT
I have tríed to gíve more and more facííítíes ín a gíven
íímíted tíme, but many thíngs are untouched whích can be
added ín future. In the foííowíng sectíon some of the facííítíes
of Bankíng System whích ís untouched by me ís gíven -
1) In future we can take on-ííne Bankíng (through
Internet).
2) In future ATM facíííty wouíd be províded by the Bank.
A0
3) Facíííty of cíearíng of cheques both Locaí and Out
Statíon wouíd be províded by the bank.
4) Loaníng wouíd be started by the Bank for varíous
purposes.
5) Some compíex report wouíd be generated by bank
usíng the core-concept of fínancíaí accountíng.
;AR*BARE < SOFTBARE RECURIEMENTS
;ard0are Re+%ire2ent ' "Re&o22ended#
1. Pentíum III (566 MHz)
2. RAM 64 MB
0* 20 GB
So-t0are Re+%ire2ents '
Language : |AVA
Backend : ORACLE-8
Píatform : Wíndows 98 (SE)
Mini2%2 ;ard0are Re+%ire2ent '
A1
1. Pentíum I (133 MHz)
2. RAM 32 MB
3. H.D.D. 5 GB
A,