ATM_DOC

UOM IBM MS (Tech) 7th Semester

1. ABSTRACT

In this Project we present a a model for the utilization of biometrics

equipped Automatic Teller Machines (ATMs) to provide a number of

social services including identity verification and disbursement of

social security, unemployment, welfare and pension benefits to a la rge

segment of the population. The paper summarizes how ATMs have

matured into a technology application providing financial services to a

segment of our society, and the technical functionality behind the

provisioning of those services. Biometrics innovation and functionality

is explored and a technical model is developed for its integration

to existing ATM devices, networks and databases. The paper concludes

by outlining potential benefits to business, government and

individuals, as well as some of the social and legal barriers to be

overcome.

ATM Management system-Biometric ATM , a Proposal - 1 -


2. INTRODUCTION

ATM innovation paralleled the growth of the PC and

telecommunications industries. Each machine operated in a local mode

without any connection to the banking systems, and transaction

authorization took place based on the information recorded in the

magnetic bands of the cards. The next step in the evolution of this

industry was to connect these devices to the bank’s centralized

systems; by then, mid -1980’s, banks would work in a dual modality, in

other words, the ATM would work on-line but in the event of

communication loss it had the ability to authorize the transaction with

the information recorded on the magnetic band.

In the early 90’s, taking advantage of the technological boom in

microcomputers and communications, ATMs started to work

exclusively on-line implying that, if the ATM loss communication with

its central system, there would not be service. Once ATMs were

connected directly, the need arose to protect the information in the

card and the client’s PIN (Personal Identification Number) found in

messages that had to travel across public telecommunication lines. For

this purpose, from the beginning, algorithms that allowed for the

encryption of the information were utilized; the most commonly

utilized algorithm is(Delta Encryption Standard).



1.1.1 Purpose, Scope, and Objectives

The purpose of the project is to analyze the requirements of, design,

implement, and maintain the software for both the central bank server and

the ATM client machines that will comprise the specific Bank ATM

network, according to the requirements specified by the client.

All activities directly related to the purpose are considered to be in scope.

All activities not directly related to the purposes are considered to be out of

scope. For example, issues concerning ATM hardware and network

availability are not within the scope of this project.

The objectives of the project are as follows:

• complete the project by the project due date

• complete the project within budget

• provide all deliverables identified in section 1.1.3 by the project due date

• fulfill all stated requirements, as in the SRS, of the software product deliverable, which fall into one of the following categories

central bank customer database modifications

interface with central bank computerized accounting system

customer ATM transactions

customer ATM statement

weekly statistical report of ATM operations



Assumptions and Constraints

The project will be planned with the following assumptions:

• this project is a component of a larger project

• this project will deliver only the software components of the larger project

• initial estimates for the project as provided in this SPMP are +/- 40%

• the larger project that this project is a part of has already defined the

hardware that the software will run on

• the software products will be Windows NT-based using Windows Open

Services Architecture / eXtensions for Financial Services (WOSA/XFS),

supporting NNB’s desire for an open architecture ATM product

• the ATM hardware has documentation available suitable for interface

discovery

• the ATM hardware is defined (4th generation NCR ATM hardware) and

detaileddocumentation about the platform will be delivered to Terasoft by

June 1, 2004.



• a documented physical ATM computer network is being created in a

separate project and will exist between each ATM client and the central

bank in time for acceptance testing

• the ATM hardware is being handled as a separate project and will be

available in time for the installation phase

• we will be able to acquire the expertise of two outside consultants from

Banks, Etc. to assist with the requirements elicitation and detail design of the

ATM client/server software

• this SPMP is submitted as a firm-fixed-price (FFP) bid; the project shall

not exceed the established budget

The project will be planned with the following constraints:

• budget

$3,000,000 (25% of total $12,000,000 budget; software portion only)

Time : one year: once the software product is installed on the ATM

machines, it will take 30 days for NNB to install the physical ATM

machines in their permanent locations

Staff two outside consultants from Banks Etc. will be required to

assist in the requirements and detail design phases of the project, so as

to lend their extensive ATM experience to the project. The consultants

will also supplement our team elsewhere, as necessary.



Maintenance : the software will have to be designed such that

maintenance expenses do not exceed $100,000 per year (software

maintenance portion of the total $600,000 budget)

Project Deliverables

• Software program and library binaries

• Software documentation

Installation documentation End-user documentation updates applied to NNB’s central bank documentation

• Installation of software program and library binaries on target hardware

• Software training performed against affected users

ATM site users (i.e. bank branch staff) ATM site installers Software maintenance team

• Project documentation

Software Requirements Specification (SRS) Software Design Specification (SDS) Software Project Management Plan (SPMP) Software Test Plan (STP) Software Quality Assurance Plan (SQAP) Software Configuration Management Plan (SCMP) Software Verification and Validation Plan (SVVP)



