arXiv Science⌕ Search

arXiv subjects

Stefan Wagner

Publications and source records attributed to Stefan Wagner.

At least 181 records · Page 10Linked to original sources

Comparing Bug Finding Tools with Reviews and Tests

Bug finding tools can find defects in software source code us- ing an automated static analysis. This automation may be able to reduce the time spent for other testing and review activities. For this we need to have a clear understanding of how the defects found by bug finding tools relate to the defects found by other techniques. This paper describes a case study using several projects mainly from an industrial environment that were used to analyse the interrelationships. The main finding is that the bug finding tools predominantly find different defects than testing but a subset of defects found by reviews. However, the types that can be detected are analysed more thoroughly. Therefore, a combination is most advisable if the high number of false positives of the tools can be tolerated.

cs.SE↗

Noncommutative Coverings of Quantum Tori

We introduce a framework for coverings of noncommutative spaces. Moreover, we study noncommutative coverings of irrational quantum tori and characterize all such coverings that are connected in a reasonable sense.

math.OA↗

Exploratory Study of the Privacy Extension for System Theoretic Process Analysis (STPA-Priv) to elicit Privacy Risks in eHealth

Context: System Theoretic Process Analysis for Privacy (STPA-Priv) is a novel privacy risk elicitation method using a top down approach. It has not gotten very much attention but may offer a convenient structured approach and generation of additional artifacts compared to other methods. Aim: The aim of this exploratory study is to find out what benefits the privacy risk elicitation method STPA-Priv has and to explain how the method can be used. Method: Therefore we apply STPA-Priv to a real world health scenario that involves a smart glucose measurement device used by children. Different kinds of data from the smart device including location data should be shared with the parents, physicians, and urban planners. This makes it a sociotechnical system that offers adequate and complex privacy risks to be found. Results: We find out that STPA-Priv is a structured method for privacy analysis and finds complex privacy risks. The method is supported by a tool called XSTAMPP which makes the analysis and its results more profound. Additionally, we learn that an iterative application of the steps might be necessary to find more privacy risks when more information about the system is available later. Conclusions: STPA-Priv helps to identify complex privacy risks that are derived from sociotechnical interactions in a system. It also outputs privacy constraints that are to be enforced by the system to ensure privacy.

cs.CY↗

Abstractness, specificity, and complexity in software design

Abstraction is one of the fundamental concepts of software design. Consequently, the determination of an appropriate abstraction level for the multitude of artefacts that form a software system is an integral part of software engineering. However, the very nature of abstraction in software design and particularly its interrelation with equally important concepts like complexity, specificity or genericity are not fully understood today. As a step towards a better understanding of the trade-offs involved, this paper proposes a distinction of abstraction into two types that have different effects on the specificity and the complexity of artefacts. We discuss the roles of the two types of abstraction in software design and explain the interrelations between abstractness, specificity, and complexity. Furthermore, we illustrate the benefit of the proposed distinction with multiple examples and describe consequences of our findings for software design activities.

cs.SE↗

Piezoresistive Properties of Suspended Graphene Membranes under Uniaxial and Biaxial Strain in Nanoelectromechanical Pressure Sensors

Graphene membranes act as highly sensitive transducers in nanoelectromechanical devices due to their ultimate thinness. Previously, the piezoresistive effect has been experimentally verified in graphene using uniaxial strain in graphene. Here we report experimental and theoretical data on the uni- and biaxial piezoresistive properties of suspended graphene membranes applied to piezoresistive pressure sensors. A detailed model that utilizes a linearized Boltzman transport equation describes accurately the charge carrier density and mobility in strained graphene, and hence the gauge factor. The gauge factor is found to be practically independent of the doping concentration and crystallographic orientation of the graphene films. These investigations provide deeper insight into the piezoresistive behavior of graphene membranes.

cond-mat.mes-hall↗

Monitoring of the FSRQ PKS 1510-089 with H.E.S.S

