T.2 Project-Specific Adjustments of the V-Model

  T.2 Projektspezifische Anpassung des V-Modells

Contents		T.2 Project-Specific Adjustments of the V-Model T.2.1 Generation of the Project-Specific V-Model       T.2.1.1 Consideration of the Minimum Set       T.2.1.2 Standardized Pre-Tailoring       T.2.1.3 Tailoring with Deletion Conditions       T.2.1.4 Consideration of Development Strategies for the Tailoring       T.2.1.5 Application of the Tailoring Method T.2.2 Assessment of the Project-Specific V-Model T.2.3 Documentation of the Project-Specific V-Model       T.2.3.1 Activity and Product Descriptions       T.2.3.2 Recordings of Deletion Conditions for the Project Links to the V-Model Mailinglist

T.2 Project-Specific Adjustments of the V-Model

• Generation of the Project-Specific V-Model

  The activity and product classes that are appropriate and practical for the project are defined. It is possible to differentiate between two methods:

  1. standardized pre-tailoring
  2. tailoring with deletion conditions.

  The reasons for realized deletions and the conditions for the admission of future deletions (deletion conditions) will be defined as well. They are evaluated during the project planning (detailed planning). When selecting the activity and product classes, minimum set of conditions have to be taken into consideration that must be observed in every project.

• Assessment of the Project-Specific V-Model

  The realized deletions resulting in the project-specific V-Model must be assessed with regard to its reconstruction. In this connection it is important to find out if the minimum set are covered or if deviations are sufficiently explained. The model itself must be assessed with regard to its consistency, i. e. if it can be realized.

• Documentation of the Project-Specific V-Model

  First, the form of the project-specific V-Model is defined, i. e. in which way the project-specific V-Model describes the activities and products. There are two possibilities: the activities and products of the project-specific V-Model

  1. refer to the descriptions of the generic V-Model or
  2. they contain the complete representation of the V-Model.

  In case the description text is adopted from the V-Model, the text can be adjusted.

T.2.1 Generation of the Project-Specific V-Model

During the realization of the project it is practical to allow further possibilities to delete activities and products. Within the scope of activity PM4 - Detailed Planning, the products generally intended for the project are identified for the planning section ahead. Under certain conditions (depending on the situation) individual activities can be deleted. This form of adjustment is called technical tailoring. The reasons (marked "TT") must be defined at the beginning of the project so arbitrary deviations from the project plan are impossible while the project is being realized. These reasons must be documented as deletion conditions in chapter 3. Overview of the Project Manual.

Figure T.2 illustrates the application environment of the tailoring. The unique application of the tailoring procedure at the beginning of the project-the so-called bid-relevant tailoring-results in the definition of the project-specific V-Model and in the specification of the deletion conditions relevant for the technical tailoring. The technical tailoring will then be repeatedly conducted on the basis of the TT deletion conditions, within the detailed planning of the project.

The two methods to define the relevant activities and products,

1. standardized pre-tailoring and
2. tailoring with deletion conditions,

are described more closely in the following. This method demands that the minimum set is taken into consideration.

Figure T.2: Application of the Tailoring

T.2.1.1 Consideration of the Minimum Set

The minimum set results from the basic understanding of the regulations for order handling and, e. g., from requirements of the ISO 900x. Deviations from the minimum set must be justified in relation to the project.

Note: If V-Model activities are listed in the following that must be realized as minimum set in each project, then the reasonableness of the realization must be kept in mind. This means that, in small projects, the realization may be required but cost and efforts must not be over expanded. In this case, the resulting products will have a specially appropriately low volume.

Next, the minimum set of activities for the four sub models are listed:

