Project 2 Quarter 8 ATM SYSTEM

Huỳnh Thủy Ngân NIIT Cần Thơ
PROJECT ON
ATM SYSTEM
Developed by
Name: Huỳnh Thủy Ngân

ATM System Page 1
Huỳnh Thủy Ngân NIIT Cần Thơ
ATM SYSTEM
Batch Code : B120011
Start Date : 8
th
Jun 2012
End Date : 18
th
Jun 2012
Name of the Coordinator : Phạm Tiến Phúc
Name of the Developer : Huỳnh Thủy Ngân
Date of Submission : 20
th
Jun 2012
ATM System Page 2
Huỳnh Thủy Ngân NIIT Cần Thơ
NIIT
CERTIFICATE
This is to certify that this report, titled ATM System, embodies the original work done
by Huỳnh Thủy Ngân in partial of their course requirement at NIIT.
Coordinator: Phạm Tiến Phúc
ATM System Page 3
Huỳnh Thủy Ngân NIIT Cần Thơ
ACKNOWLEDGEMENT

We have benefited a lot from the feedback and suggestions given to us by Mr. Phạm
Tiến Phúc and other faculty members, and the machine room coordinator.
ATM System Page 4
Huỳnh Thủy Ngân NIIT Cần Thơ
SYSTEM ANALYSIS
System Summary:
The ATM system have following features:
- Cash withdrawal
- Cash deposit
- Transaction summary
- Changing the PIN
- Check deposit
- Fund transfer within the same bank
On the basic of these features, prepare a white paper for testing the ATM system. The
white paper should present the general requirements of an ATM system and discuss the
following points:
- Test environment that needs to be set up to test an ATM system.
- Testing techniques that need to be adopted to test an ATM system.
- Testing tools that need to be acquired to test an ATM system.
- Risk involved in testing an ATM system
- Typical components of a test plan that need to be developed for an ATM system.
- Test metrics that need to be gathered while testing an ATM system.
One of the best ways to guarantee long term performance is through rigorous,
standardized testing at both the component and system levels. Testing systems check
whether ATM equipment meets their design specifications, confirm that products from
different manufacturers can work together, measure performance against traffic
contracts, and provide assurances that the underlying physical resources are operating
correctly.
ATM System Page 5
Huỳnh Thủy Ngân NIIT Cần Thơ

IDEAL TEST ENVIRONMENT FOR
ATM SYSTEM
FUNCTION TEST ENVIRONMENT
Server/device
types
Machine name Hardware specification Software specification
Client application
and Database
Server
MSDNFTEST01 750 MHz
256 MB of RAM, 19-GB
HD
Intel EtherPro 10/100 NIC
* Windows 2000 Advanced
Server * Windows 2000 SP1
Server* SQL Server 2000 * SOAP
Toolkit
End-user machines Various 700 MHZ
64 MB RAM, 10 GB HD
* Windows 2000 Professional
* Internet Explorer 5.0 or
later/Netscape browsers
SYSTEM TEST ENVIRONMENT
Server/device
types
Machine name Hardware specification Software specification
Web server
MSDNIIS01
933 MHz
256 MB of RAM, 70-GB

HD
Intel EtherPro 10/100 NIC
* Windows 2000 Advanced
Server
Web server MSDNIIS02 933 MHz
256 MB of RAM, 70-GB
HD
Intel EtherPro 10/100 NIC
* Windows 2000 Advanced
Server
Database server MSDNSQL01 700 MHz
256 of MB RAM, 29-GB
HD
Intel EtherPro 10/100 NIC
* Windows 2000 SP1 Server*
SQL Server 2000 * SOAP
Toolkit
Client application
server
MSDNCLIENTAP0
1
750 MHz
256 MB of RAM, 19-GB
HD
Intel EtherPro 10/100 NIC
* Windows 2000 Advanced
Server
End-user machines Various 700 MHZ
64 MB RAM, 10 GB HD
* Windows 2000 Professional

