The amount of automotive software functions is continuously growing. With their interactions and dependencies increasing, the diagnosis’ task of differencing between symptoms indicating a fault, the fault cause itself and uncorrelated data gets enormously difficult and complex. For instance, up to 40% of automotive software functions are contributable to diagnostic functions, resulting in approximately three million lines of diagnostic code. The diagnosis’ complexity is additionally increased by legal requirements forcing automotive manufacturers maintaining the diagnosis of their cars for 15 years after the end of the car’s series production. Clearly, maintaining these complex functions over such an extend time span is a difficult and tedious task. Since data from diagnosis incidents has been transferred back to the OEMs for some years, analysing this data with statistic techniques promises a huge facilitation of the diagnosis’ maintenance. In this paper we use multivariate splitanalysis to filter diagnosis data for symptoms having real impact on faults and their repair measures, thus detecting diagnosis functions which have to be updated as they contain irrelevant or erroneous observations and/or repair measurements. A key factor for performing an unbiased split analysis is to determine an ideally representative control data set for a given test data set showing some property whose influence is to be studied. In this paper, we present a performant algorithm for creating such a representative control data set out of a very large initial data collection. This approach facilitates the analysis and maintenance of diagnosis functions. It has been successfully evaluated on case studies and is part of BMW’s continuous improvement process for automotive diagnosis.

Regression testing analyzes whether software maintenance has inadvertently broken existing functionality. Since it is costly---especially for manual testing---it is typically limited to a subset of test cases. Since impact analysis of code modifications on test cases is far from trivial for real world software, regression test selection is hard. However, if it misses affected test cases, bugs may remain unnoticed. In response, the research community has proposed numerous test selection approaches. Regression test selection is especially relevant for manual tests, since their execution costs limit the number of tests that can be executed in practice. However, existing work focuses on automated tests. Its applicability to manual tests is thus unclear. We present an industrial case study that demonstrates the challenges that regression test selection techniques face when applied to manual system tests. Furthermore, we sketch how, given these challenges, manual regression test selection can be improved.

By now there is no best practise available to effectively estimate the maintenance costs of historically grown large-scale software landscapes being productive. Most cost estimation models are either not generalizable due to highly specialised scenarios or too abstract to implement. In this paper we introduce a multi-level approach to meet these challenges, create transparency and establish a method for sustainable cost-control. At the heart of our approach we place the deduction of meaningful indicators for the estimation of current and future maintenance efforts. We present our ongoing work implementing this approach at Deutsche Post MAIL resulting in the first version of a statistical cost estimation model built of key indicators we derived from our recent analysis.

Download presentation slides:

Recently, we were prompted by a local company to improve the maintainability of a postal legacy system and to reduce the time to close the change requests. In this paper, we describe the first step of our on-going project that consists in the comparison of two alternative architectures of the target postal system using the Software Architecture Analysis Method (SAAM). The first architecture is the architecture currently used in the system while the second one is a new architecture based on SOA. Preliminary results are in favour of the new architecture that can be adapted to change faster than the actual one. The main lesson that we have learnt in this project is that SAAM is a methodology simple to apply and useful for comparison purposes but the effective final result remains somewhat subjective.

To keep our software products and cross-product software components maintainable, an approach to software architecture management with a long-term perspective is required. One-time modeling of the intended software architecture is not sufficient. Instead, it must be maintained throughout the whole life-cycle of the software system. Tool support is required to monitor the actual physical software architecture. Deviations must be resolved by modifying the software system or the software architecture description. All software architectures are required to follow a consistent architectural style, which is defined in a technology-neutral way and mapped to all technologies we use in development. In order to support this multi-technology landscape, the architectural style, and our use cases, we developed a tool suite, the BTC RevEngTools.

The United Nations Centre for Trade Facilitation and Electronic Business (UN/CEFACT) provides a conceptual, model-driven approach, named the Core Components Technical Specification (CCTS), for creating business document models. These business document models are essential for defining service interfaces of systems following the Service-oriented Architecture (SOA) paradigm. However, in such a highly dynamic environment with ever-changing market demands, business partners are confronted with the need to constantly adapt their systems. This implies revising conceptual business documents as well as adapting the corresponding service interface definitions. In this paper, we discuss evolution challenges encountered while using CCTS in industry. Furthermore, we present our current framework as well as future challenges for model-driven business document evolution in service-oriented systems.

Any changes for maintenance or evolution purposes may break existing working features, or may violate the requirements established in the previous software releases. Regression testing is essential to avoid these problems, but it may be ended up with executing many time-consuming test cases. This paper tries to address prioritizing requirementsbased regression test cases. To this end, system-level testing is focused regarding two practical issues in industrial environments: i) addressing multiple goals regarding quality, cost and effort in a project, and ii) using non-code metrics due to the lack of detailed code metrics in some situations. This paper reports a goal-driven practice at Research In Motion (RIM) towards prioritizing requirements-based test cases regarding these issues. Goal-Question-Metric (GQM) is adopted in identifying metrics for prioritization. Two sample goals are discussed to demonstrate the approach: detecting bugs earlier and maintaining testing effort. We use two releases of a prototype Web-based email client to conduct a set of experiments based on the two mentioned goals. Finally, we discuss lessons learned from applying the goal-driven approach and experiments, and we propose few directions for future research.