Acknowledgment

In preparation for my mini-project, I had to take the help and guidance of some respected
persons, who deserve my deepest gratitude. As the completion of this project gave me
much pleasure, I would like to show my gratitude Amit sir, Course Instructor, for giving
me good guidelines for this project throughout numerous consultations. I would also like
to expand my gratitude to all my classmates those who have directly and indirectly
guided me in this project.

Many people, especially my classmates have made valuable comment suggestions on my

paper which gave me the inspiration to improve the quality of the assignment.
Table of Contents
Introduction ................................................................................................................................................ 1
Profile of the problem ...................................................................................................................................2
Existing System .............................................................................................................................................. 3
Problem Analysis .......................................................................................................................................... 4
Software Requirement Analysis ...................................................................................................................7
Design ........................................................................................................................................................... 13
Table and its Relationship .......................................................................................................................... 14
Testing ......................................................................................................................................................... 17
Gantt chart ................................................................................................................................................... 23
Bibliography................................................................................................................................................. 25
 Introduction

The topic “ATM” has been chosen keeping the functions of an ATM machine and kiosk in
mind. When we swipe our card through the machine, we are able to extract all the relevant
information of our account. A same attempt has been made through this application to
simulate those functions:

1. I have devised a menu-driven program that lets the user view his last account
activity combined with deposit & withdrawal of money from his account.
2. Before the starting of this application, we have assumed that the account
information of 50 users would be stored by our application and the variables like
account balance, deposit & withdrawal would be initialized in the very beginning
to give a good look & feel of the application.
3. As the application starts, we assume that the user swipes his ATM debit card which
is effectively read by the machine though this is performed through the human input
because we are not integrating any such reader with our application.
4. After that the user, enters his/her secret pin no. which is accepted by the system in
the form of a password. If the card no. which we are eventually assuming as the
account number entered manually by the user matches the pin no., the user is
redirected to the menu where he can see all the details related to his account and
can also do any account activity according to his desires.
5. After that the user, enters his/her secret pin no. which is accepted by the system in
the form of a password. If the card no. which we are eventually assuming as the
account number entered manually by the user matches the pin no., the user is
redirected to the menu where he can see all the details related to his account and
can also do any account activity according to his desires.

PAGE 1
 Profile of the problem
1. Before making this application, we assumed that a fictitious bank which had
recently started its operations found it very difficult to handle their customers.
2. It was due to their great customer service and efficient handling of daily operations
that they customer base started growing and, in a day, they started to handle lot of
customer requests.
3. When this happened, the bank authorities realized that the customer had lot of
different queries but the most common ones was account information, deposit and
withdrawal of money.
4. Slowly & slowly the count of such customers started to grow very rapidly and the
bank employees had to devote their maximum time in handling such customers.
5. This resulted in large response times of the bank employees who found themselves
unable to give adequate time to some more important customers like NRIs or people
who were interested in opening a fresh account.
6. Slowly, the bank started loosing its important or gold customers due to poor
response times by the bank employees and they even started loosing those
customers whose requests could not be fulfilled.
7. After this, the bank decided to install a system that can effectively & efficiently
service the request of such customers and can the corresponding work of its
employees who were overburdened with such tasks.

PAGE 2
 Existing System
The next stage is to analyze the existing information system. The requirement analyst has
to identify the requirement by talking to people and understanding their needs.
In the existing system we have Customer, Project Manager aka Administrator. The project
manager has responsibilities include the following duties: -
 Maintaining customer records.
 Report Generation.
 Handling the enquiries.
Customer has following functionalities: -
 Opening Account
 Access the existing Account
 Withdraw
 Deposited

PAGE 3
 Problem Analysis

Product Definition:

The Automated Teller Machine ATM Banking System is a banking application

