Click here to view the complete list of archived articles

This article was originally published in the Fall 2006 issue of Methods & Tools

---

Making an Incremental Transition to Software Product Line Practice - Part 2

Charles W. Krueger, http://www.biglever.com/
William A. Hetrick and Joseph G. Moore; http://www.engenio.com/

The Decision to Transition to a Software Product Line Approach

The negative impact of the rapidly increasing file branches became evident from two complimentary viewpoints, one from the architects andone from the managers. First, an architect began to observe code qualitydegeneration due to excessive file branching. As new features were implemented,there was a statistical likelihood that 30% of the impacted files would havebranches (recall that 30% of the files in the code base were branched). Thefeature implementation on a branched file had to be duplicated on each branch ofthat file, which was labor intensive and highly error prone since each branch of a file might be slightly different in subtle ways.

Second, from the managers’ viewpoint, defect resolutions were also becoming increasingly expensive, since defects resulted in a largepercentage of development capacity spent on analysis, correction, and validationon multiple file branches. The change management tool in use modeled thisduplication of defect resolution tasks as clone requests. The developmentmanagement team then used this data to track clone metrics – the ratioof clone requests versus the total number of change requests. The managementteam considers clone work a waste item in the development capacity because theduplication of effort prevents a developer from working on new revenue-generating features.

Clone metrics were increasing over time, mirroring the code quality issue observed by the architect. The root cause was attributed to thefile branching, which was a result of the growing number products underconcurrent development, which in turn was a direct result of LSI Logic’s success in their OEM business.

To the architects and managers faced with this growing problem, software product lines intuitively resonated as a viablesolution, though no one on the team had direct experience with this emergingfield of practice. Before launching into a full-scale change initiative, theydecided to expand their understanding of basic product family developmentprinciples with consulting and an assessment by an outside organization specializing in software product line development tools and practices.

During the assessment, a pilot project plan emerged based on a vision of the development and production environment after a full-scale transition. The development and production environment would be based a unified set of core assets, residing on the single common trunk in configuration management – no more branches. A software product line development tool [3] would be used to manage variation at the source configuration binding time. Product instantiation, or production, would be fully automated, driven from decisions in the feature model and extracted from the core assets. All of the common and varying source code would exist as core assets with variation points, so no manual application engineering would be required.

Over the next few months, the pilot project plan was refined. Two products were selected to become the initial baseline for core assets in the product line. The pilot was designed to be an initial transition step in a deployment, if proven successful.

The pilot project was budgeted as a six-week effort, beginning on May 17, 2004. After consolidating the two product code sets with feature model and variation points, the methods and results of the prototype production line were shared with all of the development managers, architects, and their superiors on June 8, 2004 – three weeks ahead of schedule. With considerable discussion and analysis, projecting business requirements and scenarios in the development organization, the group concurred that the product line environment would eliminate the branching and clone problem, enabling the development staff better satisfy LSI Logic’s business and engineering requirements. Development management agreed to the final deployment plan on June 17, 2004, one month after the beginning of the pilot. After hardening the pilot prototype and documenting the new configuration management and production procedures, the new software product line development environment was put into daily production use by the development staff on July 30, 2004. The entire effort to get to this point was 4 developer-months.

LSI Logic’s Transition

LSI Logic structured its transition to software product line practice into four sequential and incremental stages. Each of these four stages had nested incremental substructure. The objective was to make small incremental investments in product line practice – small enough not to disrupt ongoing production schedules – in an effort to immediately reap larger incremental returns on those incremental investments.

The four stages were ordered sequentially to address, in order, the most prominent inefficiencies and bottlenecks first.

• Transition the infrastructure and core assets
• Transition the team organization
• Transition the development processes
• Transition the validation and quality assurance

Transition of the Infrastructure and Source Code Assets

The most critical issue identified to address first was the growing problem of file branching degrading quality and productivity. To accomplish this, the development infrastructure was enhanced to support a single consolidated collection of core assets rather than highly branched files in configuration management. The subtasks within this stage were to:

• validate the approach with a pilot project
• create the software product line development and production infrastructure
• incrementally extract a core asset base from existing source code branches
• incrementally transition development teams away from branch and clone methods to core asset development using the new infrastructure
• incrementally refactor the core assets to maximize commonality and to optimize abstraction in variation points

When the transition started, eight product releases were concurrently in various stages of active development. The pilot project consolidated the branched source code for two of these products, resulting in the initial core asset base. To minimized the potential disruption of the critical product releases under development, the pilot and initial deployment strategically targeted two products that were early in their release cycle.

The initial code base for the two products was comprised of 3300 files, 1000 of which had anywhere from 2 to 16 branches, organized into 212directories. The core asset base after consolidation was comprised of 3103common files, 51 variation point files, 211 common directories, 1 variation point directory, and 0 branches.

The transition plan dictated that the remaining product releases currently in flight would be completed using existingbranch/merge/clone methods. All subsequent product and feature releases were todeploy from the core assets of the product line. As illustrated below in Figure1, over the subsequent 9 months, developers rolled off of projects developedunder the legacy methods, while the core assets and production line evolved to deploy 23 products.

 

Figure 1. Incremental Transition of People and Products

Early in this stage of the transition, the variation points were unceremoniously extracted from the existing branched code base with noattempt to re-architect or re-engineer the core assets other than toencapsulate, characterize, and program variation points based on a simplefeature model. This allowed, for example, all 51 variation points to beextracted from the 3300 files, 1000 of which were branched, in less than 3 daysduring the pilot. However, over time, the variation points were incrementallyrevisited in order find opportunities for greater commonality and to find better product line abstractions.

The incremental investment during the first stage of the transition was to establish a new software product line development andproduction infrastructure, create a baseline of core assets from the existingbranched source base, and train developers on the new product line developmentenvironment and methodology. The initial investment to conduct the pilot projectand then to go into live product line development and production with those 2products was 4 developer-months. Subsequent transition of the remaining 21products and product teams required less than one half developer-month per product.

The incremental return on investment originated from improved efficiencies at the tactical developer level. Developers spent lesstime manipulating the configuration management tool, navigating and makingcloned modifications on intricate file-by-file branch structures. As a result they could spend more time developing new features.

The dramatic reduction in branch complexity is illustrated in Figure 2 using a file branch factor metric, defined as the number of filebranches normalized by the number of products. Note from the graph that branches have been eliminated in the product line core asset base.

Figure 2. File Branch Factor During the Transition

Page 1    Page 3    Back to the archive list