Experiment No: 2 A STUDY EXPERIMENT ON …chettinadtech.ac.in/storage/12-02-07/12-02-07-10-09-24...ATM System Computer Science and Engineering OOSD Lab STUDY EXPERIMENT ON RATIONAL

ATM System

Computer Science and Engineering OOSD Lab

Experiment No: 2

A STUDY EXPERIMENT ON RATIONAL ROSE

Experiment Date:

ATM System


STUDY EXPERIMENT ON RATIONAL ROSE

AIM:-

To study the basic concepts of Unified Modeling Language.

UML NOTATION

Unified Modeling Language.

Set of notations and conventions used to describe and model an application.

Universal language for modeling systems.

Standard notation for OO modeling systems.

Does not specify methodology to develop an application.

UML DIAGRAMS

Class Diagram

Use Case Diagram

Behavioral Diagram

Interaction Diagram

Sequence Diagram

Collaboration Diagram

State Chart Diagram

Activity Diagram

Implementation Diagram

Component Diagram

Deployment Diagram

ATM System


CLASS DIAGRAM

Shows the static structure of the model.

Collection of static modeling elements such as classes and their relationships

connected as a graph.

Provides visual representation of objects, relationships and their structures.

Class:-

A class is a set of objects that share a common structure and common behavior.

It is represented as:

Interface:-

Specifies the externally-visible operations of a class and/or component.

Association:-

Model properties of associations.

The properties are stored in a class and linked to the association relationship.

Example,

Generalization:-

A generalize relationship is a relationship between a more general class or use

case and a more specific class or use case.

Example,

<Class Name>

<Attributes>

<Operations>

Bank Account Person

ATM System


USE CASE DIAGRAM

Set of use cases enclosed by system boundary, communication association

between actors and use cases, and generalization among use cases.

Actors:-

External factors that interacts with the system from the user's perspective.

Use Cases:-

Set of scenarios that describe how actor uses the system.

Represented as,

Relationship:-

Communication – communications with the use case normally.

Uses – Shown by generalization arrow from the use cases.

Extends – Used when one case does more than another that is similar to it.

Vehicle

TruckBus Car

ATM System


BEHAVIOR DIAGRAM

INTERACTION DIAGRAM

Diagrams that describes how group of objects are collaborated.

SEQUENCE DIAGRAM:

Describes the behavior of the system through interaction between the system and

the environment in time sequence.

Two dimensions:

Vertical dimension – represents time.

Horizontal dimension – represents objects.

Life line – Object's existence during the interaction.

<Event>

COLLABORATION DIAGRAM:

An interaction diagram that shows the order of messages that implement an

operation or a transaction.

Collaboration diagrams show objects, their links, and their messages.

1. <Event>

Object:-

An object has state, behavior, and identity.

Object 1 Object 2

Object 1 Object 2

ATM System


Objects interact through their links to other objects.

Link:-

A link is an instance of an association, analogous to an object.

Message:-

A message is the communication carried between two objects that trigger an

event.

STATECHART DIAGRAM

Models the dynamic behavior of individual classes or any other kind of object.

Shows the sequences of states, events, and actions.

State:-

Represents a condition or situation during the life of an object during which it

satisfies some condition or waits for some event.

Start State:-

Shows the beginning of workflow.

End state:-

Represents the final or terminal state.

ACTIVITY DIAGRAM

Used for modeling the sequence of activities in a process

Special case of a state machine in which most of the states are activities and most

of the transitions are implicitly triggered by completion of the actions in the

source activities.

<State>

ATM System


Activity:-

Represents the performance of task or duty in a workflow.

Swim lanes:-

Represents organizational units or roles within a business model.

IMPLEMENTATION DIAGRAM

Shows the implementation phase of system development.

Two types of implementation diagrams:

Component diagram

Deployment diagram

COMPONENT DIAGRAM

Models the physical components in the design.

A graph of the design’s components connected by dependency relationships.

Includes concept of packages.

Package is used to show how classes are grouped together.

DEPLOYMENT DIAGRAM

Shows the configuration of runtime processing elements and software

components.

It is a graph of nodes connected by communication association.

Nodes are the components that are connected to other components through

dependencies.

Used in conjunction with component diagrams to show the distribution of

physical modules.

<Activity>

ATM System


RESULT:-

Thus the different conceptual models under UML have been studied.

ATM System


Experiment No: 3

SOFTWARE REQUIREMENTS SPECIFICATION FOR ATM SYSTEM

Experiment Date:

ATM System


SOFTWARE REQUIREMENT SPECIFICATION

Aim:

The aim of the experiment is to prepare and Document the Software Requirements

Specification for the project “ATM System”

1. Introduction

1.1 Purpose

1.2 Scope

1.3 Definition, Acronyms, and Abbreviations

1.4 Reference

1.5 Overview

2. Overall Description

2.1 Product Perspective

2.1.1 System Interfaces

2.1.2 User Interfaces

2.1.3 Hardware Interfaces

2.1.4 Software Interfaces

2.1.5 Communication Interfaces

2.1.6 Memory Interfaces

2.1.7 Operations

2.1.8 Site Adaptation Requirements

2.2 Product Functions

2.3 User Characteristics

2.4 Constraints

2.5 Assumptions and Dependencies

ATM System


3. Specific Requirements

3.1 External Interfaces Requirements


Login Screen

User details

Account details

Administrator

3.1.2 Hardware Interfaces



3.2 Software Product Features

3.2.1 Question Details Maintenance

3.2.2 Administrator Details Maintenance

3.2.3 Report Generation

3.3 Performance Requirements

3.4 Design Constraints

3.5 Software System Attributes

3.6 Logical Database Requirements

3.7 Other Requirements

1. Introduction

This document aim to defining the overall software requirements for “ATM system”.

The final product will entirely depend on this documentation.

1.1 Purpose

This specific documentation describes the capabilities that will be provided by the

software application “ATM System”. It also defines the required constraints of the

system and it is useful for development team, testing and end users of the product.

ATM System


1.2 Scope

The main of this project is to implement online Atm system. Here this will provide a time

safety for the user to make transactions.

This project has the following features:

Registration process.

