Registration number 100089332

2017

Developing an Automated AttendanceRegistration System for Universities

Supervised by Dr Wenjia Wang

University of East Anglia

Faculty of Science

School of Computing Sciences

Abstract

Attendance monitoring is a difficult task at higher education institutes, with universities

often having thousands of students and these systems can quickly become complex.

Keeping an accurate record of student participation allows for universities to discourage

truancy, which has been proven to corralate to better academic performance. In addition

to this, for institutions hosting students with Tier 4 visas, it is a legal requirement for

attendance records to be kept for proof of study. Currently the University of East Anglia

uses a paper-based attendance monitoring system, which is time consuming for both

teaching staff and students, and also allows students to sign in by proxy. This project

will begin by discussing technologies and methodolgies that could be used to improve

the system; it will then document the design, development, and testing of a new system,

factoring in these areas for improvement.

Acknowledgements

The University of East Anglia IT Services, for their cooperation.

Dr Wenjia Wang and Dr Pierre Chardaire, for the guidance they have provided.

My friends and family, for their love and support.

CMP-6012Y

Contents

1 Introduction 6

1.1 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Aim and Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2.1 Aim . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2.2 Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2 Literature Review 8

2.1 History and Background . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Existing Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3 Legal Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.4 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.4.1 Near Field Communication . . . . . . . . . . . . . . . . . . . . 11

2.4.2 Wi-Fi Positioning Systems . . . . . . . . . . . . . . . . . . . . 12

2.4.3 Barcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.4 QR Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.4.5 Biometric Authentication (Fingerprint Recognition) . . . . . . . 14

2.5 Development Approaches . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.6 Summary and Key Findings . . . . . . . . . . . . . . . . . . . . . . . 16

3 System Analysis 16

3.1 How the Current System Works . . . . . . . . . . . . . . . . . . . . . 17

3.2 Evaluation of System . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.1 Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.2.2 Actions to Improve . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3 Technological Feasibility . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.3.1 Near Field Communication . . . . . . . . . . . . . . . . . . . . 18

3.3.2 Wi-Fi Positioning System (WiPS) . . . . . . . . . . . . . . . . 19

3.3.3 Barcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.3.4 QR Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

3.3.5 Biometrics (Fingerprints) . . . . . . . . . . . . . . . . . . . . . 20

Reg: 100089332 iii

CMP-6012Y

3.3.6 Evaluation and Decision . . . . . . . . . . . . . . . . . . . . . 21

3.4 Soft Systems Methodology . . . . . . . . . . . . . . . . . . . . . . . . 21

3.4.1 CATWOE Analysis . . . . . . . . . . . . . . . . . . . . . . . . 22

3.4.2 Rich Picture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4.3 Root Definition . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.5 Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

3.5.1 Requirements Table . . . . . . . . . . . . . . . . . . . . . . . 24

4 Systems Architecture 25

4.1 Model-View-Controller Architecture . . . . . . . . . . . . . . . . . . . 25

4.2 Multilayer Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 26

4.3 Proposed Systems Architecture . . . . . . . . . . . . . . . . . . . . . . 27

4.4 Database Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

4.4.1 Database Management Systems . . . . . . . . . . . . . . . . . 28

4.4.2 Database Structure . . . . . . . . . . . . . . . . . . . . . . . . 28

5 Prototyping 29

5.1 Evaluation of Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1.1 Windows NFC Card Reader . . . . . . . . . . . . . . . . . . . 31

5.1.2 TaoTronics USB Barcode Scanner . . . . . . . . . . . . . . . . 31

5.1.3 Eyoyo Barcode Scanner . . . . . . . . . . . . . . . . . . . . . 32

5.1.4 Decision and Reasoning . . . . . . . . . . . . . . . . . . . . . 32

5.2 Languages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

5.2.1 Web-Based Prototype . . . . . . . . . . . . . . . . . . . . . . . 33

5.2.2 Desktop-Based Prototype . . . . . . . . . . . . . . . . . . . . . 33

5.3 Database Construction . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.4 Interface Development . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.4.1 Design Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.4.2 Mobile Optimisation . . . . . . . . . . . . . . . . . . . . . . . 37

5.4.3 JavaScript . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

5.4.4 User Interaction . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Reg: 100089332 iv

CMP-6012Y

6 Testing 42

6.1 Objective . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.2 Testing Levels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.3 Plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

6.4 Test Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

6.5 Conformance Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

6.5.1 Web Application Validation . . . . . . . . . . . . . . . . . . . 45

6.6 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.6.1 PHP Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6.6.2 Java Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6.7 Integration Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

7 Evaluation 49

7.1 Fulfilment of Requirements . . . . . . . . . . . . . . . . . . . . . . . . 49

7.2 System Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

7.3 Future Developments . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8 Conclusion 51

8.1 System Outcomes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

8.2 Personal Development . . . . . . . . . . . . . . . . . . . . . . . . . . 51

References 52

Reg: 100089332 v

CMP-6012Y

1 Introduction

Attendance monitoring has been an issue at universities for a while. With the increased

number of international students attending higher education institutes in the UK, due

to visa requirements, it has become ever-more important to keep accurate records of

student attendance. The current attendance monitoring system at the University of East

Anglia is time consuming for lecturers and allows for students to take advantage by

signing in on behalf of others. This project considers the practicality of implementing a

technological based system that combats proxy sign-ins and also improves the efficiency

of updating registers.

1.1 Motivations

In my second year at the University of East Anglia, I took part in a project looking into

the perception of attendance monitoring at universities, and subsequently began investi-

gating the current system in place. During this time I discovered that, with the exception

of a few departments, there is currently a very primitive paper-based system used for the

recording of attendance at lectures. This method requires teaching staff to upload these

records manually to the electronic system, taking up their time, and also leaves the sys-

tem vulnerable to the falsification of attendance records, in the form of fraudulent proxy

sign-ins. This led me to the consideration that there must be a simpler way to monitor

attendance, which saves time for both staff and students, and also helps to reduce the

cases of proxy register signing.

I have been interested in contactless technology for a while, so this project provided

me with an opportunity to explore this aspect of computing further. Additionally, being

from a Business Information Systems background, over the course of this project I hope

to enhance my ability to approach a software development task, particularly with regard

to my programming skills.

Reg: 100089332 6

CMP-6012Y

1.2 Aim and Objectives

1.2.1 Aim

To propose, design and demonstrate an alternative, automated registration system, that

has the potential to be implemented.

1.2.2 Objectives

• Understand the current failings of the attendance monitoring system implemented

at the University of East Anglia

• Perform research into technologies that can help to combat these issues

• Undertake feasibility studies into whether these technologies are suitable

• Use object-oriented design techniques to plan the production of a system that

makes attendance monitoring more efficient for lecturing staff and students

• Build a prototype of this attendance monitoring system, using some of the tech-

nologies investigated

• Perform various tests on the prototype, and highlight areas than need improvement

• Suggest an implementation plan for the final product

• Provide a write up of significant findings

Reg: 100089332 7

CMP-6012Y

2 Literature Review

2.1 History and Background

Regarding the literature that discusses attendance monitoring, most of the research per-

formed is primarily focused on the attendance of employees within a workplace en-

vironment. Although many of the topics and key themes of this research do overlap

with university attendance, it is very important to establish that there are significant

differences in how each of these should be recorded. For example, as of 2016, at the

University of East Anglia there are 15,444 students enrolled on over two hundred de-

gree courses, across over thirty departments; with lectures taking place in hundreds of

different rooms across a campus that with an area exceeding 3km2. As you can see, this

is significantly more complexed than the notion of clocking in at the workplace and thus

some articles have been dismissed due to this misalignment in systems functionality.

2.2 Existing Systems

The following section will discuss two variations of attendance monitoring solutions

available on the market, those designed for the workplace and those for implementation

at educational institutes; evaluating their appropriateness for use in the context of a uni-

versity.

There is a huge market for attendance monitoring; however many of the products pro-

duced by these companies are mainly targeted for implementation within a workplace

environment; where employee numbers rarely exceed a few hundred individuals, shift

patterns are regular and there is a fixed point of contact for confirming attendance. An

example of such a system is ClockingSystem’s CS Time attendance monitoring solu-

tion. This product offers both facial recognition, NFC card reading and hand scanning

as registering options. From first impressions this looks like an effective system, how-

