JISC Final Report

hamburgerfensuckedSecurity

Nov 20, 2013 (3 years and 7 months ago)

69 views

Project
hashtag:

ExamView

Version:

1.1

Contact:

Jen Fuller

Date:

31/01/11


Document title:
JISC Final Report Template







Page
1

of
18

Template version: v6.0


August 2010


JISC Final Report


Project Information

Project Hashtag

ExamView

Project Title


ExamView: Integrating key student systems with the VLE

Project Acronym

ExamView

Start Date

July 1
st

2010

End Date

Dec 31
st

2010

Lead Institution

City of Glasgow College

(formerly Glasgow Metropolitan College)

Project Director

Jennifer Louden

Pr
oject Manager

Jen Fuller

Contact email

jen.fuller@glasgowmet.ac.uk

Partner Institutions

None

Project Web URL

http://projects.glasgowmet.ac.uk/examview

Programme Name

03/10 JISC e
-
Learning Programme: Distributed VLE

A: Technical rapid innovation projects

Programme Manager

Sarah Davies


Document
Information

Author(s)

Jen Fuller

Project Role(s)

Project Manager

Date

31
st

Jan 2011

Filename

ExamView_
0310
r
eport_
final
.docx

URL

I
f
this report
is
on

your

project web site

Access

This report is for general dissemination


Document History

Version

Date

Comments

1.0

1
st

Dec 2010

1
st

draft


awaiting feedback from Programme Manager

1.1

31
st

Jan 201
1

Final report






Project
hashtag:

ExamView

Version:

1.1

Contact:

Jen Fuller

Date:

31/01/11


Document title:
JISC Final Report Template







Page
2

of
18

Template version: v6.0


August 2010

Table of Contents


1)

ACKNOWLEDGEMENTS

................................
................................
................................
......

3

2)

REPORT SUMMARY

................................
................................
................................
............

3

2.1

P
ROJECT
O
VERVIEW

................................
................................
................................
......................

3

2.2

P
ROJECT
O
UTPUTS

................................
................................
................................
........................

3

2.3

I
MPACT AND
B
ENEFITS TO THE
C
OMMUNITY

................................
................................
......................

3

2.4

M
AIN
L
ESSONS
L
EARNT

................................
................................
................................
..................

4

3)

MAIN BODY OF REPORT

................................
................................
................................
.....

5

3.1

W
HAT DID YOU DO
?

(M
ETHODOLOGY
)

................................
................................
.............................

5

Background

................................
................................
................................
................................
......

5

3.2

P
ROJECT
D
EVELOPMENT

................................
................................
................................
................

6

July


August 2010

................................
................................
................................
...........................

6

August


S
eptember 2010

................................
................................
................................
................

8

September


November 2010

................................
................................
................................
..........

8

November


December 2010

................................
................................
................................
...........

9

3.3

T
ECHNICAL
A
PPLICATION
D
EVELOPMENT

................................
................................
..........................

9

Possibilities for Data Integration

................................
................................
................................
.....

9

Option 1: Web service calls through Columbus

................................
................................
...............

9

Option 2: Scheduled export of data from UNITe

................................
................................
.............

9

Option 3: Querying Oracle directly

................................
................................
................................

10

Our Chosen Method(s)

................................
................................
................................
...................

10

3.4

W
HAT DID YOU LEARN
?

................................
................................
................................
...............

11

Project Management: a good example of rapid application development

................................
...

11

Technical Development: Use of formal specifications

................................
................................
...

11

3.5

I
MPACT

................................
................................
................................
................................
.....

12

Students

................................
................................
................................
................................
.........

12

Staff / Organisation

................................
................................
................................
.......................

12

Communit
y

................................
................................
................................
................................
.....

12

4)

CONCLUSIONS & RECOMM
ENDATIONS

................................
................................
............

13

5)

IMPLICATIONS FOR THE

FUTURE
................................
................................
.......................

13

6)

FURTHER READING

................................
................................
................................
..........

13

7)

APPENDICES

................................
................................
................................
....................

14

Appendix 1:
Model of Application Layers

................................
................................
......................

14

Appendix 2: Model of Application Tiers

................................
................................
.........................

15

Appendix 3: Student Evaluation Survey

................................
................................
.........................

16



Project
hashtag:

ExamView

Version:

1.1

Contact:

Jen Fuller

Date:

31/01/11