Account process.

Amount withdraw process.

1.3 Definitions Acronyms and Abbreviation

ATM – Automatic Teller Machine.

ACC NO- .Account Number

1.4 Reference

(i) IEEE Recommended practice for SRS IEEE Standard 830-1993

(ii) “Object Oriented Analysis and design” Ali Bahrami, Object Oriented System

Development, using UML, McGraw –Hill international Edition, 1999

1.5 Overview

The SRS document gives an idea about the requirements and features of the system.

2 Overall Descriptions

The system Atm is developed to automate the Atm system in Work places.

2.1 Product Perspective

The application will be a window-based, independent software product.

2.1.1 System Interfaces

None

ATM System



The following are the screen provided in the application.

Login Screen.

User name and password.

User registration.

Question and answer.

2.1.3 Hardware Interface

Minimum Requirements of the system.

Processor-486D/66Mhzor higher processor (Pentium)

Memory- 16MB of RAM

Monitor- 17Inch monitor

CD RW Drive-52X

USB Port

Printer


Operating system-Windows XP

Front End Tool –Visual Basic 6.0

Back End Tool-Oracle

UML Software- Star UML5.0


Not required

2.1.5 Memory Constraints

Hard Disk-5GB

RAM – 128MB

ATM System


2.1.6 Operations

Insert- insert the questions in the database

Delete- delete the questions from the database

Update- update the questions and answers in the database

View - view the result from the database

2.1.7 Site Adaptation Requirements

The stand alone system must able to support the hardware and software interfaces.

2.2 Product Functions

A summary of major functions that the software will perform.

2.3 User Characteristics

Administrator - he must know how to operate the software. He must have a

technical knowledge to handle the system. He must be able to upload the question

User - he must how to operate the software and with draw the Amount.

2.4 Constraints

The developed system is meant for standalone system only. So it cannot be used for on

line management.

2.5 Assumptions and Dependencies

The user details in the database entirely depend upon the information provided in login

that are provided by the administrator.

Atm system works on the assumption that the user attends the test.

3 Specific Requirements

This section contains the software requirements to a level of detail sufficient to enable

designers to design the system and tester to test the system.

ATM System


3.1 External Interface Requirements

• User Interface

• Amount withdrawal:

• Pin No:

• Account Details:

• Balance Enquiry:

3.2 Login screen

Username: String of the alphabets of length up to 8

Password: String of Alphabets of Length up to 6

Role: Two types of role will be there Administrator, user and coordinator.

3.1.1 Main Menu Screen

User details

Account details

Balance details.

Amount Withdrawal.

3.1.2 Hardware Interface

Minimum Requirements of the system.

Processor-486D/66MHzor higher processor (Pentium)

Memory- 16MB of RAM

Monitor- 17Inch monitor

CD RW Drive-52X

USB Port

Printer

ATM System



Operating system-Windows XP

Front End Tool –PHP

Back End Tool-MYSQL

UML Software- Star UML5.0


• Not Required

3.2 Software Product features

Account detail maintenance

User detail maintenance

3.2.1 Account Details maintenance

Description:

It contains the details of the Account holders and their respective Bank account

Details. Sequencing information

Error Handling/Response to abnormal

3.2.2 User Detail Maintenance

Description:

It contains the details of the user such as user name, Acc no, Amount details, address,

age, branch, job etc.

Sequencing information

Error Handling/Response to abnormal

3.2.3 User details Report

Name user_id Password address age

ATM System


3.3 Performance requirements

None

3.4 Design Constraints

None

3.5 Software System Attributes

Usability: It is used to write the test through online and reduce manpower. it is

computerized.

3.6 Logical Database Requirements

The following information will be placed in the database

User Details: User details includes user name, type of account, address, age etc.

ACcount Details: Account details include the balance details,account duration etc.

3.7 Other Requirements

None

ATM System


Result:

The Software Requirements Specification for the project “ATM SYSTEM” has

been analyzed and documented successfully.

ATM System


Experiment No: 4

OBJECT ORIENTED DESIGN FOR ATM SYSTEM

Experiment Date:

ATM System


OBJECT ORIENTED DESIGN FOR ATM SYSTEM

AIM:

The aim of the experiment is to prepare document and the object oriented diagram for the

project ATM System.

USE CASE DIAGRAM:

Set of use cases enclosed by system boundary, communication association

between actors and use cases, and generalization among use cases.

ACTORS:

User

Machine

SENARIOS

Enter pin number

Pin code.

Pin Accept.

Balance.

Amount With draw.

Fee pay.

Collect Cash.

Exit.

ATM System


CLASS DIAGRAM:

Shows the static structure of the model.

Collection of static modeling elements such as classes and their relationships

connected as a graph.

Provides visual representation of objects, relationships and their structures.

Classes used:

System.

Administrator

User.

Attributes for System

Verify.

Calculate.

Update.

ATM System


Attributes for System Administrator

Checking

Providing password

Maintain Account.

Attributes for User

Enter value

Pin no, and Acc no

SEQUENCE DIAGRAM:

Describes the behavior of the system through interaction between the system and

the environment in time sequence.

Two dimensions:

Vertical dimension – represents time.

Horizontal dimension – represents objects.

Life line – Object's existence during the interaction.

ATM System


: UserCardReader Screen Customer

AccountCash

dispatches

insert the card

Read Card No

Invalid Card(OP)

Initialize Screen

Activate Account

Prompt for pin

Enter the pin no

Prompt for transaction

Invalid pin no(OP)

Cash withdraw

Prompt for amount

Enter the amount

Check balance

Verify funds

Detect funds

Invalid query

Provide cash

Provide reciept

Collect cash and reciept

Eject card

OBJECTS FOR User:

ATM System


Card Reader

Screen

Customer Account

Cash Dispatch.

SEQUENCES FOR User Module:

Insert the card

Read Card No

Invalid Card Operation

Initialize screen

Active Account.

Prompt for Account.

Enter the pin number

Invalid pin no

Cash withdraw

Invalid query

Check balance

Verify Funds

Detect Funds

Provide Cash

Provide Receipt

Eject Card

ATM System


Screen : Machine

Card reader Customer Account