Evolution of the Plan

The plan is considered to be a dynamic document and will be

updated monthly by default and on an unscheduled basis as

necessary Scheduled updates to the plan will occur once every

month, on the last business day of the month. Notification of

scheduled and unscheduled updates to the plan will be

communicated via e-mail to all project participants according to the

Reporting Plan.

Start-up Plan

Estimation Plan

Schedule, Cost, and Resource Estimates: An estimation chart showing

activities, estimated duration, estimated cost, and estimated

resource requirements.

Estimation methods

Schedule duration and work estimation for each leaf activity in the

Work Breakdown Structure (WBS) will be performed using a

combination of the following methods and data sources:

o Resource input



For the resource(s) identified as being required to complete the

activity, the resources will be asked for an estimate of the amount of

time required to complete the activity. A detailed estimate will be

requested, broken down into subactivity milestones. Subactivity

milestones tied to the “% complete” metric will force a consideration

of everything that is involved in the activity as well as providing a

basis for EVM monitoring.

o When more than one resource is assigned to the activity, their

estimates will be collected independently and, if substantially

different, meetings will be held between the project manager and all

resources so that an agreement may be reached on a final estimate.

This is in the spirit of the wideband delphi approach, but is modified

for the size of our organization and tight project schedule.

o Organizational project history data

Data from those that are most relevant will be used to fine-tune the

estimates for the activities on this project.

o Contractor project history data

o The contracting company that we use to assist in financial software

development project has a substantial project history from which we

can draw. The acquisition of two contractors from the company, as

outlined in the project staffing plan, will give us access to this data for

the purpose of making estimates.

PROJECT STAFFING PLAN



In terms of domain-specific knowledge as it relates to the

development ATM software, we have accommodated our limited

experience in this area by recognizing the need for two consultants

from a company with which we have had a good working relationship

in the development of financial software. The two consultants whose

services we will acquire from Banks, Etc. will fill our knowledge gap in

this area.

WORK PLAN

Work activities must be documented. Schedule allocation , Resource

allocation and Budget allocation must be recorded

5. PROJECT ORGANIZATION

5.1 PROCESS MODEL

The project shall utilize a combination of Iterative and Waterfall

development approach, with three interim deliveries prior to the final

build. Content of each build shall be determined by the Program

Manager with direct input from the customer regarding need dates for

required functionality.

PROJECT RESPONSIBILITIES

PROGRAM MANAGER - The Project Manager shall be responsible for

defining and controlling project work activities and schedules. Other

team members shall work in conjunction with the project manager to

define the elements of their task assignments, establish a schedule

baseline, collect metric data to assess performance against that



baseline, and conduct re-base lining activities as required. The Project

Manager shall submit the initial baseline and any baseline

modifications to the Program Manager for approval.

CONFIGURATION MANAGER - The CM is responsible for maintaining a

matrix of all customer approved requirements; is responsible for

oversight of the requirements change control process; is responsible

for applying changes to requirements matrix; is responsible for

maintaining the modification history of requirements.

QA/TEST MANAGER - The QA/Test Manager is responsible for verifying

that the delivered product satisfies the approved requirements; is

responsible for documenting the results of the requirements

verification in a Test Analysis Report.

BUSINESS ANALYST - is responsible for analyzing and evaluating

requirements for feasibility and impact to the project.

RISK MANAGER - The Risk Manager is responsible for identifying the

risks likely to compromise the project success; is responsible for

assessing the loss probability and loss magnitude for each identified

risk; will prioritize the risks as they are identified and bring them to the

attention of the group; is responsible for planning for, resolving and

monitoring each risk item.

DEVELOPER - The developer is responsible for designing a system

satisfying the requirements; is responsible for creating prototypes, as

necessary, for feasibility studies; is responsible for creating and

changing all source files in accordance with the change and control

process; is responsible for documenting the source files for

maintenance purposes.

TESTER

CUSTOMER REPRESENTATIVE - The customer is responsible for defining

and approving all requirements, and all modification to requirements.



PRODUCT MANAGER - The product manager is responsible for

periodically reviewing the content, organization and style of the

system

Performance ReportingThe project will report performance to plan with the following metrics:

Earned Value

Budgeted Cost of Work Scheduled (BCWS) vs. Budgeted Cost of

Work

Performed (BWCP)

Schedule Variance (CV)

Budgeted Cost of Work Performed (BCWP) vs. Actual Cost of

Work

Performance (ACWP)

Cost Variance (CV)

Cost Performance Index (CPI)

Schedule Performance Index (SPI)

Critical Ratio (CR)

Estimated Cost at Completion (ECAC)

Estimated Time at Completion (ETAC)

Requirements

Requirements change count

Configuration

Configuration churn

Quality

Open defects vs. closed defects over time

Lines of code (LOC)

Comment percentage

