Background: Technical debt is a metaphor for trading software quality for business goals, reminding actors of the deferred cost associated with such trade-offs. The bulk of the literature on technical debt focuses on source code quality debt. Much less research is devoted to other forms of technical debt, such as documentation debt or architecture debt. In practice, however, we often observe technical debt pertaining to even higher-level, domain-oriented design issues. Goal: In this position paper, we aspire to bring attention to this gap in the study of technical debt and establish "domain debt" as a first class citizen in the discourse on technical debt. We aim to further this discourse by providing relevant examples and a working definition. Method: Based on many years of industrial experience, we present prototypical examples of domain debt from an industrial project, representing common design flaws of Enterprise Information Systems. We explore the origin and impact of these faults, and analyze the differences to other forms of technical debt. We use our examples to produce a working definition of the notion "domain debt". Conclusions: Domain debt is a useful notion in practice. It is suitable to steer the conversation around business trade-offs towards higher levels of system design quality. It has not been covered sufficiently in research so far, despite its relevance.

Existing definitions and metrics of technical debt (TD) tend to focus on static properties of software artifacts, in particular on code measurement. Our experience from software renovation projects is that dynamic aspects - runtime indicators of TD - often play a major role. In this position paper, we present insights and solution ideas gained from numerous software renovation projects at QAware and from a series of interviews held as part of the ProDebt research project. We interviewed ten practitioners from two German software companies in order to understand current requirements and potential solutions to current problems regarding TD. Based on the interview results, we motivate the need for measuring dynamic indicators of TD from the practitioners' perspective, including current practical challenges. We found that the main challenges include a lack of production-ready measurement tools for runtime indicators, the definition of proper metrics and their thresholds, as well as the interpretation of these metrics in order to understand the actual debts and derive countermeasures. Measuring and interpreting dynamic indicators of TD is especially difficult to implement for companies because the related metrics are highly dependent on runtime context and thus difficult to generalize. We also sketch initial solution ideas by presenting examples of dynamic indicators for TD and outline directions for future work.

Context/Background: To achieve high software quality, particularly in the context of agile software development, organizations need tools to continuously analyze software quality. Several quality management (QM) tools have been developed in recent years. However, there is a lack of evidence regarding the quality of QM tools, standardized definitions of such quality, and reliable instruments for measuring it. This, in turn, impedes proper selection and improvement of QM tools. Goals: We aimed at operationalizing the quality of a research QM tool, namely the ProDebt prototype, and evaluating its quality. The goal of the ProDebt prototype is to provide practitioners with support for managing software quality and technical debt. Method: We performed interviews, workshops, and a mapping study to operationalize the quality of the ProDebt prototype and to identify reliable instruments to measure it. We designed a mixed-method study aimed at formative evaluation, i.e., at assessing the quality of the ProDebt prototype and providing guidance for its further development. Eleven practitioners from two German companies evaluated the ProDebt prototype. Results: The participants assessed the information provided by the ProDebt prototype as understandable and relevant. They considered the ProDebt prototype's functionalities as easy to use but of limited usability. They identified improvement needs, e.g., that the analysis results should be linked to other information sources. Conclusions: The evaluation design was of practical value for evaluating the ProDebt prototype considering the limited resources such as the practitioners' time. The evaluation results provided the developers of the ProDebt prototype with guidance for its further development. We conclude that it can be used and tailored for replication or evaluation of other QM tools.

Continued development and maintenance of software requires understanding its design and behavior. Software at runtime creates a complex network of call--callee relationships that are hard to determine but that developers need to understand to optimize software performance. Existing tools typically focus on static aspects (e.g., Structure101 or SonarQube), or they are difficult to use and require high expertise (e.g., software profiling tools).

Within the framework of a project, a variety of known and unknown problems and difficulties in collaboration may occur, which affect how the success of a project is perceived. The goal of our research is to identify factors that influence the perceived success of a project in order to be able to take early countermeasures if project success is threatened. In this paper, we present preliminary results of a study for perceived project success. The study measures perceived project success quantitatively and qualitatively; in addition, our goal was to analyze correlations between perceived project success and aspects of collaboration, communication and individual experiences by using path analysis. The study was conducted in the context of a large-scale research and development project, where multiple partners from research and industry with a heterogeneous background work together to develop new methods and technologies in the field of "internet of things". After the first half of the project, we conducted an explorative survey with 45 persons to evaluate how the current status and project success are perceived by the partners after 1.5 years of collaborative work. As key result, we identified factors that significantly influence the perceived future project success.

