Ankita Project
Ankita Project
ON
“BANK MANAGEMENT SYSTEM”
SUBMITTED BY
NAME : ANKITA SINGH
ROLL NO : 03
CLASS : XII – ‘B’
GROUP MEMBERS : BANDANA KUMARI,KUMARI SHAKCHI
Date:
APPROVED BY-
1
TABLE OF CONTENT
PAGE
SER DESCRIPTION
NO
01 CERTIFICATE 3
02 ACKNOWLEDGEMENT 4
03 INTRODUCTION 5
05 PROPOSED SYSTEM 7
10 OUTPUT 22-24
11 TESTING 25-27
13 REFERNCES 29
2
CERTIFICATE
3
ACKNOWLEDGEMENT
I pay my gratitude and sincere regards to Dr. Anu Aujla, my project guide for
giving me the cream of his knowledge. I am thankful to her as she has been a
constant source of advice, motivation and inspiration. I am also thankful to her
for giving her suggestions and encouragement throughout the project work.
4
PROJECT ON “BANK MANAGEMENT SYSTEM”
INTRODUCTION
The Bank Management System is a comprehensive software solution designed to
automate and streamline various banking operations. This system allows banks
The system will include features such as account creation, balance inquiries, fund
system, banks can enhance their operational efficiency, reduce manual errors, and
providing an efficient and user-friendly interface for both bank employees and
perform routine banking tasks, such as account creation, fund transfers, and
5
2. Improve Customer Service: Provide customers with easy access to their
mechanisms.
regulatory compliance.
systems
6
PROPOSED SYTEM
1.Account Management Module
6.Customer Interface
7.Administration Interface
7
SYSTEM DEVELOPMENT LIFE CYCLE (SDLC)
8
involved in reviewing the output of each phase to ensure the system is being built
to deliver the needed functionality.
INITIATION PHASE
9
enterprise architecture. The initiation phase begins when an opportunity to add,
improve, or correct a system is identified and formally requested through the
presentation of a business case. The business case should, at a minimum, describe
a proposal’s purpose, identify expected benefits, and explain how the proposed
system supports one of the organization’s business strategies. The business case
should also identify alternative solutions and detail as many informational,
functional, and network requirements as possible.
10
• It may include several trade-off decisions such as the decision to use
COTS software products as opposed to developing custom software or
reusing software components, or the decision to use an incremental
delivery versus a complete, onetime deployment.
• Construction of executable prototypes is encouraged to evaluate
technology to support the business process. The System Boundary
Document serves as an important reference document to support the
Information Technology Project Request (ITPR) process.
• The ITPR must be approved by the State CIO before the project can move
forward.
11
PLANNING PHASE
This phase formally defines the detailed functional user requirements using high-
level requirements identified in the Initiation, System Concept, and Planning
phases. It also delineates the requirements in terms of data, system performance,
security, and maintainability requirements for the system. The requirements are
defined in this phase to a level of detail sufficient for systems design to proceed.
12
They need to be measurable, testable, and relate to the business need or
opportunity identified in the Initiation Phase. The requirements that will be used
to determine acceptance of the system are captured in the Test and Evaluation
Master Plan.
• Further define and refine the functional and data requirements and
document them in the Requirements Document,
• Complete business process reengineering of the functions to be supported
(i.e., verify what information drives the business process, what
information is generated, who generates it, where does the information
go, and who processes it),
• Develop detailed data and process models (system inputs, outputs, and
the process.
• Develop the test and evaluation requirements that will be used to
determine acceptable system performance.
DESIGN PHASE
The design phase involves converting the informational, functional, and network
requirements identified during the initiation and planning phases into unified
design specifications that developers use to script programs during the
development phase. Program designs are constructed in various ways. Using a
top-down approach, designers first identify and link major program components
and interfaces, then expand design layouts as they identify and link smaller
subsystems and connections. Using a bottom-up approach, designers first identify
and link minor program components and interfaces, then expand design layouts
as they identify and link larger systems and connections. Contemporary design
13
techniques often use prototyping tools that build mock-up designs of items such
as application screens, database layouts, and system architectures. End users,
designers, developers, database managers, and network administrators should
review and refine the prototyped designs in an iterative process until they agree
on an acceptable design. Audit, security, and quality assurance personnel should
be involved in the review and approval process. During this phase, the system is
designed to satisfy the functional requirements identified in the previous phase.
Since problems in the design phase could be very expensive to solve in the later
stage of the software development, a variety of elements are considered in the
design to mitigate risk. These include:
14
DEVELOPMENT PHASE
15
Multiple levels of testing are performed, including:
IMPLEMENTATION PHASE
This phase is initiated after the system has been tested and accepted by the user.
In this phase, the system is installed to support the intended business functions.
System performance is compared to performance objectives established during
the planning phase. Implementation includes user notification, user training,
installation of hardware, installation of software onto production computers, and
integration of the system into daily work processes. This phase continues until
the system is operating in production in accordance with the defined user
requirements.
16
effectively adapted to respond to the organization’s needs. When modifications
or changes are identified, the system may re enter the planning phase.
The purpose of this phase is to:
17
SOURCE CODE
================================================================
CODING
• import mysql.connector
def connect():
try:
return mysql.connector.connect(
host="localhost",
user="root",
password="12as12as@",
database="bankmanagementsystem",
auth_plugin="mysql_native_password" # Explicitly set the
authentication plugin
)
except mysql.connector.Error as err:
print(f"Error: {err}")
exit(1)
def view_account(AccountNumber):
query = "SELECT * FROM accounts WHERE AccountNumber = %s"
params = (AccountNumber,)
return fetch_query(query, params)
18
def withdraw( AccountNumber,amount):
query = "SELECT balance FROM accounts WHERE AccountNumber = %s"
params = (AccountNumber,)
balance = fetch_query(query, params)[0][0]
if balance >= amount:
query = "UPDATE accounts SET balance = balance - %s WHERE
AccountNumber = %s"
params = (amount, AccountNumber)
execute_query(query, params)
else:
print("Insufficient balance")
• import bcrypt
from database import execute_query, fetch_query
def user_exists(Username):
query = "SELECT * FROM users WHERE Username = %s"
params = (Username,)
result = fetch_query(query, params)
return bool(result)
def user_exists_by_id(user_id):
query = "SELECT * FROM users WHERE UserID = %s"
params = (user_id,)
result = fetch_query(query, params)
print(f"Debug -> User Exists by ID: {result}") # Debug statement
return bool(result)
def main():
19
while True:
print("------------------------------------------------------
------------------------")
print(" WELCOME TO BANK MANAGEMENT
SYSTEM! ")
print("------------------------------------------------------
------------------------")
print("1. Register User")
print("2. Login User")
print("3. Create Account")
print("4. View Account")
print("5. Deposit")
print("6. Withdraw")
print("7. Exit")
try:
choice = int(input("Enter your choice: "))
except ValueError:
print("Invalid input. Please enter a number between 1 and
7.")
continue
if choice == 1:
username = input("Enter username: ")
password = input("Enter password: ")
print(f"Debug -> Registering user: {username}")
if not register.user_exists(username):
register.register_user(username, password)
print("User registered successfully.")
else:
print("Username already exists.")
elif choice == 2:
username = input("Enter username: ")
password = input("Enter password: ")
print(f"Debug -> Verifying user: {username}")
if register.verify_user(username, password):
print("Login successful.")
else:
print("Invalid username or password.")
elif choice == 3:
account_number = input("Enter account number: ")
name = input("Enter name: ")
try:
balance = float(input("Enter initial balance: "))
if balance < 0:
print("Balance cannot be negative.")
continue
except ValueError:
print("Invalid input. Please enter a valid number for
balance.")
continue
user_id = int(input("Enter user ID: "))
print(f"Debug -> Creating account: {account_number}, User
ID: {user_id}")
if not register.user_exists_by_id(user_id):
print("User ID does not exist in users table.")
continue
banking.create_account(account_number, name, balance,
user_id)
print("Account created successfully.")
elif choice == 4:
account_number = input("Enter account number: ")
20
print(f"Debug -> Viewing account: {account_number}")
account = banking.view_account(account_number)
if account:
print(f"Account Number: {account[0][0]}, Name:
{account[0][1]}, Balance: {account[0][2]}, User ID: {account[0][3]}")
else:
print("Account not found.")
elif choice == 5:
account_number = input("Enter account number: ")
try:
amount = float(input("Enter amount to deposit: "))
if amount <= 0:
print("Amount must be positive.")
continue
except ValueError:
print("Invalid input. Please enter a valid number for
the amount.")
continue
print(f"Debug -> Depositing amount: {amount} to account:
{account_number}")
banking.deposit(account_number, amount)
print("Amount deposited successfully.")
elif choice == 6:
account_number = input("Enter account number: ")
try:
amount = float(input("Enter amount to withdraw: "))
if amount <= 0:
print("Amount must be positive.")
continue
except ValueError:
print("Invalid input. Please enter a valid number for
the amount.")
continue
print(f"Debug -> Withdrawing amount: {amount} from
account: {account_number}")
banking.withdraw(account_number, amount)
elif choice == 7:
break
else:
print("Invalid choice.")
if __name__ == "__main__":
try:
main()
except Exception as e:
print(f"An unexpected error occurred: {e}")
•
21
OUTPUT
================================================================
USE DATABASES AND SHOW ALL TABLE IN THE DATABASES:1
:2
22
MAIN MENU: REGISTER USER
LOGIN USER
CREATE ACCOUNT
23
VIEW ACCOUNT
DEPOSIT AMOUNT
WITHDRAW AMOUNT
EXIT
24
TESTING
It can also be stated as the process of validating and verifying that a software
program/application/product meets the business and technical requirements that
guided its design and development, so that it works as expected and can be
implemented with the same characteristics. Software Testing, depending on the
testing method employed, can be implemented at any time in the development
process, however the most test effort is employed after the requirements have
been defined and coding process has been completed.
TESTING METHODS
Software testing methods are traditionally divided into black box testing and
white box testing. These two approaches are used to describe the point of view
that a test engineer takes when designing test cases.
Black box testing treats the software as a "black box," without any knowledge of
internal implementation. Black box testing methods include: equivalence
25
partitioning, boundary value analysis, all-pairs testing, fuzz testing, model-based
testing, traceability matrix, exploratory testing and specification-based testing.
SPECIFICATION-BASED TESTING
The black box tester has no "bonds" with the code, and a tester's perception is
very simple: a code must have bugs. Using the principle, "Ask and you shall
receive," black box testers find bugs where programmers don't. But, on the other
hand, black box testing has been said to be "like a walk in a dark labyrinth without
a flashlight," because the tester doesn't know how the software being tested was
actually constructed.
That's why there are situations when (1) a black box tester writes many test cases
to check something that can be tested by only one test case, and/or (2) some parts
of the back end are not tested at all. Therefore, black box testing has the advantage
of "an unaffiliated opinion," on the one hand, and the disadvantage of "blind
exploring," on the other.
26
WHITE BOX TESTING
White box testing, by contrast to black box testing, is when the tester has access
to the internal data structures and algorithms (and the code that implement these)
For example, the test designer can create tests to cause all statements in the
program to be executed at least once.
• fault injection methods.
• mutation testing methods.
• static testing - White box testing includes all static testing.
White box testing methods can also be used to evaluate the completeness of a test
suite that was created with black box testing methods. This allows the software
team to examine parts of a system that are rarely tested and ensures that the most
important function points have been tested.
27
II. PROCESSOR : INTEL OR AMD
X. Printer : required
SOFTWARE REQUIREMENTS:
• Windows OS
• Python--
• MySQL
28
REFERENCES
www.wikipedia.com
www.youtube.com
4. Dr. Anu Aujla (IP Teacher): Guidance and expert input on the project content.
29