Using Product Line Analysis to Get Started With Software Product Lines

NEWS AT SEI

Author

Patrick Donohoe

This library item is related to the following area(s) of work:

Software Product Lines

This article was originally published in News at SEI on: March 1, 2005

Suppose your organization has decided to pursue a software product line approach. There seems to be a sound initial business case for doing so, the set of likely products in the product line has been identified, there is a market for such a product line, and your organization believes it has the domain expertise and technical savvy to make it all work. Now what? How do you combine these disparate sources of information into a coherent set of preliminary requirements that will shape the product line architecture and production strategy?

Product line analysis (PLA) is an initial and relatively brief pass at requirements engineering for a product line of software-intensive systems. Its goal is to identify opportunities for large-grained reuse across the product line. PLA is the link between the recognition of a business opportunity and the design of a product line architecture. It incorporates the views of multiple product line stakeholders in a preliminary requirements model that includes the functional features of products and the software quality attributes (e.g., performance, modifiability) of both the products and their development. The stakeholders providing the necessary input include marketers, managers, customer representatives, and architects. The requirements model created by PLA identifies common requirements across the product line and their allowed variants.

The primary benefit of PLA is its early identification of the major issues affecting a product line and its development (e.g., how much of the functionality and quality attributes could be implemented in core assets and how much will need to be done by product developers, and the technical and business consequences of the proposed reuse strategy). PLA is based on a systematic modeling process that incorporates the organization’s business goals and constraints, clarifies and refines assumptions about the product line scope, and provides early information about the technical feasibility of the product line. PLA also provides input to the decisions and tradeoffs concerning allocation of resources to core asset and product development. PLA helps managers identify risks in their approach to adopting software product lines. It also helps asset developers (including architects) who need usable AND useful representations of requirements, not a set of “shelfware” binders.

What the SEI now calls “product line analysis” grew out of its early domain-analysis and requirements-modeling work with industrial customers building software product lines. Because product lines span multiple domains and have multiple stakeholders, domain-analysis techniques alone did not provide a complete solution. As a consequence, the SEI approach uses techniques from domain analysis, but also borrows from work in object technology, use-case modeling, and architecture definition and evaluation.

A joint SEI-customer team used an early version of PLA to define the requirements for a product line of automotive software. The requirements model captured common requirements and variation points and allowed early exploration of the product line architecture to proceed in parallel with detailed requirements engineering.

What PLA Can Do for Your Organization

Because PLA is focused on large-grained reuse across a product line, it does not address all the requirements. It is an iterative, incremental process of eliciting, analyzing, specifying, and verifying the early requirements for a product line based on an initial business case and market analysis. The output of the process is a requirements model comprising four interrelated work products. The work products are based on object modeling, use-case modeling, and feature-modeling techniques:

  • The use-case model specifies the product line stakeholders and their key interactions with the product line. These stakeholders will verify the acceptability of the product line (and of the requirements).
  • The feature model specifies the stakeholders’ views of the product line. It captures the functional features of products and the software quality attributes of the product line and its products.
  • The object model specifies the product line responsibilities that support those features and the commonality and variability of the responsibilities.
  • The dictionary defines the terminology used in the work products and supports a consistent view of the product line requirements.

Together these work products form the basis of a systematic method for capturing and refining requirements for current products, future envisioned products, stakeholder needs and expectations, and associated rationales and tradeoffs. The work products are first populated with an initial set of use cases, features, responsibilities, and terminology, and then refined iteratively and incrementally. Use cases and features determine the elicitation of the product line requirements. Features and objects are analyzed for commonalities and variabilities, consistency, quality, interactions, and priority. The product line stakeholders verify the accuracy and completeness of the resultant requirements model. The modeling stops when opportunities for large-grained reuse can no longer be identified.

A software product line succeeds because the commonalities shared by the products can be exploited to achieve economies of production. PLA mitigates the risk of product line adoption by combining information from multiple product line stakeholders in a form that permits reasoning about the allocation of functional features and quality attributes to assets and products. The premise of PLA is that a sound initial understanding of the problem to be solved is essential before an organization embarks on a software product line as a solution. The model of a product line that emerges from PLA also provides early identification of the architecturally-significant requirements. The modeling process incorporates the organization’s business goals and constraints, clarifies and refines assumptions about the product line scope, and provides an early indication of the technical feasibility of the product line.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to del.ico.us  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us

info@sei.cmu.edu

412-268-5800

Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.