A Project Report On

E-BANKING - ONLINE BANKING SYSTEM

SUBMITTED TO THE DEPARTMENT OF COMPUTER SCIENCE
ADIKAVI NANNAYA UNIVERSITY, RAJAMAHENDRAVARAM

In partial fulfilment for the award of the Degree of

BACHELOR OF COMPUTER SCIENCE
SUBMITTED BY:

SAKHUMALLA HIMASRI
(Regd no: 160377102120)

Under the Esteemed Guidance of

Sri L. DASARADHA RAMAYYA, MCA, M.Tech
Lecturer in Computer Science
Department of Computer Science

ADITYA DEGREE COLLEGE

(Affiliated to Adikavi Nannaya University)
Accredited by NAAC with B++ Grade
SAMBHAMURTHY NAGAR, KAKINADA-533003, E.G.Dt, ANDHRA PRADESH.
2016-2019

1
 ADITYA DEGREE COLLEGE
(Affiliated to Adikavi Nannaya University)
Accredited by NAAC with B++ Grade
SAMBHAMURTHY NAGAR, KAKINADA-533003, E.G.Dt, ANDHRA PRADESH.

DEPARTMENT OF COMPUTER SCIENCE

CERTIFICATE
This is to certify that the project entitled, “E-BANKING - ONLINE BANKING
SYSTEM” is a bona fide work of SAKHUMALLA HIMASRI, VI SEMESTER BSC
COMPUTER SCIENCE bearing Regd. No: 160377102120, submitted to the Department of
Computer Science, Aditya Degree College , Kakinada for the academic year 2016-2019.

Project Guide Head of the Department

Sri L. Dasaradha Ramayya, MCA,M.Tech Sri V.S.N Kumar, M.Tech
Lecturer in Computer Science Associate Professor

External Examiner

2
 DECLARATION
I hereby declare that the project entitled “E-BANKING - ONLINE BANKING
SYSTEM” submitted to Department of Computer Science, Aditya Degree College, Kakinada has
been carried out by me alone under the guidance of Sri. L.DASARADHA RAMAYYA.

Place: Kakinada
Date: (Sakhumalla Himasri)

3
 ACKNOWLEDGEMENT

I acknowledge the following distinguished personalities who graciously allowed me to

carry out this project work successfully. I feel it my duty and honour to acknowledge all
extended their guidance and warm support in completing my project work.
Firstly, it is privilege to thank Sri. N. Sesha Reddy, Chairman, and Sri. N. Deepak
Reddy, Secretary, Aditya Group of Educational Institutions for providing state-of-the-art
facilities, experienced and talented faculty members.
And next, I thank Sri. B.E.V.L.Naidu, Academic Co-ordinator, Aditya Degree
Colleges and Principal, Aditya Degree College , Kakinada, for their continuous support
and encouragement in my endeavour.
I express my deep sense of gratitude to Sri.V.S.N.Kumar, Head of the Department,
under whose guidance I could make a thorough and complete copy of my project work.
Finally, I thank all the teaching and non-teaching staff members who extended their
cordial and valuable help.

Project Associates

4
 ABSTRACT

E-banking is a term that includes the entire information technology

revolution that has taken place in the banking industry .E- banking simply refers to
the use of electronic channels like phone, mobile, internet for delivery of their
services to their valuable customers. Liberalization and de-regulation process, which
started in 1991-92, has made a drastic change in the Indian banking system. From a
totally regulated environment, we have gradually moved into a market driven
competitive system.
E-banking technology is gaining all-round adoption in banking industry
across developed and developing countries. The use of e-banking technologies that
includes automated teller machines (ATM’s) , telephone-banking, internet banking
and mobile banking i.e. branchless banking in the delivery of banking products and
services to their customers has become an essential aspect of modern banking
system.
E-banking system is growing its roots in developing countries like India.
Private sector banks have been adopting e-banking since their birth, but for public
sector banks, it is an uphill task. However, it is believed that e-banking will help
banks to cut cost, increase revenue, cut time for delivering service and become more
convenient for the valuable customers.

5
Online Banking System Table of Contents

1. PROBLEM DEFINITION AND SCOPE OF PROJECT......................................................................................04

1.1 Introduction...........................................................................................................................04
1.2 System Analysis....................................................................................................................05
1.2.1 Introduction....................................................................................................................05
1.2.2 Problem in Exiting System...........................................................................................06
1.2.3 Proposed System...........................................................................................................06
1.3 Project Scope........................................................................................................................07
Modules.....................................................................................................................................07
1.4 Technologies.........................................................................................................................08
1.4.1 Operating Environment................................................................................................08
1.4.2 Deployment Environment............................................................................................08
1.4.3 Development Tools and Technologies.......................................................................09
1.4.4 Development Environment..........................................................................................12
2. OVERALL DESCRIPTION......................................................................................................................................14

2.1 User Characteristics..............................................................................................................14

2.1.1 Customer........................................................................................................................14
2. 2.Assumptions.........................................................................................................................14
3. SYSTEM FEATURES................................................................................................................................................15

3. 1.Systern features...................................................................................................................15
3.1.1 .Description:...................................................................................................................15
4. REQUIREMENT ANALYSIS AND SRS...............................................................................................................16

4.1 Business goals.......................................................................................................................16

4.2 Design goals..........................................................................................................................16
4.3 Business Reqirements..........................................................................................................17
4.4 User Requirements...........................................................................................................18
4.4.1 Customer........................................................................................................................18
4.5 Operational requirements....................................................................................................18
4.6 System Requirements..........................................................................................................19
4.7 System Constraints...............................................................................................................19
5. NONFUNCTIONAL REQUIREMENTS.................................................................................................................20

5.1 Performance Requirements.................................................................................................20

5.2 Availability Requirements....................................................................................................21
5.3 Reliability Requirement........................................................................................................22
5.4 Scalability Requirement.......................................................................................................22
5.5 Security Requirements.........................................................................................................25
Security Features of .NET Technologies..............................................................................26
6 ESTIMATION.............................................................................................................................................................27

6.2 Basic COCOMO......................................................................................................................27

6.2 Function Point Estimation....................................................................................................28
6
7. IMPLEMENTATION METHODOLOGY................................................................................................................29

7.1 Spiral Model:..........................................................................................................................29

7.2 Phases of Spiral Model:.......................................................................................................30
7.2.1 Planning Phase:.............................................................................................................30
7.2.2 Risk Analysis Phase:.....................................................................................................31
7.2.3 Engineering Phase:.......................................................................................................31
7.2.4 Customer Evaluation Phase:........................................................................................31
8. PRELIMINARY DESIGN........................................................................................................................................32

8.1 Use Case..............................................................................................................................32

