Chapter 3

METHODOLOGY

This chapter discusses about the systems features and how the system was

developed.

Project Description

The system Interactive Cash Collection Kiosk is a remotely installed cash

collection device that accepts cash as payment for the students tuition and fees. The

device has a user interface that interacts with the user, accepts bills and coins, and

generates a detailed temporary receipt that is mark with a unique scannable

transaction code right after the successful payment transaction. The kiosk is

connected to the server that stores the users data. The server has its own user

interface that interacts with the system administrator.

The kiosk system identifies the validity of its users which is based on the list

saved in its database, reads the authenticity and the amount of the bank notes and

coins inserted, calculates the total amount inserted by the user before the end of

each transaction, and provides a detailed cash collection report called kiosk logs

after each day for the system administrator.

The system has many integrated security features such as rejecting fake or

deformed bank notes and coins to make sure that only the authentic ones are being

credited; displaying the users information on the screen before accepting the

payment to ensure that the payment will be credited to the correct person; printing

of cash collection report or kiosk logs before resetting the kiosk to safeguard the
data; and providing a backup copy of all transactions that transpired in the kiosk to

the server.

The kiosk systems cash box is safeguarded by a master key that is used to

lock or unlock the cashbox.

Design Specifications

The users activity diagram of the system is shown in Figure 9. It shows the

activities that the system goes through after the user logs into the system.

Figure 9. The Users Activity Diagram of the System

 The flow of activity of the system starts when the user enters credentials such

as student number and password. The system validates the supplied credentials, if

valid, the system displays the students data on the screen; if not, the kiosk displays

an error message and goes back to the log-in screen.

When the user successfully logs into the system, the system allows cash

payment either by bills or coins in Philippine peso denomination. The kiosk

validates the denominations authenticity. If invalid, the system rejects the money,

otherwise, the system reads the amount and update the kiosk logs and database logs

in the server. The user can insert cash in the kiosk system many times as needed.

After the end of the transaction, the kiosk system displays the total amount the user

has entered for confirmation and generates receipt and goes back to the users data

page, the user can again proceed to pay or choose to log out from the system.

The system administrator can also use the system. Figure 10 shows the

Systems Administrators Activity Diagram of the system. In the event of a

successful log in, the system administrator will be able to generate the logs of the

days transaction and has options whether to log out or print a report of the kiosk

logs. If the second option is chosen, the system prints the kiosk logs which holds the

record of all transactions done in a day. This ensures that the system administrator

would hold the report before the system proceeds to the next operation which is

resetting the kiosk counter. When the system administrator logs out, the device is

made ready again for the next transactions. The system administrator can get the

cash from the cash box manually using a master key and manually lock the cash box

using the same key.

Figure 10. The System Administrators Activity Diagram of the System

The sequence of events when the user logs into the system is shown in Figure

11. When the user has successfully logs into the system, the kiosk relays the users

credentials to the main servers database for verification. If the user credentials

exist, the system displays the users data on the screen as a confirmatory display and

allows him to proceed to payment, otherwise the system does not continue to

execute.

When the verified user clicks on the payment button, the kiosk system

receives the message and enables the cash acceptor and the coin acceptor. When the

user inserts bank notes and / or coins, the system sends a message to itself to verify

the inserted moneys authenticity. When the authentication process passes, the kiosk

system reads the amount of the bank notes or coins inserted.

 After the user submits the amount paid, the kiosk system sends the payment

information to the server and also records the transaction to itself and prints a

temporary receipt. The process repeatedly executes until the user stops paying and

logs out from the system.

Figure 11. The Sequence Diagram When the User Logs into the System
Figure 12. The Sequence Diagram When the System Administrator Logs into the

System

Figure 12 shows the sequence diagram when the system administrator logs

into the system to get the kiosk logs. The system administrator must log in using

his/her employee ID number and password. When the log in is successful, the

system administrator must generate the kiosk logs to view all the transactions that

have transpired during the day. When the kiosk logs are shown on the screen, the

system administrator must print the logs and reset the system to re-zero the kiosk

