Chapter 3 METHODOLOGY
This chapter discusses about the system’s 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 student’s 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 user’s 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 reecting fake or deformed bank notes and coins to make sure that only the authentic ones are being credited! displaying the user’s information on the screen before accepting the paymen pa ymen t to ensure ens ure that tha t the t he payme pa yment nt will be credite cre dited d to the correc cor rectt pers p erson! on! printin pri ntin g 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 system’s cash bo" is safeguarded by a master key that is used to lock or unlock the cashbo".
Design Specifications
The user’s activity diagram of the system is shown in #igure $. It shows the activities that the system goes through after the user logs into the system.
#igure $. The %ser ’s &ctivity 'iagram of the ( ystem
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 student’s data on the screen! if not, the kiosk displays an error message and goes back to the log)in screen. *hen the user successfully logs into the system, the system allows cash payment either by bills or coins in +hilippine peso denomination. The kiosk validates the denomination’s authenticity. If invalid, the system reects the mone y, 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. &fter 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 user’s 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. #igure - shows the (ystem’s &dministrator’s &ctivity 'iagram of the system. In the event of a successful log in, the system administrator will be able to generate the logs of the day’s 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 da y. This ensures that the s ystem administrator would hold the report before the system proceeds to the ne"t operation which is resetting the kiosk counte r. *hen the system administrator logs out, the device is made ready again for the ne"t transactions. The system administrator can get the cash from the cash bo" manually using a master key and manually lock the cash bo" using the same ke y.
#igure -. The ( ystem &dministrator’s &ctivity 'iagram of the ( ystem The sequence of events when the user logs into the system is shown in #igure . *hen the user has successfully logs into the system, the kiosk relays the user’s credentials to the main server’s database for verification. If the user credentials e"ist, the system displays the user’s data on the screen as a confirmatory display and allows him to proceed to payment, otherwise the system does not continue to e"ecute. *hen the verified user clicks on the payment button, the kiosk system receives the message and enables the cash acceptor and the coin acceptor. *hen the user inserts bank notes and or coins, the system sends a message to itself to verify the inserted money’s authenticity. *hen the authentication process passes, the k iosk system reads the amount of the bank notes or coins inserted.
&fter 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 e"ecutes until the user stops paying and logs out from the system.
#igure . The (equence 'iagram *hen the %ser /ogs into the (ystem
#igure 0. The (equence 'iagram *hen the (ystem &dministrator /ogs into the (ystem #igure 0 shows the sequence diagram when the system administrator logs into the system to get the kiosk logs. The system administrator must log in using hisher employee I' number and password. *hen the log in is successful, the system administrator must generate the kiosk logs to view all the transactions that have transpired during the day. *hen the kiosk logs are shown on the screen, the system administrator must print the logs and reset the system to re)1ero the kiosk cash counter. The system administrator can gather the cash from the cash bo" at this
point using the master key. *hen through, the cash bo" must be locked by using the same key. The system administrator can now log out from the kiosk s ystem. The Circuit 'iagram of how the Kiosk system works using a set of &rduinos, coin acceptor, bill ac ceptor, 2elay, and 0 3olt 'C ) 0 &mp 403, 0&5 power suppl y is shown in #igure 6.
#igure 6. The Circuit 'iagram of the Kiosk (ystem’s Cash &cceptors The kiosk uses 0 Channel 2elay 7odule (+'T, &rduino %no 26, and &rduino 7ega 089- 26. *hen the user enters log in credentials, the coin and bill acceptors are powered up by the &rduino 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 &rduino %no 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 &rduino 7ega device. *hen the user clicks on the (ubmit button, The &rduino 7ega device disconnects all ground connections that are in the 2elays and forward all data that are in &rduino %no and &rduino 7ega to the system’s program for computation. The system’s program passes all data from the transaction to the main server and posts update in the kiosk logs. The %se Case diagram of the system’s client side which is shown in #igure :, shows the u sers’ interaction with the kiosk s ystem.
#igure :. The %se Case 'iagram of the Kiosk (ystem’s Client (ide The set of actors are the student, system ad ministrator 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. &ll payment transactions are saved in the main server. #igure 8 shows the %se Case 'iagram of the server side of the Kiosk (ystem. The only valid user of the main server is the (ystem &dministrator who can log in and out from the system, manage the users, and view and print transaction reports.
#igure 8. The %se Case 'iagram of the Kiosk (ystem’s (erver (ide The %ser’s credentials that are saved in the main server are being fetched by the kiosk to authenticate its users. #igure 9 shows the network diagram of the system. The main server is connected to a 7y(;/ 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 4Transmission Control +rotocolInternet +rotocol5 TC+I+. & printer is connected to the kiosk system to print receipts. & %+( is connected to the kiosk system to ensure that transactions is uninterrupted even when electric power is down.
#igure 9. The
Project Development
The study was developed using a prototyping software development methodology. #igure 0 shows this model.
t
#igure 0. The +rototyping (oftware /ife Cycle 7odel =0>? 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 w hich do not require additional manpower to lessen, if not tota lly 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 g oing to the cashier ’s 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@ 0 Channel 2elay 7odule (+'T, &rduino %no 26, &rduino 7ega 089- 26, 0 3olt 'C ) 0 &mp 403, 0&5 +ower (upply, Coin &cceptor, Aill &cceptor, (tandard +C /aptop, /&< cable, 2B :8 Connectors, 7ouse, Cash bo", wire connectors, durable body of the kiosk, C, 7y(;/, and *in D and above E(. %pon completion of the requirements, the researcher came up with a quick design, trying every device to ensure a ccurate and efficient system’s prototype. &t this stage, a simple C program has been tried to make sure the devices complied with the programming language. (imple 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 7y(;/ 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 Evalation
The system will be evaluated using a black bo" testing strategy and I(E 08-- quality conformance. The blackbo" testing is a test to the system’s functional and non F functional features as a whole. The testers need not to see the comple"ity of source codes, rather focus only on the system’s behavior and performance. =0$? In this research, black bo" testing will be conducted after the system’s 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)e"perience assessment by the po tential users. The system’s overall quality shall conform to that of I(E 08--. This sets the standards on th e software’s functionality suitability, reliability, performance efficiency, operability, security, compatibility, maintainability, and portability. The system will be evaluated by IT e"perts in terms of this international quality standards.
Data Gathering !nstrments
;ualitative and ;uantitative data gathering techniques are used in the study. ;ualitative data gathering techniques includes interviews conducted to resource persons. The data that have been gathered through this means have been ana ly1ed,
filtered and processed to come up with cleansed data repository. Enline 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. ;uantitative data gathering techniques were also used when the researcher conducted the user’s acceptability survey and the I(E 08-- conformance survey. Two sets of questionnaires were used to gather feedback on how the system conforms to the standards.
"ali#it$ of the !nstrment
The survey materials that were used to test the system’s conformance to I(E 08-- is also based on the I(E 08-- quality standards, thus considered internationally accepted and valid. The %sers &cceptability Test 4%&T5 is conducted by the clients or potential users of the system. This testing should be based on a Gdefined set of acceptance criteria that are defined at the proect incept ionH. This includes testing the system’s performance and functionality stated in the contrac t or agreement, thus th is is generally considered as software validation to ensure that the right product has been built. The %&T can be based on documented requirements, test designs are to be based on user processes. GThese can be work flows or other process driven activities that people will use the software to accomplish.H =6-?. In this system, the researche r based its %&T on what was defined and stated as the systems criteria which are its obectives and workflows. The functionality test
was based on the system’s obectives. The usability and user e"perience were based on work flows. Thus, adopting a process)driven test design.
%espon#ents of the St#$
To evaluate the system’s acceptability, 6 sets of potential users will be randomly selected as th e evaluators to assess the system’s usability and functionality. The first set of users who will perform the %&T will be from the students group. #ive 485 randomly selected students of I(&T % will do the system assessment! and the second group of evaluators to conduct %&T will be from the Cashier’s Effice for they will administer the system once it is installed. #ive 485 personnel from the Cashier’s office will do the asse ssment. The third group of users who will conduct th e %&T will be from the 7ana gement Information (ystems 47I(5 department for they will be integrating the master database of I(&T % to the kiosk system once approved by the university’s administrators. &lso, five 485 personnel from the 7I( department w ill be allowed to do the assessment. & total of 8 respondents from different departments will assess the system in terms of its acceptability. To evaluate the system’s software conformance to international standards, ten 4-5 IT personnel from different fields of e"pertise such as academe, and software development will be chosen to do the evaluation according to the standards set by I(E 08--. The IT personnel will evaluate the system’s functionality suitability,
reliability, performance efficiency, operability, security, compatibility, maintainability, and portab ility.
Data Processing an# Statistical Treatment
To determine the degree of user’s acceptability, the 7ean results of the survey materials from potential users were computed and interpreted independently using the /ikert (cale which has the following result interpretations@ (cale@
Interpretation
.-).>-
) (trongly disagree
.>)0.9-
) 'isagree
0.9)6.-
)
6.:):.0-
) &gree
:.0)8.-
) (trongly &gree
To determine the degree of cohesion between the respond ents’ view about the system, the standard dev iation is computed and interpreted. & small standard deviation whose value is less than would suggest that there is a high cohesion between the user’s v iews with regard to the system’s acceptability! a high standard deviation tells otherwise.
