Paper: Incremental and Iterative Reengineering towards Software Product Line: An Industrial Case Study
Authors: Gang Zhang, Liwei Shen, Xin Peng, Zhenchang Xing and Wenyun Zhao
Session: Industry Track Session 3: Evolution and migration
Gen AI in Business - Global Trends Report 2024.pdf
Industry - Evolution and migration - Incremental and Iterative Reengineering towards Software Product Line: An Industrial Case Study
1. 27th IEEE International Conference on Software Maintenance
Incremental and Iterative Reengineering
towards Software Product Line:
An Industrial Case Study
Gang Zhang1,3, Liwei Shen1, Xin Peng1, Zhenchang Xing2, Wenyun Zhao1
1School of Computer Science, Fudan University, Shanghai, China
2School of Computing, National University of Singapore, Singapore
3Alcatel-Lucent Shanghai Bell, Shanghai, China
pengxin@fudan.edu.cn
www.se.fudan.edu.cn/pengxin
2. Background: Reengineering towards SPL
• SPL: Software Product Line [SEI]
– a set of software-intensive systems that share a
common, managed set of features
– developed from a common set of core assets in a
prescribed way
• SPL adoption by reengineering is common
– a collection of variant products developed with ad-hoc
reuse already exist there
– reengineering: migration to SPL in an extractive way
commonality and variability among variant products are identified
core assets are extracted
legacy products are reconstructed based on the shared core assets
2/25
2011-10-06 http://www.se.fudan.edu.cn
3. The Subject Case: IXM-PF
a telecom product family in Alcatel-Lucent
AXM
History: > 10 years
IXM Variants: 6 products
Scale: >10M LOC/product
IXM-G IXM-A
300~400 modules/product
IXM-U IXM-MD
- New products were developed by branching and adapting
from selected ancestors in an ad-hoc way
- Variant products were maintained separately
3/25
2011-10-06 http://www.se.fudan.edu.cn
4. Problems in IXM-PF Evolution
product Cost of Cost of
branches new feature maintenance
development
4/25
2011-10-06 http://www.se.fudan.edu.cn
5. Reengineering to SPLE
Product A Product B
How to establish the core
assets in an extractive way?
Product C 5/12
Support product customization
Improve maintainability
Improve extensibility
SPL core assets 5/25
2011-10-06 http://www.se.fudan.edu.cn
6. SPL Reengineering:
Incremental over Big-bang
The Economic Impact of Product Line Adoption and Evolution.
by K. Schmid and M. Verlage
IEEE Software 2002, 19(4)
Huge initial
investment
Big-bang versus Incremental
6/25
2011-10-06 http://www.se.fudan.edu.cn
7. More Challenges
Don’t bother me when
I am busy working for Can we achieve
a new delivery! real benefits from
SPL reengineering?
developer
multi-tasking team management
lack of SPLE knowledge
and confidence
limited budget:
often no additional budget for SPL reengineering 7/25
2011-10-06 http://www.se.fudan.edu.cn
8. Requirements for SPL Reengineering Process
R1: Proper increment definition
R2: Steady reengineering process
to deal with
Insufficient confidence on the success
Limited additional budget for reengineering
Parallel work on regular product delivery
8/25
2011-10-06 http://www.se.fudan.edu.cn
9. IXM-PF Reengineering Project Overview
• The same team took on the regular
maintenance and delivery tasks of related
products during the reengineering process
• Some principles from agile development
are adopted
• Achieved initial success after 1.5 years
– an initial set of core assets established
– reused in both legacy products and several new products
– the confidence of the organization on SPL reengineering
strengthened
9/25
2011-10-06 http://www.se.fudan.edu.cn
10. Principles in our Attempts
Principle Objective
value-based increment
definition Early success
domain driven reengineering Less initial investment
localized impact Low Risk
iterative propagation Early value delivery
10/25
2011-10-06 http://www.se.fudan.edu.cn
11. The Reengineering Process
an increment
(component)
The next increment Iterative propagated
to other products
11/25
2011-10-06 http://www.se.fudan.edu.cn
13. Value-Driven Increment Definition
SPL dimension
(space)
product
specific
component
component
shared with
differences
component
shared without Project dimension
any differences
(time)
low medium high
possibility of being involved in future maintenance and extension
13/25
2011-10-06 http://www.se.fudan.edu.cn
14. Reference Product Selection
• Be actively maintained
• Has the most “common” implementation of the component
Reference Product Selection for EntityManagement
14/25
2011-10-06 http://www.se.fudan.edu.cn
15. Domain Model Definition
@reference
product
System
Node Lookup
UniqueID
Entity Indexing
ReadableID
ConcreteEntity ConcreteEntity domain
TypeA TypeX concept
help the clarification and refactoring of
the component responsibility, boundary, responsibility
and internal implementation
boundary
help addressing the variability of the
components across variant products implementation
15/25
2011-10-06 http://www.se.fudan.edu.cn
17. Boundary Reengineering
other components @reference
product
new boundary
old boundary adapter
Component implementation
will be replaced latter
- internal-adapters were implemented to provide the expected interfaces
- external-dependencies of other components on the current component are
cleaned up-
- system level tests were executed continuously to guarantee that no side-effect
was introduced
17/25
2011-10-06 http://www.se.fudan.edu.cn
18. Internal Implementation Reengineering
@reference
product
UniqueIDLookup
EntityManager LookupStrategy
ReadableIDLookup
Entity EntityTypeStrategy EntityTypeAStrategy
UniqueIDGenerator
class common across products
ConfigManager_IXM class specific to IXM
- improve the maintainability of the reference product
- enhance the reusability to support variability
18/25
2011-10-06 http://www.se.fudan.edu.cn
19. Iterative Propagation to Other Products
domain model continually refined and updated
component adapted and integrated in variant products
19/25
2011-10-06 http://www.se.fudan.edu.cn
20. Evaluation (Component: EntityManagement)
- Metrics about variants support
Before After
reengineering reengineering
Lines of code 91,106 31,932
Average McCabe 5.85 2.62
Complexity
Average 15.82 7.03
statements/operation
Lines of code to support 196 140
concreteTypeA
Code fragments to support 139 2
concreteTypeA
20/25
2011-10-06 http://www.se.fudan.edu.cn
22. Evaluation (Component: EntityManagement)
Return of Investment (ROI)
Return Investment
I-1. Domain model analysis
Saved new feature I-2. Responsibility model definition
development cost in all I-3. Boundary reengineering (all related
products products)
I-4. Component level automation test
8.8 PY I-5. Internal implementation refactoring
I-6. Total integration and faults fixing cost
4.2 PY
By person year (PY)
ROI=(R-I)/R (8.8-4.2)/4.2=110% 22/25
2011-10-06 http://www.se.fudan.edu.cn
24. Conclusion
• Incremental and iterative approach with
stakeholder-value considerations can help to
– achieve steady and successful SPL reengineering
– in a risk-reduced and cost-effective manner
• Agile principles fit well for SPL reengineering
• SPL adoption can be regarded as an emergent
result of reconstruction and improvement of
existing product assets
24/25
2011-10-06 http://www.se.fudan.edu.cn