ever research must be done into the practicality of the installation of terminals in lecture

rooms, and if this implementation will be viable only for larger audiences. It must

also be considered as to whether the system can cope with the volume of data that will

Reg: 100089332 8

CMP-6012Y

be held in the database, and also if the attendance system can be modified to mark in

lectures as opposed to just the measurement of time. Other examples of these business-

centric attendance systems are Replicon and Kronos; although these products can be

used a source of inspiration, they are entirely unsuitable for implementation within a

university environment.

There are also a few systems currently available designed for use in education institu-

tions, an example of this is Time Data Security (TDS) wo are a company that provide at-

tendance monitoring solutions for businesses and colleges. Their system is a standalone

desktop application what works with portable attendance terminals that can either read

card data through radio-frequency identification or barcode scanning. Although this

system is much more practical than the business focussed ones, they still offer limited

customisation for institutional needs and are expensive to implement. Another example

of a similar system is the BioStore Identity Management attendance and registrations

system. Again, much like the one offered by TDS, although it is tailored more toward

educational environments, scope for customisation and implementation costs are also

major drawbacks.

Overall, there are many commercial availabilities which address the issue of mon-

itoring attendance, however it is important to understand what each system is able to

offer, and whether it aligns with the requirements of the university if these options are

pursued. I believe that although many of these solutions do provide insight into how this

issue can be approached, the lack of customisation and overall costs of implementation

across the university makes the pursuit of an in-house development worthwhile.

2.3 Legal Considerations

When storing data, especially that of a sensitive nature, it is important to understand the

how it should be kept and handled. The 1998 data protection act provides a basic set of

fundamental procedures. When implementing a system which stores personal informa-

tion regarding thousands of individuals, encryption and security must be considered as

a primary concern and steps must be taken to mitigate related risks.

Reg: 100089332 9

CMP-6012Y

Almost all international students from outside of the European Union, that study in

the United Kingdom, are here on Tier 4 visas, which require holders to attend a mini-

mum number of lectures to prove their student status. Sponsor institutions are required

by the Home Office to inform them when Tier 4 visa students have finished their studies

and subsequently must record the attendance and participation of these students (uk-

cisa.org.uk, 2017). Having a large demographic of international students, the Univer-

sity of East Anglia have stringent rules on monitoring attendance appropriately. The

following passage is taken from the University of East Anglia website: The University’s

General Regulation 13 (7) permits the University at any time to suspend or preclude

from further study: (a) any student whose attendance and engagement is deemed to be

unsatisfactory; (b) any student who fails to make satisfactory progress in the programme

of study. (UEA, 2017)

Overall, both government and university policy dictate that attendance monitoring

records must be kept up to date and be held as accurately as possible. Therefore, during

the development of the project attention must be given to effective systems testing in

order to ensure that any risks that may compromise this, such as data loss, database

issues and issues with query performing functions are prevented.

Reg: 100089332 10

CMP-6012Y

2.4 Technologies

2.4.1 Near Field Communication

Although Radio Frequency Identification (RFID) technology dates to World War II; the

first record of this technology being filed for patent wasn’t until 1970. (Palmer, 2009).

Initially, this technology was primarily used for Military access purposes, however, as

time went on, and RFID technology became cheaper to implement, it began to enter the

public domain. (Landt, 2005).

Near Field Communication (NFC) is a subset of RFID technology, and specifically

refers to close proximity communication between an RFID chip and a reader (within

4cm) - (Android Authority). NFC comes in two variations; active and passive. Passive

devices cannot interact with one-another, but can send information to active devices

without the need for a power source, passive devices do not usually process informa-

tion from other sources (reading of access cards). Active devices can both send and

recieve data, and communicate with each other, such as contactless payment terminals

and smartphones. NFC have many applications in the real world, including contact-

less phone and card payment, access control to buildings, e-ticketing, keyless cars and

identity verification. Communication occurs through a mechanism called "load mod-

ulation"; variations in current within the antenna of a tag results in a small variation

of current in the readers antenna, and this variation is what the reader receives - these

frequencies are typically either 128 kHz or 13.56 MHz (Chawla and Ha, 2007).

Figure 1: Near-field communication using inductive coupling (Chawla and Ha, 2007).

Reg: 100089332 11

CMP-6012Y

Geven et al. (2007) provide four metaphors for the classification of NFC interactions.

These interactions

Interaction Metaphor Description ExampleReading Barcode Scan-

ner

NFC used to convey in-

formation

Marketing and social

networking

Verification Ticket NFC controlling access eTickets and access

control

Payment Credit Card NFC as an alternative to

cards or cash

Banking and contact-

less payment

Peer-to-Peer Cable NFC in peer-to-peer

networks

File sharing and

streaming

Table 1: Geven et al.’s NFC metaphores.

As an application increases in complexity of data transmission from reading to peer-to-

peer, the costs of security also increases (Jones, 2014). This notion must be considered,

ensuring the interaction type is appropriate for the context of the situation.

2.4.2 Wi-Fi Positioning Systems

A Wi-Fi Positioning System (WiPS) is a system that works to locate users of wireless

networks through their access points. As well as allowing for wireless data transfer

between machines, Wi-Fi can also be used to locate a device. Radio waves, being on

the electromagnetic spectrum, travel at the speed of light. Therefore, by comparing the

times of when data is sent from a modem, to when it is received by a device, we can

establish what distance it is from the modem.

If we have access to three modems, by using something called trilateration, we can

work out a precise location. Trilateration works by measuring the distance of an object

from three separate locations called access points. The location of the object is where

all three ranges meet. As radio waves are emitted uniformly from the centre of a

Reg: 100089332 12

CMP-6012Y

modem and travel at a constant speed of 299, 792, 458 m/s, if the times can be recorded

to an accurate enough degree, then the location of a device can be determined.

Research performed by Shin et al. (2010) has been used for the evaluation of the prac-

ticality of implementing an attendance monitoring system within a university environ-

ment.

2.4.3 Barcodes

Barcodes are the graphical representation of identifying information formed by a two

dimensional pattern of black and white shapes which are able to be read by optical

devices (Investopedia, 2017).

Barcodes work on the premise of encoding data into lines of differing widths and

sizes, that when read reveals the original data. They were developed in 1948 by Joe

Woodland, and were originally designed for automatically reading product information

at supermarket checkouts. Light is emitted from a scanner and shone on the barcode,

reflected light is then picked up by a sensor and converted into readable data. This

allows for the recording of a vast amount of data, in a very quick time-frame. (Weight-

man, 2017)

Papers by Kassem et al. (2010), and by Benyó et al. (2012) discuss their usage in atten-

dance monitoring and will be evaluated in the technological feasibility section of this

report.

2.4.4 QR Codes

Quick Response (QR) Code were developed in 1994 by Japanese company Denso-

Wave, to allow for high-speed scanning of components during the manufacturing

processes for tracking purposes. QR Codes Allow for four data storage techniques: nu-

meric, alphanumeric, binary (ISO 8859-1), and Kanji (logographic Chinese characters

used in modern Japanese writing). (Mobile-QR-Codes.org, 2017). Although similar to

barcodes, 1D Barcode (UPC/EAN) con only store up to 30 numbers, a QR code can

Reg: 100089332 13

CMP-6012Y

store up to 7,089. (whatisaqrcode.co.uk, 2017).

QR Codes became more and more popular as people began to appreciate their reading

speed, accuracy and functional characteristics, namely its correction abilities - being

capable of restoring data, even when a significant segment of the code is missing or

damaged; and also the ease of use, with many smartphone applications available for the

production and reading of codes (Rouillard, 2008).

A paper by Masalha (2014) discusses the practicalities of implementing a QR based

attendance monitoring system, which is discussed in further detail later in this report.

2.4.5 Biometric Authentication (Fingerprint Recognition)

In recent year, biometrics has come to mean the identification of individuals using bio-

logical traits (Biometricsociety.org, 2010). Whilst there are many biometric measures

(including facial recognition and retinal scanners), due to the time restraints upon this

project and the implementation costs that would be incurred, I will only be investigating

fingerprint identification.

There are three main methods of rendering this surface map: optical, ultrasonic and

capacitance. Optical fingerprint imaging is achieved by capturing visible light from

the touch surface, this produced the lowest quality fingerprint representation as it

