One of the most effective ways to identify and manage reusable software assets is by understanding the concepts in your domain that vary and the need for supporting these variations in a flexible manner. The idea of domain concepts having variability is not new and is present in several domains.
For example, cell phone software could have variations around size/features on the contact list, ability to create and manage image/video content, and the support for web browsing and data exchange. Using these core categories of variations there might be a variety of cell phone offerings that might need to be supported.
For the sake of this post, lets say there are only three flavors: a basic plan, a medium plan, and a high-end plan. All of them support local and long distance calling, call waiting, caller identification, and voice-mail. The basic might support 50 contacts in the contact list, no support for multiple numbers per contact, and only ability to view pictures from other callers. The medium supports all the features of the basic and additionally offers ability to store multiple phone numbers per contact, take and email pictures as well as store 100 entries in the contact list. The high-end flavor might support storage for 500 contacts, ability to take pictures and store and distribute them, as well as ability to view video content.
What you are looking at is certainly a product line that needs to be managed. If not, there will not be reuse but chaotic duplication of functionality implemented inconsistently across the different flavors. To manage the variations:
- Separate common capabilities across products from ones that vary with every product
- Identify the capabilities that vary among the products
- For each capability identify the parameters that will vary based on product offerings
- Establish a means to gracefully upgrade or downgrade among products within the product line
- Encapsulate variation characteristics via configuration external to the execution code
The capabilities that are common need to be built as reusable software assets leveraged across the product line. The capabilities that vary are also built as reusable software assets supported by a variability mechanism. In the example from above, contact management could be the same asset reused across all the products with product specific parameters – basic only supports 50, medium 100, and high-end 500 contacts – based on the product the total number of contacts could be customized. Similarly, the idea can be extended to all the other features that vary across products in the product line. This in essence the idea of encapsulating what varies and can be applied to classes and software services. In the coming days, I will expand on aligning product variations within an iterative lifecycle in order to not only achieve systematic reuse but minimize schedule risks.