1

“Bank Management System”

Submitted by:
Avni Singh (191950040003)

Omkar Ojha (191950040006)

Shivam Pandey (191950040010)

A Project Report Submitted

In Partial Fulfillment of the Requirements For the Degree of

Bachelor’s in Computer Applications

Under the supervision of

Miss. Safia Bano

“Lecturer”
2

AZAD DEGREE COLLEGE, LUCKNOW

Department of Computer Science & Engineering

UNIVERSITY OF LUCKNOW

Session: 2021-2022
3

BONAFIDE CERTIFICATE

Certified that this project report “Bank Management

System” is the bonafide work of “AVNI SINGH”

(191950040003) “OMKAR OJHA” (191950040006) and

“SHIVAM PANDEY” (191950040010) who carried out the

project work under my supervision.

The report embodies result of original work and studies

carried out by student himself/herself and the contents of the

project do not form the basis for the award of any other

degree to the candidate or to anybody else.

SIGNATURE OF SUPERVISOR
Miss. Safia Bano , (B.Tech+MBA)
(Lecturer)
4

ABSTRACT:

The bank management system project is a

program that keeps track of a client’s bank
account. This project demonstrates the operation
of a banking account system and covers the
essential functions of bank management
software. It develops a project for resolving a
customer’s financial applications in a banking
environment to meet the needs of an end
banking user by providing multiple ways to
complete banking chores.
5

Additionally, this project is to provide

additional features to the user’s workspace that
are not available in a traditional banking project.
The project’s bank management system is built
on cutting-edge technologies. This project’s

Main goal is to create software for a bank

account management system. This project was
designed to make it simple and quick to
complete previously impossible processes with
manual systems which are now possible with
this software.
6

TABLE OF CONTENT

S. No. Headings Page No.

1
INTRODUCTION 8-16
Bank Management System Project
1.1 11
Proposal
1.2 Project Description 12

1.3 Project Objective 13

1.4 System Requirement 14-15

1.5 Project Scope 16

LIST OF DIAGRAMS FOR
2 BANK MANAGEMENT 17-43
SYSTEM:
2.1 ER Diagram 17-24

2.2 Case Diagram 25-26

2.3 Data Flow Diagram 27

7

2.4 DFD Symbols 28-31

2.5 Activity Diagram 32-34

2.6 Class Diagram 35-37

2.7 Sequence Diagram 38-40

Data Structures And Database
2.8 Specifications 41-43

3 DESIGN 44-51

3.1 Splash Form 44

3.2 Admin Login Form 45

3.3 MDI Form 46

3.4 Account Opening Form 47

3.5 Customer Login Form 48

3.6 MDI Form 49

8

3.7 Check Balance 50

3.8 PIN Change 51

4 TESTING AND DEBUGGING 52-59

4.1 Introduction 52-53

4.2 Terms in testing fundamental 54-59

a Error 54

b Fault 54

c Failure 55

4.3 Debugging 59
FUTURE SCOPE OF THE
5 60-62
PROJECT
6 REFERENCE 63
9

INTRODUCTION:

During the past several decades’ personnel function

has been transformed from a relatively obscure
record keeping staff too central and top level
management function. There are many factors that
have influenced this transformation like
technological advances, professionalism, and general
recognition of human beings as most important
resources.

A computer based management system is designed

to handle all the primary information required to
calculate monthly statements of customer account
which include monthly statement of any month.
Separate database is maintained to handle all the
10

details required for the correct statement calculation

and generation.

This project intends to introduce more user

friendliness in the various activities such as record
updation, maintenance, and searching. The searching
of record has been made quite simple as all the
details of the customer can be obtained by simply
keying in the identification or account number of
that customer. Similarly, record maintenance and
updation can also be accomplished by using the
account number with all the details being
automatically generated. These details are also being
promptly automatically updated in the master file
thus keeping the record absolutely up-to-date.

The entire information has maintained in the

database or Files and whoever wants to retrieve can’t
11

retrieve, only authorization user can retrieve the

necessary information which can be easily be
accessible from the file.
12

Bank Management System

Project Proposal:

The bank management system project

proposal states the solution and the problems
faced by bank management. It should
contain the project objectives, scope, and
description.
13

Project Description:

