Demo Project File
Demo Project File
01 ACKNOWLEDGEMENT
02 INTRODUCTION
04 PROPOSED SYSTEM
07 SOURCE CODE
08 OUTPUT
09 TESTING
11 BIBLIOGRAPHY
1
PROJECT ON STUDENT LOAN BANK MANAGEMENT SYSTEM
INTRODUCTION
OBJECTIVESOFTHEPROJECT
The objective of this project is to let the students apply the programming
softwaredevelopment.
2
PROPOSEDSYSTEM
wise saying “to err is human” no longer valid, it’s outdated to rationalize
your mistake. So, to keep pace with time, to bring about the best result
One has to use the data management software. Software has been
to maintain a lot of ledgers and a lot of paper work has to be done but
now software product on this organization has made their work faster and
easier. Now only this software has to be loaded on the computer and
workcanbe done.
This prevents a lot of time and money. The work becomes fully
3
SYSTEMDEVELOPMENTLIFECYCLE(SDLC)
4
PHASES OF SYSTEM DEVELOPMENT LIFE CYCLE
INITIATION PHASE
6
SYSTEMCONCEPTDEVELOPMENT PHASE
7
PICTORIALREPRESENTATION OF SDLC:
PLANNING PHASE
8
acquisition planning, configuration management planning, quality
assurance planning, concept
9
Of operations, system security, verification and validation, and systems
engineering management planning.
Further define and refine the functional and data requirements and
document the min 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 process sit),
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
11
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 techniques often use prototyping tools that build mock-up designs
of items such as application screens, data base layouts, and system
architectures. Endusers, designers, developers, data base 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 softwaredevelopment, a variety of elements are considered in
the design to mitigate risk. These include:
13
DEVELOPMENT PHASE
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
SOURCE CODE
class StudentLoan:
def __init__(self, loan_amount, annual_interest_rate,
loan_term):
self.loan_amount = loan_amount
self.annual_interest_rate = annual_interest_rate
self.loan_term = loan_term
def calculate_monthly_payment(self):
rate = self.annual_interest_rate / 100 / 12
months = self.loan_term * 12
if rate == 0: # No interest loan
return self.loan_amount / months
payment = self.loan_amount * rate * (1 + rate) ** months /
((1 + rate) ** months - 1)
return payment
def total_payment(self):
return self.calculate_monthly_payment() * self.loan_term *
12
def main():
print("Welcome to the Student Loan Calculator!")
try:
loan_amount = float(input("Enter the loan amount ($): "))
annual_interest_rate = float(input("Enter the annual
interest rate (%): "))
loan_term = int(input("Enter the loan term (years): "))
monthly_payment = loan.calculate_monthly_payment()
total_payment = loan.total_payment()
print("\nLoan Summary:")
print(f"Loan Amount: ${loan_amount:,.2f}")
print(f"Annual Interest Rate: {annual_interest_rate}%")
print(f"Loan Term: {loan_term} years")
print(f"Monthly Payment: ${monthly_payment:,.2f}")
print(f"Total Payment: ${total_payment:,.2f}")
except ValueError:
print("Invalid input. Please enter numeric values.")
if __name__ == "__main__":
main()
17
OUTPUT
18
19
TESTING
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.
BLACKBOX TESTING
Black box testing treats the software as a "black box," without any
knowledge of internal implementation. Black box testing methods include:
equivalence partitioning, boundary value analysis, all-pairstesting, fuzz
testing, model-based testing, trace ability matrix, exploratory testing and
specification-based testing.
20
SPECIFICATION-BASED TESTING
21
cases to be provided to the tester, who then can simply verify that for a
given input, the output value (or behaviour), either "is" or "is not" the
same as the expected value specified in the test case. Specification-based
testing is necessary, but it is in sufficient to guard against certain risks
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.
23
CODE COMPLETENESSE VALUATION
24
HARDWARE AND SOFTWARE REQUIREMENTS
HARDWARE REQUIREMENTS:
FORAMDATHALON
IX. Keyboardandmouse
X. Printer : required
SOFTWAREREQUIREMENTS:
I. WindowsOS
II. Python
25
BIBLIOGRAPHY
*****************
26