One of the main challenges in empirical software engineering today lies in the aggregation of evidence. Existing summaries often use qualitative narrative approaches or ad-hoc quantitative methods, such as box plots. With these, information important for decision makers, such as existence and magnitude of a technology's effect, is hard to obtain objectively. Meta-analysis addresses this issue by providing objective quantitative information about a set of studies; however, its usefulness for software engineering studies suffers from high heterogeneity of the studies and missing information. In this paper, we describe an approach for quantitative aggregation of controlled experiments that reduces these two problems. We demonstrate the approach by aggregating available experiments to investigate whether Perspective-Based reading (PBR) improves team effectiveness compared to alternative reading approaches. We then compare the results of our aggregation to previous summaries addressing PBR's team effectiveness. Although the findings are similar, our approach is able to provide the required quantitative information objectively. Our aggregation showed that there is no clear positive effect of PBR: Inspection teams using PBR on requirements documents are more effective when compared to ad-hoc approaches, but are less effective when compared to checklists. In addition, we found strong indicators of researcher bias.

Open Source Software (OSS) has an increasing importance for the software industry. Similar to traditional (closed) software acquisition, OSS acquisition requires an assessment of whether its quality is sufficient for the intended purpose, and whether the chances of being maintained and supported in the future, as well as of keeping certain quality standards over time, are sufficiently high. In this paper, we present an approach toward a comprehensive measurement framework for OSS projects, developed in the EU project QualOSS. This approach takes into account product quality as well as process maturity and sustainability of the underlying OSS community.

For traditional software development, process maturity models (CMMI, SPICE) have long been used to assess product quality and project predictability. For OSS, on the other hand, these models are generally perceived as inadequate. In practice, though, many OSS communities are well-organized, and there is evidence of process maturity in OSS projects. This position paper presents work in progress on developing a process maturity model specifically for OSS projects. 1.

One means for institutionalizing project control, systematic quality assurance, and management support on the basis of measurement and explicit models is the establishment of so-called Software Project Control Centers. Nowadays many companies develop their own dashboards for project control or use off-the-shelf tools that provide a predefined functionality. It is not clear how to tailor an existing tool to the specific needs and goals. An engineering-like approach providing the methodological foundation is needed for systematically defining and applying project control mechanisms. "Soft-Pit" is a research project focusing on an improvement-oriented approach for setting up and applying project control mechanisms in a goal-oriented way and evaluating the practical benefits of such a control center. This article describes the results of industrial case studies conducted in the context of the project. Moreover, lessons learned are discussed, related work is described, and future work is presented.

Many software development organizations still lack support for detecting and reacting to critical project states in order to achieve planned goals. One means to institutionalize project control, systematic quality assurance, and management support on the basis of measurement and explicit models is the establishment of so-called software project control centers. However, there is only little experience reported in the literature with respect to setting up and applying such control centers in industrial environments. One possible reason is the lack of appropriate evaluation instruments (such as validated questionnaires and appropriate analysis procedures). Therefore, we developed an initial measurement instrument to systematically collect experience with respect to the deployment and use of control centers. Our main research goal was to develop and evaluate the measurement instrument. The instrument is based on the technology acceptance model (TAM) and customized to project controlling. This article illustrates the application and evaluation of this measurement instrument in the context of industrial case studies and provides lessons learned for further improvement. In addition, related work and conclusions for future work are given.

A systematic approach to decision making in software engineering is required, for instance, if an organization aims at achieving CMMI level three. Rational decision making regarding the selection and introduction of SE technologies requires adequate information about their suitability for the intended organizational context. Research is often unable to provide such information, and this could be one reason why promising techniques are sometimes not adopted in practice. From a research point of view, successful technology transfer requires knowing which information decision makers in industry need, and where they actually look for it. With this knowledge, empirical research can strive to produce the needed information in order to increase the likelihood of successful technology adoption. To address these questions, we conducted an online survey among German software industry decision makers. To focus the survey, we used inspections as an exemplary technology. We invited 9653 companies to participate, from which we received 92 fully completed questionnaires. Our main findings are that information regarding the impact of technologies on product quality, cost, and development time, as well as on technology cost-benefit ratio is considered most important among decision makers. The preferred sources of information are colleagues, textbooks, and industry workshops.

SOFTPIT 2007 is the first workshop on Measurement-based Cockpits for Distributed Software and Systems Engineering Projects. Its goal is to discuss technical and societal challenges for software cockpits in global software development projects.

No abstract available.