Defects per LOCATM Management system-Biometric ATM , a Proposal - 11 -


Risks

Risk exposure

Top 10 risks

Weekly risk changes

Methods, Tools, and Techniques

Development methodology

The project shall use the waterfall software development

methodology to deliver the software products, with work

activities organized according to a tailored version of those

provided by the IEEE Standard for Developing Software Life Cycle

Processes (IEEE 1074-1997). The decision to use the waterfall

methodology is due to the following characteristics of the

project:

the product definition is stable

requirements and implementation of the product are both very

well-understood

technical tools and hardware technology are familiar and well-

understood

waterfall methodology has proven successful for projects of this

nature performed by

The Software Project Management Plan (SPMP) shall be based on

the IEEE Standard for Software Project Management Plans (IEEE

1058-1998).



Development techniques

The requirement passed down to this project from the larger ATM

project is that the software be based on an open architecture using

a Windows NT-based platform and Windows Open Services

Architecture / eXtensions for Financial Services (WOSA/XFS). This

architecture allows us to use object-oriented methods and tools for

analysis, design, and implementation. We will use Object Modeling

Technique (OMT) for this purpose.

Tools

The following work categories will have their work products satisfied

by the identified tools:

Team member desktop foundation

Microsoft Windows 2000 desktop operating system

VMWare Workstation 4.5 [virtual machine support – one VM

per active project]

Microsoft Office 2003 productivity application suite

IBM Lotus Notes R6 [e- mail, calendar]

MindJet MindManager X5 Pro [information organization,

brainstorming]

Adobe Acrobat 6.0 [creating/viewing PDF files]

Project management

Microsoft Project 2003 [WBS, schedule/cost estimates,

resource planning, project

control]

Best Carpe Diem [electronic time sheet]

Tera metric [internally-developed metrics collection database]



Document publishing (applies to all documents published by

the project)

Microsoft Word 2003 [document preparation and revision]

Configuration Management & Change Management

IBM Rational Clear Case LT [version control]

IBM Rational Clear Quest [defect and change tracking]

Quality

Terametric [internally-developed metrics collection database]

Requirements

IBM Rational RequisitePro [requirements tracking]

Design

IBM Rational Rose Data Modeler [database design]

IBM Rational Rose Technical Developer [use cases, non

database software design]

Implementation

Microsoft Visual C++ [programming language, development

tools and object code generation]

Windows Software Development Kit (SDK) [programming

support]

Testing

IBM Rational Robot [automated functional and

regression testing]

Training

Microsoft PowerPoint 2003 [training presentations]

Online Performance Reporting

Microsoft Windows 2000 Server Standard [server operating

system],



Microsoft Internet Information Services 4.0 [web server

software]

ADDITIONAL FEATURES FOR THE ATM PROPOSAL

BIOMETRIC MEASURE FOR ENHANCING ATM SECURITY

It is important to mention that in parallel to the development of the

industry different modes of fraud have made it necessary to reinforce

the levels of security utilized in ATMs; this leads to the theme of this

investigation: to adapt biometric technology to the ATM networks

Cards with Magnetic Bands

The plastic cards with magnetic bands date back to more than 30

years. The financial sector has used them as a means to making

payments and to offer access to the financial services for clients. The

magnetic band contains unique information for every card allowing for

user identification and providing access to its products through the

various electronic channels. In order to provide access to these

products, cards with magnetic bands are normally associated to a

personal identification number (PIN) which is initially assigned by the

entity issuing the card and, in some cases, the client can then change

it at his/her convenience. The card and the PIN are directly related to

the user identification and allow for the utilization of electronic

channels just like as is the case with the ATMs.

ATM Hardware and Software Characteristics



We may classify the hardware for an ATM in two major categories: the

first one, corresponding to its PC architecture (a microprocessor,

memory, drives, monitor, keyboard, etc.), the second one related to

ATM specific functions such as card reading, cash dispensing, cash

storage, user and operator’s video and keyboard interaction, etc.

Based on the PC architecture, the software included in an ATM is not

very different to that which is found in a personal computer. It has an

operating system (OS/2, or Windows based). The telecommunication

system is today mostly oriented to services based on the TCP/IP

protocols.The application software is most of the time provided by the

manufacturer of the ATM machine. It normally offers an interface

allowing for each financial institution to adapt its own applications.

Transaction Functionality

We have described the various elements that intervene in an ATM

transaction, the card and the ATM components. Figure 1 shows the

sequence of events involved in the authorization process together with

the functionality of the central authorization system to which the ATM

is connected.



Biometric Technology

The term biometrics comes from the word bio (life) and metric

(measurement). Biometric equipment has the capability to measure,

codify, compare, store, transmit, and/or recognize a specific

characteristic of a person with a high level of precision and

trustworthiness. Biometric technology is based on the scientific fact

