Browsing by Author "Ostberg, Jan-Peter"

Now showing 1 - 6 of 6

Open Access
Assessing iterative practical software engineering courses with play money
(2016) Mindermann, Kai; Ostberg, Jan-Peter; Wagner, Stefan
Changing our practical software engineering course from the previous waterfall model to a more agile and iterative approach created more severe assessment challenges. To cope with them we added an assessment concept based on play money. The concept not only includes weekly expenses to simulate real running costs but also investments, which correspond to assessment results of the submissions. This concept simulates a startup-like working environment and its financing in an university course. Our early evaluation shows that the combination of the iterative approach and the play money investments is motivating for many students. At this point we think that the combined approach has advantages from both the supervising and the students point of view. We planned more evaluations to better understand all its effects.
Open Access
At ease with your warnings: the principles of the salutogenesis model applied to automatic static analysis
(2016) Ostberg, Jan-Peter; Wagner, Stefan
The results of an automatic static analysis run can be overwhelming, especially for beginners. The overflow of information and the resulting need for many decisions is mentally tiring and can cause stress symptoms. There are several models in health care which are designed to fight stress. One of these is the salutogenesis model created by Aaron Antonovsky. In this paper, we will present an idea on how to transfer this model into a triage and recommendation model for static analysis tools and give an example of how this can be implemented in FindBugs, a static analysis tool for Java.
Open Access
Get started imminently: using tutorials to accelerate learning in automated static analysis
(2012) Ostberg, Jan-Peter; Wagner, Stefan
Static analysis can be a valuable quality assurance technique as it can find problems by analysing the source code of a system without executing it. Getting used to a static analysis tool, however, can easily take several hours or even days. In particular, understanding the warnings issued by the tool and rooting out the false positives is time consuming. This lowers the benefits of static analysis and demotivates developers in using it. Games solve this problem by offering a tutorial. Those tutorials are integrated in the setting of the game and teach the basic mechanics of the game. Often it is possible to repeat or pick topics of interest. We transfer this pattern to static analysis lowering the initial barrier of using it as well as getting an understanding of software quality spread out to more people. In this paper we propose a research strategy starting with a piloting period in which we will gather information about the questions static analysis users have as well as hone our answers to these questions. These results will be integrated into the prototype. We will evaluate our work then by comparing the fix times of user using the original tool versus our tool.
Open Access
How are functionally similar code clones syntactically different? An empirical study and a benchmark
(2016) Wagner, Stefan; Abdulkhaleq, Asim; Bogicevic, Ivan; Ostberg, Jan-Peter; Ramadani, Jasmin
Background. Today, redundancy in source code, so-called ‘‘clones’’ caused by copy&paste can be found reliably using clone detection tools. Redundancy can arise also independently, however, not caused by copy&paste. At present, it is not clear how only functionally similar clones (FSC) differ from clones created by copy&paste. Our aim is to understand and categorise the syntactical differences in FSCs that distinguish them from copy&paste clones in a way that helps clone detection research. Methods. We conducted an experiment using known functionally similar programs in Java and C from coding contests. We analysed syntactic similarity with traditional detection tools and explored whether concolic clone detection can go beyond syntax. We ran all tools on 2,800 programs and manually categorised the differences in a random sample of 70 program pairs. Results. We found no FSCs where complete files were syntactically similar. We could detect a syntactic similarity in a part of the files in <16% of the program pairs. Concolic detection found 1 of the FSCs. The differences between program pairs were in the categories algorithm, data structure, OO design, I/O and libraries. We selected 58 pairs for an openly accessible benchmark representing these categories. Discussion. The majority of differences between functionally similar clones are beyond the capabilities of current clone detection approaches. Yet, our benchmark can help to drive further clone detection research.
Open Access
Static analysis and stress : influence and measurements
(2024) Ostberg, Jan-Peter; Wagner, Stefan (Prof. Dr.)
Die Dissertation beschreibt wie statische Codeanalysewerkzeuge unter Stressgeschichtspunkten untersucht werden können und wie Stress in Gruppen, ohne Hilfe von medizinisch geschultem Personal, gemessen werden kann.
Open Access
What do practitioners vary in using scrum?
(2015) Diebold, Philipp; Ostberg, Jan-Peter; Wagner, Stefan; Zendler, Ulrich
Background: Agile software development has become a popular way of developing software. Scrum is the most frequently used agile framework, but it is often reported to be adapted in practice. Objective: Thus, we aim to understand how Scrum is adapted in different contexts and what are the reasons for these changes. Method: Using a structured interview guideline, we interviewed ten German companies about their concrete usage of Scrum and analysed the results qualitatively. Results: All companies vary Scrum in some way. The least variations are in the Sprint length, events, team size and requirements engineering. Many users varied the roles, effort estimations and quality assurance. Conclusions: Many variations constitute a substantial deviation from Scrum as initially proposed. For some of these variations, there are good reasons. Sometimes, however, the variations are a result of a previous non-agile, hierarchical organisation.