Contents

1. Abs tr act

2. O r ganiz ational Pr ofile

3. Softw ar e D evelopm ent Methodology

4. Intr oduction

4.1 Pur pos e.

4.2 Scope

4.2.1 Exis ting sys tem with lim itations

4.2.2 Pr opos ed s ys tem featur es

4.3 Acr onym s and Abbr eviations

5. O ver all D es cr iption

5.1 U s er char acter is tics

5.2 Pr oduct Functions

6. Specifi cation r equir em ents

6.1 H ar dwar e requir em ents

6.2 Softwar e r equir em ents

6.3 U s er Inter face r equir em ents

7. Behavior al D es cr iption

7.1 D ata Flow.

7.1.1 D ata Flow D iagr am s

7.1.2 U s e-Cas e Docum entation

 7.2 Pr oces s Flow

7.2.1 Sys tem flow Char t

7.2.2 Activ ity D iagr am s

8. Functional D es cr iption

9. Per for m ance Requir em ents

10. D es ign

10.1 Sequence and Collabor ation D iagr ams

10.2 Clas s D iagr am s

10.3 E- R D iagr am s

11. Sam ple Code

12. Sys tem T es ting and Im plem entation

13. Scr eens

14. C onclus ion

15. Bibliogr aphy

 ABSTRACT
The main objective of our project is to provide more security while performing
online transaction by providing efficient authentication etc. In the existing system, we can
perform all the operations using a single user id and password. Once this password is stolen, it is
easy for the others to access all the operations like transfer of money etc., so that the customer
could pay a huge loss. Thus it is not secured up to mark. In our project, we provide much
security to the customer while using the online banking service in the following ways. The
customer using the online banking service would be given user id along with two other
passwords. One called Login Password and the other called transaction password. By using login
password the customer can login to be account and we can perform only some (limited)
operations like viewing A/C balance and personal details etc. But to perform transfer or online
transaction, the user needs to provide the transaction password and other secure information in
order to complete the transaction successful.

If the customer login password and id is stolen by someone else, he can see the details but he
can’t perform online transaction or transfer. Apart from the transaction password the customer
needs to get verified by providing the grid values present on is debit card which would be asked
randomly. So there is no chance for the person whose steals the password details to make
transaction because he also needs to enter the values which are present on the customer’s debit
card.

Number of Modules:

The system after careful analysis has been identified to be presented with the following modules:
The Modules involved are

1. Admin.
2. User
3. Registration
4. Security and Authentication
 SOFTWARE DEVELOPMENT METHODOLOGY:
The methodology used to develop this project is object-oriented methodology is
based on function and procedures. It can be said as the development of software by building self-
contained modules as objects that can be easily replaced, modified and reused. In this
environment software is a collection of discrete objects that encapsulate their data as well as the
functionality to model real world “objects”. Each object has attribute and methods. Objects are
grouped into classes. Here each object is responsible for itself.

This environment emphasizes its cooperative philosophy by allocating tasks

among the objects of the applications. Instead of writing a lot of code we can create a lot of code
we can create a lot of helps to take in an active role.

Object oriented methodology involves mainly

1. Analysis

2. Design

3. Prototyping and testing.

ANALYSIS:

There are 5 important steps in the analysis. They are

1. Identification of the users/actors.

2. Development a simple business process model.
3. Developing the use cases.
4. Developing the interaction diagrams.
5. Classifications.
SOFTWARE METHDOLOGY:
Using JACOBSON METHDOLOGIES to develop the proposed system.
INTRODUCTION:
In 1986 BOOCH developed the Object Oriented Design concept is called as
BOOTCH METHOD. It covers both analysis and Design phases of the Object Oriented System,
The BOOTCH METHOD consists o following diagrams:

 Class diagrams
 Object diagrams
 State transition diagram
 Module diagram
 Process diagram
 Interaction diagram
BOOTCH used the large set of symbols. Even though BOOTCH defines a lot of symbols to
document almost every design decision, if we work with his method, you will notice that you
never use all these symbols and diagrams; this is this main drawback of the BOOTCH
METHOD. In 1991 Jim Raumbaugh develop the OMT (Object Modeling Technique) with the
help of his team It covers analysis, Design and implementation of the system.