developed to perform different banking services through the Automated Teller Machines.
The all functions include the regular transactions like cash deposits, cash withdrawals,
balance enquiry, balance statements, savings account, and current account; change PIN
Number, Credit card Withdrawals and so on. The application design maintains the
information of the accounts of various customers including the information of the ATM
cards, their types Credit cards, Debit Cards and the transactions done by the customers
through the ATM machine centers with co-relation of the Banking Services.

The stored details also include the information of the various centers in and around the
ATM services, which help in the relational maintenance of every transaction in the ATM
Machine by the customers with their concerned branch operations.

PAGE 4
Feasibility Analysis:

When complex problems and opportunities are to be defined, it is generally desirable to

conduct a preliminary investigation called FEASIBILITY STUDY.

The outcome of the feasibility study is very clear. So, depending upon the aspect on which
feasibility is being done is categorized into following classes: -
 Technical feasibility
 Operational Feasibility

Technical Feasibility
In technical Feasibility, the following issues are taken into consideration:
 Whether the required technology is available or nor?
 Whether the required resources are available –
Manpower-programmers, testers and debuggers
Software/Hardware
Therefore, it is mainly concerned with the satisfying equipment i.e. hardware and software
that will successfully satisfy the user requirements. The technical needs of the system may
vary, but might include:
 The facility to produce outputs in a given time.
 Response time under certain conditions.
 Ability to process a certain volume of transaction at a particular speed.

After examining the technical feasibility, we give more importance to the configuration of
the system than the actual make of the hardware. The configuration gives the complete and
true picture of the system’s requirements.
The PC will have its own color monitor, keyboard and mouse. The computer system should
have enough speeds of input and output. The software, which has been used in the proposed
system, is C++. These soft wares are very popular and easily available in the market. The
system can be upgraded from time to time when new versions of software are available
from either the Internet or in the market.

PAGE 5
Operational Feasibility
For operational feasibility study we appointed a small group of people, which included the
Customers. This group worked with the new system and found that the system was very
user friendly, and very efficient. It was found that no special training was required to
operate the system. It takes about 5 minutes to enter the issue details as compared to the
30-40 minutes of the manual system.

System Requirements
To run this project successfully it is required that certain software and hardware
requirements should be kept in mind. Following are the requirements:

Hardware Requirements:
Ram: 256 M.B. or more
Processor: Pentium-III or above.
Hard Disk: 40GB or more.
Display: Any Color CRT or flat panel display
Any windows compatible mouse-pointing device.

Software Requirements:
Microsoft Windows XP operating system (with service pack 2 will be better).
C++ Running Environment
MS-Word for Documentation

PAGE 6
 Software Requirement Analysis

1) This was a subset of feasibility analysis in which we defined a set of objectives for the
complete system after thoroughly analyzing it.

2) All the objectives were further subdivided into a set of function(s).

3) The input(s) required by each function & the expected output(s)/behavior was/were
clearly defined.

4) The source of information/input to every function was determined & its corresponding
processing, usage & storage were also taken into account.

Choice of the Platform

S/W Used: C++ - 11 with Code::Blocks
The software for the ATM is written in Code::Blocks C++ 17.12, mainly because of its
suitability for this type of application. Its user-friendly nature and in-built documentation,
complication, error detection, binding facilities and interaction with other software
packages make it most powerful tool for software development. Moreover. gcc 5.1.0
consists of all the technologies that help in creating and running robust, scalable and
distributed packages.
C++ (called Object oriented Language) is based on some features which is mention below:

C++ is a general-purpose object-oriented programming language and is intended to be an

improved C with object capabilities.

1. Basic Concepts

In C++, an object is a region of storage with associated semantics. In the context of the
object model of C++, the term object refers to an instance of a class. A class defines the
characteristics of its instances in terms of members: data members (state) and member
functions (methods or operations), and the visibility of these members to other classes.
C++is statically typed.

PAGE 7
2. Objects

