Use product line engineering to reduce the total costs required to create, deploy & maintain systems & software -

Use product line engineering to reduce the total costs required to create, deploy & maintain systems & software

At Lockheed Martin Maritime Systems &Sensors (LM MS2) – in pursuit of a core business objectiveof timely and cost-effective delivery of the latest in technologicaladvances to our customers – we are finalizing a multi-year initiativeto identify, evaluate and implement a leading-edge Common Product Linereuse strategy to streamline systems and software engineering in eachof its core product lines.

The driving goal is to satisfy strong customer demand to reduce thetime, cost and effort required to create, deploy and maintain products.To achieve this goal, the ultimate solution must minimize duplicateeffort, maximize commonality among design and implementation assets,and optimize reuse of effort across similar products within each of itsproduct lines.

An emerging discipline in the software industry has offered greatpromise for high degrees of strategic reuse within a software productline portfolio of similar products. This approach is referred to as Software Product Line (SPL)engineering.

Until recently, the state-of-the art for traditional developmenttools, conventional software reuse, and early generation SPLengineering approaches did not enable the advanced capabilities desiredby LM MS2, where the objective is to enable strategic reuse ofengineering assets across the entire systems and embedded softwaredevelopment lifecycle ” spanning requirements, architecture, design,source code, documentation and test artifacts.

However, this situation has dramatically improved within recentmonths through a combination of three key advances in the SPL field.

1. A fundamental shift inperspective offers a simpler solution to a traditionally difficultproblem. Analogous to engineering a product line of hard goods, it issimpler to take a broader perspective that views product lineengineering as creating a single system ” including the manufacturingproduction line ” rather than viewing product line engineering ascreating a multitude of products.

2. A SPL engineeringlifecycle framework offers a consistent and integrated SPL solution forall system and software tools and for the reuse of all systems andsoftware assets, across the entire product development and maintenancelifecycle. This is simpler and much more effective than traditionaldevelopment approaches and early generation SPL methods that resultedin disparate and “silo'ed” solutions for each stage of the productdevelopment lifecycle.

3. A methodology forincremental SPL adoption offers non-disruptive techniques forseamlessly transitioning from current practices into a more efficientand effective SPL practice. This minimally invasive strategy overcomesbarriers associated with the early generation “big bang” SPL approachesthat required large-scale, upfront re-engineering.

Collectively, these advances have opened up new frontiers forinnovation in product line engineering and delivery, suitable formainstream use throughout the systems and embedded software engineeringindustry.

This broader lifecycle-wide approach for applying systematic andstrategic reuse methods has uniformly extended the concepts pioneeredin SPLs, spanning from the earliest stages of systems engineering allthe way through the final stages of test engineering and productdelivery. By leveraging this advanced yet pragmatic engineeringapproach, LM MS2 is moving forward with its Common Product Line vision.

Software Product Line Engineering
In the world of hard goods, a product line refers to the variations ona common theme, where multiple products are combined into one “line”,offering different sizes, colors and features, with a common goal offilling customer need for a particular kind of item.

“Economy of scale” is a key aspect of the product line concept, withgreater profitability achieved when common product or manufacturingassets can be used for different “flavors” of a product.

As product differentiation moves from the physical attributes(color, size) to software-based functional capabilities (caloriecalculators on treadmills, cars that maintain personalized temperaturesettings, mobile phones that also provide up to the minute sportsscores) the product line concept is making its way into softwaredevelopment.

Software Product Line (SPL) engineering is a growing trend that ishelping organizations achieve product diversity at the speed andefficiency it takes to satisfy today's cost-conscious “want it new,want it now” consumers and businesses.

The focus of SPL engineering is on the means of efficientlyproducing and maintaining multiple similar software products,exploiting what they have in common and precisely managing what variesamong them.

This is analogous to the automotive industry, where the focus is oncreating a single production line, out of which many “customized”(e.g., body color, interior package, sound system, navigation option,transmission type) but similar variations of a car model are produced.

The powerful, though subtle, essence of this description is thefocus on a singular means of production rather than a focus onproducing the many individual products. Once this “production line”focus is established, creating the individual products is more a matterof automated instantiation rather than manual creation.

Figure1: Software Product Line Engineering

SPL engineering can be described in terms of four simple concepts,as illustrated in Figure 1,above:

1) Reusable SPLAssets: Being developed on the left side of the diagram is thecollection of reusable SPL assets ” such as requirements,architectures, models and designs, source code components, test cases,documentation, and so forth ” that can be configured and composed indifferent ways to create all of the products in a product line.

Each of the assets has a well defined role within a commonarchitecture for the product line. To accommodate variation among theproducts, some of the assets may be optional and some of the assets mayhave internal variation points that can be configured in different waysto represent different system behavior.

2) FeatureProfiles: Being fed into the top of the product configurator arethe feature profiles. They describe optional and variable features forthe products in the product line. Each product in the product line isuniquely defined by its own feature profile ” choices for each of theoptional and variable features.