Document title:
JISC Final Report Template







Page
3

of
18

Template version: v6.0


August 2010

1)

Acknowledgements

This project was funded by t
he JISC e
-
Learning Programme: Distributed VLE. The project team would
like to thank Sarah Davies and Sheila MacNeill for their support

and feedback throughout the project
and Allan Forsyth for his assistance with the development of the application.


2)

Report
Summary

2.1

Project Overview

The aim of this ‘Technical Rapid Innovation’ project was to extend the functionality of the VLE by
linking it with the Student Records system. I
n particular this project focus
ed on the development of
the following block:




Vi
ew exam results
:

developing a ‘window’ onto

the

UNITe

Student Records system to allow
students to view their exam results once logged into Moodle.


It was anticipated that the block could be used by any institution using the same systems (Moodle,
UNITe
) a
nd that the community could use the underlying code to develop blocks relevant to their
own systems.

2.2

Project
Outputs



Application



Source code



User guides



Project documents and processes


The source code and related documentation
are

available to download from:




Project website:
http://projects.glasgowmet.ac.uk/examview/



Moodle.org:
http://moodle.org/mod/data/view.php
?id=6009

(search for “
ExamView
”)



Google Code:
http://code.google.com/p/examview/


2.3

Impact and
Benefits

to the Community

Benefits to students include:




Flexible access to live, personalised information (onli
ne, 24/7).



Single point of access (one username / password).



Having a clear overview of progress could prompt student to take quick remedial action.




Project
hashtag:

ExamView

Version:

1.1

Contact:

Jen Fuller

Date:

31/01/11


Document title:
JISC Final Report Template







Page
4

of
18

Template version: v6.0


August 2010

Benefits to staff / organisation include:




Encourage staff to input student resul
ts into Student Records

systems
.



More effective integration of systems.



Reduction in data entry and duplication of effort.



Increased student satisfaction (quicker return of results).


Benefits to community include:




Ability to share development process, code and user guides with the Moodle community.



Opportunity to use code to develop similar blocks, customised to other systems.


2.4

Main Lessons Learnt

The use of the Rapid Application Development methodology
, particularl
y time spent creating paper
-
based data models,

helped the team to interact with consultants and end users, and to respond to
changes, whilst still meeting tight deadlines.


A lack of familiarity with the Basic LTI or Widget specifications meant that they
were not used due to
the time constraints. However the application was developed in such a way that it would be easy to
apply them retrospectively, in a future iteration.


Developing the application

in an object oriented way

will make

it much easier for o
ther institutions
to use and adapt the source code.


Feedback on the use of the application from staff and students has so far been positive, with 80% of
students rating it as their top method to receive exam results information.


Further developments and

iterations are ongoing, based on feedback from staff, students and the
wider community.


Project
hashtag:

ExamView

Version:

1.1

Contact:

Jen Fuller

Date:

31/01/11


Document title:
JISC Final Report Template







Page
5

of
18

Template version: v6.0


August 2010


3)

Main Body of Report

3.1

What
did you do?

(Methodology)

Background

Currently when a student takes an assessment the lecturer will
give students their marks in a variety
of ways

(
depending on the lecturer
)
:




F
ace to face
,

in class or in a one
-
to
-
one feedback session
.



By
posting

p
rinted results

on notice
-
boards outside
class
.



...or students w
ait until the official awards letter is sent in the post.


As well as giving the st
udents feedback, t
he lecturer needs to type in their results to the Student
Records system so the award can be processed.


All of the above methods t
ake time, often involve

duplication of effort for staff and raise concerns
about privacy of information. A

solution was required that would provide students with
secure,
private

access to their
exam

results as quickly as possible, without placing a
n additional

burden on
staff.


One option considered was the promotion and use of the inbuilt VLE gradebook.

Lectur
ers could
type student results into the gradebook and within a matter of seconds the students w
ould be able
to see their marks,

privat
ely and from any location, 24/7. The main problem
with this approach was

that lecturers would still have to type in result
s to the Student Records system in order to process
the award. This would invo
lve duplication of effort and wa
s unlikely to be adopted by many staff.


A second option was considered


to build an application that would ‘pull in’ student results from
the St
udent Records system directly into the VLE.
This option offered several benefits:




Staff only have to type results into one system.



Students receive
their results quickly, privately and from any location 24/7.




Students are encouraged

to use the VLE