* Internet Explorer 5.0 or
later/Netscape browsers
ATM System Page 6
Huỳnh Thủy Ngân NIIT Cần Thơ
INDIVIDUAL PROJECT SCHEDULE
S.
No.
Activity Description Time
1 Analyze the given case study to identify the requirements 2 Hrs
2 Research for relevant information.
Prepare a rationale for recommendations made in the solution
2 Hrs
3 Prepare the white paper after appropriate study. 2 Hrs
4 Prepare the white paper after appropriate study.
Submit the white paper to the faculty.
2 Hrs
5 Present the white paper in class.
Answer viva-voice related to the white paper.
2 Hrs
ATM System Page 7
Huỳnh Thủy Ngân NIIT Cần Thơ
METHODOLOGY APPROACH
PROCESS OVERVIEW
General Testing Guidelines
The steps in this testing plan are to ensure a smooth transition of code from a development
environment to its production usage. The general approach in most recommended testing
plans have been considered. Combined, all of them emphasize a standard approach to testing
with the following steps: usability testing, unit testing, integration testing, function testing,
system testing, acceptance testing and regression testing.
Testing starts with the developer and the customer verifying (usability testing) the interface

early in development. The developer develops the code to support the requirements and
exercises it (unit test). After this, the interfaces between modules is tested (integration
testing), and then independent testing against requirements (functional) is conducted.
Exercising all components in a production like environment (system testing) with final testing
by the customer (acceptance testing) completes most of the process. This also takes into
consideration the need to retest software in the event of ongoing fixes (regression testing).
Early Development of Test Cases
Test cases are developed early in the process. To complement the Extreme Programming
paradigm, which is discussed below, use cases will be developed early in development.
These describe the use of a system by an “actor” and form the basis for both design and test
cases.
Extreme Programming
The most common method of software development is the waterfall method, which specifies a
phased approach to software development – including plan, design, code, test, and release
cycles. If a project is canceled during coding or earlier, it’s probable that no working code was
developed, and the entire project will yield no tangible results.
ATM System Page 8
Huỳnh Thủy Ngân NIIT Cần Thơ
METHODOLOGY APPROACH
PROCESS OVERVIEW
XP processes also include pair-up design sessions and code sessions; this ensures all code that
is created is viewed by two people. After the software is created, it may be re-factored, and
then tested on a single “continuous integration” machine. After copying the code, developers
run a full suite of the “test first” unit tests. If the code passes all tests, the developers can
check in the code and the unit test. XP unit tests and building are covered in more detail under
“unit tests”, below.
Essentially, stories allow coders to begin development early, and an on-site customer ensures
that the software that is created actually meets the customer’s need. “Getting to the code”
early transforms expenses into working software; because of the priorities, it’s possible for the
customer to cancel the project at 25% of schedule and actually get working software that

fulfils the most important 25% of the business need.
Extreme Programming also uses the concept of “Project Velocity” to measure the cost, time,
and relative late/early-ness of the project.
In addition to a project-level function point analysis, Smart Savings also asked it’s developers
to measure the effort involved in creating the software in Extreme Programming units (XPU).
By dividing the XPUs by the typical development speed (XPU’s developed per week on
previous projects) the team produced a man-month estimate for development of the ATM
project; this estimate, along with function points and risk-adjusted estimates, was used to
create the $350,00 bid for the ATM Project. (Note: The deviation from “book” XP of
working for a fixed price was a concession to the customer made to win the contract. The
customer insisted on this concession to minimize uncertainty.)
The XP method practiced by Smart Savings Co. feeds directly into the testing phase of the
project. Although “book” XP does not include a testing phase, this concept has not exactly
been embraced by the business community. As a result, Smart Savings Co. typically
includes a testing phase in it’s software projects similar to the testing phase advocated by
Donaldson/Siegel in their book Successful Software Development.
ATM System Page 9
Huỳnh Thủy Ngân NIIT Cần Thơ
METHODOLOGY APPROACH
DEFINITIONS
Common Terminology
Term Definition
Acceptance Testing Formalized testing by the customer to determine completion of the product
prior to delivery and payment of services.
Base Line The version of the source code currently in production. This is sometimes
referred to as the “gold” copy of the software currently in production.
Black Box Testing Testing software for its basic functionality without specifically exercising
known pieces of code.
Defect An instance of where the software does not meet the requirement.
Function Testing Formalized testing of modules for their functionality based on the