3) ProductConfigurator: At the center of the diagram, the productconfigurator is the means for automatically composing and configuringproducts from the reusable software assets. Feature profiles are usedduring production to determine which reusable software asset to use andhow to configure the variation points within those assets.

4) Product LinePortfolio: Being automatically generated out of the right of theproduct configurator are the products in the product line portfolio “the collection of all products that can be produced for the productline. The scope of the product line is determined by the set ofproducts in the portfolio that can be automatically produced from thereusable software assets and the feature profiles.

Real world success stories of the SPL approach come from diverseareas such as mobile phones, e-commerce software, RAID storage systems,computer printers, diesel engines, telecom networks, enterprisesoftware, construction and mining equipment, cars, ships, andairplanes. Each of these examples relies on creating and maintaining acollection of similar software-centric systems, as part of delivering aproduct line of similar yet varying products.

For example, a mobile phone company may have tens or hundreds ofdifferent phone models, each using software that is unique, yetsubstantially similar to software in the other models. New models maybe introduced every few weeks.

By using pragmatic SPL engineering techniques to exploit thesoftware commonality and effectively manage the desired variations foreach model, companies are reporting order of magnitude reductions intime-to-market, engineering overhead, defect rates, and developmentcost.

Shift in Perspective
The best characterization of the SPL approach might be simply statedas: “the right point of view saves twenty points of IQ.” An innovativeshift in perspective invokes the SPL epiphany ” a realization that theproblems and solutions associated with creating and maintainingsoftware for a product line can be much simpler than the “obvious”approaches taken from a conventional perspective.

The before-and-after scenarios shown in Figures 2 and 3 illustratethe differences between the conventional product-centric perspectiveversus the SPL perspective. In Figure2 below , the vertical blue bars highlight a primaryproduct-centric focus on the development lifecycle for each of theindividual products (A, B, through N) in a product line.

The red lines illustrate the complex and labor-intensiveinteractions, dependencies and coordination activities required tomanage the product line as a whole. Note that the number of redinterdependency lines for N products is N × (N – 1), or N2 – N,illustrating that complexity and effort increase rapidly by order-of-N2 with the growth of the product line.

Figure2. Conventional Product-centric Perspective

Figure 3 below shows the SPLengineering perspective for delivering the same product line ” productsA through N on the right side of the diagram. Tilting your head 90degrees shifts the perspective from the conventional vertical focus onindividual products to a horizontal focus on the software assets(requirements, designs, source code, test cases, and so forth) used tocreate the products, as highlighted by the horizontal blue bars .

The key to the SPL engineering perspective is the automatedcomposition and configuration of products A through N on the right,utilizing the reusable SPL assets and feature profiles on the left..

The SPL epiphany ” that this approach is dramatically more efficientand effective ” comes by observing the shift in manual developmenteffort for the individual products (onthe right ) to a singleproduction system (inside the red box on the left ).This shift in focus from the multitude of products to the singleproduction system of reusable SPL assets, feature profiles and productconfigurator, eliminates the complex and labor-intensive N2 – N interactions, dependencies and coordination activities (thered lines in Figure 2 ).

For Lockheed,, this shift in perspective revealed an easier way forus to expand, evolve and maintain its product lines.

Figure3. Software Product Line Engineering Perspective

SPL Engineering Lifecycle Framework
Early generation SPL engineering techniques were often point solutions,focused on a single stage in the software development lifecycle, suchas managing requirements or developing source code for a product line.As LM MS2 searched for an enhanced systems and software product lineengineering approach, it was clear that the company's Common ProductLine objectives could not be solved at any one stage in the lifecycle.

Nor would they be solved optimally as long as independent anddisparate solutions were applied in each of the different lifecyclestages. A more holistic approach was needed; one that was deeplyintegrated into and across the entire system and software engineeringlifecycle.

A recent advance in the SPL field addressed this problem ” the SPLEngineering Lifecycle Framework. The role of this technologyframework is to ease the integration of tools, assets and processesacross the full systems and software development lifecycle. Theframework provides product line engineers with a common set of SPLconcepts and constructs for all of their tools and assets, at everystage of the lifecycle, and to assure that product line developmenttraceability and processes flow cleanly from one stage of the lifecycleto another.

To illustrate the need for this SPL framework, imagine the followingscenario within a product line development organization. Therequirements engineering team has embraced an SPL technique based ontagging requirements in a requirements database with attributes thatdifferentiate feature variations in requirements.

The design team has adopted a UML tool and has embracedinheritance as the mechanism for managing SPL design variations. Thedevelopment team is using feature diagrams drawn in a graphical editor,plus #ifdefs, build flags and source code configuration managementbranches to manage SPL implementation variations. The test team hasadopted a clone-and-own approach for managing variations in their SPLtest plan sections, with files stored in appropriately nameddirectories.

What would be needed to create a complete SPL lifecycle solutionthat integrates into a larger business process model? How do therequirements database attributes and tagged requirements relate andtrace to the subtypes and supertypes in the design models? How do theseattributes and supertypes relate and trace to the #ifdef flags, CM branches, featurediagrams, and test case clone directories?

Translating between the different representations andcharacterizations of features and variations creates dissonance at theboundaries between stages in the lifecycle.