is majorly effected by contaminants on the surface of the touch surface. Ultrasonic

imaging uses ultra-sonic sound waves and piezoelectric transducers to form a map of

the fingerprint. As the dermal skin layer has the same characteristic as the fingerprint,

the reflected wave measurements can form an image of the fingerprint without the

need for a undamaged skin and a clean touch surface. The final method of fingerprint

recognition is the use of capacitance sensors, which uses electrical charge to measure

the ridges and valleys of a fingerprint to generate a surface map.

This literature identifies papers by Rao and Satoa (2013), by and Shoewu and Idowu

(2012), as a basis for consideration when discussing feasibility.

Reg: 100089332 14

CMP-6012Y

2.5 Development Approaches

This section will discuss and summarise the software development standards which will

could used during the design of this system. A report collated by the Department of

Health and Human Services (2005) discussed various development approaches, and the

situations they are most appropriate for; having analysed their report I have short-listed

Spiral and Rapid Application Development as two potential candidates. In addition to

this I will also be making reference to the Agile development methodology.

Developed by Boehm (1988), the Spiral methodology is designed primarily for the

mitigation and minimization of risk during the software development lifecycle. Four

key quadrants of this spiral are considered before the next stage of development is

initiated; these steps are determining objectives and alternatives, evaluation of these

alternatives, development of system and verify deliverables, and planning of the next

iteration. Criticisms of this approach are that the lack of specific deadlines or iteration

termination criteria can cause project to go over budget and exceed overall deadlines,

and also the need for experienced project management to implement.

Rapid Application Development puts priority on the quick production of quality

software; this is achieved, much like the Spiral methodology, by segmenting a project

into smaller parts, improving flexibility for requirement and scope changes. Focus is

invested into prototyping and active user involvement and fulfilling user / business

needs carries more importance than technological excellence.

The Agile approach to systems development stems from the 2001 Agile Manifesto

(Beck et al., 2001), which puts forward a list of twelve principles which encourage

projects to embrace change and uncertainty in the software development lifecycle.

Agile is comprised of many different frameworks, all of which have a mutual approach

to producing working functional software within two-six week cycles, which responds

to change (Highsmith and Cockburn, 2001). Agile is particularly beneficial for the

accommodation of changing requirements and scope creep; however there have been

criticisms that it is more of a management fad rather than a solution to uncertain

Reg: 100089332 15

CMP-6012Y

environments, and that within large organisations which have complex systems, it can

be too extreme.

When approaching the development of a system, it is important to understand fully

the environment it functions in. If there is potential for changes in this environment,

being capable of having flexibility with both scope and direction, post design stage, is

an important factor. Equally, this must be balanced with some form of plan in order to

ensure time a resources are not wasted.

2.6 Summary and Key Findings

This literature review has highlighted the key areas which must be considered and

the relevant background information regarding these areas; providing a basis for the

design and development process. This includes understanding what existing systems

are available, and benefits they provide; what technologies can be utilised in the context

of the problem domain, and how these technologies work; and potential development

techniques that can be taken and what type of projects they are most appropriate for.

Ten articles have been suggest for when approaching feasibility and three potential de-

velopment approaches have been put forward as candidates to pursue during the devel-

opment stage.

3 System Analysis

The following section of this report will provide a brief description of how the current

attendance monitoring system works within the University of East Anglia. It will then

discuss areas in which improvements can be made in order to assist in the developments

of requirements.

Reg: 100089332 16

CMP-6012Y

3.1 How the Current System Works

Student data; including their personal information, academic performance, addresses,

emergency contacts, financial information, timetabling, and attendance records are

stored on an online system called e:Vision. Data is accessible to view by both staff and

students, subject to access permissions, and due to the sensitivity of this information is

stored on a secure server on-site.

Currently, teaching staff are required to print out registers prior to a seminar / lecture,

these attendance sheets are then dispersed throughout the room and students sign their

names to mark their attendance. On the attendance monitoring system, it is assumed that

all students are present, then staff manually go through the attendance sheet looking for

missing students and update the records manually.

3.2 Evaluation of System

3.2.1 Issues

Through my research I discovered two significant issues with the current system in

place at the University of East Anglia; the first issue is proxy register signing, the

second issue is the time and effort necessary for staff to mark attendance.

Proxy signing is the act of getting another person to mark your attendance at a lecture in

which you are not present. This act is strongly opposed by the university and although

measures have been put in place to combat this occurrence (such as the inclusion

of photographs on the registration system), this is still a prevalent issue, particularly

with international students. It can be extremely difficult to authenticate signatures

(especially within larger classes), and images of students are only useful within smaller

lecture theatres or seminar groups, where it is possible to feasibly check the faces of

those on the register against those in the audience.

The issue surrounding the time and effort required to mark the attendance is a topic

of debate for many teaching staff. As the system works on the basis of assumed at-

Reg: 100089332 17

CMP-6012Y

tendance, for lectures with low enrolment and high attendance it is not a particularly

time consuming process, as the paper register is completed quickly without disruption

and the physical act of marking the attendance is also simple. However, for some mod-

ules, there can be in excess of 300 students enrolled with particularly low attendance

around holiday periods; making the attendance marking for these lectures a very time

consuming experience.

3.2.2 Actions to Improve

With respect to the prevention of proxy sign-ins, I think any steps taken to facilitate the

removal of a paper based system would significantly reduce the number of incidents.

Biometrics would be a particularly powerful tool for the prevention of falsifying

identification, however consideration must be given to the technical, legal, and financial

practicality of implementing a system of this type. The reading of student cards

(whether that be via NFC or scanning) would also help to prevent the cases of proxy

sign-ins; so that is also an area worth exploring.

To improve the efficiency of attendance taking, the implementation of a fully (or at least

partly) automated system should be considered. Again, consideration to the feasibil-

ity of implementation must be made; both in terms of usability, appropriateness, and

financial costs.

3.3 Technological Feasibility

3.3.1 Near Field Communication

With respect to attendance registering, two studies at the Budapest University of

Technology and Economics, and the Notre Dame University Louaize, identified that

the key advantage of the implementing an NFC attendance monitoring process is the

reduction in the complexity of administration. Benyó et al. (2012) (Kassem et al., 2010).

Limitations of this system include the difficulty caused if lectures are moved, requiring

the constant checking and updating terminals to ensure they are collecting data for the

Reg: 100089332 18

CMP-6012Y

correct lecture. Also, for this system to work, every lecture hall would have to have a

terminal installed at the entrance, which would cause substantial implementations costs.

With respect to the feasibility of NFC within my system, readers are already in installed

at the entrances of some lecture theatres at the university, so it would be possible to take

advantage of this. NFC is also a very quick and efficient means of reading data, and in

the future NFC enabled phones could be used too. However, not all rooms have NFC

card readers, so for campus-wide implementation it may be expensive. Extra security

measures may also be required too due to the increased number of access points.

3.3.2 Wi-Fi Positioning System (WiPS)

During my information search, I failed to find any attendance monitoring systems that

functioned using a WiPS, however, as there is an average of only three meters in error

for geo-location (Shin et al., 2010) there is no doubt regarding the ability for WiPS to

produce a precise enough location approximation. The key benefits of WiPS is that wi-fi

spreads over the entirety of campus so every room would be covered, and its capability

to generate location coordinates, providing further evidence that student is at the lecture.

However wi-fi within the university is notoriously unreliable, so registers could be

missed, also, not every student will be able to bring a device capable of connecting

to wi-fi to every lecture, which would prevent them from successful registration.

3.3.3 Barcodes

Barcode-based attendance monitoring systems have been the subject of many studies,

however this report is considering two. (Sudha et al., 2015) (Moksin and Yasin, 2009).

In both cases they model a three step procedure for the logging of student attendance. A

student scans their card, the scanner then sends data to a monitoring system, this system

then saves this data to a server; once this data has been uploaded reports can be printed.

Although these papers give a comprehensive evaluation of systems architecture, there is

little written about implementation methods or software design, and there is no mention

of testing or implementation.

Reg: 100089332 19

CMP-6012Y

Every campus card has a unique barcode already (no cards would have to be reprinted

and there is already the processes in place to generate bar codes). This method is also

much quicker than the current signing of the register, and the requirement of campus

