Dr.

D Y Patil Unitech Society’s

Dr. d. y. patil arts, commerce, science college,
Pimpri

A
Project Report On
“Co-operative Bank Application”
Developed by
Abhishek Pravin Gaikwad
Sahil Rakesh Gunwani

M.Sc. computer science- SEM – 3rd

In
Department of Computer Science
Under
“Savitribai Phule Pune University”
2021- 2022
Dr. D Y PatilUnitech Society’s
 INDEX

Sr. No Content Page No

1 Title Page

2 Introduction 6

2.1 Motivation

2.2 Problem Statement

2.3 Purpose/Objective and Goals

2.4 Project Scope and Limitations

3 System Analysis 10

3.1 Comparative Study of Existing Systems

3.2 Scope and Limitations of Existing Systems

3.3 Project Perspective

3.4 Stakeholders

3.5 Requirement Analysis = Functional Requirements, performance requirement,

Security Requirement etc.

4 System Design 13

4.1 Design Constraints

4.2 Entity-Relationship diagram

4.3 Class Diagram

4.4 Use case diagram

 4.5 Activity Diagram

4.6 Sequence Diagram

4.7 Component Diagram

4.8 Deployment Diagram

4.9 Data Dictionary

4.10 Screenshots

4.11 Reports

5 Implementation Details 45

5.1 Software/hardware specification

6 Testing 46

Test plan, black box testing or data validation Test cases, White box testing or
functional validation test cases and results

7 Limitations 50

8 Conclusion 50

9 Bibliography 51

10 Reference
 4: Introduction
Providing a loan should be a simple process. One should check the client’s
eligibility to get the loan and then approve or deny the loan. Once approved, the
customer should receive the funds. 
This project reflects the implementation of our work. It is a Web Application that
is developed for a co-operative Bank Application along with certain technologies.
It includes various components and features of the firm and aims to provide
services to the customers/Member. The enhanced features are the technologies
included such as SMS service and Loan Facility etc. The application is developed
using Eclipse which helps any project to be developed in an IDE (Integrated
Development Environment). It can be proved as a small attempt to reduce the
paper work behind the loan application and cost of publishing the brochure of
bank, thus paving path towards digital India.
However, in traditional lending systems, particularly in larger organizations, this
process is often chaotic–and for valid reasons. As the customer base increases,
servicing loans become complex. Every customer has different terms and payment
dates. It is cumbersome to keep everything in order. 
2.1 MOTIVATION

The co-operative bank web application which comprises of various elements

of the co-operative society bank in order to provide services to the
customers. All of the components are accessible in a sequence for the
smooth functioning of application. It also includes certain technologies
which are broadly classified into modules. First module is Admin and
second is Member.

2.2 PROBLEM STATEMENT

The system is having many problems such as security problems, more human
involvement which is a time-consuming process with many manual work. It even
includes the loan process which allows the Member and Bank Manager, Admin,
Clerk to waste their valuable time and resources. The major problem in existing
system is to maintain data of each activity which is in perform in Co-Operative
Bank Manually.

2.3 PURPOSE /OBJECTIVE AND GOALS

 Easy to use.
 To provide online Loan information.
 Minimizing the keeping of manual records.
 Minimal data entry as most of the data will be fetched form database
automatically.
 User friendly system contains Graphical User Interface.
 Rich user interface.
 Data reliability.
2.4 PROJECT SCOPE AND LIMITATIONS
Scope:
This application is applicable is applicable for all types of bank :
 The main aim of an application is to somewhere automate records on the
system. It gives all sorts of functions which are required by the bank in
order to run a stable system.
 The application also changes or manipulates the new data that is being
added and is then re-recorded.
 Reduce Queue time.
 Customer can apply for a loan and after approved it they can track their
details from online.

Limitations:
 Speed of system depends on internet connection
 Quite hard to handle large amount of members loan applications.
 3 System Analysis

3.1 EXITING SYSTEM

The existing system is having many problems such as security problems, more
human involvement which is a time-consuming process with many manual works.
It even includes the loan process which allows the Member and Bank Manager,
Admin, Clerk to waste their valuable time and resources. The major problem in
existing system is to maintain data of each activity which is in perform in Co-
Operative Bank Manually.

3.2 PROJECT SCOPE & LIMITATIONS OF EXITING SYSTEM

Scope:
 Banking loan system is a way to maintain few records which bank holds in
order to keep a track of everything in the bank so a software application is
required in order to make the work easier.
 In existing system, we need to require go to the bank.
 Stand in queue and do waiting till our number is coming.
 Then we take the form and need to be fill it.
 Then again stand in queue and submit the form and do the further process .

Limitations:
 It takes the lots of time.
 It has a security problem.
 The current system has too much manual work from filling a form to filing a
document.

3.3 PROJECT PERSPECTIVE, FEATURES

● Full-featured talent marketplace & project management platform built
for the Finance Industry
● Easily define your requirement, our intelligent system track symptoms
 and search best expert service through designed application.
● Manage all aspects of your project.

3.4 STAKEHOLDERS

Name Represents Role

Advids Owner of This is the organization that is owner of this system

System and has all rights about system and its sales rights.

