GuardIEn uses the concept of a 'deliverable' to define the configurable items.
For CA Gen projects, this means high level object types like action
blocks, procedure steps and entity types as well as external objects that can be versioned using XOS.

Each deliverable is individually versioned in GuardIEn. This enables the tracking
of the versions that have been created for a deliverable, the release of the
system they are included in, and their progress through the development life-cycle.
Versions are automatically created by GuardIEn when changes are uploaded to
the encyclopaedia using the integrated Upload
Assistant.

The concept of versioning
deliverables is key to the effective automation of configuration management,
but it also requires the ability to explicitly and uniquely identify individual
versions. Whilst CA Gen allows multiple versions to be stored, it does not allow
them to be explicitly identified. GuardIEn complements CA Gen by enabling the
explicit identification of versions. The data about the versions is stored in
the GuardIEn database and linked to the underlying objects in the models.

GuardIEn can be setup to
record each change made to an object, when it was changed and which userid applied
the change.It can
store the action diagram (PAD) statements for each change and produce a comparison
between any two versions. This allows statement level tracking of changes to
an action diagram without requiring separate models. To view the differences,
you can select any two versions and press the Compare button to view the differences.

Since GuardIEn stores
the data for the minor versions in its own database, it is able to provide statement
by statement, property by property tracking of changes. This is not possible
if you only rely on the Gen encyclopaedia since a Gen model only contains the
latest version of an object.

Release Management

An important part of effective
configuration management is a clear and well understood release management policy.
This helps plan when changes are to be applied to the production system. It
should cater for both the medium to long-term enhancements as well as short
term fixes that may be required.

GuardIEn helps projects
to define and plan release implementations by providing facilities to document
the releases and their content. Multiple system releases can be defined as either
independent releases, or linked as a hierarchy of releases which facilitates
the tracking of changes between releases.

GuardIEn allows the parallel
development of system releases. This enables the team to work on more than one
release at the same time. The diagram below illustrates an example model architecture
for parallel development.

One of the problems with
parallel development is ensuring that any changes or fixes that are applied
to a release are also applied to the subsequent release. This is illustrated
in the diagram above by the blue double headed arrow linking the development
models for releases 1 and 2.

GuardIEn contains special
facilities for tracking changes in one release and detecting whether they can
be safely migrated to the next release or not. It uses a concept called 'baselining'
to detect whether the object has been changed in the subsequent release and
thus whether it can be migrated or whether the change has to be manually applied
to the next release to avoid losing any changes made in that release.