Minimum Set of Activities in Submodel SD
SD 1.2	Description of Application System The User Requirements represent the users point of view of the planned system. Therefore, they are the only reference point for reaching the objectives of the entire system development. They also are the basis for the acceptance of the system.
SD 2.1	Technical System Design The specification of a technical system structure is required in every project. The system structure results in small modules and thus helps to reduce the complexity.
SD 3.4	Definition of Requirements for the Quality of the SW/HS Unit Requirements to quality are the basis for the appropriate realization of product assessments, because every product assessment is to prove that the defined requirements have been met.
SD 4.1-SW	SW Architecture Design A defined SW Architecture is the presupposition for the application of successful test strategies like interface test, whitebox test, error propagation analysis.
SD 6-SW	SW Implementation Basically, the actual generation of executable code cannot be dispensed, even when code generators are used, i. e. activities SD6.1 - Coding of SW Modules and/or SD6.2 - Realization of Database must be realized.
SD 7.3-SW	Integration into SW Unit The integration of the elements defined in activity SD4.1 - SW Architecture Design into a SW Unit must take place in a reconstructable process so the parts of the integrated objects can be identified with regard to version, test status, and the like, at any time.
SD 8.1	Integration into System The necessity for this activity results from activity SD7.3 - Integration into SW Unit.

Minimum Set of Activities in the Sub-Models QA, CM and PM.
QA 1.1	Generation the QA Plan The QA Plan is the basis for quality assurance, and thus required for every project.
QA 2.1	Definition of Assessment Methods and Criteria Documents can only be properly assessed by means of defined assessment criteria. Assessment criteria are, at the least, required for the assessment of the User Requirements and the System Architecture.
QA 2.3	Definition of Test Cases Software can only be properly tested with defined test cases. The completed system must be tested, at least.
QA 4.2	Assessment of the Content of the Product User Requirements, System Architecture and the System must be assessed in minimum. The results of the assessments have to be documented in assessment report.
CM 1.1	Generation the CM Plan The CM Plan is the basis for the entire configuration management and thus a must in every project.
PM 1.3	PM1.3 - Generation of Project-Specific V-Model A sensible application of the V-Model is only possible after a project-specific adjustment. This is documented in the Project Manual. The Project Manual is required for the project control.
PM 1.4	Toolset Management The specification of methods and tools as well as standards and regulations in the Project Manual is the basis for the entire project handling.
PM 1.5	PM1.5 - Generation of Preliminary Plan A reconstructable Project Plan is the basis for every structured project method, this is also particularly true for the success control of defined milestones. The required details of the plan depend on the project itself. However, the aspects "Overall Planning/ Milestone Planning" and "Planning of individual Activities" must always be taken into consideration.
PM 4	PM4 - Detailed Planning The planning of individual activities must be updated during project realization.
PM 8	PM8 - Project Control Without constant project controls it is not possible to get information about the actual status of the project. The controls must take place as an activity to be periodically realized. On top of that, all measures helping to adjust the project development to a changed situation, must be realized in a reconstructable way as well.

Note: The tailoring methods "Standardized Pre-Tailoring" and "Tailoring with deletion conditions", which are described in the next sections, take the above mentioned minimum set into consideration.

T.2.1.2 Standardized Pre-Tailoring

The following project classes are defined:

• administrative projects,
• technical-scientific projects,
• selection, procurement, and adjustment of off-the-shelf products.

This results in the following project types for which, at present, a standardized pre-tailoring exists:

• small administrative IT projects
• medium administrative IT projects
• large administrative IT projects
• small/medium technical-scientific IT projects
• large technical-scientific IT projects
• selection, procurement, and adjustment of off-the-shelf products.

The following figure illustrates the structure:

Figure T.3: Classification of Project Types

It is the objective of the standardized pre-tailoring to determine the customized number of regulations in as simple a way as possible, by taking into consideration both project type and special additions, and by applying standard forms. Forms will be made available (see section T.3.6 Tailoring Forms); to select the activities of the according project type.

The basic regulations contained in the forms can be completed for the following situations (also see section T.3.1 Characteristics with Corresponding Quantifications):

1. A criticality classification (with at least two classes) has taken place.
2. Databases are used.
3. The complexity of the functionality is particularly high.
4. The data structures are particularly complex.
5. The maintenance requirements are particularly high.

