Download Chapter 1: Introduction - VLE

Module Support Management
System
David Goodwin
BSc Computing
2004/2005
The candidate confirms that the work submitted is their own and the appropriate credit has
been given where reference has been made to the work of others.
I understand that failure to attribute material which is obtained from another source may be
considered as plagiarism.
(Signature of student) _______________________________
Summary
In Leeds University’s School of Computing postgraduates are employed to assist module leaders with
their work load. The process involves allocating postgraduates to module work based on the skills they
possess. The current method of doing this is entirely paper based and is not very efficient. The
project’s purpose was to produce an electronic version of the system allowing data entry via webbased forms.
The project required gathering the user requirements, analysing them and producing a design for a
prototype system. The prototype was then implemented and tested. This report is a detailed description
of all the work done on the project and the methods used.
The project was a success in that the aim, objective and minimum requirements were met. The
prototype was able to meet the minimum requirements but would require further work to meet all the
user requirements identified.
I
Acknowledgments
This section is dedicated to all the people that have helped me in their own special way throughout the
project.
The first acknowledgment goes out to Stuart Roberts my supervisor. Without his continuous support,
advice and general guidance this project would not even exist. Thank you to Charlie Brown for his
time, patience and detailed descriptions of the current system. Also thank you to Natasha Shakhlevich
for her advice in the progress meeting which I have put to good use.
Finally, to my parents who put up with my constant complaining over the Easter holidays a big thank
you for being there for me.
II
CHAPTER 1: INTRODUCTION ........................................................................................................................ 1
1.1 THE PROBLEM .............................................................................................................................................. 1
1.2 AIM ............................................................................................................................................................... 2
1.3 OBJECTIVES ................................................................................................................................................. 2
1.4 MINIMUM REQUIREMENTS .......................................................................................................................... 2
1.5 DELIVERABLES ............................................................................................................................................ 3
1.6 PROJECT SCHEDULE .................................................................................................................................... 3
CHAPTER 2 – BACKGROUND READING ..................................................................................................... 4
2.1 BACKGROUND TO THE PROBLEM ................................................................................................................. 4
2.2 METHODOLOGY RESEARCH ......................................................................................................................... 5
2.3 THE WATERFALL MODEL ............................................................................................................................. 5
2.4 PROTOTYPING .............................................................................................................................................. 6
2.5 THE SPIRAL MODEL ..................................................................................................................................... 7
2.6 METHODOLOGY SELECTION ........................................................................................................................ 8
2.7 TECHNOLOGIES ............................................................................................................................................ 9
CHAPTER 3: ANALYSIS.................................................................................................................................. 11
3.1 ANALYSIS OF CURRENT PROCEDURE ......................................................................................................... 11
3.2 REQUIREMENTS.......................................................................................................................................... 12
3.3 ANALYSING USING SOFT SYSTEMS METHODOLOGY ................................................................................ 13
3.3.1 Rich picture......................................................................................................................................... 13
3.3.2 Root definition .................................................................................................................................... 15
3.3.3 CATWOE analysis.............................................................................................................................. 15
3.4 USE CASE DIAGRAM.................................................................................................................................... 16
CHAPTER 4: DESIGN ...................................................................................................................................... 19
4.1 DATABASE DESIGN ..................................................................................................................................... 19
4.1.1 Entity-Relationship modelling ........................................................................................................... 19
4.1.2 Normalisation ..................................................................................................................................... 21
4.2 INTERFACE DESIGN .................................................................................................................................... 26
4.2.1 Usability .............................................................................................................................................. 27
4.2.2 Colour ................................................................................................................................................. 27
4.2.3 Form designs ...................................................................................................................................... 28
CHAPTER 5: IMPLEMENTATION................................................................................................................ 31
5.1 CONNECTING TO THE DATABASE ............................................................................................................... 31
5.2 MODIFYING THE DATABASE ....................................................................................................................... 31
5.3 WRITING THE CGI SCRIPTS ....................................................................................................................... 32
5.3 THE ALLOCATION REPORT......................................................................................................................... 33
III
5.4 PROBLEMS ENCOUNTERED ........................................................................................................................ 35
5.5 SOURCE OF FORMS ..................................................................................................................................... 36
CHAPTER 6: TESTING .................................................................................................................................... 37
6.1 WHAT IS TESTING?..................................................................................................................................... 37
6.2 TYPES OF TESTING ..................................................................................................................................... 37
6.3 TESTING THE CODE .................................................................................................................................... 37
6.4 TESTING THE SYSTEM ................................................................................................................................ 37
6.5 TESTING THE FUNCTIONS ........................................................................................................................... 38
6.6 MEETING THE USER REQUIREMENTS ........................................................................................................ 39
6.7 USER WALKTHROUGH ................................................................................................................................ 39
6.7 .1 Skills form.......................................................................................................................................... 39
6.7 .2 Modules form..................................................................................................................................... 40
6.7 .3 Postgraduates form............................................................................................................................ 40
6.7.4 Report form......................................................................................................................................... 40
CHAPTER 7: EVALUATION........................................................................................................................... 41
7.1 EVALUATION CRITERIA.............................................................................................................................. 41
7.2 IS THE SYSTEM PRAGMATIC?..................................................................................................................... 42
7.3 IS THE SYSTEM USEABLE? .......................................................................................................................... 42
7.4 IS THE SYSTEM RELIABLE? ........................................................................................................................ 42
7.5 IS THE SYSTEM METAMORPHIC?................................................................................................................ 42
7.6 METHODOLOGY USE .................................................................................................................................. 43
7.7 TIME MANAGEMENT .................................................................................................................................. 43
7.8 COMPARISON WITH EXISTING SOLUTIONS ................................................................................................ 43
CHAPTER 8: THE FUTURE ............................................................................................................................ 45
8.1 FUTURE EXPANSION ................................................................................................................................... 45
8.2 FUTURE IMPROVEMENTS ........................................................................................................................... 45
REFERENCES: .................................................................................................................................................. 46
APPENDICES ..................................................................................................................................................... 48
APPENDIX A -REFLECTION ................................................................................................................................ 48
APPENDIX B – ORIGINAL TIME SCHEDULE ......................................................................................................... 50
APPENDIX C –ACTUAL TIME SCHEDULE ............................................................................................................. 51
APPENDIX D – POSTGRADUATE REQUEST FORM ................................................................................................ 52
APPENDIX E – WORK ALLOCATION FORM .......................................................................................................... 53
APPENDIX F – PAYMENT CLAIM FORM ............................................................................................................... 54
APPENDIX G – SCREENSHOTS ............................................................................................................................ 55
IV
Chapter 1: Introduction
1.1 The problem
Leeds University’s School of Computing offers a wide variety of modules for all the different degrees
it caters. The module leaders often require additional assistance to cope with their large workload of
running these modules at degree level. Assistance is acquired through employment of postgraduate
students who have accomplished academic skills covering those required of the modules.
Students that are undertaking modules are often given the opportunity to attend laboratory sessions
where they are able to seek advice and receive help with their current coursework. Demonstrations
may also be given by these employed postgraduates who run the sessions. Another task for which they
are employed is that of marking. The amount of marking for just one module is quite considerable
with possibly over a hundred attending students, each submitting more than one piece of coursework.
In order to give the student the best possible feedback the coursework must be marked quickly and
accurately.
It is essential that the right postgraduate is matched to their task. A postgraduate who does not possess
the required skills will be inadequate at performing their job. Problems may also occur if a
postgraduate dislikes a certain programming language and is then allocated to hold a lab session for a
piece of coursework based on that language. When applying for employment the postgraduates are
encouraged to specify their likes and dislikes as well as their experiences and preferences.
There is also a limit to the number of hours one postgraduate can work for. The module tasks are all
defined in timescale by hours. Coursework marking has a recommended number of hours for
completion whereas demonstrating will have a specified number of hours required. More than one
postgraduate can work on a particular task for a module and modules can have more than one task.
The current system utilises a mixture of paper-based resources and manually updated databases.
Transferring information from paper to electronic form is time consuming and doesn’t make full use
of technology presently available. Although the system does work it is not very efficient being a slow
and messy procedure. Paper records are easily lost and are difficult to keep organised. Problems also
occur with the collection of paper-based information within deadlines. This leads to essential
information being omitted and not recorded.
1
Completely automating the process electronically will hopefully improve efficiency, by speeding up
and improving the process organisation for entry and retrieval of data. Keeping to deadlines should be
easier using electronic submission instead of pieces of paper. Data will not be lost as easily. It can be
stored within a database in an orderly fashion. Transferring of data can all be done electronically and
keep redundancy of data to a minimum.
1.2 Aim
A definition of the project’s aim is:
“To produce a system that allows the entry of module support requirements and postgraduate
availability via a web based interface. The storage of the data in a database for later manipulation. All
done using the existing SIS system.”
1.3 Objectives
The objectives of this project include:
•
To understand the problem
•
To research into the current procedure and analyse
•
To interview the main users of the system and gather requirements
•
To decide on an appropriate methodology to use
•
To design and implement the database
•
To design and implement web based data entry forms
•
To design and implement data reports
•
To test the system
•
To evaluate the system
1.4 Minimum requirements
The project’s minimum requirements are:
•
Produce a summary of the existing processes for capturing module support data and the
efficiency of these processes.
•
Gather and analyse requirements and produce a specification of a new system.
•
To design and build a relational database that will store information on modules,
postgraduates and their periods of availability.
2
•
Design and implement web-based data entry forms.
•
Design and implement at least one report.
Possible project extensions include:
•
Automatic scheduling algorithm
•
Design and implement reports detailing allocations, hours worked and amount spent.
•
Provide evidence to the university payroll system of the benefits of using electronic forms
when dealing with the School of Computing.
1.5 Deliverables
•
The final project report
•
Prototype system
1.6 Project Schedule
Due to the importance and size of this project the management of the limited time available had to be
carefully handled. Different sections required varying amounts of time to be spent on them. The
workload was balanced so that the majority of it took part in the second semester. The original Gantt
chart, see Appendix B, was altered repeatedly due to unrealistic time scheduling, evaluation of how
the project was managed and why the time scheduling changed can be found later in the report.
3
Chapter 2 – Background reading
2.1 Background to the problem
Before a system could be built to solve the problem, background research had to be conducted. To
fully understand the problem it was decided that meetings should be held with the people most
associated with the current procedure. The purpose of the meetings was to gather as much information
as possible about the current procedure and any problems that have arisen from using it. From the
information gathered user requirements for a new system could be created. These would be used as the
starting blocks for the system design.
A meeting has the advantage of being bidirectional. New questions that arise can be put forward from
both sides and answered immediately without the delay normally associated with methods such as email. A meeting is also more intimate and can be both formal and informal depending on the situation.
It was very important to plan and structure the meeting in order to get the best possible result. They
were treated as informal interviews with a set of questions prepared beforehand.
The Allocation Officer is the person directly responsible for the allocation of postgraduates to module
support. He holds the major role for the current procedure and without him there would be no
procedure. He also understands, in intricate detail, the processes that occur in the procedure. All of this
qualifies him as an ideal source for information gathering.
Documentation of the results of the meeting included a detailed description of the current procedure.
From this an analysis of the procedure was produced which currently resides in section 3.1 of this
report. The analysis highlighted the problems with the system. These problems included the fact that
the procedure is currently a mixture of paper-based resources and manually updated databases. The
movement of data between the two mediums causes both time and efficiency problems which becomes
a serious concern when strict deadlines have to be met. To combat the problem it has been concluded
that a completely electronically based system would be beneficial in numerous ways. The proposed
solution should hopefully simplify and increase the efficiency of the Allocation officer’s current job.
The findings of the meeting deduced that the proposed system would have to be compatible with and
implemented using current SIS data. SIS stands for the School Information System, a large relational
database of administrative information in the School of Computing. Information it holds ranges from
the details of the people within the school to performance statistics, Ainsworth (2004). Research into
the technology of SIS was therefore essential.
4
A source for such information could have included any member of the SIS team, a group of people
working with and having knowledge of the workings of SIS. The meeting, once conducted, produced
documentation of a list of tables currently used in SIS. The list was useful as it could be used to
produce a rough idea of the tables required to produce the proposed system. The main tables
concerning the project included details about postgraduates and modules. Other information gathered
from the meeting included that the database management system Postgres was used for SIS and the
language perl was used to access the database. This proved to be useful when the decision needed to
be made of the technology to use for the proposed system.
2.2 Methodology research
Choosing the correct methodology to create the system is very important. The methodology will
decide how to represent the system and ultimately go about designing it. If the wrong methodology is
used then problems with the design and implementation may occur.
Matravers (2003) states that although there are situations where an information system solution to a
problem is obvious, this is not always the case. Matravers (2003) goes on to explain that sometimes
the problem situation needs to be explored further to give a better understanding of the process. One
way of doing this is using Soft Systems Methodology (SSM). Unlike a hard approach which
concentrates on the technical side, SSM explores the social processes. Eva (2004) reveals that SSM
does not represent strict steps that have to be followed but instead a loose framework of techniques.
“It is based on systems thinking, which enables it to be highly defined and described, but is flexible in
use and broad in scope,” Checkland & Scholes (1990). Once the problem has been clearly defined a
hard approach can then be used to find a solution.
The analysis of the meetings findings has explored the problem in greater depth. It has revealed its
increased complexity and scope resulting in new factors having to be taken into account, making SSM
more relevant. To complement the findings of the SSM analysis techniques a hard system
methodology was required. Research into the different types was undertaken to find the best one for
the proposed system.
2.3 The waterfall model
According to Beauchemin (2000) the waterfall model was the first model in systems development to
have a structure. It is linear, with the stages following a sequential order. Supremisitc (2005) explains
the origin of the name. In a waterfall the water has no choice but to fall once it has gone over the edge.
5
It’s the same with each stage, once one is complete its time to go on to the next. Progress only flows in
one direction so there is no going back.
Although sources differ with their choice of names for each stage, the basic structure includes
analysis, design, implementation, testing and evaluation as shown in figure 1. The arrows represent the
flow of progress.
Analysis
Design
Implementation
Testing
Evaluation
Figure 1, Waterfall model
Supremisitc (2005) states that one advantage of the waterfall model is its strictness, this allows a
schedule with deadlines to be set. These deadlines must be met allowing a timescale of the project to
be given. However, like every methodology the waterfall model also has its disadvantages “The
disadvantage of waterfall development is that it does not allow for much reflection or revision”,
Supremisitc (2005). This means that if something occurs that affects a stage that has already been
completed it is not possible to go back and modify that stage. Therefore it is important that the stages
are well thought out before the process starts.
2.4 Prototyping
If requirements for the system are not fully understood when starting the project then Beauchemin
(2000) advises using a prototyping model. This involves creating a prototype for the system, letting
the users try it and then collect the feedback. This feedback could then be used to build an improved
prototype. The process continues until the requirements are fully understood and the system can then
be implemented. Figure 2 shows the different stages and how they relate according to Beauchemin
(2000). Unlike the waterfall model progress does not just travel in one direction as stages can be
revisited. Beauchemin (2000) warns that developing the system too quickly can lead to bad choices
and design. Customers can also be mislead by the prototype and assume the system will be produced
sooner than it actually will.
6
Collect
requirements
Design prototype
Create/Modify
prototype
Assessment of
prototype by users
Implementation of
system
Figure 2, Model representation of prototyping
2.5 The Spiral model
“The spiral model is a combination of the best features of both the waterfall model and prototyping”,
Beauchemin (2000). Beauchemin (2000) expands further by explaining that the spiral model uses the
method of repeatedly modifying the system until it reaches the clients expectations. However, each
iteration makes use of the waterfall methodology. Risk assessment is a new feature that has been
included which assesses the risk and decides whether it is wise to continue. Figure 3 taken from
Boehm (1998) shows the spiral model in detail.
According to Beauchemin (2000) the spiral model consists of four stages:
•
Objectives of the project – where objectives are determined and different approaches are
considered.
•
Risk assessment – using the risk assessment the different approaches are evaluated. If
continuing is worth the risk an approach to use is identified.
•
Engineering – the prototype is implemented
•
Planning and management – the user tests the prototype and provides feedback
7
The problem identified by Beauchemin (2000) is that due to the large number of steps the model
consists of any delays become a serious issue.
Figure 3, The spiral model
2.6 Methodology selection
Evaluating each methodology in turn gives a clearer understanding of which is the most suitable. It has
already been made clear that soft systems methodology techniques will be used to analyse the process
to give a clearer view of the problem situation. However after the process has been fully analysed the
results will be used to proceed with a hard methodology.
The waterfall method is an attractive methodology if the requirements have been collected early on in
the project, however it does not allow much room for error. If the implemented system is not to the
standard the users would like it there is no room for improvement. The prototype method allows for
repeated improvement of the system however it is time consuming and requires the design of the
system to be created fairly quickly in the project. The spiral method is very time consuming and
complex so is therefore not suitable for a project of this size.
8
As tine is of the up most importance for this project it makes sense to use the waterfall model. It will
allow time for one iteration. The SSM will ensure that the analysis for the system is fully completed
before the methodology continues hopefully reducing the chance of the system not reaching the users’
standards.
2.7 Technologies
There are various methods of storing the required data. The documentation of the meeting with the
allocation officer determines that the current solution uses a manually updated database to store the
existing postgraduates. It reveals to be practical to use a database to store all details about both module
requirements and postgraduates. Research shows that a database management system (DBMS) is
required and that the three main contenders in the field are Oracle, PostgreSQL and MySQL.
“The DBMS is hence a general-purpose software system that facilities the processes of defining,
constructing and manipulating databases for various applications”, Elmasri & Navathe (2000).
MySQL (2005) compares the features of the different DBMSs and shows their different capabilities.
Features that are important to this project include being able to store a variety of different data types.
Other areas that are relevant to the project are integrity constraints, access, and licence cost. Figure 4 is
a table using the data from MySQL (2005) showing the features required for the system and if they are
supported by the different DBMSs. Boolean data type is an important data type as is date which will
be required for storing postgraduate availability. Access is important especially if in the future the
system is implemented with SIS. Finally and most importantly the DBMS should be free to use.
Features
MySQL
Oracle
PostgreSQL
Data type: Boolean
Yes
No
Yes
Data type: Date
Yes
Yes
Yes
Primary keys
Yes
Yes
Yes
Foreign keys
No
Yes
Yes
Set access privileges
No
Yes
Yes
Views
No
Yes
Yes
Licence cost
No
Yes
No
Figure 4, DBMS comparisons
Vita Voom (2004) also shows comparisons between the DBMSs. The source claims that MySQL is
slower and less efficient than PostgreSQL and that Oracle’s licence fees are very expensive. The
meeting with the SIS team member revealed that the SIS currently uses Postgres so any data provided
9
would be in the form of a Postgres database. Taking everything into account it proves to be practical to
use Postgres as the DBMS for the system.
Research into PostgreSQL is essential. PostgreSQL (2005) explains that PostgreSQL is based on
Postgres. It has all the same features as Postgres and more, yet still remains free. The query language
has changed from PostQUEL to SQL making it even more favourable towards anyone who has a brief
understanding of SQL. It would save them from having to learn a brand new query language.
In order to use SQL properly and efficiently, revision of the topic is required. Refsnes Data (2005)
gives a detailed tutorial on how to use SQL. Teorey (1990) discusses data modelling and design in
detail which is essential for making the project’s database as efficient as possible.
For the different users to enter their data into the database some sort of method is required. As all users
will have access to the Internet, it deems feasible for it to be web-based. A website on the method and
tools of web-based databases, Rittenhouse (2002), reveals the different ways to introduce web-based
data entry forms. Rittenhouse (2002) explains that for dynamic web pages a common gateway
interface (CGI) is required. The CGI script would have to be written in a programming language.
Documentation from the meetings with the SIS team reveals that SIS uses perl with embedded SQL.
As, according to Vita Voom (2004), PostgreSQL is compatible with many different languages such as
Python, Perl and C++ it becomes a matter of the advantages and disadvantages of each. Perl would
involve anyone who has previously programmed in both python and C++ before to learn a completely
new language. However along with the tables of their data, SIS may also provide examples of perl
scripting to connect a web page to SIS. The possibility that the project could be implemented with the
SIS system sometime in the future makes it feasible to use perl to script.
10
Chapter 3: Analysis
3.1 Analysis of current procedure
By the end of August the allocation officer has to have collected information about who is teaching
what and when. This involves the lecturer, the name of the module including the module code which
uniquely determines the module and the semester the module falls within. After the basic information
about the modules has been collected the allocation officer needs to know the support requirements in
detail. This involves the number of hours and postgraduates required. Date schedule for coursework
including the deadline date for the students and the date by which it has to be returned to them by. All
this information is currently collected by module leaders by either notifying the allocation officer by
word of mouth or in writing.
At the start of September the allocation officer starts collecting details about the postgraduates
available for employment. The allocation officer has a database of postgraduates that have been
employed in previous years. To find out about new postgraduates, paper based forms are provided that
must be completed and returned by a strict set deadline. See Appendix D for an example of the form
used in 2004. This form allows postgraduates to define their preferences for the type of work and their
particular skills including their expertise and enjoyment.
The next step involves allocating the postgraduates to the modules. A set number of hours are given to
a postgraduate to work for a module. A paper based form is given to both the postgraduate and module
leader to inform them of the allocation. See Appendix E for an example of the form used.
As the postgraduates will be employed by the University’s School of Computing registration within
the payroll system is required. This involves completing various forms such as registration documents,
student income tax forms and bank transfer forms. Postgraduates must also provide a photocopy of a
valid type of identification including passport or birth certificate. All of this must be returned to the
allocation officer before the end of October. Postgraduates must register each year despite possible
previous employment by the School.
Postgraduates are paid three times a year, at the end of each term. Before they are paid they must
prove they have completed the work allocated to them. This is done via a postgraduate claim for
payment paper based form. See Appendix F for an example of the form. The form which has a
submission deadline requires a signature of the module lecturer agreeing to the number of hours
claimed. The allocation officer then collects and sends the pay claims to the pay roll section.
11
At the end of the year, between the months of June and July, the allocation officer and the director of
learning and teaching analyse and summarise the whole procedure. This involves the total cost of
employment and the total number of hours worked by the postgraduates.
3.2 Requirements
Resulting from the meeting with the SIS team member it is known that the School of Computing holds
PostgreSQL databases on a variety of subjects including postgraduates and modules. Although no
electronic system currently exists for the procedure of employing postgraduates, the director of
learning and teaching had proposed to the allocation officer that one be built. A list of general and user
requirements were proposed. The requirements have since been modified, added to and agreed upon
with the different users of the system and are recorded below:
General requirements
1. The system to be based on SIS. All the allocation and hour details to be recorded on SIS. SIS
data on postgraduates and modules to be available for input to the system.
2. For security aspects only module leaders can update hours worked for their own modules.
Only postgraduates can enter their own details.
3. All viewing and modifying to be done over the School intranet.
User requirements
The following requirements are split into the different users of the system.
Module leaders
1. Be able to specify the details of the support they require for their module. This includes type
of work, number of hours, number of postgraduates and particular expertise.
2. For the coursework specify a schedule including the deadline date and date of return.
3. View the support allocated to their module.
4. Be able to update the hours worked by a postgraduate for their module. To be used as claim
for payment.
5. View the hours remaining of allocated work for their module.
Postgraduates
1. Be able to register their availability for work.
2. Be able to register their skills and their level of expertise and enjoyment..
3. View their allocation details.
4. View the hours remaining of their allocated work.
12
Allocation officer
1. Allocate postgraduates to requests of support. Including checking against availability and
checking hours allocated against hours requested.
2. Informing postgraduates and module leaders of completion of allocation and details of
allocation.
3. Ensure all tasks are completed by the deadlines set.
4. View all allocations
5. View total hours worked by all postgraduates.
6. View total amount spent to date.
Director of Learning and Teaching
1. View all allocations
2. View total hours worked by all postgraduates
3. View estimate of total amount committed
4. View total amount spent to date
3.3 Analysing using Soft Systems Methodology
Peter Checkland’s Soft Systems Methodology involves seven stages. The first few stages consist of
changing an unstructured problem to a structured problem. The way of doing this is by first, collecting
as much information as possible about the problem and then trying to understand it. The process can
only continue once the problem is fully understood. The problem is further analysed using a rich
picture which is a way of representing the problem situation in a graphical format, Kremer (2001).
“Rich pictures are used to provide a model for thinking about the system and to help the analyst to
gain an appreciation of the problem situation”, Couprie et al (2004).
There is no true structure to drawing a rich picture. They usually include people, also known as actors,
who are directly involved in the situation. The actor’s wants are normally drawn in thought bubbles
above them. The rich picture may also show any processes or transaction that take place between the
actors and any conflicts that may occur, Jarvis (2004).
3.3.1 Rich picture
Figure 5 shows the rich picture for the current situation of employing postgraduates and allocating
them to module support requests. The conflicts that occur can not all be resolved in the system to solve
the problem. This is mostly due to university payroll being outside of the aim of the project. The
payroll is a large and complex system that would require time and expertise that is not available. The
13
payroll system has been included as it is part of the extended problem but it will not be dealt with in
the project.
Conflict: Allocation Officer v Module Leaders
Conflict: University Payroll v
Conflict: DoLT v
An automatic allocation algorithm may speed up
Postgraduates
Postgraduates
and simplify the process for the Allocation
Postgraduates requiring a quick
The DoLT requires trained
Officer but it may not match the best PG for the
payment could conflict with the
Postgraduates for the jobs.
job required. This could result in poor quality
University Payroll system’s
Untrained Postgraduate would
work results for the Module Leaders.
current process.
then find themselves unable to
get work.
Figure 5, Rich picture of the current situation
14
3.3.2 Root definition
After clarifying the situation, the next stage is to design a system that can act as a solution to the
problem. A description of the system is required which is acquired using a root definition. The root
definition is a short paragraph, describing why the system is being built, what it does and how it does
it, Kremer (2001). As this project is concentrating on the allocation process, only this part of the
situation will be represented via a root definition. The root definition is as follows:
“A module support management system to enable data entry by conventional web-based data entry
forms, for module support requirements and postgraduate availability in keeping with the existing SIS
system, in order to allocate support where requested in the most efficient way.”
What the system will do: “enable data entry… for module support requirements and postgraduate
availability”.
How the system will do this: “by conventional web-based data entry forms”.
Why the system will do this: “in order to allocate support where requested in the most efficient way”.
3.3.3 CATWOE analysis
To analyse the root definition a mnemonic known as CATWOE is used. This is composed of six
different elements that are important to the system. CATWOE and root definitions normally go handin-hand as they are used together to help produce an accurate system, Couprie et al (2004). The
following table shows the mnemonic CATWOE in relation to the proposed system.
Acronym
C
What it stands for
Customers
What it means in
The answer in
relation to the
relation to the
system
system
People who would
Undergraduates
benefit from the
system.
A
Actors
Those who would
Allocation Officer,
actually do
Director of Learning
something in the
and Teaching,
system
Postgraduates,
Module Leaders
15
T
Transformation
What are the input
Requirements and
process
and outputs of the
availability give
system?
allocation.
Allocation and
money spent gives
reports.
W
World view
Why is the system
Modern improved
being built?
SIS data makes this
feasible
O
Owners
Who has control and
Director of Learning
could stop the system
and Teaching
from happening?
E
Environmental
Elements outside the
Technology of SIS
Constraints
system that limit the
database.
capabilities of the
University payroll
system.
system.
Table 1, CATWOE analysis of system
3.4 Use case diagram
It should be possible to build upon the soft systems methodology analysis to help produce Use case
diagrams of what the system will do in detail. The diagrams will indicate exactly what each actor will
do within the system based on their requirements. Figure 6 shows the Use case diagram of the
proposed system, the requirements have been taken from the user requirements that have been
collected. Each user of the system is represented by an actor in the diagram. It should be noted that in
both the CATWOE analysis from table 1 and the Use case diagram of figure 6 the university payroll
system does not play a part as an actor. The payroll system is part of the overall system as it pays the
postgraduates. However, it is not classed as a user of the system being built for the project as it is more
of an external factor and beyond the capacity of this project.
Use case diagrams give more of an idea of the users’ requirements and how they interact with other
users of the system. More detail is given about each requirement for each user specifying exactly what
will happen in the process.
16
Register
View all
registered
availability
information
Register skills
Allocate
and expertise
postgraduates to
support requests
Allocation Officer
Postgraduates
View allocation
details
View hours
View total hours
remaining of
worked by all
allocated work
postgraduates
Update hours
Module leaders
worked by
View total
Director of
postgraduate
amount spent
Learning and
Teaching
Register module
support requests
Figure 6, Use Case diagram of proposed system.
Postgraduates
•
Register availability – The postgraduates will actually enter their periods of unavailability.
This is because postgraduates are assumed to be available all year round. Periods of
unavailability may include holidays and will have a start and end date.
•
Register skills and expertise – Postgraduates will choose from a list skills that they have. They
will then give a rating, out of 5, for their enjoyment and expertise of that particular skill. They
will also be able to enter a preference of work, either demonstrating or marking.
Module leaders
•
Register module support requests – Once the support requests for the module are known, the
module leader will be able to enter the details for various module tasks. These will include the
17
type of task, marking or demonstration, the number of postgraduates required, a brief
description of the task, the number of hours it will take and any skills required to perform it. It
will also have a start and end date.
•
Update hours worked by postgraduate – The module leader will be able to update the number
of hours that the postgraduate has worked for that particular module once the postgraduate has
done the work.
Postgraduates and Module leaders
•
View hours remaining of allocated work – Both the postgraduate and module leader will be
able to view how many hours of work remain for the postgraduate allocated to the module
leader’s module.
Allocation Officer
•
View all registered information – The allocation officer will be able to view all the module
task details that have been entered and all the postgraduate details.
•
Allocate postgraduates to support requests – With all the details available to view the
allocation office will be able to match the postgraduate to the module. This will be based on
the skills required by the module’s tasks matching the skills of the postgraduate. It will be a
manual process completed by the allocation officer with the postgraduate’s skills enjoyment,
experience and preference all taken into account.
Allocation Officer and Director of Learning and Teaching
•
View total hours worked by all postgraduates – Both of the allocation officer and the director
will be able to view a summary of the total number of hours worked by all the postgraduates
for all the modules.
•
View total amount spent – Using the hourly rate paid by the University it will be possible to
display the total amount spent to both the allocation officer and the director.
All users
•
View allocation details – All the users of the system will be able to view the allocation details
that concern them. In the case a postgraduate it would be the allocation details involving
themselves. Whereas a module leader would be able to view the allocation details involving
their own module. Both the allocation officer and director of learning and teaching would
have access to view all the allocations made involving all postgraduates and modules.
18
Chapter 4: Design
4.1 Database Design
As it has been decided that all information will be held in a PostgreSQL database it is important that
the database is designed well. The database should be designed so that the tasks performed upon it are
efficient, fast and correct. This means that data should not be unnecessarily stored more than once and
the relationships between the tables are correct.
4.1.1 Entity-Relationship modelling
According to Holding (2000) an important tool for designing tables in a database and the relationship
between them is entity-relationship modelling. Holding (2000) claims that entity-relationship
modelling is made up of two parts. The first part is the list of items and events stored as information in
the system. The second part is the relationship between the items and events which is shown using an
entity-relationship diagram.
From the analysis in Chapter 3 the following items of information need to be stored in the database.
Module support requests, in the form of tasks, and postgraduate availability. From these it becomes
apparent that both module and postgraduate details also need to be stored. The actual allocation details
would be required to be stored in the database so they can be accessed and viewed. Finally, the skills
are the important information that the allocation will be made upon. The skills that are required by the
module tasks, and those that the postgraduates may possess, will be selected from a stored list.
Holding (2000) describes the items as entities, which in themselves hold more information.
The relationships between the entities vary. Holding (2000) states that there are three different types of
relationships one-to-one, one-to-many and many-to many. The following relationships occur between
the entities for the proposed system and are shown using an entity relationship diagram.
One postgraduate can enter many periods of unavailability. A postgraduate’s unavailability slot is
unique to that postgraduate so this is a one-to-many relationship.
Postgraduates
1
N
Postgraduate
unavailability
Figure 7.1 ER diagram for postgraduates and their unavailability
One module can register many support requests known as module tasks. A module’s task is unique to
that module. This is also a one-to-many relationship.
19
Modules
1
N
Module Tasks
Figure 7.2 ER diagram for modules and their tasks
A postgraduate can possess one or more skills. A skill can be possessed by one or more postgraduates.
This makes it a many-to-many relationship.
Postgraduates
M
N
Skills
Figure 7.3 ER diagram for postgraduates and their skills
A module task can require one or more skills. A skill can also be requested by more than one module
task. This is also a many-to-many relationship.
Module Tasks
M
N
Skills
Figure 7.4 ER diagram for module tasks and skills
Originally it was assumed that postgraduates would be allocated to individual module tasks in the
database. It was decided this was an inefficient and complex method. The solution was to allocate the
postgraduates to the modules whose tasks requests they met. A postgraduate would then be associated
with that module and perform all the tasks for that module. A postgraduate would be able to work for
one or more modules and one or more postgraduates would be able to work for one module.
Postgraduates
M
N
Modules
Figure 7.5 ER diagram for postgraduates and modules.
Holding (2000) informs that many-to-many relationships cannot be built in a database. The solution is
to transform the relation into two one-to-one relationships with a new entity between them. The new
entity will hold both primary keys of the other two entities.
Module Tasks
M
Module
N Skills
skills
Figure 7.6 Revised ER diagram for module tasks and skills
20
Postgraduates
M
Pg
N Skills
skills
Figure 7.7 Revised ER diagram for postgraduates and skills
Postgraduates
M
Allocation
N Modules
Figure 7.8 Revised ER diagram for postgraduates and modules
4.1.2 Normalisation
The entities will become tables in the database and they will require columns called attributes to store
information. The SIS already holds existing data on postgraduates in a table called rs_student and
module details in a table called ts_module_detail. The primary keys are stu_num for the
postgraduates and module_code, year and semester for the modules. As extra columns are required to
be stored in the postgraduate table a new table will be built which will be designed so that information
from the SIS table can be referenced. The ts_module_detail table will be used directly for module
details.
Holding (2000) describes a second method of database design called normalisation. In a series of steps
and rules it is possible to improve the quality and efficiency of the database. The three main stages of
normalisation are first, second and third normal form and are described by Holding (2000) as follows:
First normal form – If there are several rows where the same group of column data is repeated remove
the columns and place them in new tables.
Give each table a primary key column to uniquely identify each row. Any table’s column that
references another table’s primary key becomes a foreign key.
Second normal form – With a multi-column key table remove any other columns that depend on only
part of the key. Place these columns in a different table.
Third normal form – Remove any columns from a table that are not dependant on the key and place
them in a new table. Also do the same for any columns that are dependant on other columns that are
not the key.
21
Using the background reading, analysis, SIS tables and normalisation rules the following table designs
were formed. For the data types and check constraints the PostgreSQL website documentation
PostgreSQL (2005) was referred to on a regular basis. The primary key for each table is highlighted in
bold whilst any foreign keys are indicated by an asterisk.
Table: Postgraduates
Column name
Description
Data type
stu_num*
student unique number
character varying(10)
pref_demonstrating preference for demonstrating
boolean
pref_marking
preference for marking
boolean
pref_admission
preference for admission
boolean
Check constraints
visits
hours_avail
number of hours available for numeric(5,2)
work
Figure 8.1 Postgraduate table design
In figure 8.1 the preference for admission visits has been added as it is used on the original form and
could be used if the system was expanded, see Appendix D. The data type numeric (5, 2) is a variable
5 integers long of which 2 are decimal places, PostgreSQL (2005). The student number, stu_num, is
also a foreign key as it references the column stu_num in the table rs_student from the existing SIS
system. As SIS holds all the postgraduates this ensures only legitimate postgraduates can store their
details.
The ts_module_detail table from SIS will be used as it holds everything required. The primary key is
made up of a module_code, year and semester. The module_code is of a length of up to 12 characters
long whilst both the semester and year are small integers.
Table: pg_unavailability
Column name
Description
Data type
unavail_id
a unique number for ID
SERIAL
s_date
start date
date
e_date
end date
date
stu_num*
student unique number
character varying(10)
Figure 8.2 postgraduate unavailability table design
22
Check constraints
The SERIAL data type in figure 8.2 ensures that each time a new record is formed the unavail_id
increments by one. The foreign key stu_num references stu_num in the postgraduates table to ensure
only postgraduates that have registered their details can enter their unavailability periods.
Table: module_tasks
Column name
Description
Data type
mt_id
a unique number for ID
SERIAL
type
type of task
text
Check constraints
Demonstrating or
Marking
hours
number of hours the task will
numeric(5,2)
take to complete
pg_required
number of postgraduates
integer
required for the task
description
a brief description of the task
text
d_start
start date
date
d_end
finish date
date
module_code*
module unique code
character varying (12)
year*
The year the module is held
small integer
semester*
semester of study
small integer
Figure 8.3 module tasks table design
The check constraint in figure 8.3 ensures only the specified values can be entered for that field. For
type admission is not stated as module tasks do not include admission visits. For demonstrating both
the start date and finish date will be the same. For coursework marking the start date will indicate the
deadline date for the students, when the postgraduates will get the work to mark. The finish date will
indicate the date it has to be given back to the students. The foreign key is made up of three parts all
referencing ts_module_detail table from SIS.
Table: skills
Column name
Description
Data type
skill_id
a unique number for ID
SERIAL
name
short description of skill
character varying (30)
Figure 8.4 skills table design
23
Check constraints
Figure 8.4 shows the skills table where the primary key is the skill_id given to each skill description.
Table: module_skills
Column name
Description
Data type
mt_id*
module task id number
integer
skill_id*
skill identification umber
integer
Check constraints
Figure 8.5 module skills table design
In the module skills table in figure 8.5 the mt_id and skill_id columns are both primary and foreign
keys. This is due to the table being used in the middle of a many-to-many relationship between module
tasks and skills. The mt_id column references the mt_id column in module tasks whilst the skill_id
column references the column skill_id in the skills table. Pg_skills in figure 8.6 and allocation in
figure 8.7 are similar types of table.
Table: pg_skills
Column name
Description
Data type
Check constraints
stu_num*
Student unique number
character varying (10)
skill_id*
skill identification number
integer
enjoyment
the postgraduate’s enjoyment
integer
A value between 0 and 5
integer
A value between 0 and 5
of the skill
experience
the postgraduate’s experience
of the skill
Figure 8.6 postgraduate skills table design
In figure 8.6 the stu_num column references the stu_num column in the postgraduates table. The
skill_id column references the skill_id column in the skills table. Both enjoyment and experience use a
check constraint to ensure that the value for their fields is between 0 and 5 inclusive.
24
Table: allocation
Column name
Description
module_code* Module unique code
Data type
Check constraints
character varying (12)
year*
the year the module is held
small integer
semester*
semester of study
small integer
stu_num*
Student unique number
character varying (10)
hrs_allocated
number of hours allocated to
numeric(5,2)
postgraduate for the module
hrs_claimed
number of hours claimed by
numeric(5,2)
postgraduate for the module
verification
verification of hours claimed
boolean
by postgraduate
Figure 8.7 allocation table design
In figure 8.7 the module_code, year and semester columns reference the columns of the same names in
the ts_module_detail table. The stu_num column references the stu_num column in the postgraduates
table. The verification field will be filled in by the module leader to verify the hours claimed by the
postgraduate so that they can be paid.
Figure 9 shows the completed ER diagram for the proposed system. The tables are represented by
rectangles with the attributes of the tables represented by ovals. The diagram shows how all the tables
relate to each other and completes the database design. The database is now ready be implemented in
PostgreSQL.
25
Start
End
Name
Stu_num
Date
Preference
1
Postgraduates
N
Is
Postgraduate
unavailability
unavailable
Hours
M
Enjoyment
unavail_id
available
Experience
N
Is
Pg Skills
allocate
Hrs_claimed
Skill_id
N
N
Verification
M
Skills
Name
Allocation
M
M
Hrs_allocated
Module Skills
To
Semester
N
Year
Modules
N
1
Module Tasks
Description
N
Module_code
Have
Hours
Number of
Date
PG’s required
Start
Type
End
Figure 9, Entity relationship diagram of proposed system
4.2 Interface Design
Although the system may have a well designed normalised database it is of no use without a well
designed interface. There is no point having a place to store information if the users of the system are
unable to enter or retrieve the information. The interface design is important as it will be what the
users of the system will rely on to make the system work. A poorly defined interface that doesn’t
26
allow information to be entered correctly is useless. On the other hand an interface that does exactly
what it should but is hard to use or time consuming will put off prospective users. An interface should
be easy to use and well presented requiring the least amount of time and effort as possible. This is
difficult to achieve and extensive research into the subject is required.
4.2.1 Usability
Jacob Nielsen is well-known for his work with usability on web sites. He has produced an effective
method for testing usability known as heuristic evaluation and guidelines for producing a good user
interface, Nielsen (2005). The ten guidelines are as follows:
1. Visibility of System status – the user should always be informed of the current status of the
system via regular feedback.
2. Match between system and the real world – the user should not be confronted with
unfamiliar language or terms when using the system.
3. User control and freedom – the user should be able to undo any mistakes they make.
4. Consistency and standards – the user should find the layout and processes consistent.
5. Error prevention – the user should find it as difficult as possible to make a mistake and cause
an error to occur.
6. Recognition rather than recall – the user should not have to rely on their memory,
everything should be clearly presented before them.
7. Flexibility and efficiency of use – the different users’ levels of expertise should all be catered
for.
8. Aesthetic and minimalist design – the user should only have to view information that is
relevant to them.
9. Help users recognize, diagnose, and recover from errors – in the event of an error the user
should be presented with a helpful message explaining the problem and a solution.
10. Help and documentation – the user should be able to access small helpful documentation
explaining exactly how things work.
4.2.2 Colour
According to Parker (1997) colour has both good and bad points. It can be used to benefit the interface
by attracting attention to and emphasising an important part. It can also be useful by helping increase
understanding of something by clarifying and simplifying. However Parker (1997) warns that colour
can be misused. Used incorrectly it can cause the opposite effect leading to confusion and disorder.
Too much colour is bad and clashing the colours can lead to problems especially with text. A
27
particular colour font on the wrong colour background can lead to illegible text. A pale blue
background with black text is therefore the colour of choice in the designs.
4.2.3 Form designs
Three different data entry forms have to been designed:
•
One for postgraduates to enter their unavailability periods, select skills and preferences.
•
One for module leaders to enter their module requests.
•
One for an administrator to enter skills.
The three main forms will each consist of many pages for each section of entering data. Each form
should allow easy navigation for the required user by highlighting where they are at each stage of the
process of entering data and having buttons to allow movement between pages in both directions.
The postgraduate form will consist of a starting page, known as the selection page, where the
postgraduates enter their unique student number to personalise the data entry process for them. If an
incorrect number is entered then access to the data entry pages will not be allowed. Figure 10.1 is the
initial design for the starting page for the postgraduate data entry form. It includes a text input box for
entry of the number and a button labelled submit to send the number for confirmation.
Pgs - selection
Enter number:
Submit
Figure 10.1, Postgraduates selection
The next page will be the main menu giving the postgraduates a choice of places to go to and enter
data or alternatively log out. Figure 10.2 is rough design of the main menu. The title at the top will
give the postgraduate unique number to show which postgraduate is currently entering data. The
logout button will go back to the selection page and the form will no longer be personalised. The other
buttons go to the respective pages.
28
Pgs – menu for (Pg number)
Unavailability
Skills
Preferences
Logout
Figure 10.2, Postgraduates main menu
If the unavailability button is selected then the postgraduate will be presented with the unavailability
menu as shown in figure 10.3. Clicking the view button shows any existing records in the form of a
table. If records do exist then new buttons will appear giving the option to sort the records by date or
to delete the selected record. The menu button will send the postgraduate back to the main menu
whilst the add button will bring up the page where unavailability is entered. The enter unavailability
page will allow the postgraduate to select a start and end date using drop down boxes for the day,
month and year.
Pgs – unavailability for (Pg number)
View
Add
Menu
Figure 10.3, Unavailability menu
For the skills page, accessed via the skills button on the main menu, the skills entered by the
administrator in the skills data entry form will be available to select via a drop down list. To
complement the skill selected the postgraduate will also be able to select an enjoyment and experience
level from a drop down list. Postgraduates will have the option to add, view and delete skills from
their records.
The preference page will be the same concept as the skills page but instead of selecting a skill the
postgraduate will select their preference choice using drop down lists. They will also be able to enter
the number of hours they will be available for.
29
The module data entry form will be similar to the postgraduate form. Like the postgraduates enter their
number, the module leaders will enter their module code on the starting page of the module form as
well as the year and the semester of the module. It too will lead to a personalised main menu. The
menu will give the option of logging out or entering a module task. The module task entry page will
consist of drop down lists for the type of task and start and end dates. It will also contain text boxes
for the number of hours, number of postgraduates and description. Once the task has been recorded
then skills can be added to it on a separate page. This is because a task can require more then one skill.
The skills will be selected from a drop down list with its selection coming from the administrator’s
skill data entry form. All records will be able to be viewed in the form of a table and be able to be
deleted using the delete button. Figure 10.4 shows a design for the task entry page.
Enter tasks for (module code)
Type
Hours
Postgraduates
Description
Start date
End date
Add
Skills
Delete
Menu
Figure 10.4, module task entry page
For the skill data entry form that will be used by the administrator, skills will be entered in a text box
and once recorded given a unique identification number. The administrator will be able to view all the
skills and modify them by adding to them or deleting them. Searching the skills will be possible either
by name or unique number. These skills once recorded will be then made available in drop down lists
for both postgraduates and module leaders to select in their own forms.
30
Chapter 5: Implementation
5.1 Connecting to the database
SIS technical support created a PostgreSQL database on the csweb2 server for the project. It included
a list of tables full of existing data from SIS including module details and postgraduate details. They
also included links to helpful references such as perldoc CGI and perldoc DBI for using perl to access
the database. One link at ~mpc/pub/Perl/DBI/Postgres on the Linux machine led to a file called
table_display. The file in question listed how to connect to the database using DBI.
“DBI defines a set of functions, variables and conventions that provide a consistent database
programming interface for Perl”, Patwardhan et al (2002).
The code from table_display was modified slightly and used at the beginning of the CGI scripts to
connect to the database. The code is shown below, the name of the database is scs2dag and the host is
csweb2. The password has been removed from the code listing for security reasons.
use DBI;
$drh = DBI->install_driver('Pg');
$db = 'scs2dag';
$username = 'scs2dag';
$password =
$dsn="DBI:Pg:dbname=$db";
$dbh = DBI->connect("$dsn;host=csweb2.leeds.ac.uk", $username, $password) or
$dbh = DBI->connect($dsn,$username,$password);
All the scripts are held on the WWWdev server in a folder called cgi-bin. Permissions are set to allow
execution, read and write access.
5.2 Modifying the database
Accessing the database is done using the command on one of the School of Computing’s Linux
machines:
psql -h csweb2 -d scs2dag -U scs2dag
31
The line of code was given by the SIS technical staff. PostgreSQL (2005) explains that psql is an
interactive terminal for PostgreSQL. It allows the user to enter queries for the database via a command
line and view the results.
Initially tables were added to the database and modified using the command line. However, as the
tables were constantly requiring modification it became a time consuming and tedious procedure with
mistakes occurring frequently. As there were no graphical applications available in the School of
Computing another method was sought. PostgreSQL (2005) suggested creating the queries in a text
file and then using the command forward slash ’\’ and then the letter ‘i’ followed by the filename. This
would run the query just like it would have if the query was typed in the command line interface. This
allowed modification of the queries a lot quicker and efficiently as just the text file had to be modified
and then run again.
PostgreSQL (2005) was the main reference used for creating and modifying the tables as it is detailed
yet simple to follow and covers a broad range of methods. Although the tables were created with some
check constraints the majority of the validation was done using the perl code. This ensured that
incorrect data was prevented from being sent to the database in the first place.
5.3 Writing the CGI scripts
Guelich et al (2000) explains some features that are required for the CGI scripts:
Each CGI script was written in perl and required a line at the top of the script showing where perl
resides on the system: #!/usr/local/bin/perl -wT
A perl module called CGI.pm was used to create the CGI scripts. The module has to be called using
the code: Use CGI;
As CGI is object-oriented a new CGI object is created using the code: $CGI = new CGI();
As the perl is going to produce a HTML page it requires a line of code to notify the browser that it is
going to be sent a HTML page: print $CGI->header();
To include HTML in the code various print statements were used which had to be escaped with '\n'
due to the use of speech marks. This is the simplest method of including HTML and as large sections
of the code were similar, a lot of cutting and pasting was used.
32
Querying the database using DBI involves creating a statement, preparing the statement and then
executing it. The statements were made up of normal SQL and the results are returned as rows that
were stored in an array using the command: @row = $sth->fetchrow_array
The number of rows returned was useful information and was stored in a variable using the code:
$rows = $sth->rows
The majority of the code involved manipulating the arrays and variables to give the information
required and then displaying it in a user friendly manner in HTML. The forms pass data between their
HTML generated pages using the POST method.
5.3 The allocation report
The report was particularly difficult to implement. It consisted of matching the postgraduates to the
module whose task skill requirements they met. A postgraduate can possess many skills and a module
can include many module tasks with each module task requiring many skills. For a postgraduate to be
considered for a module they must possess all the skills required by the module’s tasks. The problem
came trying to find a SQL statement that would bring out the correct results as the join was trying to
occur between two link tables pg_skills and module_skills matching on skill_id. Figure 11 is a basic
example. Module task of mt_id nine requires skills of skill_id one and two; postgraduate of stu_num
800005 is the only postgraduate who possesses all the correct skills. However a SQL select statement
SELECTS stu_num WHERE skill_id = 1 AND skill_id = 2 does not work.
pg_skills
stu_num
module_skills
skill_id
mt_id
skill_id
800005
1
5
2
800005
2
9
1
800004
1
9
2
Figure 11, example of allocation
It was finally implemented using nested select statements, an iteration technique in perl and storing
values in arrays and variables. The following is a slightly modified version of the actual code created:
33
1 $statement580 = "Select skill_id from module_skills where mt_id =?";
2 $sth = $dbh->prepare($statement580);
3 $sth->execute($elem5700);
4 $rows5000= $sth->rows;
5 while($row5701 = $sth->fetchrow_array())
6{
7 push(@row5702, $row5701);
8}
9 $sth->finish;
10 if (@row5702)
11 {
12 $statement581 = "Select stu_num from Pg_skills where skill_id = @row5702[0]";
13 $bracket = 0;
14 for (1..$rows5000){
15 foreach $elem500(@row5702)
16 { $bracket = $bracket + 1;
17 $statement581 = $statement581 . " and stu_num in ( select stu_num from Pg_skills where
skill_id = $elem500";
19 }
20 }
21 while ($bracket > 0)
22 {
23 $statement581 = $statement581 . ")";
24 $bracket = $bracket - 1;
25 }
26 }
27 else{
28 $statement581 = "Select distinct stu_num from Pg_skills";
29 }
30 $sth = $dbh->prepare($statement581);
31 $sth->execute();
Line 1 – 3 is just running a SQL statement to get all the skill_ids required for the module task in
question. Line 4 saves the number of rows returned as a variable $rows5000 which is used to show
how many skills are requested by the module task. Line 5- 8 pushes the rows returned into an array
@row5702. Line 10 checks to see if the array contains values if it does then line 12 creates a SQL
statement with the skill_id as the first element in the array. Line 14 – 20, for the number of skills
requested the SQL statement grows in size with each skill_id becoming part of it. The bracket variable
also increases in size at the same rate. Line 20-26, brackets are added to the end of the statement
according to the number of skills. Line 27 -29 is for if the array was empty, the module task requested
no skills, the resulting statement would select all postgraduates. Line 30 – 31 prepares and executes
the statement it is given.
34
The statement works by selecting all the postgraduates that have the first skills and from that list
selecting all the postgraduates that also have the second skill and continuing for all the skills
requested.
5.4 Problems encountered
One problem encountered was being unable to find a way of increasing the size of the submit buttons
on the forms. This resulted in the buttons being left the same size.
Another problem was sending a variable between html pages within a script when it wasn’t stored
anywhere. This occurred when using the postgraduate identification number to personalise every page
when the number had not been entered in any text box so couldn’t be selected using parameter calling.
Guelich et al (2000) recommended solution was to use a hidden field’s value to store the number and
then reference it using a parameter call. The hidden field works like a text box but is invisible on the
form.
Entering user input values to an SQL statement became a problem if the user enter something with an
apostrophe. It was also dangerous as using the right command the whole database could be deleted. To
combat this a question mark was used in place of the variable. Patwardhan et al (2002) refers to them
as place holders. Values can then be bound to them before execution ensuring only the exact value is
sent and nothing is escaped. The variable would then be set within the execute command,
The final problem encountered was being unable to get the scripts to work in an Internet Explorer
browser. The script worked in Mozilla but not in Internet Explorer, the pages wouldn’t change. An
investigation into the problem revealed the buttons in the code were not within the form brackets and
as such were not working.
35
5.5 Source of forms
As the prototype system is a deliverable the following addresses link to the forms.
The skills data entry form can be found at:
wwwdev.comp.leeds.ac.uk/cgi-bin/scs2dag/skills.cgi
The modules data entry form can be found at:
wwwdev.comp.leeds.ac.uk/cgi-bin/scs2dag/modules.cgi
The postgraduates data entry form can be found at:
wwwdev.comp.leeds.ac.uk/cgi-bin/scs2dag/postgraduates.cgi
The report form can be found at:
wwwdev.comp.leeds.ac.uk/cgi-bin/scs2dag/report.cgi
They are best viewed using Mozilla web browser as they were implemented using the browser as a
reference. However they do work in Internet Explorer.
Screen shots of the forms can be seen in Appendix G.
36
Chapter 6: Testing
6.1 What is testing?
Emprend (2005) states that testing is a crucial part of the product development process. It is used to
ensure that for a set of specified inputs, a design produces the correct and expected outputs. Testing is
also used to ensure the product has met its initial requirements and is in such a position that it can be
used efficiently and effectively by the users of the system.
6.2 Types of testing
Almstrum (1998) describes different types of testing methods. Black box testing ignores anything
internal, like the code, and concentrates on the functional performance of the system. White box
testing is the opposite in that it concentrates on the code internally. Walkthrough testing is completed
by a user to try and find faults with the system.
6.3 Testing the code
Testing has been a continuous process throughout the building of the system. Each new piece of code
once implemented was tested individually to ensure that it worked. This involved testing it with a
variety of different inputs both valid and invalid to ensure that the correct output was given. The code
was also continuously tested using the command perl -wcT <filename> to ensure that the perl syntax
was correct. Guelich et al (2000) refers to it as a switch. The form was continuously refreshed to
ensure that the HTML code was producing the desired result every time it was slightly modified.
6.4 Testing the system
Testing the system as a whole was performed using different inputs, the expected output and what the
actual output was. The inputs were a wide range of data including valid and invalid data. Ranges were
tested as were data types. The database as a whole was tested to ensure that records could be added,
deleted, modified and viewed. The system was also tested against the user requirements to ensure it
met them.
The final stage of testing involved getting users to test the system using a walkthrough. After they had
finished they were interviewed and their responses were recorded. This allowed not only faults to be
found in the system that may have been overlooked but also to find any usability issues that may
37
occur. It also allows the design of the interface to be commented on so that it can be modified in the
future.
6.5 Testing the functions
Figure 11 shows an example of the testing procedure that was performed on every input box on all the
forms. The example is only short but as there is not room to show every testing procedure performed it
gives a brief view of what the process consisted of and how it was performed. If an actual result was
different to the expected result then the problem, if any, was rectified.
Area Tested
Input
Expected result
Actual result
Problem
rectified?
Skill form – Search
Valid number
Return and display row
Return and displays row
N/A
Invalid number
Return no result
Error message indicating
N/A
ID number
Skill form – Search
ID number
Skill form – Search
invalid number entered
A letter
Error message
ID number
Skill form – Search
Error message indicating the
N/A
input was not numerical
Nothing
Error message
ID number
Error message indicating the
N/A
field was empty
Figure 12, Example of data testing
After the data testing was completed then the functions were tested to ensure the procedure worked as
a whole. Records were added to the database to test how the tables interacted. Not all problems
encountered could possibly be recorded so the following are brief examples:
In the module form after deleting a skill from a task and then going back to the task entry form, the
module code would disappear. The page would no longer be personalised to a particular module. The
solution was to call the value for the module code that stored in a hidden field before displaying the
task entry page.
Another problem was in the report if a module task had no specified skill then all the postgraduates
were listed, however they were listed for each skill they possessed. The solution was to use a
DISTINCT value in the SQL statement so that they were only listed once.
In the postgraduate form, if a user doesn’t register their preferences before their skills and
unavailability then no records are created when trying to enter skills or unavailability. This is due to
38
the fact that the preferences actually creates a postgraduate record that the skills and unavailability
reference.
Unable to delete a module task record that has requested skills. This causes a referential integrity
problem. The solution is to ensure the skills are deleted from the task before deleting the task itself.
Another solution is to use cascade delete in the table designs, PostgreSQL (2005).
6.6 Meeting the user requirements
As the system is only a prototype and only one iteration has been performed the system is not expected
to reach all the user’s requirements. The system is mostly concerned with catching data and there is
room for expansion. Testing the system against the user requirements led to problems being
discovered and corrected.
6.7 User walkthrough
The results of the user walkthrough are summarised below:
In general the consensus was that instead of having several different addresses for all the different
forms, one page should be used with links to all of them. Then only one address would be required.
The background colour was considered a good colour to use and the font was clear and easy to read.
The red text really stood out and was a good idea for important pieces of information like error
messages.
6.7 .1 Skills form
For the skills form, a user commented that just one button would be preferable for searching rather
than have separate buttons for name and number. The preferable solution was that the user would able
to fill in any field and search depending on what was entered.
Criticisms included the navigation being poor with the skills entry and searching being on separate
pages. The users didn’t enjoy, after entering a skill, having to go back to the search page to view the
results as this required unnecessary clicks of buttons.
39
A final criticism for the skills form was that it didn’t contain a password. When entering the address
the form opens up with the search page. Also, an introduction explaining what the page was and did
would be advantageous.
6.7 .2 Modules form
A problem occurred straight away as, given a module code, users were unable to log on. This was due
to them not entering it in capital letters. Although users didn’t mind they claimed they would prefer it
if it specified near the text box that data entry was case sensitive.
When it came to the task entry form the size of the window was an issue. Users were unable to see the
entire screen and had to scroll down to see everything, especially error messages. A popular thought
was that it would be an improvement if the skills of the tasks were listed along with the task rather
than having to travel to a separate page to view them.
Points that were considered well designed were the error messages as they were informative, clear and
precise. They explained exactly what the error was and how to solve it. The drop down lists for
entering dates were also considered useful and easy to use.
6.7 .3 Postgraduates form
Again more comments about how it is not very clear what everything does. Users quickly became
confused and claimed more information was required.
For the preferences a suggestion that rather than have to delete the record if the postgraduate wanted to
change it they should be able to edit or update it. A large error occurred when trying to delete the
record as it was unable to be deleted due to being referenced from records of postgraduate skills and
unavailability.
6.7.4 Report form
The report was considered well designed apart from that instead of using the postgraduate’s number it
was suggested their names should be used instead.
As the user walkthrough was performed at the end of the project and the system is only a prototype the
suggestions of improvements could be considered for future expansion of the system.
40
Chapter 7: Evaluation
7.1 Evaluation criteria
To correctly evaluate the system a set of criteria is required. Martin et al (2003) provides a general
framework for evaluating business multimedia products. The framework includes a large list of
criteria, some of which are appropriate for evaluating this system. The criteria chosen include:
•
Pragmatic – Does the system do what it is meant to?
•
Useable – Are users able to use the system? Can they find what they want easily enough?
•
Reliable – Is the system stable?
•
Metamorphic – Is the system able to expand to meet new requirements?
Each criterion will now be justified to show its relevance to the system.
For the pragmatic criterion the system needs to be able to do what is was designed to do. In the case of
the system this would be if the project had met its minimum requirements. The minimum requirements
specify the bare minimum the system is meant to do. This criterion is justified as it essential for
evaluating what the project has achieved via the system. This also includes the minimum aim and
objectives of the project. The system may also be evaluated against the user requirements.
The justification of the useable criterion is that the system is no good if the users are unable to use it.
Evaluating this will see if the design was done correctly and used a strong enough emphasis on HCI
aspects. The testing procedure from Chapter 6 will help with the evaluation.
As the system would hopefully be implemented with SIS in the future it would have to be stable and
reliable. It would also have to be able to expand to meet all the user requirements and any new
requirements that come with being implemented with SIS. This is the justification of the last two
criteria in the list.
Other criteria include the methodology that was used for producing the system to see if it was the
correct one to use and time management to see if all deadlines and milestones were kept to.
41
7.2 Is the system pragmatic?
The minimum requirements included to create a database, web-based data entry forms and at least one
report. The system has all these features so it does what it is meant to. It has actually expanded upon
these by allowing postgraduates to not only record their periods of availability but also record their
skills and preferences. As for the user requirements the system does not meet them all as it is only a
prototype and has only gone through one iteration of the development process. It allows both
postgraduates and module leaders to enter their details which are stored in a PostgreSQL database.
7.3 Is the system useable?
According to the users who tested it using the user walkthrough in Chapter 6 the system was useable.
Although it could be greatly improved upon especially in the navigational aspects they still managed
to use it to perform procedures such as creating records of postgraduate unavailability. The design of
the database works until trying to delete a record that is referenced elsewhere and causing referential
integrity problems, although this could be solved with more time. The design of the interface is poor
and could have done with more research into it and maybe some initial testing instead of leaving it to
the end. The colour scheme was effective and helped with the HCI aspects.
7.4 Is the system reliable?
Although the system underwent vigorous testing new problems were constantly found. At the current
state, once the referential integrity problem has been solved, the system is fairly stable. The system
can perform the procedures declared in the minimum requires to a respectable degree. However, with
the many different text boxes and the different values that can be entered it is not stable enough to be
considered for anything other than a prototype. Something important that is missing from the system is
the security aspects. There are no password fields and no part of the system is secure.
7.5 Is the system metamorphic?
Although the system does not meet all the user requirements it is possible to expand upon the
prototype to meet the rest. The database which can be referenced and modified currently includes a
table for allocation details to be held. By implementing a form or modifying the report an expansion
could include allocating a postgraduate to a module and then storing it in the table. This table when
referenced could meet a lot more of the user requirements including allowing all the users to view the
allocations that concern them. The code allows for expansion as it includes a lot of re-use of the same
42
methods. Although as a prototype it is along way off being implemented with SIS even it does use the
same technology and language.
7.6 Methodology use
The waterfall methodology was used due to the time constraints on the project which only allowed for
one iteration. The use of SSM helped with the analysis to ensure everything was fully understood
before the design took place. The waterfall model prevented going backwards so it was convenient
that the process of going through the stages did not call for this. The main problem with the model was
performing the main testing at the end as it left no time for amending any problems that were found.
Although testing was a continuous process throughout the development it was only basic and the
majority of problems only revealed themselves at the end.
7.7 Time management
At the start of the project the time schedule of when each task would be completed was set in the form
of a Gantt chart, see Appendix B. However the project was not keeping with the schedule due to the
Christmas break not being used as efficiently as possible. Also the time process for learning perl was
heavily underestimated. Due to these factors implementing the interface took longer resulting in there
not being time to produce a prototype to show to the main users which could be improved upon. The
testing therefore had to be done right at the end once the system had been fully implemented meaning
it couldn’t be improved upon. The write up of the project which was known to be time consuming was
started later than planned as more time was put into developing the system. The final time schedule of
when the tasks were actually completed is shown in Appendix C.
7.8 Comparison with existing solutions
The project has met all the minimum requirements, all the objectives set and reached its aim.
In comparison with existing solutions a system was produced to solve a problem of using the current
situation. The initial problem was that current situation was not very efficient. The solution was to
speed up and increase the efficiency of data entry and storing it orderly in a database. All the transfers
of data were to be done electronically while keeping redundancy to a minimum. The system does
allow for easy and quick data entry. It is efficient and stores the data in a normalised database.
However as a prototype it does not completely do everything the original situation does although it
was never designed to. It couldn’t completely replace the existing situation but it gives some ideas of
43
how to improve the way things are done. Hopefully in the future after much work and expansion it
could be considered a serious contender for replacing the current methods.
44
Chapter 8: The future
8.1 Future Expansion
The original concept was to build a prototype for a system that could eventually after many iterations
be implemented with SIS. The aim for the project actually claims that the project’s system should
make use of SIS. It did in that it used and referenced copies of tables that exist on SIS. Future
expansion would involve the system actually using the tables in SIS and possibly creating the tables
from the system in SIS. However in this event the database would be completely redesigned and the
standard forms for web-interface for SIS would most likely be used.
8.2 Future Improvements
The prototype system could be improved in so many numerous ways that they can not all be listed.
Firstly all the user requirements would have to be met. This would involve implementing all the
different reports.
At the moment the prototype only caters for postgraduates. To improve the system further Teaching
Assistants could be taken into account. Deadline dates could be implemented into the system to ensure
that data received is not after the deadline. Most importantly a proper logging in system for the forms
with security including passwords and real user names would be a great improvement.
Although the allocation process in the system doesn’t actually work in the system, the allocation report
does produce a list of postgraduates suitable for each module based on skills. The method of allocation
in the current situation is manual with the allocation officer choosing the postgraduates for the
modules. That was what was intended for the system, a manual process based on skills possessed and
requested. However in a future expansion instead of just skills other factors could also be taken into
account. These could include dates of tasks, postgraduate unavailability dates and preferences. Now
this is a very complex method for a manual allocation and could be made even more complex making
use of the skill experience and enjoyment. One method of performing the allocation would be to turn it
from a manual allocation into an automatic scheduling algorithm. Winston (1991) describes many
different types of algorithms.
45
References:
Ainsworth, J (2004) ‘SIS introduction’
http://www.comp.leeds.ac.uk/internal/sis/ [18th April 2005]
Almstrum, V (1998) ‘V & V Plan Information’
http://www.cs.utexas.edu/users/almstrum/classes/cs373/fall98/doc-stds/VVP-info.html [20th April
2005]
Beauchemin (2000) ‘Software development life cycle models’,
http://www.csd.uwo.ca/courses/CS377b/CS377-Development.html [5th April 2005]
Boehm, B (1998) ‘A Spiral Model of Software Development and Enhancement’ Computer, May 1988
(Vol. 21, No. 5), pp. 61-72.
Checkland, P & Scholes, J. (1990) ‘Soft Systems Methodologies in Action’, Wiley
Couprie et al (2004) ‘Soft systems Methodology’,
http://sern.ucalgary.ca/courses/seng/613/F97/grp4/ssmfinal.html [5th April 2005]
Elmasri, R & Navathe, S (2000) ‘Fundamentals of database systems’, third edition, Addison-Wesley
Emprend inc. (2005) ‘Testing Techniques’
http://www.projectconnections.com/knowhow/kb_contents/skills/testtech.html [20th April 2005]
Eva, M (2004) ‘Soft systems Methodology’,
http://www.acca.org.uk/publications/studentaccountant/1073535 [5th April 2005]
Guelich et al (2000) ‘CGI Programming’, second edition, O’reilly
Holding, H (2000), ‘Mastering Database Design’, Macmillan
Jarvis, C (2004) BOLA: CATWOE and Soft Systems Methodology
http://www.brunel.ac.uk/~bustcfj/bola/research/ssm.html [5th April 2005]
Kremer, R (2001) ‘Soft systems Methodology’
http://sern.ucalgary.ca/~bowen/613/report/#stagesRichPicture [5th April 2005]
46
Martin et al (2003) ‘A Simple Framework for the Evaluation of Business Multimedia products.’
http://www.ejise.com/volume6-issue2/issue2-art14.htm [21st April 2005]
Matravers, J (2003) ‘The Conception of an IS Project Introduction to Soft System Methodology
(SSM)’. IN11 lecture notes 4 and 5. The University of Leeds.
MySQL (2005) ‘Database server feature comparisons’
http://dev.mysql.com/tech-resources/crash-me.php?res_id=2051&brief=1 [6th April 2005]
Nielsen, J (2005), ‘Heuristics for user interface design’
http://www.useit.com/papers/heuristic/heuristic_list.html [11th April 2005]
Parker, R (1997) ‘Web Design & Desktop Publishing for Dummies’, IDG Books Worldwide
Patwardhan et al (2002) ‘Perl in a nutshell’, second edition, O’reilly
PostgreSQL (2005), PostgreSQL 7.3.9 Documentation
http://www.postgresql.org/docs/7.3/interactive/index.html [11th April 2005]
Refsnes Data (2005) ‘SQL Tutorial’
http://www.w3schools.com/sql/default.asp [6th April 2005]
Supremisitc (2005) ‘Software development methodologies’
http://www.supremistic.com/development-methodology.html [5th April 2005]
Teorey, T.J. (1990) ‘Database Modelling and Design’, Morgan Kaufmann
Vita Voom (2004) ‘PostgreSQL comparisons’
http://www.vitavoom.com/postgresql.html [6th April 2005]
Winston, W (1991) ‘Operations research: applications and algorithms’, second edition, Pws-Kent
47
Appendices
Appendix A -Reflection
Having finally completed my project I can now reflect on the entire process. I believe the project to
have been very challenging. It was a brand new experience for me; I have never undertaken anything
before that requires so much time and work. Although I have found it hard work it has also been very
rewarding and I feel enormous pride on completion for having achieved so much. It has required
making use of existing computer skills as well as learning new ones. I feel this experience has
benefited me by producing new abilities I will be able to call on in later life.
The selection of the project was one that required a lot of time and consideration. I knew my forte lay
in databases so it made sense to base my choice on this. It was after meeting with Stuart Roberts that a
final choice was made. To me the project description chosen seemed both interesting and challenging
and I felt I could really do something with it.
Although I knew the project was going to be time consuming I didn’t realise just how much.
Fortunately I had chosen my modules for my final year so that the majority were undertaken in the
first semester leaving me more time to work on my project in the second semester. This is advice I
would strongly recommend to any future students undertaking a final year project.
Another lesson I have learnt is to try to stick to what you know best and not to take too much on.
If the project does require learning new skills try to leave adequate time to learn to apply them. This
was my main mistake, trying to learn perl CGI and PostgreSQL when I had never touched on either
before. Although I had reasons for doing so, I don’t think the reasons justify the work that was not
completed. If I were to do the project over again I would stick to a database management system I had
used before and a computer language that I had at least had experience in
Starting the project was the hardest part and I would advise any future student to plan their progress
carefully by setting deadlines that are realistic and achievable. Understanding the problem exactly and
getting the requirements early is essential as it will leave more time to work on the actual system.
Finishing the system early will leave time for testing and improvements and hopefully another
implementation. So it is highly recommended that a good methodology that suits the project is
selected.
Timing is essential as it soon runs out leaving you with too much work and not enough time to
complete it in. There is a lot of man hours required but I would advise future students not to neglect
48
their other coursework and exams in favour of the project. Time management is an essential skill that I
wish I put to better use; it would have definitely reduced the stress in the last few weeks.
Although my solution is not fully working and doesn’t meet all the user requirements I have to
remember it is only a prototype and that I was never expected to produce a fully implemented system.
Overall I have really enjoyed the project, I am proud of what I have achieved and what I can do when I
really put my mind to it. I’m sure that if I were to undertake a project of this size again I would learn
from the mistakes I have made in this one.
49
Appendix B – original time schedule
Aim and minimum
requirements
Mid
Progress
Final Project
meeting
report
report
Preference form
Weeks
project
1
2
3
4
5
6
7
8
9
10
11
Christmas
Exams
1
2
3
4
5
6
7
8
Easter
9
10
Deadlines
Draft chapter and table
of contents
Gather requirements
Requirements analysis
Review current method
Background reading
Research into
methodologies
Mid project report
Model using diagrams (ER)
Design database
Implement database
Design Interface
Implement interface
Design reports
Implement reports
Show prototype to main
users
Make changes
Testing
Evaluation
Write up
A
waterfall
method
will be
used here,
leaving
time for at
least one
iteration.
50
Appendix C –actual time schedule
Weeks
1
2
3
4
5
6
7
8
9
10
11
Christmas
Deadlines
Gather requirements
Requirements analysis
Review current method
Background reading
Research into
methodologies
Mid project report
Model using diagrams (ER)
Design database
Implement database
Design Interface
Implement interface
Design reports
Implement reports
Testing
Evaluation
Write up
51
Exams
1
2
3
4
5
6
7
8
Easter
9
10
Appendix D – Postgraduate request form
52
Appendix E – work allocation form
53
Appendix F – payment claim form
54
Appendix G – screenshots
55
56