cash counter. The system administrator can gather the cash from the cash box at this
point using the master key. When through, the cash box must be locked by using the

same key. The system administrator can now log out from the kiosk system.

The Circuit Diagram of how the Kiosk system works using a set of Arduinos,

coin acceptor, bill acceptor, Relay, and 12 Volt DC - 2 Amp (12V, 2A) power supply

is shown in Figure 13.

Figure 13. The Circuit Diagram of the Kiosk Systems Cash Acceptors

The kiosk uses 2 Channel Relay Module SPDT, Arduino Uno R3, and

Arduino Mega 2560 R3. When the user enters log in credentials, the coin and bill

acceptors are powered up by the Arduino mega by enabling the ground connection

of the acceptors that are in the relays. If the user drops coins, the coin acceptor

identifies the coins and reads the amount. These data are being passed to the

Arduino Uno device. If the user inserts bills as payment, the bill acceptor identifies
and checks the authenticity of the bill, reads in the amount of the bill and passes the

data to the Arduino Mega device. When the user clicks on the Submit button, The

Arduino Mega device disconnects all ground connections that are in the Relays and

forward all data that are in Arduino Uno and Arduino Mega to the systems program

for computation. The systems program passes all data from the transaction to the

main server and posts update in the kiosk logs.

The Use Case diagram of the systems client side which is shown in Figure

14, shows the users interaction with the kiosk system.

Figure 14. The Use Case Diagram of the Kiosk Systems Client Side

The set of actors are the student, system administrator and the server. The

student can log in, process payment and log out from the system. The system

administrator can log in and out from the system as well, view and print kiosk logs
for the day, and reset the kiosk logs. All payment transactions are saved in the main

server.

Figure 15 shows the Use Case Diagram of the server side of the Kiosk

System. The only valid user of the main server is the System Administrator who can

log in and out from the system, manage the users, and view and print transaction

reports.

Figure 15. The Use Case Diagram of the Kiosk Systems Server Side

The Users credentials that are saved in the main server are being fetched by

the kiosk to authenticate its users.

Figure 16 shows the network diagram of the system. The main server is

connected to a MySQL database server where all the data are stored. The main

server is connected to the kiosk system via a hub. The connection is through the

(Transmission Control Protocol/Internet Protocol) TCP/IP. A printer is connected to

the kiosk system to print receipts. A UPS is connected to the kiosk system to ensure

that transactions is uninterrupted even when electric power is down.

Figure 16. The Network Diagram of the System

Project Development

The study was developed using a prototyping software development

methodology. Figure 12 shows this model.

t
Figure 12. The Prototyping Software Life Cycle Model [28]

The gathering of requirements, during the initial phase, includes the

identification of the problem and formulating solutions, identification of needed

materials and processes to come up with the desired solution.

The researcher has established the need of having a third party that accepts

payments which do not require additional manpower to lessen, if not totally

eliminate, the problem of long queues during payment periods, and to boost

employee productivity. The third party has been identified as the self-service kiosk

system in which students can pay securely without going to the cashiers office. To

come up with an efficient kiosk system, several interviews with electrical engineers

and IT professionals, as well as online researches were conducted. The list of

hardware and software requirements were identified and are as follows: 2 Channel

Relay Module SPDT, Arduino Uno R3, Arduino Mega 2560 R3, 12 Volt DC - 2 Amp

(12V, 2A) Power Supply, Coin Acceptor, Bill Acceptor, Standard PC / Laptop, LAN

cable, RJ 45 Connectors, Mouse, Cash box, wire connectors, durable body of the

kiosk, C#, MySQL, and Win 7 and above OS.

Upon completion of the requirements, the researcher came up with a quick

design, trying every device to ensure accurate and efficient systems prototype. At

this stage, a simple C# program has been tried to make sure the devices complied

with the programming language. Simple prototype of the system has been created

gradually over time with both hardware and software components. C# programming

language was used to control both the kiosk system and the main server. The

MySQL database was used as a storage of data.

 The prototypes of the system underwent several evaluation until a near

