Introduction
To describe a process that produces a Reusable Asset, without specifying the kind of asset being produced, requires a
more generic process than RUP. However, the RUP practices, and most tasks and artifacts apply to a project that
produces Reusable Assets, even when the assets are not executable software, such as reusable requirements or reusable
designs.
The following describes how RUP applies in general to an asset production project. Note that this is not a complete
description since a complete description is dependent on the kind of assets being produced. For example, if no code is
produced, then code metrics, code reviews, and unit tests are out of scope. RUP, and the asset-based development
activities need to be tailored to the specific project, based on the assets to be produced and the target asset
consumers.
Project Management
Some characteristics of asset production projects are:
-
The asset consumers can be people on existing projects, planned projects, and as yet unplanned projects.
-
The asset being managed may not be executable software, and so only some subset of RUP guidance is applicable.
Iterative development and risk management are key themes, as with any RUP project. Development of the asset can and
should be iterative when possible. That is, prioritize features and deliver incremental versions of the asset, and
prove the value of the increments through actual use.
The risks may include technical risks as well as business risks. The asset's complexity may be too great for the asset
consumers, or the business may not be able to pay for the maintenance and care of the asset. Risks should be identified
early and mitigation plans should be established.
Planning should consider the effort of creating/harvesting the artifacts, producing the packaging and documentation,
certifying and validating the asset, and maintaining the asset.
The Business Case (which may be the responsibility of the organization reuse program, rather than the asset production
project) should include the following considerations:
-
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?
Environment
Before asset-based production tasks can be performed, an environment must be set up that supports these tasks. There
needs to be an environment that allows the assets to be packaged and delivered to the organization reuse program.
The delivery process should be updated to include the project's asset-based development tooling. For more information
on tooling to support asset-based development, see Tool: Rational Asset Manager.
The project-specific guidelines may also need to be modified to reflect the refined workflows. For more information on
preparing project-specific guidelines, see Guideline: Preparing Project-Specific Reuse Guidelines.
Requirements
All projects, including asset production projects, need to identify and manage requirements.
The main difference is that the requirements aren't necessarily for an executing system, and the stakeholders are
different, as described previously. Use Cases, if produced, would typically include the use cases for how the asset is
to be located and applied.
Some specific guidance is provided for producing a Vision. See Guideline: Developing a Specification for a Reusable Asset.
Analysis and Design
This RUP discipline is focused on the analysis and design for a software product. If the product is not a software
system, but rather some other kind of asset, such as a Design Pattern or a Test Suite, architectural concerns must
still be addressed. For more information, see Guideline: Architecture of a Reusable Asset.
It's often a good idea to build an architectural prototype of the asset, as a means of mitigating risks and getting
early feedback, even when the asset isn't executable software.
Example: A project produced a collection of assets for consumption through a corporate Intranet channel. However, the
target audience did not possess the necessary background to work with the flexibility and inherent complexity of the
assets. The assets had to be simplified and the number of variability points drastically reduced.
Configuration and Change Management
There are general tasks that apply to the production of any Reusable Asset. This includes harvesting existing
artifacts, developing new artifacts (Task: Create Asset), update existing artifacts (Task: Update Asset) packaging the artifacts into Reusable Assets, versioning an
asset.
Other Disciplines
As noted previously, all disciplines are applied as relevant to the specific kind of Reusable Asset.
Implementation and Test disciplines specifically describe implementing and testing executable software, and so
predominantly apply when the asset is executable software.
|