8.2 Specification of actors..........................................................................................................32
8.2.1 Customer........................................................................................................................32
8.3 Specification of Use Cases...................................................................................................32
8.3.1 Use Case View Mini Statement..............................................................................33
9 ER DIAGRAM.............................................................................................................................................................34
10 SCHEMA DIAGRAM...............................................................................................................................................35
11 DATA DICTIONARY..............................................................................................................................................36

11.1 Table: AccountMaster....................................................................................................36

11. 2 Table: AccountTransaction..........................................................................................36
12. PROJECT PLANNING AND SCHEDULING....................................................................................................37

12.1 Planning...............................................................................................................................37
12.2 User Interfaces...................................................................................................................37
12.3 Hardware Interfaces..........................................................................................................37
12.4 Software Interfaces............................................................................................................37
12.5 Cost of Implementation.....................................................................................................37
12.6 Effort:...................................................................................................................................38
12.6.1. Hardware cost:...........................................................................................................38
12.6.2 Training Cost:..............................................................................................................38
12.6.3 Project duration:.........................................................................................................38
12.6.4 With respect to the customer:..................................................................................38
12.7 Scheduling...........................................................................................................................39
12.8 Gantt chart:.........................................................................................................................39
12.9 Class Diagram.....................................................................................................................40
12.10 Work Breakdown structure of e-banking 41
13 INTERFACE..............................................................................................................................................................42
13 INTERFACE..............................................................................................................................................................42
13.1 EBANKING HOME PAGE..................................................................................................................................43

13.2 eBanking Start Login..........................................................................................................43

13.3 EBANKING LOGIN.............................................................................................................................................44

13.4 eBanking My Account.........................................................................................................45

13.5 eBanking Mini Statement..................................................................................................46

7
13.6 EBANKING STATEMENT SELECTION..........................................................................................................47
13.7 EBANKING VIEW DETAIL STATEMENT......................................................................................................48

13.8 eBanking Fund Transfer........................................................................................................49

13.9 eBanking Fund Transfer (Own Account).............................................................................50
13.10 eBanking Fund Transfer (Other Account)........................................................................51
13.11 eBanking Add Payee............................................................................................................52
13.12 EBANKING CHEQUE BOOK REQUEST......................................................................................................53
13.13 EBANKING FIND BRANCH...........................................................................................................................54
13.14 EBANKING CHANGE PASSWORD..............................................................................................................55
14. TEST PLAN..............................................................................................................................................................56

Introduction..................................................................................................................................56
14.1 Test Scope...........................................................................................................................56
14.2 Test Strategy.......................................................................................................................56
14.3 Preconditions.......................................................................................................................57
14.4 Test Priorities......................................................................................................................57
14.5 Test Techniques..................................................................................................................58
14.6 Test Organization...............................................................................................................58
Roles and Responsibilities......................................................................................................58
14.7 Deliverables.........................................................................................................................58
14.8 Test Environment...............................................................................................................59
Hardware and Software..........................................................................................................59
14.9 Testing Automation Software...........................................................................................59
14.10 Application Configuration................................................................................................59
15. FUTURE ENHANCEMENT...................................................................................................................................60
16. BIBLIOGRAPHY....................................................................................................................................................61

16.1 Websites............................................................................................................................... 61
16.2 Books.....................................................................................................................................61

8
 1. PROBLEM DEFINITION AND SCOPE OF PROJECT

1.1 Introduction

This e-Banking - Online Banking System Project is a model Internet

Banking Site.This site enables the customers to perform the basic banking transactions by
sitting at their office or at homes through PC or laptop. The customers can access the
banks website for viewing their Account details and perform the transactions on account
as per their requirements. With Internet Banking, the brick and mortar structure of the
traditional banking gets converted into a click and portal model, thereby giving a concept
of virtual banking a real shape. Thus today's banking is no longer confined to branches. E-
banking facilitates banking transactions by customers round the clock globally.

The primary aim of this software is to provide an improved design

methodology, which envisages the future expansion, and modification, which is necessary
for a core sector like banking. This necessitates the design to be expandable and
modifiable and so a modular approach is used in developing the software. Anybody who is
an Account holder in this bank can become a member of online banking. He has to fill a
form with his personal details and Account Number.

All transactions are carried out online by transferring from accounts in the
same Bank. The software is meant to overcome the drawbacks of the manual system. The
software has been developed using the most powerful and secure backend MS SQL Server
2005 and the most widely accepted web oriented as well as application oriented .Net
Platform 2008 which is being deployed using MS Windows Server 2003.

9
1.2 System Analysis

1.2.1 Introduction
During the analysis phase the existing system was studied. The data flow
in the existing system was studied .As part of the analysis; various documents for account
opening, money transferred issuing, Cash withdrawing, customer information reports, and
transaction reports were all collected. These were used in later stages to design the
computerized forms used the existing system was determined. The deliverable for this
stage was documentation on the existing system.

The system study is the first phase in the system life cycle. It involves
studying the ways an organization currently retrieves and process data to produce
information with the goal of determining how to make it better. For this, system analyst
should develop alternative system and evaluate each terms of cost, benefit and feasibility.
The term analysis, design and development are used in sequence, because in practice this
sequence of steps used to construct computer based information system. System analysis
includes the investigation and possible changes to the existing system.

Analysis is used to gain an understanding of the existing system

description and set of requirements for a new system. If there is no existing system, then
analysis only defines the requirements. Development begins by defining a model of the
new system and continues this model to a working system. The module of the system
shows what the system must do to satisfy these' requirements. Finally, the data models
are to a database and processed to user procedures and computer programs status.

10
1.2.2 Problem in Exiting System

The existing system involves the following activities:

 The present system operated on LAN network.

 However activities like transaction are done by bank staff only.

 Customer needs to visit bank branch for all the requirement .

 Bank staff need to address all the customer query including balance query.

 Leads to tedious manual work

 The technique adopted in this system is more complicated.

 Customer dissatisfaction

1.2.3 Proposed System

In order to overcome the drawbacks in the existing LAN based system, we have
developed online banking system for:

 Integrated
 Accessibility
 Reliable
 Consistent
 Flexible
 Secure
 Greater efficient and better data security
 Better information retrieval
 Consumption of time while generating report is less
 Reports can be viewed as and when needed from internet

11
1.3 Project Scope

The E-Banking – Online Banking System consists following features .

Modules

1: Home – This is the home page of banking system, from this page user can click
on Login link to go login page.

2: Login – This is the login page for customer. Customer needs to login to access
his account details and perform transaction over internet. Customer can use virtual
key pad to type password. System logs all valid and invalid login attempts for
security porpoise.

3: Change Password – Logged user can change their password from this page,
System automatically redirects user to change password page for first time user.

