29
Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Embed Size (px)

Citation preview

Page 1: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Programme

Specification,

Benchmarks etc.Warren Houghton

School of Engineering and Computer Science,

University of Exeter

Page 2: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Context of examples

• University of Exeter

– mid ranking “old” university

– “research lead”

• Department of Engineering

– in School of Engineering and Computer Science

– small general engineering department

– 26 full time academic staff

– approx 400 U/G students

Page 3: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Context of examples

3-yrgeneral

BSc

3-yr BEngaccredited

Ele

ctro

nic

Mech

an

ica

l Civ

il

En

g.

&

Man

ag

em

en

t

4-yr MEngaccredited

Ele

ctro

nic

Mech

an

ica

l Civ

il

En

g.

& M

an

Common first year

Page 4: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Constructive Alignment

IntendedLearning

Outcomes

LearningActivities

Assessmentmethods and

criteria

John Biggs: Teaching for Quality Learning at University, Society for Research into Higher Education and Open University Press 1999

Page 5: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

How we wrote Programme Specifications

1. Put Subject Benchmark Statement to one side !

2. Wrote aims and ILOs for existing programmes

– many iterations - emergent outcomes

3. Wrote aims and ILOs for existing modules

– many iterations

– drawing out what staff were already doing

4. Then, checked against Benchmark Statements etc.

5. Did not try to achieve one-to-one mapping

Page 6: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Why not use Benchmark Statements as “blueprints”?

• What authority should we give the Benchmark

Statements ?

– What does the QAA say ?

• Is there a “correct answer” ?

• How can we obtain a set of required ILOs ?

– From industry?

• Do we have to take responsibility, with our own

ideas?

Page 7: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

William Perry’s positions:

1. Absolute right answers are provided by Authority.

2. Authority may make us find his absolute right answers ourselves.

3. Authority may not have found all the absolute right answers – yet . . .

4. Anyone has a right to his own opinion, but better keep Authority happy.

5. Everything is relative.

6. I may have to make some decisions for myself.

7. I must commit myself to a viewpoint.

8. I must take responsibility for what I commit to.

9. I am confident in my personal commitment, but I will keep an open mind.

Page 8: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

What position do we take ?What position do we take ?

1. Absolute right answers are provided by Authority.

2. Authority may make us find his absolute right answers ourselves.

3. Authority may not have found all the absolute right answers – yet . . .

4. Anyone has a right to his own opinion, but better keep Authority happy.

5. Everything is relative.

6. I may have to make some decisions for myself.

7. I must commit myself to a viewpoint.

8. I must take responsibility for what I commit to.

9. I am confident in my personal commitment, but I will keep an open mind.

Page 9: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

What position are we encouraged to take ?What position are we encouraged to take ?

1. Absolute right answers are provided by Authority.

2. Authority may make us find his absolute right answers ourselves.

3. Authority may not have found all the absolute right answers – yet . . .

4. Anyone has a right to his own opinion, but better keep Authority happy.

5. Everything is relative.

6. I may have to make some decisions for myself.

7. I must commit myself to a viewpoint.

8. I must take responsibility for what I commit to.

9. I am confident in my personal commitment, but I will keep an open mind.

Page 10: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

• NOT as some definitive “right answer”

• We have to take responsibility for creating/recreating the curriculum

– drawing on

– our own experience

– others’ experience - set out in benchmarks etc.

• an iterative, reflective, process

How should we use benchmarks?

Page 11: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Curriculum developmentCurriculum development

Emergent Emergent outcomesoutcomes

Rewrite ProgrammeSpecification

Implement changes

Read availableliterature.

Benchmark Statements etc.

Contribute tonational discussion

Compare curriculum with Benchmark Statements etc.

Articulate currentaims, ILOs etc.

Curriculum experienced by teachers and students

Page 12: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Threshold standards

Page 13: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Threshold standards

• benchmarking implies . . .

• all graduates will meet all threshold

standards

• we need to show how

• we may have to change our assessment

• QAA(2000) Engineering Benchmark Statement.

Page 14: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

The EPC Engineering Graduate Standard

26 “ability to” statements under 7 headings

Ability to

• exercise Key Skills . . .

• transform existing systems into conceptual models

• transform conceptual models into determinable models

• use determinable models to obtain system specifications . . .

• select optimum specifications and create physical models

• apply results from physical models to create real target systems

• critically review real target systems and personal performance

Page 15: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

The EPC Engineering Graduate Standard

“The A2 statements set out what all engineering graduates should be able to do and the intention is that graduates should be able to provide evidence of all 25 abilities to a greater or lesser extent - there are no options or choices.”

Page 16: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Threshold standards

• Effective/easy in training (e.g. the Royal Navy)

• Different in HE – why?

– “Education and training are different”

– Is certification realistic / useable ?

• PDP offers a solution to both problems

Page 17: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Example:

setting and assessing threshold setting and assessing threshold standards in core academic modulesstandards in core academic modules

in Engineering at Exeter

Page 18: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Traditional examination

• 3 hr paper

• Choose 5 out of 8 questions

• Pass mark 40%

• Pass provides evidence of 25% of ILOs tested

• But which 25% ?

• What can we build further learning on ?

Page 19: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

• define detailed ILOs/assessment criteria . . .

• For all 1st and 2nd year engineering modules

Page 20: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Module specification – A/B structureDETAILED LEARNING OUTCOMES / ASSESSMENT CRITERIA

List A comprises core outcomes that will be covered fully in lectures and must be achieved by all students to meet the minimum requirement for progression.

List B comprises outcomes that are EITHER more difficult to achieve OR are to be achieved by private study (or both).

A: THRESHOLD LEVEL B: GOOD TO EXCELLENT

.

.Apply nodal analysis, with step by step prompting, to 2 loop circuits....

.

.Apply nodal analysis, without guidance or prompting, to 2 and 3 loop circuits. ..

Page 21: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Assessment - examinations

• Paper A: – Covering list A ILOs only

– Typically, short straightforward questions

– No choice

– Expected mark >80%

– Criteria referenced

• Paper B– All ILOs, and some choice

– Longer, more challenging questions with no “easy” parts

– Expected average < 40%

Page 22: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Doesn’t this approach mean

that we are blatantly

teaching to the examination?

Yes !Yes !

Page 23: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Development

• Accepted because of PEI accreditation

– evidence that students with different marks

had achieved identifiably different learning

outcomes

• Originally developed as part of a

scheme to give better guidance to

students

Page 24: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Impact on staff

• Staff find it hard to split ILOs this way

BUT

• asking for differentiated ILOs seems to

work better than just asking for single

level ILOs

Page 25: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Realism

• Any test is demanding when the pass

mark is 80%

• If we are genuinely going to test all ILOs

they must be achievable.

• We have to be honest.

Page 26: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Deep vs. surface learning

• Are we encouraging surface learning?

• Other factors enable deep learning . . .

• Consider structure of the learning (noun)

– Hierarchy of concepts

• What happens if students try to understand complex concepts when they haven’t grasped the components?

• A/B approach makes deep learning possible

Page 27: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

a problem

• of success ?

Page 28: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

Supporting students

• A/B split originally introduced for student guidance

• students asked to identify progress against ILOs on weekly basis

• now whole of 1st year

• ILOs are a prerequisite to PDP

Page 29: Programme Specification, Benchmarks etc. Warren Houghton School of Engineering and Computer Science, University of Exeter

How do we achieve alignment of:

with

How academic staff think about

research in their disciplines

How academic staff approach

curriculum development

withHow we want

academic staff to approach curriculum

development

How academic staff are managed

?