Cash dispatches

Prompt for amount

Provide cash and receipt

accept card

Accept pin no

Account verified

Transaction details

SEQUENCES FOR MACHINE:

Accept card

Accept Pin no

Account Verified

Transaction Details

Prompt for Amount.

ATM System


COLLABORATION DIAGRAM:

An interaction diagram that shows the order of messages that implement an

operation or a transaction.

Collaboration diagrams show objects, their links, and their messages.

A link is an instance of an association, analogous to an object.

COLLABORATION FOR USER:

: User

CardReader

Screen

Customer Account

Cash dispatches

2: Read Card No

14: Verify funds15: Detect funds

1: insert the card

3: Invalid Card(OP)20: Eject card 4: Initialize Screen

5: Activate Account

6: Prompt for pin8: Invalid pin no(OP)

9: Prompt for transaction11: Prompt for amount

7: Enter the pin no10: Cash withdraw

12: Enter the amount

13: Check balance

16: Invalid query

17: Provide cash18: Provide reciept

19: Collect cash and reciept

ATM System


COLLABORATION FOR ADMINISTRATOR:

: Machine

Card reader

Screen

Customer Account

Cash dispatches

5: Prompt for amount6: Provide cash and receipt

1: accept card

2: Accept pin no4: Transaction details

3: Account verified

STATE CHART DIAGRAM:

Models the dynamic behavior of individual classes or any other kind of object.

Shows the sequences of states, events, and actions.

OBJECTS:

Card reader

Pin code

Balance

ATM System


Withdraw

Receive Cash

OPERATIONS:

Insert Card

Enter Pin no

Verify Balance

Prompt for Withdraw

Collect Cash

Receipt

ATM System


Pin code

Card reader

Balance

Receive cash,receipt

Insert card

Withdraw

Enter pin

Verify balance

Prompt for withdraw

Collect cash,receipt

ATM System


COMPONENT DIAGRAM:

Models the physical components in the design.

A graph of the design’s components connected by dependency relationships.

Includes concept of packages.

Package is used to show how classes are grouped together.

COMPONENTS USED:

ATM.Exe

Transaction

Verification

ATM.Exe

Transaction verification

Transaction.cpp verification.cpp

ATM System


DEPLOYMENT DIAGRAM:

Shows the configuration of runtime processing elements and software

components.

It is a graph of nodes connected by communication association.

Nodes are the components that are connected to other components through

dependencies.

Used in conjunction with component diagrams to show the distribution of

physical modules.

ATM.exe

ATM System


RESULT

The Object Oriented Design for the project “ATM System” using Star UML

software design is completed successfully.

ATM System


Experiment No: 5

STUDY OF SOFTWARE TESTING PROCESS

Experiment Date:

ATM System


STUDY OF SOFTWARE TESTING PROCESS

AIM:

To study about the software testing process this includes various levels approaches and

types of testing.

5.1. OVERVIEW:

The importance of software testing to software quality can not be

overemphasized. Once source code has been generated, software must be tested to allow

errors to be identified and removed before delivery to the customer. While it is not

possible to remove every error in a large software package, the software engineer’s goal

is to remove as many as possible early in the software development cycle. It is important

to remember that testing can only find errors, it cannot prove that a program is bug free.

Two basic test techniques involve testing module input/output (black-box) and exercising

internal logic of software components (white-box). Formal technical reviews by

themselves can not find allow software defects, test data must also be used. For large

software projects, separate test teams may be used to develop and execute the set of test

cases used in testing. Testing must be planned and designed. The SEPA web site contains

the template for a generic test plan.

5.1.1. Software Testing Objectives:

Testing is the process of executing a program with the intent of finding

errors.

A good test case is one with a high probability of finding an as-yet

undiscovered error.

A successful test is one that discovers an as-yet-undiscovered error.

5.1.2. Software Testing Principles:

All tests should be traceable to customer requirements.

ATM System


Tests should be planned long before testing begins.

The Pareto principle (80% of all errors will likely be found in 20% of

the code) applies to software testing.

Testing should begin in the small and progress to the large.

Exhaustive testing is not possible.

To be most effective, testing should be conducted by an independent

third party.

5.1.3. Software Testability Checklist:

Operability (the better it works the more efficiently it can be tested)

Observably (what you see is what you test)

Controllability (the better software can be controlled the more testing

can be automated and optimized)

Decomposability (by controlling the scope of testing, the more quickly

problems can be isolated and retested intelligently)

Simplicity (the less there is to test, the more quickly we can test)

Stability (the fewer the changes, the fewer the disruptions to testing)

Understandability (the more information known, the smarter the

testing)

5.1.4. Good Test Attributes:

A good test has a high probability of finding an error.

A good test is not redundant.

A good test should be best of breed.

A good test should not be too simple or too complex.

5.1.5. Test Case Design Strategies:

ATM System


Black-box or behavioral testing (knowing the specified function a

product is to perform and demonstrating correct operation based solely

on its specification without regard for its internal logic)

White-box or glass-box testing (knowing the internal workings of a

product, tests are performed to check the workings of all independent

logic paths)

5.2. TESTING METHODS:

5.2.1. Basis Path Testing

White-box technique usually based on the program flow graph

The cyclomatic complexity of the program computed from its flow

graph using the formula V(G) = E – N + 2 or by counting the

conditional statements in the PDL representation and adding 1

Determine the basis set of linearly independent paths (the cardinality

of this set id the program cyclomatic complexity)

Prepare test cases that will force the execution of each path in the basis

set.

5.2.2 Control Structure Testing:

White-box techniques focusing on control structures present in the

software

Condition testing (e.g. branch testing) focuses on testing each decision

statement in a software module, it is important to ensure coverage of

all logical combinations of data that may be processed by the module

(a truth table may be helpful)

ATM System


Data flow testing selects test paths based according to the locations of

variable definitions and uses in the program (e.g. definition use chains)

Loop testing focuses on the validity of the program loop constructs

(i.e. simple loops, concatenated loops, nested loops, unstructured

loops), involves checking to ensure loops start and stop when they are

supposed to (unstructured loops should be redesigned whenever

possible)