4: My Account – System display all account no and details in this screen, user can
select link to view mini statement and detail statement from this page

5: Mini Statement – In this page system display current account balance, last 10
transaction.

6: Account Statement – User can select the account no, date range to view the
detail account statement.

7: Profile – In this page customer can view his customer id, display name, email
id and mobile no. Customer can update this information also.

8: Fund Transfer – Customer can transfer funds from and to his own account or
other accounts. System validates amount limit, available balance before transfer.

9: Payee– From this page customer can add payee details like payee account no,
payee name. This details are used in Fund transfer screen.

10: Cheque book request– User can view old request and add new Cheque book
request from this page.

11: Find Branch– Customer can search bank branch by entering bank address,
city, area, pincode from this page.

12
1.4 Technologies

1.4.1 Operating Environment

OE-1: The e-Banking web application will operate with the following Web
Browsers: Microsoft Internet Explorer version 5.0, 6.0. 7.0

OE-2: The e-Banking web application shall operate on a server running the latest
versions of IIS (Internet Information Server).

OE-3: The e-Banking web application shall permit user access from Internet
connection

OE-4: Operating System: Windows 2000. XP

OE-5: Software requirements: SQL Server 2005, .net framework 3.0.

OE-6: Languages used are asp.net using c# and scripting is done using JavaScript.

OE-7: Hardware Requirements: 256(minimum)/512(recommended) MB RAM

OE-8: Hard disc- nGB depending upon the requirement to store data minimum of
25GB.

1.4.2 Deployment Environment

DE-1: Database Server

OS – Win 2003 Enterprise Server
SQL Server 2005
HDD – Min 10 GB, Recommended 25 GB
RAM – Min 2 GB, Recommended 4 GB
Processor - Pentium Dual Xenon Processor

DE-2: Application Server

OS – Win 2003 Enterprise Server
IIS – Internet Information Server
HDD – Min 5 GB, Recommended 10 GB
RAM – Min 2 GB, Recommended 4 GB
Processor - Pentium Dual Xenon Processor

13
 DE-3: The e-Banking web application will operate with the following Web
Browsers: Microsoft Internet Explorer version 5.0, 6.0. 7.0.

[e-Banking – Online Banking System Architecture]

1.4.3 Development Tools and Technologies

DT-1: Visual Studio .NET

Visual Studio .Net is the rapid application development tool for BASIC.
Visual Studio .Net offers complete integration with ASP.NET and enables to
drag and drop server controls and design Web Forms as they should appear
when user views them. Some of the other advantages of creating BASIC
applications in Visual Studio .Net are

 Visual Studio .Net is a Rapid Application (RAD) tool. Instead of adding

each control to the Web Form programmatically, it helps to add these
controls by using toolbox, saving programming efforts.

14
  Visual Studio .Net supports custom and composite controls. Can
create custom controls that encapsulate a common functionality that
might need to use in a number of applications.

Visual Studio .Net does a wonderful job of simplifying the creation and
consumption of Web Services. Mush of the programmer-friendly stuff
(creating all the XML-based documents) happens automatically, without
much effort on the programmer's side. Attribute-based programming is a
powerful concept that enables Visual Studio .Net to automate a lot of
programmer-unfriendly tasks.

DT-2: .NET programming languages

The .NET Framework provides a set of tools that help to build code that
works with the .NET Framework, Microsoft provides a set of languages that
are already .NET compatible. BASIC is one of those languages.

ASP.NET environment:

Active Server Pages were released by Microsoft to enable the creation

of dynamic pages based on user input and interaction with a Web site.
ASP.NET improves upon the original ASP by providing code-behind. With
ASP.NET and code-behind, the code and HTML can be separated.

ASP.NET Web services are XML-based services that are exposed on

the Internet that can be accessed by other Web services and Web service
clients.

DT-3: ASP.NET

ASP.NET is more than the next version of Active Server Pages (ASP);
it is a unified Web development platform that provides the services
necessary for developers to build enterprise-class Web applications. While
ASP.NET is largely syntax compatible with ASP, it also provides a new
programming model and infrastructure for more secure, scalable, and stable
applications.

15
 ASP.NET is a compiled, .NET-based environment; you can author
applications in any .NET compatible language, including VisualBasic.NET,
BASIC, and JScript.NET. Additionally, the entire .NET Framework is available
to any ASP.NET application. Developers can easily access the benefits of
these technologies, which include the managed common language runtime
environment, type safety, inheritance, and so on.

ASP.NET has been designed to work seamlessly with WYSIWYG

HTML editors and other programming tools, including Microsoft Visual Studio
.NET. Not only does this make Web development easier, but it also provides
all the benefits that these tools have to offer, including a GUI that
developers can use to drop server controls onto a Web page and fully
integrated debugging support. Developers can choose from the following
two features when creating an ' ASP.NET application, Web Forms and Web
services, or combine these in any way they see fit.

Web Forms allows you to build powerful forms-based Web pages.

When building these pages, you can use ASP.NET server controls to create
common Ul elements, and program them for common tasks. These controls
allow you to rapidly build a Web Form out of reusable built-in or custom
components, simplifying the code of a page.

DT-4: ASP.NET Features

 Intuitive C++ based Language

 Use a language modeled on C++ syntax, immediately familiar to C++

and Java developers, as well as intuitive new language constructs that
greatly simplify development tasks

 Reliable Interoperability

16
DT-5: SQL Server
Relational database systems are the most important database systems
used in the software industry today. One of the most outstanding systems is
Microsoft SQL Server. SQL Server is a database management system developed
and marketed by Microsoft. It runs exclusively under Windows OS.

The most important aspects of SQL Server:

• SQL Server is easy to use.

• SQL Server scales from a mobile laptop to symmetric multiprocessor

systems.

• SQL Server provides data warehousing features that until now have
only been available in Oracle and other more expensive DBMSs.

A database system is an overall collection of different database software

components and databases containing the parts viz. Database application
programs, Front-End components, Database management systems, and
Databases.

SQL Server is a Relational Database Management System. The SQL Server

relational language is called Transact-SQL.SQL is asset-oriented language. This
means that SQL can query many rows from one or more tables using just one
statement. This feature allows the use of this language at a logically higher level
than procedural languages. Another important property of SQL is its non-
procedurally. SQL contains two sub languages DDL and DML.

SQL Server works as a natural extension of Windows NT and windows 95/98.SQL

Server is relatively easy to manage through the use of a graphical computing
environment for almost every task of system and

1.4.4 Development Environment

DE-1: 1.Visual Studio 2005 IDE

Most advanced integrated development environment for
developing .NET application. Microsoft Visual Studio is an integrated

