BIGLEVER NEWSLETTER: Special Series
The Software Product Line Lifecycle Framework: Series Introduction
Greetings from BigLever:
Mainstream forces are driving Software Product Line (SPL) approaches to take a more holistic perspective that is deeply integrated into the system and software engineering lifecycle. These forces illustrate that SPL challenges will not be solved at any one stage in the product engineering lifecycle, nor will they be solved in independent and disparate silos in each of the different stages of the lifecycle.
This newsletter is the first installment in a special series describing BigLever Softwares response to these forces the SPL Lifecycle Framework. The motivation for this technology framework is to ease the integration of tools, assets and processes across the full system and software development lifecycle. The goal is to provide product line engineers with a standard set of SPL concepts and constructs for all of their tools and assets, at every stage of the lifecycle, and to assure that product line development traceability and processes flow cleanly from one stage of the lifecycle to another.
Background on the Problem
A fundamental tenet of software product line engineering is that product line variation must be simultaneously managed along the two dimensions of time and space:
- Variation in time, to manage asset evolution
- Variation in space, to manage diversity among assets and products in the product line
Practical experience with BigLever's customers has illuminated an equally important third dimension that must be addressed in order to satisfactorily provide a complete SPL solution:
- Variation in the lifecycle, to provide consistency and to manage traceability among asset variations in different lifecycle stages
Early generation SPL engineering techniques were often based on point solutions, focusing on a single stage in the software development lifecycle such as managing requirements or developing source code for a product line without consideration of how they might be applied in combination with other concepts, techniques and tools in other lifecycle stages. For mainstream organizations looking for a complete SPL solution, this situation poses a prohibitive adoption barrier.
For example, imagine a requirements engineering team has embraced an SPL requirements management technique based on tagging requirements in a requirements database with attributes that differentiate feature variations in requirements. The design team has adopted a UML tool and has embraced inheritance as the mechanism for managing SPL design variations. The development team is using a FODA feature model drawn in a graphical editor, plus #ifdefs, build flags and configuration management (CM) branches to manage SPL implementation variations. The test team had adopted clone-and-own of test plan modules, stored in appropriately named file system directories to manage their product line test plan variations.
Now imagine what would be needed to create a complete SPL lifecycle solution that integrates into a larger business process model. How do the product line evolution requests from the product marketing and product management teams relate to the requirements database attributes? How do the requirements database attributes and tagged requirements relate and trace to the subtypes and supertypes in the design models? How do these attributes and supertypes relate and trace to the #ifdef flags, CM branches, FODA features, and test case clone directories?
Without answers to these questions, it is not possible to define a product line engineering lifecycle process that flows cleanly from one stage of the lifecycle to another. Trying to translate between the different representations and characterizations of features and variations creates dissonance at the boundaries between stages in the lifecycle.
The SPL Lifecycle Framework
The SPL Lifecycle Framework provides an industry standard integration framework for tools, assets and processes across the full system and software development lifecycle for business and system analysts, requirements engineers, architects, modelers, developers, build engineers, document writers, configuration managers, test engineers, project managers, and so forth (click image to enlarge). The framework provides a standard set of SPL concepts and constructs for all tools and assets across the lifecycle, which allows development processes to flow cleanly from one stage to another:
- A single feature model that can uniformly express the full product line feature diversity
- A single variation point mechanism that can be uniformly applied to all tools and their associated assets
- A single, automated product configurator that uniformly and automatically assembles, configures and produces all of the software assets and products in a product line
Stay tuned for the next installments in this newsletter series to learn more about the concepts and mechanisms behind the SPL Lifecycle Framework and how it has enabled mainstream organizations with some of the largest, most sophisticated and complex, safety-critical systems ever built to adopt the SPL approach.
Charles W. Krueger
BigLever Software CEO
Don' t miss your Newsletter!
Please help us make sure that you continue to receive the BigLever Newsletter by confirming your subscription with us. This ensures that future newsletters will be successfully delivered to your Inbox and not misplaced into your junk mail or spam folder.
To confirm, simply click the "confirm" link in the white bar below. After confirming, you can unsubscribe from our newsletter distribution at any time.