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.
|