A Framework for Interaction in Software Development Training

Introduction "What do you mean we have to document everything?"--a project team to their management Recent articles on software engineering education stress the importance of real-world experience (McCauley & Jackson, 1999). It is agreed that this experience can be gained from participating in projects that are complex with potentially marketable results (Nachbar, 1998). A customer, that is not the instructor, should be involved in the development process (Polack-Wahl, 1999). Unfortunately, time constraints often make the realization of meaningful projects difficult. Within a software projects course, an established technique is to maintain the instructor as direct manager over all of the projects. In this model, four issues make relevant projects difficult to use (Bryant, 1999): (1) instructor overload, (2) the balance of theory with practice, (3) evaluation of student performance, and (4) keeping students motivated. Sacrificing depth and quality in code and documentation can provide a more manageable workload and help to address these four issues. However, the undergraduates then lack the experience (and the frustration) that is part of industrial-scale development. Different frameworks have been devised for software engineering education--both at the graduate and undergraduate levels. In many case, the frameworks are tailored to the curriculum and the degree of focus on software engineering, e.g., the number of software engineering courses and whether a degree is software engineering is offered. Cowling presents a hierarchical curriculum framework based on process, products, and people (Cowling, 1994). The framework serves as a guideline for establishing software engineering courses specific to the computer science curriculum. While he suggests there be a balance between the three parts, he recognizes that products are the main focus, and thus, that branch of the hierarchy requires more depth and attention. Laboratory concepts have been extended to software engineering (Sebern, 2002). One approach is to use a laboratory to have traditional project-based training, while giving students "staff" assignments, like Quality Assurance Group or Configuration Management Group, to foster cross team sharing of information and experience. Similar to lab experiment reports, students provide feedback through "process improvement proposals" and "advice to future students" as project hand-ins. This provides a mechanism for self-reflection and expression. Graduate students in software project management classes are often taught using case studies (Kemerer, 1997). Students assess the managerial problems and detail potential project directions in written briefs. Sample projects for architectural descriptions, configuration management, and development tool usage may also be included. Missing from this curriculum is actual project scheduling and assessment, managing of personnel, and communicating with a realm of stakeholders. One clever approach to partially overcome these problems uses assignments that focus on a particular software project in which the "managers" formulate project artifacts (schedules, test plans, etc.) given an imaginary team that performs the development (Murphy, 1999). Programs for Master's in Software Engineering have greatly expanded over the past decade. Most encompass multiple courses that are focused on obtaining industrial foundation for problems, teaching methods, and projects. Some go beyond the typical academic bounds by having industry partners contribute to master's theses by providing students with relevant problems and participating on the committee that judges the outcome of the thesis (Wohlin & Regnell, 1999). This provides a genuine problem to accompany classroom topics. An interesting concept called the "Virtual Enterprise" strengthens a project-based approach for the Master's in Software Engineering degree (Herwig, 1997). …