5.2.3 Graph-based Testing Methods:

Black-box methods based on the nature of the relationships (links)

among the program objects (nodes), test cases are designed to traverse

the entire graph

Transaction flow testing (nodes represent steps in some transaction

and links represent logical connections between steps that need to be

validated)

Finite state modeling (nodes represent user observable states of the

software and links represent transitions between states)

Data flow modeling (nodes are data objects and links are

transformations from one data object to another)

Timing modeling (nodes are program objects and links are sequential

connections between these objects, link weights are required execution

times)

5.2.4. Comparison Testing:

Black-box testing for safety critical systems in which independently

developed implementations of redundant systems are tested for

conformance to specifications

ATM System


Often equivalence class partitioning is used to develop a common set

of test cases for each implementation

5.2.5. Orthogonal Array Testing:

Black-box technique that enables the design of a reasonably small set

of test cases that provide maximum test coverage

Focus is on categories of faulty logic likely to be present in the

software component (without examining the code)

Priorities for assessing tests using an orthogonal array

a. Detect and isolate all single mode faults

b. Detect all double mode faults

c. Multimode faults

5.3. UNIT TESTING:

Black box and white box testing.

Module interfaces are tested for proper information flow.

Local data are examined to ensure that integrity is maintained.

Boundary conditions are tested.

Basis path testing should be used.

All error handling paths should be tested.

Drivers and/or stubs need to be developed to test incomplete software.

5.4. INTEGRATION TESTING:

5.4.1. Top-down integration testing:

Main control module used as a test driver and stubs are substitutes for

components directly subordinate to it.

ATM System


Subordinate stubs are replaced one at a time with real

components(following the depth-first or breadth-first approach).

Tests are conducted as each component is integrated.

On completion of each set of tests and other stub is replaced with a

real component.

Regression testing may be used to ensure that new errors not

introduced.

5.4.2. Bottom-up integration testing:

Low level components are combined in clusters that perform a specific

software function.

A driver (control program) is written to coordinate test case input and

output.

The cluster is tested.

Drivers are removed and clusters are combined moving upward in the

program structure.

Regression testing (check for defects propagated to other modules by

changes made to existing program)

Representative sample of existing test cases is used to exercise all

software functions.

Additional test cases focusing software functions likely to be affected

by the change.

Tests cases that focus on the changed software components.

5.4.3. Smoke testing:

Software components already translated into code are integrated into a

build.

ATM System


A series of tests designed to expose errors that will keep the build from

performing its functions are created.

The build is integrated with the other builds and the entire product is

smoke tested daily (either top-down or bottom integration may be

used).

5.5. VALIDATION TESTING:

Ensure that each function or performance characteristic conforms to its

specification.

Deviations (deficiencies) must be negotiated with the customer to

establish a means for resolving the errors.

Configuration review or audit is used to ensure that all elements of the

software configuration have been properly developed, cataloged, and

documented to allow its support during its maintenance phase.

5.6. ACCEPTANCE TESTING:

Making sure the software works correctly for intended user in his or

her normal work environment.

Alpha test (version of the complete software is tested by customer

under the supervision of the developer at the developer’s site)

Beta test (version of the complete software is tested by customer at his

or her own site without the developer being present)

5.7. SYSTEM TESTING:

Recovery testing (checks the system’s ability to recover from failures)

Security testing (verifies that system protection mechanism prevent

improper penetration or data alteration)

ATM System


Stress testing (program is checked to see how well it deals with

abnormal resource demands – quantity, frequency, or volume)

Performance testing (designed to test the run-time performance of

software, especially real-time software)

ATM System


RESULT:

Study of software testing process has been completed and documented

successfully.

ATM System


Experiment No: 6

PROJECT PLAN FOR ATM SYSTEM

Experiment Date:

ATM System


PROJECT MANAGEMENT PLAN

AIM

The aim of the experiment is to prepare and document the project management plan

for the project “ATM SYSTEM

6.1 Introduction

6.1.1 Purpose

Project management plan describes the software life cycle of ATM SYSTEM based test

plan and resource plan of ATM SYSTEM.

6.2 Process Model

This ATM SYSTEM is developed by applying incremental model. The product is

designed, implemented, integrated and tested as series of incremental development

activities. The development activities consist of code pieces from various modules

interacting to provide a specific functional capability. This model delivers the quality

system and sub systems. The complete product is divided into several sub parts, and the

developers deliver the product in series of incremental development activities. It reduces

the traumatic effect of imposing a completely new ATM SYSTEM. From the financial

viewpoint, phased delivery does not require large outlay. In this model not necessary to

complete the product to get a return on investment. Instead, the client can stop

development of the product at any time.

Incremental model, the requirements, specifications, planning and architecture design

must all complete before implementation of the various sub systems. The client

requirements have been complete, the specification of the build draw up. When this has

been complete the specification team turns to the specification of the second build while

design team designs the first sub system. The various sub systems are constructed

parallel. Four increment in ATM SYSTEM.

ATM System


Fig: 6.1 Incremental Models for ATM SYSTEM

Requirements for ATM SYSTEM

ATM SYSTEM specification

ATM planning

ATM SYSTEMarchitectural design

Implementation

Incremental delivery

Operational mode of ATM System

Maintenance

Enter the username/password

Check the pin number and begin transaction

Perform the withdraw or fee pay operation

ATM System


6.2.1 Project milestones

Project milestones are describe the project started, project plan, project schedule,

analysis, design, implementation, testing and documentation for each increment .

Table 6.2 Project Milestones

Mile Stones Date Status

ATM Project started 14-Dec-2010 Completed

ATM System Segment Specification 14-Dec-2010 Completed

ATM Project Management Plan 14- Dec -2010 Completed

ATM Software Requirement Specification 14- Dec -2010 Completed

ATM Software Test Plan 14- Dec -2010 Completed

Develop modules and integrate it.

Increment phase 1: login module

Subsystem Analysis & Design 22-Dec-2010 Completed

Implemented 22- Dec -2010 Completed

Module testing activities completed 30- Dec -2010 Completed

Documentation 30- Dec -2010 Completed

Increment phase 2: Account details Operation Modules

