Software Product Lines

For the past several years I have been interested in applying software product line development techniques to the domain in which I work (unmanned air vehicles).  Specifically, I’m interested in applying these techniques to the development of Ground Control Station software.

The concept of a software product line is well established in the software industry and a significant amount of academic and case study literature is available for review.  The basic idea is to develop a core software product where specific variation points are designed in from the beginning.  This core software product can then be applied to different, but related, business problems by tailoring the software around these pre-determined variation points.  The tailoring process can range from minor modifications of declarative configuration files to the insertion of completely new software services.

Here are some of the software product line advantages I came up with.  Most are fairly straightforward and generally fall into business and technical categories.

Business Advantages:

1. Staffing – The current business climate has made it difficult to hire sufficient numbers of qualified software engineers to staff large software development efforts.  If most of our UAV Ground Control Stations were using a common software product line, there would be a reduction in the overall number of software engineers required across participating programs.  Alleviating this staffing constraint would eliminate obstacles that prevent programs from meeting schedule objectives.
2. Lower Software Costs – With less software development required by each program, the program costs related to software should be lower.  This savings could either manifest itself as lower overall program costs or with more costs available to be allocated to developing air vehicle capabilities. In general, air vehicle capabilities sell a program, Ground Control Stations do not.  Either approach translates into a competitive advantage to the company.
3. Reduced Risk – Software development is notoriously risky with respect to cost and schedule.  There are enumerable case studies in the software engineering literature detailing massive cost or schedule overruns on large software projects.  With less new software to develop on each new program, our programs will be less susceptible to these risks.
4. New Business Opportunities – Customer communities are increasingly expressing an interest in developing a common UAV Ground Control Station that will support air vehicles from multiple vendors.  Our customers are under pressure to reduce the manpower footprint required to operate their heterogeneous UAV fleets and are beginning to ask why they need a separate Ground Control Station for each UAV platform, each requiring trained staff to operate.  Some communities have already funded small efforts to develop common UAV task management standards and plan to evolve their scope to focus on the larger issue of a common Ground Control Station.  Developing a common Ground Control Station product line for internal use would give my company a competitive advantage when our customers begin to look to UAV suppliers to realize their objectives.

Technical Advantages:

1. Cross-Fertilization – The concept of a product line entails a feedback loop from the domain-specific development performed by each program using the product line.  The technical advances developed under each program are fed back to the product line team and become part of the core software product line and subsequently are available for use by the next program.
2. Institutional Knowledge – When each new program goes through the staff-up process of hiring engineers from external sources, those engineers are usually unfamiliar with the UAV domain.  Creating continuity through a product line team, which is sustained by multiple, ongoing programs, will provide our company with the opportunity to develop and maintain a talent base with institutional knowledge of UAV Ground Control Station software engineering.
3. Consistent Quality – Similar to the discussion above regarding cost and schedule risks, large software systems often suffer from quality problems.  There are many technical challenges with large-scale software development that inexperienced teams fail to anticipate.  The resulting software system often fails to meet requirements or is not extensible or maintainable.  With a core software product line, an engineering team can address these challenges once and apply those solutions repeatedly on each participating program.
4. Consistent Design Philosophy – Each new software project incurs overhead to derive an overall design philosophy before a single line of production code is ever written.  For large-scale projects, this is where software architects determine how the various software components will be developed, how they will be integrated and through what mechanism the system will be extended in the future.  Inattention to this phase of system design will result in the quality issues described above.  With a software product line, this design philosophy is handed to each participating program.  The approach for introducing new software capabilities will be carefully thought out as part of the design of product line variation points.  Each new program’s domain engineers will be trained by the product line team in how to extend the system for their unique requirements.

Not all UAV systems are the same – some are what we call remotely piloted vehicles (RPVs) and some are more autonomous.  I work on the autonomous end of the spectrum and under some circumstances the Ground Control Stations end up being large, enterprise computing systems with many complex, distributed and often heterogeneous components.

This brings me to a set of open questions I have as to the applicability of software product line techniques to my particular set of domain problems and to the most appropriate implementation approaches.

1. How should a product line team be organized?  There is a wealth of available literature on product line management philosophies and requisite engineering team structures that should be studied and tailored to my company’s business model and the UAV domain.
2. How would the product line team serve the needs of multiple programs concurrently?
   1. What organizational structure is needed to manage the competing interests of multiple programs?
   2. How should the engineering teams be structured to perform requirements analysis, design and development for multiple programs?
   3. What engineering tool suites would be most appropriate for concerns such as configuration management within this type of an environment?
3. What are the software architecture challenges?
   1. How do my company’s various UAV systems differ and how would that translate into variation points within the product line software architecture?
   2. What is the capability scope of the product line?  This depends on how much the supported UAV systems have in common.
   3. What is the software architecture design philosophy and what enabling technologies should be selected to support that philosophy?

I’ve set out to answer some of these questions and if some of those answers turn out favorably, I intend to formalize an approach for pursuing a software product line.

I have recently started reading Software Product Lines in Action and have so far found it to be a useful reference in answering some of the questions I’ve posed above.  The Software Engineering Institute also has a wealth of information available on this subject.

If you have experiences you’d like to share regarding the development or management of a software product line – even in a different domain – please contact me or leave a comment on this post.