The flat spectrum radio quasar (FSRQ) PKS 1510-089 (z=0.361) is known for its complex multiwavelength behavior. It has been monitored regularly at very high energy (VHE, $E>100\,$GeV) gamma-rays with H.E.S.S. since its discovery in 2009 in order to study the unknown behavior of FSRQs in quiescence at VHE, as well as the flux evolution around flaring events. Given the expected strong cooling of electrons and the absorption of VHE emission within the broad-line region, a detection of PKS 1510-089 at VHE in a quiescent state would be an important result, implying an acceleration and emission region on scales beyond the broad-line region. The H.E.S.S. monitoring has been intensified since 2015 and is complemented by monitoring at high energy ($E>100\,$MeV) gamma-rays with Fermi, at X-rays with Swift-XRT, and at optical frequencies with ATOM. The dense lightcurves allow for the first time detailed comparison studies between these energy bands. The source has been active in several frequency bands for a large fraction of the observation time frames. Yet, we do not find obvious correlations between the VHE and the other bands over the observed time frame indicating a non-trivial interplay of the acceleration, cooling and radiative processes. It also implies a rich variety in flaring behavior, which makes this source difficult to interpret within a unique theoretical framework.

astro-ph.HE↗

An Activity-Based Quality Model for Maintainability

Maintainability is a key quality attribute of successful software systems. However, its management in practice is still problematic. Currently, there is no comprehensive basis for assessing and improving the maintainability of software systems. Quality models have been proposed to solve this problem. Nevertheless, existing approaches do not explicitly take into account the maintenance activities, that largely determine the software maintenance effort. This paper proposes a 2-dimensional model of maintainability that explicitly associates system properties with the activities carried out during maintenance. The separation of activities and properties facilitates the identification of sound quality criteria and allows to reason about their interdependencies. This transforms the quality model into a structured and comprehensive quality knowledge base that is usable in industrial project environments. For example, review guidelines can be generated from it. The model is based on an explicit quality metamodel that supports its systematic construction and fosters preciseness as well as completeness. An industrial case study demonstrates the applicability of the model for the evaluation of the maintainability of Matlab Simulink models that are frequently used in model-based development of embedded systems.

cs.SE↗

Part I, Free Actions of Compact Abelian Groups on C*-Algebras

We study free and compact group actions on unital C*-algebras. In particular, we provide a complete classification theory of these actions for compact Abelian groups and explain its relation to the classical classification theory of principal bundles.

math.OA↗

Part II, Free Actions of Compact Groups on C*-Algebras

We study a simple subclass of free actions of non-Abelian groups on unital C*-algebras, namely cleft actions. These are characterized by the fact that the associated noncommutative vector bundles are trivial. In particular, we provide a complete classification theory for these actions and describe its relations to classical principal bundles.

math.OA↗

Improving Communication in Scrum Teams

Communication in teams is an important but difficult issue. In a Scrum development process, we use the Daily Scrum meetings to inform others about important problems, news and events in the project. When persons are absent due to holiday, illness or travel, they miss relevant information because there is no document that protocols the content of these meetings. We present a concept and a Twitter-like tool that improves communication in a Scrum development process. We take advantage out of the observation that many people do not like to create documentation but they do like to share what they did. We used the tool in industrial practice and observed an improvement in communication.

cs.SE↗

What Is the Best Way For Developers to Learn New Software Tools? An Empirical Comparison Between a Text and a Video Tutorial

The better developers can learn software tools, the faster they can start using them and the more efficiently they can later work with them. Tutorials are supposed to help here. While in the early days of computing, mostly text tutorials were available, nowadays software developers can choose among a huge number of tutorials for almost any popular software tool. However, only little research was conducted to understand how text tutorials differ from other tutorials, which tutorial types are preferred and, especially, which tutorial types yield the best learning experience in terms of efficiency and effectiveness, especially for programmers. To evaluate these questions, we converted an existing video tutorial for a novel software tool into a content-equivalent text tutorial. We then conducted an experiment in three groups where 42 undergraduate students from a software engineering course were commissioned to operate the software tool after using a tutorial: the first group was provided only with the video tutorial, the second group only with the text tutorial and the third group with both. In this context, the differences in terms of efficiency were almost negligible: We could observe that participants using only the text tutorial completed the tutorial faster than the participants with the video tutorial. However, the participants using only the video tutorial applied the learned content faster, achieving roughly the same bottom line performance. We also found that if both tutorial types are offered, participants prefer video tutorials for learning new content but text tutorials for looking up "missed" information. We mainly gathered our data through questionnaires and screen recordings and analyzed it with suitable statistical hypotheses tests. The data is available at [12]. Since producing tutorials requires effort, knowing with which type of tutorial learnability can be increased to which extent has an immense practical relevance. We conclude that in contexts similar to ours, while it would be ideal if software tool makers would offer both tutorial types, it seems more efficient to produce only text tutorials instead of a passive video tutorial - provided you manage to motivate your learners to use them.