OMT separates Modeling into three different parts:

 Object Model
Presented by the Object Model and the data dictionary.
 Dynamic model
Presented by the State diagrams and Event flow diagrams.

 Functional Model

Presented by Data flow and constraints.

There is no traceability in the different phases, both forward and back ward; this is the main
disadvantage of the OMT.
 In order to avoid the problems faced in the above two models JACOBSON invented the one
model called as the JACOBSON METHDOLOGIES (Object Oriented Software Engineering). It
will cover the entire life cycle and stress tractability between different phases, 0both forward and
back ward, Additionally he invented the Use case diagrams, these diagrams are necessary to
understanding system requirement. It captures the goal of the system. It is used to identify the
Use cases and External users (external users are the users who interact with our system to
complete the task)

THE JACOBSON ET AL. METHDOLOGIES:

JACOBSON METHDOLOGIES (Object Oriented Software Engineering) OOSE cover the

Entire life cycle and stress trace ability between the different phases, both forward and backward.
And Use case diagrams, these diagrams are necessary to understanding system requirement. It
captures the goal of the system. It is used to identify the USE CASES and External users
(external users are the users who interact with our system to complete the task)

The Use case Description must contain

 HOW and WHEN the use case begins and ends.

 The interaction between the use case and its actors, including WHEN the
interaction occurs and WHAT is exchanged.
 HOW and WHEN the use case will need data stored in the system or will store
data in the system.
 EXCEPTION TO THE flow of events
 HOW and WHEN concepts of the problem domain are handled.

By using the use case model we will find the External users, External users are the users who
will interact with our system to complete the task. Every single use case should describe one
main flow of events. An exceptional additional flow of events could be added.
 OBJECT ORIENTED SOFTEWARE ENGINEERING

Object oriented software engineering also called, as the objector. It is build around several
models:

USE CASE MODEL: The use-case model defines the outside (actor) and
inside (use case) of the systems behavior.

DOMAIN OBJECT MODEL: The objects of the “real” world are

mapped in to the main object model.

ANALYSS OBJECT MODEL: The analysis object model presents how

the source code (implementation) is carried out and written.

IMPLIMENTATON MODEL: The implementation model represents the

implementation of the system.
TEST MODEL: The test model constitutes the test plan, specification and reports

JACOBSON METHDOLOGY consists o following diagrams:

 Use case Diagrams

 UML activity diagram
 UML use Case Diagram
 Sequence diagrams
 Class diagrams
  Business class diagram

USE CASE DIAGRAMS:

A use case describes a sequence of actions that provide something of measurable

value to an actor and is drawn as a horizontal ellipse an actor is a person, organization, or
external system that plays a role in one or more interactions with your system.

UML ACTIVITY DIAGRAM:

Activity diagrams are used to document workflows in a system, from the business level
down to the operational level. When looking at an Activity diagram, you'll notice elements from
state diagram, the Activity diagram is a variation of the state diagram where the "states"
represent operations, and the transitions represent the activities that happen when the operation is
complete. The general purpose of Activity diagrams is to focus on flows driven by internal
processing vs. external events.

SEQUENCE DIAGRAMS:

UML sequence diagrams model the flow of logic within your system in a visual
manner, enabling you both to document and validate your logic, and are commonly used for both
analysis and design purposes.  Sequence diagrams are the most popular UML artifacts for
dynamic modeling, which focuses on identifying the behavior within your system.

CLASSDIAGRAMS:
A class diagram describes the static structure of the symbols in your new system.
It is a graphic presentation of the static view that shows a collection of declarative (static) model
elements, such as classes, types, and their contents and relationships. Classes are arranged in
hierarchies sharing common structure and behavior, and are associated with other classes

USE CASE DIAGRAMS:

Its purpose is to define Piece of behavior. It describes both inside (use case) and outside (actor)

Behavior of the system. It describes what a system does.

These diagrams consist of:

 Use cases
 Actors