that there are certain characteristics of living forms that are unique

and not repetitive for each individual; these characteristics represent

the only technically viable alternative to positively identify a person

Without the use of other forms of identification more susceptible to

fraudulent behavior



Biometric identification is utilized to verify a person’s identity by

measuring digitally certain human characteristics and comparing those

measurements with those that have been stored in a template for that

same person. Templates can be stored at the biometric device, the

institution’s database, a user’s smart card, or a Trusted Third Party

(TTP) Service Provider’s database. Where database storage is more

economic than plastic cards, the method tends to lack public

acceptance; however, Polemi (1997) found that TTPs can provide the

confidence that this method is missing by managing the templates in a

trustful way.

There are two major categories of biometric techniques: physiological

(fingerprint verification, iris analysis, hand geometry-vein patterns, ear

recognition, odor detection, DNA pattern analysis and sweat pores

analysis), and behavioral (handwritten signature verification,keystroke

analysis and speech analysis). Deane et al. (1995) found that behavior

based systems were perceived as less acceptable than those based on

physiological characteristics.Of the physiological techniques, the most

commonly utilized is that of fingerprint scanning.

Restricted in the past due to its high cost and lack of social

acceptance, biometric identification is now experiencing a higher level

of acceptance not only in high security applications such as banks and

governmental facilities, but also in health clubs, sports events, office

and industrial sites. Costs have been reduced to a reasonable level and

functionality and reliability of the devices is today satisfactory.

Biometrics is also increasingly included in a wide range of verification



applications in e-commerce, financial electronic transactions, and

health information systems patient data storage and dissemination.

Components of a Biometric System

The processes associated with a biometric methodology: enrollment,

identification/verification, and learning.



Enrollment: Prior to an individual being identified or verified by a

biometric device, we must complete the enrollment process with the

objective of creating a profile of the user. Enrollment is a relatively

short process, taking only take a few minutes and consisting of the

following steps:

1. Sample Capture: the user allows for a minimum of two or three

biometric readings, for example: placing a finger in a fingerprint

reader. The quality of the samples, together with the number of

samples taken, will influence the level of accuracy at the time of

validation. Not all samples are stored; the technology analyzes and

measures various data points unique to each individual. The number of

measured data points varies in accordance to the type of device.ATM Management system-Biometric ATM , a Proposal - 20 -


2. Conversion and Encryption: the individual’s measurements and data

points are converted to a mathematical algorithm and encrypted.

These algorithms are extremely complex and cannot be reversed

engineered to obtain the original image. The algorithm may then be

stored as a user’s template in a number of places including servers,

PCs, or portable devices such as PDAs or smart cards. Identification

and Verification. Once the individual has been enrolled in a system,

he/she can start to use biometric technology to have access to

networks, computer centers, buildings, personal accounts, and to

authorize transactions. Biometric technology determines when a

person could have access in one of the two forms be it identification or

verification. Some devices have the ability to do both.

1. Identification: a one-to-many match. The user provides a biometric

sample and the system looks at all user templates in the databa se. If

there is a match, the user is granted access, otherwise, it is declined.

2. Verification: a one-to-one match requiring the user provides

identification such as a PIN or a smart card in addition to the biometric

sample. In other words, the user is establishing who he/she is and the

system simply verifies if this is correct. The biometric sample with the

provided identification is compared to the previously stored

information in the data base. If there is a match, access is provided,

otherwise, it is declined.

Learning. Each time the user utilizes the system the template is

updated through learning processes taking into account gradual

changes due to age and physical growth. These are later utilized by

the system to determine whether to grant or deny access.



Technical Model Development

The integration of the two technologies requires the incorporation of

the fingerprint sensor to the ATM, and the interaction of the biometric

system with the ATMs and the authorizing system. The following steps

outline in more detail the necessary modifications:

1. We start by connecting the biometric system to the same network

utilized by the ATMs and authorization system. The biometric system

needs to be compatible with the communications protocol (most likely

TCP/IP) utilized by the other devices.

2. The biometric system will need software to allow it to “listen” to the

network communications for messages directed to it, and to create

messages for the other devices.



3. The fingerprint sensor is installed on the ATM; it will have the

capability to connect (via the network) to the biometric system. It also

needs to be protected from vandalism and be weather -resistant.

4. Through software changes, the ability to identify a customer

requiring fingerprinting will be incorporated to the ATM. User screens

will be created to guide the client through the process of entering the

fingerprint and receiving notification of fingerprint acceptance or

denial.

5. The authorizing system software needs to identify when a

transaction requires fingerprinting so that it can prompt the ATM to

present the screen(s) requesting the user to place his finger on the

reader, at the same time in which it instructs the biometric system to

read and validate the fingerprint for transaction authorization. The

authorizing system will also be modified to accept the validation

results from the biometric system and enter it into its log. Once the