cards discourages proxy sign-ins. However, issues can arise if student a does not have

their campus card, and either every room, or every lecturer would need a scanner; which

would incur significant costs.

3.3.4 QR Codes

Masalha (2014) proposed the idea of implementing a student attendance monitoring

system using the capturing of QR codes to mark attendance. The system worked on

the premise that a unique QR code would be scanned by a student using an application

on their mobile phones; the scanning of this code would then mark their attendance

and transfer their location as well as an image of their face for verification. Although

this system was successfully implemented on a small scale, it is quite a complex and

convoluted experience for both staff and students involved and assumes that every

student has access to a smartphone and internet.

QR codes would be one of the quickest ways for students to register, however software

would have to either be manufactured or bought-in that could generate a code for each

lecture; and a mobile phone app would also have to be developed that can read the code,

identify the student and register them, which would be very complex and require large

amounts of time and investment to implement. Also, there is the added issue of ensuring

identity; and students without access to smartphones would also be at risk of not being

able to register.

3.3.5 Biometrics (Fingerprints)

Biometrics are used widely in attendance monitoring, and there are many journals dis-

cussing its success. Rao and Satoa (2013) and Shoewu and Idowu (2012) both consider

the practicalities of developing and implementing fingerprint recognition attendance

monitoring. In each of their papers, the benefit of accurate student identification and

Reg: 100089332 20

CMP-6012Y

ease of use are highlighted as primary motivators for the implementation of such a

system. Although these benefits do exist; there are areas which I believe have not been

discussed in enough detail.

The process of recording the initial student metrics which will be used as a sample for

caparison will be a substantial undertaking, the financial cost of implementing terminals

in each lecture room , and the legal implications apparent with the storage of biometric

data are all factors which hinder the appropriateness for implementation (East Sussex

County Council, 2017). For these reasons I did not believe that the pursuit of biometric

identification for registration is a feasible option within the context of my system.

3.3.6 Evaluation and Decision

After having considered these technologies, I decided that when entering the prototyp-

ing stage I would be pursuing the investigation Near Field Technology and barcode

scanning in further detail. The reasoning behind this was the availability of both Near-

Field Communication and barcodes within the university already. Other key factors for

this decision included the implementation costs (in terms of both time and resources)

for QR codes and biometrics, and the complexity and unreliability of basing attendance

on the the use of wi-fi for the generation of student locations.

3.4 Soft Systems Methodology

The Soft Systems Methodology was developed by Peter Checkland during his time at

the University of Lancaster. It is a set of loose tools that can be used as a means of

refining a vague problem into a set of definite requirements. The methodology con-

sists of seven stages; stage one is to provide an unstructured definition of the issue, the

second stage is to structure it by using tools such as a CATWOE analysis and a rich

picture, these can then be used to form a root definition, stages four and five involve the

production of conceptual models and comparing them to real world situations, the final

two stages are the performance of feasibility studies and the implementation of these

actions.

Reg: 100089332 21

CMP-6012Y

3.4.1 CATWOE Analysis

Customers Lecturing staff, administration staff, university students

Actors University of East Anglia, staff, students, the government

Transformation Make a record of students who have and have not attended

lectures

Worldview An automated system that registers the attendance of stu-

dents at university lectures and allows lecturers to view

statistics about the attendance of students, and the atten-

dance for modules.

Owner University of East Anglia

Environment Data protection laws, visa laws, university policies, govern-

ment regulations

Reg: 100089332 22

CMP-6012Y

3.4.2 Rich Picture

Figure 2: Rich picture of current system

3.4.3 Root Definition

A system owned by the University of East Anglia, operated by lecturing staff, maintained

by administrative staff and used by students, that allows for the automated registration

of students at lectures; constrained by data protection laws and university policy.

Reg: 100089332 23

CMP-6012Y

3.5 Requirements

Requirements for this project where explicit, so elicitation was as a quick process. Once

identified, a list of these requirements, they were then split into functional and non-

functional categories; and a MoScoW analysis was performed.

3.5.1 Requirements Table

Requirement ID Requirement Description MoSCoWFR01 Accurately update attendance records Must

FR02 Be accessible from both desktop and mobile devices Must

FR03 Provide means to contact a student Should

FR04 Generate a list of students with poor attendance Should

FR05 Accurately calculate attendance statistics Should

FR06 Ability to provide reasons for authorised absences Should

FR07 Allow for the exporting attendance data Could

FR08 Integrate with the current e-vision system Won‘t

FR09 Log student arrival time or location Won‘t

Table 2: Functional requirements

Requirement ID Requirement Description MoSCoWNR01 Be able to automatically mark student attendance with

an interaction time of less than three seconds

Must

NR02 Be fully tested on multiple browsers and devices to

ensure optimised interface

Must

NR03 Page load times of less than five seconds Should

NR04 Good user support through the display of error mes-

sages

Should

NR05 Accessibility standards are met Should

NR06 HTML and CSS validation for web application Should

NR07 Update register without internet connection Won‘t

Table 3: Non-Function requirements

Reg: 100089332 24

CMP-6012Y

4 Systems Architecture

The systems architecture governs the method in which data is stored, transferred, ma-

nipulated an displayed. This following section will discuss two prevalent architecture

approaches (MVC and Multilayer), proposing an approach which should be taken dur-

ing the development of this project; consideration will also be given to database design

options, suggesting a structure.

4.1 Model-View-Controller Architecture

One of the most widely adopted approaches to software development architecture is

model-view-controller. This is where the data manipulation, and the user interface are

completely decoupled; and interactions are achieved via a controller, each element is

only concerned with receiving the correct data in an appropriate format.

Table 4: Example of an MVC architecture

Having a completely decoupled system is beneficial for many reasons. For one, it is

much easier to maintain - segments of the system can be updated or replaced without

worrying about how it will effect other processes. Secondly, adding functionality and

Reg: 100089332 25

CMP-6012Y

dealing with changes to scope is also made easier by using a decoupled architecture;

legacy code does not need to be rewritten to adjust for additional code modules. A third

area which benefits from a decoupled approach to systems architecture is implementing

a platform changes; if the data storage and handling is processed separately from the

interface, then replacing the way the data is displayed to end users allows for code re-

usability, meaning quick and simple platform changes.

4.2 Multilayer Architecture

Multilayer Architecture is the physical separation of data management, data processing

and visual presentation functions. Although in some circumstances, a systems can have

more layers, this "three layer architecture" is the most standardised approach.

Table 5: Example of a three-layer architecture

As the three-layer architecture allows for the segmentation of processes, it means that

additional functionality / changes to a system can be implemented without the require-

ment of the redesigning of the entire system. Also, the preserving of independent mod-

ules on separate platforms ensures simpler system maintenance. (Technopedia, 2017)

Reg: 100089332 26

CMP-6012Y

4.3 Proposed Systems Architecture

With regards to approaching the architecture, I split the overall system into two primary

subsystems. The first subsystem is a web application that deals with the storing of

attendance data, and the generation of visual statistics. This will be delivered as a

mobile optimised website, only accessible by staff. The second subsystem will be a

desktop application that can be downloaded easily to the personal computers of lec-

turing staff and will be pre-installed on university computers. The desktop application

will adhere to the MVC architecture to segment the interface design from the data

manipulation process, and the web-application will use a three-layer architecture to

manage transaction with the database.

Table 6: Architecture of proposed system

When timetabling is completed before each semester, lecturing staff will be sent a zip

file containing all the lectures they are scheduled to teach. Before each lecture, staff

will be required to open the desktop application and upload the relevant file, then they

will need to connect their computer to some type of device capable of reading student

data from campus cards. This device will can then either be handed around the lecture

hall, or be places at the entrance, allowing students to scan their cards and mark their

attendance. At the end of the lecture this file it then overwritten and can be uploaded to

the website to complete the registration process.

Reg: 100089332 27

CMP-6012Y

A simple, external system will also be built for administration purposes, that allows

for the authorisation of absences. This will have no effect on the registration system,

communicating only with the database; so has not been included in the diagram.

4.4 Database Design

4.4.1 Database Management Systems

Database management systems are pieces of software designed to help with the

capturing, structuring and manipulating of data stored within a server. Well known

DBMS variations are MySQL, PostgreSQL, MongoDB, MariaDB, Microsoft SQL

