Guideline: Assessing Asset Applicability
This guideline describes how to perform a fit-gap analysis to see if a Reusable Asset will work in a required context.
Relationships
Related Elements
Main Description

Introduction

Assessing the applicability of a Artifact: Reusable Asset is essentially performing a fit-gap analysis to see if an asset will work in the required context. To perform the analysis, you must consider and compare the asset within one or more contexts.

When assessing the applicability of an asset, knowing where to start and the steps to follow minimizes time and cost. Jacobson states (Software Reuse, Addison-Wesley, pp. 8-9) that for pragmatic reuse to occur a systematic approach must be taken in four areas: business, organizational, process, and engineering. Thus, we use these four areas to organize the description of how to assess the applicability of an asset:

The asset may be evaluated in any order. Meaning, the asset's business fit may be evaluated first followed by evaluating the process fit, and so on.

The following sections highlight some things to look for when evaluating the "fit" for a specific area, as well as the kinds of questions to consider.

Evaluate Asset's Business Fit

Financial

  • Determine the reuse cost avoidance by using the asset.
    Another way of saying this is to determine the potential cost savings to the business by using this asset. To do this, you must understand the capabilities the asset provides and what would be the cost for your organization to develop it.
    Understanding the asset's capabilities helps in determining the cost savings by using the asset and the potential payoff threshold.
  • Determine the payoff threshold by using the asset.
    How many uses will it take to payoff the costs of purchasing and maintaining the asset?
    Poulin (Measuring Software Reuse, Addison-Wesley, p. 68) discusses the techniques for calculating this.

For more information on the cost of reuse, see Concept: Reusable Asset.

Legal

  • Determine if the asset's terms and licensing fit with your business model.
    Will the asset be used in domestic and international locations?
    Does the asset need to be distributed to multiple servers?

Maintenance

  • Identify who owns the task of maintaining the asset.
    What are the maintenance support agreements?
    Will the asset authors provide support?
    If it is a white-box asset, can your organization maintain the asset? For more information on white-box assets, see Concept: Reusable Asset.

Evaluate Asset's Organizational Fit

  • Determine if all stakeholders will accept the use of the asset.
    Can your organization overcome the not-invented-here mentality?
    Is the asset viewed as a threat to any groups or individuals within the organization?
  • Determine if the asset will be used and accepted on multiple projects. 
    Is there sufficient need for this asset in other projects?
    Can the costs of reusing this asset be amortized to other projects?
    Understanding the asset's capabilities helps in determining if the asset is a candidate for reuse on other projects within the organization.

Evaluate Asset's Process Fit

  • Determine if the use of the asset will fit into your organization?s process.
    Does this asset require new roles and tasks in the process to develop with it and support it?
    Is your organization?s process maturity level sufficient to incorporate the roles and tasks for reuse?
    Usage information for the asset aids in the evaluation of the asset fitting into the process, as well as the roles required to work with the asset.
  • Make sure that tasks and time have been allocated to use/maintain the asset.
    Will the asset's stakeholders (architects, developers, and so on) be given sufficient time to comprehend, use, and defend the asset?

Evaluate Asset's Engineering Fit

  • Determine ease of understanding and usage
    What is the quality of the documentation?
    How many steps are involved to use the asset?
    How many variability points does the asset have?
  • Determine functional completeness
    Does the asset do what it says and do what you need?
  • Evaluate reliability.
    Exercise and test the asset to determine if the asset will fit your context(s).
  • Evaluate error handling.
    Will the error handling fit into the way your organization's software does it?
  • Review information hiding.
    Are the complexities encapsulated to strengthen the value proposition and decrease maintenance issues?
  • Evaluate cohesion/coupling properties.
    How many dependencies does the asset have?
    What technical assumptions does the asset make?
    Is the asset organized along reasonable, functional boundaries?
  • Review portability.
    What technical contexts will the asset work in?
  • Evaluate comments from other users.
    What has been the experience of others using the asset?
  • Understand level of effort invested in the asset.
    What reuse metrics come with the asset?
    How many person labor months/years are invested into the asset?