A Scalable and Portable Structure for Conducting Successful Year-long Undergraduate Software Team Projects

Introduction Producing industry ready graduates who are able to perform successfully in the workplace is a very important goal for tertiary educators. Factors of importance to employers, as described by Nunan (1999), extend beyond technical capabilities and include flexibility, independent learning, highly developed communication skills, and the ability to work in teams. This is underlined by industry accreditation requiring teamwork opportunities be provided during the undergraduate experience. Organising teamwork so that it is fairly structured and assessed is not an insignificant challenge (Clarke, 2002, 2005), as students should be sufficiently engaged to ensure that participation is equitable between team members. Engagement is an important issue more broadly. Engaged students become more deeply involved in their own learning, and the current generation of students are very strategic with their choices for engagement (Krause, 2006). Students are highly motivated when faced with authentic tasks in a realistic setting (Krause, 2006). Year-long team projects with external clients provide a well recognized opportunity for students to gain industry experience, whilst being supported and guided by staff to minimize risks. Each group needs to be supervised to ensure that they have enough direction and confidence to approach a new problem of significant size, without being daunted. A structure is needed that is flexible and adaptable to suit various institutional cultures but, at the same time, provides the safety net to ensure that success is highly likely. This paper proposes a structure that is scalable to any class size and portable across institutions and potentially across technical disciplines. The structure leads to team student projects that are successfully engaging and provide excellent experience toward producing work-ready graduates. The structure has been successfully implemented in at least three different universities in Australia and several remote partner sites in different countries over many years. This paper describes and reports on the positive aspects of capstone project units at three different institutions. The work presented is valuable as a presentation of our considered experience and observations of how to manage projects in a flexible framework that we recommend to others teaching similar units. This paper is a comprehensive review of distilled wisdom--based on literature and our own experience. The paper is organised as follows. We initially provide some background regarding our approach and argue that it is based on current best practice. We articulate key success factors for student software team projects, concentrating on those related to student support. We outline the structure in terms of the scaffolding it provides for problem based team learning with a constructivist approach. We then show that it is flexible and can be implemented in different settings by providing case study examples and short descriptions of its successful implementation at various institutions. We conclude this section with some comments on terminology. A project can occur within a Software Engineering degree, IT degree, or Computer Science degree. The different degree context can give subtly different scope for a project, and student background and expectation can differ. The project is often described as a capstone experience. People differ between whether the project is done by a team or a group. Discussing the trade-offs in terminology is beyond the scope of the paper. What we have in mind is a year-long software development project for an external client by a team of at least four later-year students, where students have to proceed from requirements elicitation through to delivery of a product to the client. Background Software team projects are recognized by professional societies, computing practitioners, and educationalists as a core component of effective undergraduate computing degrees (Fincher & Petre, 1998). …