17
development environment (IDE) from Microsoft. It can be used to develop
console and graphical user interface applications along with Windows Forms
applications, web sites, web applications, and web services in both native
code together with managed code for all platforms supported by Microsoft
Windows, Windows Mobile, Windows CE, .NET Framework, .NET Compact
Framework and Microsoft Silverlight.
Visual Studio includes a code editor supporting IntelliSense as
well as code refactoring. The integrated debugger works both as a source-
level debugger and a machine-level debugger. Other built-in tools include a
forms designer for building GUI applications, web designer, class designer,
and database schema designer. It allows plug-ins to be added that enhance
the functionality at almost every level - including adding support for source
control systems (like Subversion and Visual SourceSafe) to adding new
toolsets like editors and visual designers for domain-specific languages or
toolsets for other aspects of the software development lifecycle (like the
Team Foundation Server client: Team Explorer).

Visual Studio supports languages by means of language

services, which allow any programming language to be supported (to
varying degrees) by the code editor and debugger, provided a language-
specific service has been authored. Built-in languages include C/C++ (via
Visual C++), VB.NET (via Visual Basic .NET), and C# (via Visual C#).
Support for other languages such as Chrome, F#, Python, and Ruby among
others has been made available via language services which are to be
installed separately. It also supports XML/XSLT, HTML/XHTML, JavaScript
and CSS. Language-specific versions of Visual Studio also exist which
provide more limited language services to the user. These individual
packages are called Microsoft Visual Basic, Visual J#, Visual C#, and Visual
C++.

18
 2. Overall Description

2.1 User Characteristics

2.1.1 Customer
Able to login, view balance, account statement and perform transcation.

2. 2.Assumptions

1) System User and Administrator communicate with each other via emails.

19
 3. System Features

3. 1.Systern features

3.1.1 .Description:
A web based Online Banking System provides the banking facility over internet.
.

3.1.2.Constraints
Sending SNS and EMAIL alert. Full Text Search Capability: Send and Save account
statement in PDF, EXCEL formats, keywords. Basic and Advanced Search: Ability to do a
quick or advanced searching. Etc.

20
 4. Requirement Analysis and SRS
The requirement analysis outlines the approach the development team will take to meet
the goals of the project and provides the basis for proceeding to the planning phase. After
identifying the business problem and defining the vision and scope of e-Banking
application, the team creates the solution concept that explains in general terms how the
team intends to meet the requirements of the project.

For a project to be successful, it is essential that we correctly identify the goals of the
project. Project goals can be categorized as follows:

 Business goals
 Design goals

4.1 Business goals

Business goals represent what the organization wants to achieve with the solution.
Business goals form the basis for determining the success criteria of the solution. The
purpose of defining business goals is to clearly articulate the objectives for the project and
to ensure that your solution supports those business requirements. The team needs to
determine the best method for identifying the goals and agreeing on them.

For this e-Banking for Online Banking System project, business goals might include the
following:

 Extends well beyond the normal concept of a ‘Banking’ and represents a online
banking facility to provide better customer support and experience.
 Reduce customer query and provide facility to customer perform limited online
transaction.

 Shorten the time to overall request handling time.

 Secure platform to perform online transaction.

4.2 Design goals

Design goals are similar to business goals in many ways. The difference is that design
goals focus more on the attributes of the solution and less on what the solution will

21
accomplish for the business. Design goals address not only what the team wants to
accomplish but also what the team is not trying to accomplish with the solution. As with
business goals, you need to prioritize design goals so that the team knows which goals
must be accomplished, in case the project cannot achieve all of them.

Consider the case of this e-Banking web site. Some of the design goals for the online
Online Banking System might include:

 Improve the user experience by reducing page-download wait times to 5 seconds

or less.
 Limit dependency on connectivity with the server.

 Reduce the time and level of effort required for a user to complete the online
request submit process.

 The service must have an availability of 99.99 percent.

 The service cannot lose data.

 The service must permit access only by authorized users.

4.3 Business Requirements

The following preliminary lists are based on initial interviews and study of existing manual
system,

The business goal for the application is to support an increase the productivity and
complete automation of existing manual or semi automatic Online Banking System.
Business requirements are discussed in the Scope section, with the following additional
detail:

 Increase customer handling capacity.

 Provide 24 hours customer support.
 Customer can access the site from any location and any where by using e-Banking
web portal.
 The Administrator should be able to enter or update master information like
customer and account information.

22
 The application should support the capability to use multi user environment.
 Every page on the Web site must display a menu option with appropriate options
for easy navigation.

23
4.4 User Requirements
User requirements are categorized by user type.

4.4.1 Customer
 Able to login into e-Banking system.
 Able to view account information.
 Able to view updated account balance.
 Able to view mini statement.
 Able to generate account statement for date range.
 Able to change his login password.
 Able to perform fund transfer.

4.5 Operational requirements

The following requirements provide a high-level view of how the system will run:
 Processor usage should not exceed 80 percent during concurrent uses.
 Backups will occur incrementally throughout the day.
 A full weekly backup is required to WORM drives.
 Ensure that information is easy to access either, and meaningful for the system
users and the company.
 Minimize the technical knowledge that system users and customer need to access
the data, generate ad hoc queries, search and view request.
 Any change to information must be reflected immediately, and the changes must
be propagated to the search engine so that system users that perform searches
see this new information.
 The application should work with the existing communications and networking
infrastructure.

24
  The application should deploy with a minimum of additional operational processes,
manual or otherwise.

4.6 System Requirements

These are additional constraints from a system perspective:

 The administrator must be able to monitor everything from the IT department.

 The information must be accessible by everyone in the company in intranet and in
internet for the members as per the rights specify.
 All data especially request status must be up to date.

4.7 System Constraints

Constraints indicate the parameters to which the final business solution must adhere.
They are aspects of the business environment that cannot or will not be changed. Often,
these constraints become design goals for the application. If constraints are not identified
properly, the project team might design a product that cannot be deployed within the
business.

Examples of possible constraints that you should document include:

 Budget limitations
 Characteristics of earlier supporting systems

 Network system architecture

 Security requirements

 Operating systems

 Planned upgrades to technologies

 Network bandwidth limitations

 Maintenance and support agreements and structures

 Knowledge level of development or support staff

25
 Learning limitations of users

26
 5. Nonfunctional Requirements

5.1 Performance Requirements

An application’s performance is defined by metrics such as transaction throughput and
resource utilization. A user might define an application’s performance in terms of its
response time. No more than 5-percent degradation in average query response is allowed
while all concurrent users are using the system. Processor utilization should not exceed 80
percent during all concurrent users are using the system.

We must define performance requirements before the team proceeds to the developing
phase. To define a good performance requirement, we must identify project constraints,
determine services that the application will perform, and specify the load on the
application.