ATM, authorizing system and biometric system have been

interconnected, the validation database needs to be built through the

“enrolment” process. User information (name, address, telephone

number, etc.) needs to be entered together with a key identifier such

as card number, social sec urity number, voter’s registration number,

etc. After all the information is entered, the application activates the

sensor and fingerprint(s) are read; the program can make multiple

readings, until it ascertains the quality of the sample meets the

pre-established standards for validation. Application software can

register prints for up to 10 fingers per individual. Figure 4 shows the

sequence of events involved in a transaction validation utilizing the

biometrics-equipped ATM system model.



Figure 4. Integrated model transaction validation sequence of events

Business Model Development Today, banks , other financial institutions

and, increasingly, retailers are offering Automatic Teller Machines

(ATMs) as a service , through the utilization of “transaction processing”

service companies who offer the daily management of the network

infrastructure, the authorization systems, and the inter -connection of

ATMs to multiple credit/bank card providers. Banks, other financial

institutions and retailers pay these banking services a fee based on a

fixed subscription cost as well as a variable cost associated with the

volume and types of customers and transactions. The banks then

charge their customers, typically, on a per transaction basis. ATM

service is no longer seeing as a competitive advantage, but as a

necessity to maintain the customer base.



Potential Benefits and Barriers

There are a lot of benefits which can be obtained from the synergistic

effect of offering welfare and pension payments through biometrics-

equipped bank ATM networks:

1. Government could reduce its cost and provide a more efficient and

timely service to its constituents.

2. Banks, other financial institutions and retailers could increase the

volume and reduce their ATM unit transaction costs; increase their

revenues by charging the government agencies for the service; and

expand their potential customer base.



3. Transaction processing services companies would increase their

revenues with a higher volume of transactions and from the

provisioning of biometrics database and verification services.

4. Pension and welfare recipients could receive their benefits faster, in

a more convenient and secure form.

5. The public at large could benefit through a reduction in taxes as a

result of a more efficient government.

There also are a number of barriers to the deployment of such a

system. There are countries where the capture and storage of

fingerprints by other than a government agency may be considered

illegal and/or a form of “big brother” control by the general public; or

where government may not want to outsource public functions to

private industry. There is a segment of the population which fears

computer or machine interface, and/or the natural resistance to

change inherent to most humans.

There are number of means to overcome these barriers

1. Use smart cards to store the biometric templates whenever the

storage of templates in a central database brings discomfort or

hesitation.

2. Educate people on the technologies and the differences between

this application and that of criminal databases.

3. Emphasize the advantages of biometric technologies, particularly

the added security to transactions.

4. Provide awareness of when, how and where people are

authenticated; they should know when and where they are identified

and verified, and which technology is being used.

USECASE DIAGRAM FOR ATM – TRANSACTION



Flows of Events for Individual Use Cases

System Startup Use case

The system is started up when the operator turns the operator switch

to the "on" position. The operator will be asked to enter the amount of

money currently in the cash dispenser, and a connection to the bank

will be established. Then the servicing of customers can begin.



System Shutdown Use CaseThe system is shut down when the operator makes sure that no

customer is using the machine, and then turns the operator switch to

the "off" position. The connection to the bank will be shut down. Then

the operator is free to remove deposited envelopes, replenish cash and

paper, etc.



Session Use CaseA session is started when a customer inserts an ATM card into the card

reader slot of the machine. The ATM pulls the card into the machine

and reads it. (If the reader cannot read the card due to improper

insertion or a damaged stripe, the card is ejected, an error screen is

displayed, and the session is aborted.) The customer is asked to enter

his/her PIN, and is then allowed to perform one or more transactions,

choosing from a menu of possible types of transaction in each case.

After each transaction, the customer is asked whether he/she would

like to perform another. When the customer is through performing

transactions, the card is ejected from the machine and the session

ends. If a transaction is aborted due to too many invalid PIN entries,

the session is also aborted, with the card being retained in the

machine.

The customer may abort the session by pressing the Cancel key when

entering a PIN or choosing a transaction type.



Transaction Use Case

Note: Transaction is an abstract generalization. Each specific concrete

type of transaction implements certain operations in the appropriate

way. The flow of events given here describes the behavior common to

all types of transaction. The flows of events for the individual types of

transaction (withdrawal, deposit, transfer, inquiry) give the features

that are specific to that type of transaction.

A transaction use case is started within a session when the customer

chooses a transaction type from a menu of options. The customer will

be asked to furnish appropriate details (e.g. account(s) involved,

amount). The transaction will then be sent to the bank, along with

information from the customer's card and the PIN the customer

entered.



If the bank approves the transaction, any steps needed to complete

the transaction (e.g. dispensing cash or accepting an envelope) will be

performed, and then a receipt will be printed. Then the customer will

be asked whether he/she wishes to do another transaction.