A use case is the specification of sequences of actions, including variant sequences and error
sequences, which a system, subsystem or a class can perform by interacting with outside actors.

An actor may be anything that interact with the system, human, hardware device or another
system etc.

Scope

Existing system with limitations:

In the existing system, we can perform all the operations using a single user id password. Once
this password is stolen it is easy for the others to access all the operations like transfer of money
etc. Till now the password will be set by the user and will be reset depending upon the
requirement of the user which can be easily hacked and there is no good security for your
mailing service

So that the customer could pay a huge loss. Thus it is not secured up to mark.

Proposed system feature:

In our project, we provide much security to the customer while using the online banking service
in the following ways.

The customer using the online banking service would be given user id along with
two other passwords. One called Login Password and the other called transaction password.

By using login password the customer can login to be account and we can perfume
only some (limited) operations like saving A/C balance and personal details etc.
 But to perform transfer or online transaction, he needs to provide the transaction
password.

If the customer login password and id is stolen by someone else, he can see the
details but he can’s perfume online transaction or transfer. Apart from the transaction password
the customer needs to get verified by providing the grid values present on is debit card which
would be asked randomly

So there is no chance for the person whose steals the password details to make
transaction because he also needs to enter the values which are present on the customer’s debit
card

In the proposed system we will be able to provide an opportunity for the user to make the
mailing service to be highly secured by generating a random password each and every time he
wants to logon and encrypted random password will be forwarded to the Personal mail id of the
user where will be giving a link to forward his decrypted password to the mail.

Acronyms and Abbreviations:

ACC:Account

Pwd:password

Uid:user id

Facc:From Account

Tacc:To Account

Overall Description:
Specification requirements:

Software requirements :
  Front End : C# 2008
 Data Base : SQL Server 2005
 Technology : .Net

Hardware Requirements:

 Hard disk : 80GB Min.

 RAM : 512 MB Min. & Above
 Processor : Intel Pentium-IV and above

User Interface requirements:

WindowsXP and above

ASP.NET,C#,MS SQL,

DATA FLOW
1) A Data Flow has only one direction of flow between symbols. It may flow in both
directions between a process and a data store to show a read before an update. The
later is usually indicated however by two separate arrows since these happen at
different type.
2) A join in DFD means that exactly the same data comes from any of two or more
different processes data store or sink to a common location.
3) A data flow cannot go directly back to the same process it leads. There must be at
least one other process that handles the data flow produce some other data flow
returns the original data into the beginning process.
4) A Data flow to a data store means update (delete or change).
5) A data Flow from a data store means retrieve or use.
A data flow has a noun phrase label more than one data flow noun phrase can appear on a single
arrow as long as all of the flows on the same arrow move together as one package.

A data flow diagram is graphical tool used to describe and analyze movement of data through a
system. These are the central tool and the basis from which the other components are developed.
The transformation of data from input to output, through processed, may be described logically
and independently of physical components associated with the system. These are known as the
logical data flow diagrams. The physical data flow diagrams show the actual implements and
movement of data between people, departments and workstations. A full description of a system
actually consists of a set of data flow diagrams. Using two familiar notations Yourdon, Gane
and Sarson notation develops the data flow diagrams. Each component in a DFD is labeled with
a descriptive name. Process is further identified with a number that will be used for
identification purpose. The development of DFD’s is done in several levels. Each process in
lower level diagrams can be broken down into a more detailed DFD in the next level. The lop-
level diagram is often called context diagram. It consists a single process bit, which plays vital
role in studying the current system. The process in the context level diagram is exploded into
other process at the first level DFD.

The idea behind the explosion of a process into more process is that understanding at one
level of detail is exploded into greater detail at the next level. This is done until further
explosion is necessary and an adequate amount of detail is described for analyst to understand
the process.

Larry Constantine first developed the DFD as a way of expressing system requirements
in a graphical from, this lead to the modular design.

A DFD is also known as a “bubble Chart” has the purpose of clarifying system
requirements and identifying major transformations that will become programs in system design.
So it is the starting point of the design to the lowest level of detail. A DFD consists of a series of
bubbles joined by data flows in the system.