PR-1: Identifying constraints - Constraints in the project include budget, schedule,

infrastructure, and the choice of development tools or technologies. For example, we
might need to deploy this e-Banking application by a specific date. We might also need
to use a specific development tool because the team has expertise in that tool only.
We might not be able to design and develop applications that are processor intensive
because the client computers do not have adequate hardware. We need to design an
application so that it meets its performance goals within the limitations of the
constraints. Instead of changing some aspects of a project to improve performance,
you can modify aspects of the project that are not constrained to determine how we
can improve performance. For example, can the team be trained so that they can
create components by using a different tool? Can data access be improved by
changing the data access technology?

PR-2: Determining features - The features of this application correspond to use

cases and usage scenarios. We can identify the usage scenarios that affect the
performance of the application and, for each such scenario, specify what the user does
and what the application does in response, including how databases and other system
services are accessed. In addition, you need to determine how often each feature will
be used. This information can help you create tests for measuring performance that
resemble actual usage of the application as closely as possible.

PR-3: Specifying the load - We can specify the load of this e-Banking application as
the number of users that will use the application. In addition, we can examine how the
load might vary over time. For example, the number of requests for this e-Banking site
will be higher during certain times of year. We can use the load to define the
performance metrics of this application.

27
5.2 Availability Requirements

Availability is a measure of how often the application is available to handle service

requests as compared to the planned run time. Availability also takes into account repair
time because an application that is being repaired is not available for use.

Designing for availability includes anticipating, detecting, and resolving hardware or

software failures before they result in service errors, faults, or data corruption, thereby
minimizing downtime. To ensure availability, provide multiple routes to application
services and data. Use only tested, proven processes (both automated and people-based)
that support the application throughout its life cycle.

Availability of e-Banking application also depends on its reliability. For a highly available
and reliable application, you need a reliable foundation: good application design, rigorous
testing, and certification. Some of the techniques used for designing for availability
include:

AR-1: Reduce planned downtime - To avoid planned downtime, use rolling

upgrades. For example, to update a component on a server, move the server’s
resource groups to another server, take the server offline, update the component, and
then bring the server online. Meanwhile, the other servers handle the workload, and
this application experiences no downtime. You can use this strategy in an application
that scales out.

AR-2: Reduce unplanned downtime with clustering - Clustering is a technology

for creating high-availability applications. A cluster consists of multiple computers that
are physically networked and logically connected using cluster software. By using
clustering, a multiple server Web site can withstand failures with no interruption in
service. When the active server fails, the workload is automatically moved to a passive
server, current client processes are switched over, and the failed application service is
restarted automatically. If a resource fails, customers connected to that server cluster
might experience a slight delay, but the service will be completed. Cluster software
can provide failover support for applications, file and print services, databases, and
messaging systems that have been designed as cluster-aware and assigned to a
cluster.

AR-3: Use network load balancing - Network load balancing (NLB) is used to
distribute traffic evenly across available servers. NLB also helps increase the availability
of an application: if a server fails, you can use NLB to redefine the cluster and direct
traffic to the other servers. As client traffic increases, you can scale out the Web
server farm by adding up to 32 servers in a single cluster. NLB automatically detects
server failures and redirects client traffic to the remaining servers, all the time
maintaining continuous, unbroken client service.

28
 AR-4: Use redundant array of independent disks (RAID) for data stores. -
RAID uses multiple hard disks to store data in multiple places. If a disk fails, the
application is transferred to a mirrored data image and the application continues
running. The failed disk can be replaced without stopping the application.

AR-5: Isolate mission-critical applications - An application is constantly

performing tasks and requesting resources such as network communications, data
access, or process threads. Each of these resource requests can affect the
performance and availability of applications sharing the same resources. If an
application shares these services on the same servers, the workload and throughput
characteristics for these servers might change unfavorably. It is recommended that
mission-critical applications use dedicated infrastructures and private networks.

5.3 Reliability Requirement

The reliability of an application refers to the ability of the application to provide accurate
results. Reliability and availability are closely related. While availability measures the
capacity to handle all requests and to recover from a failure with the least loss of access
to the application, reliability measures how long the application can execute and produce
expected results without failing reliable solution ensures error-free data input, data
transformations, state management, and non-corrupting recovery from any failure
conditions. Creating a high-reliability application depends on the entire software
development lifecycle, from the planning phase, through development and testing, to
deployment and stabilizing. The following tasks can help you create a reliable application:

 Putting reliability requirements in the specification

 Using a good architectural infrastructure

 Including management information in the application

 Using redundancy

 Using quality development tools

 Using reliability checks that are provided by the application

 Implementing error handling

 Reducing the application’s functionality instead of completely failing the application

29
5.4 Scalability Requirement

Scalability is defined as the capability to increase resources to produce an increase in the

service capacity. In a scalable application, you can add resources to manage additional
demands without modifying the application itself.

A scalable application requires a balance between the software and hardware used to
implement the application. You might add resources to either software or hardware to
increase the scalability of the application. Adding these resources might produce a
benefit; however, it could also have a negative or null effect, with the application showing
no significant increase in service capacity. For example, you might implement load
balancing in an application. This will help only minimally if the application has been
written to make synchronous method calls or to retrieve lengthy datasets in response to a
user’s request.

e-Banking for Online Banking System an average load of 150 concurrent users after the
system is fully operational, and expects that to grow by 25 percent each year for the next
five years.

The two most common approaches to scalability are:

SR-1: Scaling up - Refers to achieving scalability by improving the existing

server’s processing hardware. Scaling up includes adding more memory, more or
faster processors, or migrating the application to a more powerful computer. The
primary goal of scaling up an application is to increase the hardware resources
available to the application. Typically, you can scale up an application without
changing the source code. In addition, the administrative effort does not change
drastically. However, the benefit of scaling up tapers off eventually until the actual
maximum processing capability of the machine is reached.

SR-2: Scaling out - Refers to distributing the processing load across more than
one server. Although scaling out is achieved by using multiple computers, the

30
 collection of computers continues to act as the original device configuration from
the end-user perspective. Again, the balance between software and hardware is
important. The application should be able to execute without needing information
about the server on which it is executing. This concept is called location
transparency. Scaling out also increases the fault tolerance of the application.

Bellow figure illustrates the role of design, code tuning, product tuning, and hardware
tuning in the scalability of an application. Design has more impact on the scalability of an
application than the other three factors. As you move up the pyramid, the impact of
various factors decreases. The pyramid illustrates that effective design adds more
scalability to an application than increased hardware resources.