cs.SE↗

What Do Practitioners Vary in Using Scrum?

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.

cs.SE↗

Does Outside-In Teaching Improve the Learning of Object-Oriented Programming?

Object-oriented programming (OOP) is widely used in the software industry and university introductory courses today. Following the structure of most textbooks, such courses frequently are organised starting with the concepts of imperative and structured programming and only later introducing OOP. An alternative approach is to begin directly with OOP following the Outside-In teaching method as proposed by Meyer. Empirical results for the effects of Outside-In teaching on students and lecturers are sparse, however. We describe the conceptual design and empirical evaluation of two OOP introductory courses from different universities based on Outside-In teaching. The evaluation results are compared to those from a third course serving as the control group, which was taught OOP the "traditional" way. We evaluate the initial motivation and knowledge of the participants and the learning outcomes. In addition, we analyse results of the end-term exams and qualitatively analyse the results of interviews with the lecturers and tutors. Regarding the learning outcomes, the results show no signif- icant differences between the Outside-In and the "traditional" teaching method. In general, students found it harder to solve and implement algorithmic problems than to understand object oriented (OO) concepts. Students taught OOP by the Outside-In method, however, were less afraid that they would not pass the exam at the end of term and understood the OO paradigm more quickly. Therefore, the Outside-In method is no silver bullet for teaching OOP regarding the learning outcomes but has positive effects on motivation and interest.

cs.SE↗

Requirements Engineering Practice and Problems in Agile Projects: Results from an International Survey

Requirements engineering (RE) is considerably different in agile development than in more traditional development processes. Yet, there is little empirical knowledge on the state of the practice and contemporary problems in agile RE. As part of a bigger survey initiative (Naming the Pain in Requirements Engineering), we build an empirical basis on such aspects of agile RE. Based on the responses of representatives from 92 different organisations, we found that agile RE concentrates on free-text documentation of requirements elicited with a variety of techniques. Often, traces between requirements and code are explicitly managed and also software testing and RE are aligned. Furthermore, continuous improvement of RE is performed due to intrinsic motivation. Important experienced problems include unclear requirements and communication flaws. Overall, we found that most organisations conduct RE in a way we would expect and that agile RE is in several aspects not so different from RE in other development processes.

cs.SE↗

Scrum for cyber-physical systems: a process proposal

Agile development processes and especially Scrum are changing the state of the practice in software development. Many companies in the classical IT sector have adopted them to successfully tackle various challenges from the rapidly changing environments and increasingly complex software systems. Companies developing software for embedded or cyber-physical systems, however, are still hesitant to adopt such processes. Despite successful applications of Scrum and other agile methods for cyber-physical systems, there is still no complete process that maps their specific challenges to practices in Scrum. We propose to fill this gap by treating all design artefacts in such a development in the same way: In software development, the final design is already the product, in hardware and mechanics it is the starting point of production. We sketch the Scrum extension Scrum CPS by showing how Scrum could be used to develop all design artefacts for a cyber physical system. Hardware and mechanical parts that might not be available yet are simulated. With this approach, we can directly and iteratively build the final software and produce detailed models for the hardware and mechanics production in parallel. We plan to further detail Scrum CPS and apply it first in a series of student projects to gather more experience before testing it in an industrial case study.

cs.SE↗

Are Comprehensive Quality Models Necessary for Evaluating Software Quality?

The concept of software quality is very complex and has many facets. Reflecting all these facets and at the same time measuring everything related to these facets results in comprehensive but large quality models and extensive measurements. In contrast, there are also many smaller, focused quality models claiming to evaluate quality with few measures. We investigate if and to what extent it is possible to build a focused quality model with similar evaluation results as a comprehensive quality model but with far less measures needed to be collected and, hence, reduced effort. We make quality evaluations with the comprehensive Quamoco base quality model and build focused quality models based on the same set of measures and data from over 2,000 open source systems. We analyse the ability of the focused model to predict the results of the Quamoco model by comparing them with a random predictor as a baseline. We calculate the standardised accuracy measure SA and effect sizes. We found that for the Quamoco model and its 378 automatically collected measures, we can build a focused model with only 10 measures but an accuracy of 61% and a medium to high effect size. We conclude that we can build focused quality models to get an impression of a system's quality similar to comprehensive models. However, when including manually collected measures, the accuracy of the models stayed below 50%. Hence, manual measures seem to have a high impact and should therefore not be ignored in a focused model.

cs.SE↗