Artifact: Reuse Feedback
Reuse Feedback includes experiences reported from browsing, or using the Asset Repository, or a specific Reusable Asset.
Domains: Asset-Based Development
Work Product Kinds: Project Data
Purpose

To provide information on the value and issues pertinent to a specific Reusable Asset or to the Asset Repository as a whole.

Relationships
Container Artifact
RolesResponsible: Modified By:
TasksInput To: Output From:
Description
Main Description

The Reuse Feedback captures feedback concerning a specific Reusable Asset in the repository, the Asset Repository itself, and suggestions for new reusable assets. Feedback concerning a specific reusable asset is intended to be made public (as a testimonial or a review, for example). Relevant feedback is made available to asset consumers when browsing the Asset Repository.

Reuse feedback is a critical lifeline to an Asset Repository. From this feedback asset-level and repository-level decisions are made. From such feedback the organization of a repository may be significantly altered or a Reusable Asset may be modified to address defects or to introduce features.

Brief Outline

Because the Reuse Feedback may provide feedback either on a specific asset in the repository or on the repository itself, it is important that the Reuse Feedback explicitly notes the scope/subject of the feedback: asset or asset repository.

For asset feedback, the Reuse Feedback may describe how useful the asset was, how easy it was to find and apply, as well as any concerns with the asset. It should clearly identify the asset, the version of the asset, the context in which the asset was being used, and so on.

For feedback on the repository, the Reuse Feedback may describe how easy the repository was to use, how easy it was to find assets, enter search criteria, navigate through the assets, etc.

Suggestions for new reusable assets (candidate assets) should include both business and technical considerations.

Some examples are provided below.

Business Considerations:

  • The name of the potential asset.
  • The recurring problem the asset is to provide a solution to.
  • The value the asset could bring to the company. The anticipated return on investment.
  • The anticipated reuse scope, such as personal, team, department, enterprise, public, and so on
  • The potential asset consumers, how many there are, and what are their skill sets.
  • The anticipated costs for producing, maintaining, and reusing the asset.
  • The asset's owner and maintainer.
  • The asset's sponsor (who will pay for it).
  • The longevity of the asset: Is the business' domain sufficiently stable to support the requirements for the asset over multiple reuses?
  • Cost/trade-off analysis: What are the cost tradeoffs if the asset is to be built for one time use?

Technical Considerations:

  • The technical environment for the asset
  • The asset's anticipated form of reuse: black box, white box, etc.
  • The asset's degree of customization (e.g., extension points, variability points, etc.)
  • The level of testing that should be performed on the asset
  • The quality-of-service attributes that the asset should support
  • The level of documentation that should be provided
  • The asset's classification. What classification schema should be used?
  • The asset production approach, will the asset be harvested or developed or acquired?
  • If the asset is to be harvested, any existing project artifacts that may be used as part of the asset.
  • If the asset is to be developed, recommendations on specific artifacts that should be created as part of the asset.

This information helps to form the justification for the asset, which plays an important role when a request for a Reusable Asset is being evaluated.

Note: Not all of the above information needs to be captured when a candidate asset is initially identified. Additional information may be gathered as the request is evaluated and/or approved. 

Tailoring
Representation OptionsUML Representation: None

The actual content of the Reuse Feedback varies and is dependent upon the reuse standards, guidelines, and libraries implemented in the organization and project.

Some possible forms of feedback could include the following:

  • Text feedback
  • Form-driven feedback, including assigning a "rating" or "score" to an existing asset

You may elect to provide one means for reporting general feedback on existing assets, and use a separate means (such as change requests) to report defects, request enhancements, and to suggest candidate assets.