SR-3: Design processes such that they do not wait - A process should never
wait longer than necessary. A process can be categorized as synchronous or
asynchronous. A synchronous process waits for another process to complete before
it continues. Such processes must wait for another process to succeed or fail
completely before performing another operation. Applications that implement
synchronous processes encounter bottlenecks for resources. These bottlenecks

31
 affect both the performance and the scalability of the application. One way to
achieve scalability is to implement asynchronous processes. In applications that
have asynchronous processes, long-running operations can be queued for
completion later by a separate process.

SR-4: Design processes so that processes do not compete for resources -

One of the biggest causes of scalability problems is competition for resources such
as memory, processor cycles, bandwidth, or database connections. Plan your
resource usage to minimize these problems:

 Sequence resource usage to use the most plentiful resources first and the
least plentiful resources last.

5.5 Security Requirements

Malicious attackers use various methods to exploit system vulnerabilities to achieve their
goals. Vulnerabilities are weak points or loopholes in security that an attacker exploits to
gain access to an organization’s network or to resources on the network. Some
vulnerabilities, such as weak passwords, are not the result of application or software
development design decisions. However, it is important for an organization to be aware of
such security weaknesses to better protect its systems. Common vulnerabilities of
applications include:

SR-1: Weak passwords - A weak password might give an attacker access not only
to a computer, but to the entire network to which the computer is connected.

SR-2: Misconfigured software - Often the manner in which software is configured

makes the system vulnerable. If services are configured to use the local system
account or are given more permissions than required, attackers can exploit the
services to gain access to the system and perform malicious actions on the system.

SR-3: Social engineering - A common form of discovering passwords that generally

occurs when users are not aware of security issues and can be deceived into revealing
their passwords. For example, an attacker posing as a help desk administrator might
persuade a user to reveal his or her password under the pretext of performing an
administrative task.

SR-4: Internet connections - The default installation of Internet Information

Services (IIS) version 5.0 often enables more services and ports than are necessary
for the operation of a specific application. These additional services and ports provide
more opportunities for potential attacks.

32
ADO.NET and SQL Server

ADO.NET provides data access services. It is designed for distributed Web applications,
and supports disconnected scenarios. When we build Web-based applications, it is
essential that we must use a secure approach to accessing and storing data. ADO.NET
and SQL Server provide several security features that can be used to ensure secure data
access.

[Security architecture]

33
 6 Estimation

6.2 Basic COCOMO

The COnstructive COst MOdel (COCOMO) is an algorithmic Software Cost Estimation
Model developed by Barry Boehm. The model uses a basic regression formula, with
parameters that are derived from historical project data and current project
characteristics. Constructive Cost Model: It is a hierarchy of estimation models that
address: Application composition model: Used during the early stage of software
engineering, when prototyping of user interfaces, consideration of software and system
interaction, assessment of performance, and evaluation of technology maturity are
paramount..

COCOMO consists of a hierarchy of three increasingly detailed and accurate forms. The
first level, Basic COCOMO is good for quick, early, rough order of magnitude estimates of
software costs, but its accuracy is limited due to its lack of factors to account for
difference in project attributes.

6.2 Function Point Estimation

A function point is a unit of measurement to express the amount of business functionality

an information system provides to a user. Function points are the units of measure used
by the IFPUG Functional Size Measurement Method. The IFPUG FSM Method is an ISO
recognised software metric to size an information system based on the functionality that
is perceived by the user of the information system, independent of the technology used to
implement the information system.

The method of measuring the size of an information system and expressing it in a number
of function points is called function point analysis (FPA). The method is kept up to date by
worldwide cooperating FPA user groups like NESMA and IFPUG. A function point analysis
expresses the functional size of an information system in a number of function points (for
example: the size of a system is 314 FPs). There are many uses and benefits of function
points and the functional size may be used as input into many types of project and
organization decisions including determining the:

 Budget for application development or enhancement costs.

 Budget for the annual maintenance costs of the application portfolio.
 Project productivity after completion of the project.
 Software Size for cost estimating.

34
Function-Oriented Metrics

FP = count_total * [0.65 + 0.01 * sum of Fi]

1. Does the system require reliable backup and recovery=5

2. Are data communications required=4
3. Are there distributed processing functions=2
4. Is performance critical=5
5. Will the system run an existing, heavily utilized operational environment=5
6. Does system requires online data entry=5
7. Does online data entry req. input transaction to be build on multiple screens=3
8. Are master files updated online =4
9. Are I/ps , 0/ps, files and inquires complex=3
10.Is essential processing complex=5
11. Is code reusable=4
12.Are conversion and installation included in design=2
13.Is system supports multiple installations =2
14. Is application designed to facilitate change and ease of use by user=5

sum of Fi = 54

Measurement Count Simple Average Complex

Parameter
Number of 12 * 3 4 6 = 36
User Inputs
Number of 4 * 4 5 7 = 16
User outputs
Number of 1 * 3 4 6 = 6
User inquires
Number of 5 * 7 10 15 = 35
files
Number of 3 * 5 7 10 = 15
External
interface
Count Total 108

FP = Count_total * [0.65 + 0.01 * sum of Fi]

FP=108*[0.65 + 0.01 * 54]

FP=129

35
 7. Implementation Methodology

The methodology is basically your approach to solve the problem. This deals with the
process model used. A process model for software engineering is chosen based on the
nature of project and application, the methods and tools to be used, and the controls and
deliverables that are required. Hence looking at the objectives and goals of the system,
we have chosen spiral model for it.

7.1 Spiral Model:

The spiral model is a software development process combining elements of both
design and prototyping-in-stages, in an effort to combine advantages of top-down
and bottom-up concepts. Also known as the spiral lifecycle model (or spiral
development), it is a system’s development method (SDM) used in information
technology (IT). This model of development combines the features of the
prototyping model and the waterfall model. The spiral model is intended for large,
expensive and complicated projects.

 ADVANTAGES:
1. Estimates (i.e. budget, schedule, etc.) become more realistic as work
progresses, because important issues are discovered earlier.
2. It is more able to cope with the (nearly inevitable) changes that software
development generally entails.
3. Software engineers (who can get restless with protracted design processes) can
get their hands in and start working on a project earlier.

 DISADVANTAGES:
  1.Highly customized limiting re-usability
2.Applied differently for each application
3. Risk of not meeting budget or schedule

36
This model includes the following steps in the course of software development:

[SPIRAL MODEL]

7.2 Phases of Spiral Model:

7.2.1 Planning Phase:

 The planning phase 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 outputs of the project planning phase are the configuration

37
 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.

7.2.2 Risk Analysis Phase:

This phase is the most important part of "Spiral Model". In this phase all possible
(and available) alternatives, which can help in developing a cost effective project
are analyzed and strategies are decided to use them. This phase has been added
specially in order to identify and resolve all the possible risks in the project
development. If risks indicate any kind of uncertainty in requirements, prototyping
may be used to proceed with the available data and find out possible solution in
order to deal with the potential changes in the requirements.