In C++, an object is a region of storage with associated semantics. The declaration int i;,
specifies that is an object of type int. In the context of the object model of C++, the term
object refers to an instance of class. Thus a class defines the behaviour of possibly many
objects (instances).Objects are usually referred to by references, which are aliases for an
object.

A C++ class definition generates a user-defined type. A class defines the characteristics of
its instances in terms of members: data members(state) and member functions (methods or
operations), and the visibility of these members to other classes. The class defines the form
of all objects that belong to that class. Each object of the class that is created gets copy of
all the class data members, except for those declared as static (see entry under state). All
objects of a particular class share the member functions for that class.

Operations

Operations are defined by functions. In the context of the C++ object model, functions may
be globally defined (independently of object classes), or as part of class definitions
(member functions). C++ essentially supports classical object model, in that member
functions are associated with the definition of a single object class. However, friend
functions may be defined that, though not part of a class' definition, have access to the
internals of instances of that class. See entry under 5. Encapsulation.

3. Binding

C++ supports both static and dynamic (run-time) binding of function invocations to object
member functions, depending on how the member functions were declared in class
definitions. In dynamic binding, binding occurs depending on the dynamic type of the
object whose member function is being invoked. The correct operation for that object will
be selected automatically by the run-time system. See also entries under methods

4. Polymorphism

PAGE 8
C++ supports polymorphism by allowing member functions defined in classes to be
overridden with member functions having the same names (operator overloading), but
different implementations, in derived classes (subclasses).In selecting the appropriate
member function to call in response to a function invocation, C++ distinguishes between
the static type of a reference and the dynamic type of the object it refers to at a given point.
The dynamic type must be a descendant of the static type. The invocations type-checked
based on the static type of the reference. If the function called is a virtual member function,
the member function associated with the actual object pointed to is called dynamically at
run time. If the function is non-virtual, the call will have been statically bound to the
member function of the reference's class at compile time.

5. Encapsulation

C++ provides three levels of protection for data members and member functions within a
class. The default protection level is private. A private data member or member function
cannot be accessed by any function that is not a member function of that class. The next
level of protection is protected. A protected data member or member function is accessible
only to other member functions of that class or from classes derived from that class. The
least restrictive level of protection is public. Public data members and member functions
can be accessed by any other function. The protection level of data members and member
functions is specified in the member declarations using the keywords public, protected, or
private.

public members of a C++ base class do not automatically become public members of the
derived class; the base class must be explicitly declared as public to allow this.

Specified non-member functions may be given access to private or protected parts of

classes. These functions are specified using the friend keyword and may be globally
defined functions or members of other classes. Whole classes may be declared as friends
of another class, in which case every member of the friend class can access the private
members of the specified class.

PAGE 9
7. Types and Classes

In C++, an object is a region of storage with associated semantics. The declaration int i;,
specifies that is an object of type int. In the context of the object model of C++, the term
object refers to an instance of class. Thus a class defines the behaviour of possibly many
objects (instances). Objects are usually referred to by references, which are aliases for an
object.

A C++ class definition generates a user-defined type. A class defines the characteristics of
its instances in terms of members: data members(state) and member functions (methods or
operations), and the visibility of these members to other classes. The class defines the form
of all objects that belong to that class. Each object of the class that is created gets copy of
all the class data members, except for those declared as static. All objects of a particular
class share the member functions for that class. If a class data member is defined with the
static keyword, that data member is shared by all objects of that class (there is only one
copy of the static data member).

C++ is a statically typed language. A class essentially defines a type, and a derived class
(subclass) is effectively a subtype. If a variable is of a type A, then it may only refer to
objects of class A or its derived classes (subclasses). When a subclass is declared, those
members which redefine members declared in a superclass must be declared in a way that
is consistent with the superclass declaration, in order to maintain substitutability of subclass
instances.

A class can be declared within another class; such a class is called a nested class. The name
of a nested class is local to its enclosing class. A class can also be declared within a function
definition; such a class is called a local class. The name of a local class is local to its
enclosing scope.