Subsystem Analysis & Design 7- Jan -2011 Completed

Implemented 7- Jan -2011 Completed

Module testing activities completed 27- Jan -2011 Completed

Documentation 27-Jan-2011 Completed

Increment phase 3: report module

Subsystem Analysis & Design 3- Feb -2011 Completed

Implemented 3- Feb -2010 Completed

Module testing activities completed 10- Feb -2011 Completed

Documentation 10-Feb-2011 Completed

Increment phase 4: Implementation and Testing

Integrate developed modules 18- Feb -2011 Completed

ATM System


Testing 18- Feb -2011 Completed

Software Test Report 18- Feb -2011 Completed

Software Configuration Management Plan 12- Mar -2011 Completed

Software Deployment 12- Mar-2011 Completed

Software Maintenance 12- Mar -2011 Completed

Increment phase 5: Project Documentation

Feasibility study 22-Mar-2011 Completed

Implementation 22-Mar-2011 Completed

Test Documentation 22-Sep-2011 Completed

ATM System


RESULT:

The Project Plan for the project “ATM System” has been analyzed and documented

successfully.

ATM System


Experiment No: 7

SYSTEM ANALYSIS SPECIFICATION FOR ATM SYSTEM

Experiment Date:

ATM System


SYSTEM ANALYSIS SPECIFICATION FOR ATM SYSTEM

AIM: Aim of the experiment is to prepare and document the software analysis specification for “Atm System”.

7.0 INTRODUCTION

7.1 Purpose

This document is used to capture the output of system level requirements analysis of

Atm System. This document clearly describes the functional and non functional

requirements of the system, and overall development of the Atm System. It specifies a

high level requirements specification model in terms of UML methodology.

7.2 Scope

Scope of the Atm System is to reduce the answering time and generating the report.

7.3 References:

(i) IEEE Recommended practice for SRS IEEE Standard 830-1993

(ii) “Object Oriented Analysis and design” Ali Bahrami, Object Oriented System

Development, using UML, McGraw –Hill international Edition, 1999

7.3.1 Government Documents

DOD 2167A Defense Standard Software Development

7.3.2 Non Government Documents

Ali Bahrami, Object Oriented System Development, using UML, McGraw –Hill

international Edition, 1999

Software Engineering Book

7.4 System Overview

The main problem addressed is to automate the quiz in companies. The ultimate aim

to reduce the manpower and it is computerized.

2 Functional Requirements

Use case for Atm System

ATM System


Fig: 7.1Use Case for Atm System.

Actors

Participant

System

System Administrator

Organizer

Use Case

Create

Delete

Update

Analyze

ATM System


1 Scenarios:

Scenario starts

when

Actor Trace Action Output

organizer enters the question in the user database

Administrator Create the

database which

contains the

student details

Verifies the

database

Displays the

database

Participant Details of the

Question

Verifies the

Answer details

Displays the

database which

contains the

Answer details

about the

Question.

System Details of the

Question

Verifies the

Answer

Checks the

marks of each

Question

2 Non-Functional Requirements

Usability (ATM System)

The Atm System is used to attend the online test in a computerized manner.

3 Metrics for system Analysis and Specification

Metrics are units of measurement of Atm System. The term “metrics” is also

frequently used to mean a set of measurement taken on a particular item or process of

Atm System.

Software engineering metrics are units of measurement that are used to

characterize:

Software engineering Products for Atm System, e.g. designs, source code and

test cases.

ATM System


Software engineering Processes for Atm System, e.g. the activities of analysis,

designing, and coding.

Software engineering People for Atm System, e.g. the efficiency of an individual

tester, or the productivity of an individual designer. To measure the Atm System

for each increment of Atm System.

Table 2 Metrics for System Analysis and Specification

MPID Quiz_SAS_MP_1

Metrics Attributes Planned/Estimated Actual Deviation Remarks

Increment 1:Login Screen

Start Date:10-Jul-10 End Date:30-Jul-10

Schedule 15(Days) 18(Days) +2 Nil

Size 12(Days) 15(Days) +2 Nil

6(UC) 5(UC) +1 Nil

Effort 2 2 0 Specificatio

n

Developer

and

Reviewer

Number of system

requirements

4 5 +1 Nil

Training of

domain and

requirement

collection

2 2 0 Nil

Review 2 1 -1 Due to

training one

review has

reduced

ATM System


Increment 2:Question Details

Start Date:2-Aug-10 End Date:25-Aug-10


Size 5(Days) 7(Days) +2 Nil

6(UC) 5(UC) +1 Nil

Effort 2 2 0 Specification

Developer and

Reviewer

Number of system

requirements

4 5 +1 Nil

Training of

domain and

requirement

collection

2 2 0 Nil


training one

review has

reduced

Increment 3:Administrator module

Start Date:27-Aug-10 End Date:18-Sep-10


Size 10(Days) 10(days) 0 Nil

6(UC) 5(UC) +1 Nil


Developer and

Reviewer

Number of system

requirements

4 5 +1 Nil

Training of 2 2 0 Nil

ATM System


domain and

requirement

collection


training one

review has

reduced

Increment 4:Report Generation

Start Date:19-sep-10 End Date:30-Sep-10

Schedule 6(Days) 7(days) +1 Nil

Size 5(Days) 4(Days) -1 Nil


Developer and

Reviewer

Number of system

requirements

4 5 +1 Nil

Training of domain

and requirement

collection

2 2 0 Nil


training one

review has

reduced

7.4 Quality Record

7.4.1 System Specification Review Checklist

Quality record is used to improve the quality of ATM System

ATM System


Table 3 Checklist for System Specification Review:

Check list ID Quiz_SAS_Q_CHECKLIST_01

Project Atm System PHASE System

Analysis and

Specification

Subject System Specification Review

Originator DATE 22-Mar-11

Y/N Note

*Is it complete?

*Is it up-to-date (version, date)?

Yes

Yes

Nil

Nil

1. Is the Feasibility study over?

2. Have you identified the major

requirement for

Atm System?

3. Have you traced all use cases for Quiz

System?

4. Have you design milestone plan for the

project?

5. Have you follow INDIAN standard in

the system

Specification document?

