Step: Define Archiving, Baselining and Labeling Practices

List the Artifacts required for each Major Milestone

The following paragraphs provide a list of the artifacts that are to be produced at the end of each phase.

The outputs of the Inception Phase, geared to establish the technical and financial feasibility of the project, are:

• A vision of the project's core requirements.

Requirements are captured in the following artifacts:

• The Use-Case Model Survey,
• Some Use-Case descriptions,
• An initial glossary, and
• A rudimentary domain model.

• An initial business case, that includes:

• The business context,
• Financial success criteria and forecasts,
• Initial risk assessments, and
• A phase plan including resource requirement estimates.

Apart from a solid understanding of the problem following the bulk of the analysis work, the outputs of the Elaboration Phase are:

• An approximately 80% completed Use-Case Model,
• Design Model,
• Test Model,
• An integrated, executable and baselineable architectural prototype, and Software Architecture Document,
• An updated glossary,
• A revised business case,
• A revised risk list,
• An overall development plan for the project, including evaluation criteria for each iteration.
• A preliminary User Manual (optional).

At the end of the Construction Phase the product should be ready for ‘beta’ testing by a sample set of end-users. The output, at a minimum, consists of:

• An initial release of the executable production software,
• User manuals, and
• Current release notes.

The purpose of the Transition Phase is to make the software product available into the wider user community. In doing so it is normal to get ‘product change requests’ for enhancements, maintenance or changed functionality. As a result the outputs of the Transition Phase are:

• Software releases,
• Updated user manuals, and
• Current release notes.

Determine the Artifact Labeling Convention

The following is a suggested product artifact labeling convention:

<SYSTEM>[<A>]_[<SUBSYSTEM>]_[<A>]_[R|A|B]<X>[.<Y>.<Z>][.BL<#>]

<SYSTEM> Identifies the system

<A> Stands for the three letter acronym for the various kinds of artifacts used in the creation of the system. For example,

PLN    Project Plans

REQ    Requirements Files

UC    Use Cases

MOD    Model Files

SRC    Source Code Files

INT    Public Interfaces

TST    Test Scripts and Results

DOC    Documentation (User, Release Notes)

BIN    Executables

<SUBSYSTEM> Identifies each subsystem

<A>    Stands for the three letter acronym for the various kinds of artifacts used in the creation of the subsystem. For example,

REQ    Requirements Files

MOD    Model Files

SRC    Source Code Files

INT    Public Interfaces

TST    Test Scripts and Results

R|A|B Stand for release, alpha, or beta

<X>     Integer, stands for a major release (e.g. 1)

<Y>     Integer (optional), stands for a minor release

<Z>     Integer (optional), stands for an alternative release (patches, ports, etc.)

BL Stands for base level (an internal release)

# Integer, for internal releases

Here are some examples:

T2K_R1.0                 Release 1 of the Thorn 2000 system

T2K_GUI_R2.0.BL5 Internal release of the GUI system intended for delivery in release 2

T2K_B1.1                 Beta release 1.1 of the Thorn 2000 system

T2K_R2.0.BL16              Internal system baseline #16 of thorn 2000 intended for creating release 2

T2K_R1.0.5                 Maintenance release of Thorn 2000

Create a Baseline

Baselines identify fixed sets of versions of files and directories and are created at given project milestones. Baselines can be created for a subsystem, or for the entire system.

Baselines should be identified in accordance with the scheme outlined in the preceding process step (Determine the Artifact Labeling Convention).

One distinction that needs to be made at the time of creating a baseline are whether you will be creating:

• A ‘Subsystem Baseline’ with ALL the versions of files and directories that have been modified in the subsystem or subsystems.

or

• A ‘System Baseline’ with a SINGLE version of all files and directories in all subsystems.

As a general guideline, it would facilitate release management to create System Baselines at the major and minor project milestones, and Subsystem Baselines as required or at a higher frequency. As a ‘rule of thumb’ it is a good idea to create a baseline if up 30% of the components in a subsystem have been changed.  See also Concepts: Baselining.

Archive Assets

Labeling guidelines described earlier under the process step ‘Determine the Artifact Labeling Convention’ can be used when creating archiving labels. However, additional information may be required on where the actual media is to be stored. For example:

SERIAL NUMBER

VOLUME

VAULT

DATE OF STORAGE

All product related information should be maintained on a database to facilitate release and re-use.