System planning
The system planning phase is a crucial step in the development of an embedded system, such as an Automated Teller Machine (ATM). This phase
involves defining the system requirements, constraints, and objectives, which guide the design, implementation, and testing of the system. In
this document, we will outline the key activities and considerations for the system planning phase of an ATM embedded system.
Project Charter for an ATM Embedded System
I. Project Title
Automated Teller Machine (ATM) Embedded System Development
II. Project Purpose and Justification
The purpose of this project is to design, develop, and implement an ATM embedded system that provides secure, efficient, and user-friendly
banking services to customers. This new system will replace the current outdated ATM system, addressing its limitations in terms of
functionality, security, and performance. The project is justified by the need to improve customer satisfaction, increase transaction efficiency,
and enhance the bank's competitiveness in the market.
III. Project Scope
The project scope includes the following:
Design and development of an ATM embedded system that supports various transaction types, such as cash withdrawals, deposits, balance
inquiries, and fund transfers.
Integration with the bank's existing core banking systems and external payment networks.
Implementation of robust security measures to protect customer data and transactions.
Design of a user-friendly interface for customers, with support for multiple languages and accessibility features.
Development of a remote monitoring and management system for ATM maintenance and support.
The project scope does not include the development of new ATM hardware or the modification of existing banking software systems not directly
related to ATM functionalities.
IV. Project Objectives
The key objectives of this project are:
Improve customer experience by providing fast, secure, and easy-to-use ATM services.
Increase transaction efficiency and reduce processing times.
Enhance security of customer data and transactions by implementing advanced encryption and authentication mechanisms.
Ensure compliance with regulatory requirements and industry standards.
Reduce maintenance costs and downtime through remote monitoring and management capabilities.
V. Project Team and Stakeholders
A. Project Team
Project Manager: Omotosho peter
Systems Analyst: Adeye inioluwa
Embedded Systems Engineer: bukunmi 1
Security Expert: unknown
UI/UX Designer: bukummi 2
Quality Assurance Engineers: Enoch
B. Key Stakeholders
Bank Management: Approval of project scope, budget, and resources
IT Department: Integration with existing banking systems and technical support
Security Team: Ensuring compliance with security policies and regulations
Customers: End-users of the ATM system
Regulatory Authorities: Compliance with banking and security regulations
Technology Vendors: Provision of hardware components and software libraries
VI. Project Deliverables
ATM Embedded System Software
ATM Hardware Integration Manual
System Documentation (design, implementation, and testing)
User Manual and Training Materials
Quality Assurance and Compliance Reports
VII. Project Milestones
Project initiation and planning: 1 month
System analysis and design: 2 months
System implementation and integration: 3 months
System testing and validation: 1.5 months
Deployment and training: 1 month
VIII. Project Risks and Challenges
Potential risks and challenges include:
Technical difficulties in integrating with existing banking systems
Security vulnerabilities or breaches
Delays in hardware procurement or software development
Regulatory compliance issues
The project team will monitor and manage these risks throughout the project, implementing mitigation strategies as needed.
FEASIBILITY STUDY:
Once the problem is clearly understood, the next step is to conduct feasibility study, which is high-level capsule version of the entered systems
and design process. The objective is to determine whether or not the proposed system is feasible. The tOBSee tests of feasibility have been carried
out.



Technical Feasibility
Economical Feasibility
Operational Feasibility
 TECHNICAL FEASIBILITY
In Technical Feasibility study, one has to test whether the proposed system can be developed using existing technology or not. It is planned
to implement the proposed system using java technology. It is evident that the necessary hardware and software are available for
development and implementation of the proposed system. Hence, the solution is technically feasible.
 ECONOMICAL FEASIBILITY
As part of this, the costs and benefits associated with the proposed system compared and the project is economically feasible only if
tangible or intangible benefits outweigh costs. The system development costs will be significant. So the proposed system is economically
feasible.
 OPERATIONAL FEASIBILITY
