=Paper=
{{Paper
|id=Vol-2308/isee2019paper03
|storemode=property
|title=Interdisciplinary System Courses - Teaching Agile Systems Engineering
|pdfUrl=https://ceur-ws.org/Vol-2308/isee2019paper03.pdf
|volume=Vol-2308
|authors=Mariana Avezum,Andreas Seitz,Stefan Wagner,Bernd Bruegge
|dblpUrl=https://dblp.org/rec/conf/se/AvezumSWB19
}}
==Interdisciplinary System Courses - Teaching Agile Systems Engineering==
https://ceur-ws.org/Vol-2308/isee2019paper03.pdf
Interdisciplinary System Courses – Teaching Agile
Systems Engineering
Andreas Seitz, Mariana Avezum, Bernd Bruegge Stefan Wagner
Chair for Applied Software Engineering Institute of Software Technology
Technische Universität München University of Stuttgart
Munich, Germany Stuttgart, Germany
seitz@in.tum.de, m.avezum@tum.de, bruegge@in.tum.de stefan.wagner@iste.uni-stuttgart.de
Abstract—With the advent of technologies like the Internet of The ISC concept addresses the following three challenges:
Things, Industry 4.0 and Cyber-Physical Systems, many software 1) Interdisciplinary teams with different skill sets, ways of
engineering courses turn into system engineering courses. Recent
advances in technologies such as 3D printing and low-cost working and terminology
micro controllers enable to teach agile hard- and software co- 2) Producing hard- and software prototype system in a few
design in system engineering courses. In this paper, we describe days up to a few weeks
Interdisciplinary System Courses (ISC) – a teaching approach 3) Solving real problems by integrating industry as cus-
based on interdisciplinary projects, light-weight agile techniques tomer and domain experts
and solving real problems by integrating industry customers.
We describe our experiences from an exploratory case study In order to achieve these goals, we will present how we
where we applied ISC in a two-week international summer school implemented ISC through a 2-week course, overcame commu-
with a customer from the aerospace industry. We derive a set of nication problems, and taught the participants to implement
hypotheses on the effects of ISC. a system consisting of both hardware and software compo-
Index Terms—interdisciplinary, teaching, agile, hardware, soft-
ware, systems course nents.The paper is structured as follows: Section II deals with
the basics of ISC and shows relevant fields of research. In
I. I NTRODUCTION Section III, we explain the concept of ISC and its structure.
In the case study in section Section IV, we show how we
With the advent of technologies such as Internet of Things, applied ISC in a two-week summer school. The exploratory
Industry 4.0 and Cyber-Physical Systems, systems engineering study enabled us to evaluate the concept of ISC. We present
integrates evermore software engineering aspects. These sys- the general findings and derived hypotheses. The paper ends
tems do not only consist of software but also various types with the conclusion in Section VI, where we summarize the
of hardware. This means that we not only have software contributions and give an outlook on future work.
engineers in the team but require interdisciplinary work, whose
development process often is different than software. II. F OUNDATIONS
At the same time, these software/hardware systems are more An established approach for the introduction not only of
and more under the same pressures as pure software systems software engineering but also of concepts such as Scrum
to be able to innovate quickly in short cycles. In software are capstone courses, which have been around for a while
engineering, this gave birth to agile software development, [4] [5]. While these have been known to have good results,
whose application to hardware development [1]–[3] is still in introducing interdisciplinary systems engineering and hard-
its infancy. This makes working together in an interdisciplinary ware components can directly conflict with Scrum concepts
project difficult. such as incremental and continuous iterations. To bridge these
One approach to reduce this challenge in industry is to challenges, we look into relevant foundations to support the
familiarize systems engineering students with these agile organization of the ISC course.
concepts still in their studies. To let participants already
experience these difficulties and to work on making agile hard- A. Systems Engineering Teaching
and software development a reality, we propose the format After the publication of the Agile Manifesto in 2001 [6],
of Interdisciplinary System Courses (ISC). The idea is to put different frameworks appeared as how to implement these
participants with different backgrounds – such as computer values in practice, the most common of which is Scrum. While
science, electrical engineering and mechanical engineering – these frameworks spread both in software engineering and in
in a realistic project setting and let them work together in teaching, the shift has been slower in hardware development.
an agile way. The format of a summer school outside normal Hardware development has traditionally used development
university constraints allow us to work together in a focused processes that go deep into the requirement elicitation, and
way while bringing in participants with various backgrounds many industries use the V-Model as it allows the system and
and experience levels. its interfaces to be completely defined before the system is
ISEE 2019: 2nd Workshop on Innovative Software Engineering Education @ SE19, Stuttgart, Germany 11
assembled [7]. This critical need of the industry has influ- participants to present formal UML models can present a good
enced systems engineering education, and university capstone learning opportunity.
courses usually follow the same development process. A Furthermore, they are also presented with informal methods,
review of engineering design capstone courses can be found which serve the same communication purpose, while giving
in [8]. the participants a greater creative freedom, and sometimes
These two different approaches pose a challenge for in- being easier for industry clients to understand. The Tornado
terdisciplinary courses as participants may not be used to Model suggests that participants prepare a Software Theater
communicating or working with a different development pro- of their results [12], which presents an opportunity to record
cess. While there have been teaching projects where these the presentations, and use it as a communication mechanism
differences are managed, such as [9], the system developed for all project stakeholders.
in that study was a highly complex one, which makes it
harder to reproduce the situation. As for industry, it has III. I NTERDISCIPLINARY S YSTEM C OURSES (ISC)
also tried to adapt agile practices for hardware development, In the following section we describe the concept, structure
however with mixed results [10]. One agile framework that and core values of ISC.
deals with different development cycles, and the integration
of the components thereof, is Scrum of Scrums. A. Features & Design
The aim of ISC is to bring together participants from
B. Scrum of Scrums different disciplines to work together on a challenging prob-
Systems that involve components from multiple disciplines, lem. The chosen course format is not a traditional one but
and both hardware and software subsystems, will unavoidably a condensed course, which helps the organisational aspects of
involve a certain complexity and larger groups than are usually having students from different degree programs work together.
found in Scrum teams. To adopt Scrum to larger teams, the The case study presented in Section IV takes place during
Scrum of Scrums method was introduced. the semester break and is aimed at motivated and talented
As the name suggests, this consists of layering different students who want to expand their horizons. ISC is not part of
Scrum teams into a new Scrum group, where representatives a curriculum. Students can apply for this programme and will
of the lower-layer Scrum teams report their status in a second then be selected based on their performance and a letter of
daily Scrum meeting [11]. This approach helps decompose motivation. Travel and accommodation costs will be covered
not only the developed system into smaller components, but for the participants.
also the dependencies between the different teams and people ISC is characterized by the following goals and design
involved. At the same time, it also ensures that the entire decisions:
complete team is kept up to date with the project’s status. (1) Interdisciplinarity: The core of ISC is interdisci-
Big dependencies on other components is a critical aspect plinarity. It is no longer sufficient for participants of individual
of hardware development, and thus, reducing these as much disciplines to solely work in their one domain. It is necessary
as possible makes it easier to introduce a faster development for them to be able to look beyond their subject areas and
process. Furthermore, the Scrum of Scrums framework also collaborate with other participants in other subject areas. Novel
allows for different development cycle lengths for each of technologies and the fusion of hardware and software require
the subsystems involved in the project, which then allows the cooperation across disciplines. The challenge here is different
hardware and software systems more flexibility in planning knowledge and processes. In addition, projects are becoming
for a development phase that better suits their capabilities and more and more demanding and cannot be realized with the
needs. knowledge of a single discipline.
(2) Agile Light-Weight Development Process: With re-
C. Tornado Model gard to the process, we deliberately opted for a loose, adapt-
When working with different independent teams, it is es- able and flexible process. We believe that this freedom can
sential to keep a close eye on system integration. As will be make cooperation more effective. In spite of all this freedom,
presented in Section IV, our summer school case study used there are also fixed deadlines and delivery times that the
the Tornado Model [5] to achieve this. It focuses on using participants have to meet. In ISC we apply the concept of
a scenario-based development approach, useful for teaching Chaordic Learning [13]. We give the participants the freedom
courses, where participants work toward a presentation at the to organize themselves, but create order through punctual
end of the project. structures. The participants are expected to produce a light-
By selecting a visionary scenario that presents features of all weight prototype of the system by the end of the course.
components in the system, not only does a complete prototype (3) Challenging Problem of Industrial Partners: To be
demonstration become possible, but also the minimal required able to challenge and motivate the participants of ISC, a real
interfaces become clear. To further understand and correctly problem with innovative solution possibilities is required. The
implement these interfaces, students from each sub-team are solution must require technical expertise from different fields
tasked to define and document these in system-wide models, and must be dynamically extensible. ISC requires industry
which can be accessed by all sub-teams. Encouraging the partners to formulate and define the problem on the basis of
ISEE 2019: 2nd Workshop on Innovative Software Engineering Education @ SE19, Stuttgart, Germany 12
their expert knowledge. Furthermore, they should be available distractions can be minimized, and the participants can fully
for the preparation meeting, design review and final customer concentrate on dealing with the problem.
acceptance test. Industry partner integration is also seen as a In addition to the working environment, the infrastructure
motivation source as the participants know that their work will is also important. ISC assumes that participants who have
be further used. everything they need to work can also work better and more ef-
ficiently. Depending on the problem statement, this can imply
B. Skills & Techniques special hardware and software. Since ISC involves elements
To achieve these goals, the participants required core skills of systems engineering, it also covers areas such as agile
and tools which were taught throughout the course. manufacturing. This requires special infrastructure such as 3D-
Communication & Soft Skills: An important aspect to printers and hardware prototyping material. Micro controllers
address the challenges of interdisciplinary is efficient commu- such as Arduinos and RaspberryPIs are often necessary to form
nication. The terminology and prior knowledge of the partici- the interfaces between the hardware and software components.
pants are initially heterogeneous. Their different backgrounds D. Structure
result fundamentally different ways of working. While com-
puter science and software engineering participants are usually ISC is divided into 3 phases: (1) Preparation Phase, (2)
familiar with agile methods, other participants most often Development Phase and (3) Integration Phase (cf. Figure 1).
have no such experience, and thus it is important to provide
them with a relevant theoretical overview and materials, in Preparation Design
Customer
Kickoff Acceptance
order for the necessary terminology to get better understood. Meeting Review
Test
Furthermore, ways and means must be found to facilitate
cooperation between the disciplines.
Videos as Communication Models: A saying goes, a 12 weeks 1 week 1 week
picture says more than a thousand words. In ISC the motto Preparation (1): Research, & Component Preparation Development (2) & Integration (3)
is: a video says more than a thousand words. In the course of
ISC, we strongly rely on the use of videos as communication Fig. 1. Timeline of ISC: The preparation takes place before the actual course
models. starts. During the period of the ISC course, development of the subsystems
is first carried out and then integrated.
First, it supports the problem description. Today, the web
offers a variety of videos that can be used to illuminate and In the course of ISC different events with specific meaning
underscore problems, especially useful for cases where logistic are planned. We explain in detail the different events:
or organisational constraints make it hard for the students to
Preparation Meeting: The Preparation Meeting is the first
physically see the problem. Many problems today are solved
time that the participants of an ISC course as well as the
by analog or conventional approaches, which can be shown to
organizers and industry partners come together. The aim of
the students through videos. In order for the students in ISC
the meeting is to get to know each other, to understand the
to reach their goal and tackle these problems digitally, it is
problem, and to distribute work packages for the participants.
important that they understand the problem domain first.
The industry customer presents the problem to be dealt with
Second, videos are also used to visualize solution concepts. in the form of scenarios. Before this meeting, the industry
The participants of ISC record their ideas in videos and share partners and organizers jointly create an initial top-level design
them with their team members and project partners from of the architecture which is a key discussion point of the
industry. meeting. This architecture is then presented to the participants
On-Site Application Domain Expert: The participants of of ISC for the first time. Starting from the architecture,
ISC are solution domain experts but usually have little prior technological requirements and subsystem are defined. These
knowledge of the application domain. To close this gap, ISC form the basis for the teams that have to complete preparation
relies on the fact that an expert of the application domain tasks in the next 12 weeks, and thus the initial team allocation
is available for questions. This expert can thus influence the is done during the Preparation Meeting as well.
developed solutions and ensure that the developed systems Kickoff: After the arrival at the location where ISC takes
also meet expectations. In direct, non-formal communication, place the Kickoff Meeting happens. The problem statement
the requirements of a system can be constantly updated and will be discussed in more detail on the spot. To support team
checked. Having this expert physically present during the ISC building and create a nice atmosphere, an ice breaker is done
also ensures efficient communication channels. with all participants. Ideally, the icebreaker can be based on the
topic to be worked on and should clarify the motivation and the
C. Infrastructure & Environment
understanding of the problem. Subsequently, each sub-team
An essential part of ISC is the working environment and presents the results of the project work they have achieved in
infrastructure. ISC intends to take all participants out of the past 12 weeks during preparation. The focus will be on a
their familiar working environment and to accommodate them demonstration of what has already been achieved and how it
together in one place for a certain period of time. This way, should be incorporated into the common vision.
ISEE 2019: 2nd Workshop on Innovative Software Engineering Education @ SE19, Stuttgart, Germany 13
Design Review: The Design Review takes place halfway scenario that can be realized in the short time frame of the
through the ISC course. All participants, application domain course and can also be demonstrated. Action items then result
experts, and organizers come together to discuss the progress from the demo scenario. These should be realizable within
of the project. Depending on their time availability, industry one day. Unlike Scrum, the daily result of ISC is not a
partners may attend this or not. The focus is on design. Each potentially shippable product but either a demonstration or a
sub-team will present its progress and any challenges they may video demonstrating the functionality.
face and give a glimpse of what they expect to achieve in the
time remaining. IV. C ASE S TUDY
In preparation for this presentation, a video trailer can be In order to implement the objectives described in Section III,
produced. This trailer serves as a means of communication Chaordic learning [13] was used to address a problem state-
between participants and industry partners, to synchronize the ment presented by an aerospace industry partner. While the
vision of both parties. The trailer can also be sent to the ISC instructors did provide general topics to be researched
industry partner in case they could not attend the meeting. before the 2-week course and divided all the participants into
Customer Acceptance Test: Finally, there will be a joint sub-teams, the exact definition of who was responsible for
event: the Customer Acceptance Test. This event serves to what in each sub-team, which technologies to use, and what
present the final results achieved by the participants and to tasks to prioritize was self-organized by the participants.
have them accepted by the customer/industry partner. The form In the Kick-off meeting the participants were presented with
of the presentation is left to the participants. While slides can a problem statement from an aerospace industry partner and
be used for communication, the main focus is to demonstrate a used that as a common reference to set the tasks developed
demo scenario and the functionality of the developed system. during the 2-week course. The industry partner wishes to assist
rescue agencies such as the red cross after any type of natural
E. Process disaster, and thus the ISC participants should develop a Multi
Between the fixed events, ISC provides a lightweight agile Operational Drone Collaboration Platform (MODCAP).
process. It is divided into three sprints. Sprint 1 between the Problem Statement: Agencies such as the Red Cross need
Preparation Meeting and the Kickoff Meeting, Sprint 2 be- to coordinate and plan relief efforts after disasters. The focus
tween the Kickoff Meeting and the Design Review, and Sprint of the project developed in our ISC implementation was to
3 between the Design Review and the Customer Acceptance collect and analyze data gathered by any available fleet of
Test. During ISC, a typical day starts with a group breakfast, drones in disaster areas.
followed by a Daily Stand Up Meeting. MODCAP is a platform that orchestrates a collection of
drones to perform search and rescue missions after natural
Team 1
Action Items disasters. Furthermore, the data collected by the platform
Daily Event
should be used to map geographical changes caused by these
Wrap Up
disasters, as well as to help in the survivor rescue operations.
Visionary Scenario
To further assist the survivor rescue operations, the MODCAP
Team 2
Scenario
Demo
1 Day platform should also allow for the modular integration of any
Demo
Team 3
Shippable
smart wearable device the victim may be using, such as Smart
Stand Up Video
Watches, or any transceivers, as is common for skiers to use
on avalanche-prone areas.
Fig. 2. ISC Process: Starting from a Visionary Scenario, this is broken down A. Infrastructure & Environment
to a Demo Scenario. This demo scenario will be divided into action items
which will be processed by the different sub-teams. Daily Scrum Meetings
The ISC concept was implemented during a 2-week course
take place in the morning with each sub-team. where internet and hardware accessibility were limited, which
is why most of the necessary infrastructure was transported by
In this meeting everyone individually reports the progress the organizers to the location. In this section, we explain how
of the previous day, the impediments they have and promises the environment and technical infrastructure made available
what they want to achieve in the course of the day. In this con- influenced the implementation of the course.
text, it is also worth mentioning that between the working days To facilitate the adoption of agile manufacturing techniques
there are also days for leisure time. The combination of work and simultaneously keep a light-weight development process,
and leisure is important since it motivates the participants. rapid prototyping equipment was made available to all of
The process is visualized in Figure 2. While the division into the participants. This includes, but is not limited to, a 3D-
sub-teams can be loosened, it is important for each participant printer and prototyping electronics such as Raspberry Pis and
to have well-defined tasks, that do not rely too much on other Arduinos. Since the problem statement implemented by the
subsystems, as that would hinder the agility of the process. The participant’s had some drone components, it was important
visionary scenario describes the functionality to be provided for the available electronics to be able to interface to the
by the future system [14]; this can be tailored to a demo drone’s software development kit. This hardware allowed for
scenario. The demo scenario is an excerpt from the visionary the different teams to quickly test and iterate their components.
ISEE 2019: 2nd Workshop on Innovative Software Engineering Education @ SE19, Stuttgart, Germany 14
One example of hardware iteration can be seen in the scoop
mechanism developed for the drone. The idea behind the
mechanism was to modularly connect a component to the
drone so that samples of the areas affected by the disaster
could be collected. As this mechanism was to be attached to
any available drones in the area, it was important to keep it
as modular as possible, but also stable enough to grab any
necessary samples of the area. To solve this, the participants
initially designed a sample mechanism, designed for a DJI
Phantom 4, however, the first iteration of the component did
not really fit the drone. By the end of the first iteration,
they had adjusted the size and tested the component in flight,
however, the stability of the system proved to be insufficient
to actually snatch any sample from the ground. This was then
successfully fixed in the following phase of the project.
An important aspect of agile development is the communi- Fig. 3. Work Environment
cation between developers. While this is classically supported
through the use of online issue tracking tools, this was not
possible due to the limited internet connectivity of the location
where we carried out ISC. Furthermore, the fact that all
participants were located in the same place meant that they
could exchange much information through informal meetings,
which greatly helped communication and fast decision making.
To allow all participants to keep track of the system’s status,
pen and paper were used in the place of online issue trackers,
and a Kanban board with Backlog, In Progress, and Done
columns was set up, as can be seen in Figure 4. Post-its were
used for each task, where the exact action item and person
responsible for it were written down.
At both the Design Review and Customer Acceptance Test Fig. 4. Kanban with Pen & Paper
milestones, a system scenario was presented. In the Design
Review, the status was discussed between all participants and
the organizers, and a video trailer was used to demonstrate we believe that a team assignment based on personal pref-
the scenario envisioned by the end of the two weeks. This erence increases team motivation and allows the participants
really helped the participants to know which tasks to focus on the opportunity to learn new skills based on what they enjoy.
during the second week of the project, as these were the exact Furthermore, the fact that this team assignment was made
features to be demonstrated to the industry partner client at several weeks before the kick-off meant that the participants
the Customer Acceptance Test. had time to research, prepare, and learn any fundamental skill
It should also be noted that our industry partner appreciated sets that would be required during the two development weeks.
the video trailer, as it allowed them to easily explain to
objectives of the system to several other stakeholders inside To get everyone onto the same page as far as what was
of the company, who were not involved in the process. possible or not during the two weeks, right on the first day
of the ISC, each sub-team presented their research results.
B. Team Work These were short 10-15min presentation from each sub-team,
The fact that the ISC participants came from different study where some initial feedback was already provided as to how
courses meant that they individually had very different skill far their expectations were realistic. These presentations lead
sets. Furthermore, the Problem Statement presented to them to important discussions on necessary frameworks, interfaces,
required different backgrounds and a considerable amount of and further capabilities. We have deliberately not defined a
both hardware and software components. format here in which way the presentation should take place,
As presented in Section III, all participants of the summer to allow for self-organization of the different teams.
school met for a Preparation Meeting a few weeks before the Another activity that was important at the beginning of the
Kick Off. It is relevant to note that the team assignment that ISC was the Ice-breaker. The participants simulated a search
took place in the Kick-Off Meeting, was not done based on and rescue operation, with the use of an analogue transceiver.
skill set, but on the participant’s personal preference. This helped them not only bond more and overcome their
While a skill set based assignment could make the develop- different background, but also gave them insights in the current
ment easier (and perhaps even produce a better final system), state of the art of the systems they would be working on.
ISEE 2019: 2nd Workshop on Innovative Software Engineering Education @ SE19, Stuttgart, Germany 15
V. C ASE S TUDY E VALUATION The participation in the Ferienakademie improved my skills in...
6
In this section, we will look at the exploratory study
Strongly Agree ------------ Strongly Disagree
we conducted during the case study and evaluate what the 5
participants thought of the ISC. Based on a questionnaire sent
to the participants, we present the results below and discuss 4
the participants’ feedback.
A. Objectives & Design 3
We carried out an exploratory study and collected data
2
from the participants by means of a questionnaire to verify
our assumptions as well as to validate whether the goals
1
of the applied methodology are met. The questionnaire was
distributed to the participants shortly after the Design Review, System Design Programming Prototyping Communication Team Work
around halfway through the course. The questionnaire focuses
on the following research questions: Fig. 5. Skill Improvement Box-Plot
1) Interdisciplinarity: Effects of different backgrounds of
participants on how they work together.
2) Agile Light-weight Process: Effects of the chosen en- 2) Interdisciplinarity: The participants overwhelmingly
gineering approach regarding high-level scenarios, daily stated that the communication with participants from other
scrum meetings, demos, simple architecture descriptions areas was easy (median = 6, min = 2, max = 6). We also
3) Software Theater: The effects and implications of using asked how communication on the sub-team level worked.
videos during the course to visualize problems. The Communication within the sub-teams (median = 5, min = 2,
videos serve as a communication model between the max = 6) as well as with the other sub-teams (median = 5,
participants and the industry partners. min = 1, max = 6) were seen as working well.
The open question about describing the challenges and
B. Questionnaire problems of working with fellow participants, however, reveals
Altogether we distributed the questionnaire to 19 partici- challenges: The participants report that it was difficult to
pants, all of whom answered. The questionnaire contains 29 define a common understanding of the tasks and problems
questions which are divided into 4 free-form questions, 24 (e.g. “differing implicit assumptions”). We also observed a
Likert item questions and 1 multiple-choice question. The heterogeneous previous knowledge that could be overcome
questions are divided into the subject areas: interdisciplinarity, through the course of time (“Unclear what skills people have”).
process model and utilization of videos within the course. Yet, several participants also reported no problems.
The applied Likert scale ranges from 1 (strongly agree) to While the ISC structure probably contributed to the in-
6 (strongly disagree). The mean and median values in the terdisciplinary communication flow, there are further relevant
following section refer to this scale. aspects that may also have avoided problems in this regard.
C. Results The free-text answers of the questionnaire indicate that the
location played an important role in relaxing the students, and
In the following, we describe the answers to the general
that the free time activities helped them bond together. While
and to each research questions, for which we then propose
an ice-breaker is part of the ISC structure, currently no data is
hypotheses that are suggested by the data.
1) General Questions: Of our ISC participants, 26% have available whether that was enough to reduce communication
never previously worked with participants from other depart- problems, or to what extent other activities contributed com-
ments or disciplines. For 16% it was their second collaboration pared to it. The importance of the environment, however, is
and 58% had already collaborated once with participants of supported by the fact that all participants of the questionnaire
other departments or disciplines in projects before ISC. agreed with the statement ”You could work well in the created
Figure 5 shows the self-assessed learning of the participants working environment (atmosphere, room, food).”
with regards to communication, programming, prototyping, While the cause behind the improved interdisciplinary com-
system design and team work. A learning experience could be munication may be disputed, our data indicated that cross
established across all points. However, it is also clear that ISC team communication in the ISC worked well. Interdisciplinary
is not a programming course, but a systems engineering course communication and work is commonly problematic in other
where the focus on interdisciplinarity and team collaboration contexts, for example, because of misunderstandings [15],
is more important than the actual implementation. [16], and we see little problems due to interdisciplinarity in
The answer to the question whether the participants would ISC. Therefore, we formulate the following hypothesis:
recommend the ISC summer school to other participants is
extremely clear. Here, 16 out of 19 participants absolutely Hypothesis 1: The ISC concept reduces interdisci-
agree and none of the participants disagrees with this opinion. plinary communication problems.
We regard this as a success of the overall concept.
ISEE 2019: 2nd Workshop on Innovative Software Engineering Education @ SE19, Stuttgart, Germany 16
3) Agile Light-Weight Process: We also evaluated the ap- earlier the actual values would have been received earlier, and
plied agile process. The whole process was considered suitable perhaps the system could have delivered a better performance.
for the project (median = 5, min = 3, max = 6). In the free
text answers, the participants suggest that some of the meetings Hypothesis 2: System iterations support development,
lasted too long. There are also mentions that an earlier focus but complete subsystems decoupling hinders integration.
on integration would be useful.
When looking at the system iterations in particular, par-
ticipants agreed that these were relevant to the development 4) Problem Statement Understanding: Due to the different
process (median = 2, min = 1, max = 4). Given the fact that background from the participants, common understanding of
students outside of the software engineering environment had the problem statement was of special importance. In the
limited previous access to agile processes and iterations, this questionnaire, we asked how the different communication
can be seen a meaningful contribution of ISC. Figure 6 shows approaches facilitated this. We initially communicated the
the detailed distribution of answers. problem in written form as a problem description. 74% of
the participants agreed on the importance of this.
System iterations were an important part of the development
The ice-breaker activity previously mentioned, further
process. served the double function of showing the students how search
8 and rescue operations are manually done today. It is relevant to
7 note that this was in the beginning of the course, and thus, the
6 general understanding of the problem was somewhat vague. By
5 providing the students with a transceiver to find hidden objects
4 in a field, the students both had fun, and learned something
3
2
about the real world use of the system they were to develop.
1 The introduction of software theater aimed to further sup-
0 port the understanding. The participants also watched videos
Strongly Agree Slighlty Slightly Disagree Strongly that showed them how search and rescue operations currently
Agree Agree Disagree Disagree function, and this showed to be a good communication tool.
78% of the participants approved of the use of video tools.
Fig. 6. System Iteration Value
The free text answers suggest that participants considered Problem Statement Understanding
the meetings communicating the status as useful and impor- 12
tant. It is however relevant to note that not all days spent 10
Number Occurrences
during the ISC were work days, and there were some entire 8
leisure days as well. In these cases, the morning meeting in
6
the following day was sometimes criticised, as the participants
4
had not achieved any work progress during the leisure day, and
the meeting content thus became repetitive. 2
One aspect of agile development that was not adequately 0
accessed in our evaluation were the problems and benefits Strongly
Agree
Agree Slighlty Agree Slightly
Disagree
Disagree Strongly
Disagree
of the Scrum of Scrums element. While both internal sub-
Textual Description Manual Activity Videos Domain Expert
team meetings and meetings with all sub-team took place, it
is possible that the latter happened with too many participants,
thus diminishing it’s efficiency. Perhaps a more rigorous, with Fig. 7. Value of Each Understanding Technique
fewer people, implementation of the Scrum of Scrum process
could have aided in the integration problems, however, it Figure 7 depicts the student’s assessment of the usefulness
would likely also have diminished the learning effect, by of each of the different techniques used. As can be seen,
limiting the number of students receiving input from other the tool which showed most useful for problem statement
sub teams. understanding was the exchange with the expert from the
Furthermore, the questionnaire also suggest insights as to application domain (median = 2, min = 1, max = 4). While
why the system integration became problematic at the end, this may also be due to the fact that the remote location of
even when the iterations were evaluated as useful. While the course made the expert a more reachable resource, wee
the interfaces between each sub-team was defined, and the postulate that this finding may perhaps be generalized.
participants did know what they had to deliver for the demo-
scenario, the data received from the external drone control Hypothesis 3: Exchange with a domain expert encour-
library was different than expected, and at the end of the ISC ages system understanding and problem solving.
there was not enough time to fix this. Had integration begun
ISEE 2019: 2nd Workshop on Innovative Software Engineering Education @ SE19, Stuttgart, Germany 17
D. Discussion The paper explains the concept of ISC to make it feasible
All in all, we can say that the assumptions we have made for other universities and organizations to apply the method.
regarding the ISC concept are working out well. We discuss We plan to continue running ISC courses in the coming years
the three goals described in the beginning and the feedback and want to apply the knowledge and experience to further
from both the participants and industry partners. improve the teaching of these innovative course formats.
As far as interdisciplinary teams go, both the quantitative R EFERENCES
and qualitative feedback from the participants show that they
[1] P. M. Huang, A. G. Darrin, and A. A. Knuth, “Agile hardware and
learned how to communicate with people from other back- software system engineering for innovation,” in Aerospace Conference,
grounds. Our industry partner also mentioned that the fact 2012 IEEE, pp. 1–10, IEEE, 2012.
that participants from different disciplines participated in the [2] T. Punkka, “Agile hardware and co-design,” in Embedded Systems
Conference, 2012.
project as interesting for them. [3] S. Wagner, “Scrum for cyber-physical systems: a process proposal,” in
At the end of ISC, the state of the developed system was 1st International Workshop on Rapid Continuous Software Engineering,
only partially working. While the individual sub-teams mostly RCoSE 2014, pp. 51–56, ACM, 2014.
[4] V. Mahnic, “A capstone course on agile software development using
achieved their goals, the integration process required more scrum,” IEEE Transactions on Education, vol. 55, no. 1, pp. 99–106,
time than was available in the end, thus resulting in one part of 2012.
[5] B. Bruegge, S. Krusche, and L. Alperowitz, “Software engineering
the demo scenario not working. While this was of concern to project courses with industrial clients,” Trans. Comput. Educ., vol. 15,
our industry partner, who was interested in the actual achieved pp. 17:1–17:31, Dec. 2015.
results, it was not critical for the participant’s view, as they [6] K. Beck, M. Beedle, A. Van Bennekum, A. Cockburn, W. Cunningham,
M. Fowler, J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, et al.,
did learn from both the process and the non-performance. “Manifesto for agile software development,” 2001.
Last but not least, the collaboration with our industry partner [7] A.-P. Bröhl, Das V-Modell: Der Standard für die Softwareentwicklung
proved to be motivating for the participants. The visit from the mit Praxisleitfaden. Oldenbourg, 1993.
[8] A. J. Dutson, R. H. Todd, S. P. Magleby, and C. D. Sorensen, “A review
industry representatives in the Client Acceptance Test also was of literature on teaching engineering design through project-oriented
a good opportunity for the participants to understand how these capstone courses,” Journal of Engineering Education, vol. 86, no. 1,
systems are developed and considered in an industry context. pp. 17–28, 1997.
[9] L. Boskovski and M. Avezum, “Combining hardware and software
While the results of our case study can only be generalized development: A case study on interdisciplinary teaching projects.,” in
with caution, they do suggest that the approach presented by Software Engineering (Workshops), pp. 12–15, 2018.
ISC can stimulate more effective interdisciplinary teaching. [10] M. Glas and S. Ziemer, “Challenges for agile development of large
systems in the aviation industry,” in Proceedings of the 24th ACM SIG-
VI. C ONCLUSION PLAN conference companion on Object oriented programming systems
languages and applications, pp. 901–908, ACM, 2009.
In this paper, we present an approach to teach Interdisci- [11] L. Faria, “Scrum of scrums: Running agile on large projects,” Obtenido
plinary System Courses. In a case and explorative study, we de scrumalliance. org, Junio, 2013.
[12] S. Krusche, D. Dzvonyar, H. Xu, and B. Bruegge, “Software theater
show the applicability of the method. ISC focuses on the three - teaching demo-oriented prototyping,” ACM Trans. Comput. Educ.,
core areas interdisciplinarity, lightweight agile development vol. 18, pp. 10:1–10:30, July 2018.
process and real problem solving by having an industry part- [13] S. Krusche, B. Bruegge, I. Camilleri, K. Krinkin, A. Seitz, and
C. Wöbker, “Chaordic learning: A case study,” in Proceedings of
ner. The interdisciplinary aspect is achieved by focusing on the the 39th International Conference on Software Engineering: Software
parallel development of hardware and software components, Engineering and Education Track, ICSE-SEET ’17, (Piscataway, NJ,
the communication between individual sub-teams as well as USA), pp. 87–96, IEEE Press, 2017.
[14] B. Bruegge and A. H. Dutoit, Object-Oriented Software Engineering
collaboration between these. Using UML, Patterns and Java. Prentice Hall, 2009.
The case study and its evaluation show that the concept is [15] E. Cooley, “Training an interdisciplinary team in communication and
applicable and adds value for both the participants and the decision-making skills,” Small group research, vol. 25, no. 1, pp. 5–25,
1994.
industrial customers. Although the developed system leaves [16] T. W. Reader, R. Flin, K. Mearns, and B. H. Cuthbertson, “Interdis-
room for improvement, the realization of ISC and knowledge ciplinary communication in the intensive care unit,” British journal of
gained by the participants has proven to be a success. anaesthesia, vol. 98, no. 3, pp. 347–352, 2007.
ISEE 2019: 2nd Workshop on Innovative Software Engineering Education @ SE19, Stuttgart, Germany 18