It is recommended to check the regulations thus defined once more with regard to the background of the concrete project situation. If necessary, justified deletions or updates have to be realized.

T.2.1.3 Tailoring with Deletion Conditions

• reference to activity or product (reference)
• reason for deletion (text)

Example: Bid-Relevant Deletion Condition

SD1.6 - Threat and Risk Analysis has been listed as an activity in the V-Model. In the current project this activity needs not to be observed since, basically, the regulations of the basic protection are observed (e. g. generally guaranteed on the level of the user organization) and since neither classified nor staff-specific data will be processed. The following is documented in the chapter 3. Overview of the Project Manual: SD1.6 - Threat and Risk Analysis BT deleted, because: The regulations of the basic protection are observed (generally guaranteed by the user organization) and since neither classified nor staff-specific data will be processed.

Example: Technical Deletion Conditions

SD5.2 - Analysis of Resources and Time Requirements At the start of the project ("Analysis of Resources and Time Requirements"), was basically considered as a good idea and included in the chapter 5. Project-Specific V-Model. The SW Modules to be developed in the current planning section only use a small fraction of the available resources. Obviously it is not practical to realize activity SD5.2-SW for these SW Modules. In order to delete activity SD5.2-SW , contrary to the Project Manual, it was noted in the Project Manual that although activity SD5.2-SW may be required to handle a project reasonably well (e. g. in some cases already foreseeable), it may be deleted in a case where there are obviously sufficient resources available. This prevents an "over-regulation" of the project as well as senseless documents. The following is documented in the chapter 3. Overview of the Project Manual: SD5.2 - Analysis of Resources and Time Requirements TT deleted, if: The assessed SW module requires only a small part of the available resources and this fact is made plausible in a reconstructable way within the scope of the module documentation (SW Design (Module)), e. g. by a brief explanation.

When applying the deletion conditions, the degree to which the deletion is either approved or rejected is defined for the project. It is differentiated between the following cases:

1. If the reason for the deletion of a project activity is given, it must be identified with "BT" in the chapter 3. Overview of the Project Manual. The activity is deleted in the Project-Specific V-Model.
2. If the reason for the deletion of an activity is to be used while the project is being realized, this reason must be identified with "TT" and entered in the chapter 3. Overview of the Project Manual. The activity has to be added to the project-specific V-Model.
3. If the reason is not used to delete an activity for the project, it can be identified with "-" (not BT and not TT) in the chapter 3. Overview of the Project Manual (optional) to consider a delimitation of the corresponding reasons. The activity is relevant for the project and must be added to the Project-Specific V-Model.

Similar statements can also be applied for products. If the reasons for deletion according to section T.4 Deletion Conditions not be applied in relation to the project, it is necessary to state the individual reasons.

Figure T.4: Application of the Deletion Conditions illustrates the chronological development in connection with the selection of relevant deletion conditions for a project.

T.2.1.4 Consideration of Development Strategies for the Tailoring

Figure T.4: Application of the Deletion Conditions

Next, the effects of the development strategy on the selection of activities required by the minimum set are briefly explained:

Incremental Development:	No
Grand Design:	No
Use of Off-the-Shelf Products:	The activities PM2 - Placement/ Procurement and SD1.7 - Realization of Requirements Controlling must be realized. If necessary, User Requirements and System Architecture have to be changed. Certain SD activities can be deleted, depending on the type of the off-the-shelf product.
Object-Oriented Development:	No
Knowledge-Based Systems:	No
Maintenance and Modification:	Completion of important CM activities (CM1.2 - Setting up CM and CM3 - Change Management (Configuration Control))

The complexity of functions and data play an important role in the tailoring mechanisms introduced in this manual. Functions and data are assessed separately. When applying an object-oriented development strategy, the aim is to encapsulate functions and data in classes and objects and to overcome this separation. In order to classify the complexity it is possible, however, to continue to assess both aspects separately. To classify the complexity of the functionality it is possible to assess the operations allocated to the classes. For the complexity of the data it is the classes as units, as well as their attributes.