Data Flow Diagrams

DFD SYMBOLS:
In the DFD, there are four symbols

1. A square defines a source(originator) or destination of system data

2. An arrow identifies data flow. It is the pipeline through which the information flows
3. A circle or a bubble represents a process that transforms incoming data flow into outgoing
data flows.
4. An open rectangle is a data store, data at rest or a temporary repository of data

Process that transforms data flow.

Source or Destination of data

Data flow

Data Store
CONSTRUCTING A DFD:

Several rules of thumb are used in drawing DFD’s:

1. Process should be named and numbered for an easy reference. Each name should be
representative of the process.
2. The direction of flow is from top to bottom and from left to right. Data traditionally flow
from source to the destination although they may flow back to the source. One way to indicate
this is to draw long flow line back to a source. An alternative way is to repeat the source symbol
as a destination. Since it is used more than once in the DFD it is marked with a short diagonal.
2. When a process is exploded into lower level details, they are numbered.
3. The names of data stores and destinations are written in capital letters. Process and dataflow
names have the first letter of each work capitalized

A DFD typically shows the minimum contents of data store. Each data store should contain all
the data elements that flow in and out.

Questionnaires should contain all the data elements that flow in and out. Missing interfaces
redundancies and like is then accounted for often through interviews.

SAILENT FEATURES OF DFD’s:

1. The DFD shows flow of data, not of control loops and decision are controlled
considerations do not appear on a DFD.
 2. The DFD does not indicate the time factor involved in any process whether the dataflow
take place daily, weekly, monthly or yearly.
3. The sequence of events is not brought out on the DFD.

RULES GOVERNING THE DFD’S

PROCESS
1) No process can have only outputs.
2) No process can have only inputs. If an object has only inputs than it must be a sink.
3) A process has a verb phrase label.
DATA STORE

1) Data cannot move directly from one data store to another data store, a process must
move data.
2) Data cannot move directly from an outside source to a data store, a process, which
receives, must move data from the source and place the data into data store
3) A data store has a noun phrase label.
SOURCE OR SINK

The origin and /or destination of data.

1) Data cannot move directly from a source to sink it must be moved by a process
2) A source and /or sink has a noun phrase land

Design
Sequence and Collaboration Diagrams:

Administrator Sequence diagram:

 Administrator System Database

Enter login & password Conforming pin

Valid pin

Successfully login

Rigister the customer

update

Succcessfully

View reports
Riports
Display the

View total no.of

Check total no.of customer
Display no.of

Logout

Logout successfully

User Sequence diagram:

 User System Database

Enter login id & Conforming password

Vallid password

Successfully login

Enter acc no verify acc no

Enter amount valid acc no

Amount

Enter transaction id

Transaction id is
Verifying

Vallid

Enter grid values

Grid values is

Verifing

Verified

Transaction completed

Check balence Amount details

Current balence

Display balnce

Logout

Logout successfully

10.2 Usecase Diagrams

 Log in

Rigister

Enter user id

Enter login password

Bank admin Customer

Check balence

Change password

Change profile

View profile

View total no.of customers

View total amount

Transaction

Update amount

log out

System Testing and Implementation

TESTING :

Testing Concepts

 Testing

 Testing Methodologies

 Black box Testing:

 White box Testing.
 Gray Box Testing.

 Levels of Testing

 Unit Testing.
 Module Testing.
 Integration Testing.
 System Testing.
 User Acceptance Testing.

 Types Of Testing

