A Framework for Software Product Line Practice, Version 5.0
Understanding Relevant Domains
One of the constants we've observed in successful software product line organizations is that they have at their disposal extensive experience in the domains that are relevant to their software endeavors. This practice area is about achieving that understanding. Domains are areas of expertise that can be applied to the creation of a system or set of systems. Domain knowledge is characterized by a set of concepts and terminology understood by practitioners in that area of expertise. It also includes an understanding of recurring problems and known solutions within the domain. Knowledge from several domains is usually required to build a single product. For example, to build a distributed banking application, you would need knowledge of banking practices, commercial bank information systems, workflow management, database management systems, networking, and user interfaces, just to name a few. You would never attempt to build a distributed banking application (or any other nontrivial system) without first making sure you knew enough about the relevant business and technical areas to impart the expectation for success. "Knowing enough" to make good product decisions comes from understanding the relevant domains.
The practice of understanding the relevant domains involves
- identifying the areas of expertisedomainsthat are useful for building the product or products under consideration
- identifying the recurring problems and known solutions within these domains
- capturing and representing this information in ways that allow it to be communicated to the stakeholders and used and reused across the entire effort
How does an organization achieve this understanding? Typically, it builds up its store of expertise with its prior experiences in delivering products. An organization can also hire outside experts who provide or augment the organic level of understanding. In addition, it can employ domain analysis methods to gather, organize, and communicate domain information in a form known as a domain model.
Understanding relevant domains is initiated by eliciting domain information from various sources. This elicitation includes the investigation of current products and interviews with domain experts and product marketers, developers, and users to identify the current and potential future capabilities for the product(s) being considered. The elicitation also captures the needs and expectations of the various stakeholders and helps in the assessment of the technical maturity and stability of the relevant domains. The extent of the elicitation activity depends on the availability of sources and the amount of domain knowledge already known in-house.
Domain understanding should include whatever key domain information can be used as the vehicle for analysis and reasoning. Domain information should capture different views of the product(s) from the perspectives of relevant stakeholders. In the absence of this information, your organization is vulnerable if experts leave. Further, documentation will refine and sharpen the understanding of the experts themselves; writing a thing down requires a deeper understanding of it than carrying it around in your head. And finally, recorded domain information can be reviewed and improved by stakeholders who can speak to their future needs.
The extent to which a formal domain analysis is performed to achieve domain understanding depends on these two factors:
the depth of the organization's domain experience: Organizations that have deep domain expertise frequently opt not to invest in a full-blown "formal" domain analysis to model their understanding of the relevant domains. (For example, they may use a hybrid approach that combines requirements gathering with use case modeling and commonality and variability analysis.) Foregoing formal domain analysis allows them to move into design more quickly or to perform some initial design activities (e.g., the investigation of architectural patterns) in parallel with the analysis.
the amount of resources that can be devoted to analysis: The time, money, and people allocated to the analysis will determine the duration and scope of the analysis activities. However that's not to suggest that more analysis is always better. In fact, "analysis paralysis" is a risk associated with this practice area.
Regardless of its formality or comprehensiveness, domain information should be documented to capture the expertise needed to serve as authoritative criteria for making product and design decisions. You need to have enough information to make sound business decisions without necessarily undertaking an extensive analysis of all the applicable domain knowledge. An organization has achieved a sufficient understanding of the domains relevant to a product or products when it can successfully apply that understanding towards
- reasoning about the technical and business implications of a proposed design
- making informed decisions about which features, capabilities, and technologies to offer in proposed products
- creating a set of artifacts that exploits the understanding of the relevant domains
Aspects Peculiar to Product Lines
Understanding the relevant domains is the first step to defining the commonality and variability that can be expected to occur among the products identified in the product line's scope. Domain understanding for a product line emphasizes the commonality and variations present among the products, whereas domain analysis for a single system focuses instead on the technical concepts inherent in a single system or how that system might evolve once fielded.
Domain information for a product line will help you determine
- which capabilities tend to be common across systems in the domain(s) and what variations are present. This information will inform the process of scoping, in which the commonality and variations for your product line will be established.
- which subsets of capabilities might be packaged together as assets for the product line. This information begins to inform the architecture creation effort for the product line, by suggesting potential subsystems that have occurred in other systems in the domain(s).
- what constraints (e.g., standards, legal restrictions, business constraints, specific hardware platforms) apply to systems in the domain(s)
- which assets typically constitute members of the domain(s). This suggests a list of assets that an organization could begin to search for in its own legacy inventory or on the open market.
- whether to continue with the product line development effort
The last item is particularly important; the ability to reason about a product line can help management gain confidence in the soundness of the decision to adopt a product line approach. Put another way, domain understanding informs both the product line's scope and its associated business case. Domain understanding also grounds the design decisions in experience (even if the experience is not the organization's own), which reduces technical risk and also has a soothing effect on nervous managers. Even a rudimentary and informal domain analysis can help refine both the scope of the product line and the initial estimates for resource allocation. And it can show the organization and its management that they are not exploring uncharted territory.
The level of detail and degree of formality of the documented domain information for a product line depend both on the depth and distribution of an organization's domain knowledge and on the kind of reasoning about the product line that the organization wishes to support by modeling. Some organizations have such a thorough understanding of their domains and their reuse potential that they can move very quickly from identifying a business opportunity to creating core assets. Organizations less experienced in exploiting reuse need to approach the problem more deliberately, analyzing commonality and variability to understand the technical implications for assets and products and the business implications for the product line as a whole. Additionally, they may have to hire domain experts if the requisite domain expertise is missing or immature. Whatever the degree of understanding, each organization has some model of the product line that evolves as the development effort progresses. It may be an informal shared understanding of the product line with minimal documentation, or it may be a more formal domain modelthat is, an abstract characterization of the product line, complete with its own representation schemes and automated support. If the purpose of the analysis is to obtain insights into the technical feasibility and potential scope of the product line quickly, the analysis does not need to model the commonality and variability exhaustively.
In summary, understanding relevant domains is about systematically capturing and using knowledge about systems similar to the ones that you are about to build. This knowledge provides you with an informed world view from which you can then make specific decisions about your product line, especially regarding its scope, shared and unique requirements, and architecture.
Application to Core Asset Development
An understanding of the relevant domains is applied to core asset development in order to identify and model the opportunities for large-grained reuse across a product line early in its life cycle. This knowledge informs the articulation of common product constraints, as described in Core Asset Development. It has a profound influence on the architecture for the product line, which is the definitive design statement about the commonalities and variabilities that will be supported across the product line. It also supports the business case for the product line and feeds the "Scoping" and "Requirements Engineering" practice areas.
Application to Product Development
An understanding of the relevant domains supports the assessment of customer-specific requests for new product line capabilities. This assessment, in turn, may broaden your understanding of the relevant domain knowledge. In fact, such decision-making opportunities represent one form of feedback between core asset consumers and core asset producers, and they have the potential to expand the scope of the product line by challenging previously held assumptions about commonality and variability. Any such feedback from products to core assets should be documented so that it can be evaluated and, if necessary, incorporated into any models of the relevant domains.
Similarly, an understanding of the relevant domains can also be used as the basis for analyzing the effects of a proposed change in the product line's requirements and for recommending a course of action. For example, a business decision to switch to a different operating system can be checked against the operating system capabilities assumed for the product line. At a minimum, there could be a checklist of features whose presence or absence in the new operating system will either shorten or lengthen the product development schedule. A more detailed model of assumed operating system capabilities would provide a greater ability to quantify the effects of the proposed change on the product development process.
Have domain experts available: The best way to achieve domain understanding is by having the right people in the product line organizationthose with extensive experience in the relevant domains. (This was a recurring theme at the one of the SEI product line practice workshops [Bass 1998a].)
Scope, commonality, and variability (SCV) analysis: The SCV approach, from Lucent Technologies, gives software engineers a systematic way of thinking about the product family they are creating. It identifies, formalizes, and documents commonalities and variabilities. SCV is the commonality analysis portion of the Family-Oriented Abstraction, Specification, and Translation (FAST) approach, also from Lucent Technologies. The FAST method includes the dual life cycles of domain engineering and application engineering. It uses the results of a commonality analysis to create a language for both specifying domain members and generating them from the specification [Coplien 1998a, Weiss 1999a].
Domain analysis and design process (DADP): DADP is a process model for domain analysis and design created by the Defense Information Systems Agency (DISA). It is based on an object-oriented approach to analysis and design. The domain analysis process focuses on identifying commonalities and determining common object adaptation requirements (the differences among domain common objects are not described in terms of variability, but rather in terms of tailoring the information to particular needs) [DISA 1993a].
Feature-oriented domain analysis (FODA): The FODA method defines the process and products of a domain analysis, with an emphasis on the commonality and variability of the features that users commonly expect in domain applications. The analysis process creates models of the domain that describe its relationship to other domains, its common and variant features, and the behavior of the applications in it [Kang 1990a, Cohen 1991a]. The feature-oriented reuse method (FORM) is an extension to FODA that addresses the design and implementation phases [Kang 1998a].
Synthesis process of the reuse-driven software processes (RSP) approach: Synthesis is a methodology for creating software systems as instances of a family of similar systems. It was developed by the Software Productivity Consortium in recognition of a need to produce improvements in software productivity, product quality, manageability, and customer responsiveness. A Synthesis process consists of two subprocesses: domain engineering and application engineering. The domain engineering process includes an explicit domain analysis process that captures commonality and variability for a product family [SPC 1993b].
Domain analysis process of organizational domain modeling (ODM): ODM is a highly tailorable and configurable domain engineering process model. It's organized hierarchically as a tree of processes, and while it doesn't use the term domain analysis, all the elements of a domain analysis process are present at various levels within its process tree. In particular, the model contains subtrees of processes for domain identification and scoping, domain modeling, and model refinement [STARS 1996a].
There are documented cases of organizations that have employed and adapted these methods successfully. Several books contain chapters that summarize and compare the characteristics of these and other domain analysis methods [Arango 1994a, Wartik 1992a]. There are also cases where organizations have employed domain analysis practices successfully in the creation of product lines, even though they did not use a documented domain analysis method [Bass 1998a].
The elicitation, representation, and validation of relevant domain information and the techniques employed (e.g., object-oriented technology, use case modeling, state-transition diagrams) vary across the different domain analysis methods and are not described using the same vocabulary. In a product line context, organizations perform these practices to varying degrees of completeness and rigor. In particular, organizations with deep domain knowledge and considerable expertise in applying it to developing products often opt for an abbreviated form of analysis that proceeds very quickly to design.
Product Line Software Engineering Customizable Domain Analysis (PuLSE-CDA): This method is one of the elements of the PuLSE product line engineering framework. PuLSE-CDA creates a domain model that can be customized to specific projects based on variation points called customization decisions. It also creates a decision model (based on that of Synthesis [SPC 1993b]) that provides instantiation support for specifying the products in a product line. There is a tool called Domain and Variant Engineering Supporting Technology/CDA (DIVERSITY/CDA) to support the method. PuLSE was developed by the Fraunhofer Institute for Experimental Software Engineering (IESE) [Bayer 2000a].
Domain-Specific Modeling (DSM): DSM creates a language based on high-level domain concepts and supports the automatic generation of programs specified in that language. Tolvanen identifies over 20 industrial cases in which this approach has been successfully applied to target languages such as C, C++, Java 2 Platform, Enterprise Edition (J2EE), and Extensible Markup Language (XML) [Tolvanen 2005a]. The domains of these industries include telecom services, insurance, medical device configuration, handheld devices, machine control, and business processes.
Inadequate domain understanding in the organization will jeopardize the product line effort. Without a detailed (not just basic) understanding of the precise commonalities and variabilities that need to be accounted for, the architect's hands are tied, the business case will be weak, and the scope definition will be unrealistic. The result will be a set of products that do not adequately address the needs and market demands they were intended to meet. Inadequate domain understanding can result from
analysis paralysis: The "analysis paralysis" phenomenon occurs when an inordinate amount of time is devoted to the creation of one or more very detailed analysis models. A strategy to mitigate this risk is to perform a relatively quick, broad exploration of commonality and variability to gain an understanding of the issues and their effect on the product line. This allows for early input to management decision makers, who can then assess the value of proceeding further with the analysis and allocate resources accordingly. It also allows some of the design work to proceed in parallel with, for example, the initial architecture exploration. Ideally, this approach would be part of an overall iterative and incremental process for the development of the product line. An alternative risk mitigation strategy is to narrow the scope of the analysis.
a lack of access to the necessary domain expertise: Eliciting domain information from the domain experts is essential. However, they are usually coveted organizational resources who are in high demand and may not be in the same geographical location as the rest of the analysis team. Therefore, careful planning is needed to ensure that the domain experts' time is not wasted. Such planning may include scheduling specific meetings with the experts, circulating elicitation questionnaires in advance, and using videoconferences or teleconferences when face-to-face meetings are not possible. In all cases, there must be management commitment to ensure that the domain experts are available for participation.
inadequate documentation and sharing of relevant domain information: If the understanding of the relevant domains is in the heads of a few key people and not shared with the rest of the product line team, there is a great and obvious risk should any of these key people leave the organization. There is also the more subtle risk of false assumptions and time wasted rediscovering what is already known. Hence, the "mental model" carried by the key people should at least be recorded so that it can be shared. The level of rigor and amount of detail in the documentation should be driven by the need to make such information robust enough for the long haul of a product line effort. At a minimum, assumptions and decisions about what is common, what is variable, and what is excluded from the product line should be documented, plus some justification of them that ties to the business case. Recording this information will also mitigate the risk of having key people leave the project, taking their domain understanding with them.
a lack of an understanding of an analysis process: The naïve application of an analysis process can be evidenced by a too-early focus on design and implementation issues or too much time spent on the analysis. Proper training in both the analysis method and its role for the product line is essential here; the analysis should be performed in the context of the organization's overall reuse and process improvement goals and the specific goals established for the product line.
a lack of the appropriate tool support for the process and products of domain analysis: Organizations typically use existing commercial object-oriented analysis and design tools to support a product line analysis effort. Such tools may not support the kind of conceptual modeling required by product line analysis; care must be taken to avoid being driven by the tool into a premature design process masquerading as an analysis process.
a lack of management commitment: If management does not appreciate the value of domain understanding and does not understand the need for an analysis process that could be time-consuming and that does not culminate with the production of any marketable products (or executable code), the effort will likely lose requisite management support. The documentation of relevant domain information and any analysis that is initiated should be grounded in issues that are key to management's ability to support specific business goals established for the product line. The product line organization must make upper management aware of the importance of having documented domain understanding not only as essential input to subsequent decisions about the product line but also as a powerful way of mitigating the technical and product risks associated with the product line effort.
[Arango 1994a, Ch. 2]
Arango provides a comparative survey of published domain analysis methods that also maps each method onto a common domain analysis process.
Ardis and colleagues describe an effort in understanding relevant domains at Lucent Technologies in 1994.
Bayer and colleagues describe CDA, a domain analysis method that is part of the PuLSE product line engineering framework created by the Fraunhofer Institute for Experimental Software Engineering.
Geppert and Weiss describe Avaya Labs' method for the quantitative assessment of potential product line domains and, using an example application of this method, define measures for a candidate domain's potential corporate impact and likelihood of success when implemented as a product line.
Kang and colleagues provide a comprehensive description of FODA.
This paper presents FORM, an extension of FODA used to develop domain architectures and components for reuse.
Lee and colleagues describe their experience with domain analysis for their software product line.
This guidebook describes the Software Productivity Consortium's Synthesis methodology, which incorporates domain analysis into the construction of families of systems having similar descriptions.
This STARS report describes ODM.
Tolvanen and Kelly describe industrial cases where domain-specific modeling has been used successfully.
Weiss and Lai describe the commonality and variability analysis, which is an important part of Weiss and Lai's FAST process for product lines.