Frank Houdek

Establishing experience factories at Daimler-Benz: an experience report

The experience factory concept enables systematic learning and continuous improvement in software development. As with most learning initiatives, it is hard to establish. In our experience, there is a great deal of uncertainty and skepticism about the mission and contents of an experience factory. The starting phase is especially endangered through pitfalls or unexpected delays. As expectations vary and there is pressure to demonstrate success within only a few months, tension arises which may jeopardize the entire enterprise. In the course of a large-scale software improvement program, we have established three experience factories in different environments of the Daimler-Benz AG within two years. At each site, several application projects are involved. We describe how we approached the task, what actions we took, and the lessons we learned.

Organizational learning and experience documentation in industrial software projects

Learning from experiences in the software domain is an important issue for the DaimlerChrysler Corporation. Unfortunately, there are no textbook recipes on how a process of organizational learning can be established. In particular, those types of experiences must be identified that are potentially valuable for reuse. Furthermore, the organization and representation of such experiences must be defined in such a way that they can easily be retrieved and used for the solving of new problems. In this paper, we provide some insights that we gained during the examination of these issues in projects aiming at establishing a so-called experience factory.

Quality patterns—an approach to packaging software engineering experience

Building up experience for its reuse plays a key role in context of systematic qualit,y and process improvement. An organizational approach for building competencies and supplying them to software projects is provided by the concept of the experience factory. A basic step within the experience factory is the continual accumulation of all kinds of experience and storing them syst emetically in a repository, the experience base. A systematic and adequate packaging of experience is essential to successful reuse in this context. It has to be identified, analyzed for its potential reuse and tailored to meet the future needs. In this paper we introduce quality patterns as a suitable way of packaging experience to make it reusable. Main characteristic of this approach is that gained experience is packaged beyond a problem–solu tion strategy. To illustrate our approach, we enrich a common mechanism in quality improvement programs in view of reusability. To enable an effective handling of quaiity patterns we have developed a hypertext–breed prototype of an experience base which is presented, too.

Guiding requirements engineering for software-intensive embedded systems in the automotive industry

Over the past decade, a dramatic increase of functionality, quantity, size, and complexity of software-intensive embedded systems in the automotive industry can be observed. In particular, the growing complexity drives current requirements engineering practices to the limits. In close cooperation between partners from industry and academia, the recently completed REMsES (Requirements Engineering and Management for software-intensive Embedded Systems) project has developed a guideline to support requirements engineering processes in the automotive industry. The guideline enables the requirements engineers to cope with the challenges that arise due to quantity, size and complexity of software-intensive systems. This article presents the major results of the project, namely, the fundamental principles of the approach, the guideline itself, the tool support, and the major findings obtained during the evaluation of the approach.

Experiences in managing an automotive requirements engineering process

The specification volume for all software-based systems that are built in a modern car has passed the 20,000 pages mark. Even for a single component, we find specification documents comprising several hundred pages. Clearly, such specification documents cannot be created and changed simply and quickly. We hence need a systematic process to elicit and maintain, negotiate and validate all requirements, i.e. a proper requirements engineering process. We present an example for such an automotive requirements engineering process and the instruments we employed to manage this process. The experiences are drawn from projects at DaimlerChrysler passenger car development. The paper sketches the requirements engineering process used, the core management instruments deployed, e.g. a feature list, and observations gained in utilizing this process.

Analyzing requirements engineering processes: a case study

Thorough process improvement starts with an analysis of the current situation. This is also true for requirements engineering processes. The goal of cooperation between DaimlerChrysler and the department of Software Systems Engineering at the University of Essen is to establish a framework for such RE process analysis in the area of car manufacturing. In this paper, we report on our first analysis using a traditional interview technique and the results obtained. We compare the major findings with existing research and other experiences, identify a set of challenges and provide an outlook of our future investigations.

Towards systematic recycling of systems requirements

Many (technical) systems are not developed from scratch but as an evolution of existing systems. Consequently, a large portion of the system requirements employed can be recycled when building the next version of the product. Usually, this recycling step is performed unsystematically, i.e. simply by copying and modifying complete requirements documents. In this paper, we present in a case study a lightweight requirements recycling approach which evolved from observations and concrete needs of projects at DaimlerChrysler Passenger Car Development. The basic idea of the approach is separation of model-dependent from model-independent requirements on the same level of abstraction. This notion is supported by document structures, criteria for identifying reusable requirements and tool support. The paper presents the core elements of the approach and provides observations and valuable experiences we made in the projects.

Semi-automatic identification of features in requirement specifications

Reuse of requirements leads to reduction in time spent for specification of new products. Variant management of requirement documents is an essential prerequisite in terms of a successful reuse of requirements. It supports the decisions if available requirements can be reused or not. One possibility to document the variability is feature modelling. One main challenge while introducing feature modelling in a grown environment is to extract product features from large natural language specifications. The current practice is a manual review of specifications conducted by domain experts. This procedure is very costly in terms of time. A promising approach to optimize feature identification is a semi-automatic identification of features in natural language specifications based on lexical analysis. This paper presents the current approaches used for handling variability in automotive specifications at Daimler passenger car development along with first experiences gained in using the optimized approach for feature identification using a lexical analysis.

DEFECT DETECTION FOR EXECUTABLE SPECIFICATIONS — AN EXPERIMENT

The deployment of executable specifications has increased significantly in the last few years. Just as with any other specification documents, these specifications must be examined to ensure the necessary degree of quality. A common and successful technique used for examining traditional specifications is inspection. Now the question has arisen whether inspections on executable specification are the best choice, or if other techniques which use the execution capabilities of the models perform better. In this paper, we empirically compare several defect detection techniques for executable specifications. In particular, we examine inspections, testing, and ad-hoc simulation. Here, we use the specification languages Statemate and Matlab/Simulink. Also, we take a closer look at the inspection process itself and try to quantify the benefits of an inspection meeting for executable specifications.

Transferring and Evolving Experience: A Practical Approach and Its Application to Software Inspections

Experience and knowledge management are seen as key capabilities for systematic software development and process improvement. However, it is still not quite clear, how to get this vision to work. In this paper, a process for systematic experience transfer is presented. It covers the activities of experience acquisition, experience documentation and evolution, and experience reuse. This process is a result of the German publicly-funded project SoftQuali, and its practical use is demonstrated by two real project examples, dealing with experience transfer for software inspections. In general it is described how experience can be packaged, both to transfer the technique and to improve it.