perfect device has been developed which is now ready for deployment.

Project Evaluation

The system will be evaluated using a black box testing strategy and ISO

25010 quality conformance.

The blackbox testing is a test to the systems functional and non functional

features as a whole. The testers need not to see the complexity of source codes,

rather focus only on the systems behavior and performance. [29]

In this research, black box testing will be conducted after the systems

implementation to ensure that all required features shall be integrated into it. This

will be carried out by conducting a software acceptance testing through the

functionality, usability and user-experience assessment by the potential users.

The systems overall quality shall conform to that of ISO 25010. This sets the

standards on the softwares functionality suitability, reliability, performance

efficiency, operability, security, compatibility, maintainability, and portability. The

system will be evaluated by IT experts in terms of this international quality

standards.

Data Gathering Instruments

Qualitative and Quantitative data gathering techniques are used in the study.

Qualitative data gathering techniques includes interviews conducted to resource

persons. The data that have been gathered through this means have been analyzed,
filtered and processed to come up with cleansed data repository. Online researches

are also conducted as part of the qualitative data gathering technique. The gathered

data are being compared with the rest of the data to come up with accurate ones.

Conflicting data were eliminated, only confirmed true data were retained.

Quantitative data gathering techniques were also used when the researcher

conducted the users acceptability survey and the ISO 25010 conformance survey.

Two sets of questionnaires were used to gather feedback on how the system

conforms to the standards.

Validity of the Instrument

The survey materials that were used to test the systems conformance to ISO

25010 is also based on the ISO 25010 quality standards, thus considered

internationally accepted and valid.

The Users Acceptability Test (UAT) is conducted by the clients or potential

users of the system. This testing should be based on a defined set of acceptance

criteria that are defined at the project inception. This includes testing the systems

performance and functionality stated in the contract or agreement, thus this is

generally considered as software validation to ensure that the right product has been

built. The UAT can be based on documented requirements, test designs are to be

based on user processes. These can be workflows or other process driven activities

that people will use the software to accomplish. [30].

In this system, the researcher based its UAT on what was defined and stated

as the systems criteria which are its objectives and workflows. The functionality test
was based on the systems objectives. The usability and user experience were based

on work flows. Thus, adopting a process-driven test design.

Respondents of the Study

To evaluate the systems acceptability, 3 sets of potential users will be

randomly selected as the evaluators to assess the systems usability and

functionality.

The first set of users who will perform the UAT will be from the students

group. Five (5) randomly selected students of ISAT U will do the system

assessment; and the second group of evaluators to conduct UAT will be from the

Cashiers Office for they will administer the system once it is installed. Five (5)

personnel from the Cashiers office will do the assessment. The third group of users

who will conduct the UAT will be from the Management Information Systems (MIS)

department for they will be integrating the master database of ISAT U to the kiosk

system once approved by the universitys administrators. Also, five (5) personnel

from the MIS department will be allowed to do the assessment. A total of 15

respondents from different departments will assess the system in terms of its

acceptability.

To evaluate the systems software conformance to international standards, ten

(10) IT personnel from different fields of expertise such as academe, and software

development will be chosen to do the evaluation according to the standards set by

ISO 25010. The IT personnel will evaluate the systems functionality suitability,
reliability, performance efficiency, operability, security, compatibility,

maintainability, and portability.

Data Processing and Statistical Treatment

To determine the degree of users acceptability, the Mean results of the

survey materials from potential users were computed and interpreted independently

using the Likert Scale which has the following result interpretations:

Scale: Interpretation

1.0-1.80 - Strongly disagree

1.81-2.60 - Disagree

2.61-3.10 - Neither Agree nor Disagree

3.41-4.20 - Agree

4.21-5.0 - Strongly Agree

To determine the degree of cohesion between the respondents view about the

system, the standard deviation is computed and interpreted. A small standard

deviation whose value is less than 1 would suggest that there is a high cohesion

between the users views with regard to the systems acceptability; a high standard

deviation tells otherwise.