=Paper=
{{Paper
|id=Vol-2066/isee2018paper02
|storemode=property
|title=Reaching Steady State in Software Engineering Project Courses
|pdfUrl=https://ceur-ws.org/Vol-2066/isee2018paper02.pdf
|volume=Vol-2066
|authors=Dora Dzvonyar,Bernd Bruegge
|dblpUrl=https://dblp.org/rec/conf/se/DzvonyarB18
}}
==Reaching Steady State in Software Engineering Project Courses==
https://ceur-ws.org/Vol-2066/isee2018paper02.pdf
Reaching Steady State in
Software Engineering Project Courses
Dora Dzvonyar Bernd Bruegge
Department of Informatics Department of Informatics
Technical University of Munich Technical University of Munich
Munich, Germany Munich, Germany
dzvonyar@in.tum.de bruegge@in.tum.de
Abstract—Project courses provide students with a hands-on goes through between the course kickoff and its termination.
experience of software engineering practices in industry and We then go into detail about the challenges students face in the
prepare them for their later career. The first weeks of such a Launch Phase during the first weeks of the course. While we
course typically involve change and uncertainty and are therefore
challenging for students: project teams have to understand do not aim to provide solutions, we give recommendations and
requirements that are often unclear, learn to work together examples of how instructors can support the teams in handling
and communicate as a team, as well as become accustomed to these challenges. Finally, we present and discuss the results of
processes and workflows used in the course. In this paper, we a qualitative analysis of students’ perspective of the first weeks
summarize our experiences of how student teams master change of a multi-project capstone course.
at the beginning of a project course to reach a steady state
in which the level of uncertainty is manageable. We describe II. C OURSE S TRUCTURE AND THE P ROJECT L IFECYCLE
the typical stages of a student project, go into detail on the
challenges during the Launch Phase and provide suggestions of This publication is based on our experience conducting the
how instructors can help students overcome those challenges. large multi-project capstone course iPraktikum with customers
We report both on our experience conducting project courses from industry and 10-12 projects per semester. We have
with clients from industry since 2008 and on the results of a
qualitative evaluation of one instance of a large multi-project described the course structure, our teaching methods and other
capstone course. aspects of the course in further detail in [5], [8], [10]–[15].
Each instance of the course runs for one semester and starts
I. I NTRODUCTION with a Kickoff meeting in which all industry partners present
Project work helps students apply and develop their software their problem to all participants. The instructors of the course
engineering skills in a realistic environment, thus preparing allocate project teams based on students’ priorities with the
them for their career in industry [1]. Project courses often goal of creating balanced teams regarding experience as well
involve industry partners to increase students’ motivation and as other factors described in [13]. Each project team consists
maximize educational effectiveness: by working on real-world of 6-10 developers, one team coach who is an experienced
problems, the course participants develop both their technical student having participated in the course as a developer before,
and soft skills, gain contacts to potential mentors in industry and a project leader who is a PhD candidate.
and get the satisfaction of working on a project that is not a After the Kickoff, the teams go through a period of 2-3
purely academic exercise [2], [3]. weeks, which we call Sprint 0. During this time, the focus
However, the realistic setting also introduces challenges is on reducing uncertainty in the project: the teams discuss
for the participants. The beginning of a project course is the requirements and verify them with the customer, conduct
particularly difficult, as students have to familiarize them- team building activities, set up the tools and test important
selves with development processes and tools, get to know workflows. Sprint 0 can be of varying duration depending
the project’s problem domain, understand requirements, and on the initial level of definition of the project as well as the
get acquainted with their fellow team members [4]. Some technological challenges involved.
projects are more clearly defined than others, resulting in Following Sprint 0, teams start developing based on our ag-
different initial situations and varying levels of uncertainty ile process model Rugby [10]. We hold two major events with
for the teams [5]. Instead of shielding students from these presentations from all teams: in the Design Review 8 weeks
challenges, instructors should design environments that enable after the beginning of the course, all teams present the result of
project teams to overcome them and learn from experience [6], their requirements analysis and system design activities, and
[7]. This task is challenging and time-consuming, especially the Client Acceptance Test marks the last milestone of the
with large courses or inexperienced instructors [8], [9]. course, after which teams wrap up their project by finishing
In this paper, we report on our experiences conducting large the documentation and conducting a retrospective.
capstone courses with industry partners since 2008. We first The aforementioned milestones of the course are visualized
describe our course structure and the phases a project typically in Figure 1 along with the typical phases we experience in the
ISEE 2018: 1st Workshop on Innovative Software Engineering Education @ SE18, Ulm, Germany 8
Retrospective
Kickoff Meeting
Design Review Client Accep-
Team Allocation
tance Test
Sprint 0 Development Sprints Final
Delivery
Week 1 Week 2 Week 3 Week 8 Week 12
Project A Launch Phase Steady State
Project B Launch Phase Steady State
Project C Launch Phase
Fig. 1. Course timeline and project phases (amount of red color signifies level of uncertainty).
projects. After the initial team allocation, projects go through III. C HALLENGES OF THE L AUNCH P HASE
a Launch Phase, a period of typically high uncertainty in We have grouped the typical challenges of project teams
which students have to familiarize themselves with a large during the Launch Phase into three categories visualized in
amount of information both general to software engineering Figure 2 and explain each in further detail in this section.
as a discipline, as well as specific to the problem domain of
their project. As the teams gradually reduce uncertainty, they A. Requirements
reach what we call a Steady State: while requirements can be Uncertainty resulting from factors around requirements is
refined or disambiguated during iterations, there should not be regarded as one of the highest risk factors in software projects
any changes that fundamentally alter or even derail the project, [16], thus it is not surprising that we also experience it as one
setting the team back by several weeks [10]. of the biggest challenges in our capstone courses. Involving
The duration of the Launch Phase depends on the initial industry partners in a course brings a more realistic experience
level of definition of a project. We visualize three examples for students, but it also introduces uncertainty compared to
in Figure 1. Project A reaches steady state during Sprint 0, a project that is fully defined by the instructor from the
which is the case for roughly half of the projects in the beginning [17]. For instance, some customers do not have
iPraktikum. This project is adequately defined by the customer a technical background and thus are not able to specify the
so that the team can fully understand the requirements and requirements sufficiently to be used as a basis for development.
decide on the initial system architecture as well as the main Students have to understand the visionary scenarios given
technologies involved, enabling them to start development by the customer, clarify ambiguous requirements, as well as
with a strongly reduced level of uncertainty. In the case of prioritize and negotiate requirements.
Project B, the Launch Phase outlasts Sprint 0 and overlaps In projects involving emerging or unstable technologies,
with the development sprints. This can be the case if the students need to do research to decide on frameworks or
problem is more abstract or involves technological challenges. products to use, and they might even find that the results
We describe the varying initial situations of student projects envisioned by the customer are not entirely feasible. Tech-
in our courses in further detail in [5]. In the past, an example nological challenges have been previously identified as a risk
of this type of project involved a NFC sensor that collected factor [18] and source of demotivation [19] in student projects.
shock and humidity data that was not yet fully developed by To name an example from a past course, one project aimed at
the manufacturer, requiring the team to reverse-engineer the saving blood glucose levels and other data of diabetic patients
protocol used to read and write sensor data before they were in Apple’s secure HealthKit database had to change direction
sure that they could use it for their purposes. when the team found out that the API did not support all kinds
Requirements
of measurements; they had to implement their own database
Finally, as Team C shows, some projects might not even and merge the data from both sources for analysis.
reach a steady state until the end of the course due to extremely In order to help students overcome challenges surrounding
highChallenges
uncertainty
for
and fundamental changes to the project requirements, instructors should encourage frequent communi-
throughout
Project Teams the semester. This situation should be prevented
cation between the customer and the team in the beginning of
Communi-
to avoid frustration of students and has happened very rarely
Processes the project. We place a strong emphasis on communication
cation in our courses. In such & Roles a case, the instructor should intervene
models in Sprint 0 because we believe that they enable
by, e.g., limiting the scope of the project. targeted, rich discussions between stakeholders, foster the cre-
ation of a shared mental model and expose misunderstandings
in requirements [5], [15]. In addition, we introduced a contin-
Requirements uous prototyping workflow and tool that allows developers to
easily deliver even early mock-up prototypes to stakeholders,
Challenges for gather feedback and iteratively transition to the delivery of
Project Teams
Communi- Processes
hybrid and code prototypes through the same channel [20]. Our
cation & Tools student teams use the workflow to regularly deliver potential
product increments to their customer and verify the progress
Fig. 2. Challenges for project teams in capstone courses. with them.
ISEE 2018: 1st Workshop on Innovative Software Engineering Education @ SE18, Ulm, Germany 9
B. Processes & Tools location: many course participants work next to their studies
As instructors, our goal is to introduce students to the or attend various other courses. This results in scheduling
processes and tools used in industry so that they can gain difficulties when trying to find a suitable time for the team
valuable knowledge for their later career [17]. However, this meeting or time to work together on the project. Scheduling
also increases the workload for students especially at the has also been reported by fellow researchers as a major source
beginning of the course, as they need to familiarize themselves of annoyance in student projects [18].
with a variety of new topics, from the principles of agile As instructors, we take cultural and scheduling factors into
software development through workflows such as continuous account when composing the teams [13]. However, we cannot
delivery, software modeling, prototyping, code reviews or do much to support teams in overcoming these hurdles in
meeting management [10]. The tools used in the course are a centralized way, as establishing communication processes
also new to most students: depending on their prior experience, and synergy is a very team-individual process. Instead, we
they have to get used to an issue tracker, repository and merge use the coaches and project leaders who work closely with
request system, continuous integration system and more. Prob- the developers. We urge the coaches to organize at least one
lems with tools have also been named as one of the top four icebreaker event in Sprint 0, in which they participate in a
risks in student projects, e.g., [18]. joint activity outside of the course context to get to know
As these topics are relevant to all teams, we use centralized each other. Furthermore, we teach them facilitation methods
teaching methods to transfer the necessary knowledge to all such as dealing with shy team members or agile retrospectives
participants. We hold a weekly course-wide lecture during the to establish a constructive feedback culture and react to issues
first month of the course in which we introduce all students arising in their team.
to the principles of agile software development, continuous
IV. C ASE S TUDY
delivery and UML modeling, including the tools supporting
these workflows. In addition, we have cross-functional teams In order to get a more accurate picture of how students
that consist of one team member per project and concentrate perceive the challenges in the Launch Phase, we conducted
on the major workflows of the course [11]. For instance, a qualitative evaluation in one instance of the iPraktikum. 78
we have a cross-functional team Release Management that developers and 12 team coaches participated in the course,
is concerned with the continuous integration and delivery which ran between October 2017 and February 2018. We sent
pipelines of the teams: the cross-project members get in-depth all participants a repeat questionnaire one, two, four and six
knowledge about the workflows, set up the tools in their team, weeks after the Kickoff on 19 October and asked them to
and get support from coaches and instructors as needed. They describe at least one problem or challenge they had been
then present the information that is important for the other facing in their team since the last time they received the
team members and make sure their team correctly adopts the questionnaire. Students had one week to answer the open-
workflows. This enables us to disseminate knowledge through ended question, with the promise that we would analyze their
an additional channel without burdening all team members responses anonymously and not use them for assessing their
with detailed information. contribution to the course in any way. The response rate
After giving course participants the necessary information, decreased slightly with each round, from 93.3% down to 70%
instructors should make sure that the workflows are correctly with the last questionnaire, which was sent out two weeks
applied in the teams, which can be a time-consuming task before the Design Review. We coded the responses using a
with multiple projects. We use a set of metrics to get a high- provisional coding technique [22], grouping codes into the
level view over the projects and only investigate further if the three categories described in Section III. Figure 3 shows the
metrics show issues, making our courses more manageable frequency of each code in the responses by questionnaire.
[8]. Our results show that students perceived unclear require-
ments as a challenge at the very beginning of their project,
C. Communication with 17.9% and 15.7% of responses containing a reference to
Issues around communication, team work and personal this issue after week 1 and 2 of the course. The frequency of
relationships are also among the top challenges in student this code dropped below 5% in the following questionnaires,
projects [18], [21]. We do not find this surprising: on top suggesting that most students felt they had reduced uncertainty
of the high workload in terms of understanding requirements in terms of unclear requirements after Sprint 0. However, they
and getting used to processes and tools, students need to get began to sense issues with the technologies involved in their
acquainted and start working productively with their fellow project from week 2 onward. Communication with fellow team
team members, most of whom they did not know prior to the members is the code with the highest frequency in all question-
course. Cultural and language issues can also get in the way naires, ranging from 17.5% to 27.1% of responses. Another
of establishing team synergy [19]. Customer communication is challenge in this category was “Synergy & Investment”, the
often an additional challenge if the customer is rarely available code under which we group responses referring to a lack of
for questions or does not have a technical background. trust or team spirit as well as differences in dedication and
Additional complexity is introduced by the fact that the de- time investment of team members; the frequency of this code
velopment teams do not spend every day working at the same increased dramatically in the last questionnaire, which was
ISEE 2018: 1st Workshop on Innovative Software Engineering Education @ SE18, Ulm, Germany 10
30%
Week 1 Week 2 Week 4 Week 6
20%
10%
0%
No REQ: REQ: REQ: REQ: COM: COM: COM: COM: COM: PRT: PRT: PRT: PRT: PRT:
problems Unclear Changes Missing Technology Customer Team Manage- Culture & Synergy & Decision- Scheduling Agile Infra- Meeting
Skills ment Personal Investment making Process structure Management
Fig. 3. Frequency of codes in students’ responses, categorized by challenges in Requirements (REQ), Communication (COM) and Processes & Tools (PRT).
sent out during a high-workload period filled with preparations R EFERENCES
for the first major event. In terms of processes and tools, [1] C. Ghezzi and D. Mandrioli, The Challenges of Software Engineering
students perceived challenges around the decision-making Education. Springer Berlin Heidelberg, 2006, pp. 115–127.
practices of their team, which includes answers referring to [2] C. Wohlin and B. Regnell, “Achieving industrial relevance in software
engineering education,” in CSEET ’99. IEEE, 1999, pp. 16–25.
unnecessarily long discussions or a lack of decisiveness and [3] R. Chatley and T. Field, “Lean Learning - Applying Lean Techniques to
compromise. Issues around finding times to meet and work as Improve Software Engineering Education,” in ICSE ’17. IEEE, 2017,
well as punctuality and time management, grouped under the pp. 117–126.
[4] B. Boehm and D. Port, “Educating software engineering students to
code “Scheduling”, were also recurring in the projects, which manage risk,” in ICSE ’01. IEEE, 2001, pp. 591–600.
is in line with the findings of, e.g., [18]. Problems referring [5] D. Dzvonyar, S. Krusche, and L. Alperowitz, “Real Projects with
to the course infrastructure increased as the course progressed Informal Models,” in MODELS ’14 EduSymp. ACM, 2014.
[6] S. A. Hernandez, “Team learning in a marketing principles course:
and students had to integrate and deliver a growing amount of Cooperative structures that facilitate active learning and higher level
features to their customer. thinking,” Journal of Marketing Education, vol. 24, no. 1, pp. 73–85,
Overall, our case study provided us with a deeper un- 2002.
[7] A. B. Kayes, “Experiential learning in teams,” Simulation & Gaming,
derstanding of students’ experience at the beginning of our vol. 36, no. 3, pp. 330–354, sep 2005.
project course. While it is debatable whether students can [8] L. Alperowitz, D. Dzvonyar, and B. Bruegge, “Metrics in Agile project
accurately assess and predict problems in a software project, courses,” in ICSE ’16. ACM, 2016, pp. 323–326.
[9] D. Coppit and J. M. Haddox-Schatz, “Large team projects in software
we were interested in their subjective perception of challenges engineering courses,” in SIGCSE ’05. ACM, 2005, p. 137.
and how these evolve over time. Each of our three clusters [10] S. Krusche, L. Alperowitz, B. Bruegge, and M. O. Wagner, “Rugby:
Requirements, Communication and Processes & Tools posed an agile process model based on continuous delivery,” in RCoSE ’14.
ACM, 2014, pp. 42–50.
challenges to participants of the course. More analysis is nec- [11] B. Bruegge, S. Krusche, and M. Wagner, “Teaching Tornado: from
essary to examine the impact of teaching methods described communication models to releases,” in MODELS ’12 EduSymp. ACM,
in Section III on students’ ability to tackle these challenges. 2012, pp. 5–12.
[12] D. Dzvonyar, D. Henze, L. Alperowitz, and B. Bruegge, “Algorithmi-
cally Supported Team Composition for Software Engineering Project
V. C ONCLUSION Courses,” in EDUCON ’18, accepted for publication.
In this publication, we described how projects in capstone [13] D. Dzvonyar, L. Alperowitz, D. Henze, and B. Bruegge, “Team Compo-
sition in Software Engineering Project Courses,” in SEEM ’18, submitted
courses reach a steady state by reducing change and uncer- for publication.
tainty, and the challenges they need to overcome to do so. [14] S. Krusche, D. Dzvonyar, H. Xu, and B. Bruegge, “Software Theater
We summarized how we experience the evolution of projects - Teaching Demo Oriented Prototyping,” Transactions on Computing
Education, 2018.
throughout our multi-project capstone course and described [15] L. Alperowitz, J. O. Johanssen, D. Dzvonyar, and B. Bruegge, “Modeling
typical challenges along with suggestions of how instructors in agile project courses,” in MODELS ’17 Satellite Events. CEUR-
can empower students to tackle those challenges. Finally, we WS.org, 2017, pp. 521–524.
[16] L. Wallace, M. Keil, and A. Rai, “Understanding software project risk:
gained a deeper understanding of students’ experience during a cluster analysis,” Information & Management, vol. 42, no. 1, pp. 115–
the first weeks of the course. 125, 2004.
We do not believe that there is a one-size-fits-all toolbox for [17] B. Boehm, A. Egyed, D. Port, A. Shah, J. Kwan, and R. Madachy,
“A stakeholder win-?win approach to software engineering education,”
instructors to ensure that student projects run smoothly, as the Annals of Software Engineering, vol. 6, no. 1/4, pp. 295–321, 1998.
course structure, nature of the projects and background of the [18] T. Ahtee and T. Poranen, “Risks in Students’ Software Projects,” in
people involved can differ widely. While we did not provide CSEET ’09. IEEE, 2009, pp. 154–157.
[19] I. Bosnić, I. Čavrak, M. Orlić, M. Žagar, and I. Crnković, “Student
concrete solutions, we hope that by reflecting on the Launch motivation in distributed software development projects,” in CTGDSD
Phase from both an instructor’s and a student’s perspective, we ’11. ACM, 2011, pp. 31–35.
inspired instructors to help students overcome the challenges [20] L. Alperowitz, A. M. Weintraud, S. C. Kofler, and B. Bruegge, “Con-
tinuous prototyping,” in RCoSE ’17. IEEE, 2017, pp. 36–42.
in their projects. In the future, we want to examine the impact [21] C. Bastarrica, D. Perovich, and M. M. Samary, “What can Students Get
of instructors’ teaching on the ability of students to tackle from a Software Engineering Capstone Course?” 2017.
these issues, and we are also analyzing the influence of team [22] M. B. Miles, A. M. Huberman, and J. Saldana, Qualitative data analysis.
Sage, 2013.
composition on teamwork and students’ experience at the
beginning of the course.
ISEE 2018: 1st Workshop on Innovative Software Engineering Education @ SE18, Ulm, Germany 11