6. Have you made the metrics for system

analysis?

7. Has the system specification document

reviewed

and authorized?

8. Is the metrics for system specification

verified and

Authorized?

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Yes

Nil

Nil

Nil

Nil

Nil

Nil

Nil

Nil

ATM System


9. Have you done any root cause analysis

for

Defects?

10. Does the analysis finish with in the

duration?

Yes

Yes

Nil

Nil

Authorized/Reviewed by:

7.4.2 Inspection and Review Report

The primary goal of the inspection process is to eliminate defects from a given, well defined work product. Inspect and review the System Analysis and Specification of Re (Atm System).

Table 7.4 Inspection and Review Report for System Specification Review:

IRR ID Atm System _SAS_Q_REPORT_1

PROJECT Atm System PHASE System AnalysisAnd

Specification

Subject System Specification Review

Originator DATE 14-Dec-11

Peer Review Complete (Y/N) YES Peer Reviewer

Review Complete (Y/N) YES

If Review IncompleteModerator’s recommendation for action Rework/Reconvene/Re-Review/Abandon

ATM System


Commands: Inspection and Review Report for System Specification Review is verifiedCorrectly.

Signed:

Project Manager’s Decision: Inspection and Review Report for System SpecificationReview is verified correctly.

Signed.

ATM System


RESULT

The Software Analysis Specification for the project “ATM System” has been

analyzed and documented successfully.

ATM System


Experiment No: 8

TEST PLAN FOR THE ATM SYSTEM

Experiment Date:

ATM System


TEST PLAN FOR THE ATM SYSTEM

AIM: Aim of the experiment is to prepare and document the test plan for the project ATM SYSTEM.

8.1 Introduction

8.1.1 Purpose

The main purpose of this document is to achieve the 100% functionally correct system

and to ensure all functional and design requirements are implemented as specified in the

documentation. It also provides a procedure, identified of the documentation process and

test methods for system level testing.

8.2 Test Identification

8.2.1.1 Test Item

All the required items will be tested during the system test.

The following documents will provide the basis for defining correct operation.

Software requirements

Software design description.

8.2.1.2 Registration process

This process is used for the user to register into the system and the entire registration is

stored in the Administrator.

8.2.1.3 Account generation

The account process is one in which the Account details are being generated and

activated.

8.2.1.1.3 Report generation.

The reports of the answer details are generated.

Test GUI display

Test interface with display unit.

8.3 Features to be tested

The following functionalities of the Atm System to be tested for functional correctness

Enters the pin no.

ATM System


View the process

Perform operations.

Choose the options.

Withdraw or balance enquiry

Generate the result.

8.4 Test Approach

8.4.1 Test Levels

Atm System is to be tested in different levels like unit, integration, system level.

All programs like getting the request, Analysis the request are to be tested at unit

level by developer themselves.

All modules like Registration module, question and answer module, report

module are to be tested individually.

The whole Atm System is tested after integration i.e., Integration testing, the main

emphasis is the functionality and the integration.

The entire system is tested by stress testing for find out the whether system is

properly functioning in critical environment.

The acceptance testing is find out the Atm System achieve the corresponding goal

or not.

8.4.2 Test Classes

8.4.2.1 User Interface Testing for Atm System

User interface testing verifies a user’s interaction with the software. The goal of UI

testing is to ensure that the user interface provides the user with the appropriate access

and navigation through the functions of the Atm System. In addition, UI testing ensure

that the objects within the UI functions as expected and conform to corporate or industry

standards.

Test Objective

Verify following:

ATM System


Navigation through the Quiz application properly reflects business functions and

requirements, including window-to-window, field-to-field and use of access

methods (tab keys, mouse movements, accelerator keys).

Window objects and characteristics, such as menus, size position, state and focus

conform to GUI.

Technique

Create or modify test for each window to verify proper navigation and object states for

each application window and objects.

Completion Criteria

Each window successfully verified to consistent with benchmark version or within

acceptable standard.

8.4.2.2 Load Testing of Atm System

The goal of load testing is to determine and ensure that the system functions properly

beyond the expected maximum workload. Additionally, load testing the performance

characteristics are vary from line to line depend on the speed of the line.

Test Objective

Verify performance behavior time for designated functions or business cases under

varying workload conditions.i.e. To test whether the communication interface and

processing model are properly working in huge network environment

Completion Criteria

Many no of active systems or huge network environment: successful completion of test

without any failures within acceptable time allocation.

8.4.2.3 Security Testing

The goal of Security Testing is to ensure system security capability.

If the system is compromised with attackers then it should reflect what are the activities

made by attacker like tools, techniques etc. The processing module captures all the

information from Atm System.

8.4.2.4 Recovery Testing

ATM System


Recovery will be tested by halting the machine during stand alone time and then

following recovery procedures.

8.4.2.5 Performance Testing

Performance will be evaluated against the performance requirements by measuring the

run times of several jobs using production data volumes.

8.4.2.6 Regression Testing

It is assumed that several iterations of the system test will be done in order to test

program modifications made during the system test period. A regression test will be

performed for each new version of the system to detect unexpected impact resulting from

modifications.

8.4.2.7 General test conditions

General test conditions describe conditions that apply to all of the test or to a group of

tests in Atm System. Each test shall include nominal, maximum, minimum values,

execution size and time shall be measured for each Atm System. Include shall be

statement of the extent of testing to be performed and rational for the extent selected. The

extend of testing shall be expressed as a percentage of some well defined total quality,

such as the number of samples of discrete operating conditions or values, or other

sampling approach. Also included some approaches to be followed for

retesting/regression testing.

8.4.2.8 Data recording, reduction and analysis

Data recording, reduction and analysis procedures to be used during and after the test’

identified in this Atm System test plan. These procedures shall include, as applicable,

manual, automatic, and semi automatic techniques for recording test results, manipulating

the raw results into a form suitable for evaluation, and retaining of data reduction and

analysis. To record all test level and test classes, if any faults is there to record that, and

also give the solution to reduce that faults.

8.4.3 Planned Test

8.4.3.1 Basic function test

ATM System


Enter the user name.

Enter the password.

Choose the question type.

Write the exam.