The Bank Management System (BMS) is a web-

based tool that is used to reimburse financial
institutions for services rendered to the Bureau
of the Fiscal Service. In addition, BMS provides
analytical tools for reviewing and approving
salaries, budgets, and outflows.
14

Project Objectives:

The goal of the bank management system project is

to create organic and optimal software of interaction
between the various banking components. This is to
maximize the profit of the banking mechanism. The
implementation of competent bank management
procedures is significantly responsible for the
successful optimization of the bank’s productivity
and activities.

The project’s main goal is to create an online

banking system for banks. All banking work is done
manually in the current system. To withdraw or
deposit money, the user must go to the bank. Today,
it is also hard to find account information for people
who have accounts in the banking system.
15

System Requirements:
Hardware specifications:
Hardware is a set of physical components, which
performs the functions of applying appropriate,
predefined instructions. In other words, one can say that
electronic and mechanical parts of computer constitute
hardware.
This package is designed on a powerful programming
language python. It is a powerful Graphical User
Interface. The backend is ACCESS, which is used to
maintain database. It can run on almost all the popular
microcomputers. The following are the minimum
hardware specifications to run this package: -
Personal Computer: -

It minimum contains P-III

Processor with 128 MB RAM

16

Software Requirements:
The software is a set of procedures of coded
information or a program which when fed into
the computer hardware, enables the computer to
perform the various tasks. Software is like a
current inside the wire, which cannot be seen
but its effect can be felt.
1. Operating System :- Windows NT / 2000 / XP
Editor:- Notepad++ , IDLE, pycharm
17

Project Scope:

Depending on the bank’s policies, bank

personnel and or customers can utilize the
Banking Management System. It can be
utilized by multiple employees at the same
time if they have the necessary permissions.
Any web browser with a graphical interface
can be used to access it.
18

LIST OF DIAGRAMS FOR BANK

MANAGEMENT SYSTEM:

 ER Diagram:

The ER diagram for the bank management system

was made based on bank requirements. It can
encode customer information and banking
transactions.

The admin can have access to the customer status

and information for the important transactions.
They can handle the data needed in managing
customer and employee files as well as the
transactions made by the customer and staff.
19
20

The features included in the system ER

diagram were the security and monitoring of
the customer records, transactions, and status.
These features were also listed and recorded in
reports that served as the history of transactions
done in the system.

ER-modeling is a data modeling technique used

in software engineering to produce a conceptual
data model of a information system. Diagrams
created using this ER-modeling technique are
called Entity-Relationship Diagrams, or ER
diagrams or ERDs. So you can say that Entity
Relationship Diagrams illustrate the logical
structure of databases.
21

Dr. Peter Chen is the originator of the Entity-

Relationship Model. His original paper about
ER-modeling is one of the most cited papers in
the computer software field. Currently the ER
model serves as the foundation of many system
analysis and design methodologies, computer-
aided software engineering (CASE) tools, and
repository systems.

The original notation for ER-Diagrams uses

rectangles to represent entities, and diamonds to
represent relationships.
22

There are three basic elements in ER-Diagrams:

 Entities are the "things" for which we want

to store information. An entity is a person,
place, thing or event.
 Attributes are the data we want to collect for
an entity.
 Relationships describe the relations between
the entities.

ERDs show entities in a database and

relationships between tables within that
database. It is essential to have ER-Diagrams if
you want to create a good database design. The
diagrams help focus on how the database
actually works.
23

Entity (Instance)

An instance of a physical object in the real

world.

Entity Class

: Group of objects of the same type.

E.g. Entity Class “Student”, Entities “John”,

“Trish” etc

Attributes

Properties of Entities that describe their

characteristics.

Types:
24

Simple

: Attribute that is not divisible, e.g. age.

Composite

: Attribute composed of several simple

attributes,

e.g. address (house number, street, district)

Multiple

: Attribute with a set of possible values for the

same

entity, e.g. Phone (home, mobile etc.) or email

Key
25

: Uniquely Ids the Entity e.g. PPSN, Chassis

No.

Each simple attribute associated with a VS that

may be assigned to that attribute for each
individual entity,

e.g. age = integer

26

 Case Diagram:
27

This use case diagram is a visual

representation of how a user might
interact with the bank management
system.