Smoke Testing.
 Sanitary Testing.
 Regression Testing.
 Re-Testing.
 Static Testing.
 Dynamic Testing.
 Alpha-Testing.
 Beta-Testing.
 Monkey Testing.
 Compatibility Testing.
 Installation Testing.
 Ado Testing.
 Ext….
  TCD (Test Case Documentation

SLC

 Test Planning.
 Test Development.
 Test Execution.
 Result Analysis.
 Bug-Tracing.
 Reporting.

 Microsoft Windows – Standards

 Manual Testing

 Automation Testing (Tools)

 Win Runner.
 Test Director.

TESTING:
  The process of executing a system with the intent of finding an error.
 Testing is defined as the process in which defects are identified, isolated, subjected
for rectification and ensured that product is defect free in order to produce the
quality product and hence customer satisfaction.
 Quality is defined as justification of the requirements
 Defect is nothing but deviation from the requirements
 Defect is nothing but bug.
 Testing --- The presence of bugs
 Testing can demonstrate the presence of bugs, but not their absence
 Debugging and Testing is not the same thing!
 Testing is a systematic attempt to break a program or the AUT
 Debugging is the art or method of uncovering why the script /program did not
execute properly.

Testing Methodologies:

 Black box Testing: is the testing process in which tester can perform testing
on an application without having any internal structural knowledge of
application.
Usually Test Engineers are involved in the black box testing.

 White box Testing: is the testing process in which tester can perform testing
on an application with having internal structural knowledge.
Usually The Developers are involved in white box testing.

 Gray Box Testing: is the process in which the combination of black box and
white box tonics are used.
Levels of Testing:

Module1 Module2 Module3

Units Units Units

I/p Integration o/p I/p Integration o/p

System Testing: Presentation + business +Databases

UAT: user acceptance testing

STLC (SOFTWARE TESTING LIFE CYCLE)

Test Planning
1.Test Plan is defined as a strategic document which describes the procedure how to
perform various testing on the total application in the most efficient way.

2. This document involves the scope of testing,

3. Objective of testing,
 4. Areas that need to be tested,

5. Areas that should not be tested,

6. Scheduling Resource Planning,

7. Areas to be automated, various testing tools

Used….

Test Development: 1. Test case Development (check list)

2. Test Procedure preparation. (Description of the

Test cases)

Test Execution: 1. Implementation of test cases. Observing the result.

Result Analysis: 1. Expected value: is nothing but expected behavior

Of application.

2. Actual value: is nothing but actual behavior of

application

Bug Tracing: Collect all the failed cases, prepare documents.

Reporting: Prepare document (status of the application)

Types of Testing:

> Smoke Testing: is the process of initial testing in which tester looks for the
availability of all the functionality of the application in order to perform detailed testing
on them. (Main check is for available forms)

> Sanity Testing: is a type of testing that is conducted on an application initially to

check for the proper behavior of an application that is to check all the functionality are
available before the detailed testing is conducted by on them.

> Regression Testing: is one of the best and important testing. Regression testing is
the process in which the functionality, which is already tested before, is once again tested
whenever some new change is added in order to check whether the existing functionality
remains same.

>Re-Testing: is the process in which testing is performed on some functionality which

is already tested before to make sure that the defects are reproducible and to rule out the
environments issues if at all any defects are there.

Static Testing: is the testing, which is performed on an application when it is not been
executed.ex: GUI, Document Testing

Dynamic Testing: is the testing which is performed on an application when it is being

executed.ex: Functional testing.

Alpha Testing: it is a type of user acceptance testing, which is conducted on an

application when it is just before released to the customer.
 Beta-Testing: it is a type of UAT that is conducted on an application when it is
released to the customer, when deployed in to the real time environment and being
accessed by the real time users.

 Monkey Testing: is the process in which abnormal operations, beyond capacity

operations are done on the application to check the stability of it in spite of the users
abnormal behavior.

Compatibility testing: it is the testing process in which usually the products are tested
on the environments with different combinations of databases (application servers,
browsers…etc) In order to check how far the product is compatible with all these
environments platform combination.

Installation Testing: it is the process of testing in which the tester try to install or try to
deploy the module into the corresponding environment by following the guidelines
produced in the deployment document and check whether the installation is successful or
not.

Ado Testing: Ado Testing is the process of testing in which unlike the formal testing
where in test case document is used, without that test case document testing can be done
of an application, to cover that testing of the future which are not covered in that test case
document. Also it is intended to perform GUI testing which may involve the cosmetic
issues.
TCD (Test Case Document):

Test Case Document Contains

 Test Scope (or) Test objective

 Test Scenario
 Test Procedure
 Test case

This is the sample test case document for the Academic details of student project:

Test scope:

 Test coverage is provided for the screen “ Academic status entry” form of a
student module of university management system application
 Areas of the application to be tested

Test Scenario:

 When the office personals use this screen for the marks entry, calculate the status
details, saving the information on student’s basis and quit the form.

Test Procedure:
 The procedure for testing this screen is planned in such a way that the data entry,
status calculation functionality, saving and quitting operations are tested in terms
of Guy testing, Positive testing, Negative testing using the corresponding Guy test
cases, Positive test cases, Negative test cases respectively

Test Cases:

 Template for Test Case

Techno Description Exp Act Result

Guidelines for Test Cases:

1. GUI Test Cases:

 Total no of features that need to be check

 Look & Feel
 Look for Default values if at all any (date & Time, if at all any require)
 Look for spell check

Example for Guy Test cases:

 Techno Description Expected Actual value Result
value
Check for all the The screen
features in the must
1
screen contain all
the features
Check for the The
alignment of the alignment
2
objects as per the should be
validations in proper
way

2.Positive Test Cases:

 The positive flow of the functionality must be considered
 Valid inputs must be used for testing
 Must have the positive perception to verify whether the requirements are
justified.

Example for Positive Test cases:

Techno Description Expected value Actual value Result

1 Check for the The date and
date Time Auto time of the
Display system must be
displayed
2 Enter the valid It should accept
Roll no into the
student roll no
 field

 Negative Test Cases:

 Must have negative perception.

 Invalid inputs must be used for test.

Example for Negative Test cases:

Techno Description Expected Actual value Result

value
1 Try to modify Modification
The information should not be
in date and time allow
2 Enter invalid It should not
data in to the accept invalid
student details data, save
form, click on should not
save allow

System Testing and Implementation

Testing Concepts

 Testing

 Testing Methodologies

 Black box Testing:

 White box Testing.
 Gray Box Testing.

 Levels of Testing
 Unit Testing.
 Module Testing.
 Integration Testing.
 System Testing.
 User Acceptance Testing.

 Types Of Testing
 Smoke Testing.
 Sanitary Testing.
 Regression Testing.
 Re-Testing.
 Static Testing.
 Dynamic Testing.
  Alpha-Testing.
 Beta-Testing.
 Monkey Testing.
 Compatibility Testing.
 Installation Testing.
 Ado Testing.
 Ext….
 TCD (Test Case Documentation)
 STLC
 Test Planning.
 Test Development.
 Test Execution.
 Result Analysis.
 Bug-Tracing.
 Reporting.
 Microsoft Windows – Standards
 Manual Testing
 Automation Testing (Tools)
 Win Runner.
 Test Director
.

Testing:
  The process of executing a system with the intent of finding an error.
 Testing is defined as the process in which defects are identified, isolated, subjected
for rectification and ensured that product is defect free in order to produce the
quality product and hence customer satisfaction.
 Quality is defined as justification of the requirements
 Defect is nothing but deviation from the requirements
 Defect is nothing but bug.
 Testing --- The presence of bugs
 Testing can demonstrate the presence of bugs, but not their absence
 Debugging and Testing is not the same thing!
 Testing is a systematic attempt to break a program or the AUT
 Debugging is the art or method of uncovering why the script /program did not
execute properly.

Testing Methodologies:

 Black box Testing: is the testing process in which tester can perform testing on
an application without having any internal structural knowledge of application.
Usually Test Engineers are involved in the black box testing.

 White box Testing: is the testing process in which tester can perform testing on
an application with having internal structural knowledge.
Usually the Developers are involved in white box testing.

 Gray Box Testing: is the process in which the combination of black box and
white box techniques are used.
Levels of Testing:

Module1 Module2 Module3

Units Units Units

I/p Integration o/p I/p Integration o/p

System Testing: Presentation + business +Databases

UAT: user acceptance testing

Sample Code
Transfer:
SqlConnection con = new SqlConnection("user
id=sa;password=amith;database=bank");
SqlCommand cmd;
SqlDataReader dr;
int curbal = 0;
cmd = new SqlCommand("select userbalance from customer where userid =
'"+Session["uname"].ToString()+"'",con);
con.Open();
dr = cmd.ExecuteReader();

if (dr.Read())
{

curbal = Convert.ToInt32(dr[0].ToString());
}
con.Close();

if (Convert.ToInt32(TextBox2.Text) > curbal)

{
Label1.Text = "Insufficient balance";
}
else
{
cmd = new SqlCommand("select tpwd from login where userid='" +
Session["uname"].ToString() + "'", con);
con.Open();
dr = cmd.ExecuteReader();
if (dr.Read())
{
if (TextBox3.Text == dr[0].ToString())
{
Session["a"] = TextBox1.Text;
Session["b"] = TextBox2.Text;
Session["c"] = curbal;
//Session["uname"] = TextBox1.Text;
Response.Redirect("gridform.aspx");
}

else
{
Label1.Text = "Invalid Transaction Password";
}

con.Close();
}
}

Register:
 da = new SqlDataAdapter("select accno from customer",con);
DataSet ds = new DataSet();
da.Fill(ds,"x");
if (ds.Tables[0].Rows.Count == 0)
{
nacno = "10000001";
TextBox1.Text = nacno;
}
else
{
int k = ds.Tables[0].Rows.Count;

string acno = ds.Tables[0].Rows[k - 1].ItemArray[0].ToString();

nacno = (Convert.ToInt32(acno) + 1).ToString();
TextBox1.Text = nacno;
}
}
protected void Button1_Click(object sender, EventArgs e)
{
if (RadioButton1.Checked)
{
gender = "Male";
}
else
{
gender = "Female";
}

string db = DropDownList1.SelectedItem.ToString() + "/" +

DropDownList2.SelectedItem.ToString() + "/" +
DropDownList3.SelectedItem.ToString();

con.Open();

cmd = new SqlCommand("insert into customer

values('"+TextBox1.Text+"','"+TextBox2.Text+"','"+TextBox3.Text+"','"+gender+"
','"+db+"','"+TextBox4.Text+"','"+TextBox5.Text+"','"+TextBox6.Text+"','"+Text
Box7.Text+"','"+TextBox8.Text+"','"+TextBox9.Text+"','"+TextBox10.Text+"','"+T
extBox11.Text+"')", con);
cmd.ExecuteNonQuery();
con.Close();

Random r = new Random();

string[] grid = new string[6];
for (int i = 0; i < 6; i++)
{
grid[i] = r.Next(10,99).ToString();
}
con.Open();
cmd = new SqlCommand("insert into login values('" + TextBox11.Text +
"','" + TextBox11.Text + "','" + TextBox11.Text + "','" + grid[0] + "','" +
grid[1] + "','" + grid[2] + "','" + grid[3] + "','" + grid[4] + "','" +
grid[5] + "')", con);
cmd.ExecuteNonQuery();
con.Close();
Label1.Text = "Registration Successfully completed";
TextBox1.Text = "";
TextBox2.Text = "";
TextBox3.Text = "";
TextBox4.Text = "";
TextBox5.Text = "";
TextBox6.Text = "";
TextBox7.Text = "";
TextBox8.Text = "";
TextBox9.Text = "";
TextBox10.Text = "";
TextBox11.Text = "";

}
View Transactions:

protected void Page_Load(object sender, EventArgs e)

{
SqlConnection con = new SqlConnection("user
id=sa;password=amith;database=bank");
SqlDataAdapter da = new SqlDataAdapter("Select * from [transaction]
where facc = '" + Session["uname"].ToString() + "'", con);
DataSet ds = new DataSet();
da.Fill(ds);
GridView1.DataSource = ds.Tables[0];
GridView1.DataBind();
}
Screens
Conclusion:
Here we provide security and authentication for the online banking
account ,t he customer using the online banking service would be given user id along
with two other passwords. One called Login Password and the other called transaction
password. By using login password the customer can login to be account and we can
perform only some (limited) operations like viewing A/C balance and personal details
etc. But to perform transfer or online transaction, the user needs to provide the transaction
password and other secure information in order to complete the transaction successful.