Abstract-Published software quality models either provide abstract quality attributes or concrete quality assessments. There are no models that seamlessly integrate both aspects. In the project Quamoco, we built a comprehensive approach with the aim to close this gap.For this, we developed in several iterations a meta quality model specifying general concepts, a quality base model covering the most important quality factors and a quality assessment approach. The meta model introduces the new concept of a product factor, which bridges the gap between concrete measurements and abstract quality aspects. Product factors have measures and instruments to operationalise quality by measurements from manual inspection and tool analysis. The base model uses the ISO 25010 quality attributes, which we refine by 200 factors and 600 measures for Java and C# systems.We found in several empirical validations that the assessment results fit to the expectations of experts for the corresponding systems. The empirical analyses also showed that several of the correlations are statistically significant and that the maintainability part of the base model has the highest correlation, which fits to the fact that this part is the most comprehensive. Although we still see room for extending and improving the base model, it shows a high correspondence with expert opinions and hence is able to form the basis for repeatable and understandable quality assessments in practice.

Software quality models are a well-accepted means to support quality management of software systems. Over the last 30 years, a multitude of quality models have been proposed and applied with varying degrees of success. Despite successes and standardisation efforts, quality models are still being criticised, as their application in practice exhibits various problems. To some extent, this criticism is caused by an unclear definition of what quality models are and which purposes they serve. Beyond this, there is a lack of explicitly stated requirements for quality models with respect to their intended mode of application. To remedy this, this paper describes purposes and usage scenarios of quality models and, based on the literature and experiences from the authors, collects critique of existing models. From this, general requirements for quality models are derived. The requirements can be used to support the evaluation of existing quality models for a given context or to guide further quality model development.

Context Software quality models provide either abstract quality characteristics or concrete quality measurements; there is no seamless integration of these two aspects. Quality assessment approaches are, hence, also very specific or remain abstract. Reasons for this include the complexity of quality and the various quality profiles in different domains which make it difficult to build operationalised quality models. Objective In the project Quamoco, we developed a comprehensive approach aimed at closing this gap. Method The project combined constructive research, which involved a broad range of quality experts from academia and industry in workshops, sprint work and reviews, with empirical studies. All deliverables within the project were peer-reviewed by two project members from a different area. Most deliverables were developed in two or three iterations and underwent an evaluation. Results We contribute a comprehensive quality modelling and assessment approach: (1) A meta quality model defines the structure of operationalised quality models. It includes the concept of a product factor, which bridges the gap between concrete measurements and abstract quality aspects, and allows modularisation to create modules for specific domains. (2) A largely technology-independent base quality model reduces the effort and complexity of building quality models for specific domains. For Java and C# systems, we refined it with about 300 concrete product factors and 500 measures. (3) A concrete and comprehensive quality assessment approach makes use of the concepts in the meta-model. (4) An empirical evaluation of the above results using real-world software systems showed: (a) The assessment results using the base model largely match the expectations of experts for the corresponding systems. (b) The approach and models are well understood by practitioners and considered to be both consistent and well suited for getting an overall view on the quality of a software product. The validity of the base quality model could not be shown conclusively, however. (5) The extensive, open-source tool support is in a mature state. (6) The model for embedded software systems is a proof-of-concept for domain-specific quality models. Conclusion We provide a broad basis for the development and application of quality models in industrial practice as well as a basis for further extension, validation and comparison with other approaches in research

Background:] Nowadays, industries are facing the problem that the Requirements Engineering (RE) process is highly volatile, since it depends on project influences from the customer's domain or from process models used. Artefactbased approaches promise to provide guidance in the creation of consistent artefacts in volatile project environments, because these approaches concentrate on the artefacts and their dependencies, instead of prescribing processes. Yet missing, however, is empirical evidence on the advantages of applying artefact-based RE approaches in real projects. [Aim:] We developed a customisable artefact-based RE approach for the domain of business information systems. Our goal is to investigate the advantages and limitations of applying this customisable approach in an industrial context. [Method:] We conduct a case study with our artefact-based RE approach and its customisation procedure. For this, we apply it at a software development project at Siemens following the steps of the customisation procedure. We assess our approach in direct comparison with the previously used RE approach considering possible improvements in the process and in the quality of the produced artefacts. [Results:] We show that our approach is flexible enough to respond to the individual needs in the analysed project environment. Although the approach is not rated to be more productive, we find an improvement in the syntactic and the semantic quality of the created artefacts. [Conclusions:] We close a gap in the RE literature by giving empirical evidence on the advantages of artefact orientation in RE in an industrial setting.

Context: Requirements Engineering (RE) is a critical discipline mostly driven by uncertainty, since it is influenced by the customer domain or by the development process model used. Volatile project environments restrict the choice of methods and the decision about which artefacts to produce in RE.Objective: We aim to investigate RE processes in successful project environments to discover characteristics and strategies that allow us to elaborate RE tailoring approaches in the future.Method: We perform a field study on a set of projects at one company. First, we investigate by content analysis which RE artefacts were produced in each project and to what extent they were produced. Second, we perform qualitative analysis of semi-structured interviews to discover project parameters that relate to the produced artefacts. Third, we use cluster analysis to infer artefact patterns and probable RE execution strategies, which are the responses to specific project parameters. Fourth, we investigate by statistical tests the effort spent in each strategy in relation to the effort spent in change requests to evaluate the efficiency of execution strategies.Results: We identified three artefact patterns and corresponding execution strategies. Each strategy covers different project parameters that impact the creation of certain artefacts. The effort analysis shows that the strategies have no significant differences in their effort and efficiency.Conclusions: In contrast to our initial assumption that an increased effort in requirements engineering lowers the probability of change requests or project failures in general, our results show no statistically significant difference between the efficiency of the strategies. In addition, it turned out that many parameters considered as the main causes for project failures can be successfully handled. Hence, practitioners can apply the artefact patterns and related project parameters to tailor the RE process according to individual project characteristics.

This paper presents the findings of a survey on quality models in practice conducted among four software companies in Germany. In the first phase of the study, 25 quality managers and users of software quality models were interviewed regarding the use of quality models, quality assurance techniques, and problems arising from the current situation in their companies. We present qualitative and quantitative findings as well as our plans for the second study phase including an international online questionnaire

No abstract

In order to assess software quality by software metrics, usually, thresholds for metric values are needed. A common problem is to define reasonable threshold values. One possible solution is to use a benchmarking approach: the threshold value for a metric is calculated based on the metric values of a set of systems, which are called benchmarking base. A relevant question is, how the used benchmarking base influences the result of the software quality assessment. Based on the quality assessment approach of Quamoco, we conduct a series of experiments, using different benchmarking bases. For each benchmarking base a quality assessment of a series of test systems is conducted. We analyze the whether the quality assessment results of the test systems are concordant for different benchmarking bases. The main findings are: (1) The bigger the benchmarking base, the less divergent are the rankings, and the less is the variance of the results. (2) The size of the systems contained within a benchmarking base does not influence the results, i.e. a benchmarking base containing small systems works equally well for small and large systems, and vice versa. These results show that benchmarking is a feasible approach for determining threshold values.