T.2.1.5 Application of the Tailoring Method

1. Definition of Project Class
   It must be determined to which of the three project types the project belongs:
   • administrative IT projects,
   • technical-scientific IT projects, or
   • selection and procurement of off-the-shelf products (standard applications).
   In case none of these project types are suitable for the project, tailoring with deletion conditions must be applied (see item 5).
2. Definition of Project Size
   The size of the project must be determined by means of the classification characteristics for project sizes.
3. Selection of Corresponding Form
   The form corresponding to the project type must be selected (section T.3.6 Tailoring Forms). This also defines the basis activities and products.
4. Selecting Completions from Form
   It is necessary to check if one of the conditions for the realization applies (criticality higher, database application, function and data complexity higher). The additional activities and products from the corresponding columns/lines must be obtained accordingly (continued with item 7).
5. Applying Tailoring with deletion conditions
   If no project type can be selected or if other modifications are necessary, the deletion conditions from section T.4 Deletion Conditions can be applied.
6. Definition of Development Strategy
   The development strategy (see Scenarios manual) must be defined.
7. Assessment of Project-Specific V-Model
   The reasons that lead to the project-specific V-Model have to be assessed with regard to reconstructability. The model itself must be assessed with regard to its consistency in the sense of "reconstructability" (see section T.2.2 Assessment of the Project-Specific V-Model). Furthermore, it is necessary to check if the minimum set in section T.2.1.1 Consideration of the Minimum Set have been covered.
8. Documentation of Project-Specific V-Model
   The activities and products considered as practical and necessary for the project have to be included in the Project Manual to be generated (chapter 3. Overview of the Project Manual ). References to the type of the documentation are found in section T.2.3.1 Activity and Product Descriptions.