LM MS2, as well as other product line development organizations andsoftware tool vendors, have adopted the framework to create a uniformSPL engineering lifecycle solution across a heterogeneous collection oftools and assets. Existing assets and tools, both commercial andhomegrown, can be plugged into the framework, enabling companies tocapitalize on:

1) A single feature model touniformly express product diversity for all assets in all stages of thesystem and software development lifecycle, including requirements,architecture, models, design, source code, test cases anddocumentation.

2) A single variation pointmechanism that can be uniformly applied to all tools and theirassociated assets in each stage of the systems and software developmentlifecycle, including tools for requirements management, model-drivendevelopment, source code development, test case development,configuration management, build automation, change management anddocument development.

3) A single, automatedproduct configurator that uniformly assembles and configures assetsfrom each stage of the development lifecycle to automatically produceall the products in a product line.

The SPL engineering lifecycle framework provides LM MS2 with anend-to-end solution that utilizes a common set of SPL concepts andconstructs across the lifecycle. LM MS2 refers to this as theirIntegrated Product Line Engineering (IPLE) environment. The unifiedapproach enables inter-stage traceability and processes to flow cleanlyfrom one lifecycle stage to the next.

Incremental SPL Adoption
Change within an organization is hard. Or as Dilbert succinctly put it,”Change is good. You go first.” Even when it is painfully obvious thatchange is needed, it is often easier to continue doing things today thesame way they were done yesterday.

As LM MS2 explored ways of transitioning from a product-centricapproach to an SPL approach, it was clear they needed an approach thatwould allow non-disruptive, incremental steps to be taken rather than alarge “big bang” start-over event.

Early generation SPL methodologies tended to be large and complex,offering many options and choices. The myriad of interrelatedtechnical, process and organizational issues for these methodologiesmade it difficult to “connect the dots” between the practice changesbeing prescribed. Development organizations found it difficult totranslate these complex, often conceptual, methods into the practicalreality of their daily engineering activities.

Another recent advance to the SPL field directly addresses thisissue with a pragmatic 3-Tiered SPL Methodology, shown in Figure 4 below . This methodologyenables and encourages incremental transitions to SPL practice.

As companies shift from conventional product-centric softwaredevelopment to SPL development, three tiers of capabilities andbenefits are established, sometimes in sequence and sometimes inparallel. Each tier builds upon and is enabled by the capabilities andbenefits of the previous tier.

That is, the capabilities at each tier provide direct benefits, butalso enable increasingly more strategic capabilities and benefits inthe higher tiers. The base tier provides a very tactical set ofdeveloper capabilities and benefits, which enables a middle tier ofengineering management capabilities and benefits, which ultimatelyenables the top tier of highly strategic capabilities and benefits inthe business operations.

Figure4. Three -Tiered SPL Methodology

The 3-tiered SPL methodology encourages a transition to SPL practicebased on the strategy of incremental return on incremental investment “in essence, a “start with what you've got” approach. A product linedevelopment organization makes a series of incremental investments,each of which yields immediate and larger returns.

With a small upfront investment to transition one team, or twoproducts, or several subsystems, the cumulative returns quickly beginto outpace the cumulative investments in terms of time, effort andmoney. The “profits” in time, effort and money from the firstincremental investment can be used to fuel the remaining steps in thetransition.

Using the incremental return on incremental investment strategy andinitially focusing on the base tier of the 3-tiered SPL methodology, LMMS2 has been able to successfully introduce SPL engineering practice ina selective, non-disruptive, incremental manner.

For Lockheed Martin's Maritime Systems and Sensors division, recentadvances in systems and software product line engineering have openedup new opportunities for innovation in our product line engineering anddelivery. The fundamental SPL shift in perspective allows product lineengineering to be viewed as creating a single system rather than amultitude of products.

The SPL engineering lifecycle framework offers a consistent andintegrated product line engineering solution for all tools and assetsacross the full systems and software development lifecycle. Theincremental SPL adoption strategy, as part of the 3-tiered SPLmethodology, offers non-disruptive and seamless transitions fromcurrent practices into a more efficient and effective SPL practice.

These pragmatic SPL engineering advances have enabled LockheedMartin Maritime Systems & Sensors to move forward on our CommonProduct Line vision and are similarly being applied in diversebusinesses and markets throughout the mainstream systems and embeddedsoftware engineering industry.

James Cezo is a Principle Engineer at Lockheed Martin MS-2 divisionin Moorestown New Jersey, responsible for pioneering the SoftwareProduct Line solution at Lockheed Martin. He has been instrumental inextending the SPL approach to include both System and Software ProductLine engineering in order to dramatically improve the way that hisorganization designs, develops, delivers and maintains its current andfuture products. He holds a BS degree in Computer Science from RichardStockton College and an MBA degree from Monmouth University.

Charles Krueger, PhD, is the founder and CEO of BigLeverSoftware, a leading provider of software product lineengineering development framework, tools and services and has beenintimately involved in establishing standardized SPL practices. He hasco-chaired the International Conference on Software Reuse and moderatesthe website.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.