It is a standard that ensures interoperability without stifling competition and innovation among users, to the benefit of the public both in
terms of cost and service quality. The proposed system is acceptable to users. So the proposed system is operationally feasible.
Gantt chart
Level
Task Name
Start
Finish
Working
Days
January
10/
10
1
2
3
Planning
10/10
20/10
11
1.1 Define the project name and
description
10/10
12/10
3
1.2 Define users and the expertise
that involve
13/10
15/10
3
1.3 Define the component that
needed to carry out the task
16/10
20/10
5
1/11
14/11
14
2.1 Analysis the possibility of the
input and output of the system
1/11
6/11
6
2.2 Construct the flow chart of the
system
7/11
9/11
3
2.3 Construct the paper-type
Prototype
10/11
14/11
5
15/11
4/12
18
3.1 Design the real prototype
15/11
22/11
8
3.2 Getting feedback from user
and renovate the prototype
23/11
26/11
4
3.3 Improves the design
27/11
30/11
3
3.4 Finalize the design and its
system
1/12
4/12
3
Analysis
Design
17/
10
February
24/
10
03/
11
10/
11
March
17/
11
24/
11
01/
12
08/
12
15/
12
22/
12
29/
12
7/0
1
14/
01
21/
01
4
Implementation
4.1 Consult with the expert
4.2 Presentation
5/12
24/12
18
5/12
13/12
9
21/1
1
21/1
Project phase
Planning
Analysis
Design
Implementation
Rate (%)
15%
20%
35%
30%
Work Plan
System
Development
Process
Industrial
Standard
Ex: 12 Months
Results
Planning
Analysis
Design
Implementation
Total
Duration
15%
20%
35%
30%
100%
1.8 months
4 Months
2.4 months
5 Months
4.2 months
9 Months
3.6 months
8 Months
12 months
3 Months
Example of calculation: 0.15 X 12= 1.8 months
4 months / 0.15 = 26.67 months
SYSTEM ANALYSIS
II. System Requirements
The requirement analysis of an Automated Teller Machine (ATM) involves identifying and documenting
the various functional and non-functional requirements that the system must meet to provide efficient,
secure, and user-friendly banking services. This analysis helps guide the design, development, and
testing of the ATM system, ensuring that it meets the needs of both the bank and its customers.
Functional Requirements
1. User Authentication
Card Reader: The ATM must be able to read and validate magnetic stripe or EMV chip cards.
PIN Verification: The system should prompt users to enter their Personal Identification Number
(PIN) and validate it against the bank's records.
Biometric Authentication: The ATM may support additional biometric authentication methods,
such as fingerprint or facial recognition, for enhanced security.
2. Transaction Processing
Cash Withdrawal: The system should allow customers to withdraw cash in multiple
denominations based on their account balance and the ATM's cash availability.
Balance Inquiry: The ATM should provide customers with their account balances, including
savings, checking, and credit accounts.
Fund Transfer: The system should enable fund transfers between a customer's own accounts or
to other accounts within the same bank.
Bill Payment: The ATM should facilitate bill payments for utilities, credit cards, loans, and other
services supported by the bank.
Mini Statement: The system should be able to generate and print a mini statement of the
customer's recent transactions.
3. User Interface
Display: The ATM should have a clear and easy-to-read display, with support for multiple
languages if required.
Keypad: The system should feature a secure, tamper-resistant keypad for PIN entry and
transaction selection.
Touchscreen: The ATM may include a touchscreen display for a more intuitive and user-friendly
interface.
Audio Jack: The system should have an audio jack to support accessibility for visually impaired
users.
Non-Functional Requirements
A) Performance
I. Response Time: The ATM should process transactions quickly, with minimal wait times for
customers.
II. Throughput: The system should be able to handle a high volume of transactions during peak
hours without performance degradation.
III. Availability: The ATM should have high uptime and be operational 24/7, with minimal
downtime for maintenance or technical issues.
B. Security
I.
Data Encryption: The system should use strong encryption algorithms to protect customer
data during transmission and storage.
II. Tamper Resistance: The ATM should be designed to resist physical and logical attacks, with
measures such as secure enclosures and intrusion detection systems.
III. Fraud Detection: The system should include mechanisms to detect and prevent fraudulent
transactions, such as unusual transaction patterns or card skimming attempts.
C. Usability
I.
Accessibility: The ATM should comply with accessibility standards and guidelines, including
support for visually and hearing-impaired users.
II. User-Friendly Interface: The system should have an intuitive and easy-to-use interface, with
clear instructions and feedback messages.
III. Multilingual Support: The ATM should support multiple languages if the target customer
base is multilingual.
IV. Regulatory and Compliance Requirements
V. Banking Regulations: The ATM system must comply with local and international banking
regulations, including those related to customer data privacy, anti-money laundering, and
transaction processing.
VI. EMV Compliance: The system should be EMV (Europay, MasterCard, and Visa) compliant,
ensuring compatibility with EMV chip cards and supporting secure transactions.
VII. ADA Compliance: In the United States, the ATM should comply with the Americans with
Disabilities Act (ADA) requirements for accessibility.
How ATM works?
The ATM will be managed by an operator, who operates the ATM and refills it with cash and receipts.
The ATM will serve one customer at a time and should not shut down while serving. To begin a
transaction in the ATM, the user should insert their ATM card, which will contain their account
information. Then, the user should enter their Personal Identification Number (PIN) for authentication.
The ATM will send the user’s information to the bank for authentication; without authentication, the
user cannot perform any transaction/service.
The user’s ATM card will be kept in the ATM until the user ends a session. For example, the user can end
a session at any time by pressing the cancel button, and the ATM Card will be ejected. The ATM will
maintain an internal log of transactions that contains information about hardware failures; this log will
be used by the ATM operator to resolve any issues.
1. Identify the system user through their PIN.
2. In the case of depositing checks, the amount of the check will not be added instantly to the user
account; it is subject to manual verification and bank approval.
3. It is assumed that the bank manager will have access to the ATM’s system information stored in
the bank database.
4. It is assumed that user deposits will not be added to their account immediately because it will
be subject to verification by the bank.
5. It is assumed the ATM card is the main player when it comes to security; users will authenticate
themselves with their debit card and security pin.
Use Case Diagram
Here are the actors of the ATM system and their use cases:
Operator: The operator will be responsible for the following operations:
1.
2.
3.
4.
5.
Turning the ATM ON/OFF using the designated Key-Switch.
Refilling the ATM with cash.
Refilling the ATM’s printer with receipts.
Refilling the ATM’s printer with INK.
Take out deposited cash and checks.
Customer: The ATM customer can perform the following operations:
1.
2.
3.
4.
Balance inquiry: the user can view his/her account balance.
Cash withdrawal: the user can withdraw a certain amount of cash.
Deposit funds: the user can deposit cash or checks.
Transfer funds: the user can transfer funds to other accounts.
Bank Manager: The Bank Manager can perform the following operations:
1.
2.
3.
4.
Generate a report to check total deposits.
Generate a report to check total withdrawals.
Print total deposits/withdrawal reports.
Checks the remaining cash in the ATM.
Here is the use case diagram of our ATM system:
Class Diagram
Here are the main classes of the ATM System:


