The LCM (Life Cycle Management) of a System, as Agile is, still needs a set of constructs (documents) produced within the various activities.
Based on the framework DaD and the related three primary phases (Inception, Construction and Transition, Figure 1), let us try to define a structured related documents and their versioning.
Figure 1 - "Basic" DaD
The idea start by the necessity of having a well define types of documents to be created and a way to connect them with a versioning number related to the DaD phases. Before proceeding should be strongly emphasized that the constructs are meaningless if they create Value for stakeholders, as well as their modification must be made to add new Value.
Following various discussions and the vision of the various proposals, the final proposal is to use four supporting documents:
-
- Proposal [proposal], describes the first idea and the domain afferent;
- Intentional Architecture [iarchitecture], describes the Intentional Architecture with its Views;
- Planning & Costing [planning], describes the Planning and Coting;
- Test Plan [testplan], describes the Test Plan.
Brackets shows the DocumentTypeIdentify that is used in the following naming pattern of the physical file:
ProjectName_DocumentTypeIdentify_VersionNumber
For the VersionNumber is possible to define, in turn, three patterns of versioning sufficiently convincing:
InceptionPath: [0.ReleaseNumber.InceptionReviewNumber];
ConstructionPath: [ConstructionReleaseNumber.IterationNumber];
ransitionPath: [FinalConstructionNumber.TransitionReviewNumber]
with (table 1)
|
Elemento |
Descrizione |
|
0. |
Explicitly identifies the Inception phase |
|
InceptionReviewNumber |
Identifies the evolution of the document through Inception phase |
|
ConstructionReleaseNumber |
Identifies the number Release on which you are working |
|
IterationNumber |
Identifies the current Iteration and, implicitly, the Construction phase |
|
FinalConstructionNumber |
This is the final release of the documents associated with the last iteration incurred for the completion of the project |
|
TransitionNumberReview |
Identifies the maintenance activity and, implicitly, the phase of Transition |
Table 1
Assuming working on Release 1 of the system:
The versions of the documents during the Inception start: 0.1.0
The versions of the documents during the Construction start: 1.0
The versions of the documents during the Transition start 1.last-iteration.0
Let's make some examples of application of the four patterns in their entirety, with reference to a hypothetical Stargate project (Table 2):
|
Phase |
Stato |
Numerazione |
|
Inception |
|
stargate_proposal_0.1.40 |
|
|
||
|
Construction |
|
stargate_planning_1.10 |
|
Transition |
|
stargate_iarchitecture_1.24.3 |
Table 2
The path relative to the Inception phase have a purely sequential numbering without "holes". This means that if we have version 0.1.40 we will have also all versions from 0.1.0 to 0.1.39.
The same applies to the Transition phase (if we have the 1.24.3 we also 1.24.1 and 1.24.2).
On the contrary during Construction, since documents related to the Iterations, there may not be a continuity in the numbering because there can be Itereation we don’t need to create a new version of the documents. So have the version 1.10 does not automatically imply the availability of version 1.1 to 1.9 but only 1.0.
Another element is that the four documents can have a different number of reviews, but at the beginning of each new phase the numbers must be realigned. Thus, if at the end of the phase of Inception we have:
stargate_proposal_0.15
stargate_planning_0.2
stargate_iarchitecture_0.3
at the beginning of phase Construction we will have:
stargate_proposal_1.0
stargate_planning_1.0
stargate_iarchitecture_1.0
Look forward to your comments and your suggestions.