as a p
ortal of information.



Staff are encouraged to
type results into the Student Records system in a timely fashion.


Thanks to funding from the JISC DVLE programme the team were able to build
an

application for this
second option, called ‘ExamView’.

Project
hashtag:

ExamView

Version:

1.1

Contact:

Jen Fuller

Date:

31/01/11


Document title:
JISC Final Report Template







Page
6

of
18

Template version: v6.0


August 2010

3.2

Project
Development

The project used a Rapid Application Development (RAD) methodology which allowed us to develop
the application in a short period of time while still capturing user requirements and feedback.


RAD outcomes:




Define
user requirements



Map the appl
ication through

data models



Prototype the application

(g
ather user feedback

and r
efine
)



Develop the application

(gather user feedback and refine)



July


August 2010

In July 2010 the project began. A project blog


http://projects.glasgowmet.ac.uk/examview



was
set up to capture the
project process and log any thoughts, ideas, updates or developments.

Initial
meetings were held with the Student Records System Administrator to explore the Student R
ecords
database a
nd identify the fields holding the required results information
.

Time was spent
investigating the
Widget 1.0

and

IMS Basic Learning Tools Interoperability 1.0

specifications
.



As per the RAD process, the application was initially mapped out on paper, through a series of
preliminary data models (
below and in

Appendix
1
: Model of Application Layers

and
Appendix
2
:
Model of Application Tiers
).




The tiers
were identified.

Project
hashtag:

ExamView

Version:

1.1

Contact:

Jen Fuller

Date:

31/01/11


Document title:
JISC Final Report Template







Page
7

of
18

Template version: v6.0


August 2010





The tiers’

responsibilities were
mapped out
.

T
ier Name

Responsibilities

Comments

(pre
-
development)

Technical Platform

Presentation
Layer



Displaying exam results to the user.



Integrating into the chosen front
-
end system.



Providing a
username that can be
matched to the student records by
the Model
Layer.



Translating the u
sername to a user
ID
that can be used with the data
store on a 1:1 relationship.



Displaying feedback on results.

Both the presentation layer and
chosen front
-
end will have to be
trusted. The model layer trusts
everything given to it

by the
Presentation Layer, so any gaps
here could allow students to access
any other student
s’
records.



XHTML & CSS
front
-
end



PHP for code



Complying with
any

requirements
set by the front
-
end system

Model Layer



Interfacing with the data layer to
pull
records from it.



Converting records from the data
layer into a single recordset that can
be read by the front end.



Will have support for several
different back ends (unite,
plain mysql).



Configuration file will let users
set which kind of environment,
and

how to connect to it (IP
address, port, authentication)



PHP for cod
e



MySQL or another
ODBC

compatible
database for

the
user mapping


Data Layer

Providing exam results for a given
student.

Independent from
ExamView

system.
R
eturn
s

results in a format
that depends on the back
-
end
used.
Model layer translates.

Requires method of

connecting to
ExamView, usually
TCP/IP connectivity.




UML diagrams were drawn up, outlining the relationship between the application’s tiers and
the informa
tion to be passed between them.

Project
hashtag:

ExamView

Version:

1.1

Contact:

Jen Fuller

Date:

31/01/11


Document title:
JISC Final Report Template







Page
8

of
18

Template version: v6.0


August 2010


August


September 2010

Following the next steps in the RAD methodology, a simple paper
-
based prototype of application’s
user interface

was designed

and
shown to student pilot groups for evaluation. Feedback was positive
b
ut suggested

that the application should display
all

exam results from their time at the College, not
just those from
a

current course
/

year.
D
iagrams and models were updated to reflect this
change
.




September


November

2010

Alex Walker

then
worked with external consultant Allan Forsyth to code and develop the application
layers. Alex brought extensive knowledge and experience of the front end (Moodle) while Allan
brought extensive knowledge and experience of the
databases and
UNITe

in particular
.


Project
hashtag:

ExamView

Version:

1.1

Contact:

Jen Fuller

Date:

31/01/11


Document title:
JISC Final Report Template







Page
9

of
18

Template version: v6.0


August 2010

Building on the data models created in the early stages of the RAD process, each tier was coded i
n a
standards based format with extensive comments to support any future developments /
customisations once released to the developer communi
ty.
Once complete the

application was
installed on a

front end


(
test
Mo
odle

site
)