Get the result

8.5 Item pass/ fail criteria

Pass criteria Atm System module outputs should be expected outputs.

Fail criteria not meet the expected outputs.

8.6 Test deliverables

The following documents will be generated by system test group and will be delivered to

the configuration management team after its completion.

Test documentation

System Test Plan

System Test Design specification

System Test Case Specification

System Test Procedures Specification

System Test Logs

System Test Incident Report Log

System Test Incident Reports

System Test Summary Report

Test data

1. Copies of all data entry and inquiry screens and the reply screens are to be attached to

the related test case document.

2. Copies of the input and output test files should be delivered to the configuration

management team.

8.7 Testing Tasks

Table 8.1 Testing Tasks

Task Special skills Responsibility Effort Finish date

ATM System


Prepare test

plan

Expertise in

software

Engineering

principles, good

knowledge of

computer

science.

Test manager,

senior test

analyst

3days 15-Dec-2011

Prepare test

design

specification

Knowledge of

ATM

Senior test

analyst

2days 23- Dec -2011

System Test

Case

Specifications

Knowledge of

ATM

Test analyst 2days 31- Dec -2011

System test

Procedure

specification

Knowledge of

ATM

Test analyst 2days 08- Jan -2011

Test Current

Locaion Reader

Knowledge of

PHP,MYSQL

and ATM

Test technician 1days 28-Jan-2011

Test the

Information

Processing

Knowledge of

PHP and

MYSQL

Test technician 1days 04-Feb-2011

Test Data

source Interface

Module

Knowledge of

Machines

Test technician 1days 11-Feb-2011

8.8 Environment needs

8.8.1 Software items

Windows xp

ATM System


PHP

MYSQL

Rational Rose

8.8.2 Hardware and Firmware Items

PC with P4 processor, 256 RAM, 40 GB HDD

8.8.3 Proprietary nature, acquire rights and licensing

Rational Rose is used to design and developed the software.

PHP is support to develop the software.

MY-SQL is used to compile.

8.9 Responsibility

Project Manager- Responsible for Project schedules and overall and the success of the

project

Test Leader- verify the test documents.

Tester Responsible for performing the actual system testing.

8.10 Staffing and training needs

Test manager -1

Senior Analyst -1

Test Analyst -2

Test Technician -1

Training

Skill needs

Basic knowledge of PHP

Basic knowledge of MYSQL

Strong knowledge in software Engineering principles

8.11 Schedule

System Test -- (5 hours)

Performance Test -- (7 hours)

Document Test -- (3 hours)

Unit Test -- (7 hours)

ATM System


User Acceptance Test -- (9 hours)

8.11 Risk and Contingencies

8.11.1 Schedule

The schedule for each phase is very aggressive and could affect testing. A slip in the

schedule in one of the other phase could result in a subsequent slip in the test phase. If the

testing schedule is significantly impacted by system failure, the project manager has

agreed to assign a full time person to the test team to co debugging.

8.11.2 Personnel

If one test analyst/technician is not available for testing, then the test manager has agreed

to identify a second analyst/technician. Due to the schedule, it’s very important to have

experienced testers on this project. Unexpected turnovers can impact the schedule. If

attrition does happen, all efforts must to replace the experienced individual.

8.11.3 Requirements

The test plan and test schedule are based on the current requirements document. Any

change to the requirements could affect the test schedule. Changes should be approved by

the project manager.

8.11.4 Technical

The hardware problems impact system availability during the day, then the test group will

schedule their activities during the evening. The first production runs of the Atm System

must be checked out in detail before the Atm System processes are distributed, and any

checks in error must be corrected by manually.

ATM System


RESULT:

The Test Plan for the project “ATM System” has been analyzed and documented

successfully.

ATM System


Experiment No: 1

PROBLEM STATEMENT FOR THE ATM SYSTEM

Experiment Date:

ATM System


AIM: Aim of the experiment is to prepare Problem Statement for the project ATM SYSTEM.

PROCEDURE:

1. ATM machine is mainly used for withdrawal money from any time.

2. In emergency case, we use only ATM machine system.

3. It has some additional feautures also such as Transfer funds, change PIN, checking balance enquiry and so on.

4. After getting cash, it provides confirmation receipt.

5. Using this ATM system, we save our time.

6. If we use ATM machine for withdrawal money, some procedural are follows,

Insert the ATM card to the machine, then the machine verify the card number.

Then it activate user accounts and it display the welcome screen.

Then it ask our four digits PIN no. If our PIN no correct means, it should display the next information such as cash withdraw, mini statement, etc. otherwise it should display PIN no not valid.

We select cash withdraw, and type how much amount we want.

If our amount exceeds our account balance, then it should display not enough balance in your account.

Then from cash dispensher, user collect the cash and receipt.

Finally we eject the card.

ATM System


RESULT:

The Problem Statement for the project “ATM System” has been Prepared

successfully.

ATM System


Experiment No: 9

IMPLEMENTATION FOR THE ATM SYSTEM

Experiment Date:

ATM System


AIM:

To prepare an implementation For the project “ATM SYSTEM”

PROCEDURE:

//WELCOME SCREEN

Data1.Refreshsd = TrueDim s As Strings = Text1.TextIf Data1.Recordset.EOF ThenMsgBox "Invalid Card No.", vbCritical, "Sorry! Plz Try Later"Text1.SetFocusText1.SelStart = 0Text1.SelLength = Len(Text1.Text)Exit SubElse Form2.Show Me.Hide SendKeys "{home}+{end}"End IfEnd Sub

Private Sub Command2_Click()EndEnd Sub

Private Sub Command3_Click()EndEnd Sub

Private Sub Command4_Click(Index As Integer)Text1.Text = Text1.Text + Command4(Index).CaptionEnd Sub

Private Sub Command5_Click()Text1.Text = ""End Sub

ATM System


Private Sub Form_Load()

On Error Resume NextSet db = OpenDatabase(App.Path & "\bankt.mdb")Text1.Text = ""SaveSetting "vikassoni", "StartupForm", "TimesRun", GetSetting("vikassoni", "StartupForm", "TimesRun", 0) + 1timesrun = GetSetting("vikassoni", "StartupForm", "TimesRun")MsgBox "The Program has been " & timesrun & " times started"If timesrun = 1 Or timesrun = 2 ThenMsgBox "After First You Started The Program Your Registry File Will Take Change"End IfEnd Sub

