{'fraction_non_alphanumeric': 0.02704007725736359, 'fraction_numerical': 0.0147271849348141, 'mean_word_length': 5.057017543859649, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Talking Past Each Other-Student and Staff Reflection in Undergraduate Software Projects

Introduction The importance of a substantial Software Engineering project executed by groups of undergraduate Computer Science students is widely recognized (Daniels, Faulkner & Newman, 2002; Fink, 2000; Flener, 2003; Liu & Stroulia, 2003) With group work, there are many issues relating to group dynamics, organisation and conflict that arise that have an effect on project outcomes. It can often be difficult for staff to penetrate the social context that groups create for themselves in order to understand the issues that groups face during their projects. We focus on the issues relating to group projects and the role of reflection in discovering the true nature of project circumstances. We discuss a protocol that we used to guide reflective activity in our teaching. In our institution, we face a continual problem in retaining students at postgraduate level in Computer Science. Our undergraduate students are motivated to complete their studies as quickly as possible and find work. At the same time, we are finding that more and more educational initiatives within New Zealand are encouraging us to work more closely with industry. In teaching Software Engineering, we find a natural focus for our teaching practice to account for both of these trends. We view a course in Software Engineering as involving more learning than teaching. We view student involvement in such a course as "...learning to be an engineer, by practising to be an engineer..." and for an engineer to "[walk] the bridge between science and technology" (Bjorner, 2002), balancing engineering activity with the application of strong scientific principles (Shaw & Tomayko, 1991). Providing a simulation of the "real world" of Software Engineering is again a common approach throughout Software Engineering Education. This simulated project environment provides the grounding in real tasks that seems to be important for adult learning (Stewart & Richardson, 2000). There is a strong resonance here with constructivist theories of learning, where we find an emphasis on learning by developing knowledge through practice and working collaboratively to solve problems (Jacques, 1985). Group work encourages the development of personal skills and responsibility and the development of inter-personal relationships (Butcher, Stefani & Tariq, 1995; Oldfield & Macalpine, 1995). Practical experience in engineering and project management can only be acquired in a large project setting (Gehrke et al., 2002). The question arises as to whether academic software projects really are simulating the real-world environment (Ford & Morice, 2003). That is, when we engage in this process of simulation, do we provide an environment in which real-world practice can take place, or do we provide a simulacrum in which principles of teaching and learning are applied and enable activities and outcomes related to group work occur and emerge? We lean more towards this latter approach in our course designs and delivery. Course Organisation We teach Software Engineering as a full-year course, involving 26 weeks of full-time study with two formal lectures each week. At our institution, the study year is divided into two semesters of 13 weeks each, with a 1-week break in the middle of each semester and a 4-week break between semesters. Institutional guidelines to students indicate that they are expected to spend approximately 6 hours per week on this course, including formal class time, preparation for class and project work. In practical terms, this means that students are expected to spend about 3 hours per week on project work. Assessment for the course is divided into 60% for a 3-hour final examination and 40% for the full-year project. Our philosophy on teaching this course is based on the notion that simulating the engineering environment provides good preparation for real engineering--we strongly believe that students should be able to do things in a practical way and hence they can learn the theoretical underpinnings in a stronger sense through this practice. …