and fully tested to ensure the correct information was
being passed through and that there were no performance or security issues.


T
ime
was then spent
c
ustomising
how the

information was

displayed to users.
Responding to
feedback from within the team, the arrangement of information on the ‘front end’ was refined from
the original prototype to better suit Moodle’s layout
.




The application was

tested across a range of bro
wsers

/
platforms to ensure that
i
t display
ed

consistent
ly
.

November


December 2010

Extensive user guides were written to accompany the code, including information on how to adapt
the code to suit various systems / databases.

The code and accompanying use
r guides were then
packaged and uploaded to developer communities on
Code.Google.com

and Moodle.org (and made
available on the project blog).


A
ll lecturers were sent an email an
nounc
ing

the release of ExamView

and a news item was
posted
on the front page
of Moodle. This was accompanied by a link to a short survey, asking students to
give feedback on the application
(see

Appendix 3
: Student Evaluation
Survey
)
.


3.3

Technical
Application

Development

Possibilities for Data Integration

When deciding the best way to develop the application
each option was

considered

on two levels:
which option would best

retrieve the data from our own student records system
(UNITe)
and
wh
ich
option would b
e most portable and
retrieve data from

other institutions’
systems

(unknown).


Option 1: Web service calls through Columbus

Building
the
application with UNITe
in mind,
one option was to query Columbus,
a web
-
based
interface to UNITe
. To do this

we would have written a custom report
to query

Columbus us
ing

an
available
information exchange protocol

e.g. SOAP.


Project
hashtag:

ExamView

Version:

1.1

Contact:

Jen Fuller

Date:

31/01/11


Document title:
JISC Final Report Template







Page
10

of
18

Template version: v6.0


August 2010

This option would have been difficult and costly to set up. Because Columbus is proprietary software
institutional
web developers
would need training / support from Capita (UNITe’s author) to develop

a custom report.

Also, Columbus is not a standard compon
ent of UNITe (it requires an additional
license) so many institutions may not use it, even if they have UNITe.


T
his option was very much tied to the use of Columbus + UNITe, making it the least portable of the
three options considered. For these reasons t
his option was discarded.


Option 2: Scheduled export of data from UNITe

Again

with UNITe in mind, we explored the option of creating (what it

calls
)

‘data warehouse
s
’:
database
quer
ies

that can be scheduled to run at
regular
intervals and output
resultant
data

to a CSV

file
.

Th
e

CSV file
data
would then be exported into a
n intermediate data store

(e.g. a MySQL
database)
that could be queried by ExamView
whenever a student logs on to check their results.


The main advantage

of this option
is that
queries

from the application

will hit the intermediate data

store
and never reach UNITe.
T
h
u
s

during
periods of high demand (thousands of students checking
exam results at the same time)

UNITe is in no danger
of slowing down or crashing
.


However
this

opt
ion
also has a number of

disadvantage
s:




UNITe’s
‘data warehouses’ can only output data in a CSV format
, requiring an additional step
to transfer the data into a format which c
an

be queried.



A
lthough the export from UNITe
>

CSV
>

MySQL can be automated, th
is extra
step
is one
more place
where
things could go wrong.



There were concerns in h
ousing confidential

student

data in a
n intermediate

database
which
may not be
as secure as the student records system.



S
tudents
would not

see
their
live results
;

queries from ExamView to the intermediate data
store

would only return data
from

the last export.


Option 3: Querying Oracle directly

Building
on discussions for options 1 and 2, the project team discussed “cutting out the middle man”
and
querying UNITe’s

Oracle
database directly.
There were a number of advantages to this option:




It
would be relatively easy to implement. All
you

need is permission to access the Oracle
database and a query that gives
ExamView the correct data.



Queries will return live data
. As soon as exam results are entered into UNITe, students will
be able to see them with no delay.



The database query written
can be used with any

UNITe

Oracle database. Any
Oracle
database

can use this ‘back end’ with a new query
.



Creating database querie
s is a standard skill for web developers

therefore institutions could
create queries for their own systems (if other than Oracle).


Project
hashtag:

ExamView

Version:

1.1

Contact:

Jen Fuller

Date:

31/01/11


Document title:
JISC Final Report Template







Page
11

of
18

Template version: v6.0


August 2010

The main advantage of this option is also its main disadvantage however


querying the student
records database directly giv
es students live access to their results but could potentially put a heavy
load on the system if a large volume of simultaneous queries