7.2.3 Engineering Phase:

This phase which includes 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.

7.2.4 Customer Evaluation Phase:

 During the construction phase 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.

38
 8. Preliminary Design

8.1 Use Case

e-Banking for Online Banking System Application 1.0 will address the following use cases.
The complete usage scenarios will be completed during the information-gathering
process. Use cases will be created and prioritized. Selected use cases will be expanded
into usage scenarios and features that are derived from both use cases and the usage
scenarios, as represented in the following diagram:
[e-Banking Usage Scenario – This usage scenario, or scenario for short, describes a real-
world example of how one or more people or organizations interact with e-Banking
application.  It describe the steps, events, and/or actions which occur during the
interaction.  This Usage scenarios indicating exactly how someone works with the user
interface, or reasonably high level describing the critical business actions but not the
indicating how they’re performed.  ]

8.2 Specification of actors

The following actors are defined so far in the analysis phase of the e-Banking Application
for Online Banking System development process.

8.2.1 Customer
Customer
Element Details

Description Customer is a person and having rights to access e-Banking system

Examples User logged in into system and view mini statement

8.3 Specification of Use Cases

8.3.1 Use Case View Mini Statement
View Mini Statement
Element Details

Actor Customer
Trigger Customer wants to view mini statement.

39
View Mini Statement
Element Details

Pre Conditions Actor having rights to access e-Banking system

Post Conditions Mini Statement is displayed
Normal course 1. Actor login into system
2. Actor select account to view statement.
3. System display last 10 transcation
Alternative courses 3a. Not all mandatory data fields are filled
3a1.User fills in the missing data fields

40
 9 ER Diagram

1 1
Falls In
User Groups

Customer I
S 1
Account Holder

M Manage
1
View

M M
Request
Statement Transact Account
ion
M 1
M
M
Have
Cheque Book Details

M
M

Debit and Credit

41
10 Schema Diagram

42
 11 Data Dictionary

11.1 Table: Account Master

11. 2 Table: Account Transaction

43
 12. Project Planning and Scheduling

12.1 Planning

Planning is very important in every aspect of development work. Software project plan
indicated scope of the project, milestones and deliverables, project estimates, resource
allocation, risk management, scheduling techniques and quality control and standard.
Software project plan can be viewed as the following:

12.2 User Interfaces

The use of Textbox and List box for accepting data. The input data are then stored in the
database. These data can also be retrieved from the database and displayed in the form
of tables.

12.3 Hardware Interfaces

Raw data inserted into this software are permanently stored in tables; hence processor
having free space will be useful for faster storage and retrieval of data. Here we have
used 3.6 GHz P4 processor, which will have an additional support for our software.

12.4 Software Interfaces

This software is operated in a WINDOWS XP environment. This will help for firewall
security provisions if the software is used along with internet connection.

12.5 Cost of Implementation

This project can be implemented in the organization in one to two weeks. The cost of this
project is derived from effort, hardware cost, travel expenses, training cost,
telecommunication costs etc.

44
12.6 Effort:
It includes the total number of manpower per months. As this project is completely
computerized hence less number of manpower will be used to successfully run this
project. At least 2-3 persons will be enough to maintain this project.

12.6.1. Hardware cost:

It includes 2 INTEL P4 Standalone Computers. Cost around 60,000.

12.6.2 Training Cost:

One Software personnel will be allotted for providing training to the manpower allotted

12.6.3 Project duration:

It will take complete 2 months for completion. After that it will take another 2-3 weeks
for implementation and testing. Another 1-2 weeks is kept in hand for any inconvenience.

12.6.4 With respect to the customer:

Weekly or timely meetings will be scheduled with the customers for getting time to time
feedback. These meetings will be accompanied with presentation reports. After getting
feedback further modifications and developments will be done.

45
12.7 Scheduling

Scheduling of a project can be correlated to prioritizing various jobs with respect to their
cost, time and duration. Scheduling can be done with resource constraint or time
constraint in mind.

12.8 Gantt chart:

P HA SE TI ME R EQU IRE D (I N W EE K S)

W K1 W K2 W K3 W K4 W K5 W K6

R EQU IR E ME NT
G ATHE R ING

R EQU IR E ME NT
AN ALYS IS

D E SIG N

C OD ING

TE STI NG

IMP LE ME NT A-
TION

46
12.9 Class Diagram

Transaction
* 1 CustInfo
 GenTranID()
 GetCust()
 UpdateTran()
 GetAcct(ID)
 ViewTran(ID)
 GetStatus(ID)

* 1

1
1
Payee

TramDetails
 GetPayee ()
 UpdatePayee()  UpdateTarn()
 ViewTran(ID)

47
 12.10 WBS – Work Breakdown Structure of e-Banking

e-Banking – Online Banking System

3 5 7 9
Mini Statement Payee Branch Search
Login & Change
Password
5.1
User Interface 7.1 9.1
3.1 User Interface Design
Coding
User Interface 5.2 Coding
Coding Handler Class 7.2 9.2
3.2 Testing
Coding Handler Class
Handler Class 5.3 Coding
Coding Testing 7.3
3.3 Testing
Testing
1 4 6 8
System Analysis Account View Statement Fund Transfer
Information

1.1 4.1 6.1 8.1

System User Interface User Interface
User Interface Coding Coding
Analysis
1.2 Coding 6.2 8.2
4.2 Handler Class
System Design Handler Class
Handler Class
Coding Coding
Coding 6.3 8.3
4.3 Testing Testing
Testing
Database & test
data creation 10

2.1 Integration & Testing

Database creation

2.2 10.
Test data creation System Integration
1
10.
2 Integration Testing

Work Breakdown Structure (WBS)

48
 13 Interface

13.1 e-Banking Home Page

49
13.2 e-Banking Start Login

50
13.3 e-Banking Login

51
13.4 e-Banking My Account

52
13.5 e-Banking Mini Statement

53
13.6 e-Banking Statement Selection

54
13.7 e-Banking View Detail Statement

55
13.8 e-Banking Fund Transfer

56
13.9 e-Banking Fund Transfer (Own Account)

57
13.10 e-Banking Fund Transfer (Other Account)

58
13.11 e-Banking Add Payee

59
13.12 e-Banking Cheque Book Request

60
13.13 e-Banking Find Branch

61
13.14 e-Banking Change Password

62
 14. Test Plan

Introduction
This document describes the user acceptance test plan for the e-Banking application for
Online Banking System The complete test strategy for the e-Banking application for Online
Banking System is to perform the following kinds of tests, in sequence:

1. Component testing of each component that makes up the e-Banking application

