networks & systems laboratory> research> current projects> improving outcomes for at risk programming student

Improving Outcomes for at Risk Programming Students
Smart Internet Technology Research Group

Introduction

- This project seeks to improve pass rates in core second year units involving programming skill. We wish to identify and examine factors that correlate with poor performance, in order to identify students at risk early in the year. We aim to improve the overall learning and conceptual understanding of programming as a whole in the degree program.

- Students who choose to take the information technology stream study SOFT1001 (Software Development 1) and SOFT1002 (Software Development 2). These cover the basics of programming. In second year the students do SOFT2004 which is used as a gatekeeper unit for senior software and networks units. This is the focus of the current project as it is a prerequisite for most third year software development and network topics. We aim to analyse the aspects of first year computer science that are essential for the success of second year studies and beyond.

- There is evidence that some first year university students function at Piagetian cognitive levels described as concrete level rather than the formal level1. Notably students often revert to such pre-formal operational levels when confronted with a problem outside their scope of experience2. The challenge is helping students move to the formal level required for programming competence. Computer science can be quite a large paradigm shift for students and often lacks any concrete operational level examples or instruction. If this is taken into account when developing remedial resources then the resources developed can be designed to focus on raising students understanding from a concrete level to a formal level.

Learning Outcomes

1. Ability to read and write correct, clean code in C that allocates, deallocates and manages memory.

2. Understanding of common memory-related errors (such as memory leaks and dangling pointers) and how to avoid these. [Higher performance could involve detecting errors in examples code, and fixing them using debuggers (see below)]

3. Ability to read and write code that correctly uses the main standard library functions, especially for I/O, file handling and string handling. [Higher performance could involve elegant use of these functions, particularly avoiding idioms which are extremely inefficient.]

4. Ability to correctly implement standard linked list data structures [Higher performance could involve slightly more complicated structures such as binary search trees]

5. Ability to use code quality strategies appropriate for C, including preprocessor techniques, and use of common idioms.

6. Experience of following a thorough automated testing regime using tools such as make, diff, scripts to present the outcomes, and a tool to manage regression testing. [Higher performance could involve ability to construct such a regime]

7. Experience in using debugging tools.

8. Understanding of the approach and concepts of Unix, including its tools, philosophy, processes (including pipes and redirection), the file system and the shell.

9. Ability to learn to use Unix commands and system calls (including usage of flags etc) from online manual system

Risk Factors

- One of the factors that has been identified as an ongoing risk for students passing SOFT2004 is their performance in the exam of the prerequisite course COMP1002.

- Students who scored in the forty to forty-four band had a three times higher failure rate, for SOFT2004 than those students who scored forty-five to forty-nine in the COMP1002 exam (see Fig. 1). Even more marked is the difference between students who scored in the thirty-five to thirty-nine and the later group who had over eleven times better chance of passing.

- The COMP1002 exam is designed so that students who fail to perform adequately in the first question (often referred to the barrier question) are not normally permitted to continue onto SOFT2004. The barrier question tests the students ability to iterate through a data structure and count the occurrences of a value. However when students pass rate in SOFT2004 is plotted against their mark in the barrier question for COMP1002 it can be seen that there is no correlation between the barrier question mark and the pass rate in SOFT2004 (see Fig. 2).

- This suggests that the barrier question is not serving its function as a gatekeeper question. The intention is to discriminate against students who show no programming ability, but even students who do very well (> 7) have a 15 % chance of failing.

COMP1002 Exam Mark vs SOFT2004 Pass Rate (with mark granularity of 5)



*click image to enlarge

Figure 1 – COMP1002 exam mark vs. SOFT2004 Grade as a percentage with a mark granularity of 5.

COMP1002 Barrier Question Mark vs SOFT2004 Pass Rate (with granularity of 1)



*click image to enlarge

Figure 2 – COMP1002 barrier question mark vs. SOFT2004 Grade as a percentage with a granularity of 1.

Self-Assessment Materials

- In an attempt to help students who are at risk of failing the School of Information Technologies has developed a website to assist the students develop skill in reading and writing code and the ability to assess the quality and correctness of code (see Fig. 3). The self-assessment site is mastery based, meaning that the student is presented with a problem which they solve and then submit the code to an automated testing system. This code is tested against a predefined set of sample data and the results are returned to the student, and logged to a central database. The student may repeat the tasks as many times as they need to until they ‘master’ the problem. The student can also view a set of supplied solutions. Each example solution illustrates a different way of approaching and solving the problem: for example, one method may be recursive and another iterative. In addition it is usual for each example solution to include some common mistakes, so that the student learns to identify these.

- The logging of a students performance allows tutors to review a students or a group of students performance of certain questions and evaluate whether further remedial exercises.



*click image to enlarge

Acknowledgements

- This work is supported by a the Teaching Development Fund grant from the Faculty of Science and the Science Lectureships Web WorkForce project.

References

1. Herron, J.D., Piaget for Chemists Explaining what "good" students cannot understand. Journal of Chemical Education, 1975. 52(3): p. 146-150.

2. Herron, J.D., Piaget in the Classroom Guidelines for applications. Journal of Chemical Education, 1978. 55(3): p. 165-170.

3. Kay, J. and Kummerfeld, B. Unit Specifications. Undergraduate Handbook 2002, 2002. Faculty of Science, The University of Sydney.

4. Prabhakar, C. Self-assessment Website. The School of Information Technologies, The University of Sydney.

Contact

Charles Prabhakar
Associate Professor Alan Fekete
Associate Professor Judy Kay

 
University of SydneyDesigned by eliu