Experiences in Project-Based Software Engineering: What Works, What Doesn't

Introduction

Since its early roots at the 1968 NATO conference in Garmisch Germany (Naur, Randell & Buxton, 1976), the software engineering discipline as has sought to use tools, techniques, and paradigms similar to those found in other engineering disciplines in order to improve the quality and reduce the cost of software development. The seminal “No Silver Bullet” article by Brooks (1987) in part focuses on identifying the essence of what makes software development difficult and stresses that the ability to modify software so as to accommodate evolving hardware requirements is one of the key aspects of understanding the inherent difficulties faced by software developers. Agile, lightweight methodologies such as Extreme Programming (Beck, 1999) emphasize customer involvement and promote team work in an effort to make the development process better suited to adapt to changing requirements. Of note with Beck’s approach is the use of ad-hoc teams to resolve difficulties that arise during the development process. Software engineering educators have responded to these needs in part with the emergence of project-based software engineering capstone courses at the undergraduate level.

Such software engineering capstone courses are becoming a cornerstone of many computer science (CS) and computer science & engineering (CS&E) programs, and provide a means for practice-based exploration of large-scale projects in a team setting following current trends in software engineering course sequence design (Abran & Moore, 2004; Boehm, Kaiser & Port, 2000; LeBlanc & Sobel, 2004; Meyer, 2001; Shaw, 2000). Our approach to project-based software engineering capstone courses allows students to apply concepts and ideas garnered throughout their undergraduate program within a capstone experience near the end of their studies. For students, such courses can provide the opportunity to control the project topic, select teammates (to a limited degree), make critical decisions, and problem solve by applying coursework knowledge and their experiences. Project topics selected by our teams have run the gambit from standalone Java applications, automatic mixing machines that use windshield wiper motors and micro-processor controlled PVC pipes run via a web interface, to embedded system controllers for autonomous underwater vehicles. In such courses, instructors can serve as the mentor or project manager, overseeing the week-to-week schedule of deadlines, and arbitrating among team members when difficulties or clashes in personalities arise.

Project-based, software engineering capstone courses can also play a vital role in terms of accreditation. ABET, known prior to 2005 as the Accreditation Board for Engineering and Technology (ABET, 2007), has assumed accreditation over CS, CS&E, information technology, software engineering, and computer engineering programs. As part of ABET accreditation, departments must identify program objectives, and detail the program outcomes for each program; CS&E has outcomes that are influenced by engineering accreditation requirements, while CS outcomes have been influenced by computing accreditation requirements. Given a set of program outcomes, in order to support a continuous improvement process, it is necessary for departments to assess their programs on a regular basis. Since well-focused project-based software engineering courses can span nearly the entire curriculum in terms of topic coverage, they can serve as an ideal vehicle to accomplish this objective.