=Paper=
{{Paper
|id=Vol-2066/cse2018paper01
|storemode=property
|title=Tool Support for Decision and Usage Knowledge in Continuous Software Engineering
|pdfUrl=https://ceur-ws.org/Vol-2066/cse2018paper01.pdf
|volume=Vol-2066
|authors=Anja Kleebaum,Jan Ole Johanssen,Barbara Paech,Bernd Bruegge
|dblpUrl=https://dblp.org/rec/conf/se/KleebaumJPB18
}}
==Tool Support for Decision and Usage Knowledge in Continuous Software Engineering==
<pdf width="1500px">https://ceur-ws.org/Vol-2066/cse2018paper01.pdf</pdf>
<pre>
Tool Support for Decision and Usage Knowledge in
Continuous Software Engineering
Anja Kleebaum∗ , Jan Ole Johanssen† , Barbara Paech∗ , and Bernd Bruegge†
∗ Heidelberg University † Technical University of Munich
Institute of Computer Science Department of Informatics
Heidelberg, Germany Munich, Germany
{kleebaum, paech}@informatik.uni-heidelberg.de {jan.johanssen, bruegge}@in.tum.de
Abstract—Continuous software engineering copes with fre- Thus, as already discussed in our previous work [4], deci-
quent changes and quickly evolving development projects while sion and usage knowledge are two important knowledge types
maintaining a high software quality. Developers require know- that need to be managed during CSE. Since this knowledge is
ledge about former and ongoing decisions as well as about
the users’ needs to evolve software. Thus, decision and usage complex, tool support is needed.
knowledge are two important knowledge types in continuous According to Burge and Brown, essential requirements for
software engineering. Issue tracking and version control systems decision knowledge tool support are its integration into the de-
are widely used in continuous software engineering but lack a velopment environment, direct association of knowledge with
structured approach to integrate decision and usage knowledge. software artifacts (such as code), automatic presentation of the
In this paper, we present ideas and requirements for a tool
support to manage decision and usage knowledge in continuous knowledge when needed, intuitive display of argumentation,
software engineering. As a first step, we introduce the JIRA automatic propagation and reevaluation when criteria change,
DecDoc plug-in for documenting decision knowledge. and support for filtering and querying knowledge [5]. In this
paper, we refine these requirements with CSE specific aspects
I. I NTRODUCTION in order to promote the paradigm shift in documentation [6].
In continuous software engineering (CSE), developers con- Tool support to manage knowledge can be characterized by
tinuously handle change while maintaining a high software its intrusiveness in the software development process [3]. Tools
quality so that builds are releasable at any time [1]. For that fit into the development context are less intrusive and
this purpose, developers create feature branches to implement will more likely be used [7]. Next to integrated development
a feature, perform code reviews prior to merging a feature environments (IDE), issue tracking systems (ITS) and version
branch, and write tests to ensure code quality [2]. control systems (VCS) are widely adopted [8]. We focus on
In particular, both the individuals’ and teams’ knowledge are integrating our tool support into these tools. As a first step,
important to guarantee a high quality of the software. Every we introduce a plug-in for JIRA1 , the JIRA DecDoc plug-in.
member of a software development team needs to know the This paper is structured as follows. Section II describes key
major decisions made, so that their own decisions are con- ideas on how to handle decision knowledge in CSE. Section III
sistent with the former ones. If developers lack such decision presents the requirements for tool support for decision and
knowledge and make inconsistent decisions, they are likely usage knowledge in CSE. Section IV introduces the JIRA
to contribute to the erosion of the software architecture or DecDoc plug-in. Section V discusses related work. Section VI
introduce other quality problems. Hence, decision knowledge concludes the paper and sketches ideas for further work.
is important to handle change [3]. Decision knowledge covers II. D ECISION K NOWLEDGE IN CSE
knowledge about decisions, the problems they address, solu-
During CSE, developers collaboratively implement and
tion proposals, their context, and justifications—rationale—
deliver many small increments, which involves decision-
through arguments and assessments.
making. We use the decision documentation model by Hesse
In CSE, a special focus is put on aligning software features
& Paech [9] to represent the thereby emerging decision
to users’ needs. The more the developers know about what the
knowledge during CSE. This model supports incremental
users want, the better they can develop and adopt software for
documentation of decisions, since it does not prescribe a
them. Such usage knowledge can be derived from explicit and
complete template for decision documentation. Any part of
implicit user feedback. Short feedback cycles in CSE provide a
the decision knowledge can be captured as soon as it is
great opportunity to integrate usage knowledge in the decision
available. Furthermore, developers are able to collaborate
making process. Whenever an artifact has changed, or a new
while documenting decisions and contribute the part of the
artifact increment evolved, the artifact creator can make the
decision knowledge they know best.
artifact available to the users. Then, during the artifact’s usage,
the users’ behavior is observed and feedback is collected. 1 https://atlassian.com/software/jira
CSE 2018: 3rd Workshop on Continuous Software Engineering @ SE18, Ulm, Germany 74
1 decision knowledge essential feature of the software. In this example, developers
4
start is tacit start/consider
and inconsistent consistency
decide on how to implement this image matching feature.
with artifacts 3 We derive requirements for tool support in CSE by aligning
finish/make
explicit
the running example to Figure 1 and evolving its decision in
decision knowledge
Figure 2. As motivated in Section II, a first requirement is:
decision knowledge
is explicit, distributed,
and inconsistent finish/package
is explicit and consistent R1 Developers are supported in explicitly capturing decision
with artifacts
with artifacts 2 knowledge consistent with artifacts in the tools they work with.
A developer opens a feature task in the ITS to imple-
Fig. 1. Decision knowledge and artifacts shown as a state diagram. The state
on the lower right side is the preferred state.
ment image matching, indicated by the start transition in
Figure 1- 1 . Developers discuss image matching algorithms in
chat messages and, thus, get into the state decision knowledge
To exploit decision knowledge, it is important that decision is explicit, distributed, and inconsistent with artifacts. One
knowledge is consistent with the software artifacts it concerns, developer makes the proposal to implement a common image
e. g., with requirements, design, and code. Consistency means matching algorithm based on detecting the maximum zero
that decisions are documented as well as linked to and realized normalized cross correlation. A second developer proposes
in the artifacts they relate to. Therefore, it is essential that deci- to take advantage of algorithms provided by the open source
sion knowledge is made explicit and checked for consistency. computer vision library (OpenCV), which they think comes
However, in the beginning, decision knowledge is often tacit with less implementation effort. However, this also introduces
in the head of a few developers (Figure 1). If decisions are third party code. Users will have a higher installation effort,
not tacit, they are often discussed informally, captured partly since they have to make sure that the library is correctly
and in a distributed manner, such as in issue comments [10], provided by their operation system. Finally, the developers
commit messages, pull-requests [11], or chat messages [12]. decide to implement their own image matching algorithm on a
We refer to this decision knowledge as distributed knowledge. distinct feature branch in the VCS. When merging this branch
This knowledge is hard to access later and might even be out- back to the mainline, they perform a finish practice. A second
dated. Therefore, we consider tacit and distributed knowledge requirement for our tool support is:
as inconsistent with artifacts (cf. Figure 1, left). R2 Developers are presented with distributed decision know-
Thus, tool support is needed to explicitly capture decision ledge when performing a finish practice.
knowledge consistent with artifacts when developers finish Criteria to classify knowledge as relevant may be its creation
some work. Practices that indicate that developers finished within a specific time frame, by the same person, or textual
work are closing a feature task in the ITS and committing code similarity with the feature task. In this case, relevant decision
or merging a feature branch in the VCS. In contrast, practices knowledge is extracted from a history of chat messages [12].
that indicate that developers start work are opening a feature The developers package this knowledge to make it explicit
task in the ITS—and for this purpose—the creation of a feature and consistent with the implemented code (Figure 1- 2 ). Here,
branch in the VCS. The integration of tool support into such packaging means that knowledge is captured as in Figure 2- 1 .
short-cycled start and finish practices triggers developers to If the developers had not explicitly discussed the implementa-
explicitly capture decision knowledge consistent with artifacts tion of the image matching algorithm, this decision knowledge
and exploit it afterwards, indicated by the labeled state tran- would be tacit and inconsistent with the code (Figure 1). In
sitions in Figure 1. The left side of these transitions indicates this case, the finish practice would be that they commit code.
the type of CSE practice (start or finish), while the right A third requirement for our tool support is:
side indicates the developers’ tasks that we support (package, R3 Developers are presented with summarized artifact
make explicit, and consider consistency). These transitions are changes when performing a finish practice.
further explained in the following section.
As a result, the developers would be presented with the
summarized change that they “inserted methods to calculate
III. T OOL S UPPORT
the average and the zero normalized cross correlation” inferred
In this section, we introduce a running example, describe from the code in Figure 2- 1 . To achieve this, a tool parses
the requirements for tool support in CSE using this example, the code before and after the change and compares the nodes
and map the requirements to tools. of the two syntax trees [13]. This triggers developers to recon-
Example Imagine the development of a software that com- struct decision knowledge, to make tacit decision knowledge
putes three dimensional surface models of the earth from explicit (Figure 1- 3 ). Ideally, developers document decision
satellite stereo images. The idea behind this software is knowledge similar to the packaged one in Figure 2- 1 .
the following: An image matching algorithm detects pixels The software is continuously deployed to users. After a
belonging to the same object—homologous points—on the while, multiple users provide explicit feedback in the form of
stereo images. The distance between the homologous points— written text stating that the image matching takes a fairly long
the disparity—is then used to calculate the relative height of time when they process new high-resolution satellite images
the object, e. g., of a mountain. Thus, image matching is one (Figure 2- 2 ). A forth requirement for our tool support is:
CSE 2018: 3rd Workshop on Continuous Software Engineering @ SE18, Ulm, Germany 75
Image Matching Feature
double average(NumericMatrix img, int u, int v, int n) { #include "opencv2/highgui.hpp"
double avg = 0; #include "opencv2/imgproc.hpp"
Image Matching Feature for (int i=-n-1; i<n; i++) { 3
for (int j=-n-1; j<n; j++) {
Implement Image Matching Feature Task Improve Image Matching Feature Task #include <iostream>
avg += img(u+i, v+j); #include <stdio.h>
attached to attached to ...
}
Implement Image Matching Feature Task } 4 Decision Decision
return(avg/((2*n+1)*(2*n+1))); revised Solution
} Implement image matching based on Use an image matching algorithm
attached to Use OpenCV library
1 zero normalized cross correlation from the OpenCV library
Decision double zeroNormalizedCrossCorrelation(NumericMatrix master, becomes
Implement image matching based on NumericMatrix slave, int u1, int v1, int u2, int v2, int n) { attacks
zero normalized cross correlation ... Alternative Pro
Contra Use image matching Less implementation effort
Takes too long for based on
Issue
Solution Alternative Pro high-resolution stereo images zero normalized Constraint
How can we detect
Use own Use OpenCV library Less implementation effort cross correlation Users might not have installed this library.
homologous points
implementation based on
on stereo images?
Issue
Constraint
2 User Feedback How can we detect homologous
Users might not have installed this library. Users report performance problems. points on stereo images?
Fig. 2. Image matching decision before (left) and after (right) employing usage knowledge. Yellow items are decision knowledge.
R4 Developers are presented with assessed user feedback, These requirements could be fulfilled by multiple tools,
resulting in pro and contra arguments that are linked to the though we prefer their implementation into that tool the
respective decision knowledge or to new proposals. developers work with. Figure 3 shows a possible mapping from
Based on this insight, a developer creates the contra argu- the requirements to tools.
ment and attaches it to the image matching decision. Alterna- IV. JIRA D EC D OC P LUG - IN
tively, the tool support could automatically assess implicit user
In this section, we present the JIRA DecDoc plug-in2 as
feedback when a certain threshold is reached, such as a drop
a first ITS extension towards our tool support. Thurimella
in feature usage after its internals have been changed. After
et al. suggest to customize JIRA to support rationale guide-
that, the developers create a new feature task to improve image
lines [14], but to the best of our knowledge, this is the
matching (Figure 2- 3 ). Developers who open the feature task
first work to explicitly capture decision knowledge in JIRA.
perform a start practice. A fifth requirement is:
The JIRA DecDoc plug-in is based on the Unicase DecDoc
R5 Developers are presented with relevant knowledge and tool [15]. Both tools—JIRA and Unicase DecDoc—support
artifacts when performing a start practice. developers in documenting decision knowledge in a structured,
The decision knowledge as well as the former feature task collaborative, and incremental way according to the decision
and code in Figure 2- 1 are presented to the developers. documentation model (DDM) by Hesse & Paech [9]. JIRA
This triggers the developers to consider consistency when DecDoc transfers the concepts from the research prototype
changing the software (Figure 1- 4 ). Figure 1- 1 indicates a Unicase DecDoc to the widely used commercial tool JIRA.
start practice without any initial knowledge for presentation. The JIRA DecDoc plug-in supports two strategies to im-
By reflecting the former decision knowledge, the developers plement the DDM: the issue strategy and the active object
remember the alternative that they could employ the OpenCV strategy. The issue strategy represents the concepts of the
library, which offers fast image matching methods. Therefore, DDM as JIRA issues. JIRA issue links are used to link DDM
they revise their former decision (Figure 2- 4 ) and implement elements to each other and to JIRA issues of other types
the new code. After a while, a new developer joins the project such as feature tasks. The advantage of this strategy is that
team and is asked to improve the image matching even further. all features available for JIRA issues can be used to manage
The sixth requirement for our tool support is: decision knowledge, e. g., searching for a decision in the list
R6 Developers are supported in accessing knowledge by of issues. The disadvantage is that the dedicated issue type
filtering and searching from within the tools they use and from scheme needs to be assigned to the JIRA project. To overcome
a dashboard, not bound to start and finish practices, also from this disadvantage, the active object strategy uses distinct model
artifacts such as code and features. classes for decision, decision components, and links. This
To learn about existing knowledge, developers use a know- strategy uses object-relational mapping to communicate with
ledge dashboard [4] and search for image matching. They are JIRA’s internal database. The JIRA DecDoc plug-in provides a
presented with the feature, the two feature tasks, code, decision view that presents decision knowledge similar to Figure 2. De-
and usage knowledge as depicted on the right side of Figure 2. velopers are supported to document decision knowledge either
by using a context menu or an accordion editor. Furthermore,
Integrated Development Environment
JIRA DecDoc enables developers to textually filter decision
knowledge. The JIRA DecDoc plug-in fulfills the requirement
R1
Issue Version Usage
Other R1. It partly fulfills the requirement R6, as it allows to filter
R2 Knowledge
Tracking
R3
Control Analytics
System for decision knowledge. Thus, it provides the key decision
System System System
R5 R4
(e. g., Chat, Wiki) knowledge infrastructure that facilitates the implementation of
Knowledge Dashboard R6
the other requirements on top of it.
2 The JIRA DecDoc plugin as well as further implementation details and
Fig. 3. Requirements mapped to tools. screenshots are available at https://github.com/cures-hub.
CSE 2018: 3rd Workshop on Continuous Software Engineering @ SE18, Ulm, Germany 76
V. R ELATED W ORK ACKNOWLEDGEMENT
There are various tools to manage decision know- This work was supported by the DFG (German Research
ledge during software development. Hesse et al. [15] and Foundation) under the Priority Programme SPP1593: Design
Capilla et al. [16] provide a comparison between existing For Future – Managed Software Evolution (CURES project).
tools, such as SEURAT [5] or Archie [17]. Alexeeva et al. We thank Ewald Rode and Tim Kuchenbuch for their work on
provide a literature overview about 56 decision documen- the JIRA DecDoc plugin and their very helpful discussions.
tation approaches of which 32 provide tool support [18]. R EFERENCES
The requirements for our tool support differ from other tools
[1] S. Krusche and B. Bruegge, “CSEPM - A continuous software engi-
as follows: We use short-cycled CSE practices to integrate neering process metamodel,” in 3rd Int. Workshop on Rapid Continuous
tool support that triggers the developers to document and Software Engineering, 2017, pp. 2–8.
exploit knowledge, which none of the existing tools address, [2] S. Krusche, L. Alperowitz, B. Bruegge, and M. O. Wagner, “Rugby: An
agile process model based on continuous delivery,” in 1st Int. Workshop
e. g., merging of feature branches in the VCS or opening on Rapid Continuous Software Engineering, 2014, pp. 42–50.
and closing a feature task in the ITS. We will integrate [3] A. H. Dutoit, R. McCall, I. Mistrík, and B. Paech, Rationale Manage-
informal and distributed knowledge from sources such as chat ment in Softw. Engineering: Concepts and Techniques. Springer, 2006.
[4] J. O. Johanssen, A. Kleebaum, B. Bruegge, and B. Paech, “Towards
messages, pull requests, or issue comments. We will employ a systematic approach to integrate usage and decision knowledge in
summarization techniques to encourage the reconstruction of continuous software engineering,” in 2nd Workshop on Continuous
decision knowledge. To the best of our knowledge, none of the Software Engineering, 2017, pp. 7–11.
[5] J. E. Burge and D. C. Brown, “Software engineering using RATionale,”
existing tools integrates usage knowledge into the decision- Journal of Systems and Software, vol. 81, no. 3, pp. 395–413, 2008.
making process. Leveraging the capabilities of CSE, we will [6] M. P. Robillard, A. Marcus, C. Treude, G. Bavota, O. Chaparro, N. Ernst,
support developers in reflecting on usage knowledge. M. A. Gerosa, M. Godfrey, M. Lanza, M. Linares-Vásquez, G. C.
Murphy, L. Moreno, D. Shepherd, and E. Wong, “On-demand developer
For usage knowledge, Guzman et al. report on an interactive documentation,” in Int. Conf. on Softw. Mainten. and Evol., 2017, p. 5.
visualization to display the summarization of unstructured user [7] P. Kruchten, R. Capilla, and J. C. Dueñas, “The decision view’s role
feedback in the form of app reviews [19]. Maalej and Nabil in software architecture practice,” IEEE Software, vol. 26, no. 2, pp.
36–42, 2009.
describe the automatic classification of explicit application [8] S. Saito, Y. Iimura, A. K. Massey, and A. I. Antón, “How much
reviews into four types and derive requirements for an analytic undocumented knowledge is there in agile software development? Case
tool [20]. We extend the presented work in the context of usage study on industrial project using issue tracking system and version
control system,” in 25th Int. Requir. Eng. Conf., 2017, pp. 186–195.
knowledge with a relation to decision knowledge, combined [9] T.-M. Hesse and B. Paech, “Supporting the collaborative development
with a continuous analysis perspective enabled by CSE. of requirements and architecture documentation,” in 3rd Int. Workshop
on the Twin Peaks of Requir. and Architecture. IEEE, 2013, pp. 22–26.
VI. C ONCLUSION AND F UTURE W ORK [10] T.-M. Hesse, V. Lerche, M. Seiler, K. Knoess, and B. Paech, “Doc-
umented decision-making strategies and decision knowledge in open
Continuous software engineering provides great opportu- source projects: An empirical study on firefox issue reports,” Information
nities for employing decision and usage knowledge—if tool and Software Technology, vol. 79, pp. 36–51, 2016.
support is provided. We introduced six requirements for estab- [11] J. Brunet, G. C. Murphy, R. Terra, J. Figueiredo, and D. Serey, “Do
developers discuss design?” in 11th Working Conference on Mining
lishing a tool support and presented the JIRA DecDoc plug-in Software Repositories. ACM, 2014, pp. 340–343.
as a first step for their implementation. [12] R. Alkadhi, T. Laţa, E. Guzman, and B. Bruegge, “Rationale in devel-
We will continue to extend tool support for decision and opment chat messages: An exploratory study,” in 14th Int. Conference
on Mining Software Repositories. IEEE, 2017, pp. 436–446.
usage knowledge in JIRA by implementing requirements R2 [13] L. F. Cortés-Coy, M. Linares-Vásquez, J. Aponte, and D. Poshyvanyk,
to R6. We will implement an IDE-integrated Git client, which “On automatically generating commit messages via summarization of
supports developers both in accessing decision knowledge source code changes,” in 14th Int. Working Conference on Source Code
Analysis and Manipulation. IEEE, 2014, pp. 275–284.
from code and commits, as well as in documenting it when [14] A. K. Thurimella, M. Schubanz, A. Pleuss, and G. Botterweck, “Guide-
committing code or merging branches. It also will support lines for Managing Requirements Rationales,” IEEE Software, vol. 34,
changes of decision knowledge and code. no. 1, pp. 82–90, 2017.
[15] T.-M. Hesse, A. Kuehlwein, and T. Roehm, “DecDoc: A tool for
There are various kinds of usage knowledge that are not documenting design decisions collaboratively and incrementally,” in 1st
addressed in this paper. In requirement R4, we point out the Int. Workshop on Dec. Making in Softw. ARCHitecture, 2016, pp. 30–37.
relevance of explicit usage knowledge in the form of written [16] R. Capilla, A. Jansen, A. Tang, P. Avgeriou, and M. A. Babar, “10 years
of software architecture knowledge management: Practice and future,”
user feedback. However, implicit usage knowledge, such as Journal of Systems and Software, vol. 116, pp. 191–205, 2016.
the results of A/B tests or controlled experiments, require [17] J. Cleland-Huang, M. Mirakhorli, A. Czauderna, and M. Wieloch,
further tool support. We are working on a usage analytics “Decision-centric traceability of architectural concerns,” in 7th Int.
Workshop on Traceability in Emerging Forms of Software Engineering.
system to explore requirements and enable usage knowledge IEEE, 2013, pp. 5–11.
management in CSE. [18] Z. Alexeeva, D. Perez-Palacin, and R. Mirandola, “Design decision
To understand the developers’ needs, we plan to evaluate documentation: A literature overview,” in Software Architecture, ser.
LNCS. Springer Berlin Heidelberg, 2016, vol. 5292, pp. 84–101.
the tool support during industrial projects that are part of a [19] E. Guzman, P. Bhuvanagiri, and B. Bruegge, “FAVe: Visualizing user
practical course at university. In particular, we will investigate feedback for software evolution,” in 2nd Working Conference on Soft-
which knowledge is worth capturing. Furthermore, we will ware Visualization. IEEE, 2014, pp. 167–171.
[20] W. Maalej and H. Nabil, “Bug report, feature request, or simply
clarify how to maintain the knowledge in order to keep it praise? On automatically classifying app reviews,” in 23rd International
useful and how to access the relevant parts of knowledge. Requirements Engineering Conference. IEEE, 2015, pp. 116–125.
CSE 2018: 3rd Workshop on Continuous Software Engineering @ SE18, Ulm, Germany 77
</pre>