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