Database Disciplinary Commons (2009-2010)
Dr Leslie Ball: University of Abertay Dundee
1. CONTEXT
Aim: To position the module and tutor within the course and institute
The University of Abertay Dundee is a post-1992 university and has a modern outlook on education. It is perhaps best known for its launching of the first Computer Games courses and has a growing reputation for innovation in delivering new courses. Until recently there were 4 Schools (Social & Health Sciences, Dundee Business, Contemporary Sciences and Computing and Creative Technologies (CCT)). CCT has last year split into the Institute of Arts, Media and Games and the School of Computing and Engineering Systems (CES). Masters courses within CES are Information Technology, Internet Computing, Ethical Hacking and Computer Security, Adaptive Systems and Intelligence and Security Informatics. The demographic population is broad-ranging on the masters courses with emphasis moving more towards the international market and links into research activity aligned with the University’s Strategic Plan.
The first round of the Commons was really quite revealing to learn how people had got into teaching. My own was a circuitous route through commercial industry, two first degrees, a PhD and a post-doctoral position before becoming an academic at the University of Abertay Dundee. My own under-graduate degree never demanded presentation skills and I was convinced that I would never be able to do that. The PhD, on the other hand, did demand these skills and I found myself giving my first presentation to an international audience in Tripoli, Libya with a wooden pointer that must have been at least 3 metres! It was terrifying and exhilarating and ultimately indelible in my memory. It was also undoubtedly a step towards the teaching profession even if I did not know it at the time.
I have developed databases in industry with well known enterprises such as Peat Marwick Mitchell and Shell UK. The latter particularly drew me towards my PhD in Petroleum Engineering and on to a post-doctoral position sponsored by the Oil industry. I was asked to do a small amount of teaching during this time at the University of Bristol and this eventually sowed the seed to becoming a full-time academic. I am glad I entered into the profession at a more mature age as I feel stronger for the experiences that underpin the teaching of the subject.
“It is that feeling of apprehension all too familiar at the beginning of another term. A new ship has just docked and I have little idea who is on it (or who might jump off it). Am I ready? ‘Oh my goodness, I’ve got so much to do, but don’t worry, you always get through it’, I tell myself.”
The above is an internally felt quote representing a professional rhythm and a personal set of emotions at the beginning of a new academic year. Much of what underpins this somewhat emotive expression is presented in the text of “Folk Pedagogy” (J. Bruner (1997), The Culture of Education, chapter 2). In particular, the following excerpts are chosen as they strike a chord with the personal experience of teaching:
1“Do you work harder with the not-so-bright or ignore them?”
2“Beliefs and assumptions about teaching …. are a direct reflection of the beliefs and assumptions the teacher holds about the learner”
3“Teachers …. adjust teaching to the backgrounds, abilities, styles and interests ……”
4“…. the varied way in which teaching occurs in different cultures. The variety is stunning”
5“What about group discussion as a way of creating knowledge rather than merely finding who has what knowledge?”
6“….. these are what may determine the educational practices that take place in classrooms in different cultural contexts”
7“demonstrating ‘how to’ and providing practice at doing so is known not to be enough ………. as when one learns by a combination of practice and conceptual explanation”
Embedded within each of these is what might be described as a cognitive artifact based on ones own experience and self-reflection. Words such as guilt1, perception2, professionalism3, diversity4, facilitation5, adaptation6 and innovation7 map directly to each of these excerpts and form the basis in some sense for a framework of reflective practice.
1.3 The Module and the Students
The focus for this portfolio is on a level 9 under-graduate Database Design and Implementation module (SA0951A) taught to a post-graduate cohort undertaking the PgDip/MSc in Information Technology. The module is one of six that are core to the programme with two additional module options in semester 2. The student must pass the PgDip and a masters proposal before proceeding onto the MSc Dissertation. Professional involvement in the module has been ongoing since 2000 and there have been many administrative changes since. It is, however, the dynamic of the changing population of the module that has offered the most significant challenges. The number of students taking the module at the onset of the new millennium was in excess of 100, whereas now there are on average around 20% of that number. More striking is the demographic (represented solely by name) of the student population as illustrated in Table 1. There has been an obvious shift from a largely British cohort to an international enrollment, where the Chinese students account for around 65% currently.
1.4 Teaching and Learning Environment
The module is co-delivered as a single module in the first semester of the PgDipIT and feeds into a second database module the following semester. The two are in sharp contrast in that the module represented here is technical and the second is largely student-led and research-based. The rationale of the module in focus is that it should equip the student with the knowledge to enter directly into the commercial database industry, while the rationale in the delivery is to align the module with the two central themes of database design and database implementation (SQL, PL/SQL). Figure 1 is customarily used to instill into the students the value of what is being taught and that mastery of the SQL skill alone could open the door to an IT career. As an artifact, SQL sits consistently and proudly at the top of the league of skills sought by the IT industry (note the relative proportions hold in the wake of the economic recession in 2008)
Q4 2008 |
Q4 2007 |
|
3,532 |
7,828 |
|
2,222 |
5,413 |
|
1,763 |
3,942 |
|
1,626 |
3,747 |
|
1,546 |
3,700 |
|
1,445 |
3,968 |
|
1,358 |
3,238 |
|
SAP |
1,271 |
3,047 |
Microsoft office |
1,248 |
2,531 |
1,184 |
2,748 |
|
Unix |
989 |
2,694 |
Access |
932 |
1,606 |
HTML |
861 |
2,033 |
WIN XP |
832 |
2,136 |
772 |
1,773 |
|
Microsoft exchange |
767 |
1,522 |
Javascript |
757 |
1,569 |
XML |
754 |
2,050 |
703 |
1,760 |
|
669 |
1,321 |
Figure 1: The Top 20 IT skills sought in Industry as reported in Computer Weekly http://www.computerweekly.com/Articles/2009/01/22/234351/UK39s-top-20-most-wanted-IT-skills-for-contractors.htm
The lecture theatre used for the module is tiered and equipped with state of the art Smartboard technology (Figure 2). This lends itself well to interactivity and the concept of the lectorial, rather than the conventional passive learning mode. There is a piano behind the lecturer, which will feature in the delivery section.
|
|
Figure 2: Lecture theatre room 3004 with SmartBoard and projector facilities.
The laboratory used for SQL teaching holds 50 students and is well designed for access and “show and tell” facilities, with 3 screens and projectors (Figure 3 left).
|
|
Figure 3: The teaching lab is on the left and the “thinking” room is on the right.
The three screens (the one nearest camera is not shown) allow each student close viewing access. The lecturer can thus use the central PC screen (shown centrally in Figure 3 left as a podium against the wall) without having to traverse the whole room. More care is necessary regarding the use of the voice as the room is long and so it is customary to rotate the head when speaking in order to reach all corners of the room and to instill “inclusiveness”. Organisation and co-delivery normally take place at the “thinking” table (Figure 3 right). This typically involves setting the schedule at the beginning of the semester and the allocation of resources each week. It is essentially where the process starts, waxes, wanes and ends.
1.5 Teaching Philosophy and Historic Artifacts
You remember a good teacher. It was the mathematics teacher at secondary school and the author has left her a personal thank you on FriendsReunited. Her methods were clear. In particular she had a “rubbish-heap-blackboard” from which one should never copy. At university the Statistics lecturer contemplated his next words while looking out the window watching the Isle of Man ferry dock in Liverpool. He was likeable and “cared” about us. These styles were different, perhaps eccentric, but effective for me. As an academic at the University of Abertay Dundee for ten years, database teaching has always been core. During this time students have said things like “How do you stay enthusiastic about such a dry subject?” and “How can you teach this stuff year after year without getting bored?” Reflecting on these and other issues has led to the adoption of certain teaching characteristics below:
1 Industrial background and anecdotal story-telling
2 Energy and enthusiasm
3 Humour and fun
4 Interactivity and feedback
5 Enquiry-led perspective
6 Empowerment
7 Question, don’t tell
8 Sharing in teaching and learning
9 Clarity in oral and written communication
These characteristics are not independent but rather intertwined. For instance, use of industrial experience comes through anecdotal references, professional practice and an appropriate dose of associated and ad-lib humour! The term “abnormal” is used for databases inherited in industry that have imparted no Normal Form whatsoever. This light touch encourages engagement and interactivity and perhaps makes the students feel more “connected”. Interactivity is key to tutorials and where the ‘real’ learning occurs. Each student is expected to lead their own enquiry into materials and empowerment comes from expressing and sharing this knowledge in group tutorial discussions. The teaching approach is to elicit response through probing rather than offering solutions readily.
All of these characteristics sit within the context of the pedagogical excerpts outlined in section 1.2.
Aim: To teach the most relevant materials and transferrable skills for database technology.
2.1 Module Overview
Database modules were my entry point into the academic profession and their content has oscillated over the past ten years according to the level, perceived student interest and considered relevance. In this level 9 module the materials have stabilized into a set of core topics and are delivered currently to a post-graduate cohort only. The core topics are Relational modeling, Entity Relationship modeling and mapping, normalization, SQL and procedural SQL. Some database topics have attained a “legacy” status including relational algebra (a topic I enjoyed personally but which was deemed less useful by the student population), other data models and the database development lifecycle. Other topics have never been included such as the implementation of concurrency and distributed architectures, security and Object-Oriented databases. The rationale for the content is based specifically on a post-graduate cohort that may not have a background in information technology. The topics are thus chosen to provide these students with a “core” skill set for database fundamentals as a precursor to the semester two database module, which is more research focused.
The module is co-delivered with me as the principle tutor. Prior to the onset of the semester there is a preparatory meeting held in the “thinking” table (fig. 3) to schedule the content and delivery over 12 weeks. The module descriptor defines the broad content of the module.
As can be seen in the descriptor the aim of the module is to provide the student with an extensive experience in designing and implementing advanced database applications with the following 3 learning outcomes:
i) Critically analyse application requirements and design appropriate conceptual database models
ii) Implement effective databases using a mainframe DBMS, including database programming techniques
iii) Evaluate the different approaches to data manipulation using SQL demonstrating one of the options within an application
Learning outcome 1 maps to the modeling topics, outcome 2 relates to mapping, the use of a DBMS’s Data Definition Language and programming features, while outcome 3 essentially maps to the full portfolio of SQL.
2.2 Taught Materials
Content is arranged into lectures, tutorials, labs and additional homework where deemed appropriate. Table 1 shows the content for each topic and generally supports the database design theme with tutorials and the database implementation theme with labs.
Table 1: Content by Topic
Topic |
Content |
Relational Modelling |
|
Entity Relationship Modelling |
|
Mapping |
|
EERM & their Mapping |
|
Normalisation |
|
Basic SQL |
|
Advanced SQL |
|
Basic PL/SQL |
|
Triggers |
|
Stored Procedures and Functions |
|
Oracle Packages |
The thread of the teaching is that the students are first introduced to relational modeling and to the basics of Oracle in order to give the essence of the database building blocks. From there, the students construct basic ERM’s and map them to a relational database. The recursive relationship example below (Fig. 4) always produces an interesting challenge to the beginner and invariably the question “Do any of you have more or less than two biological parents?” needs to be asked! I particularly like this example for its richness in conceptual content as it gives a very good indication as to whether the more difficult concepts are being understood at an early stage.
Figure 4: A preliminary exercise for the ERM and Mapping tutorials
The final question is large and requires a skill in interpreting the text to design the ERM. In turn, this question is used in the following tutorial to test their full understanding of the ERM-mapping process. The class diagrams for E(Enhanced)ERM are deliberately delayed until the following week so that these concepts can be treated in their own right along with the rules to map them. My own belief is that designing a full EERM is the difficult part and that applying the mapping rules is a more straight forward process. In practice, this assumption is however unfounded as often the students have difficulty applying the rules, especially when dealing with class structures. Why do students struggle with Normalisation? I remember disconnecting from this subject myself at university. My excuse is that COBOL was the teaching vehicle and that data structures were all embedded in the application code. It wasn’t until I became a lecturer that I really understood it. I keep this in mind when I am teaching this subject and squeeze every creative morsel in my body to try to communicate the ideas effectively. This tutorial brings the design aspects to a close and it ends with what I consider to be an example that knits everything together. It is Question 3 on the tutorial sheet from Table 1. The students normalize a standard ORDERS database and are shown the associated ERM. The question calls for minor amendments to the data and to re-normalise due to the inherent changes in functional dependency. Finally, the students are asked to re-draw the ERM after the changes and it transpires that a ternary relationship emerges. At the end point I usually find myself saying “isn’t that beautiful?” and reflect back on my mathematics teacher who used to say this. Obviously the students don’t share this passion at this stage, but, if they ever become academics themselves, they might. I did.
The second half of the semester is devoted to SQL and procedural SQL programming. Two SQL lectures cover the spectrum of structures and are supported by a host of questions in the homework assignments. The same Oracle database is used throughout this teaching period. I like a particular database to be implanted in the students minds so that it becomes a familiar entity and facilitates greater fluency. The students are asked to treat the database paper version with as much due care as they would their passport. It doesn’t always work and sometimes they are only half equipped with learning materials in class. Of course, everything is available online but sometimes it is actually better for me that I can teach “to the paper copy”.
Here are 5 examples from the SQL homework sheets that are considered to be basic, moderate, advanced, nested and puzzling respectively. See if you agree perhaps?! The database is here.
Level |
Query |
Basic |
Show for each vehicle registration and make, the branch name and city as well |
Moderate |
What is the average, maximum and minimum salary for each division name (use suitable aliases for your output)? |
Advanced |
How many staff does each staff member manage, including those who don’t many any at all? |
Nested |
Find the employees located in London who have the same job title as Raines. Return the results in alphabetical order of employee name. |
Puzzling |
Find the division with the highest average salary. List the division’s name, number and average salary. |
Aspects of SQL teaching design and delivery are covered in the next two sections. PL/SQL wraps up the module and takes the students through basic procedural programming structures to database triggers, stored programs and packages. Most of these lectures are driven by example, which has a potential downside in that the less able students are more or less given code to regurgitate for assessment. An illustration of an annotated example is shown here.
Aim: To organize the module that befits effective learning
3.1 Module Planning and Design
Modules undergo annual scrutiny with the goal of enhancing delivery and the student experience. As outlined in section 1.4, the ‘thinking’ table plays a particularly important role at the beginning of September when instructional design is being reviewed in the light of feedback and new knowledge.
One of the outcomes of the thinking is the module schedule, which is consequently posted onto the VLE (Virtual Learning Environment), a snapshot of which is shown here. The VLE mimics the teaching schedule week by week as well as providing supplementary readings, links and podcasts. The teaching schedule is organized around 11 lectures, 4 tutorials and 6 laboratory sessions. The design schedule follows some chronological train of thought in that the design theme is taught first (Relational Modelling, Entity Relationship Modelling, Mapping and Normalisation), followed by the practical theme of SQL and PL/SQL. Tutorials are used to discuss the theory of modelling, while labs are equipped with the Oracle software to develop the practical database skills. Tutorials are designed to run the week after the lecture, giving the students a full week for preparation on each topic. As the module is co-delivered, there is some thought given to blocking each tutor’s time on the themes. Tutors’ initials are logged against each week’s lecture on the module schedule. The cohort of students is split into two sub-groups for tutorials. Each student attends a one hour tutorial per week with both tutors responsible for one tutorial each. To calibrate the teaching of the tutorials, the co-deliverers agree on the order of the questions and how long will be spent on each question approximately. The lab sessions are two hours for the whole student cohort and run from week 6 to week 11. A single tutor is normally used for each of these sessions.
An element of the assessment that falls into instructional design is the preparative guidelines for each unit. The week before the test unit, which runs in week 12, the skeleton structure of the assessment is posted onto the VLE. This is done to make sure that the students are given full awareness of what to expect in advance in terms of style and structure. Similarly, a week before the viva for unit 2 are administered, a set of preparation instructions is issued to the students outlining approximately what to expect in terms of questions and demonstrations.
3.2 Special Focus on SQL
SQL has always been at the forefront of importance in my mind when teaching databases and I have never really understood fully why a significant number of students have difficulty in getting to grips with it. This has provided the motivation to experiment with different methods as well as the drive to bid for research funds. For many years, a standard design method of “here is a lecture” now “here are some questions” in the lab was used. In some cases it worked and there was quite a “buzz” in the lab with lots of questions. Recently, however, it has been noticed that this has waned somewhat. It may be because of a demographic shift towards a predominantly international student cohort where there is arguably less of an emphasis on expressing outward opinion amongst certain cultures. The author has no significant evidence to substantiate this assertion but, regardless, felt a need to try to enhance the experience in this important field of learning.
Through discussion it was decided to deliver SQL for this academic session using team work and a student peer-review method. The motivation behind the change was to introduce a team spirit into learning and a competitive edge. So, back at the ‘thinking’ table, sketches were made of how to design this over the two week period (sketch1, sketch2). These brainstorming artifacts represent the initial process of designing the structure and content, and contribute crucially to the construction of the formal SQL teaching rationale distributed to the students so that they are primed in advance of our intentions and our expectations of them. On reflection, the schedule may look a bit unwieldy in its detail but, together with the timings in the timetable (see section 4) it was carried out with little difficulty. The detail of the actual delivery follows in the next section.
Aim: To connect effectively with the student and to have some fun
4.1 Timetabling
Friday was designated as SA0951a day, regarding the timetabling. As this activity was determined before the onset of the Database Disciplinary Commons (DDC) there were of course clashes to manage. During the DDC weeks, delivery was moved to Thursdays. Two lectures are delivered in week one to front load the database modelling concepts along with a lab to give some early hands-on practice in building databases on the Oracle platform. Tutorial materials are issued at each lecture and posted on the VLE along with the lecture notes in advance at the request of the students, historically. Tutorials for each topic are delivered the following Friday immediately before the lecture for the next topic. I find the pace of this agreeable as it provides a rapid gear shift into the next topic to allow the thematic links to be forged in a timely fashion. Similarly, labs are run a week after lectures. The students are encouraged to attempt the questions on the lab sheet in advance of classes and some students do take this advice, which is always encouraging to observe.
4.2 Teaching Style
I think the style of delivery is very important to successful engagement in teaching. To this extent, the first four points in my teaching philosophy are particularly crucial. Motivation is not only to attempt to engage the students but also to enjoy myself. In lectures, formal quick fire questions are asked at set intervals to try to counter disengagement and to practice new concepts in real time. Here is an example of a question from the ERM lecture during which time I can traverse the theatre looking for potential problems and misunderstandings.
A story that is specific to SQL delivery will now unfold! When I first started at the university my very first lecture was in a music auditorium detached from the main building. I felt daunted by the prospect but intrigued to find that was a grand piano in the room. “Well if they don’t like my lecture I could play for them” was my instant thought and safety valve. I was excited at the prospect and dared myself to do it. But I had to question why. There was no link to databases and therefore a complete folly, surely? No. A piano is, after all, a database of sound and ordered. “Hmm, this could work”. The analogy concocted is that the database of sound is just waiting for a user and a retrieval language, like SQL. So, my retrieval language on that first day was Mozart’s Piano Sonata K331 (famous for its Rondo alla Turka). The result? An ovation. I will never forget it. But they never asked me again! I still do this on this module as the lecture theatre I use now also has a piano. The idea is of course to break the lecture up as a kind of timeout. I figure it is best to choose something internationally recognizable and so this year the Beatles got a dressing down. Just like within SQL, the piece is played both well and poorly to illustrate in particular semantic errors in SQL (you may remember two famous 70’s British comedians such as Eric Morecambe’s one-liner with Andre Previn “I was playing all the right notes but necessarily in the right order” or Les Dawson’s ability to play the piano badly incredibly well!). On asking the audience what they thought, a voice from the back shouted “Because you like showing off”. In part this is probably true but with a belief that some level or injection of “performance” in a lecture can go down well. The piano is obviously not a necessity to teach this subject, but I think it plants an artifact potentially for the student.
PL/SQL lectures are delivered using code examples in slides and live demonstrations in the Oracle interface. This involves switching between Powerpoint and Oracle “live”, which presents no problem, provided the Oracle server is operational. It brings some variation to the delivery and allows impromptu questions and even “what if” scenarios from any questions raised. An illustration of the traverse from Powerpoint to retrieving code into Oracle is shown here. Note that the Notepad interface does not actually need to be opened as Oracle simply imports the Block2.sql file from the appointed folder.
All lectures are recorded as podcasts and uploaded to the VLE. Only if the lecture is changed significantly is a new podcast recorded, otherwise an older version is retained. I must admit I don’t particularly like having the device wrapped around my neck and if I pause it I sometimes forget to continue when absorbed in the delivery of the material. Here is the normalization podcast. The rationale for doing this comes from student feedback, particularly those students whose first language is not English. Interestingly I have been told that my speaking voice is well received by the foreign students. I am sure this is due to my original accent being neutralized by working around different geographic parts of the UK and a self-conscious effort to be understood.
4.3 Implementation of the SQL Teaching Methodology
The teaching rationale for SQL has already been outlined here. This section explains the implementation of the strategy in practice. The first SQL lecture is delivered 1-2pm on Friday in week 5. This is followed by the second SQL lecture on Thursday of week 6 at 1-2pm. By this time the students have received all SQL theory and go into the first lab session immediately after the second lecture with fully charged minds! The first lab orientates the students into five groups of four at random. The group task for this lab is to come up with a list of 6 SQL queries covering breadth and depth of the taught materials using a crime database (fictitious!). An example of those produced is here. The next instruction is “Questions and Solutions to previous lab should be uploaded to VLE by Tuesday 5pm for “verifying” by tutors. We’ll choose 3 out of the original 6 for the following peer-reviewed lab”. This allows the group some time to reflect on their work rather being pressured to deliver the final set of queries by the end of the lab. Following submission from all groups, the co-deliverers vet all queries and shortlist the best 3 from each of the five groups, giving a total of fifteen questions. These form the materials for the second lab whereby each group receives the queries from the other 4 groups (a total of 12). The task of the second lab is twofold and forms the basis for the competitive element. The students have to answer all queries for all groups and hand them back. The responsibility of each group is to make judgments on the quality of the queries of each group and on each group’s solutions to that group’s queries. This illustration shows the form issued to Group A to mark the other groups on these categories. By the end of the lab, all marks are entered into the scoring spreadsheet to reveal the lucky winner! Unfortunately, the end results were not saved but I can reveal that it was a very close run thing with only one point separating the winner and second place (as witnessed by DDC peer reviewer – see evaluation section). The winning team received a splendid box of chocolates and came under extreme pressure to share there and then!
Aim: To give each student the fairest opportunity to demonstrate their highest potential
The module assessment is designed around the basic premise that, on completion, the student should know how to design, build and manipulate databases. These entities represent the three learning outcomes in section 2. Various methods have been used in the past, including online tests and standard coursework. Currently, the module is assessed using two units at 50% each. Unit 1 is a tutor-invigilated written paper test and unit 2 is a portfolio.
The rationale for two units is to form some kind of study boundary between the ‘designing databases’ and the ‘doing something with databases’ themes. In a more technical sense, the unit assessments act as independent learning mechanisms to essentially test database modelling and database manipulation.
Unit 1 is an open book assignment to assess entity-relationship modelling, mapping to a relational model and normalization. Practice for this assessment has occurred during the delivery of tutorials (see sections 2 and 4). Historically, this unit had been assessed by standard coursework activity, which had witnessed problems with collusion. The paper test seems a better method and, with hand drawn diagrams is perhaps less cumbersome for the student to implement their ideas. There is, however, an outstanding issue with the assessment in that question 2 is dependent on the answer to question 1. The evaluation section addresses this.
Unit 2 is assessed primarily using a fairly standard method of submission. The students are instructed to deliver a portfolio of DDL (Data Definition Language), SQL and PL/SQL code to demonstrate the breadth and depth of their knowledge. The split of these is 20%, 30% and 50% respectively. Being aware that problems of collusion could occur with this method, additional caveats are included to minimize the risk. Firstly, the students have to set up their own data, secondly they are asked to present the results of their queries in addition to the SQL code. Lastly, the viva instructs the student to present their PL/SQL code. These instructions are made available to the student prior to viva to aid preparation. The two main purposes of the viva are to establish authorship of the work and to contribute towards the grade for that section of unit 2. There is a debate as to whether a viva system would scale for larger class sizes. It works well for this size of 20-30 students. Also, with co-delivery, the viva can be conducted in parallel and therefore halving the amount of timetabled contact.
To conform to the Quality Assurance Agency’s requirements, the module assessments undergo a rigorous moderation and auditing process via an in-house electronic system known as MOSY (MOdule SYstem). This system ensures that all assessments are checked by a 3rd party moderator and that a dialogue has been recorded with the module tutor to the point of agreeing that the assessment is ‘fit for purpose’. The MOSY moderation dialogue for the portfolio unit is shown here.
Reassessment for the module merges the two units together. This avoids having to allocate specific times for test invigilation and viva administration. The reassessment has three sections, depending on the current status of the module for the student. A student who has failed both units sits section A, a student failing only unit 2 sits section B and a student failing only unit 1 sits section C. On the assumption of very few students needing the reassessment, the viva is considered superfluous to the process.
Aim: To enhance the effectiveness in teaching, learning and grading
6.1 Feedback Mechanisms
Feedback to and from the students is a very important part of the evaluation process. How else can you or they know if we are on the rails or not without it? The feedback process essentially starts during the MSc Induction week where ‘primer’ classes in databases and other topics for all students registered on the MScPgDip/IT Programme are held. We can get immediate feedback from these sessions as to the ‘technical’ level of most of the students and where our efforts might be concentrated at the beginning of the semester. Socially during induction week, we invite all of our MSc students to a barbecue in a Country Park. I find this helpful in getting to know the students, their background and their social confidence levels. It’s great fun and comforting to know that in the ‘Egg and Spoon’ race there are no differences observed across nationalities. Everyone cheats!
More formally, the first feedback on academic delivery occurs at the mid-semester point. The students are given a yellow post-it note at the beginning of the 6th or 7th lecture (but normally to capture SQL materials in particular) and asked to write freely about the module. At the end of the lecture the post-its are stuck on the door (sometimes even on the lecturer!) and gathered for summarizing. They are fairly scribbled but mostly visible in this collage. On this occasion the feedback is generally centred on SQL. Some references to not liking collaborative work do NOT refer to the SQL team teaching as this feedback was collected before those sessions. They are referring to group work in tutorials. No feedback was collected from the SQL sessions, which was an oversight and will be included next year if the same methodology is adopted. Overall, SQL seems in favour but with more practice time requested. I particularly like the reference to the tutor being ‘humous’! Sometimes it is possible to remedy any problem immediately (this is the ultimate purpose), other times the feedback goes into the rationale for the following year. Complementary to this is the feedback gathered at the School Executive committee meetings where student representatives communicate any module or general problems on the programme. These occur once a semester and coincide well with our own modular feedback mechanism.
For assessments, currently no feedback other than a grade is given for the unit 1 Test. This is probably because it is treated in the same fashion as a formal examination in that feedback is not generally given. Meetings can be arranged for students wishing to receive more feedback, however. For unit 2, the criteria-based feedback sheet is used to determine grades and given back to the students. Additional comments are made on the sheet as necessary.
6.2 Peer reviews
Peer review takes place bi-annually through the University’s Teaching and Learning Committee. This can take many forms but involves peer observation of a class, a piece of documentation, a procedure or a combination. The internal peer review is signed off via an online form. An external peer review also took place through the DDC courtesy of Jim Paterson of Glasgow Caledonian University. The SQL competition lab was chosen both for internal and external review. So, in a sense the session was two peer reviews within a peer review as the students were making valued judgments on the work of their peers too. The external review was very useful and one or two interesting points came out of it for follow-up. The reviewer commented on the effective delivery and what was a seemingly complex operation of paper organization! The review highlighted a possible link to using the Peerwise system as a means of students posting SQL queries on a shared space. This would tie in very strongly to this methodology and will probably be adopted as a result. The full peer review is here. The session was arranged in the morning so that the reviewer could get back to Glasgow for Guy Fawkes Night only to find that the inclement weather had brought about its cancellation. Lucky Jim?!
6.3 Marking
The university introduced criteria marking in the recent past and this has now become a standard practice for calibrating and mapping submissions to grades. The words are often quite difficult to articulate at times but they do act as a base guideline for academic standards at each grade level. The marking template for the portfolio shows the breakdown of the contributory parts for this unit. Essentially, the criteria are setting the relative standards for how the students define their database, how they query it and how they program it respectively. If marking is co-delivered, as is mostly the case on this module, a couple of scripts are normally marked together first to align the calibration of the markers within the demarcations of the marking scheme. Table 2 shows three examples of annotated feedback sheets. A20 is the highest pass grade awardable, D9 the lowest pass and MF6 the lowest marginal fail. Below that CF3 refers to Clear Fail, LA0 to Little Achievement and NS0 to Non-submission.
Table 2: Portfolio Unit grade feedback sheets
Unit |
Excellent |
Good |
Marginal Fail |
Portfolio |
Note from the assessment criteria for this unit that PL/SQL code is not asked for in the submission. Rather, the students bring this code to the viva session and all the hardcopies are collected then. In hindsight this will probably change in that ALL code will be submitted so that there is no onus on bringing the code just for the viva and tutor annotations of the code will also be naturally available to the viva as well. The challenge is turning the marking around in between submission and the viva period. With a small class it is no problem and favourable. With a larger class the present model may still be a better option.
For the Test unit 1, the marking scheme will always be bespoke according to the scenarios set. Broadly, however, marks will be allocated in similar proportions. The marking scheme for the Test unit is here. It includes a rather scribbled tutor sketch of the recommended solution for the ERM. The students are told that their work just needs to be legible. This is applied to tutors too! Each submission is marked clearly in the margins according to the scheme. Scores are allocated for each question, totted up to make a final score, which is then mapped to a grade according to a grading feedback template. The unit will undergo slight modification next year to eradicate the dependency of question 2 on question 1. This seems both fairer to the student from a point of view of optimizing performance but will also make calibration of marking easier against a set example.
6.4 Preparation for Boards
The process of evaluation comes to an end in the run up to the Programme Boards with invited externals. There is an institutional entity called “The Module Box” which tends to make most lecturers go a lighter shade of pale at the mere mention of it! It’s a signal to get all the paperwork in order concerning the module for presentation to the Board. It contains all information about the module content, planning, student scripts, feedback, module grades, module summary form and a signing off by the moderator.
An interesting observation that emerged from the peer review sessions of the DDC as that as an institution we do not plot all module grades on a graph to show correlations and potential outliers as part of the decision making process regarding the module portfolio as a whole. Oppositely, we produce our module summary forms in the form of a factual and reflective narrative, which was deemed useful by the observer. A natural conclusion from this would be to merge the two.
Maybe you know Mozart’s “Don Giovanni” opera. At the end there is an epilogue before the final curtain drops. The module box represents this epilogue to the semester and at the time of writing is being phased out by an electronic system. It would seem fitting therefore to pay homage to this relic. Graduation brings down the curtain. Is this the end or the beginning?
“Anyway folks, the next ship is about to dock. But then that’s the rhythm, isn’t it?”