It depicts the system’s numerous use

cases and different sorts of users. The
circles or ellipses are used to depict the
use cases.
28

 Data Flow Diagram:

 The data flow diagram is also known as

“bubble chart” has the purpose of clarifying
system requirements and identifying major
transformations that will become programs
in system design so it is the starting point of
specification down to the lowest level of
detail. A DFDs consists of a series if
bubbles joined by lines. The bubbles
represent data transformation and the lines
represent the data flow in the system.
29

 DFD Symbols:

 A system defined a source or destination

of data.
 An arrow identifies data flow, data in
motion.
 A circle represents the process that
transforms incoming data flow to outgoing
data flow.
 An open rectangular is data store-data at
rest or a temporary repository of data.
30

TRANSACTIONS
BANKING ACCOUNT HOLDERS

DATABASE
31

The Data Flow Diagram (DFD) represents

the flow of data and the transformations in the
Bank Management System. It discusses the
overall definition of input, processing, and
output.

The bank management system DFD has

three levels explaining the content of the data
flow diagram.
32
33

 Activity Diagram:

The bank management system activity

diagram is a designed illustration that
shows the system’s behavioral aspect.

It shows the bank management system’s

behavior in terms of responding to its
users or clients.
34
35

It is designed for both customers and the

admin of the Bank. It shows more
detailed information on the interactions
between the system and its users.

This design is to explain and inform

readers or users that the system provides
security for the important transaction
records and can only be accessed by
authorized personnel.
36

 Class Diagram:

The bank management system class

diagram is a designed diagram that shows
the system’s relationships and classes. This
UML Class Diagram is made to guide
programmers along with the Bank
management system development.

It contains the class attributes, methods

as well as the relationships between classes.
37
38

As you can see through the illustration,

the classes were determined which is
symbolized by boxes. They were designated
with their corresponding attributes and
show the class’ methods.

Their relationships are also plotted to

show the connections between classes and
their multiplicity.
39

 Sequence Diagram:

This diagram gives enlightenment and

guides the programmers and developers on
how should they build the system.

The idea presented in a sequence diagram

will give efficiency on Bank Management
System development.
40
41

As you can see through the illustration, the

conditions and interactions are emphasized,
these interactions are essential for the Bank
Management System development.

The series of messages are shown and

labeled to guide you in building a Bank
Management System. You can modify the
design if you have more ideas.

You can also add more features to this

design and use it as your project blueprint.
42

 Data Structures And Database

Specifications

“ACCOUNT_INFO” Table: -

Field Name Type Constraints

Account_No Int Primary Key

Account_H_Type Varchar(15) Not Null

Gender_F Varchar(6) Not Null

DOB_F DateTime Not Null

Age_F Varchar(3) Check(Age_F>=0 and Age_F<100)

Occupation_F Varchar(15) Not Null

Address_F Varchar(100) Not Null

Ph_No_F Varchar(11) Not Null

Mob_No_F Varchar(14) Not Null

Fa_Name_S Varchar(50)
43

“Deposit_Info” Table: -

Field Name Type Constraints

Account_No Int References

Account_Info(Account_No)

Depositor_Name Varchar(150)

Account_H_Type Varchar(15)

Deposit_Amt Varchar(10)

Deposit_Date DateTime

“Fixed_Info” Table: -

Field Name Data type Constraints

Account_No Int References Account_Info(Account_No)

Depositor_Name Varchar(50)

Account_H_Type Varchar(15)
44

“Login_Info” Table: -

Field Name Data type Description

UserName Varchar(20) Primary Key

UserPassWord Varchar(15)

“Withdrawl_Info” Table: -

Field Name Type Constraints

Account_No Int References

Account_Info(Account_No)

Withdrawee_Name Varchar(150)

Account_H_Type Varchar(15)

Withdrawl_Amt Varchar(10)

Withdrawl_Date DateTime
45

DESIGN:

 SPLASH FORM:
46

 ADMIN LOGIN FORM:

47

 MDI FORM:
48

• ACCOUNT OPENING FORM:

49

 CUSTOMER LOGIN FORM:

50

 MDI FORM:
51

 CHECK BALANCE:
52

 PIN CHANGE:
53

TESTING AND DEBUGGING

