• Keine Ergebnisse gefunden

Development of flexible software process lines with variability operations: A longitudinal case study

N/A
N/A
Protected

Academic year: 2022

Aktie "Development of flexible software process lines with variability operations: A longitudinal case study"

Copied!
2
0
0

Wird geladen.... (Jetzt Volltext ansehen)

Volltext

(1)

Jens Knoop, Uwe Zdun (Hrsg.): Software Engineering 2016, Lecture Notes in Informatics (LNI), Gesellschaft für Informatik, Bonn 2016 111

Development of Flexible Software Process Lines with Variability Operations: A Longitudinal Case Study

Patrick Dohrmann1, Joachim Schramm1and Marco Kuhrmann2

Abstract:Context:A software process line helps to systematically develop and manage families of processes and, as part of this, variability operations provide means to modify and reuse pre- defined process assets.Objective:Our goal is to evaluate the feasibility of variability operations to support the development of flexible software process lines.Method:We conducted a longitudinal study in which we studied 5 variants of the V-Modell XT process line for 2 years.Results:Our results show the variability operation instrument feasible in practice. We analyzed 616 operation exemplars addressing various customization scenarios, and we found 87 different operation types.

Conclusions:Although variability operations are only one instrument among others, our results suggest this instrument useful to implement variability in real-life software process lines.

This summary refers to the paperDevelopment of Flexible Software Process Lines with Variability Operations: A Longitudinal Case Study[Do15]. This paper was published as full research paper in theEASE’2015proceedings.

Keywords:software process, software process lines, variability operations, longitudinal study

1 Introduction

Different studies show manifold of processes used in practice and companies combine multiple processes and adopt these to specific requirements. Yet, defining adequate processes is a complex activity requiring deep knowledge of the actual domain in particular and software engineering in general. To overcome these challenges, in [Ro05], Rombach votes for adopting well-known concepts from software product lines to developSoftware Process Lines(SPrL). Still, these approaches lack in evidence of their feasibility in practice. In Germany, the V-Modell XT is the standard software process for IT development projects in Germany’s public sector. Starting with its release in 2005, the number of process variants using the so-called reference model increased and led to serious problems when the reference model evolved. Therefore, it was decided to adopt concepts from SPrLs to the V-Modell XT for the purpose of improving support for an efficient management of the reference model and its variants, e.g., automatic updates.

Problem.While defining the variability operations for the V-Modell XT framework, the major problem was to find suitable and actionable variability operations. Furthermore, we lack long-term studies analyzing the feasibility of SPrL approaches.

1Technische Universität Clausthal, Institut für Informatik - Software Systems Engineering, Julius-Albert-Str. 4, 38678 Clausthal-Zellerfeld, {jschr,pdo}@tu-clausthal.de

2University of Southern Denmark, Campusvej 55, 5230 Odense M, Denmark, kuhrmann@acm.org

(2)

112 Patrick Dohrmann et al.

Objective, Method, and Contribution.To understand software process variability, we analyze the feasibility of the variability operation instrument and its improvement. We conducted a longitudinal case study in which we investigated two baselines (a reference model and 5 of its variants [Ku14] and [Do15]) of the V-Modell XT conducted by two teams of researchers. In our study, we contribute a catalog 87 different (78 unique) variability operations and a quantitative analysis of their use in practice.

2 Results

Our study of two major releases of the reference model and its variants resulted in 87 variability operations for modifying process structure and content. In the study, we also observed an evolution, and we observed parallel development of variability operation sets by different process-engineering team (studying the result sets in detail shows copied/modified operations, so that we end up with 78 unique variability operations). In total, all variants use variability operations and the number of operation exemplars increased over time (more variants using this instrument, more operation exemplars).

Among the 616 operation exemplars, 223 are instances of only 6 types indicating to customization patterns. Further findings show variability operations also aiding process metamodel evolution and the combination with other variability instruments.

3 Conclusion

In summary, we found the concept of variability operations sufficient to support process engineers in constructing a process variant from a software process line. However, variability operations are only one instrument among others and, thus, can (and should) be combined with other instruments.

References

[Do15] Dohrmann, P.; Schramm, J.; Kuhrmann, M.: Development of Flexible Software Process Lines with Variability Operations: A Longitudinal Case Study. Proc. of Int.

Conf. on Evaluation and Assessment in Software Engineering, ACM, New York, NY, pp. 13:1-13:10, 2015.

[Ku14] Kuhrmann, M.; Mendez Fernandez, D.; Ternite, T.: Realizing software process lines:

Insights and experiences. Proc. of Intl. Conf. on Software and Systems Process, ACM, New York, NY, pp.110–119, 2014.

[Ro05] Rombach, D.: Integrated software process and product lines. Proc. of Int. Software Process Workshop, Springer, Berlin-Heidelberg, pp. 83-90, 2005.

Referenzen

ÄHNLICHE DOKUMENTE

By invoking loadClass within the target application, the new class version is loaded by the same class loader that loaded the original class (Listing 1.2, Line 20), which ensures

We classify this aspect as variability in components , which includes the variable hardware, data models, and behavior of a component.. Hardware variability describes all changes

We measured the metrics introduced in the Section 3.2 on the XML representation. Basically, the analysis rests on the traversal of the XML-annotated source code using our

In this study, we performed a four-dimension qualitative analysis with respect to common functionalities provided by feature modeling tools: (i) Feature Model

They are generated from the base class and its refinements in two steps: First, we merge refinements belonging to features of the same binding unit into a single class (static

Safety standards such as IEC 61508, DO-178B suggest development according to V-model.  Specification and implementation linked by verification and validation.  Variety of

 Variants of a product line share common features.  Feature models describe features and

As SPACE is intended to be a basis for both a modeling and an execution platform, it must incorporate both process models and process instances (i.e., concrete model