=Paper=
{{Paper
|id=Vol-2358/paper-11
|storemode=property
|title=Teaching Rationale Management in Agile Project Courses
|pdfUrl=https://ceur-ws.org/Vol-2358/paper-11.pdf
|volume=Vol-2358
|authors=Anja Kleebaum,Jan Ole Johanssen,Barbara Paech,Bernd Bruegge
|dblpUrl=https://dblp.org/rec/conf/seuh/KleebaumJPB19
}}
==Teaching Rationale Management in Agile Project Courses==
https://ceur-ws.org/Vol-2358/paper-11.pdf
Teaching Rationale Management in
Agile Project Courses
Anja Kleebaum1 , Jan Ole Johanssen2 , Barbara Paech1 , and Bernd Bruegge2
1
Heidelberg University, Heidelberg, Germany
2
Technical University of Munich, Munich, Germany
kleebaum@informatik.uni-heidelberg.de, jan.johanssen@tum.de,
paech@informatik.uni-heidelberg.de, bruegge@in.tum.de
Abstract of this lecture is to teach a rationale model to stu-
Rationale management is beneficial since it supports dents, to introduce them to methods and tool support
decision-making and prevents knowledge vaporiza- for rationale management, and to motivate them to
tion. To apply rationale management, developers need apply rationale management in the future. We gave
to know how to systematically capture rationale and this lecture as part of an agile multi-project course at
how to exploit the documentation. We believe that the Technical University of Munich, in which student
teaching these skills to students further integrates ra- teams work on different software projects over the
tionale management into the daily work of developers period of one semester. The projects are initiated by
and has positive effects on both the software develop- industrial customers [4]. As a default set of tools, the
ment process and on the quality of the software. In students use the issue tracking system JIRA and the
this paper, we report on a lecture on teaching ratio- wiki system Confluence. During the lecture, we pre-
nale management to students. In this lecture, students sented our methods on rationale management to the
are introduced to a rationale model, to capture and students and they applied parts of our tool support.
exploitation methods, and tool support for rationale We asked students for their feedback on the presented
management. The goal is to motivate them to apply tools and to perform exercises.
rationale management. We present the students’ re- This paper is structured as follows. In Section 2, we
sults as well as their attitude and feedback towards the outline background knowledge on rationale manage-
applied methods. Further, we sketch how rationale ment and the agile multi-project course. In Section 3,
management will be applied during the semester. we present our teaching material including six exer-
cises, and the course of the lecture. Then, we sum-
marize the students’ feedback, present the exercise
1 Introduction results, and discuss lessons learned. In Section 4, we
Developing software means to continuously solve is- describe plans on how to evaluate rationale manage-
sues and to make decisions. Developers possess knowl- ment during the agile project course. Section 5 lists
edge about decisions, the issues they solve, alterna- related work and Section 6 concludes the paper.
tives, and their justifications. This knowledge is called
decision knowledge or rationale. The success of a 2 Background
development project strongly depends on the decision- This section introduces the rationale model we use,
making abilities of the developers and other relevant basics about issue tracking and wiki systems, our pre-
stakeholders. Rationale management supports explicit vious work on integrating rationale management into
decision-making by capturing rationale and by using agile software development, and a description of the
the documentation [7]. Developers are said to be re- agile multi-project course that the lecture is part of.
luctant to capture rationale systematically [1, 14, 18].
We believe that this can be alleviated by teaching de- 2.1 Rationale Models
velopers how to capture rationale and by raising their A rationale model represents knowledge in the same
awareness for the benefits of rationale management. way a system model represents a system. Rationale
As part of our previous work, we developed meth- can be modeled as a graph of rationale elements
ods and tool support to integrate rationale manage- and edges that represent the elements’ relationships.
ment into agile development processes, in particular There are various models for building such graphs of
into continuous software engineering [11, 12]. In rationale. In general, these models differ in the types
this paper, we report on a lecture on teaching ratio- of elements and edges that they allow. For example, an
nale management to university students. The goal advanced model is the decision documentation model,
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 125
Teaching Rationale Management in Agile Project Courses
Anja Kleebaum, Jan Ole Johanssen, Barbara Paech und Bernd Bruegge, Uni Heidelberg & TU München
Emoji Name Indicating Phrases 2.3 Continuous Rationale Management
I have a question . . . Agile processes support lightweight, flexible, and con-
How should . . . tinuous software development. Rationale manage-
Issue
. . . , any suggestions? ment integrates well into such processes, yet, it should
We need to discuss how . . . be easy to apply, i. e., developers should need as lit-
I { suggest | propose } . . . tle effort for it as possible. Capturing and explor-
Alternative One { option | proposal } is . . . ing rationale should be non-intrusive, which means
What { about | do you think } . . . that developers should be able to perform rationale
The { advantages | pros } are . . .
management as part of their daily practices rather
Pro I { like | prefer } it because . . . than having to change their development context.
I agree with user . . . For example, developers should be able to capture
and explore rationale simultaneously with performing
The { disadvantages | cons } are . . .
development tasks, implementing requirements, or
Con I don’t like it because . . .
I disagree with user . . .
committing code.
In order to fulfill this requirement of non-
Let’s do . . . intrusiveness, we develop tool support that directly
Decision We decided . . .
integrates into the development tools [12]. In particu-
The best option is . . .
lar, we integrate our tool support into the issue track-
ing system, version control system, wiki system, chat
Table 1: Types of rationale elements, their represent-
system, and the integrated development environment.
ing emoji, and indicating phrases adapted from [5].
We refer to our tool support as ConDec, standing for
the continuous management of decision knowledge.
which makes fine-grained differences in element types The ConDec tool support is available online.3
such as implications resulting from a decision or con- While ConDec comprises features to trigger devel-
straints that need to be considered [9]. There could opers in capturing and exploring rationale [11], in
be various types of relationships between rationale this paper, we focus on the basic infrastructure neces-
elements, for example, a decision can solve an issue sary for capturing and visualizing rationale as a graph.
or it can also lead to a new issue. Regarding the ConDec tool support, the students get
In order to teach rationale management, we use to know and apply the ConDec JIRA plugin, i. e., the
an easy-to-learn model to represent rationale. This tool support for the issue tracking system JIRA.
model covers five types of rationale elements: issue, The ConDec JIRA plugin supports different docu-
alternative, pro- and con-argument, and decision (Ta- mentation locations of rationale, e. g., JIRA issues and
ble 1). In our model, we distinguish three types of comments. On the one hand, rationale elements can
relationships, i. e., edge types. The relates to relation- be captured as JIRA issues with special types for issue,
ship is the default edge type. Only for arguments alternative, argument, and decision. Note the differ-
different types are used: A pro-argument supports an ence between JIRA issue as an abstract container and
alternative or the decision, whereas a con-argument the concrete issue as the rationale element. JIRA issue
attacks an alternative or the decision. links are used to link the rationale elements with each
other and also to JIRA issues of other types such as
2.2 Issue Tracking and Wiki System scenarios or tasks. On the other hand, rationale can
Developers can capture rationale in various documen- be captured as part of the comments of JIRA issues.
tation locations, for example, in the issue tracking
2.4 The iPraktikum
[3, 10, 18] or the wiki system. Issue tracking systems
are widely applied to store requirements, bug reports, The iPraktikum is a multi-project course in which up
as well as development tasks. They contain various to 100 students work in eight to ten teams on real
information types such as functionality or quality re- problems provided by an industry customer [4].
quests and as-is descriptions [17]. Wiki systems are In particular in the first half of the semester, the
collaborative writing tools that can be applied for practical character of the course is supported by theo-
many purposes, for example, for meeting manage- retical, yet interactive lectures. During these lectures,
ment and requirements elicitation [19]. For a lecture the students learn the basic concepts of agile develop-
on rationale management, we assume that students ment, release and merge management, modeling, and
use the issue tracking system JIRA and the wiki system usability engineering. Recently, we added a lecture
Confluence.1 JIRA and Confluence are commercial sys- on rationale management. During the iPraktikum, the
tems that provide free licenses to universities. Both students apply latest tools and frameworks that are
systems can be extended with plugins.2 used in real industry projects. Moreover, they get to
use the results of latest research projects, which might
1 https://atlassian.com/software
2 https://developer.atlassian.com 3 https://github.com/cures-hub
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 126
Teaching Rationale Management in Agile Project Courses
Anja Kleebaum, Jan Ole Johanssen, Barbara Paech und Bernd Bruegge, Uni Heidelberg & TU München
Figure 1: The decision knowledge view as a separate view for performing rationale management in JIRA.
find their way into the development process in the
future. This prepares the students for their future use.
At the time of the rationale management lecture,
they have already been introduced to JIRA and Con-
fluence. Regarding JIRA, they have at least one month
of experience. This knowledge is imparted through
various channels: (a) a development introduction
course in which the students are required to track the
progress of their work via JIRA, (b) the work within
their teams, and (c) a course-wide lecture on man-
aging the backlog, on what JIRA issues are, on how
to close, move, and work with them in sprints. Re-
garding Confluence, we provide the students with a
meeting management introduction at the beginning of
the course. This is handled by the coaches of a team,
a special role within the team that is fulfilled by an
experienced student and which is similar to a scrum
master. The coach can decide on what to present, how-
ever, we provide a guideline that contains the major
aspects of using Confluence. In particular, this relates
to managing the team agenda, i. e., (a) how does a
team meeting schedule look like?, (b) which roles are Figure 2: The JIRA issue view including the interactive
present during each meeting?, (c) what are guidelines, rationale tree.
i. e., what to provide as the stand-up information and
when to use it?
and the instant messaging services Slack5 . Further,
the ConDec JIRA plugin6 needs to be installed in JIRA
3 Lecture on Rationale Management and be enabled for the specific projects that the stu-
In this section, we describe the lecture, the results of dent teams work in. Rationale elements that can be
its first instantiation, and then discuss these results explored by the students need to be added to the re-
and our lessons learned. spective JIRA projects, e. g., the elements shown in
Figure 1 and Figure 2. Slack is used as a communi-
3.1 Preparation and Introduction cation tool between the instructors and students. In
The lecture is designed to last 90 minutes. Students particular, polls can be created with the Polly Slack
are grouped into teams and require a web-connected app7 through which students participate during the
device with access to the internet.4 During the lec- lecture.
ture, three systems are needed: JIRA, Confluence,
5 https://slack.com
4 An alternative would be to run the servers locally and to give 6 https://github.com/cures-hub/cures-condec-jira
students access to the intranet (not possible for Slack). 7 https://polly.ai
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 127
Teaching Rationale Management in Agile Project Courses
Anja Kleebaum, Jan Ole Johanssen, Barbara Paech und Bernd Bruegge, Uni Heidelberg & TU München
The first part of the lecture covers background in- In our example, the decision and alternative on the
formation about rationale management, such as its left are more requirements-related, whereas the deci-
definition, expected benefits, and the rationale ele- sion on the right is implementation-specific (Figure 2).
ments. We advise students to use certain phrases With this exercise, the students should learn that ra-
when talking about and capturing rationale (Table 1). tionale can be captured for all steps in the software
Further, we recommend to phrase issues as questions engineering process, including requirements elicita-
ending with a question mark and to end alternatives tion, implementation, deriving test cases, and when
with an exclamation mark. processing user feedback.
Now, the students will make their first experience
3.2 Capturing, Visualizing, and Filtering
in capturing rationale:
Rationale in JIRA
In the second part of the lecture, the students are Exercise 3 Link the existing issue “How to save trans-
introduced to the JIRA ConDec plugin including the actions?” to the scenario.
JIRA issue types for rationale elements (Figure 3).
This issue is already part of the JIRA project (Fig-
ure 1) but not linked to the scenario yet. The students
can link the issue via a context menu on the scenario
node (root node in Figure 2).
The students realize that graphs of rationale can
become large and complex. Therefore, filtering is
important. The next exercise addresses filtering:
Exercise 4 Filter the element types so that only the
scenario and decisions are shown in the rationale tree.
Figure 3: JIRA issue types available in the project.
Two views for rationale management are shown to
the students: the decision knowledge view (Figure 1)
and the JIRA issue view (Figure 2). The decision
knowledge view is a separate view that holds all ratio-
nale elements and their links for the given project. In Figure 4: Filtered rationale tree.
this view, a user can select single rationale elements
and visualize the graph of rationale as a tree, called Figure 4 shows the solution of this exercise. Now,
rationale tree. In the JIRA issue view, rationale at- students discuss rationale in their team:
tached to JIRA issues can be explored. For example,
Exercise 5 Create a new issue “How to persist data?”.
Figure 2 shows the rationale tree for a scenario.
Add the following alternatives: “JSON!”, “SQLite!”. Dis-
Then, the instructor demonstrates how to create
cuss and capture pro and cons of each persistence alter-
and link rationale elements shown on the right side
native in your team. Add more alternatives and make a
of Figure 1. Afterwards, the students gather in teams
decision.
and perform the first exercise:
To solve this exercise, the students can add rationale
Exercise 1 Gather your team, open your JIRA project, elements collaboratively from different devices. This
and find the scenario already documented in the project. exercise takes about 10 to 15 minutes.
Answer the question: How many issues are linked to the
Rationale can be captured in many places. JIRA
scenario?
issues are just one possible documentation location
The students can answer the question via a poll. In to store rationale. In order to demonstrate that there
our example, the correct answer is that two issues are are other possible documentation locations, the stu-
linked to the scenario (Figure 2). The next exercise is dents are presented with capturing rationale in JIRA
to discuss the content of the solution proposals, i. e., issue comments (Figure 6). In this lecture, this is
the alternatives and decisions. for information only, but, as part of our future work,
we integrate various documentation locations typical
Exercise 2 Answer the question: Which of the proposed for continuous software engineering and support the
alternatives and decisions focus on requirements, which identification of rationale elements with a supervised
of them on implementation? text classifier.
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 128
Teaching Rationale Management in Agile Project Courses
Anja Kleebaum, Jan Ole Johanssen, Barbara Paech und Bernd Bruegge, Uni Heidelberg & TU München
3.4 Results
Two authors of this paper gave the lecture on Novem-
ber 8, 2018. In this section, we present results of this
first instantiation of the lecture.
The first poll was to answer the question what team
a student belongs to. With this poll, we wanted the
students to get warmed up in voting and to get the
number of participating students. In total, 88 students
answered the poll, i. e., about 88 students participated
in the lecture. This number serves as a reference point
for the following, quantitative evaluation results.
Exercise 1 was answered by 64 students, i. e., 73 %
of the participating students, of whom 63 gave the
correct answer.
Regarding the content of the solution proposals,
Figure 6: Explicit rationale in the comments of the i. e., the alternatives and decisions, we initially asked
scenario. a different question than given in Exercise 2. We asked
the students to describe the difference between the
alternatives and decisions. Since this question seemed
3.3 Rationale-based Meeting Management to be hard to answer, we restated the question as given
Capturing rationale pays off during sprint meetings. in Exercise 2. This exercise was verbally performed
The meeting agenda has an information sharing sec- and we did not collect any results for it.
tion that lists issues discussed and decisions made After performing Exercise 3, we asked students to
during the last sprint. If meeting agendas are man- assess how easy it was to link an existing issue to
aged in Confluence, the rationale elements captured a scenario via a poll. They were asked to rate the
in JIRA can be easily imported. statement Linking an existing issue to a scenario is
Exercise 6 Gather your team, open your Confluence easy with one answer from a five point Likert scale. 59
space and create a new page called students participated in this poll, of whom 6 disagreed,
(one per team). Create a sub-page called 11 were neutral, and 32 agreed with the statement
(every team member). Use the JIRA Issue/Filter macro (Figure 5). After the lecture, we checked whether the
to display decisions from your JIRA project. Answer the teams correctly performed Exercise 3. In every team
question: How many decisions do you see? project, the issue was correctly linked to the scenario.
The JIRA Issue/Filter macro is used in the exercise We did not collect any results for or attitudes to-
and the search string is expressed using the JIRA query wards Exercise 4.
language (JQL). The JQL string is: For Exercise 5, we created a poll in which the stu-
dents could rate the statement Discussing rationale
project = AND using ConDec is simple. 56 students participated in
issuetype = Decision AND this poll, of whom 7 disagreed, 13 were neutral, and
created > -7d. 35 agreed with the statement (Figure 5).
In our case, two decisions are shown.
I would apply presenting rationale in Confluence pages.
I would apply capturing rationale in JIRA issue comments.
Discussing rationale using ConDec is simple.
Linking an existing issue to a scenario is easy.
20 0 20 40
Number of students
strongly disagree disagree neutral agree strongly agree
Figure 5: Students’ attitude towards the presented methods and tools for rationale management.
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 129
Teaching Rationale Management in Agile Project Courses
Anja Kleebaum, Jan Ole Johanssen, Barbara Paech und Bernd Bruegge, Uni Heidelberg & TU München
We asked the students to provide written feedback The results of voting on the statements in Figure 5
on discussing rationale (Table 2) and we analyzed the lead us to conclude that the majority of the students
rationale graphs. A total of 126 rationale elements liked applying rationale management. More impor-
were documented, i. e., a mean value of 12.6 rationale tant than the votes, the written feedback summarized
elements per team with a standard deviation of 9.4 in Table 2 encourages us to improve the visualization
elements. That means that each student contributed and filtering components of the ConDec JIRA plugin.
a mean value of 1.4 rationale elements. A mean value In general, we had the impression that the students
of 3.3 alternatives were documented per team (stan- liked voting on the polls and performing the exercises,
dard deviation 1.2). 61 % of the alternatives correctly since this made the lecture more interactive [13].
ended with an exclamation mark. Seven of the ten Studying the rationale trees that the students cre-
issues correctly ended with a question mark. Four ated in Exercise 5, we noticed that we did not ask the
teams documented the decision. The types of the el- students to make a decision. Thus, only four decisions
ements were correctly chosen, e. g., arguments were were documented. As a result, we will restate the
not accidentally classified as alternatives. exercise for future use. The students seem to under-
stand the elements of the rationale model (Table 1),
Student Feedback Our Rationale since they correctly classified the element types in
their trees of rationale.
Permission scheme in the
Deletion of elements is not
JIRA project forbids dele-
possible.
tion for non-admin users. 4 Evaluation During Semester
If there are many alterna-
Two teams continue to apply rationale management
tives and arguments, it is during the agile project course. Thus, we will evalu-
A better graph visualization ate the explained methods for rationale management,
hard to get an overview.
and better, easy-to-apply fil- especially the ConDec JIRA plugin.
The user needs to scroll
ter possibilities are needed.
very far to the right to see We introduced the role of the rationale manager.
all the content. The rationale manager is responsible for checking and
Capturing rationale ele- improving the rationale quality, i. e., they make sure
Rationale elements should ments in separate JIRA is- that important elements are documented and that
not always be a single sues has the advantage that they are consistent. Further, the rationale manager
ticket. This seems to end they can easily be imported imports issues and decisions important for the last
up in a ticket overflow. Pro- into Confluence. We also sprint into the meeting agenda in Confluence. They
and con-arguments should develop the ConDec Conflu- update and add rationale elements after the meeting
be comments. ence plugin to import ratio- in JIRA. The role of the rationale manager is taken by
nale from comments. one student per team. The role is passed on after a
week to a different student, i. e., it is an interchanging
Table 2: Summarized feedback provided by students. role. After the students have completed the role of the
rationale manager, we ask them to give us feedback
After demonstrating that rationale could also be cap- by filling in a questionnaire. We derive the questions
tured in the comments of the scenario, we asked the in this questionnaire by considering the variables of
students to rate the statement I would apply capturing the technology acceptance model [16]: We consider
rationale in JIRA issue comments. 61 students partic- the perceived usefulness, the perceived ease of use,
ipated in this poll, of whom 18 disagreed, 24 were and the intention to use. Next to rating statements as
neutral, and 19 agreed with the statement (Figure 5). shown in Figure 5, it is important that the students
After the students performed Exercise 6, we asked provide detailed feedback on the features for rationale
them to rate the statement I would apply presenting management they applied. For example, students
rationale in Confluence pages. 55 students participated should provide details on what they think is useful or
in this poll, of whom 7 disagreed, 13 were neutral, useless, easy or difficult, and why they think so.
and 35 agreed with the statement (Figure 5).
A mean value of 58 students participated in the 5 Related Work
polls analyzed in Figure 5, which represents 66 % of To the best of our knowledge there is no work that
all students. reports on teaching rationale management. Thus, in
3.5 Discussion and Lessons Learned this section, we present related work on applying
rationale management in student projects.
Clearly, the results that we collected during the lecture
While tools for rationale management have been
only represent the students’ first impression about the
evaluated in student projects before, e. g., in [8] and
presented methods for rationale management and the
[2], the following authors especially focus on the pos-
ConDec JIRA plugin. As described in the next section,
itive effects of rationale management for the success
we will apply a more thorough evaluation process
of the student course.
during the semester.
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 130
Teaching Rationale Management in Agile Project Courses
Anja Kleebaum, Jan Ole Johanssen, Barbara Paech und Bernd Bruegge, Uni Heidelberg & TU München
Dutoit et al. discuss experiences with an integrated, Acknowledgements
rationale-based modeling environment in a variety This work was supported by the DFG (German Re-
of software engineering courses [6]. By applying ra- search Foundation) under the Priority Programme
tionale management, they aim to enhance the com- SPP1593: Design For Future – Managed Software
munication between instructor and students, to sup- Evolution (CURES project). We thank the partici-
port students in reflecting their own work, and to pants of the rationale management lecture for their
enable the instructor to better monitor the students’ participation in the exercises as well as the ConDec
progress. These are valid benefits that we also expect developers, inter alia, Tim Kuchenbuch, Jochen Clor-
when students apply rationale management during mann, and Lars Tralle. Furthermore, we would like to
the semester as part of the agile project course. Simi- thank Dominic Henze, Matthias Linhuber, and Florian
lar to their modeling environment, ConDec integrates Angermeir for their technical support and Doris Kei-
the rationale elements with the system elements, such del–Mueller for providing valuable feedback on the pa-
as requirements. In addition, we focus on linking ratio- per. The emojis are created by Yusuke Kamiyamane10
nale with development tasks since they represent the and licensed under a Creative Commons License.
place where developers need to solve issues related to
design and implementation.
References
Malloy and Burge developed the software engineer-
ing using rationale tool SEURAT_Edu as a web-based [1] Zoya Alexeeva, Diego Perez-Palacin, and Raf-
system that replaces the former SEURAT Eclipse8 ex- faela Mirandola. Design decision documenta-
tension [15]. Like our tool support, SEURAT_Edu tion: A literature overview. In Software Architec-
aims to support students in making the best decision ture, volume 5292 of Lecture Notes in Computer
for an issue under consideration by explicitly reason- Science, pages 84–101. Springer, Berlin, Heidel-
ing about design alternatives. During their evalua- berg, 2016.
tion, Malloy and Burge found that the students us-
[2] Rana Alkadhi, Jan Ole Johanssen, Emitza Guz-
ing their tool considered more alternatives and put
man, and Bernd Bruegge. REACT: An approach
more thought into decision-making. Similar to their
for capturing rationale in chat messages. In
tool, the ConDec JIRA plugin is web-based, which
11th ACM/IEEE International Symposium on Em-
allows students to easily collaborate. Their tool in-
pirical Software Engineering and Measurement
tegrates with learning management systems such as
(ESEM’17), Toronto, Canada, 2017. IEEE.
Moodle9 , which has the advantage that the learning
management system takes care of authentication and [3] Manoj Bhat, Klym Shumaiev, Andreas Biesdorf,
assignment creation. In our case, this is handled by Uwe Hohenstein, and Florian Matthes. Auto-
JIRA. Similar as we do in the lecture on rationale matic extraction of design decisions from is-
management, SEURAT_Edu enables the teacher to sue management systems: A machine learning
supply students with incomplete rationale that they based approach. In 11th European Conference
are asked to complete. In addition, SEURAT_Edu en- on Software Architecture (ECSA’17), pages 138–
ables the teacher to create a set of “solution” rationale. 154, Cham, Switzerland, 2017. Springer. ISBN
It displays the status to which students reached a so- 978-3-319-65830-8.
lution, in order to encourage them during their tasks.
SEURAT_Edu performs automatic error checks, e. g., [4] Bernd Bruegge, Stephan Krusche, and Lukas
whether there are issues not solved by a decision. The Alperowitz. Software engineering project
ConDec JIRA plugin provides a report page that lists courses with industrial clients. ACM Trans-
quality metrics. We plan to integrate support to ensure actions on Computing Education, 15(4):17:1–
the rationale quality in the development process. 17:31, 2015.
[5] Michael Doyle and David Straus. How to Make
6 Conclusion Meetings Work: The New Interaction Method.
We presented a lecture on rationale management that Berkley, 1993. ISBN 978-0425138700.
teaches students to apply a rationale model as well as
methods and tool support for rationale management. [6] Allen H. Dutoit, Timo Wolf, Barbara Paech, Lars
The students’ feedback and the exercise results let us Borner, and Jürgen Rückert. Using rationale
conclude that the students comprehend the usage of for software engineering education. In 18th
the rationale model and that they are motivated to Conference on Software Engineering Education
apply rationale management. To validate this first and Training (CSEE&T), pages 129–136, Ottawa,
impression, a more detailed evaluation will be part of Canada, 2005. IEEE.
the remaining duration of the agile project course.
[7] Allen H. Dutoit, Raymond McCall, Ivan Mistrík,
and Barbara Paech. Rationale Management in
8 https://eclipse.org
9 https://moodle.de 10 http://p.yusukekamiyamane.com
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 131
Teaching Rationale Management in Agile Project Courses
Anja Kleebaum, Jan Ole Johanssen, Barbara Paech und Bernd Bruegge, Uni Heidelberg & TU München
Software Engineering: Concepts and Techniques. [14] Claudia López, Víctor Codocedo, Hernán As-
Springer, 2006. ISBN 978-3-540-30998-7. tudillo, and Luiz Marcio Cysneiros. Bridging
the gap between software architecture rationale
[8] Davide Falessi, Giovanni Cantone, and Martin
formalisms and actual architecture documents:
Becker. Documenting design decision rationale
An ontology-driven approach. Science of Com-
to improve individual and team design decision
puter Programming, 77(1):66–80, 2012.
making. In ACM/IEEE International Symposium
on Empirical Software Engineering (ISESE), pages [15] John Malloy and Janet Burge. SEURAT_Edu: A
134 – 143, Rio de Janeiro, Brazil, 2006. ACM. tool to assist and assess student decision-making
[9] Tom-Michael Hesse and Barbara Paech. Support- in design. In 47th Technical Symposium on Com-
ing the collaborative development of require- puting Science Education (SIGCSE), pages 669–
ments and architecture documentation. In 3rd 674, Memphis, Tennessee, USA, 2016. ACM.
International Workshop on the Twin Peaks of Re- [16] Nikola Marangunić and Andrina Granić. Tech-
quirements and Architecture, pages 22–26, 2013. nology acceptance model: a literature review
[10] Tom-Michael Hesse, Veronika Lerche, Marcus from 1986 to 2013. Universal Access in the Infor-
Seiler, Konstantin Knoess, and Barbara Paech. mation Society, 14(1):81–95, 2015.
Documented decision-making strategies and de- [17] Thorsten Merten, Bastian Mager, Paul Hüb-
cision knowledge in open source projects: An ner, Thomas Quirchmayr, Simone Bürsner, and
empirical study on firefox issue reports. Informa- Barbara Paech. Requirements communication
tion and Software Technology, 79:36–51, 2016. in issue tracking systems in four open-source
[11] Anja Kleebaum, Jan Ole Johanssen, Barbara projects. In 6th International Workshop on Re-
Paech, Rana Alkadhi, and Bernd Bruegge. Deci- quirements Prioritization and Communication
sion knowledge triggers in continuous software (RePriCo), pages 114–125, Essen, Germany,
engineering. In 4th International Workshop on 2015.
Rapid Continuous Software Engineering (RCoSE),
[18] Benjamin Rogers, Yechen Qiao, James Gung,
pages 23–26, Gotheburg, Sweden, 2018. ACM.
Tanmay Mathur, and Janet E. Burge. Using
[12] Anja Kleebaum, Jan Ole Johanssen, Barbara text mining techniques to extract rationale from
Paech, and Bernd Bruegge. Tool support for de- existing documentation. In 6th International
cision and usage knowledge in continuous soft- Conference on Design Computing and Cognition,
ware engineering. In 3rd Workshop on Continu- pages 457–474. Springer, 2014.
ous Software Engineering, pages 74–77, 2018.
[19] Carlos Solis and Nour Ali. Distributed require-
[13] Stephan Krusche, Nadine von Frankenberg, and ments elicitation using a spatial hypertext wiki.
Sami Afifi. Experiences of a software engineer- In 5th IEEE International Conference on Global
ing course based on interactive learning. In Software Engineering, pages 237–246, Princeton,
15. Workshop Software Engineering im Unterricht NJ, USA, 2010. IEEE.
der Hochschulen (SEUH), pages 32–40, Hanover,
Germany, 2017.
V. Thurner, O. Radfelder, K. Vosseberg (Hrsg.): SEUH 2019 132