Instructor perspective #

This document addresses a number of concerns from the course instructor’s point of view: how to run a course with one or multiple projects, what course prerequisites need to be there, importance of institutional context and program specifics. It also addresses a number of important assumptions.

Options for multi-semester projects #

One of the attributes of many external projects is they often can’t be completed in a single academic semester. Consequently, instructors must decide the most suitable method for carrying forward the work, taking into account the course structure of the institution and any specific learning goals. Throughout the existence of the Studio, we have experimented with various transition models, each showing success. Below, we detail these approaches, outlining the benefits and potential drawbacks observed with each:

For institutions with only a single SPSG semester length course #

For institutions that don’t have multi-semester sequences suitable for SPSG this approach may be the only fit.

Continuation with different student team(s) same course #

For this model each semester the new student team must become familiar with the project and the partner’s project leadership. This is the steepest learning curve as without fore thought it can be like starting a whole new project again. We have found a couple of approaches that make this a much easier transition. First, with this type of model the documentation and transition activities at the end of each semester become all the more critical so being sure to emphasize that these activities are just as important as development activities and having a grade weighting appropriate to reflect this importance can be an invaluable tool in students appreciating the documentation is more than just a formality. The other aspects we have used successfully to assist this transition is having the members of the previous team that are now either more senior students or alumni continue to be a resource for the new team, such as serving as near peer mentors on the projects or at a minimum meet with the new student team at the start of the semester in a kickoff event which serves as a crash course for the new student teams.

For institutions with either year-long or course sequences suitable for SPSG #

For institutions that have either a year-long course or similar course sequence (e.g. Software Engineering I and Software Engineering 2, or Software Engineering and Senior Project) there are a number of options for supporting a multi-semester project.

Continuation with same student team #

With this approach in the subsequent semester the same student team continues working with the same project in the following semester. This approach has the obvious advantage of requiring minimal to no time getting the team up to speed on the project and student’s already have built a relationship with the partner. As a result, this typically allows for progress to immediately continue. The main challenge with this approach is if not all students in the initial class continue it can lead to either a smaller team in the subsequent semester or adding one new member to an existing team that is already up to speed, which may lead to poor experience for the new added student.

Continuation splitting student teams #

This approach has been used when the initial phase of the project was a proof of concept of setting up a foundation for a larger multi-tasked development effort in a subsequent semester. An approach that has been used successfully for this has been to divide the original team in the following semester among the number of teams that will be working on the project in the new semester. With an even mix of new members and members that are familiar with the project. We have found this to work well with the continuing students becoming sources of expertise within the new teams. This typically allows for shortening the partner and project learning curve.

Continuation with different teams #

A third approach is to have the project continue on with the subsequent course in the sequence, but with a different team. With this approach there is still the need for strong transition documentation, but students have sources of expertise in their classroom. While in may seem less intuitive than keeping teams with their original project, we have found this approach along with reshuffling teams in the subsequent course to actually be our preferred approach from a learning perspective. Specifically, we have found a number of benefits come from this. It gives the students a direct opportunity to see what types of gaps they may have had in preparing their first semester’s transition documents and thus learn through direct extended feedback learn what types of assumptions to avoid in documenting software systems. We have also found the switch in projects, project leadership, and student team members to be a valuable learning experience of being exposed to how tech stacks often differ across organizations and being able to recognize these similarities and differences is a valuable skill in itself. Finally, the change in projects often mean the students get exposure to different project leadership styles, as does the change in student team members require learning to be effective with different team dynamics. When considered together, these are valuable learning opportunities that benefit the students significantly.

Project maintenance concerns #

Several approaches to project maintenance have been successfully used in various contexts.

Maintenance by individual developers from the original team(s) #

Frequent communication with the project partner helps establish a good rapport with the student team. With the future maintenance concerns in mind, we encourage the project partner to openly discuss these concerns with the team to identify if any of the team members might be willing to help with the project in the longer term. This has been a viable solution for many smaller projects where students and the project partner often develop a closer connection based on their common geographic location and/or the shared cause being addressed by the project. In many cases, our graduates stayed in touch with the project partners to provide adequate and timely resolution to many bugfix requests.

Maintenance by a (new) standby team or individual developers #

In situations when the program has an established track of completed projects and there is a likelihood of multiple maintenance requests coming in every semester, it may be reasonable to reserve a team of developers to address any maintenance requests as they come in. The main advantage of this approach is the immediate availability of the developers to address any incoming requests. The disadvantage is that it may be difficult to predict the workload during a given semester. This approach can also be implemented with an individual student, especially if they are more experienced, e.g. being in a graduate program.

Maintenance as a standalone project #

This approach works well if the nature of maintenance requests is such that they do not require immediate attention and/or if they focus on developing new features rather than fixing small defects. In that case, any requests for new features along with any non-urgent bugfixes can be framed as a new project extending the work of the previous project. The instructor will need to negotiate with the project partner to ensure that the scope of the new project is right and that it still meets the project feasibility requirements. The project partner will need to have a clear understanding that this work still needs to be aligned with the academic timeline, allowing necessary time all four phases of the SPSG framework.