Admin Admin All rights about system.

Users(Employees) Users To developing the web pages and also download

source code.

3.5 REQUIREMENT ANALYSIS

 Technical Feasibility Study:

The technical issue usually raised during the feasibility stage of the investigation
includes the following:
 Does the necessary technology exist to do what is suggested?
 Do the proposed equipment’s have the technical capacity to hold the data
required to use the new system?
 Will the proposed system provide adequate response to inquiries, regardless
of the number or location of users?
 Can the system be upgraded if developed?
Are there technical guarantees of accuracy, reliability, ease of access and data
security?

 Economical Feasibility Study:

  The computerized system takes care of the present existing system’s
data flow and procedures completely and should generate all the
reports of the manual system besides a host of other management
reports.

 It should be built as a web based application with separate web

server and database server. This is required as the activities are
spread throughout the organization customer wants a centralized
database. Further some of the linked transactions take place in
different.

 Operational Feasibility Study:

Windows and Linux o/s. Hence portability problems will not arise.
 User-friendly
Customer will use the forms for their various transactions i.e. for adding
new routes, viewing the routes details. Also the Customer wants the reports
to view the various transactions based on the constraints. These forms and
reports are generated as user-friendly to the Client.
 Reliability
The package wills pick-up current transactions on line. Regarding the old
transactions, User will enter them in to the system.
 Security
The web server and database server should be protected from hacking,
virus etc.
 4: System Diagram

4.1 DESIGN CONSTRAINTS

Module Specifications:

 Admin:
o Login to the system with username and password.
o Add New Manager and Clerk in System
o View Manger and Clerk details
o View New All Member Application request
o View Loan Application Member Details
o Loan Approved Member Details
o Loan Reject Member Details
o Loan Pending Member Details
 o Monthly or Daily Report
o Logout

 Member:
o Register
o Login
o Update Profile
o Request to Loan
o View Loan Request Details
o Pay Loan Amount
o View Loan Details
o Logout

 Clerk:
o Login
o View New Member Loan Request
o Processing on Request
o Updated Request like Reject/Modification/Approde.
o Send Verify Member Details to Manager
o View Approved/Reject Member Details
o Logout.

 Bank Manager:
o Login
o View New Member Loan Request
o Processing on Request
o Updated Request like Reject /Approde.
o View Approved/Reject Member Details
o Logout.
4.2 ER Diagram
4.3 Class Diagram
4.4 Use Case Diagram
4.5 Activity Diagram
Manager Activity
Admin login
Clerk Activity
Member Activity
4.6 Sequence Diagram
4.7 Component Diagram
4.8 Deployment Diagram
4.9 DataDictionary

1. Admin

Field name Type Size Data Description

Format
Id int 20   Generate unique id
Username varchar 20 User Name
Pwd Varchar 10   Password

2. Member

Field Name Data Type Size Data Format Description

u_id Int 10 NN Generate unique id

Fname Varchar 20 First Name
Lname Varchar 20 Last Name
Gender Varchar 10 Gender
Date of birth Date 10 DD/MM/YY Birth Date
Mob Int 20 Mobile No
filename varchar 40 Name of File
Email Varchar 30 Email Id
Pwd Varchar 30 Password
Adhar no int 30 Aadhar card no

C_date Date 10 DD/MM/YY Confirm date

status Varchar 30 Accept/Waiting

3. Clerk_details

Field Name Data Type Size Data Format Description

Generate
C_id int 11
unique id
Name of
Clerk Name varchar 100
Clerk
Mobile
Mobile varchar 30
Number
Email varchar 30 Email id

Password varchar 30 Password

4. Loan request details

Field Name Data Type size Data Format Description

Generate
id int 11
unique id
u_id varchar 30 User id
loan_amount varchar 30 Loan Amount
loan_reason varchar 30 Loan reason
req_date varchar 30 DD/MM/YY Request Date
Status varchar 30 Loan status
response_by varchar 30 Response
Response
rsp_date varchar 30 DD/MM/YY
Date
Approved
aproved_amnt int 30
Amount
Reason varchar 300 Loan Reason
 5. Manager Details

Field Name Data Type Size Data Format Description

Generate
m_id int 11
Unique id
Manager
manager_name Varchar 100
Name
Mobile Varchar 30 Mobile NO
Email Varchar 30 Email id
Password Varchar 30 Password
c_date varchar 30 DD/MM/YY Date

3 Pay_amount

Field Data Description

Data Type Null
Name Format
Generate
id int 11
unique id
u_id varchar 30 User id
amount int 30 amount
C_date varchar 30 DD/MM/YY Date
4.10 UserInterfaces
 5.Implementation Details

5.1 Software/hardware specifications

Software Requirements
Operating system : Windows XP/07/08/10.
Coding Language : JAVA/J2EE
IDE : Eclipse Kepler
Database : MYSQL

Hardware Requirements
System : core i3
Hard Disk : 40 GB.
Floppy Drive : 1.44 Mb.
Monitor : 15 VGA Colour.
Mouse : Logitech.
Ram : 512 Mb.
 6: Testing

Test Plan

Software testing is an investigation conducted to provide stakeholders