If the bank reports that the customer's PIN is invalid, the Invalid PIN

extension will be performed and then an attempt will be made to

continue the transaction. If the customer's card is retained due to too

many invalid PINs, the transaction will be aborted, and the customer

will not be offered the option of doing another.

If a transaction is cancelled by the customer, or fails for any reason

other than repeated entries of an invalid PIN, a screen will be displayed

informing the customer of the reason for the failure of the transaction,

and then the customer will be offered the opportunity to do another.

The customer may cancel a transaction by pressing the Cancel key as

described for each individual type of transaction below.

All messages to the bank and responses back are recorded in the

ATM's log.



Withdrawal Transaction Use Case

A withdrawal transaction asks the customer to choose a type of

account to withdraw from (e.g. checking) from a menu of possible

accounts, and to choose a dollar amount from a menu of possible

amounts. The system verifies that it has sufficient money on hand to

satisfy the request before sending the transaction to the bank. (If not,

the customer is informed and asked to enter a different amount.) If the

transaction is approved by the bank, the appropriate amount of cash is

dispensed by the machine before it issues a receipt. (The dispensing of

cash is also recorded in the ATM's log.)

A withdrawal transaction can be cancelled by the customer pressing

the Cancel key any time prior to choosing the dollar amount.



Deposit Transaction Use Case

A deposit transaction asks the customer to choose a type of account to

deposit to (e.g. checking) from a menu of possible accounts, and to

type in a dollar amount on the keyboard. The transaction is initially

sent to the bank to verify that the ATM can accept a deposit from this

customer to this account. If the transaction is approved, the machine

accepts an envelope from the customer containing cash and/or checks

before it issues a receipt. Once the envelope has been received, a

second message is sent to the bank, to confirm that the bank can

credit the customer's account - contingent on manual verification of

the deposit envelope contents by an operator later. (The receipt of an

envelope is also recorded in the ATM's log.)



A deposit transaction can be cancelled by the customer pressing the

Cancel key any time prior to inserting the envelope containing the

deposit. The transaction is automatically cancelled if the customer fails

to insert the envelope containing the deposit within a reasonable

period of time after being asked to do so.

Transfer Transaction Use Case

A transfer transaction asks the customer to choose a type of account

to transfer from (e.g. checking) from a menu of possible accounts, to

choose a different account to transfer to, and to type in a dollar

amount on the keyboard. No further action is required once the

transaction is approved by the bank before printing the receipt. ATM Management system-Biometric ATM , a Proposal - 34 -


A transfer transaction can be cancelled by the customer pressing the

Cancel key any time prior to entering a dollar amount.

Inquiry Transaction Use Case

An inquiry transaction asks the customer to choose a type of account

to inquire about from a menu of possible accounts. No further action is

required once the transaction is approved by the bank before printing

the receipt.

An inquiry transaction can be cancelled by the customer pressing the

Cancel key any time prior to choosing the account to inquire about.



Invalid PIN Extension

An invalid PIN extension is started from within a transaction when the

bank reports that the customer's transaction is disapproved due to an

invalid PIN. The customer is required to re-enter the PIN and the

original request is sent to the bank again. If the bank now approves the

transaction, or disapproves it for some other reason, the original use

case is continued; otherwise the process of re-entering the PIN is

repeated. Once the PIN is successfully re-entered, it is used for both

the current transaction and all subsequent transactions in the session.

If the customer fails three times to enter the correct PIN, the card is

permanently retained, a screen is displayed informing the customer of

this and suggesting he/she contact the bank, and the entire customer

session is aborted.



If the customer presses Cancel instead of re-entering a PIN, the original

transaction is cancelled.





User Interface Design

A user interface is a friendly means by which users of a system can

interact with the system to process inputs and obtain outputs. It is also

a means of communication between the human user and the system

through the use of input/output devices with supporting software. This

particular ATM application is made up of 6 interfaces, which include;

Login Interface, Enroll Fingerprint Interface, Transaction Type Selection

Interface, Withdrawal Interface, Deposit Interface, and View statement

of Account Interface.



This interface is the very first interface the bank customer interacts

with on the ATM machine. This interface prompts the customer to

insert ATM card and proceeds with the entire authentication processes,

that is, inputting the ID (or card number) and PIN number (see figure

3). If the user enters an invalid card number or PIN number, a dialogue

box appears prompting an invalid PIN or invalid card number and the

system returns enter a valid PIN number. A typical description of this is

shown in figure 4. After validating the customer’s card and PIN

number, the customer is directed to the next phase of the

authentication process via the authentication dialogue box for

inputting the fingerprint. LOGIN INTERFACE



Login interface response to invalid interface

Fingerprint Interface

This is the final interface the customer interacts with in the

authentication process. It requests from the customer the enrollment

of his/her fingerprint to be placed on a Fingerprint reader. The

fingerprint reader accepts the fingerprint and seeks to match the live

sample with the already enrolled templates in the banks database. If

match is confirmed it will finally authenticate customer else it will deny

customer access to his/her bank account.



The fingerprint of an individual is very peculiar to that individual since

no two individuals can have the same fingerprint. The fingerprint

reader captures the fingerprint features of an individual and search for

a match of fingerprint brought up for identification among the stored

fingerprints in the database. . The fingerprints stored are kept along

side the other ID’s (Pin and Card Numbers) and the corresponding

biometric templates are kept in the database. When the fingerprint is

found correct, the customer is taken to the transaction phase where

he/she will choose among the transactions (deposit or withdrawal),

otherwise the customer is denied access and the system brings up a

dialogue box for which the customer can choose Ok, and as soon as

this done the system automatically log off the customer. ATM Management system-Biometric ATM , a Proposal - 42 -


Invalid Fingerprint Interface

Withdrawal Interface

This interface enables the customer withdraw money from his/her

account. It shows the customers current balance by subtracting the

amount withdrawn from the previous account balance. After the

customer has completed all his/her withdrawals, a dialogue box pops

up notifying the customer of his/her successful withdrawal transaction.

The interface is shown below.



1. Display all of the available rooms for a certain date

a. An agent requests all rooms for a given date that are available

2. Display all of the available rooms for a certain date with certain criteria

a. Display all rooms with a given number of types of beds



i. Display all with 1-n King Beds

ii. Display all with 1-n Queen Beds

iii. Display all with 1-n Double Beds

iv. Display all non-smoking rooms

v. Display all rooms with window view

vi. Display all rooms with kitchenette

vii. Display any combination of above

3. Purge reservations when agent signs in

a. When agent signs in, all reservations for days passed are purged and the screen displays the number of reservations purged and their id’s and dates

4. Agent creates new reservation for a certain number of rooms for a certain number of days

a. Agent receives confirmation number or error message depending upon success

b. Agent enters in details of person making the reservation



5. Agent deletes reservation from system (must remove all days and rooms)

6. Agent edits existing reservation

a. Agent changes one or more of the fields in the reservation

7. Agent creates a room configuration

a. Type of room (Luxury suite, penthouse, and executive suite) is specified

b. Number of beds and types of beds are specified (includes pull out couch)

c. Smoking or non-smoking specified

d. Number of bathrooms (1, 2,)

e. Kitchenette present

8. Agent prints out a bill for the hotel stay

a. A bill should be printed for each room

b. The bill needs to detail the cost of the room, taxes and any fees incurred

9. System files are backed up each time program is run

a. Need for the back up of the files each time you open and save them



USECASE DIAGRAM



7. ENTITY RELATIONSHIP DIAGRAM

\



8. RISK ANALYSIS AND MITIGATION PLAN

What is Risk?

Risk is defined as "The possibility of suffering harm or loss; danger." Even if we're not

familiar with the formal definition, most of us have an innate sense of risk. We are aware

of the potential dangers that permeate even simple daily activities, from getting injured

when crossing the street to having a heart attack because our cholesterol level is too high.

Although we prefer not to dwell on the myriad of hazards that surround us, these risks

shape many of our behaviors. Experience (or a parent) has taught us to look both ways

before stepping off the curb and most of us at least think twice before ordering a steak.

Indeed, we manage personal risks every day.

8.1 RISK ASSESSMENT

Making a list of all of the potential dangers that will affect the project

Assessing the probability of occurrence and potential loss of each item listed

Ranking the items (from most to least dangerous)

Risks Identified in a Hotel Management Project are as follows:

1. PROPERTY

Fire and Explosion

Natural disaster and third party

Security

Environment

2. PEOPLE



Health and safety

Key personnel

3. OPERATIONAL

Business interruption

Project risk

IT and communications

Product liability

Catastrophe recovery

Regulatory compliance

4. COMMERCIAL

Legal liability

Industry risks

Financial risk

Political risk

Exchange rate risk

Corporate reputation

Services liability

5. TOP TEN SOFTWARE RISKS IDENTIFIED ATM Management system-Biometric ATM , a Proposal - 50 -


Personnel Shortfalls

Unrealistic schedules and budgets

Requirements Mismatch/Gold Plating

Developing the wrong functions and properties

Developing the wrong user interface

Continuing stream of requirements changes

Shortfalls in externally furnished components

Shortfalls in externally performed tasks

Real-time performance shortfalls

Straining computer-science capabilities



8.2. RISK CONTROL

- Coming up with techniques and strategies to mitigate the highest ordered risks

- Implementing the strategies to resolve the high order risks factors

- Monitoring the effectiveness of the strategies and the changing levels of risk

throughout the project

TOP TEN MITIGATION PLANS IDENTIFIED

1. Risk Identified Personnel Shortfalls –

Staffing with top talent;

key personnel agreements;

incentives;

team-building;

training;

tailoring process to skill mix;

peer reviews

2. Risk Identified Unrealistic schedules and budgets

Business case analysis;

design to cost;

incremental development;



software reuse;

requirements descoping;

adding more budget and schedule

3. Risk Identified Requirements Mismatch/Gold Plating

Stakeholder win-win negotiation;

business case analysis;

mission analysis;

ops-concept formulation;

user surveys;

prototyping;

early users’ manual;

design/develop to cost

4. Risk Identified Legacy Software

Design recovery;

Phase-out options analysis;

Restructuring

5. Risk Identified Developing the wrong user interface

Prototyping;

scenarios; ATM Management system-Biometric ATM , a Proposal - 53 -


user characterization (functionality, style, workload)

6. Risk Identified Continuing stream of requirements changes

High change threshold;

Incremental development (defer changes to later increments)

7. Risk Identified Shortfalls in externally furnished components

Qualification testing;

benchmarking;

prototyping;

reference checking;

compatibility analysis;

vendor analysis;

evolution support analysis

8. Risk Identified Shortfalls in externally performed tasks

Reference checking;

audits;

award-fee contracts;

competitive designer prototyping;

team-building

9. Risk Identified Real-time performance shortfalls ATM Management system-Biometric ATM , a Proposal - 54 -


Architecture tradeoff analysis and review boards;

simulation;

benchmarking;

modeling;

prototyping;

tuning

10. Risk Identified Straining computer-science capabilities

Technical analysis;

cost-benefit analysis;

prototyping;

reference checking



9. FEASIBILITY STUDY

9.1 TECHNICAL FEASIBILITY

The necessary resources like hotel receptionist to provide information about the hotel

reservation system, room information’s – types of rooms, process of check-in and

checkout and customer information to develop GUI applications in Visual Basic 6.0 and

MSACCESS environments are available. The required hardware a Pentium machine and

software required i.e. Visual Basic 6.0 and MS-OFFICE is available. Hence there is no

development risk associated with the software.

9.2 OPERATIONAL FEASIBILITY

The “Hotel Management System” will operate in Windows environment on a Pentium

Machine. It will be a reliable package that facilitates management of hotel information of

Hotel. It will provide greater extent of flexibility for user to automate the check-out

billing for the customer. It will calculate the number of days a customer has stayed in the

hotel and charge the customer accordingly. Thus, it will meet all the required

functionality and be operationally feasible.

9.3 ECONOMICAL FEASIBILITY

The “Hotel Management System” project is estimated to be a project to maintain

information for 100 hotel rooms and about 100-150 customers everyday. The system will

be help about 5 receptionists to check the room information and calculate the customer

bills. Considering the hardware requirements, software requirements, manual for users

and training the staff estimated expense on this project is 30,00,000 USD.

9.4 MOTIVATIONAL FEASIBILITY

The “Hotel Management System” software will be used by the receptionists to check-in,

check-out and billing customers, accounts personal and the other employee’s such as the ATM Management system-Biometric ATM , a Proposal - 56 -


managers to check the reports. The software fulfills all necessary requirements for such

application. It provides a graphical user interface that makes easier for the staff to use. It

also provides easy to understand menu structure. It’s easy to use nature makes it readily

acceptable to the end users, who need not have much technical knowledge to use it.

9.5 HARDWARE & SOFTWARE FEASIBILITY

Hardware

Server

- Processor:

- Memory:

- Space:

Client

- Processor:

- Memory:

- Space:

Software

Front end: Visual Basic 6.0

Back end: MS_ACCESS

Operating System: Windows

9.6 ASSUMPTIONS & LIMITATIONS

• The data/information entered by the user is assumed to be correct.

• Room information and room rates are assumed to not change.



10. CONCLUSION AND REFERENCES

This project is designed to meet the requirements of Hotel Management System. It has

been developed in visual basic and MS Access keeping in mind the specifications of the

system. The Hotel Management System’s objectives are to provide a system to manage a

hotel that has increased in size to a total of 100 rooms. Without automation the

management of the hotel has become an unwieldy task. The end users’ day-to-day jobs

of managing a hotel will be simplified by a considerable amount through the automated

system. The system will be able to handle many services to take care of all customers in

a quick manner. The system should be user appropriate, easy to use, provide easy

recovery of errors and have an overall end user high subjective satisfaction.

REFERENCES

THE SOFTWARE PROJECT MANAGER’S HANDBOOK - PRINCIPLES

THAT WORK AT WORK – By Dwayne Philips

SOFTWARE PROJECT MANAGEMENT – A PRACTITIONER’S APPROACH

– By E.M.Bennatan

http://www.123eng.com

www.ignoujugaad.com/Project/


Documents

ATM_DOC