Server, Oracle, Sybase, SAP HANA, and MemSQL.

When considering DBMS it is first important to establish which form of database

to use, RDBMS or NoSQL? Although query execution is much quicker for NoSQL

databases, such as MongoDB (Hadjigeorgiou, 2013); when speaking with the Head of

CIS Development, he informed me that the University of East Anglia use the Oracle

DBMS for the management of student data, so as a result I refined my choices to

Relational Database variations.

4.4.2 Database Structure

When designing the structure of the database, I identified four tables necessary for data

storage; modules, lectures, staff and students. The ‘modules’ table contains information

about each module and the ‘lecture’ table holds data pertinent to each individual

lecture. The final two storage tables hold user data; staff and student. I had originally

considered having one table to contain all user data, however as students and staff are

involved in completely separate database transactions, storing them separately reduces

search time for values and subsequently improves query speed. Additionally, as only

staff require login credentials, storing them in separate tables avoids the assignment

of memory for passwords to students. Within the database definition, the maximum

varchar length for passwords is forty characters, meaning that each password field in

Reg: 100089332 28

CMP-6012Y

each tuple is 41 bytes. Therefore, if the system were to be scaled to account for the

entire university (15,444 students), using separate tables would save 633,204 bytes of

storage.

Table 7: Structure of the database.

In addition to the four core data storage tables, there are three relational tables. These are

used to form relationships between each of the individual entities. The ‘teaching_staff’

table dictates which staff are involved with which modules, the ‘enrolled_on’ table re-

lates students and the lectures they should be attending and finally the ‘teaches’ table

identifies which lecture is being taken by which lecturer. It is important that the keys

are appropriately identified and that relational integrity is maintained and data deletion

is cascaded to ensure that rogue values are not being stored.

5 Prototyping

5.1 Evaluation of Hardware

Barcode and Near Field Communication are favourable candidates as appropriate

technologies, as they are both already in place within the University of East Anglia.

Reg: 100089332 29

CMP-6012Y

Access permissions are embedded into campus card chips and readers are installed to

allow entrance to secure doors; NFC readers are also used for ticketing at events that

occur on campus. Barcode readers are in place at the university’s sports facilities, to

allow entrance; and the library borrowing system also works with barcode technology.

The following section of this report documents the appraisal of available Barcode

and NFC technologies on the market, that could be used for implementation of my

prototyped system within the University of East Anglia.

Figure 3: Examples of NFC and Barcode technologies already implemented within the

University of East Anglia

During this analysis, I will be evaluating a few of the off-the-shelf technologies avail-

able; exploring their benefits and flaws, and appraising the appropriateness of their po-

tential implementation; consideration will be given toward practicality, difficulty, effec-

tiveness and financial costs. The three selected technologies that feature in this analysis

are: the Windows NFC card reader; the TaoTronics USB barcode scanner, and the Ey-

oyo bluetooth barcode scanner.

Reg: 100089332 30

CMP-6012Y

5.1.1 Windows NFC Card Reader

After a while searching the internet, I found an NFC card reader online, and promptly

made a purchase.

Price £9.99

Devices PCs, Laptops

Compatibility Windows XP, Windows 7, Windows 8,

Windows 10

A simple "plug and play" set-up, this scanner is compatible with Windows laptops and

desktops, allowing for the transfer of data through tapping a NFC card. However, there

are major issues - as a result of its cabled nature, there is a necessity for proximity to

the registration recording device; there is no scope for compatibility with non-Windows

devices in the future. Also this device only works with unencrypted cards, so either a

different (and possibly more expensive) reader would have to be acquired, or modifica-

tions would have to be made one in order to read UEA campus cards.

5.1.2 TaoTronics USB Barcode Scanner

Continuing my search online, this was the first barcode scanner that I came across;

the TaoTronics USB scanner. It was one of the cheapest on the market that still had

favourable reviews, so again, I decided to purchase it and investigate.

Price £29.99

Devices PCs, Laptops

Compatibility Windows XP, Windows 7, Windows 8,

Windows 10, MacOS

Also having a simple set-up; this scanner is compatible with most laptops and desktops.

However, much like the NFC reader, it does suffer from limitation that it is cabled, so

Reg: 100089332 31

CMP-6012Y

without a method of extension, it means students are required to be in close contact with

the registration device.

5.1.3 Eyoyo Barcode Scanner

After further research, I came across this scanner; more expensive by £10, it does

however come with joint bluetooth technology, allowing for the wireless connection to

the lectures device. This would enable either the passing around of the scanner during

a lecture, or the fixing of a scanner to a point by the entrance and connection from the

lectern; simplifying the registration process further.

Price £39.99

Devices PCs, Laptops, Smartphones

Compatibility iOS, Android, Windows XP, Windows 7,

Windows 8, Windows 10, MacOS

5.1.4 Decision and Reasoning

After evaluating these three hardware options, I decided the most practical device for

the pursuit of implementation was the Eyoyo Barcode Scanner. The cabling of both the

TaoTronics scanner and Windows NFC reader would require a terminal of some sort to

be installed. The use of a bluetooth reader gives the option of either a fixed scanner in

the lecture theatre, or the ability to pass it around the hall. Also, the use of barcodes

instead of NFC readers remove the necessity to deal with encryption.

5.2 Languages

An important decision in a software development is deciding which language to write in.

Due to the time scale of the project I decided that it would be best to pursue languages

I already had familiarity with, which narrowed my options down to Java or GoLang for

the desktop portion, and PHP or Python for the web element. The following section will

Reg: 100089332 32

CMP-6012Y

discuss these options, and the justifications of my decisions.

5.2.1 Web-Based Prototype

Python has been around for over twenty years, however it has only recently become a

popular web language. As a result of this surge in popularity during the exponential

growth of the world wide web, there are more libraries and frameworks available with

Python than there are with PHP, and debugging and testing is also generally quicker

with Python. However Python is still a growing language in comparison with PHP; and

is therefore evolving at a much faster pace. Although this is a good thing in terms of

increased capabilities, code can quickly become outdated, making future maintenance

more of an important influence to factor for.

PHP on the other hand is generally considered as one of the sturdier server-side

web-based programming languages, and although unit testing and debugging can be

more difficult than with other languages, when you get the code working well it tends

to breaks less. However, the frameworks available for PHP (Laravel and Symfony) are

more primitive than those for Python (Flask and Django). Although this isn‘t so much

of an issue for an early prototyped version, it is a very important consideration for

implementing a scalable live version.

For the purposes of building this prototype I opted for using PHP. This is because I was

more experienced with this language, and due to time restraints, it was more effective

for me to work with a familiar language. If more time were available, I would have done

further research into the scalability of Python, and also establish how it would integrate

with the other systems in place at the University and make a decision based on these

factors.

5.2.2 Desktop-Based Prototype

Android applications are developed primarily in Java, therefore if a native mobile

application were to be pursued then many of the classes could be reused. I am also

experienced with Java so I could begin programming immediately after the system

Reg: 100089332 33

CMP-6012Y

design process. GoLang was developed especially for the purpose of concurrency,

meaning that it can process data much faster than Java, and when there are thousands

of data transactions happening daily it make a huge difference. Being a relatively

new language, there is much less support available compared with Java. Also when

building, maintaining or improving the system, finding developers to assist could be

difficult and would also be more expensive.

I chose to use Java for the development of the desktop portion of this application. The

reasoning for this is because I had a greater knowledge of Java, and also as it is the base

language for android development, so if a native application is pursued later, classes

could be reused.

Figure 5: Constituent classes and associated methods of Java application.

5.3 Database Construction

I attempted to find web hosting that offered Oracle DBMS for the purposes of future

integration, however I struggled, with MariaDB being my only option with most

Reg: 100089332 34

CMP-6012Y

mainstream online avenues. My implementation will be running on server space hosted

by one.com; on a live version I would insist on hosting the server locally on-site, and

for it to maintain a Secure Sockets Layer (SSL) to ensure the proper encryption of

sensitive data; however for testing with false data, this is currently not necessary.

With my web hosting company, a tool called MyPHP Admin was made available to me.

This allowed for the quick construction of tables and insertion of data.

Figure 6: Database management via backend web application.