An abstract class is a class that can be used only as a base class of some other class; no
objects of an abstract class can be created except as objects representing a base class of a
class derived from it. Abstract classes support the notion of a general concept, such as

PAGE 10
shape, of which only more concrete variants, such as circle and square, can actually be
used. An abstract class can also be used to define an interface for which derived classes
provide a variety of implementations.

A class is abstract if it has at least one pure virtual function. Specifying a function in a base
class as virtual means that if a derived class contains a function with the same name and
having the same type, a call of that function for an object of the derived class always
invokes the function in the derived class, even though the invocation was through a pointer
or reference to the base class. In this case, the derived class function is said to override the
base class function. A virtual function is specified pure by specifying its implementation
as =0 in the function declaration in the class declaration.

C++ class templates provide a parameterized type facility (genericity). A class template
specifies how individual classes can be constructed. For example, an example vector class
template

The prefix template<class T>specifies that a template is being declared and that a type
name Twill be used in the declaration (i.e., that vector is a parameterized type with T as its
parameter).A class generated from a class template is called a template class. Examples
might be vector<int>, vector<complex>, etc. Such names can be used in the same way as
the names of ordinary classes.

8. Inheritance and Delegation

C++ supports multiple inheritance. Inheriting classes are called derived classes, and the
classes they inherit from are called base classes. The derived classes inherit all the data
members and member functions from the base class. The derived class may extend the base
class by adding new data members or member functions. The derived class may also
override member functions from the base class by supplying a new definition for the
function.

PAGE 11
There are two forms of derivation, public and private. When the declaration of a derived
class contains the keyword public preceding the base class name, objects of the derived
class can be treated as if they were instances of the base class. In particular, an object of
the derived class can be used to invoke member functions or access data members defined
for the base class. If the public keyword is omitted, then the class is privately derived by
default, and objects of the derived class cannot be used as if they were objects of the base
class. For privately derived classes, only those data members and member functions that
are defined (or overridden) in the derived class can be accessed. Member functions of a
privately derived class can access the base class's data members and member functions, but
users of objects of the derived class cannot used the derived objects to access data members
and member functions of the base class. In other words, public inheritances used to define
subtypes (which can also share behaviour), while private inheritance allows sharing of
behaviour, but does not permit an instance of the derived class to be used in situations
where a base class instance would be expected.

A class may be derived from any number of base classes. The order of derivation is not
significant except possibly for default initialization by constructor, for clean-up, and for
storage layout. The order in which storage is allocated for base classes is implementation
dependent. Access to base class members must be unambiguous. Ambiguities can be
resolved by qualifying a name with its class name.

PAGE 12
 Design
Architectural Design

Under architectural design, after defining the whole system into a set of objectives &
further subdividing them into functions, we defined the basic dependency &
communication between them.

This means that all the prime functions, their required inputs, expected output/behavior &
interdependency between other functions were clearly defined. The corresponding
interfaces for the user for each function were designed to ensure user-friendliness.

We actually addressed the system-level problems here and made a conscious effort to build
a robust design which can result in an effective communication within itself and with the
system in terms of raw data or processed information.

All the primary database design for data storage was also done in this phase.

Detailed Design

In this phase, we further subdivided every function into a set of modules & defined required
inputs & expected behavior for each of them. All the minute correlations,
interdependencies, communication between the modules were clearly defined. The source,
usage & processing of data for every module was carefully done. The database design was
also normalized at this stage to ensure that the data is efficiently stored & retrieved.

It was this design phase where the factors like user-friendliness ease of use, scalability and
self-explanation of interfaces & outputs were realized. For all the modules, the placement
of controls, passing of information, communication of different interfaces, user messages,
data transfer to databases was defined.

PAGE 13
 Table and its Relationship

DURATION
(DAYS) DEPENDENCY
TASK DESCRIPTION

T1 Requirements gathering 3 None

