36.multi banking doc
TRANSCRIPT
1
PROJECT REPORT
on
MULTI-BANKING SYSTEM
for
DUCAT PVT LTD.
towards partial fulfillment of the requirement for the award of degree of
Master of Computer Applications
from
Babu Banarasi Das University Lucknow
Academic Session 2015 – 16
School of Computer Applications
I Floor, H-Block, BBDU, BBD City, Faizabad Road, Lucknow (U. P.) INDIA 226028 PHONE: HEAD: 0522-3911127, 3911321 Dept. Adm. & Exam Cell: 0522-3911326 Dept. T&P Cell: 0522-3911128; E-Mail: [email protected]
w w w . b b d u . a c . i n
2
PROJECT REPORT
on
MULTI-BANKING SYSTEM
for
DUCAT PVT LTD.
towards partial fulfillment of the requirement for the award of degree of
Master of Computer Applications from
Babu Banarasi Das University
Lucknow
Developed and Submitted by: Under Guidance of: Syed Mohd Zaigam Hussain Mr. Manish Kumar Bhatiya
Academic Session 2015 – 16
School of Computer Applications I Floor, H-Block, BBDU, BBD City, Faizabad Road, Lucknow (U. P.) INDIA 226028
PHONE: HEAD: 0522-3911127, 3911321 Dept. Adm. & Exam Cell: 0522-3911326 Dept. T&P Cell: 0522-3911128; E-Mail: [email protected]
w w w . b b d u . a c . i n
3
Babu Banarasi Das University Lucknow
CERTIFICATE
This is to certify that Project Report entitled
MULTI-BANKING SYSTEM
being submitted by
SYED MOHAMMED ZAIGAM HUSSAIN
towards the partial fulfillment of the requirement for the award of the degree of
Master of Computer Applications to
Babu Banarasi Das University Lucknow
in the Academic Year 2015-16
is a record of the student’s own work carried out at
DUCAT PVT LTD.
and to the best of our knowledge the work reported here in does not form a part of any other thesis or work on the basis of which degree or award
was conferred on an earlier occasion to this or any other candidate.
Prabhash Ch. Pathak HEAD (School of Computer Applications)
4
5
6
ACKNOWLEDGMENT “Task successful” makes everyone happy. But the happiness will be gold without glitter if we
didn’t state the persons who have supported us to make it a success.
Success will be crowned to people who made it a reality but the people whose constant
guidance and encouragement made it possible will be crowned first on the eve of success.
This acknowledgement transcends the reality of formality when we would like to express
deep gratitude and respect to all those people behind the screen who guided, inspired and
helped me for the completion of our project work.
I consider myself lucky enough to get such a good project. This project would add as an
asset to my academic profile.
I would like to express my thankfulness to my project guide Mr. Manish Kumar Bhatiya
for his constant motivation and valuable help through the project work, and I express my
gratitude to Mrs. Anshu Gupta, for his constant supervision, guidance and co-operation
through out the project.
I also extend my thanks to my Team Members for their co-operation during my course.
Finally, I would like to thanks my friends for their co-operation to complete this project.
Student Name
Syed Mohammed Zaigam Hussain
7
INDEX
I. Declaration II. Certificate III. Acknowledgement
1. Introduction
1.1 Introduction of Project 1.2 Features of Project 1.3 Proposed System 1.4 Existing System 1.5 Scope Of Project 1.6 Modules Of the Project
2. System Analysis
2.1 Feasibility study 2.2 SDLC Phases
2.2.1 Requirement Gathering 2.2.2 System Analysis 2.2.3 System Design 2.2.4 Coding 2.2.5 Testing 2.2.6 Implementation 2.2.7 Maintenance
2.3 Process Description 2.4 Project Model Used
3. Software Requirement Specification
3.1 Hardware Requirement
3.2 Software Requirement
4. System Design Approach
4.1 Data Flow Diagram
4.2 E-R Diagram
4.3 Structure of Tables
5. Screen Shots
5.1 Screenshots Of Various Pages 6. Conclusion
7. Future Scope
Bibliography
8
1. INTRODUCTION & OBJECTIVE
The ‘Multi Banking System’ Interface is targeted to the future banking solution for the users who have
multiple bank accounts in different banks. This interface integrates all existing banks and provides
business solutions for both retail and corporate.
Currently we are having lot of bank related system like Bank management , internet banking system in
the market .
Here we are presenting a such type of web system which is providing the complete information of all
banks in a single portal. Here registered user can enjoy using this system but if I talk about the previous
system there were no such system which provides you the complete help.
• This interface integrates all existing banks and provides business solutions for both retailers and
corporate.
• This system acts as a standard interface between the clients and the banks
• Users who have accounts in various banks can login here and can make any kind of transactions.
• In the backend, system will take care of the entire obligation required in order to carry on
transaction smoothly.
9
1.2. PURPOSE OF THE PROJECT
The multi banking system interface using MVC2 Architecture is targeted to the future banking
solution for the user who is having multiple bank account in multiple banks. This interface integrates
all existing banks and provides business solution for both retail and corporate.
This System acts as a standard interface between the user and all the
banks by using this portal any user who maintain accounts in various banks can directly log on
MULTI-BANKING SYSTEM interface and make any kind of transaction . In the backend System
will take care of the entire obligation required in order to carry on transaction smoothly.
1. It provides transactions from one bank to another bank.
2. It provides Single account from all banks.
3. In this system to provide response for the queries related to the customers..
4. In this system any time transactions through website.
1.3. EXISTING SYSTEM & DISADVANTAGES
Currently we are having lot of banks in the market and any person can do transactions of any
individual bank either manually or in online. But no one can do all banks transactions in a single
portal or in single bank. The current online banking system is only for individual banks in which the
customer has to remember his/her own user name and password for each bank which increase the
complexity for the user .
This is the main disadvantage in existing system to avoid this problem we are introducing “multi
banking system”.
Various points are related to existing System
They are not providing the all services in single portal.
Manual work is done by the existing System and take too much time.
10
1.4 SCOPE OF PROJECT
The objective of this application to make the Customers of various Banks can do their account
accessibility and transactions using this solution. They need not to interact with various applications
or web sites of each bank. The Admin will add new Bank details and can update the existing details
of the bank. The Admin will accept/reject the registration of a Customer to use this application.
The Bank Admin makes access this site to see the all Customer transactions, account Transfer
status, etc. He/she can accept or reject the fund transfer of the Customer. Should able to provide
Response for the queries related to the Customers.
The Customers should make request for multiple bank account access to the Administrator. He/she
can view the Account related information. The customer should able to transfer the amount from
one bank to another bank account using this system by providing the Secondary authentication
details. The customer also facilitated to generate report for own bank details for a respective
period. The Customer should able to send Queries to the Bank Admin.
The objective of this web application is to completely automate the process of
Multiple Banking information.
This web application s combination of various services which are user usually needed.
Easy to gain information of all bank services and easily use his/her multiple account.
Provided the same level of services to user , as we expect for ourselves.
11
SYSTEM ARCHITECTURE
Context Diagram:
Architecture flow:
Below architecture diagram represents mainly flow of requests from users to database through servers. In
this scenario overall system is designed in three tires separately using three layers called presentation layer,
business logic layer and data link layer. This project was developed using 3-tire architecture.
SERVER
User
Data
Base
Request Response
Admin
Banks
Customers
0
Multi Banking
System
Register Register
Bank
transactions
Customer
interaction
Controlling both
banks & customers
Stores data
12
1.5 MODULES OF THE PROJECT
1. Admin Module
2. Customer Module
3. Bank Admin Module
4. Reports Module
1. Admin Module:
The admin module will be used by the administrator of this portal, admin can accept or reject the
requests from the bankers, and also admin can accept or reject the requests from the users. The requests are
in the form of bank registration, customer registration. This module is having following functionalities.
Pending Bankers Requests: By using this functionality Administrator can give access
permeations to all bankers who are registered in this portal.
Pending User Requests: By using this functionality Administrator can give access permeations to
all users who are registered in this portal.
2. Customer Module:
This module describes all about customers, by using this module any customer can do some
operations like create a new account, view the account information, Transfer amount from one account to
other account and customer can also see the Transaction Reports. This module consists following
functionalities.
Create New Account: By using this functionality user can create a new account in any bank by
selecting bank name option.
View Account Information: By using this functionality user view all his account details, this can
be viewed by users who are having account in any bank.
Transfer Amount: By using this functionality user can transfer money from his account to other
accounts of same bank or other banks.
Transaction Reports: By using this functionality user can get all his transaction reports like
accepted transactions, rejected transactions and pending transactions.
13
3. Bank Admin Module:
This module deals with all transactions of bank management. By using this module bank staff can view
all details of customers, they can go for any transactions of their customers and also they can give access
permeations to all customers of that bank. This module consists following functionalities.
List of Customers: By using this functionality Bank admin can get their entire customers list and
their details.
List of Accounts: By using this functionality Bank admin can get their entire customers list based
on selected account type like saving account, current account etc.
Transfer Pending: By using this functionality Bank admin can maintain money transfer details of
customers.
Transfer Declines: By using this functionality Bank admin can maintain money transfer rejected
customer details.
New Accounts Pending: By using this functionality Bank admin can maintain entire user details
who are requesting for new account in that bank.
4. Reports Module:
In this module administrator will get different types of reports regarding customers like Number of
customers of this portal and no. of banks registered in this portal. This module is controlled by
administrator only.
14
2. SYSTEM ANALYSIS
Analysis of System
System analysis is an important activity that takes place when new information system is being built or
existing ones are changed. Its most crucial role is in defining user requirements.
System analysis, often called business system analysis to emphasize its business emphasis, is needed
in the first instance to clearly identify what is the possible and how a new system will work. This includes
gathering the necessary data and developing models for the new systems.
In large system, many people need to be satisfied and many conflicts resolved. System analyst must
play many roles.
System analyst help people solve their problems by defining what new system must do.
System analyst must understand the problem.
And suggest solution and way of implementation.
System analyst must help resolve conflicts as different people in
the organization may have different needs.
Analysts have to justify their solutions to different users.
There are many constraints imposed on analyst and many people to satisfy. A system analyst must spend a
lot of time talking to users and finding out how they use system.
15
2.1 FEASIBILITY STUDY
Preliminary investigation examines project feasibility, the likelihood the system will be useful to the
organization. The main objective of the feasibility study is to test the Technical, Operational and
Economical feasibility for adding new modules and debugging old running system. All systems are feasible if
they are given unlimited resources and infinite time. There are aspects in the feasibility study portion of the
preliminary investigation:
Technical Feasibility
Operation Feasibility
Economical Feasibility
Technical Feasibility
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 equipments 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?
Operational Feasibility
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.
Theses forms and reports are generated as user-friendly to the Client.
The package wills pick-up current transactions on line. Regarding the old transactions, User will enter
them in to the system.
Economical Feasibility
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.
16
2.2 SOFTWARE DEVELOPMENT LIFE CYCLE (SDLC)
To provide flexibility to the users, the interfaces have been developed that are accessible through a browser.
The GUI’S at the top level have been categorized as
1. Administrative user interface
2. The operational or generic user interface
The ‘administrative user interface’ concentrates on the consistent information that is practically, part of the
organizational activities and which needs proper authentication for the data collection. These interfaces help
the administrators with all the transactional states like Data insertion, Data deletion and Date updation along
with the extensive data search capabilities.
SDLC is nothing but Software Development Life Cycle. It is a standard which is used by software industry
to develop good software.
Stages in SDLC
Requirement Gathering
Analysis
Designing
Coding
Testing
Maintenance
Requirements Gathering stage
The requirements gathering process takes as its input the goals identified in the high-level requirements
section of the project plan. Each goal will be refined into a set of one or more requirements. These
requirements define the major functions of the intended application, define
operational data areas and reference data areas, and define the initial data entities. Major functions include
critical processes to be managed, as well as mission critical inputs, outputs and reports. A user class
hierarchy is developed and associated with these major functions, data areas, and data entities. Each of these
17
definitions is termed a Requirement. Requirements are identified by unique requirement identifiers and, at
minimum, contain a requirement title and textual description.
Analysis Stage
The planning stage establishes a bird's eye view of the intended software product, and uses this to establish
the basic project structure, evaluate feasibility and risks associated with the project, and describe appropriate
management and technical approaches.
The most critical section of the project plan is a listing of high-level product requirements, also referred to
as goals. All of the software product requirements to be developed during the requirements definition stage
flow from one or more of these goals. The minimum information for each goal consists of a title and textual
description, although additional information and references to external documents may be included. The
outputs of the project planning stage are the configuration management plan, the quality assurance plan, and
the project plan and schedule, with a detailed listing of scheduled activities for the upcoming Requirements
stage, and high level estimates of effort for the out stages.
18
Designing Stage
The design stage takes as its initial input the requirements identified in the approved requirements
document. For each requirement, a set of one or more design elements will be produced as a result of
interviews, workshops, and/or prototype efforts. Design elements describe the desired software features in
detail, and generally include functional hierarchy diagrams, screen layout diagrams, tables of business rules,
business process diagrams, pseudo code, and a complete entity-relationship diagram.
Development (Coding) Stage
The development stage takes as its primary input the design elements described in the approved design
document. For each design element, a set of one or more software artifacts will be produced. Software
artifacts include but are not limited to menus, dialogs, data management forms, data reporting formats, and
specialized procedures and functions. Appropriate test cases will be developed for each set of functionally
related software artifacts, and an online help system will be developed to guide users in their interactions
with the software.
Integration & Test Stage
During the integration and test stage, the software artifacts, online help, and test data are migrated from the
development environment to a separate test environment. At this point, all test cases are run to verify the
correctness and completeness of the software. Successful execution of the test suite confirms a robust and
complete migration capability. During this stage, reference data is finalized for production use and
production users are identified and linked to their appropriate roles. The final reference data (or links to
reference data source files) and production user list are compiled into the Production Initiation Plan.
Maintenance
Outer rectangle represents maintenance of a project, Maintenance team will start with requirement study,
understanding of documentation later employees will be assigned work and they will under go training on
that particular assigned category.
For this life cycle there is no end, it will be continued so on like an umbrella (no ending point to umbrella
sticks).
19
SOFTWARE REQUIREMENTS SPECIFICATION
Requirement analysis
The purpose of the Requirement analysis is to understand the exact requirement and problem of
the client and provide the proper documentation for problem.
Part of Requirement analysis
Requirement gathering and analysis
Requirement specification
Requirement analysis and Planning
Study the existing system for collecting all possible information.
Note all function requirement of user
Collect information about all input data and then analysis output requirement of system.
Planning for system requirement
We planned to solve the user requirements, in best, effective and economic way.
Creating Project activities schedule(Gant chart) for dealing complexity.
Choosing the best effective tool for handling user requirement.
Resource requirement analysis for system input and output.
Plan for Resource management.
20
SOFTWARE REQUIREMENT
Operating System : Windows
Technology : Java/j2ee (JDBC, Servlets, JSP)
Web Technologies : Html, JavaScript, CSS
Web Server : Tomcat
Database : MS access/Oracle
Software’s : J2SDK1.5, Tomcat 5.5, Oracle 10g
HARDWARE REQUIREMENT
Hardware : Pentium based systems with a minimum of P4
RAM : 256MB (minimum)
ADDITIONAL TOOLS
HTML Designing : Dream weaver Tool
Development Tool kit : My Eclipse
DEVELOPER
Processor :1.6(GHz)Pentiumprocessor
RAM :1GB
HDD :40GB
Display :1024 x 768 High color-32-bit SOFTWARE
21
Process Description Gantt charts mainly used to allocate resources to activities. The resources allocated to activities include staff,
hardware, and software. Gantt charts (named after its developer Henry Gantt) are useful for resource
planning. A Gantt chart is special type of bar chart where each bar represents an activity. The bars are drawn
along a timeline. The length of each bar is proportional to the duration of the time planned for the
corresponding activity.Gantt chart is a project scheduling technique. Progress can be represented easily in a
Gantt chart, by coloring each milestone when completed. The project will start in the month of January and
end after 4 months at the beginning of April.
22
2.4 PROJECT MODEL USED
This model has the same phases as the waterfall model, but with fewer restrictions. Generally the phases
occur in the same order as in the waterfall model, but they may be conducted in several cycles.
Useable product is released at the end of the each cycle, with each release providing additional functionality.
Customers and developers specify as many requirements as possible and prepare a SRS document.
Developers and customers then prioritize these requirements. Developers implement the specified
requirements in one or more cycles of design, implementation and test based on the defined priorities.
The procedure itself consists of the initialization step, the iteration step, and the Project Control List. The
initialization step creates a base version of the system. The goal for this initial implementation is to create a
product to which the user can react. It should offer a sampling of the key aspects of the problem and
provide a solution that is simple enough to understand and implement easily. To guide the iteration process,
a project control list is created that contains a record of all tasks that need to be performed. It includes such
items as new features to be implemented and areas of redesign of the existing solution. The control list is
constantly being revised as a result of the analysis phase.
The iteration involves the redesign and implementation of iteration is to be simple, straightforward, and
modular, supporting redesign at that stage or as a task added to the project control list. The level of design
detail is not dictated by the iterative approach. In a light-weight iterative project the code may represent the
major source of documentation of the system; however, in a critical iterative project a formal Software
design document may be used. The analysis of iteration is based upon user feedback, and the program
analysis facilities available. It involves analysis of the structure, modularity, usability, reliability, efficiency, &
achievement of goals. The project control list is modified in light of the analysis results.
23
PHASES
Incremental development slices the system functionality into increments (portions). In each increment, a
slice of functionality is delivered through cross-discipline work, from the requirements to the deployment.
The unified process groups increments/iterations into phases: inception, elaboration, construction, and
transition.
Inception identifies project scope, requirements (functional and non-functional) and risks at a high
level but in enough detail that work can be estimated.
Elaboration delivers a working architecture that mitigates the top risks and fulfills the non-functional
requirements.
Construction incrementally fills-in the architecture with production-ready code produced from analysis,
design, implementation, and testing of the functional requirements.
Transition delivers the system into the production operating environment.
24
Systems design
Systems design is the process or art of defining the architecture, components, modules, interfaces, and
data for a system to satisfy specified requirements. One could see it as the application of systems theory to
product development. There is some overlap and synergy with the disciplines of systems analysis, systems
architecture and systems engineering.
5.1 DATA FLOW DIAGRAMS
Data flow diagram will act as a graphical representation of the system in terms of interaction between the
system, external entities, and process and how data stored in certain location.
External entities
Data stores
Process
Data Flow
Context Level Dfd
25
First Level Dfd-:
26
27
Structure Of Table’s
Bank- This table stores details of the Bank
Field Name Data Type Size Constraint
ID Number 100 Primary key
BNAME Varchar 100 Not Null
Bank Login- This table stores details of the Bank Admin
Field Name Data Type Size Constraint
ID Number 100 Primary key
BID Varchar 100 Not Null
PWD Varchar 100 Not Null
BNAME Number 15,0 Not Null
STATUS Number 50 Not Null
28
Customer- This table stores details of the Customer
Field Name Data Type Size Constraint
CID Varchar 100 Primary Key
ID Varchar 100 Not Null
PWD Varchar 100 Not Null
ACCNO Number 15,0 Not Null
ATYPE Varchar 50 Not Null
CNAME Varchar 50 Not Null
BNAME Varchar 20 Not Null
BAL Number Not Null
TPWD Varchar 100 Not Null
STATUS Number 12 Null
C-Reject- This table stores details of the Customer Reject
Field Name Data Type Size Constraint
CID Varchar 100 Primary key
PWD Varchar 100 Not Null
ACCNO Number 100 Not Null
BNAME Varchar 50 Not Null
29
C-Login- This table stores details of the customer login
Field Name Data Type Size Constraint
ID Number 100 Not Null
CID Varchar 100 Primary key
PWD Number 100 Not Null
STATUS Number 50 Not Null
Help- This table stores details of the Customer problem
Field Name Data Type Size Constraint
TOPIC Varchar 100 PRIMARY KEY
SEQ Varchar 100 Not Null
INFO Varchar 100 Not Null
30
Reject- This table stores details of the customer
Field Name Data Type Size Constraint
CID Varchar 100 Primary key
ACCNO Varchar 100 Not Null
ATYPE Varchar 100 Not Null
BNAME Varchar 100 Not Null
Transaction the Money-:
Field Name Data Type Size Constraint
ID Number 100 Not Null
SACCNO Varchar 100 Not Null
DACCNO Number 100 Not Null
AMT Number 50 Not Null
ATYPE Varchar 100 Not Null
DTYPE Varchar 100 Not Nul
TPWD Varchar 100 Not Null
SBANK Varchar 100 Not Null
DBANK Varchar 100 Not Null
31
T-Accept- This table stores details of the Transfer Accept
Field Name Data Type Size Constraint
SCID Varchar 100 Not Null
SACCNO Varchar 100 Not Null
DACCNO Varchar 100 Not Null
ATYPE Varchar 50 Not Null
SBNAME Varchar 100 Not Null
SBAL Number 100 Not Nul
DCID Varchar 100 Not Null
DBNAME Varchar 100 Not Null
DTYPE Varchar 100 Not Null
DBAL Number 100 Not Null
32
5.3 ER DIAGRAMS
33
Screen Shots:
Main Page- It is the home page of Multi Banking system
.
34
Admin Login Page- It is the main admin login page. Where the admin is easily login this site
.
35
After admin login, this page was displays- Admin home page where he see the customer and banker requested.
36
New User Request Details Admin accept or reject user requested to this portel..
37
If The Admin Click Accepts User Then This Page Was Displays
38
User Main Page It is the main page of the Customer Login page where the user easily login or signup.
39
Customer Registration Page - User create single id and password to this portal.
40
Choose The Bank To Open Account- User can select the bank where he/she open account.
41
New User Registration Page- User generate the bank password and transaction password for security purpose.
42
User Registraion Request Page- User request going to the Bank Admin.
43
If The User Is Enters Wrong Details Then This Page Was Displays
44
Customer Login Page- User Login here.
45
If The User Successfully Login Then This Page Displays
46
User See Account Information
47
Bank Admin Login Page
48
Bank Registraion Page
49
Bank Home Page
50
Total List Of Customers In The Selected Bank Page
51
List Of Accounts That Are Available In That Bank Page
52
Transactions Pending Page
53
List of Pending Request
54
Customers Transfers Amount Page
55
If You Click The Transfers Link Then It Asks The Account Details
56
Tranaction Reports Page
57
Accepted Transactions Page
58
Rejected Transactions Page
59
Pending Transactions Page
60
System Testing
Testing is a process, which reveals errors in the program. It is the major quality measure employed during
software development. During software development. During testing, the program is executed with a set of
test cases and the output of the program for the test cases is evaluated to determine if the program is
performing as it is expected to perform.
7.1 TESTING IN STRATEGIES
In order to make sure that the system does not have errors, the different levels of testing
strategies that are applied at differing phases of software development are:
Unit Testing-:
Unit Testing is done on individual modules as they are completed and become executable. It is
confined only to the designer's requirements.
System Testing-:
Involves in-house testing of the entire system before delivery to the user. It's aim is to satisfy the
user the system meets all requirements of the client's specifications.
Acceptance Testing-:
It is a pre-delivery testing in which entire system is tested at client's site on real world data to find errors.
Test Approach-:
Testing can be done in two ways:
Bottom up approach
Top down approach
Bottom up Approach:
Testing can be performed starting from smallest and lowest level modules and proceeding one at
a time. For each module in bottom up testing a short program executes the module and provides the
needed data so that the module is asked to perform the way it will when embedded with in the larger
system. When bottom level modules are tested attention turns to those on the next level that use the
lower level ones they are tested individually and then linked with the previously examined lower level
modules.
61
Top down approach:
This type of testing starts from upper level modules. Since the detailed activities usually performed in
the lower level routines are not provided stubs are written. A stub is a module shell called by upper level
module and that when reached properly will return a message to the calling module indicating that
proper interaction occurred. No attempt is made to verify the correctness of the lower level module.
Validation:
The system has been tested and implemented successfully and thus ensured that all the requirements as
listed in the software requirements specification are completely fulfilled. In case of erroneous input
corresponding error messages are displayed
62
System Security
Setting Up Authentication for Web Applications
To configure authentication for a Web Application, use the <login-config> element of the web.xml
deployment descriptor. In this element you define the security realm containing the user credentials, the
method of authentication, and the location of resources for authentication.
SECURITY IN SOFTWARE
Three-Level security
This unique and user –friendly 3-level security system involving three level s of security. Where the
preceding level must be passed in order to proceed to next.
Security at this level has been imposed by using Text Based Password (with special character), which is usual
and now an anachronistic approach.
At tjis level the security has been imposed using image based authentication (BIA), where the user will be
asked to select from to difficulty levels. Both the level will be having three unique Image grid, from where
the user has to select three images, one from each grid.
After the succefully clearance of the above two level the 3-level security system will then generate OTP that
would be valid just for that login session.
USER Text based Authentication
Image Based Authentication
OTP Authentication
Login To System
63
PAYPAL -:
PayPal Introduced an optional Security key as an additional Precaution against Fraud. A user account tied to
a security key has a modified login process. The account holder enters his or her login ID and Password as
normal but is then prompted to enter a six-digit code provided by a credit card sized hardware security key
or a text message sent to the account holder’s mobile phone.
TAN-:
A Transaction Authentication number (TAN) is used by some online Banking Services as a form of single
use (OTP) one time password to authorize financial transaction.
TANs are a second layer of Security above and beyond the traditionl single password authentication
64
MAINTENANCE AND IMPLEMENTATION
Maintenance includes all the activity after the installation of software that is performed to keep the system
operational. As we have mentioned earlier, software often has design faults. The two major forms of
maintenance activities are adaptive maintenance and corrective maintenance.
Maintenance work is based on existing software, as compared to development work, which creates new
software. Consequently maintenance resolves around understanding the existing software and spares most
of their time trying to understand the software that they have to modify. Understanding the software
involves not only understanding the code, but also the related documents. During the modification of the
software, the effects of the change have to be clearly understood by the maintainer since introducing
undesired side effects in the system during modification is easier.
Types of maintenance
In a software lifetime, type of maintenance may vary based on its nature. It may be just a routine
maintenance tasks as some bug discovered by some user or it may be a large event in itself based on
maintenance size or nature. Following are some types of maintenance based on their characteristics
Corrective Maintenance - This includes modifications and updations done in order to correct or
fix problems, which are either discovered by user or concluded by user error reports.
Adaptive Maintenance - This includes modifications and updations applied to keep the software
product up-to date and tuned to the ever changing world of technology and business environment.
Perfective Maintenance - This includes modifications and updates done in order to keep the
software usable over long period of time. It includes new features, new user requirements for
refining the software and improve its reliability and performance.
Preventive Maintenance - This includes modifications and updations to prevent future problems
of the software. It aims to attend problems, which are not significant at this moment but may cause
serious issues in future.
65
Cost of Maintenance
Reports suggest that the cost of maintenance is high. A study on estimating software maintenance found
that the cost of maintenance is as high as 67% of the cost of entire software process cycle.On an average,
the cost of software maintenance is more than 50% of all SDLC phases. There are various factors, which
trigger maintenance cost go high, such as:
Real-world factors affecting Maintenance Cost
The standard age of any software is considered up to 10 to 15 years.
Older softwares, which were meant to work on slow machines with less memory and storage
capacity cannot keep themselves challenging against newly coming enhanced softwares on modern
hardware.
As technology advances, it becomes costly to maintain old software.
Most maintenance engineers are newbie and use trial and error method to rectify problem.
Often, changes made can easily hurt the original structure of the software, making it hard for any
subsequent changes.
Changes are often left undocumented which may cause more conflicts in future.
66
CONCLUSION
The name itself explains the portal. This is the site of MULTI-BANKING SYSTEM displaying the BANK
information related to various services. But can be used by the users across the globe for easy search of
various problems related to bank, suppose a user who wants the services like Internet Banking, Mobile
Banking etc.
Mainly this project is creates in the terms of target users who has Multiple Account in Multiple Bank and
want to services single user id and Password. we see that a user who doesn’t have enough time and want
services like these. After all this is the real system and it is the combination of various services.
Normally when a user get frustrated when his Online Transaction are not full fill due to some in convence
not want to go to Bank he can simply register and get response quickly. Anyone who want to take benefit
like insurance, finance, Loan he/she can also use this system.
One of the most important thing is that a user always need services of the Multiple Banking by using this
system he/she can simply use this system’s services.
67
Bibliography and References
References for the Project Development were taken from the following Books and Web Sites.
Database Reference
Ivan Bay Ross”SQL/PLSQL”, Third revised edition-2005, BPB publications. Ramakrishna. Gherkin
“Database Management System”, Third Edition-2003, Mc GRAW-HILL publications.
HTML Reference
Steven Holzner “HTML Black Book”, First Edition-2005, Dreamtech Press.
JAVA Reference
Hrbert Schildt “The Complete Reference of Java2”, Fifth Edition-2002, Tata McGraw-Hill Publishing
Company Limited. Robert Orfali. Dan Harkey “Client/Server Programming with JAVA and CORBA”,
Second Edition-2002, Wiley Computer Publishing.
JavaScript Reference
James Jaworski “Mastering JavaScript & Jscript”, First Edition-1999, BPB Publications.
WEBSITES REFFRED
www.Java.net
www.apache.org
www.netbeans.org
www.sun.java.com
www.jguru.com
www.google.com
www.jakarta.apache.com