CREATE TABLE IF NOT EXISTS ‘ s t a f f ‘ (

‘ s t a f f _ i d ‘ i n t ( 1 1 ) NOT NULL AUTO_INCREMENT,

‘ f i r s t _ n a m e ‘ v a r c h a r ( 3 0 ) NOT NULL,

‘ l a s t_name ‘ v a r c h a r ( 4 0 ) NOT NULL,

‘ schoo l ‘ v a r c h a r ( 3 ) NOT NULL,

‘ emai l ‘ v a r c h a r ( 4 0 ) NOT NULL,

‘ password ‘ v a r c h a r ( 4 0 ) NOT NULL,

PRIMARY KEY ( ‘ s t a f f _ i d ‘ )

)

5.4 Interface Development

Interface layout is a key element in the user experience - a clear and simple design which

is intuitive and makes it easier for users to navigate. The following section of this report

will discuss the consideration made for the design of both interfaces and interaction

processes to enhance user experience.

Reg: 100089332 35

CMP-6012Y

5.4.1 Design Scheme

Having a consistent uniform appearance gives a professional feel to a system, so when

approaching the design of this application I wanted it to fit in with the current design of

the universities other systems, so I considered the current design and branding features

in place. Recently, UEA have spent a large sum of money on new branding and so I

investigated this.

Figure 7: UEA website design and branding

After taking a quick tour of the universities various applications (namely the UEA

website, e-vision and blackboard), it became evident that there was key colour scheme

of blue, white, and black, with the exact colours being #00AEEF, #000000 and

#FFFFFF. During the design process I tried to keep as true to this design-scheme as I

could, however due to the specificity of some of the functions being performed, there

are some elements that are unique.

For consistency of design scheme for the desktop application, a framework was devel-

oped in JSwing and used as bases for the design of each interface panel. For the web

element of the system, the use of Bootstrap was considered; however, Gerchev (2014)

states that such frameworks involve the inclusion of large amounts of unnecessary

code, provides limited scope customising elements when needed, and involves taking

the time to understand how these external files effect the overall system; so therefore

a customized styling sheet was created and a base HTML template was generated for

conformity. Elements which remained the same throughout the whole system (such as

the menu bar) were also imported from external PHP files, so any changes necessary

could easily be disseminated through the change of one file.

Reg: 100089332 36

CMP-6012Y

Figure 8: Web interface design.

Figure 9: Java interface design.

5.4.2 Mobile Optimisation

Mobile phone usage has been growing exponentially since the late 1990‘s, and in 2015,

the number of adults in the U.K. who access the internet through smartphones rose to

66% (Ofcom.com, 2017). This is compounded by the ComScore (2015) statistic which

showed that in 2015, for the first time ever, the number of people who can only access

the internet via desktop dropped below the number of people who exclusively access

it by mobile. As a result of this, many companies have designed their systems for

mobile platforms; whether this be native smartphone and tablet applications, or mobile

Reg: 100089332 37

CMP-6012Y

optimised web applications. In today’s technological market, mobile optimisation is

imperative for any web-based application. Since the development of smartphones in

the early 2000s, the number of users accessing information on portable devices has

grown enormously. Subsequently vasts amounts of research has been done into creating

standardised practices for effective mobile design.

For mobile optimisation, the web browser can dynamically detect the size of the screen

and subsequently CSS was used to adjust element sizes based on the device dimensions.

/∗ Mobile ∗ /

@media on ly s c r e e n and ( max−wid th : 900 px ) {

}

Any design code placed within these braces will be used to determine the layout of

content when viewing on an device that has a screen dimension of less than 900px (most

tablets and all mobile phones). MyDevice.io offers a list of CSS device dimensions for

the most popular mobiles and tablets. With only the exception of the Apple iPad Pro

and the Microsoft Surface Pro 3, all devices on this list had a width of less that 900

pixels. At this stage I considered altering the design to increase the change condition

to trigger at 1024 pixels (to include the two outliers), however it could then lead to the

mobile version being the default for Notebooks, which would not have been ideal, so I

decided to remain with 900 pixels.

Figure 10: Statistical graphics rendered on desktop vs mobile.

Reg: 100089332 38

CMP-6012Y

In addition to the optimisation of HTML templates, individual elements contained

within them are also styled to be responsive. Fonts, images, buttons, text fields, and

statistical attendance graphics also accustomise to changes in device size - they are all

written using percentage and em values for size which are directly proportionate to the

point measurement set relative to the the DPI (dots per inch) of a display.

Figure 11: Interface map of the mobile website.

Reg: 100089332 39

CMP-6012Y

5.4.3 JavaScript

JavaScript (JS) was used within the web interface to optimise user experience and

ensure mobile responsiveness. I took an approach of implementing a mixture of

both external open-source JavaScript plugins, and the development of in-house

bespoke functionality; this was done to ensure quality of code and reduce the

amount of clutter on pages. For the purposes of code conformity, and the ability to

benefit from the additional functionality it provides, a JQuery library was also imported.

The main purpose of implementing JavaScript was the added usability; such as live

field validation, user prompts, and the ability for dynamic manipulation of user

interface elements. Examples of this include the username verifier on the login page,

the implementation of content tabs, and the calendar display. All of these give users

guidance for how the system should be used and options regarding the way they access

data.

Figure 12: List view vs calendar view.

Another reson for JS implementation was the ability to improve the dynamic response

of styling for mobile viewing. Krug (2014), states that users; especially those browsing

on portable devices; generally prefer simple interfaces where possible, and that

switching between webpages for information is laborious and time consuming, so

should be avoided. JavaScript functionality was implemented so that space available

on webpages could be maximised through the manipulation the display of data on

Reg: 100089332 40

CMP-6012Y

pages, to fit more data on a page without overloading displays. Although this worked

well, balance had to be made as to what data should be clustered together on the same

page, as there needed to be a compromise between page navigation steps and load times.

Figure 13: Three seperate content displays on one page using JS tabs.

Implementation of both internal and external features was simple and worked well with

the PHP framework and HTML templates. They also both displayed well on mobile

devices, and could be customised to fit in with the rest of the system design. Through-

out the implementation of JavaScript I periodically checked the QuirksMode.org mobile

compatibility table; that shows which JavaScript functions are supported on mobile de-

vices. The code snippets also underwent testing on android and iOS systems on a variety

of browsers to ensure full error-free functionality.

5.4.4 User Interaction

Communication is a two way process, so when an issue occurs within a system, it is

important for users to understand what has happened, how they can resolve it, and how

they can modify their behaviour during future interactions to avoid the same problems.

These are small and easily implemented features, that have a huge impact on the overall

usability of the system, but are often overlooked.

Within the Desktop system, when a member of staff save a completed register, a pop-up

is shown asking them to verify this choice, in order to prevent unwanted overwrites.

Reg: 100089332 41

CMP-6012Y

Students who scan their cards and are not on the register are added to a separate file, and

a message is displayed explaining this. Also textboxes and visual aids are implemented

to provide instructions to assist with usability.

Figure 14: Examples of system interaction with users.

6 Testing

Testing is a critical element of the software development life cycle, it allows developers

to understand if there are any errors, both functional and non-functional. “An effec-

tive and efficient testing will provide timely visibility into the quality and readiness of

the system and its input artifacts that is necessary to enable effective decision making

throughout the SDLC“. (Khan and Khan, 2017).

There are four key reasons why testing is performed:

• Identifying and correcting bugs.

• Quality assurance.

• Prevent defects.

• Ensure that business and system requirements are met.

The following section will discuss key strategies and techniques used for software test-

ing, outlining the benefits and drawbacks of each. Justifications will then be given for

the reasoning behind which testing methods have been chosen for this project.

Reg: 100089332 42

CMP-6012Y

6.1 Objective

The key objective of the testing of this system is to ensure there are minimal errors

in both the online web application and the desktop application, to test their ability to

integrate and communicate with one another, and finally to ensure that the system has

improved usability compared with the current system.

6.2 Testing Levels

There are four levels of testing; unit, integration, systems and objectives, which vary

from low-level functional testing of software code to high-level testing of abstract

organisational principles (Bourque and Fairley, 2014). For the testing of this system

I have identified three suitable types of testing that should be pursued; conformance

testing, fuzzing, and integration testing. Considering that the system is structured

into two subsystems, and that one of the focal points of this development strategy is

improving user experience; these were chosen due to their applicability and pertinence

