The Benefits of Pre-Requirements Specification Traceability [RE 2022]

Abstract: Requirements traceability is the ability to trace requirements to other software engineering artifacts. Traceability can be classified as either pre- or post-requirements specifications (RS) traceability. Pre-RS traceability is the ability to trace between requirements and their origin. However, the benefits of pre-RS traceability are often not clear. In this article, we systematically lay out the benefits of pre-RS traceability. We present results from both a literature review and a qualitative survey of practitioners involved with documenting and utilizing such trace links. We find that the benefits strongly depend on the practitioners, their tasks, and the project environment. Awareness of these relationships supports a clearer understanding of the benefits of pre-RS traceability and thus motivates successful implementation of the required practices. The results of our research motivates the adoption of pre-RS traceability and present problem areas for future research.

Continue reading “The Benefits of Pre-Requirements Specification Traceability [RE 2022]”

A Validation of QDAcity‑RE for Domain Modeling Using Qualitative Data Analysis [RE Journal]

Abstract: Using qualitative data analysis (QDA) to perform domain analysis and modeling has shown great promise. Yet, the evaluation of such approaches has been limited to single-case case studies. While these exploratory cases are valuable for an initial assessment, the evaluation of the efficacy of QDA to solve the suggested problems is restricted by the common single-case case study research design. Using our own method, called QDAcity-RE, as the example, we present an in-depth empirical evaluation of employing qualitative data analysis for domain modeling using a controlled experiment design. Our controlled experiment shows that the QDA-based method leads to a deeper and richer set of domain concepts discovered from the data, while also being more time efficient than the control group using a comparable non-QDA-based method with the same level of traceability.

Continue reading “A Validation of QDAcity‑RE for Domain Modeling Using Qualitative Data Analysis [RE Journal]”

The JDownloader Immune System for Continuous Deployment [HICSS 2020]

Abstract: Continuous deployment can reduce the time from a source code change to a newly deployed application significantly. Increased innovation speed can make all the difference in a competitive market situation. However, deploying at high frequency requires high speeds of discovering bugs in the deployed software. Using the JDownloader file download manager as our example, we present a fitness model to evaluate a continuously deployed software during operation for expected behavior, present the design and implementation of a monitoring component, and evaluate the model and its implementation using data from JDownloader’s multi-million member strong user base. Our evaluation finds that there had been thousands of undetected bugs, and that newly created bugs can be detected and reported 16 times faster than before.

Keywords: Continuous deployment, continuous delivery, immune system

Reference: Rechenmacher, T., Riehle, D., & Weber, M. (2020). The JDownloader Immune System for Continuous Deployment. In Proceedings of the 53rd Hawaii International Conference on System Sciences (HICSS 2020), pp. 6559-6568.

Download: The paper is available a PDF file.

Do You Need a Macbook to Learn to Code? (Coding vs. Systems Building)

Someone on Twitter asked this question and people loved to weigh in. Most answered: “No, just get an old $200 laptop.” While not wrong, this answer misses the point. Coding, here, apparently means reading and writing code. For that, indeed, any cheap computer will do. However, being able to read and write code does not mean you will be able to build and ship systems, which is what customers pay for.

Continue reading “Do You Need a Macbook to Learn to Code? (Coding vs. Systems Building)”

CTO vs. VP of Engineering

In tech companies, startups and large companies alike, of the many roles you need to define, two seem to be particularly confusing to German startups: The CTO and the VP of Engineering role. Many German startups I’ve seen simply have a person titled CTO who does both (and sometimes neither). These two roles are very different! They require different skill sets and while temporarily one person may be able to fill both shoes, longer term they are better filled by two different people. In more detail:

Continue reading “CTO vs. VP of Engineering”

What’s Wrong in Software Product Line Engineering? The Separation of the Platform as a Cost Center from the Product Units as Profit Centers

In three previous posts I had reported about our research into problems with product line engineering. Three important specific problems (of several more) were:

  1. Lack of resources in the platform organizational unit
  2. Insufficient collaboration between product and platform unit
  3. Political power play between product units

Continue reading “What’s Wrong in Software Product Line Engineering? The Separation of the Platform as a Cost Center from the Product Units as Profit Centers”

What’s Wrong in Software Product Line Engineering? Political Power Play Between Product Units

In previous blog posts we identified

as causes for problems in software product line engineering. Of several more, I want to pick a third and final one, before we turn to the root cause of it all in the next blog post. This third cause is the political power play between product units as they try to prioritize requirements for the platform organization.

Continue reading “What’s Wrong in Software Product Line Engineering? Political Power Play Between Product Units”

What’s Wrong in Software Product Line Engineering? Insufficient Collaboration between Product and Platform Unit

As previously posted, we analyzed current problems in product line engineering. One case study was a healthcare software product line, one was a business software product line, and one was a telco carrier software product line. All developers in their respective product line were homogeneous in time and culture (one main location, one social culture), that is, we had no problems of globally distributed software development. This both made the analyses easier but also limits the generalizability of our conclusions.

We presented our analysis using cause-and-effect chain diagrams. The following figures shows an excerpt of these diagrams.

Continue reading “What’s Wrong in Software Product Line Engineering? Insufficient Collaboration between Product and Platform Unit”