with information about the quality of the product or service under test.
Software testing can also provide an objective, independent view of the
software to allow the business to appreciate and understand the risks of
software implementation. Test techniques include, but are not limited to,
the process of executing a program or application with the intent of finding
software bugs (errors or other defects).
It involves the execution of a software component or system
component to evaluate one or more properties of interest. In general, these
properties indicate the extent to which the component or system under test:
 Meets the requirements that guided its design and development,
 Responds correctly to all kinds of inputs,
 Performs its functions within an acceptable time, is sufficiently
usable, can be installed and run in its intended environments,
and achieves the general result its stakeholder’s desire.
As the number of possible tests for even simple software components
is practically infinite, all software testing uses some strategy to select tests
that are feasible for the available time and resources. As a result, software
testing typically (but not exclusively) attempts to execute a program or
application with the intent of finding software bugs (errors or other
defects).
Software testing can provide objective, independent information about
the quality of software and risk of its failure to users and/or sponsors.
Software testing can be conducted as soon as executable software
(even if partially complete) exists. The overall approach to software
development often determines when and how testing is conducted. For
example, in a phased process, most testing occurs after system
requirements have been defined and then implemented in testable
programs. In contrast, under an Agile approach, requirements,
programming, and testing are often done concurrently.

Black Box Testing

 Black-box testing focuses on the functional requirement of the
software, i.e. Black box testing enables the software engineer to derive sets
of input conditions that will fully exercise all functional requirements for a
program. Black-box testing attempts to find errors in the following
categories.
 Incorrect or missing functions
 Interface errors
 Errors in data structures or external database access
 Performance errors o Initialization and termination errors.

White Box Testing

White-box testing sometimes called glass-box testing is a test case

design method that uses the control structure of the procedural design to
derive test cases. Using white-box testing methods, the software engineer
can derive test cases that guarantee that all independent paths within a
module have been exercised at least once.
Exercise all logical decisions on their true and false sides. Exercise
all loops at their boundaries and within their operational bounds Exercise
internal data structures to assure their validity. In this process we analyse
sets of inputs needed to satisfy each and every function.

 Unit Testing

Unit testing focuses verification effort on the smallest unit of software

design that is the module. Using procedural design description as a guide,
important control paths are tested to uncover errors within the boundaries
of the module. The unit test is normally white box testing oriented and the
step can be conducted in parallel for multiple modules. In this we checked
whether a specific function is doing its intended task or not.

 Validation Testing

At the end of testing software is completely assembled as a package.

Validation testing is the next stage, which can be defined as successful
when the software functions in the manner reasonably expected by the
customer. Reasonable expectations are those defined in the software
 requirements specifications. Information contained in those sections form a
basis for validation testing approach.

 System Testing

System testing is actually a series of different tests whose primary purpose is to

fully exercise the computer-based system. Although each test has a different
purpose, all work to verify that all system elements have been properly integrated
to perform allocated functions. In this we tested weather a different software and
hardware elements of a system working properly or not, such as mouse is giving
right input to input module or not.

Test Scenario Test step Expected Result

Case Id

1 Test case Login Screen- Sign up Pass

2 Objective Click on sign up button then check all Pass
required/ mandatory fields with
leaving all fields blank

3 Expected All required/ mandatory fields should Pass

Result display with symbol “*”.
Instruction line “* field(s) are
mandatory” should be displayed

4 Test case Create a Password >>Text Box Pass

Confirm Password >>Text Box

5 Objective Check the validation message for Pass

Password and Confirm Password field
6 Expected Correct validation message should be Pass
Result displayed accordingly or “Password
and confirm password should be
same” in place of “Password
mismatch”.

8 Limitations
In our system the admin adds the authorized business owners, and view
details of them like name, contact number address their longitude and
latitude etc, then business owners adds product images and details about
products like name, quantity and prices etc. Users search products by
entering product name, at that time user’s longitude and latitude track
internally and search nearest shops where those products are available.
View the list of shops where the products are available. Then users buy
those products

9 CONCLUSION AND RECOMMENDATION

The use of online Co-Operative Bank services is increased gradually in daily
life and existing system requires the usage of one time password which is
send to Member mobile. In this project, we propose authentication system
 for Co-Operative bank Application which can provide greater security and
convenience by using mobile message. The application is capable enough to
take the all information about Co-Operative Bank process to electronic level
and to enhance the use of technology to great extent. Eventually, it is a
small step towards ‘Digital India’.

10 BIBLOGRAPHY AND REFERENCES

[1] https://www.tutorialspoint.com
[2] https://www.guru99.com/
[3] https://www.tutorialspoint.com/java/index.htmhttps://www.w3schools.com/java/
[4] https://www.javatpoint.com/java-tutorial
[5] https://beginnersbook.com/java-tutorial-for-beginners-with-examples/
[6] https://www.mysqltutorial.org/
[7] https://dev.mysql.com/doc/refman/8.0/en/tutorial.html
[8] https://www.w3resource.com/mysql/mysql-tutorials.php
[9]https://help.shopify.com/en/manual/products/searching-filtering
[10] https://neilpatel.com/blog/ecommerce-website-search/