T2 Analysis 3 T1

T3 Designing 10 T2

Development & testing of

T4 2 T3
“Account Details” module

Development & testing of

T5 2 T4
“Amount Deposit” module

Development & testing of

T6 1 T5
“Amount Withdrawal” module

T7 Overall system testing 7 T6

T8 Documentation 7 T7

PAGE 14
DFD

PAGE 15
Description of the data objects:

1[a]: Account opening mode chosen by the User.

2[d]: If the inputted details are correct, they are passed to the “Main Menu” process and
further to different modules which serve the customer’s requests individually using those
details.

2[a]: Account information & details like Present Balance, Last Deposit & Last Withdrawal.

2[b]: Deposit details & account balance after deposit.

2[c]: This is withdrawal details & account balance after the withdrawal in case the
withdrawal amount entered is correct.

If the withdrawal amount entered is incorrect or invalid like greater than the balance, a
message is displayed to the user like “Invalid amount entered”.

PAGE 16
 Testing
Unit Testing or Module Testing
The starting point of testing is Unit testing. In this, a module is tested separately at each
step. This helps to detect syntax and logical errors in the program and is performed by the
coder himself /herself during coding.

Integration Testing
The modules, which are tested in the Unit Testing, are integrated to build the overall
system. It is observed that many errors crop up when the modules are joined together.
Integration testing uncovers these errors while integrating the modules. It helps in
establishing confidence (correctness) in the complete, assembled system. It tests the
System Design. It focus on control, communication, interfaces, performance (other system
qualities). It make use of stubs, test-beds, data generators. It is the phase of software testing
in which individual software modules are combined and tested as a group. It follows unit
testing and precedes system testing.
Integration testing takes as its input modules that have been unit tested, groups them in
larger aggregates, applies tests defined in an integration test plan to those aggregates, and
delivers as its output the integrated system ready for system testing.
Integration testing concentrates entirely on module interactions, assuming that the details
within each module are accurate. Module and Integration testing can be combined,

PAGE 17
verifying the details of each module's implementation in an integration context. Many
projects compromise, combining module testing with the lowest level of subsystem
integration testing, and then performing pure integration testing at higher levels. Each of
these views of integration testing may be appropriate for any given project, so an
integration testing method should be flexible enough to accommodate them all.
System Testing
The System testing is bringing together of all programs that a system comprises for testing
purposes. System testing is testing conducted on a complete, integrated system to evaluate
the system's compliance with its specified requirements. System testing falls within the
scope of black box testing, and as such, should require no knowledge of the inner design
of the code or logic. Programs are typically integrated in a top-down, incremental fashion.
It is a series of different tests whose primary purpose is to fully exercise the computer-
based system. It includes the following tests: -
 Recovery Testing: - It is a system test that forces the software to fail in a variety
of ways and verifies that recovery is properly performed.
 Stress Testing:- These are designed to confront program functions with abnormal
situations. It executes a system in a manner that demands resources in abnormal
quantity, frequency or volume.
 Security Testing:- This testing attempts to verify that protection mechanism built
into a system will protect it from unauthorized penetration.

The system testing is an investigatory testing phase, where the focus is to have almost a
destructive attitude and test not only the design, but also the behaviour and even the
believed expectations of the customer. It is also intended to test up to and beyond the
bounds defined in the software/hardware requirements specification(s).
Black Box Testing
It is also known as Functional Testing. It tests the overall functional requirements of
product. Inputs are supplied to product and outputs are verified. If the outputs obtained are
the same as the expected ones then the product meets the functional requirements. In this,
the internal procedures are not considered. In this the tester would only know the "legal"

PAGE 18
inputs and what the expected outputs should be, but not how the program actually arrives
at those outputs. This Testing is more effective on larger units of code. In this test’s are
done from user point of view.

White Box Testing