ATM: The main part of the system for which this software has been designed. It has attributes
like ‘atmID’ to distinguish it from other available ATMs, and ‘location’ which defines the physical
address of the ATM.
CardReader: To encapsulate the ATM’s card reader used for user authentication.










CashDispenser: To encapsulate the ATM component which will dispense cash.
Keypad: The user will use the ATM’s keypad to enter their PIN or amounts.
Screen: Users will be shown all messages on the screen and they will select different
transactions by touching the screen.
Printer: To print receipts.
DepositSlot: User can deposit checks or cash through the deposit slot.
Bank: To encapsulate the bank which ownns the ATM. The bank will hold all the account
information and the ATM will communicate with the bank to perform customer transactions.
Account: We’ll have two types of accounts in the system: 1)Checking and 2)Saving.
Customer: This class will encapsulate the ATM’s customer. It will have the customer’s basic
information like name, email, etc.
Card: Encapsulating the ATM card that the customer will use to authenticate themselves. Each
customer can have one card.
Transaction: Encapsulating all transactions that the customer can perform on the ATM, like
BalanceInquiry, Deposit, Withdraw, etc.
Data Flow Diagram(Level-0):-
This diagram shows the Automatic Teller System Software and the hardware that it interacts with. The
arrows show the direction and type of data flowing between the software and each hardware element.
External Entities:CONTROL SYSTEM
This system enables and disables the customer interface and receives customer requests and system
reports. A suitable Control System would be a personal computer linked to a central computer system
with access to the Accounts Database. The customer interface (keypad, display, etc) is controlled by
enabling and disabling the Card Reader, which is the customer's entry-point to the system. Requests for
statements and chequebooks are posted to the Control System. It also receives status reports for low
printer-paper and cash levels.
ACCOUNTS DATABASE
This is a database containing account numbers, balances and other account information. Data is
retrieved from the database when a customer requests a balance report or a cash withdrawal. The
database is updated after a withdrawal.
CARD READER
The Card Reader receives the customer's card and retrieves the PIN and account number stored on it.
This information is transmitted to the software system which enables the Customer Keypad and initiates
the PIN verification procedure. When business is completed the Card Reader is instructed to return the
card. If the customer enters an incorrect PIN, a fixed number of retries is permitted, after which the Card
Reader is instructed to confiscate the card.
CUSTOMER KEYPAD
The Customer Keypad allows a customer to enter a PIN number, select options and enter cash values.
The keypad is only enabled when a card is detected in the Card Reader.
CUSTOMER DISPLAY
The Customer Display presents messages, options and reports to the customer. The display is active at
all times.
PRINTOUT DISPENSER
This provides the customer with a printed balance or receipt. The Printout Dispenser reports to the
system if the paper level is low.
CASH DISPENSER
This assembles and delivers cash to the customer. The dispenser receives information about the values
and quantities of notes to dispense. The Cash Dispenser reports to the system if the cash levels are low.
Data Flow Diagram(Level-1):-
This diagram shows data entering and leaving the system. Input data is received from the hardware
elements on the left. Various types of data are processed by different parts of the software system.
Output data is sent to the elements of hardware on the right.
DFD Level 1 Processes:-
Interact With Operator
This process deals with commands from the system operator. These are the commands which enable or
disable the customer interface by controlling the Card Reader. The operator may issue these commands
from another computer system or by using a switch on a control panel.
Interact With Customer
This process handles all interactions with the customer and operates only when a card is detected in the
Card Reader. Input is received initially from the Card Reader and then directly from the customer via the
Customer Keypad. The customer receives output from the Customer Display, the Printout Dispenser and
the Cash Dispenser. Customer interactions may also involve sending reports to the Control System. The
initial step of all customer interactions is to verify the customer's PIN number. After this a menu of
options is presented on the display which the customer selects by pressing appropriate keys on the
keypad. These options lead to other displays and requests for further input. Some options require
account details which are retrieved from the Accounts Database and may also involve updating the
database. During the final stage of all customer interactions the Card Reader is instructed to either
return or confiscate the card.
Prepare Command
This process handles communication with the Card Reader hardware. The system requires that the Card
Reader is able to receive the following commands:
ENABLE
Makes the Card Reader ready to receive a card
DISABLE
Prevents the Card Reader from accepting a card
RETURN
Ejects a card from the Card Reader
RETAIN
Confiscates an unauthorized card
The Card Reader is enabled and disabled by commands from the system operator. A card is returned or
retained in response to interactions with the customer.
Update Display
This process deals with the Customer Display screen. When no card is in the Card Reader, the Customer
Display shows general information (such as 'Insert Card'). When a card is detected the display is updated
in response to customer interactions. If the system is disabled by the system operator, the display is
updated to indicate the system status.
The following is a list of screens which are shown on the Customer Display.
General Information
-Insert Card and other messages
PIN Verification
- Enter PIN message
Main Options
- Some or all of the following; Display Balance,
Print Balance, Cash With Receipt, Cash Without receipt, Order
Statement, Order Chequebook, Return Card
Current Balance
-Customer's account balance and cleared funds
Balance Printed
-Take Your Balance message
Withdrawal Options
-Pre-defined cash amounts and Other Amount
Cash Amount
-Enter Amount for cash withdrawal
Cash Dispensed
-Take Your Cash message
Receipt Printed
-Take Your Receipt message
Statement Ordered
-Statement Ordered message
Chequebook Ordered
- Chequebook Ordered message
Card Returned
-Take Your Card message
Card Retained
-Card Retained message (for failed PIN Verification)
Prepare Message
This process prepares and transmits messages to the Control System. These messages can be requests
from customers for statements and chequebooks or reports concerning the levels of printer-paper and
cash.
Prepare Printout
This process prepares and controls the use of the Printout Dispenser to produce balance reports and
receipts. The customer's balance is retrieved from the Accounts Database (if required). If the printerpaper level becomes low options which involve printouts are disabled and a warning message is sent to
the Control System.
Manage Withdrawal
This process receives requests for withdrawals of specific amounts from a certain account and operates
the Cash Dispenser. Before proceeding, the customer's details in the Accounts Database are checked. If
the request exceeds the customer's balance (or agreed overdraft) the withdrawal is denied. The system
uses a denomination selection algorithm based on the notes available and the amount required. The
Accounts Database is updated after each withdrawal. If the cash level becomes low, options providing
cash withdrawals are disabled and a warning message is sent to the Control System.
Systems design
System Architecture Design:
Hardware Components: Identify and select hardware components such as card reader, keypad, display,
cash dispenser, receipt printer, and network interface.
Software Components: Define software modules including user interface, transaction processing,
security, communication interfaces, and peripheral device drivers.
System Interfaces: Specify interfaces between hardware components and software modules, ensuring
compatibility and seamless interaction.
User Interface Design:
Screen Layout: Design the layout of the ATM screen, including menus, prompts, and transaction
confirmation screens.
Input Methods: Determine input methods such as keypad entry, touchscreen interactions, or a
combination of both.
Accessibility: Ensure the user interface is accessible to all users, including those with disabilities, by
providing options for adjusting font size, contrast, and audio feedback.
Transaction Processing Design:
Transaction Flow: Define the flow of transactions such as cash withdrawal, balance inquiry, funds
transfer, and bill payments.
Error Handling: Design error handling mechanisms to handle exceptions such as insufficient funds,
invalid transactions, or communication failures.
Transaction Logs: Specify how transaction logs will be recorded and stored for auditing and
reconciliation purposes.
Security Design:
Authentication: Implement strong user authentication methods such as PIN entry, biometric verification,
or card validation.
Data Encryption: Encrypt sensitive data transmitted between the ATM and the bank's servers to prevent
eavesdropping and tampering.
Physical Security: Incorporate physical security measures to protect against vandalism, skimming
devices, and unauthorized access to internal components.
Communication Design:
Network Protocol: Select communication protocols such as TCP/IP, HTTP, or ISO 8583 for
communication between the ATM and the bank's servers.
Data Exchange Format: Define the format of data exchange between the ATM and the backend systems,
ensuring compatibility and data integrity.
Error Recovery: Implement mechanisms for error recovery and retrying failed communication attempts
to ensure robustness and reliability.
Peripheral Device Integration:
Device Drivers: Develop device drivers to interface with hardware components such as the card reader,
cash dispenser, and receipt printer.
Device Control: Define protocols and commands for controlling peripheral devices and handling devicespecific events.
Database Design:
Data Model: Design the database schema to store information such as user accounts, transaction logs,
system configurations, and audit trails.
Normalization: Normalize the database to minimize redundancy and ensure data consistency and
integrity.
Indexing and Optimization: Optimize database performance by creating indexes and tuning database
queries for efficient data retrieval and storage.
Error Handling and Recovery:
Fault Tolerance: Implement fault-tolerant mechanisms to recover from hardware failures, software
errors, and communication disruptions.
Logging and Monitoring: Set up logging and monitoring systems to track system errors, exceptions, and
performance metrics for troubleshooting and analysis.
Testing and Quality Assurance:
Test Plan: Develop a comprehensive test plan covering unit testing, integration testing, system testing,
and user acceptance testing.
Test Cases: Create test cases based on requirements and specifications to validate the functionality,
performance, and security of the ATM system.
Quality Assurance: Establish quality assurance processes to ensure that the ATM system meets quality
standards and regulatory requirements.
Documentation and Training:
Technical Documentation: Prepare technical documentation including system architecture documents,
design specifications, API documentation, and user manuals.
Training Materials: Develop training materials for ATM users
SYSTEM IMPLEMENTATION
The system implementation phase of an ATM embedded system involves translating the design
specifications into executable code and deploying the system for testing and eventual production use.
Here's a detailed outline of the implementation phase for your ATM embedded system:
Setting Up Development Environment:
Configure development environments for software development, including integrated development
environments (IDEs), compilers, debuggers, and version control systems.
Set up hardware development kits or emulators to simulate the ATM hardware environment for testing
purposes.
Software Development:
Develop software modules according to the design specifications, starting with core functionalities such
as user interface, transaction processing, and security features.
Implement algorithms for transaction processing, authentication, encryption, and error handling as per
the design requirements.
Write code for interfacing with hardware components such as the card reader, keypad, display, cash
dispenser, and receipt printer.
Implement communication protocols for data exchange between the ATM and the bank's servers,
ensuring data integrity and security.
Hardware Integration:
Integrate software modules with hardware components, ensuring proper communication and
interaction between the ATM software and the physical ATM hardware.
Develop and test device drivers for controlling and managing hardware peripherals such as the card
reader, cash dispenser, and receipt printer.
Validate hardware integration by conducting hardware-software integration tests to verify that all
components function correctly together.
Security Implementation:
Implement security features such as user authentication, data encryption, and secure communication
protocols to protect sensitive information and prevent unauthorized access.
Integrate security mechanisms for detecting and preventing fraudulent activities such as card skimming,
PIN theft, and unauthorized access attempts.
Conduct security testing and penetration testing to identify and address potential vulnerabilities in the
system.
Database Implementation:
Set up and configure the database system according to the design specifications, ensuring compatibility
with the chosen database management system (DBMS).
Create database tables, indexes, and constraints based on the data model defined during the design
phase.
Develop and test database access modules for storing and retrieving data such as user accounts,
transaction logs, and system configurations.
Testing and Quality Assurance:
Execute unit tests to validate individual software components and modules for correctness and
functionality.
Conduct integration tests to verify the interaction and interoperability of integrated software and
hardware components.
Perform system tests to evaluate the overall functionality, performance, and reliability of the ATM
system as a whole.
Conduct user acceptance testing (UAT) with representative users to validate that the ATM meets user
requirements and expectations.
Documentation and Training:
Prepare technical documentation including system architecture documents, design specifications, API
documentation, and user manuals.
Develop training materials for ATM users, bank staff, and maintenance personnel to familiarize them
with the operation, troubleshooting, and maintenance of the ATM system.
Conduct training sessions to educate users and stakeholders on how to use the ATM system effectively
and efficiently.
Deployment and Rollout:
Deploy the ATM system to production environments, following deployment procedures and best
practices to minimize disruptions and ensure smooth transition.
Install and configure ATM hardware at designated locations, ensuring proper connectivity and alignment
with regulatory requirements.
Conduct pilot deployments at selected locations to validate system performance and gather feedback
for further refinement.
Roll out the ATM system across all planned locations, monitoring deployment progress and addressing
any issues or challenges that arise during the rollout process.
Maintenance and Support:
Establish a maintenance schedule for regular maintenance tasks such as software updates, hardware
inspections, and security patches.
Provide technical support mechanisms for resolving issues reported by ATM users or bank staff,
including helpdesk support and on-site maintenance services.
Monitor system performance and stability, proactively addressing any issues or concerns to ensure
uninterrupted service for ATM users.
By following this detailed system implementation phase, you can ensure that your ATM embedded
system is successfully developed, deployed, and ready for production use, providing a secure, reliable,
and user-friendly banking experience for customers.
System testing
Any system, to be successful, must be thoroughly tested, and well managed test plan should be prepared
before actual testing is being performed. “Modules” have been developed and need to be tested in a manner
that can reduce occurring of defects as low as possible. Following are the activities we planned to test the
system.
CONTENT TESTING:
Errors in Project content can be as trivial as minor typographical error as incorrect information, improper
organization or validation of intellectual property laws. Content Testing attempt to uncover this and many
other problems before the user encounter them.
Content Testing Objectives:
There are three types of objectives.
1) To uncover syntactic errors in text-based documents, graphical representation and other media.
2) To uncover semantic errors in any content object represented as navigation error.
3) To find errors in organization or structure of content that is presented to the end-user
INTERFACE TESTING
Interface design model is reviewed to ensure that generic quality criteria established for all user
interfaces have been achieved and that application specific interface design issue has been properly
addressed.
Interface testing strategy:
The overall strategy for interface testing is to
(1) Uncover error related to specific Interface mechanisms
(2) uncover errors in the way the interface implements the semantics of navigation, WebApp functionality,
or content display. To accomplish this strategy, a number of objectives must be achieved:
Interface futures are tested to ensure that design rules, aesthetics and related visual content are available
for the user without error.
USABLITY TESTING:Usability test may be designed by Project engineering team.
1. Define a set of usability testing categories and identify goal for each.
2. Design test that will enable each goal to be evaluated.
3. Select participants who will conduct test.
4. Instrument participant’s interaction with system while testing is conducted.
5. Develop a mechanism for assessing the usability of the system.
The following test categories and objective illustrate establish testing:
Interactivity- Are interaction mechanism easy to understand and use?
Layout- Are navigation mechanism, content and function place in a manner that allows the user to find
them quickly?
Readability- Is the text well written and clear?
Aesthetics- Do layout color, typeface, and related characteristics lead to ease of use?
Display Characteristics- Does the system make optimal use of screen size and resolution?
Time Sensitivity- Can important features, functions and content be used in a timely manner?
Accessibility- Is the system accessible to people who have Disabilities?
COMPATIBILITY TESTING:Project must operate within environment that differs from one another. Different computer, display
device, OS, browser and network connection speed can have significant on system operation.The Project
team derives a series of compatibility, validation tests, derived from existing interface tests, navigation
tests, performance tests and security tests.
5.3 Testing Methods:
Analyze and check system representation such as the requirement document, design diagrams and the program
source code. They may be applied at all stages of the process.
There are different Models of testing. On the basis of testing methods there are two types of testing:
1. White-box testing.
2. Black-box testing
1). WHITE-BOX TESTING
White-box testing sometimes called glass-box testing, is a test case design method that users the
control structure of the procedural design to drive the test case.
 Logical errors and incorrect assumption are inversely proportional to the probability that a