to the scenario.

Conformance Testing - ensuring that a system is built to meet standardised practice

guidelines set out by expert bodies or experts.

Fuzzing - the act of inputting unexpected data into input-fields to gauge how the soft-

ware copes. Examples include integers into text-boxes and vice-versa, using negative

numbers and placing text in date fields etc.

Integration Testing - a functionality test that is performed to evaluate how elements

of the system interact, it follows and end-to-end activity to check if all the modules of

within system integrate correctly.

6.3 Plan

Having highlighted some suitable techniques that would be appropriate for the testing

of the code-base and overall system usability. It was important to properly plan the

testing process.

Reg: 100089332 43

CMP-6012Y

For the testing of the front-end of the web application, HTML and CSS was run through

a W3C validation tool, to ensure its readability within differing browsers, and Javascript

functionality was tested on FireFox, Chrome, IE, and Safari browsers to ensure it was

supported (conformance). In terms of the back-end testing, PHP is a notoriously difficult

language to test effectively, mainly as a result of it server-side nature, and especially

when considering that I built a bespoke back-end instead of an opensource framework

such as Symfony and Wordpress. Therefore I manually tested the code base, using a

black-box approach, with the use of fuzzing to ensure correct error handling. With

respects to the desktop application, due to the nature of its architecture, JUnit testing

was difficult to achieve, therefore as with the PHP codebase, manual fuzzing was used

to assess error handling. After each subsystem had been sufficiently tested; a final

integration test was performed in order to ensure that inputs and outputs aligned and

integration of the two systems worked without bugs.

6.4 Test Cases

When testing a system it is important to use a data set which accurately represents

the data that will be used on the live version. To achieve this, I built a small program

in Java that generates comma-separated variables with fictional data, so it could be

easily uploaded to the database I was using to store the information. When generating

this data, the first consideration made was regarding the scope of testing - I wanted

to ensure that I could properly understand the functional performance of the system,

but I also didn’t want to flood it with too much data and cause failure from the

outset. After speaking to a member of lecturing staff involved with attendance at the

university, I decided to most appropriate action was to base test cases on a preliminary

implementation of the system within the school of Computer Science.

Number of Students Number of Lecturers350 50

Number of Lectures Number of Modules360 30

When creating test data, I started by analysing the tables within the data base; it quickly

Reg: 100089332 44

CMP-6012Y

became apparent that the easiest way to start approaching this matter was the generation

of user data, which I split this function into two classes (students and staff) - due to the

similarities (unique ids, emails, generation of names) most of the methods within these

classes could be reused. Amendments were made to account for difference and the

data was generated (to match the amounts stated in the list above). After user data was

generated, modules and lectures were then created, setting auto-incremented values to

’NULL’ for ensured referential integrity. The final step was the most time-consuming,

which involved the generation of the relational tables. I used Microsoft Excel in order to

map the data together and link the tables within the database. Once this was completed,

I then had a set of test data which represented the data that would be used in the live

version, and testing could commence.

6.5 Conformance Testing

6.5.1 Web Application Validation

HyperText Markup Language (HTML) and Cascading Style Sheets (CSS) are two of

the cornerstones of web applications. Development standards for web-design are set

out by the World Wide Web Consortium, who offer tools to check the validity of code

in order to ensure that code is written in accordance with best practice guidelines. I

used these tools as a form of conformance testing, in order to check for issues with

code and correct them appropriately.

With the HTML, there were serious issues flagged during the first bout of testing, with

thirty-seven warnings and twenty-seven errors, the HTML template needed adjusting.

After making a few amendments to the HTML templates, I ran another set of validation

tests which yielded considerably more favourable results. Although the warning

count only fell by two and the number of errors fell to zero. After running this set

of tests, I was curious as to what might be the cause of these errors so I investigated

potential sources. After performing some research online I quickly discovered that

these warnings were neither syntax issues nor readability problems, they were warnings

that there are multiple methods for displaying the same result and that alternatives

Reg: 100089332 45

CMP-6012Y

should be considered.

My web application has three CSS files, one for the overall styling of the general system,

a second particularly relevant to the mobile menu styling, and a third which is concerned

with the styling of the datepicker on the ‘modules’ page. Again, as with the HTML

testing, the first test for each document produced significant errors; however, these were

very simple to correct and after a short time editing and retesting code, the CSS passed

validation and I could move on to unit testing.

6.6 Unit Testing

I segmented the system into its two sub-systems for the purposes of testing; the PHP

web application was tested first to ensure

6.6.1 PHP Testing

Without the implementation of particular frameworks, PHP is a difficult language to

perform tests on, however, during the development stages constant ad-hoc testing was

performed on every new piece of functionality that was added. The main form of

testing was the input of invalid data types to assess how the system responded to user

errors. Interactions with the database were carefully mediated, with the use of the

MySQLi driver allowing interactions and subsequent errors to be managed.

Figure 15: PHP code nullifies any unexpected database outputs.

Reg: 100089332 46

CMP-6012Y

6.6.2 Java Testing

The Java application, due to its architecture, proved difficult to perform tests on,

however unit testing was attempted. Register files come in a predefined format when

they are downloaded from the website, when these files are inputted into the Java

application for registration, a check is done to ensure they arrive in the correct format.

If the system finds issues, progression to the next step is refused until an appropriate

file is chosen. This functionality was tested by attempting to upload non-compatible

files; which were all rejected.

The function which inserts barcodes was also tested; inserted values were, through it-

eration, compared against a list of expected students, with any matches being removed.

Any inputs that were not recognised were exported as a separate file. This allows for

error handling, and also the recording of both unexpected students and incompatible

data-types.

6.7 Integration Testing

It is critical that the final system can achieve its purpose from end-to-end, and that

errors are handled consistently throughout the system. Therefore once each individual

element of the system had been tested, it was important to ensure they fully integrated

without error. The following series of images follows the entire registration process

and demonstrates the full integration, following these steps: opening of registration

page for selected lecture, selection of download option, download of registration file,

uploading of file to desktop application, selection of "student view" display, scanning

of barcode number, saving of list, upload of register to web-application and the saving

of the register to the database.

Reg: 100089332 47

CMP-6012Y

Figure 16: Marking of attendance - from end to end.

Reg: 100089332 48

CMP-6012Y

7 Evaluation

7.1 Fulfilment of Requirements

Achieved FR01, FR02, FR03, FR04, FR05, FR06, NR01,

NR02, NR04, NR05, NR06

Challenged NR03 (dependent on internet speed and query

size)

Unsuccessful FR07

Of the functional requirements, six out of seven were achieved, with all the "must" re-

quirements being satisfied; however NR07 (being able to export data) was not managed.

From the non-functional requirements, six of the seven were met fully, with one being

challenged, dependent on the environmental factors. Therefore from the fourteen re-

quirements that were set out as achievable, twelve were fully met, one was challenged,

and one was unsuccessful.

7.2 System Issues

One of the key issues of this prototyped version is the necessity for a device to

be running during the attendance process, however the implementation of dedi-

cated sign-in terminals could provide a solution to this. These could be placed

securely at the back of lecture theatres - registration files could then be uploaded to the

terminal prior to the lecture, then afterwards, either exported or uploaded to the website.

Another issue is the inability for identification authentication at lectures. This problem

was reported in many articles regarding automated attendance, and the only foolproof

way to implement complete control is biometric identification, which leads to additional

security implications and expensive hardware procurements. This system requires the

possession of a campus card, as this provides access to many facilities at UEA people

are generally adverse to sacrificing it, which will lower the number of incidents of

proxy signings.

Reg: 100089332 49

CMP-6012Y

A final issue is the management of data administration, such as the production of at-

tendance reports; and the updating of records, such as authorising absences. These are

issues that are easily resolved, but I ran out of time to implement effectively solutions.

7.3 Future Developments

As this project has achieved its core aim of improving the user experience of attendance

monitoring for both staff and students, it can be considered to have been a success;

however, there are still areas for greater research and improvement - this final section

will briefly discuss these areas.

One area where this system could could be to enable the upload of a completed

register from a smartphone or tablet. Although currently it is possible for lecturers

to easily update attendance manually on a smart device, it is not yet possible for

a whole registration file to be uploaded, as the file format of is only supported

by desktop and laptop computers. Through the development of a smartphone appli-

