An enterprise has a core set of artifacts that it relies on for its software development and related activities. An
asset is a collection of artifacts, but is more than simply that.
An asset has several major characteristics, including:
-
A collection of one or more artifacts: files, binaries, models, tests, etc.
-
Connections: tool integrations that the asset needs to be properly used
-
Access control: who can do what with the asset
-
Classification: tagged values and terms to classify assets
-
Relationships to other assets: dependencies, aggregation, etc.
-
Measurements: who is using the asset, what defects does it have, etc.
-
Policies: descriptions of proper structure and content for the asset
Each asset is of a single type. The asset type describes:
-
The purpose of the asset
-
What content, or artifacts, it contains
-
Relationships with other asset types
-
Category schemas and contexts which are relevant
-
Custom attributes, or metadata elements, on the asset type.
Development-time repositories manage assets that are relevant to development roles such as technical managers,
analysts, architects, developers, and testers. This repository governs the assets as they are submitted, categorizes
the assets, provides access control to the assets, and measures the activity level of assets in terms of their usage.
A collection of asset types with these characteristics describes an information architecture that is enforced by
the repository. The asset types should focus on those artifacts which are critical to the development-related
activities in the enterprise. Not all artifacts are candidates for being in assets.
When an asset is submitted to the repository the asset type is selected. This selection dictates the
artifacts that are expected for the asset.
The basic model of asset types, assets, and artifacts is shown below. The asset type declares the expected structure,
content, relationships and so on. The asset is an instance of one type, adhering to the constraints specified by the
asset type.
When assets are submitted to the repository, it is very helpful to understand the structure of the selected asset type
as well as its relationships and other constraints. At times you may need to have a picture of the asset types and
their structure in front of you.
When creating the asset types, it is useful to understand the artifact names and labels that have been used in other
asset types. Managing the set of artifact names reduces both redundancy and the use of different names for the
same artifact. The administrator should have a single picture or a spreadsheet of the asset types, their definitions,
and their structure along with the artifact definitions in order to reduce confusion and provide consistent use of
terms.
|