requirements document.
Glass Box Testing
White Box Testing
Both terms are a form of testing where internal coding knowledge is used to
determine testing.
System Testing Formalized testing where the system is exercised under conditions similar to a
regular production environment.
Integration Testing Testing modules together to ensure the interfaces are compatible and meet
requirements.
System Testing Formalized testing where the system is exercised under conditions similar to a
regular production environment.
Test Case A specific set of steps to be followed to exercise a specific aspect of software.
The steps include how to setup, how to provide the input and the expected
output.
Unit Testing Testing performed on a specific module by the developer.
Use Case A story about the use of the system
XP Extreme programming.
ATM System Page 10
Huỳnh Thủy Ngân NIIT Cần Thơ
RISK ANALYSIS
Risk Description:
Mitigation:
Budget is reduced. Description:
The budget could be reduced if other portions of development incur cost
overruns.
Mitigation: There are two forms to address this as follows:
1. Review the prioritization of the system testing areas based on the analysis
and adjust accordingly.
2. Review the situation with the customer and request additional funding.
3. The SMART SAVINGS Co. absorbs the cost.

Time is reduced Description:
Available time for testing could be reduced if other portions of
development run over estimates time.
Mitigation:
1. Budget and timeline is not set until after functional specification and
function point analysis are complete
2. Development team uses XP and modern methods (see
to ensure
the development schedule does not “slip”
3. The schedule committed to the customer allows additional “buffer” time
for QA beyond that predicted by the function-point estimate.
4. The contract provides four factors that the customer can use to control the
project: Time, Quality, Features, and Resources. If the QA phase runs
over the committed complete date, then, to some extent, it is the customers
choice.
5. The On-Site customer will get daily feedback and have options to “steer”
the project to meet the complete date. Again, if the project is late, then, to
some extent, it is by customer choice.
6. If needed, SMART SAVINGS Co. can absorb the cost of QA over-runs.
ATM System Page 11
Huỳnh Thủy Ngân NIIT Cần Thơ
RISK ANALYSIS
Risk Description:
Mitigation:
Product is below
quality on ship date
Description:
The defect database has several high-priority defects on ship date; the
customer refuses to the sign until all the high-priority (or acceptance-test-
found) defects are removed. The customer may insist that SMART SAVINGS

Co. fix the defects without reimbursement and, in fact, insist on a discount
because the software is “late.”
Mitigation:
1. Testing group has one additional man-month of budget.
2. Beyond that month, SMART SAVINGS Co. will absorb the cost
3. Testing Manager will use FogBuz, internet-enabled bug tracking software,
to evaluate state of software and request additional development resources
as needed.
4. Customer will state explicit acceptance test requirements up front so test
manager can prioritize defects and ensure that customer-required needs are
met.
5. QA Phase as predicted by previous experience and function point analysis
is shorter than the date presented to the customer; this adds a “buffer”
zone.
Turnover causes the
department to lose
organization
knowledge
Description:
Key players on the ATM project are recruited by outside agencies, leave of
their own free will, or are recruited by the customer, causing the organization
to bring new members on staff and play “catch up.”
Mitigation:
1. SMART SAVINGS Co. practices the techniques of PeopleWare, and has
very low turnover.
2. Pair Programming according to XP methodology ensures that two
developers have an organizational knowledge of each line of code.
3. An explicit development program for testers minimizes the effect of a lost
tester
4. Contracts with the customer, vendors, and contract companies forbids

those agencies from recruiting until after the project is complete.
ATM System Page 12
Huỳnh Thủy Ngân NIIT Cần Thơ
RISK ANALYSIS
Risk Description:
Mitigation:
Customer Changes
requirements during
Development, Unit
Test or System Test
Description:
After coding begins, the customer realizes that his organization “needs”
additional features, or re-interpret the functional specification to add features
not included in the function point analysis.
Mitigation:
1. Explicit Contract forces customer to pay a nearly-prohibitive hourly fee
for changes made after the specification is complete. This provides the
budget for testing to continue after “old” budget is expended.
2. XP Methodology makes re-interpretation of “stories” extremely rare.
3. XP Methodology allows additional stories, which add Extreme
Programming Units and Function Points, which increases the cost.
Code shipped to
customer fails to meet
quality standards
Description:
Although the code is passed by developers, approved by the test manager,
and approved by the customer, the tests are minimal and the software has
serious defects. The customer insists of free “fixes”, and SMART SAVINGS
has to either fix them for free or a hefty discount, or risk loss of professional
reputation.

Mitigation:
1. Development, Testing, and the customer each perform an independent
audit to uncover defects: Unit tests, functional tests, system tests, and the
acceptance test. This provides a layer of safety: While some defects may
get past one tester, this form of testing ensures three, four, or more people
will test functionality.
2. The “test first” and use-case based testing performed during the
development cycle is claimed by XP enthusiasts to eliminate the need for
a QA group. While this may not be the case, having a QA group does in
fact add a layer of redundancy or additional confidence.
3. Because the customer performs their own acceptance test, the software
will not pass unless the customer is willing to either “skip” on the test or
make a choice to “skimp” on quality. Either way shows a lack of
commitment to quality and desire to “get the product out the door.” Under
these conditions, it would be very hard for the customer to argue that
SMART SAVINGS needs to make uncompensated bug fixes: As
described above, quality is a factor under the control of the customer.
ATM System Page 13
Huỳnh Thủy Ngân NIIT Cần Thơ
UNIT TEST/INTEGRATION TEST PLAN
Approach
SMART SAVINGS Company defines unit and Interface testing as part of the development
cycle; these tasks will be performed before the “Code Complete” date and the responsibility for
these tests lie with the software developers. Because this process is testing, it is described below.
Unit Testing:
All developers at SMART SAVINGS Co. sit through a 1-hour presentation on unit testing
techniques before commencing to code. First, all developers will ensure that fully dressed use
cases are created. Although use cases are associated more often with the Unified Modeling
Language and the Unified Process, they complement the concept of stories within XP. The use
case establishes the first point of traceability for further testing (Larman, 2002).

Before Developers create a logical unit (or module) of code, they create code to execute and test
the unit/module/object. This code creates the object, performs operations on the object, and then
checks the state of the object to ensure that it’s correct; this is a part of the Xtreme Programming
methodology practices at SMART SAVINGS Company. For example, if the programmer were
creating an object that simulates a cashier’s drawer, the code might look something like this in
C++:
// //
Cdrawer drawer;
drawer.addCash(10000); //Cash in PENNIES
int iChangeTendered;
BOOL bEnoughCash;
bEnoughCash = drawer.makesale(100, 1000, iChangeTendered);
ASSERT(bEnoughCash==TRUE);
ASSERT(iChangeTended==900);
LONG lCashLeft = drawer.getCashLeft();
ASSERT(lCashLeft==10100);
// //
This script would go on to test every public method of the class, with special attention paid to
strange possibilities and bounds testing. Of course, some classes may have to be created and
instanced to create a logical test – such as a money structure (dollars, quarters, etc) or class, for
ATM System Page 14
Huỳnh Thủy Ngân NIIT Cần Thơ
instance. These classes as a whole would compose a “unit.”
When this script is devised, the object hasn’t even been coded, and it will not compile. This
provides an additional “sanity check” and forces coders to perform design before coding;
otherwise, writing the script would be impossible.
UNIT TEST/INTEGRATION TEST PLAN
ATM System Page 15
Huỳnh Thủy Ngân NIIT Cần Thơ
In keeping with XP methodology, all test scripts must execute 100% pass before the code can be

checked in.
Interface Testing:
After Unit Testing is complete, developers must consider every other class that their object could
“interface” with. After writing up what the various interfaces are, the developer will meet with
the main coder on the other objects and the two write up a “use-case” scenarios for the
interfaces. The developer will then code and test interface tests in the same style as unit tests
above.
Setup and Configuration Requirements
In keeping with the XP concept of continuous integration, all development machines must have
MS Visual Source Safe (for Version Control) , MS Visual Basic, and the .Net Framework and
Integrated Development Environment. Continuous Integration testing is performed on a separate
“build” machine, as described by Xtreme Programming Installed. Developers run the entire suite
of checked-in unit tests overnight. In addition, the developers will need a machine to simulate
the mainframe from which transactions are downloaded and performed; the customer will
provide this machine.
Defect Handling
In the event that a unit test fails overnight, the coder who wrote that section will examine the
test, re-factor the code if needed, check in his code and run a new test the next day. The project
manager reports defects on the server side to the customer, as that application is outside the
scope of this effort.
Estimated Cost/Percentage of Budget
As described previously, Unit and Integration testing are performed as part of development, and
included in the cost of development (coding).
Approvals
Since XP depends heavily on pair programming practices, both partners in a module effort must
agree that the code is ready for the next phase of testing before requesting a migration to function
testing. After the first turnover of any module to testing for function testing, the code will be
considered base lined. From that point on, the developers must utilize the revision control
system to make further changes to the code. See migration requirements for function testing
below.

UNIT TEST/INTEGRATION TEST PLAN
ATM System Page 16
Huỳnh Thủy Ngân NIIT Cần Thơ
Setup and Configuration Requirements
Migration Requirement
Only source code is to be provided to the configuration management team through properly
checking it into the version control software. The configuration management team is required to
do a full build of all source code before placing it into the function test environment.
ATM System Page 17
Huỳnh Thủy Ngân NIIT Cần Thơ
FUNCTION TEST PLAN
General
The purpose of functional verification test is to check that the ATM conforms fully to its
functional specification. The functional test will conform to the key dimensions of extreme
functional tests
Customer-owned To get confidence from the tests, the customers must understand them, and
should provide the values tested.
Comprehensive: The values to be tested will be derived using boundary value analysis(BVA)
Repeatable: The functional test will be documented and chosen so that it is repeatable
Automatic: SMART SAVINGS Co will use the existing automated tools available in-house to
perform the functional tests.
Build Environment
The functional test environment requires a dedicated environment to build the application on
to ensure that the integrity of the build process. Except for this build, no other development is
done on this workstation to ensure the environment is free of extraneous code the developer
may have used in unit testing. Further it ensures the build is done in an environment which is
monitored to match the current architecture.

Since this application is being developed based on .Net technology, the development
configuration to prepare production releases is recommended to be the following.

Processor: Pentium III-650MHZ
Operating System: Windows 2000 – Server
Memory: 256 MB
Hard Drive: At least 2.5 Gig free on the installation drive.
Software: Full .Net System Development Kit (SDK).
Code is to be compile
ATM System Page 18
Huỳnh Thủy Ngân NIIT Cần Thơ
FUNCTION TEST PLAN
ATM System Page 19
Huỳnh Thủy Ngân NIIT Cần Thơ
Participants
Under the extreme programming (XP) paradigm, function testing involves the customer and
the developer. The primary difference being that a compile in a “clean” environment has been
done to support the testing.
Estimated Cost/Percentage of Budget
Since the XP approach includes this under development, this is not part of the testing
budget. Further, the build aspect is accomplished by the configuration management
(CM) area and all labor associated with that aspect comes under the CM budget.
SYSTEM TEST PLAN
ATM System Page 20
Huỳnh Thủy Ngân NIIT Cần Thơ
Approach
General
System testing is intended to exercise the system within an environment that resembles a
production environment as much as reasonably possible. It is impossible to test for all
conditions.
Prioritization
As implied above, system testing is a high cost activity. Due to that it is necessary to prioritize
areas of testing to reduce risk. This prioritization was done based on the recommended areas

of testing noted by Myers in Humphrey’s book, Managing The Software Process. The eleven
areas of testing and the priority assigned to them was based on the function point analysis of
the areas of influence. A full discussion on that prioritization scheme is in Appendix A. That
appendix also provides a more detailed discussion in its tables on the purpose to each test and
the setup considerations.
It should be emphasized that the priority is meant to provide a guide in how to budget for the
tests. It does not necessarily imply that any test will be dropped. If the budget does become a
severe constraint, this list will be reviewed by the testing manager, development manager and
the customer.
Briefly, the eleven testing areas are listed below in priority
SYSTEM TEST PLAN
ATM System Page 21
Huỳnh Thủy Ngân NIIT Cần Thơ
Actual Order Of Testing Summary and Budget Breakout
Cycle Category %
Budget
Comment
1 Configuration 2% The configuration must exist for setup. Most of the
expense is hardware related and also comes under
the budget for configuration management.
2 Installability 5% To test requires an installation. So even though this
has a low priority budget wise, it is necessary to do
first.
3 Security 5% This cycle will test for minimum security and is
repeated on every cycle since the majority of all the
tests require access. Essentially, security is being
tested throughout the other cycles which is and its
funding is indirectly supported in those areas.
4 Compatibility 10% Initial down loads of data require conversion and
must be done to move forward on testing

5 Reliability/Availab
ility
18% This has a higher portion of the budget due to the
priority analysis.
6 Recovery 15% This is closely related to the reliability and stress
testing below.
7 Serviceability 10% Budgeted according to the priority analysis
8 Load/Stress 10% Budgeted according to the priority analysis
9 Volume 10% Part of volume testing is covered under reliability
and availability.
10 Performance 10% Budgeted according to the priority analysis
11 Human Factors 5% Human factors should have been heavily scrutinized
early in development
SYSTEM TEST PLAN
ATM System Page 22
Huỳnh Thủy Ngân NIIT Cần Thơ
Note On Security Testing
It is strongly advised that additional funding should be considered to procure third party
support for security testing. Testing of this nature is highly specialized and should be done by
a company with expertise in security.
Manual Testing
Manual testing will be accomplished based on the test plans provided to function testing as
well as any use cases for the external system. Use cases must be developed for external
systems as well since they are considered actors. The use-cases will be developed into test-
cases by the testers when it is exercised in the system testing environment first.
Application Automated Testing
Although setting up an automated test takes ten times longer than setting up a manual test
automated testing is essential to conduct volume testing due to the time reduced in executing a
large number of tests.
Due to their nature, the first five testing areas will depend heavily on the use of robots or

automated scripts to provide the continuous activity or data volume necessary. Specific
products recommended for automated testing include Rational Robot and File Aid from
Compuware .
Migration of Code
Code moved into system test should be considered production ready from the standpoint of
configuration management. That is, it should not be recompiled when moved from the
function test environment. This is an established base line for the MicroSoft Intermediate
Language (IL) code.
SYSTEM TEST PLAN
ATM System Page 23
Huỳnh Thủy Ngân NIIT Cần Thơ
Estimated Cost/Percentage of Budget
According to Steve McConnell, Software Project Manager's Survival Guide,
20% of the development budget is typically spent on Systems Testing. Based on this, the total
budget for testing against the project budget is estimated at $70,000.
Approvals
Since system testing is crucial to ensuring a quality product to customer, all managers must
review the final status of defects to determine if the package should be released to the
customer for acceptance testing. The testing manager, the development manager shall create
an approval form in conjunction with the customer liaison.
ACCEPTANCE TESTING
ATM System Page 24
Huỳnh Thủy Ngân NIIT Cần Thơ
General
Acceptance Test is used to verify that all aspects of the Detail Specification document have
been implemented. All test scenarios must correlate to requirements previously agreed to in
the Functional Requirements and Detail Specification documents. When all the acceptance
tests pass for a given user story, that story is considered complete. Working with the customer,
a comprehensive acceptance test is designed to ensure that the final deliverable meets the
business needs established in the Specification document and agreed to in writing by both the

customer and SMART SAVINGS Co.
Approach
“Acceptance testing addresses the broadest scope of requirements, while lower levels of
verification like unit tests address requirements that satisfy functions fully contained within
builds that make up releases. The acceptance-testing objective is to verify that the end-to-end”
ATM operations satisfy ATM requirements in the following categories:
operational, functional, performance and interface requirements. This is similar to other areas
of testing, however, this is conducted by the customer to ensure a completed product is
accepted.
Operational Requirements: ensure that the ATM operates in accordance with business
requirements set by the customer
Functional Requirements: ensure that the required tasks are accomplished and that the needs
and objectives of users are met.
Performance Requirements: ensure that performance objectives with respect to throughput,
delay, number of simultaneous transactions in progress are satisfied. Requirements include
speed, accuracy, frequency, reliability, maintainability, and availability.
Interface Requirements: ensure that external and internal systems pass information or
control to one another in accordance with specifications.
ACCEPTANCE TESTING
ATM System Page 25