cation with direct communication with the database, this could be achieved in the future.

As this system is capable of flagging-up students with low attendance, and also

provides the ability to view a breakdown of these records for particular modules, the

requirements of both the university and government authorities are satisfied. However,

when approaching further developments, the implementation of a function to export

attendance statistics for manipulation by external bodies is recommended.

A final recommendation for the improvement of this system would be for the manage-

ment of administration to be hosted within the university’s hubs. Currently there is a

separate standalone systems that integrates with the main registration web-system; this

allows for the insertion of reasoning for authorised absences. However, it may be bene-

ficial for other administrative functions (like changing lecture times) to be manipulated

by hub staff too.

Reg: 100089332 50

CMP-6012Y

8 Conclusion

8.1 System Outcomes

The development of this project has not been a straight-forward process, there have

been many obstacles to overcome, and scope creep became an issue during the

development process, as addition functionality became necessary; and as a result the

RAD approach (discussed in the literature review), with iterative prototyping, was taken.

The final outcome has been the prototyping of a system that can record, store, manage,

and display attendance data of students; with the implementation of automated process

for the quickening of administrative functions. The core system is comprised of two

subsystems (a website and a native desktop application) which integrate without errors

to provide a user-friendly experience to teaching staff using them.

8.2 Personal Development

Over the course of this project, I have gained first-hand experience of the development

of a functional system using a model-view-controller architecture adhering to an agile

approach. I have also significantly improved my programming abilities; with the con-

struction of a Java desktop application capable of reading and adjusting register data, a

visually impressive website with a framework constructed to W3C web standards that

is also mobile optimised, and a server-side web application that can dynamically pro-

duce attendance statistics. In addition to these practical learnings, I have also gained a

theoretical insight into how contactless technologies work and their capabilities.

Reg: 100089332 51

CMP-6012Y

References

Beck, K., Beedle, M., Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M.,

Grenning, J., Highsmith, J.and Hunt, A., Jeffries, R., Kern, J., Marick, B., Martin, R.,

Mellor, S., Schwaber, K., Sutherland, J., and Thomas, D. (2001). Manifesto for agile

software development. http:// www.agilemanifesto.org/ . [Accessed 29 Apr. 2015].

Benyó, B., Sódor, B., Doktor, T., and Fördos, G. (2012). Student attendance monitoring

at the university using nfc. Department of Control Engineering and Information

Technology, Budapest University of Technology and Economics. Budapest, Hungary.

Biometricsociety.org (2010). The international biometric society Âz definition of bio-

metrics. http:// www.biometricsociety.org/ about/ definition-of-biometrics/ . [Accessed

21 May 2017].

Boehm, B. (1988). A spiral model of software development and enhancement. Com-

puter, 21(5):61–72.

Bourque, P. and Fairley, R. (2014). Guide to the Software Engineering Body of Knowl-

edge. IEEE, 1 edition.

Chawla, V. and Ha, D. (2007). An overview of passive rfid. IEEE Applications and

Practice, pages 11–17.

ComScore (2015). Number of mobile-only internet users now exceeds desktop-only in

the u.s. https:// www.comscore.com/ Insights/ Blog/ Number-of-Mobile-Only-Internet-

Users-Now-Exceeds-Desktop-Only-in-the-U.S. [Accessed 21 May 2017].

Department of Health and Human Services (2005). Selecting a develop-

ment approach. https:// www.cms.gov/ Research-Statistics-Data-and-Systems/ CMS-

Information-Technology/ XLC/ Downloads/ SelectingDevelopmentApproach.pdf . [Ac-

cessed 21 May 2017].

East Sussex County Council (2017). Legal requirements for using biometric

technologies. https:// czone.eastsussex.gov.uk/ schoolmanagement/ schoolpolicies/

Reg: 100089332 52

CMP-6012Y

dataprotection/ biometricdata/ Pages/ legalrequirements.aspx . [Accessed 21 May

2017].

Gerchev, I. (2014). Front-end frameworks: Custom vs. ready-to-use solutions

- sitepoint. https:// www.sitepoint.com/ front-end-frameworks-custom-vs-ready-use-

solutions/ . [Accessed 21 May 2017].

Geven, A., Strassl, P., Ferro, B., Tscheligi, M., and Schwab, H. (2007). Experiencing

real- world interaction: results from a nfc user experience field trial. In Proceedings of

the 9th international conference on Human computer interaction with mobile devices

and services, pages 234–237. New York, NY, USA. ACM.

Hadjigeorgiou, C. (2013). Rdbms vs nosql: Performance and scaling comparison. Un-

published Master’s thesis. University of Edinburgh, Edinburgh, U.K.

Highsmith, J. and Cockburn, A. (2001). Agile software development: The business of

innovation. Computer, 34(9):120–127.

Investopedia (2017). Barcode. http:// www.investopedia.com/ terms/ b/ barcode.asp.

[Accessed 21 May 2017].

Jones, S. (2014). Access granted: On the security of near-field enabled keycards. Un-

published Master’s thesis. University of East Anglia, Norwich, U.K.

Kassem, A., Hamad, M., Chalhoub, Z., and El Dahdaah, S. . (2010). An id attendance

and monitoring system for university applications. 17th IEEE International Confer-

ence on Electronics, Circuits, and Systems, pages 851–854.

Khan, M. E. and Khan, F. (2017). Importance of software testing in software develop-

ment life cycle. IJCSI International Journal of Computer Science Issues.

Krug, S. (2014). Don’t make me think! Revisited. New Riders, Berkley.

Landt, J. (2005). The history of rfid. IEEE Potentials, 24(4):8–11.

Masalha, F.and Hirzallah, N. (2014). A students attendance system using qr code. In-

ternational Journal of Advanced Computer Science and Applications, 5(3).

Reg: 100089332 53

CMP-6012Y

Mobile-QR-Codes.org (2017). What are qr codes? http:// www.mobile-qr-codes.org/ qr-

codes.html . [Accessed 21 May 2017].

Moksin, M. and Yasin, N. (2009). The implementation of wireless student attendance

system in an examination procedure. pages 174–177.

Ofcom.com (2017). Fast facts. https:// www.ofcom.org.uk/ about-ofcom/ latest/ media/

facts. Accessed 4 May 2017.

Palmer, M. (2009). Making the Most of RFID in Libraries. Facet Publishing, London,

1 edition.

Rao, S. and Satoa, K. (2013). An attendance monitoring system using biometrics au-

thentication. International Journal of Advanced Research in Computer Science and

Software Engineering, 3(4):379–383.

Rouillard, J. (2008). Contextual qr codes. Proceedings of the Third International Multi-

Conference on Computing in Global Information Technology. Athens, Greece.

Shin, B., Lee, K., Choi, S., Kim, J., Lee, W., and Kim, H. (2010). Indoor wifi positioning

system for android-based smartphone. Information and Communication Technology

Convergence (ICTC), pages 319–320.

Shoewu, O. and Idowu, O. (2012). Development of attendance management system

using biometrics. The Pacific Journal of Science and Technology, 13(1):300–307.

Sudha, K., Shinde, S., Thomas, T., and Abdugani, A. (2015). Barcode based student

attendance system. International Journal of Computer Applications, 119(2):1–4.

Technopedia (2017). What is three layer architecture? https:// www.technopedia.com/

definition/ 24649. [Accessed 21 May 2017].

UEA (2017). Disciplinary policy and procedures relating to attendance, engagement

and progress. https:// portal.uea.ac.uk/ documents/ 6207125/ 8576642/ disciplinary-

policy-and-procedures-attendance-engagement-and-progress.pdf . [Accessed 21

May 2017].

Reg: 100089332 54

CMP-6012Y

ukcisa.org.uk (2017). Ukcisa - international student advice and guidance - protect-

ing your tier 4 status. https:// www.ukcisa.org.uk/ Information--Advice/ Visas-and-

Immigration/ Protecting-your-Tier-4-status. [Accessed 21 May 2017].

Weightman, G. (2017). The history of the bar code. http:// www.smithsonianmag.com/

innovation/ history-bar-code-180956704/ . Accessed 21 May 2017.

whatisaqrcode.co.uk (2017). What is a qr code? http:// www.whatisaqrcode.co.uk/ .

[Accessed 21 May 2017].

Reg: 100089332 55