Private Sub Text1_KeyPress(KeyAscii As Integer)If KeyAscii = 13 ThenCall Command1_ClickEnd IfEnd Sub

Private Sub Text1_LostFocus()Text1.Text = UCase(Left(Text1.Text, 1)) & Mid(Text1.Text, 2)End Sub

ATM System


//PIN NO

Dim a As Integer

Private Sub Command1_Click() If Text1.Text = "" Then Text1.SetFocus Exit Sub End If Dim s As String s = Form1.Text1.Text Data1.DatabaseName = App.Path & "\bankt.mdb" Data1.RecordSource = "select * from verification where cardno='" & s & "'" Data1.Refresh If Data1.Recordset.NoMatch Then MsgBox "Please Try Later!", vbInformation, "Warning" Exit Sub End IfIf Data1.Recordset(3) <> Text1.Text Then a = a + 1If a = 1 Then b = MsgBox("Please Enter a Corect PIN", , "Enter") Text1.SetFocus Text1.SelStart = 0 Text1.SelLength = Len(Text1.Text)ElseIf a = 2 Then b = MsgBox("Please Enter a Corect PIN", , "Enter") Text1.SetFocus Text1.SelStart = 0 Text1.SelLength = Len(Text1.Text)ElseIf a = 3 Thena = MsgBox("Your ID will blocked Plz contact Branch Manager", , "Enter")Data1.Recordset.EditData1.Recordset("locked") = TrueData1.Recordset.UpdateEndEnd IfElseIf Data1.Recordset("pin") = Text1.Text Then If Data1.Recordset("locked") = True Then MsgBox "You Are Blocked By System Plz Contact Branch Manager" qq = MsgBox("Do you want nearest branch to you", vbYesNo) If qq = vbYes Then MsgBox "Sorry! All the lines are busy to this rout" End If

ATM System


Text1.Text = "" Exit Sub Else Text1.Text = "" Form7.Show Unload MeEnd IfEnd IfEnd SubPrivate Sub Command4_Click()Form1.ShowUnload MeEnd SubPrivate Sub Form_Load()On Error Resume NextData1.DatabaseName = App.Path & "\bankt.mdb"Data1.RecordSource = "select * from verification"Data1.RefreshText1.Text = ""Text1.PasswordChar = "*"End SubPrivate Sub Form_Paint()Text1.SetFocusEnd SubPrivate Sub Text1_Change()If Len(Text1) > 3 ThenCall Command1_ClickEnd IfEnd SubPrivate Sub Text1_KeyPress(KeyAscii As Integer)If KeyAscii = 13 ThenCall Command1_ClickEnd IfEnd SubPrivate Sub Text1_LostFocus()Text1.Text = LCase(Text1.Text)End SubPrivate Sub Text2_LostFocus()Text2.Text = LCase(Text2.Text)End SubPrivate Sub Text3_LostFocus()Text3.Text = LCase(Text3.Text)End Sub

ATM System


//MAIN MENUPrivate Sub Command1_Click()Form6.ShowUnload MeEnd Sub

Private Sub Command10_Click()Load Form4Form4.ShowUnload MeEnd Sub

Private Sub Command2_Click()Me.HideReport.ShowEnd Sub

Private Sub Command3_Click()Form3.ShowUnload MeEnd Sub

ATM System



Private Sub Command5_Click()Form1.ShowUnload MeForm1.Text1.Text = ""Form1.Text1.SetFocusEnd Sub

Private Sub Command6_Click()

Unload MeForm2.ShowEnd Sub

Private Sub Command7_Click()Me.HideForm11.ShowEnd Sub

Private Sub Command8_Click()a = Val(Data1.Recordset.Fields("balance"))MsgBox aIf a <= 100 ThenMsgBox "You cant pay your bill by atm sorry!"Unload MeForm7.ShowElseMe.HideForm9.ShowEnd IfEnd Sub

Private Sub Command9_Click()Unload MeForm8.ShowEnd Sub

Private Sub Form_Activate()Data1.Recordset.FindFirst "cardno ='" & Form1.Text1.Text & "'"

ATM System


End Sub

Private Sub Form_Load()Data1.DatabaseName = App.Path & "\bankt.mdb"Data1.RecordSource = "accounts"Data1.Refresh

End Sub

Private Sub Form_Paint()Command1.SetFocusEnd Sub

//CASH WITHDRAW

Private Sub Command1_Click()Dim s, d As DoubleIf Text1.Text = "" ThenText1.SetFocusMsgBox "Please Enter Amount Rupees", vbInformation, "Warning"Exit SubEnd IfData1.Recordset.MoveFirst

ATM System


Data1.Recordset.FindFirst "cardno='" & Form1.Text1.Text & "'"s = Val(Data1.Recordset("balance"))ww = Val(Text1.Text)If s <= ww Or s <= 100 ThenMsgBox ("You Can't Access Your Account" & vbCrLf & "'Low Balance")Else

If Right(Text1, 2) <> "00" Then MsgBox "Invalid Amount" & vbCrLf & "Enter amount which is divisible by 100", vbCritical, "Invalid Input" Text1 = "" Text1.SetFocus Exit SubEnd Ifd = s - wwData1.Recordset.EditData1.Recordset("balance") = Str(d)Data1.Recordset.UpdateData2.Recordset.AddNewData2.Recordset.Fields("cardno") = Form1.Text1.TextData2.Recordset.Fields("date") = NowData2.Recordset.Fields("amount") = wwData2.Recordset.UpdateMsgBox ("Completed")Text1.Text = ""End IfEnd Sub


Private Sub Form_Load()On Error Resume NextData1.DatabaseName = App.Path & "\bankt.mdb"Data1.RecordSource = "select * from accounts"Data1.RefreshEnd Sub

.

ATM System


Finally we receive cash and receipt from cash dispensher.

ATM System


RESULT:

Thus the above Atm System has been Implemented Successfully.