Robins, Rountree and Rountree( 2003) noted differences between effective novices, who can learn without excessive effort, and ineffective novices, who require close support while learning. It is easy to see how the‘ play around’ approach might benefit the former without providing the latter with adequate support.
Similarly, giving the students information on programming but leaving them to their own initiative in applying this knowledge left the students underprepared for the program design portfolio. Davies( 1993) made a distinction between declarative programming knowledge, where a student might know the purpose of a technique such as an IF statement, and strategy, where a student knows when and why to apply this knowledge. While the students may have gained declarative knowledge, there was less opportunity to learn strategy.
All of this is reflected in a number of the comments made by students in module feedback forms. In 2015 / 16, a number of the suggestions for‘ what could be improved’ followed the same theme: that the module would have benefitted from providing a more structured learning experience to help develop programming skills.
Ultimately, the problem this is best expressed using the 2001 revision of Bloom’ s taxonomy( Krathwohl, 2002). Both the programming portfolio and the assembly language assignment asked the students to plan and produce an original programming project, all of which requires the students to‘ create’, the highest level thinking skill in the taxonomy. This is difficult when most students had little opportunity to progress beyond the lower level thinking skills,‘ remember’ and‘ understand’. It is, therefore, not surprising that the mean student mark for the programming portfolio at this time was 58.32 %. learning outcomes 2, 3, 4, 5, 6, 7 and 8 are all met by the programming portfolio, rendering the assembly language assignment and assessed programming tasks redundant. Given that a typical Foundation Year student will be studying this module alongside ten other modules over the course of the year, this goes against QAA’ s guiding principles for assessment( The Quality Assurance Agency for Higher Education, 2018). This sort of overassessment has been associated with surface learning( George, 2009), poor attendance( Jonkman, Boer and Jagielski, 2006) and stress( Cefai and Camilleri, 2009). One final issue was that the program plans were submitted as part of the final portfolio, meaning that most students based their plans on the finished program and did not meet learning outcomes 4 and 6.
A more generic issue facing Computer Scientists is the disparity in the numbers of men and women enrolled as students in the subject( Sax, et al., 2017). In the 2017 / 18 academic year, 12,885 female students( 15 % of total) and 71,125 male students( 85 % of total) enrolled on undergraduate Computer Science degree programs in the UK. This is in direct contrast to gender divide found elsewhere in UK higher education, where female students comprised 55.89 % of all students enrolling on undergraduate degree programs( Higher Education Statistics Agency, 2019). The gender gap in FYO-00096 is broadly in line with that seen nationally, with Table 1 showing how female students have never made up more than 20 % of a cohort.
Increasing female recruitment goes beyond the scope of this study, but providing an inclusive student experience is a key part of Keele’ s equality objectives for 2018- 2022( Keele University, 2018). It is vital to ensure that Computer Science classes provide a safe, accessible and inclusive environment for all students.
Given the study level and number of credits available for the module, the assessment load was excessively heavy, with the three nominal assessments effectively comprising ten different assignments. According to the principles of‘ constructive alignment’ outlined by Biggs( 1996), assessment should require students to evidence that they can match the intended learning outcomes for the module. However, in FYO-00096,
Article # 3 25