Guideline: Asset-Producing Projects
This guideline describes some key aspects of a project that produces Reusable Assets.
Relationships
Related Elements
Main Description

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.