It is also known as Structure Testing. It focuses on the internal functioning of the product.
It tests the loops of the Procedure, Decision points, Execution paths etc.
White box testing uses specific knowledge of programming code to examine outputs. The
test is accurate only if the tester knows what the program is supposed to do. He or she can
then see if the program diverges from its intended goal. White box testing does not account
for errors caused by omission, and all visible code must also be readable. As the knowledge
of internal coding structure is prerequisite, it becomes very easy to find out which type of
input/data can help in testing the application effectively. The other advantage of white box
testing is that it helps in optimizing the code. It helps in removing the extra lines of code,
which can bring in hidden defects.

Acceptance Testing
This Testing is done when the software is developed for the specific customer. A series of
tests are conducted to enable the customer to validate all requirements. The end user/
customer conducts these tests and may range from adhoc test to well-planned systematic
series of tests. Acceptance testing may be conducted for few weeks or months. The
discovered errors will be fixed and better quality software will be delivered to the customer.
Acceptance testing is performed by the customer on a system prior to the customer
accepting delivery or accepting transfer of ownership of that system.
The customer specifies scenarios to test when a user story has been correctly implemented.
A story can have one or many acceptance tests, what ever it takes to ensure the functionality
works. Acceptance tests are black box system tests. Each acceptance test represents some
expected result from the system. Customers are responsible for verifying the correctness
of the acceptance tests and reviewing test scores to decide which failed tests are of highest
priority. Acceptance tests are also used as regression tests prior to a production release. A

PAGE 19
user story is not considered complete until it has passed its acceptance tests. This means
that new acceptance tests must be created each iteration or the development team will report
zero progress.
Test Data and Test cases

Test Data
Test Data are data that have been specifically identified for use in executing test scripts,
and are used to verify the expected results obtained.
It states:
 What the items to be tested are?
 At what level they will be tested?
 What sequence they are to be tested?
 How the strategy will be applied to the testing of each item and describes the test
environment.

Test Case

It describes an input description and an expected output description. These are derived
during all phases of the development cycle. It helps in determining expected results
before running a test case.

Serial Action Input Excepted Pass (Y/N)

No. Output

1. To check account support Valid Record proceeded Y

by string input

2. To check account details Proceeded. Y

in file Valid Record

3. To deposit amount Invalid Record No error N

PAGE 20
 Message

4. To check deposited Valid record procedded Y

amount

5. To check functionality of Invalid Record Error message Y

interface button

6. To check functionality of Invalid Record Blank interface N

interface button

Test Reports and Debugging

Test Reports
If your entered Account number and password matched from backened Then project will
process next step. If user put wrong account number then project will be show error
message. On Go, validation for each text box is carried out and attention is focused on to
respective text box that does not meet validation requirement, thus chances of error are
eliminated.

Account Detail
Account detail module display the User Name , Present Balance etc.

Amount Deposit
When user choice the Amount Deposit Then this module will be show three statement:
user present balance, Enter the amount to be deposited and Enter new balance after
deposit. If user click add without deposit amount then this project will display the error
message.
Amount Withdrawl
By use of module, User can withdraw amount but if entered amount is available in bank.

PAGE 21
If entered amount is not available then this project will be display error message. So user
can withdraw minimum amount than available in bank.
EXIT

This module will be work of EXIT. If user’s processing work have finish . Then user
will be exit from own Account.

PAGE 22
Gantt chart

PAGE 23
 CONCLUSIONS

We can hereby conclude that:

1. The system effectively automated the functions involved in the processes being
handled manually before.

2. The cost & benefit analysis shows that the system was quite successful in saving
costs for the bank & generate equivalently huge benefits

3. The system is secure & scalable. The system design has been done keeping user-
friendliness and efficiency in mind.

PAGE 24
 Bibliography
Object Oriented Programming 4th Edition by Robert Lafore

Web Reference

www.cprogramming.com/tutorial.html

www.geeksforgeeks.org

PAGE 25
PAGE 26