are

made.


Our Chosen Method(s)

We were quickly able to discount the first method, for the reasons already mentioned
,
but both
options 2 and 3

had strong advantages
:




Option 2
prevents the student records database from being overwhelmed with requests, but
does not display live results and has potential security issues.



Option 3 displays live results directly from the stud
ent records database but large volumes
of requests could cause the system to slow during peak periods.


Although it was not possible to run load testing on UNITe (because it is a live, central system) the
team were satisfied that there would be no performa
nce issues
because
:




Relational databases such as Oracle are built to handle large volumes of queries efficiently.



The College’s Oracle database is on a dedicated, robust, high performance server.



The size of data
per average query is small (less than
1
00k
b).


If the exceptional circumstance occurred where thousands of requests were made to ExamView
simultaneously, it is much more likely that the load would cause performance issues with the ‘front
end’ (i.e. Moodle) before eve
r

reaching the ‘back end’ (UNIT
e).


Upon w
eighing up the options and discussin
g them

with Allan Forsyth the project team agreed that
option 3 was the best for the College’s implementation of ExamView

and a

‘back end’ querying
UNITe’s Oracle database was written.


However
, because the
work involved in both
o
ption
s

2 and
3

overlapped,
the team were also able to
write a ‘back end’ querying a MySQL database
with little duplication of effort.

This has been bundled
with the final application for any institutions wishing to use option 2, or i
ndeed if there student
records system runs off of MySQL.
This is a testament to the
flexibility of the ExamView
architecture
and
one of the reasons why
ExamView
was built in this object oriented

way.


3.4

What did you learn?

Project Management
:
a good example
of rapid application development

The team found the Rapid Application Development methodology to be very useful in managing a
short
-
life
, singl
e
-
focus development project. In particular, t
ime spent creating
data

models

and
wireframes
at the start of the pr
oject allowed the team to:


Project
hashtag:

ExamView

Version:

1.1

Contact:

Jen Fuller

Date:

31/01/11


Document title:
JISC Final Report Template







Page
12

of
18

Template version: v6.0


August 2010



Identify exactly how the application tiers would interact and the information that needed to
be passed on to each one.



Use the models as a basis for discussion with external consultants, the Student Records
system admin and other
key stakeholders
.



Respond to changes to the application structure effectively and gracefully without wasted
effort coding.



Code the application i
n an object
-
oriented way,
using

the tiers / interactions identified in the
paper
-
based models

as a framework for development
.


For future
iterations

of
ExamView

the team would continue to

use

the RAD

methodology
.


Technical Development
: Use of formal speci
fications

Given the tight deadlines and short development iterations, there were limitations on what we could
accomplish in the time frame. While we have our extensible architecture and detailed specification,
the
ExamView

package does not conform to eithe
r the IMS Basic LTI or the W3C widget
specification. If we wanted to extend
ExamView

to conform to one of the specifications, we would
choose the IMS Basic LTI specification. This specification makes the most sense given the
requirements of the project and the intended user demographic.


Writing
ExamView

to conform to the Basic LTI specif
ication would not need an entire rewrite of the
project. It would simply involve writing a new front
-
end that conforms to the
ExamView

specification
at the tool end, and conforms to the LTI specification and accepts requests at the other end. Given
the arc
hitecture of
ExamView
, it would be fairly simple to implement this at any time.

Given the in
-
house development experience, the architecture we had planned and our development
methodologies, we felt that the current revision of
ExamView

is one that is simpl
e to extend and
works well.


3.5

Impact

Students

Students had the opportunity to complete a quick survey on ExamView (see
Appendix 3
: Student
Evaluation
Survey
) and a fo
cus group was held with three of the four pilot groups (the fourth being
cancelled due to low turnout).


All students in the focus groups expressed that they like the new ExamView feature in Moodle
. This
is reinforced in the survey where they rated it as t
heir
top choice for receiving exam results
(80%,
32), significantly
more than
by email,
face to face or post.


ExamView is already having a positive impact on the student experience
-

i
n the focus groups
students noted that having all their results listed
online
was particularly helpful when completing
their
online
UCAS applications to progress to University (also commented on in the survey).


Project
hashtag:

ExamView

Version:

1.1

Contact:

Jen Fuller

Date:

31/01/11


Document title:
JISC Final Report Template







Page
13