program will be executed. Errors tend to creep into our work we design and implement function,
condition or control that is out of the mainstream tends to be well understood.
 We often believe that a logical path is not likely to be executed when in fact it may be executed
on a regular basis. The logical flow of a program times counter intuitive.
2). BLACK-BOX TESTING:
For our project periodically we have tested our software using black-box testing. Thinking as a client we
have evaluated the software for its easy going and convenience.

Unit Testing:
During the programming stages each and every form, modules and class treated unit has been
put into the test data. Every module is tested independently. The steps are follows:
I. Manually code is tested like spelling checks, logic and errors.
II. Once the manual checking is over the complication has been done. Syntactical errors if
any have to be corrected.
III. After the clean complication the program, some dummy data, as specification, has been
used for testing of the module to see if it works as specified.

Integration Testing
After our individual’s modules were tested out we go the integrated to create a complete
system. This integration process involves building the system and testing the resultant system
for problems that arise from component interaction.

Performance Testing
Performance testing is designed to test the runtime performance of the system within the
context of the system. These tests were performed as module level as well as system level.
Individual modules were tested for required performance.

Condition Testing
Performance testing is a test case design method that exercises the logical conditions.

Interface Testing
Interface sting is integral part of integration. We examined the code to be tested and explicitly
list each call to an external component. In the system standards tests for GUIs have been
performed, which are as follows:
I. The position and related labels for all controls were checked.
II. Validations for all inputs were done.
III. Pull down controls was verified for proper functionality.
IV. Whether the non-editable text controls disabling and it was also verified that it doesn’t
exceed the maximum allowed length.