INTRODUCTION:-
The implementation phase of software development
is concerned with translating design specification
into source code. The preliminary goal of
implementation is to write source code and internal
documentation so that conformance of the code to its
specifications can be easily verified, and so that
debugging, testing and modifications are eased. This
goal can be achieved by making the source code as
clear and straight forward as possible. Simplicity,
clarity and elegance are the hallmark of good
programs; obscurity, cleverness, and complexity are
indications of inadequate design and misdirected
thinking.
54

Source code clarity is enhanced by structured coding

techniques, by good coding style, by, appropriate
supporting documents, by good internal comments,
and by feature provided in modern programming
languages.

The implementation team should be provided with a

well-defined set of software requirement, an
architectural design specification, and a detailed
design description. Each team member must
understand the objectives of implementation.
55

TERMS IN TESTING FUNDAMENTAL

1. Error:
The term error is used in two ways. It refers to the
difference between the actual output of software and
the correct output, in this interpretation, error is
essential a measure of the difference between actual
and ideal. Error is also to used to refer to human
action that result in software containing a defect or
fault.

2. Fault:
Fault is a condition that causes to fail in performing
its required function. A fault is a basic reason for
software malfunction and is synonymous with the
commonly used term Bug.
56

3. Failure:
Failure is the inability of a system or component to
perform a required function according to its
specifications. A software failure occurs if the
behavior of the software is the different from the
specified behavior. Failure may be caused due to
functional or performance reasons.

a. Unit Testing:
The term unit testing comprises the sets of tests
performed by an individual programmer prior to
integration of the unit into a larger system.
A program unit is usually small enough that the
programmer who developed it can test it in great
detail, and certainly in greater detail than will be
possible when the unit is integrated into an evolving
software product. In the unit testing the programs are
57

Tested separately, independent of each other. Since

the check is done at the program level, it is also
called program teasing.

b. Module Testing:
A module and encapsulates related component. So
can be tested without other system module.

c. Subsystem Testing:
Subsystem testing may be independently design and
implemented common problems are sub-system
interface mistake in this checking we concentrate on
it.

There are four categories of tests that a programmer

will typically perform on a program unit.
58

1) Functional test
2) Performance test
3) Stress test
4) Structure test

1) Functional Test:
Functional test cases involve exercising the code
with Nominal input values for which expected
results are known; as well as boundary values
(minimum values, maximum values and values on
and just outside the functional boundaries) and
special values.

2) Performance Test:
Performance testing determines the amount of
execution time spent in various parts of the unit,
program throughput, response time, and device
59

utilization by the program unit. A certain amount of

avoid expending too much effort on fine-tuning of a
program unit that contributes little to the over all
performance of the entire system. Performance
testing is most productive at the subsystem and
system levels.

3) Stress Test:
Stress tests are those designed to intentionally break
the unit. A great deal can be learned about the
strengths and limitations of a program by examining
the manner in which a program unit breaks.

4) Structure Test:
Structure tests are concerned with exercising the
internal logic of a program and traversing particular
execution paths. Some authors refer collectively to
60

functional performance and stress testing as “black

box” testing. While structure testing is referred to as
“white box” or “glass box” testing. The major
activities in structural testing are deciding which
path to exercise, deriving test date to exercise those
paths, determining the test coverage criterion to be
used, executing the test, and measuring the test
coverage achieved when the test cases are exercised.

DEBUGGING:

Defect testing is intended to find areas where the

program does not confirm to its specifications. Tests
are designed to reveal the presence of defect in the
system. When defect have been found in the
program. There must be discovered and removed.
This is called “Debugging”.
61

FUTURE SCOPE OF THE PROJECT:

This project can be handled in future by doing

various modifications like: -

We can go further for Online Banking.

We can establish and start various Branches and

available help centers for Account Holder’s
Queries.

We can also deal through internet by creating web

pages and a banking website for internet dealing.
62

To attract Account Holder’s we can offer various

offers during festivals months.

We can also deal in various types of Banking

Transactions.

To have more and more customer satisfaction we

will emphasize more and more on our dealings.
63

REFERENCES
SEARCH ENGINES: -

 google.com

WEBSITES: -
 www.w3schools.com
 www.tutorialspoint.com
 www.programiz.com
 www.guru99.com