of
18

Template version: v6.0


August 2010

Staff

/ Organisation

Staff were also impressed with the ExamView feature and
one group of staff said that they
now
planned to change their method of giving exam results from a paper card to ExamView
, especially as
it can be accessed from home during the holiday period
.


Unfortunately the project period does not cover the end of year when all of the exam results are
pub
lished
,

so it is not possible to tell whether ExamView encourages staff to input results more
timeously into the student records system. However
the

surv
ey results suggest
that
s
tudents are
already applying group pressure on staff to i
nput results

quickly
:




Some of the units haven't got a result. I would suggest to put a feature on
there that allows us to request our tutors to put the result up on to it.


(see
Appendix 3
: Student Evaluation
Survey
)


Community

Upon completion of the ExamView application the code and extensive documentation was released
to the community (see
2.2. Project Outputs
)
. Enqu
iries have already been received from a number
of
institutions world
-
wide on how to use the application with their own systems
. Although we cannot
offer technical support to these institutions we have responded to each enquiry with as much detail
as possib
le.


4)

Conclusions

& Recommendations


The Exam View application was a rapid development project which had a single purpose


to make
better use of the data gathered in the Student Records system by ‘pulling in’ student results to the
VLE. The application has

been used by staff and students and has received positive feedback.


The use of data models to discuss and plan the code developments, gave the team a basis of
discussion and allowed the team to respond to change requests, without wasting time spent codin
g.
This kept the development agile and iterative while still meeting short project deadlines.


Due to the short deadlines and lack of familiarity within the team of the
Basic LTI
and

Widget
specifications
, these were not used, however could be developed in

the future.


5)

Implications

for the future

The scope of this project was to build a simple read
-
only application that passed data between two
systems. This was completed successfully and has, to date, received positive feedback from staff and
students alike
. However there are opportunities to further develop the application in the future:




Develop read / write functionality
. Staff input results into ExamView and they are written to
the student records database. Staff and students only ever have to login to
one system.



As above but with a different front end
, e
.g. the VLE gradebook.

The gradebook becomes a
‘one stop shop’ for
inputting and receiving
results and feedback.

Project
hashtag:

ExamView

Version:

1.1

Contact:

Jen Fuller

Date:

31/01/11


Document title:
JISC Final Report Template







Page
14

of
18

Template version: v6.0


August 2010



Include feedback.

In the evaluation of ExamView students noted that they would like to se
e
feedback from staff as well as results. Although feedback is not currently logged in the
student records system this may be possible with the second option.



Other
. The code has been uploaded to community developer sites to promote new
developments / disc
ussions.


The code was developed in an object oriented way to allow for easy customisation and development
of new applications

and t
he project team have already been contacted and answered enquiries
about the application.



The application will be properly

used at the end of the academic year when the majority of exam
results are input.

Over the next six months (and before the end of year) the project team will
promote the use
of the feature to staff and students as the main way in which to give / receive
r
esults.

6)

Further Reading

IMS Global Learning Consortium (2010)
Basic Learning Tools Interoperability

[online]. Available from
http://www.imsglobal.org/lti/index.html

[last accessed 31st Jan 2011].

W3C
(2010),
Widget Packaging & Configuration

[online]. Available from
http://www.w3.org/TR/widgets/

[last accessed 31
st

Jan 2011].

Wikipedia (2011)
Rapid Application Development

[online]. Available from
http://en.wikipedia.org/wiki/Rapid_application_development

[last accessed 31st Jan 2011].

Project
hashtag
:

Version:

Contact:

Date:

Page
15

of
18

Document title: JISC Final Report Template

Template version: v6.0


August 2010


7)

Appendices

Appendix
1
: Model of Application Layers




Project
hashtag
:

Version:

Contact:

Date:

Page
16

of
18

Document title: JISC Final Report Template

Template version: v6.0


August 2010


Appendix
2
: Model of Application Tiers



Project
hashtag:

ExamView

Version:

1.1

Contact:

Jen Fuller

Date:

31/01/11


Document title:
JISC Final Report Template







Page
17

of
18

Template version: v6.0


August 2010

Appendix 3
: Student Evaluation
Survey



Project
hashtag:

ExamView

Version:

1.1

Contact:

Jen Fuller

Date:

31/01/11


Document title:
JISC Final Report Template







Page
18

of
18

Template version: v6.0


August 2010