Since 1996, the University of Stuttgart's software engineering major has been complementing the traditional computer science major with more practice-oriented education. 1
Key components of the curriculum are team projects in which eight to 12 students collaboratively develop a software system over two consecutive semesters. The projects have four primary learning objectives:
• autonomous development of a viable solution for a given problem,
• project planning and management,
• quality assurance within the project, and
• communication within the team and with an external customer.
Projects should cover all relevant phases of a typical software project: writing a proposal, a project plan, specifications, and design documents; implementation; integration; testing; and a semiformal acceptance test.
We use these projects to teach software engineering by means of a visualization-centered project, just as others are teaching visualization in a very successful way by means of specific application-centered approaches. 2
The projects are intended to be like a role-play of a principal-agent relationship. The students are the contractor. They fill roles typical in a software project, such as the project manager, quality assurance staff, configuration management staff, and software architects and developers. The customer is a faculty member who behaves realistically in that he or she has imprecise goals and occasionally changes his or her mind. 3
This has led the designers of the curriculum to involve faculty who aren't necessarily software engineering specialists.
Because the project is part of a university education, the faculty plays two additional roles. The examiner is responsible for final grading, and the supervisor helps students with technical and organizational questions. The latter usually also reviews documents such as the requirements specification to provide early feedback on what's possible and what's not.
A project regularly starts in the fifth semester of the Diplom (a 4.5-year program) or in the fourth semester of the software engineering BSc (a 3-year program). (The university is gradually replacing the traditional Diplom programs with BSc and MSc programs, in accordance with the Bologna Process, which is restructuring European academic education.) So, the students' knowledge is limited mostly to basic lectures on mathematics and on practical and theoretical computer science. Few of them have taken introductory computer graphics or human-computer interaction courses. 4
Their programming experience is also often limited.
Thus, the project involves not only the actual project work, which results in a piece of software, but also an accompanying lecture and seminar that fill in missing knowledge of the application area. One of the courses the Visualization Research Center offers on computer graphics, scientific visualization, 5
information visualization, or interactive systems is combined with the project, depending on its topic.
All projects consist of roughly the phases in Figure 1
. The length of the phases in Figure 1
corresponds to the actual length of the project described in the sidebar. In the beginning, the customer describes the project's goals to the whole group of students. In-depth requirements analysis for writing a proposal document isn't feasible in a group of eight or more students. So, we break each team into groups of up to four people for the project's first part—a strategy that most projects across all application areas use. 1
These groups conduct individual interviews with the customer and eventually present their proposal for the product and development process model, sometimes including mock-ups and small prototypes. This approach fosters creativity and competition and ensures that no students are idle during that phase.
Figure 1. The typical process for a team project. The diagram shows how many months the phases of the two iterations take and how the project work and accompanying seminar and lecture are aligned.
In parallel with the proposal work, all the students attend the seminar. This ensures the timely teaching of missing knowledge about technical foundations such as programming languages and the application area's scientific foundations.
The actual project starts after the customer has chosen a proposal. The winning group reaps double-edged rewards such as picking the project manager. From now on, the reunited team's project manager handles task allocation and time planning. The actual project's first phase is writing a requirements specification based on the proposal. This typically involves more discussion with the customer, which can be done only by a small group of people. Our experience shows that the project manager should arrange parallel training for the rest of the team to give them practical experience with the technologies used. The requirements specification is a key document in software development, so all our projects require it, regardless of the students' chosen process model.
The usual design, implementation, and test phases follow. Besides a semiformal acceptance procedure in which the customer tests the product, the students present their work to their fellow classmates, other computer science students, and department members (faculty and PhD students).
Our background is in scientific visualization, information visualization, and visual analytics. In our experience, the scientific-visualization projects are the most challenging. Even if the project's goal is little more than a reimplementation of well-established techniques, the theoretical foundations the students must learn from scratch are complex and are difficult to acquire before or while compiling the requirements specification. Furthermore, the algorithms are costly enough and the datasets are large enough to warrant low-level programming languages such as C/C++.
For information visualization and visual analytics, the performance concerns decrease because abstraction, aggregation, and filtering play an important role in most applications. This usually lets us use modern programming languages with implicit memory management, keeping in line with, for example, the scientific community's widespread use of Java for such tasks. Unfortunately, a fully fledged visual analytics system's size and complexity normally exceed the project's time budget—we devise the project's task to match the budget of 450 hours per student as defined by the curriculum as closely as possible. 6
Using an existing software system as the basis would mitigate this problem. However, the course's scope would change dramatically because software maintenance considerably lengthens the familiarization time at the project's beginning. From our experience, information visualization applications offer the best trade-off between an appealing project scenario and the constraints of the available time and the students' prior knowledge.
The projects have included visualization topics for more than 10 years. Over time, some recurrent challenges inherent in the present concept of team projects have emerged, whereas others are related to our visualization tasks.
The foremost conflict inherent in team projects is the one between a project that team members autonomously organize and the objective grading of each student's performance. The grades are compounded from the individual seminar grades, an oral examination at the project's end that covers the theoretical foundations and the project, and the practical part of the project. Seminar grading and oral examinations for courses are standard practice for student assessment at our university. So, we restrict our discussion here to our experiences grading the practical part.
First, several documents created during the project serve as the basis for grading. We examine those documents, including the final product's source code, with respect to the amount and quality of individual contributions. For this, we rely on progress and contributors documented by a version control system. Any realistically sized software project will rely on a version control system anyway, but at the same time, full access to the whole project history is an indispensable source for objective grades. Data from a bug-tracking system can serve a similar purpose.
At the project's end, the students must submit reports about their duties and experience, which as a whole provide some insight into their progress throughout the project. Additionally, we've found it reasonable to require project managers to submit a weekly summary of their project's progress and to require all students to record their working times. Besides being a source for grading, these data can improve the students' learning. However, such self-reporting isn't likely to be fully reliable and must be treated with caution.
The same holds for the general impression of a student's performance that the customer and supervisor gain from discussions about the project and from inquiries for assistance. The review meetings inevitably offer additional insight on team dynamics, workload distribution, and the student reviewers' technical skill.
In summary, we recommend basing the grading on several independent sources and constantly updating and documenting its aspects throughout the project.
The Project Manager
Another lesson learned is that the project manager is critical to the project's success. Often, and particularly in teams of apt programmers, the project manager's role tends to be unpopular because these students want to produce and hone code. This frequently results in a part-time project manager. In our experience, this is harmful, especially in large teams, because leveraging the team members' competence requires considerable organization and coordination. So, we recommend a full-time project manager. Sometimes, it might turn out early in the project that the chosen project manager can't fully cope with the job. In such a case, the supervisor can and should encourage the team to redistribute the roles, but this decision should ultimately be up to the team.
The Process Model
The project should either be planned in several iterations of a waterfall or phase model 7
or follow an agile process model such as Scrum 8
if the students have sufficient knowledge of such a process. Although we don't prescribe how to plan projects, we strongly recommend to our students that they choose an iterative process. The accompanying lecture that covers the required application knowledge spans the entire first semester. So, only an iterative process model enables the students to benefit from this knowledge in the practical part of the project, because changes in late phases tend to be costly. 9
The steep learning curve also influences what tasks are adequate for a team project. As we mentioned before, we prefer information visualization tasks, partly because we can safely rely on modern programming languages (in our case, we often use C#). We know from our own projects and projects in other application fields that this greatly increases the chance of the project's success. In particular, the pitfalls of manual memory management, as in C/C++, are an additional burden for students involved in their first large-scale project. They usually suffer from close to no experience with the language, in addition to no exposure to the application field.
Similarly, software maintenance projects should be avoided. A greenfield approach relieves the students from the time-consuming chore of understanding an existing software system. So, such an approach is more accessible for learning software engineering in practice. For students, the intrinsic difficulties of the workflow and team dynamics are such that the project's complexity must be limited, even if a first impression based on the available time and human resources seems to suggest otherwise. For the same reason, the project must have a clearly defined goal and not aim to test ideas.
The faculty's roles also involve several caveats. The customer and supervisor roles should be clearly separated. Students often express the wish for a trustworthy counselor whom they can ask for help when they encounter technical difficulties or social issues with the team. This contrasts with the customer, who must be perceived as external to the team. Achieving this clear separation of roles is sometimes difficult, particularly because a customer and supervisor might work together in another context and might even have jointly developed the idea for the project.
This separation of roles is also important because the supervisor might sometimes have to help the students reject the customer's unrealistic wishes. We've seen in nearly all the projects that the students initially don't completely understand the problem setting and hence underestimate it while overestimating their own capabilities. So, the supervisor must already have an idea of what the students can realistically achieve, requiring at least an informal requirements analysis beforehand. This will also help avoid undermining the customer's position in the students' view.
Our experiences come from a software engineering major that has set aside enough time to facilitate one-year-long projects. However, we believe that schools could incorporate similar one-semester projects into their curricula, especially in more traditional computer science majors. Also, experience from other universities shows that such one-semester projects can be successfully conducted in the context of visualization. 10
We're convinced that software engineering skills are critical for the employability of most students in computer-science-related majors. We've also seen that typical software engineering issues such as finding a common language with the customer have been observed in projects not targeting software engineering education. 2
Fitting the project into one semester will require streamlining it. The combination of seminar, lecture, and practical project work in one joint teaching unit will likely have to be abandoned. Instead, a course on the project's topic (for example, an information visualization course) should be a prerequisite for the project. In this way, the theoretical foundation will be laid earlier than in the project structure we described previously. If educators properly choose the project topic and prerequisite, the seminar might become obsolete because we use it mainly to jump-start the project with background information. Such reorganization would reduce the project's start-up portion by about two months.
Shortening the proposal phase is much more problematic because in it the students can contribute their own ideas and still steer the development's general direction, making the project's results their own. Slightly reducing the proposals' and presentations' formality will probably be more helpful than removing the one phase in which the students can concentrate most on the creative aspect of their assignment.
The interaction with the customer—formalizing the requirements and convincing the customer to fix requirements, thus producing a quantifiable, precise specification—is perhaps the main point of software engineering education. Students must understand that software development reality means offering what's feasible in a given amount of time, compared to the often far less realistic customer demands. The later phases are thus driven mostly by the possibly precise goals formulated in the relevant documents. Later changes with a nonlocal scope will involve several documents and become so costly as to effectively quench even the best ideas for improvement, owing to time constraints. 9
So, for software engineering teaching goals, skipping requirements specification isn't an option.
Judging by the typical timeline of a one-year project as depicted in Figure 1
, it's obvious that more than one iteration won't fit in a single semester. It's also evident that for the project's main task, erring on the side of simplicity is preferable. To regain some flexibility, the faculty must formulate the task such that parts of the requirements can be removed without jeopardizing the overall system's functionality. Furthermore, the faculty will need to prevent the students from making those mistakes that the students could have ironed out themselves in a longer project.
Team projects are a reasonable—if somewhat idealized—approximation of real-world working conditions for software engineers. As such, they're an integral part of the University of Stuttgart's software engineering curriculum. The project phases are simplified and sometimes more thoroughly formalized than is common today. However, they successfully teach many of the pitfalls that originate from working in a larger team with an external customer:
• The customer is never satisfied and must be convinced that only a limited number of features can be implemented at a time.
• A large team, instead of chiefly offering increased human resources, causes considerable friction and requires resources to be organized.
• Social interaction and the ensuing problems mustn't be underestimated.
The students must constantly control numerous factors, including the constraints of the formal software engineering process. This teaches them the importance of organization and communication more quickly and thoroughly than any theoretical approach.
We've found visualization topics to be of great interest to students and therefore a motivating way to teach practical aspects of computer science. At the same time, students have gained profound knowledge of visualization that would hardly be possible with just regular homework assignments.
is a PhD student at the University of Stuttgart's Visualization Research Center. Contact him at firstname.lastname@example.org.
is a postdoctoral researcher at the University of Stuttgart's Visualization Research Center. Contact him at email@example.com.
is a postdoctoral researcher at the University of Stuttgart's Visualization Research Center. Contact him at firstname.lastname@example.org.
is a professor of computer science at the University of Stuttgart's Visualization Research Center. Contact him at email@example.com.