9. Documentation of Project-Specific Deletion Conditions
   Both the deletion conditions resulting in the project-specific V-Model and the technical deletion conditions for the realization of the project must be documented in the chapter 5. Project-Specific V-Model (see section T.2.3.2 Recordings of Deletion Conditions for the Project.

The procedure is illustrated in Figure T.5 In this connection, the following has to be observed:

• The technical deletion conditions are only defined with the method "Tailoring with deletion conditions". If no technical deletion are defined for the project, no further possibilities for individual decisions shall be admitted during the project development. The V-Model does not demand that the technical tailoring is binding.
• The standardized pre-tailoring may be used for the first selection of activities and products. Any further adjustment can-if necessary-be realized by means of the method "Tailoring with deletion conditions".
• In a case where it is not possible to select a project type, the method "Tailoring with deletion conditions" has to be applied. That way it is possible to define the bid-relevant and the technical deletion conditions at the same time.

Figure T.5: Generation, Assessment and Documentation of the Project-Specific V-Model

The procedures Standardized Pre-Tailoring and Tailoring with deletion conditions are used to find out the appropriate or respectively necessary activities and products for a project. The tailoring with deletion conditions assumes the maximum number of activities and products defined in the V-Model . It identifies the relevant deletion reasons. In order to facilitate the tailoring for the most frequent project types, tailoring suggestions were made for six project types. These project types can be used as a start to generate the Project Manual in less time.

Figure T.6 illustrates that, basically, both procedures lead to the same result (project-specific model) by starting from the same initial position. It is the aim of the deletion conditions in section T.4 Deletion Conditions to define possible arguments for the deletion of activities and products of a project or respectively a project type.

Tailoring with deletion conditions is identified by high flexibility since, based on the deletions, the number of individual constellations to be taken into consideration is almost unlimited.

Standardized pre-tailoring is less flexible (it is only applicable for "pre-imagined" project types), but, based on the use of forms, easily realized.

Figure T.6: Illustration of the different Tailoring Procedures

T.2.2 Assessment of the Project-Specific V-Model

• Assessment of the Reasons for the Deletion

  The reasons to delete activities and products in a project must be objective and reconstructable. The reasons must correspond to the characterization of the project and the development subject, in accordance with the 2. Project Description of the Project Manual . This assessment concentrates on the contents and can, therefore, not be replaced by a tool.

  The deletions of activities and products may, based on certain standards and regulations that must be observed in the project, not be permitted. For official areas, especially those connected with budget, cash accounting and accounting systems, the federal and state level Audit Offices have developed definite ideas about the realization of IT projects. These were published as "Minimum Requirements of the Federal and State Audit Offices for the Application of Information Technology (IT Minimum Requirements)", (see manual FAO Meeting the Minimum IT Requirements of the Federal Audit Office by Means of the V-Model).

  The reasons leading to a violation of the minimum set listed in section T.2.1.1 Consideration of the Minimum Set must particularly be checked with regard to reconstructability.

• Assessment of the Effects of Deletions

  Usually, the deletions of activities have an impact on other activities and products. For example, if an activity is deleted because the product realizing the activity has already been submitted, then the product is an external product. Other products are also deleted after the deletion of an activity. A closer description of the effects is contained in section T.4 Deletion Conditions. The effects of deletions have also to be considered when naming the deletion conditions in the chapter 3. Overview of the Project Manual and when describing the product flows and the handling text (if described in the chapter 5. Project-Specific V-Model of the Project Manual).

• Consistency Check of the V-Model

  In a case where the project-specific V-Model also considers the product flows and where it is to be mapped in a workflow system, the assessment of realizability is of importance. In this connection, the following assessments are, among others, required:

  • Product flow assessment for activities (e. g., is the initial product of an activity really produced or respectively modified by another activity?).
  • Assessment of the changed product state.
  • Prevention of isolated (sub-) products and (sub-) activities.
  For consistency reasons, adjustments of product flows and deletions of activities and products may become necessary.

T.2.3 Documentation of the Project-Specific V-Model

• Activities and products.
• Deletion condition for the project.

T.2.3.1 Activity and Product Descriptions

• The activities and products of the project-specific V-Model refer to the descriptions of the generic V-Model.
• The description text of the V-Model is adopted for the activities and products. This also includes handling text of activities and product design.

The V-Model activity descriptions include case descriptions and differentiations of all kinds of project scenarios and circumstances. In an actual project, these case differentiations can be deleted; the descriptions may refer to concrete project conditions.

This means that all not relevant parts of the description text for activities, recommendations and explanations can be deleted. These deletions may result in the necessity that linguistic formulations must be adjusted. The remaining text sections can be completed with concrete project relationships, like references to preliminary investigations, existing results, references to cost and effort, references or information for whom (customer, contractor or sub-contractor) the activity may be relevant. This last information is practical in a case where only one Project Manual is to be written for both the contractor and the sub-contractor.

The pre-requisite for the modification of the activity text is that the original text of the V-Model and the supplemented text can be differentiated visually (e. g. based on different fonts).

Based on activity SD1 - System Requirements Analysis, the following example (see Figure T.7) explains:

• how parts in the activity description that are not applicable are canceled,
• how activity descriptions are realized for non-applicable parts,
• how necessary linguistic adjustments are realized,
• how user references important for the project development are completed,
• how the implementor of the activity is identified, and
• how the project-specific completions are optically identified.

Figure T.7: Example for the Adjustment of Activities

T.2.3.2 Recordings of Deletion Conditions for the Project

Activity/Product of the Generic V-Model	Deletion	Reason for Deletion (deleted, because, or deleted, when)
Activity or product name	BT	reason for general deletion
Activity or product name	TT	reason for deletion in technical tailoring
Activity or product name	-	i. e. no reason for deletion exists

A possibility for a tabular representation, where the methods and tools are allocated for activities that are not canceled, is described in part 1, Regulation Part in section 8, "Product Design" under 3. Overview of the Project Manual .

Links to the V-Model Mailinglist

(1) The first step has to be performed if the result is to be used not for a tender but, for example, for the specification of an internal development order.

This page online  •  GDPA Online  •  Last Updated 03.Mar.2004 by C. Freericks