36.multi banking doc

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

http://www.bbdu.ac.in/

2

PROJECT REPORT

on


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

http://www.bbdu.ac.in/

3


CERTIFICATE

This is to certify that Project Report entitled


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


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)

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-:

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


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


CID Varchar 100 Primary Key

ID Varchar 100 Not Null


ACCNO Number 15,0 Not Null

ATYPE Varchar 50 Not Null

CNAME Varchar 50 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


CID Varchar 100 Primary key


ACCNO Number 100 Not Null


29

C-Login- This table stores details of the customer login


ID Number 100 Not Null


PWD Number 100 Not Null

STATUS Number 50 Not Null

Help- This table stores details of the Customer problem


TOPIC Varchar 100 PRIMARY KEY

SEQ Varchar 100 Not Null

INFO Varchar 100 Not Null

30

Reject- This table stores details of the customer



ACCNO Varchar 100 Not Null



Transaction the Money-:


ID Number 100 Not Null

SACCNO Varchar 100 Not Null

DACCNO Number 100 Not Null

AMT Number 50 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


SCID Varchar 100 Not Null

SACCNO Varchar 100 Not Null

DACCNO Varchar 100 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

http://www.java.net/

http://www.apache.org/

http://www.netbeans.org/

http://www.sun.java.com/

http://www.jguru.com/

http://www.google.com/

http://www.jakarta.apache.com/

36.multi banking doc

Documents