Variant analysis Reuse potential based on source code analysis
- PDF / 452,869 Bytes
- 6 Pages / 595.276 x 790.866 pts Page_size
- 96 Downloads / 176 Views
Variant analysis Reuse potential based on source code analysis In the automotive domain, software functionality is often provided in multiple variants. If the variants are developed in separate code bases, redundant maintenance tasks increase the development costs. To reduce these costs through systematic software reuse, reliable facts about the existing reuse potential are needed. A variant analysis can quickly determine the reuse potential based on source code analysis and thus show the way to curb development costs and time, as Fraunhofer IESE describes. 26
a u th o r s
M.Sc. Slawomir Duszynski
works as researcher and consultant in the fields of variation-rich software systems and reverse engineering at the Fraunhofer Institute for Experimental Software Engineering (IESE) in Kaiserslautern (Germany).
Dr. Martin Becker
is Department Head of the E mbedded Systems Development Department at the Fraunhofer I nstitute for Experimental Software Engineering (IESE) in K aiserslautern (Germany).
Dipl.-Inf. Ralf Kalmar
is Business Area Manager for A utomotive and Transportation S ystems at the Fraunhofer Institute for Experimental Software E ngineering (IESE) in Kaiserslautern (Germany).
The variant jungle
A frequent and important cost factor in automotive software development is the creation and maintenance of multiple variants, e.g. to satisfy country-specific or customer-specific requirements. Therefore, cost-efficient approaches to software variant management are becoming increasingly important. However, single product development often does not have the resources to invest into strategic variant management. Most companies start considering variant management when a number of variants already exist and their maintenance becomes a problem. Frequently, variants produced until that time were created by copying existing software components and adapting the copy to the changed requirements. The “clone-and-own” practice is applied especially if tight time or budget constraints make it tempting to shortcut the path of systematic reuse. Clone-and-own helps to provide new products to the market quickly, but is at the same time the root cause of many maintenance and quality problems. First of all, the effort for modifications, e.g. during bug fixing, increases because many tasks need to be performed multiple times to address each copy. Second, it is often a non-trivial task to determine whether a specific change done to one product is also relevant for another. Moreover, after some time the developers tend to lose the overview over the similarities and differences between existing variants. The title picture illustrates this issue – can you identify the similarities in these directory trees of four midsised variants? How many elements are identical in all four systems? This task is not easy. Finally, all these problems are am plified if further variants need to be introduced. While maintenance effort increases continuously, less and less time is left for new feature development. In this setting, the cost-effici
Data Loading...
