To maintain and understand large applications, it is important to know their architecture. The first problem is that unlike classes and packages, architecture is not explicitly represented in the code. The second problem is that successful applications evolve over time, so their architecture inevitably drifts. Reconstructing the architecture and checking whether it is still valid is therefore an important aid. While there is a plethora of approaches and techniques supporting architecture reconstruction, there is no comprehensive software architecture reconstruction state of the art and it is often difficult to compare the approaches. This paper presents a state of the art in software architecture reconstruction approaches.

/pdf/software-architecture-reconstruction-a-process-oriented-7l4j2qqyzy.pdf

Software Architecture Reconstruction: A Process-Oriented Taxonomy

Software product lines have numerous members. Thus, a product line infrastructure must cover various systems. This is the significant difference to usual software systems and the reason for additional requirements on the various assets present during software product line engineering. It is imperative that they support the description of the product line as a whole, as well as its instantiation for the derivation of individual products.Literature has already addressed how to create and instantiate generic product line assets, such as domain models and architectures to generate instance specific ones [1, 2, 3], yet little attention has been given on how to actually deal with this genericity at the code level.This paper addresses the issue of handling product line variability at the code level. To this end various implementation approaches are examined with respect to their use in a product line context.

Implementing product line variabilities

This paper aims at identifying some of the key factors in adopting or running a company-wide software reuse program. Key factors are derived from empirical evidence of reuse practices, as emerged from a survey of projects for the introduction of reuse in European companies: 24 such projects performed from 1994 to 1997 were analyzed using structured interviews. The projects were undertaken in both large and small companies, working in a variety of business domains, and using both object-oriented and procedural development approaches. Most of them produce software with high commonality between applications, and have at least reasonably mature processes. Despite that apparent potential for success, around one-third of the projects failed. Three main causes of failure were not introducing reuse-specific processes, not modifying nonreuse processes, and not considering human factors. The root cause was a lack of commitment by top management, or nonawareness of the importance of those factors, often coupled with the belief that using the object-oriented approach or setting up a repository seamlessly is all that is necessary to achieve success in reuse. Conversely, successes were achieved when, given a potential for reuse because of commonality among applications, management committed to introducing reuse processes, modifying nonreuse processes, and addressing human factors.

Success and failure factors in software reuse

Product derivation in software product families: a case study

Traceability of software artefacts has been recognised as an important factor for supporting various activities in the software system development process. In general, the objective of traceability is to improve the quality of software systems. More specifically, traceability information can be used to support the analysis of implications and integration of changes that occur software systems; the maintenance and evolution of software systems; the reuse of software system components by identifying and comparing requirements of new and existing systems; the testing of software system components; and system inspection, by indicating alternatives and compromises made during development. Traceability enables system acceptance by allowing users to better understand the system and contributes to a clear and consistent system documentation. Over the last few years, the software and system engineering communities have developed a large number of approaches and techniques to address various aspects of traceability. Research into software traceability has been mainly concerned with the study and definition of different types of traceability relations; support for the generation of traceability relations; development of architectures, tools, and environments for the representation and maintenance of traceability relations; and empirical investigations into organisational practices regarding the establishment and deployment of traceability relations in the software development life cycle. However, despite its importance and the work resulted from numerous years of research, empirical studies of traceability needs and practices in industrial organisations have indicated that traceability support is not always satisfactory. As a result, traceability is rarely established in existing industrial settings. In this article, we present a roadmap of research and practices related to software traceability and identify issues that are still open for further research. Our roadmap is organised according to the main topics that have been the focus of software traceability research.

Software Traceability : A Roadmap

Software product lines have recently been introduced as one of the most promising advances for efficient software development. Yet upon close examination, there are few guidelines or methodologies available to develop and deploy product lines beyond existing domain engineering approaches. The latter have had mixed success within commercial enterprises because of their deployment complexity, lack of customizability, and especially their misplaced focus, that is on domains as opposed to products. To tackle these problems we developed the PuLSETM (Product Line Software Engineering) methodology for the purpose of enabling the conception and deployment of software product lines within a large variety of enterprise contexts. This is achieved via product-centric focus throughout the phases of PuLSETM, customizability of its components, incremental introduction capability, maturity scale for structured evolution, and adaptations to a few main product development situations. PuLSETM is the result of a bottom-up effort: the methodology captures and leverages the results (the lessons learned) from our technology transfer activities with our industrial customers. We present in this paper the main ideas behind PuLSETM and illustrate the methodology with a running example taken from our transfer experience.

/pdf/pulse-a-methodology-to-develop-software-product-lines-3jmkvsro3u.pdf

PuLSE: a methodology to develop software product lines

The creation and validation of product line software architectures are inherently more complex than those of software architectures for single systems. This paper compares a process for creating and evaluating a traditional, one-of-a- kind software architecture with one for a reference software architecture. The comparison is done in the context of PuLSE-DSSA, a customizable process that integrates both product line architecture creation and evaluation.

/pdf/creating-product-line-architectures-6ssq0owjpx.pdf

Creating Product Line Architectures

Jean-Marc DeBaud Oliver Flege Peter Knauber Fraunhofer Institute for Experimental Fraunhofer Institute for Experimental Fraunhofer Institute for Experimental Software Engineering (IESE) Software Engineering (IESE) Software Engineering (IESE) Sauetwiesen 6 Sauerwiesen 6 Sauetwiesen 6 D-67661 Kaiserslautern, Germany D-67661 Kaiserslautern, Germany D-67661 Kaiserslautern, Germany debaud @ iese.fhg.de flege@ iese.fhg.de knauber@iese.fhg.de

Oliver Flege

Papers

PuLSE: a methodology to develop software product lines

Creating Product Line Architectures

PuLSE-DSSA—a method for the development of software reference architectures

A Process for Product Line Architecture Creation and Evaluation -- PuLSE-DSSA version 2.0