for Online Banking System
2. Integration testing of the e-Banking application for Online Banking System, to
ensure the correct interworking of its components
3. Validation testing of the e-Banking application for Online Banking System, to
ensure that it works correctly in a pseudo-live environment
4. User acceptance testing of the e-Banking application for Online Banking System,
to ensure that its function is acceptable to its users

Acceptance testing is the last set of tests to be performed before the application goes
officially live.

14.1 Test Scope

The scope of the user acceptance testing covers:

 Version 1 of the e-Banking application for Online Banking System

 User-facing functionality defined by a set of use cases
 Administrator-facing functionality defined by a set of use cases

The aim of the testing is to determine how well the application meets its functional
requirements from the perspective of the user, and to identify any issues so they can be
resolved. Also, the testing serves to compile a set of test data and results that can be
used during subsequent test cycles, to test for non-regression of the software in later
releases or after the application is in maintenance.

Working practices might vary from user to user and are considered outside the scope of
the testing.

14.2 Test Strategy

The basis of user acceptance testing is that other tests were completed successfully, so
the application and its required infrastructure are considered to be stable and reliable.
Acceptance testing concentrates on the application from the user’s perspective, that is,
how the application is used and whether it meets the necessary quality criteria.

63
Change requests will be sent to the development team as the actionable documentation.
Change criteria will be determined by the Test team and the Development team prior to
the beginning of testing. For instance, criteria may include impact to desired functionality,
amount of code impacted by proposed change, and design required by proposed change.
The tester will evaluate the criteria. The test lead will determine Change Required or not.
Once a bug has been determined as Change Required, the bug report will be translated
into a Change Request and passed on to development.

The users of the acceptance testing is the System Users, and Administrator for e-Banking
application for Online Banking System The progress of the acceptance testing will be
reported to the customer, together with any issues that are discovered and their planned
resolutions. Sign-off of the tests, and therefore the acceptance of the application, will be
performed by the customer or a selected representative.

14.3 Preconditions
The following items are required before testing can take place:

 A complete and coherent functional specification of the e-Banking application for

Online Banking System expressed as use cases and usage scenarios
 A complete and validation-tested release of e-Banking application for Online
Banking System, delivered according to the delivery plan
 An agreed-upon procedure for dealing with any anomalies that are discovered
during the testing process
 A set of test specifications describing how each functional area of the e-Banking
application for Online Banking System is to be acceptance tested
 An implemented test environment for the testing
 Sufficient, suitable resources to carry out the testing
 Available standards for the acceptance testing

14.4 Test Priorities

During testing of the e-Banking application for Online Banking System, the following
qualities will be tested in order of priority:
 Functionality—whether the required functions are available and working as
expected
 Usability—how user-friendly and intuitive the e-Banking application for Online
Banking System is
 Security—how well-protected and guaranteed corporate and user data is
 Performance—whether the response times are within acceptable limits
 Customization—how straightforward it is to use the application in new, unpredicted
ways

64
14.5 Test Techniques
The following techniques will be applied:
 Scripted tests—sequences of user interactions (based on the use case and usage
scenarios) using predefined data sets against predicted results
 Unscripted tests—based on scripted tests, the tester tries to modify the scenarios
to explore what-if possibilities
 Penetration tests—scripted tests to attempt unauthorized entry into the system
 Usability checklists—tests to determine the complexity of interactions
 Performance statistics—generation of performance information to check against
desired performance criteria

14.6 Test Organization

Roles and Responsibilities
The following roles are defined:

 QA lead/test manager—responsible for planning and ensuring the smooth running

of the test process
 Tester—carries out the tests according to the test plan, and then reports the
results
 Product manager—ensures that the tests are carried out successfully from a user
perspective
 Project sponsor/client—acts as main stakeholder, and ensures that the needs of the
customer community as a whole are considered
 Test support—provides technical assistance, such as test environment
configuration, and non-technical assistance, such as methodological support

Weekly team meetings will be held involving the test manager, testers, and product
managers. At these meetings, the progress of the testing process will be reported, any
issues will be discussed, and actions will be agreed upon.

14.7 Deliverables
The following deliverables will be expected from the user acceptance testing process:

 Test plan—this document, together with any updates that have occurred during the
testing process
 Change requests—any bugs, defects, or other changes required to the e-Banking
application for Online Banking System as a result of the testing process
 Weekly reports—progress reports to enable the status of the testing process to be
determined
 Completion report—a report to be signed off by the customer, to signify the
successful completion of the user acceptance testing

65
14.8 Test Environment
Hardware and Software
The test environment will consist of:

Server

A single Intel-based computer running:

 Microsoft Windows
 E-Banking application for Online Banking System components

Client Workstations

Two Intel-based client laptop computers, each running:

 Microsoft Windows XP Professional

 Microsoft Office
 Internet Explorer 6 or greater

The following additional hardware will be required:

 One laser printer to print reports

 One color printer (laser or inkjet) to print screen dumps
 One CD-ROM drive to enable clean installation of the e-Banking application for
Online Banking System
 Networking connectivity to permit interconnection of the server, clients.

14.9 Testing Automation Software

No testing automation software packages are selected at present.

14.10 Application Configuration

The following user accounts will be configured on the server:

 System Administrator
 System Users 1
 System Users 2
 Client 1
 Client 2

66
 15. Future Enhancement

This project was developed to fulfill user requirement; however there are lots of scope to
improve the performance of the e-Banking application for Online Banking System in the
area of user interface, database performance, and query processing time. Etc.

So there are many things for future enhancement of this project. The future
enhancements that are possible in the project are as follows.

 SMS and Email alert facilities

 Allow customer to make bill payment
 Connection to third-party OLAP applications
 In the area of data security and system security.
 Provide more online tips and help.
 To optimize the query which is embedded in the system.

67
 16. Bibliography

16.1 Websites
Following websites are referring to create this project reports.
 http://www.google.com
 http://www.microsoft.com
 http://www.programmer2programmer.net
 http://www.codeproject.com
 http://www.asp.net
 http://www.asp123.com
 http://www.wikipedia.org

16.2 Books
Following books and e-book are used to complete this project reports.
 Mastering C# (Paperback)
 SQL Server Bible (Paperback)
 .NET Black Book (Paperback)
 Professional C#, 2nd Edition (Paperback)
 Professional ASP.NET (Paperback)
 MCAD/MCSD Self-Paced Training Kit: Developing Web Applications with Microsoft®
Visual Basic® .NET and Microsoft Visual C#® .NET, Second Edition
 MCAD/MCSE/MCDBA Self-Paced Training Kit: Microsoft SQL Server 2000 Database
Design and Implementation, Exam 70-229, Second Edition

68