Previous Next V-Model Official Homepage by IABG  
Part 3: Collection of Manuals Homepage  
Tailoring  Homepage  
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

    The adjustment of the generic V-Model to the actual project is realized by means of the following steps: The listed steps are combined under the term "Bid-Relevant Tailoring" (1).

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

    At the beginning of a project, the activities and products appropriate or required for such a project have to be defined. This is a decision about which parts of the V-Model scope may be generally used in the project, and which parts are appropriate for the project. Thus a basic decision is made for the project. The activities and products are documented in the chapter 5. Project-Specific V-Model of the Project Manual. The reasons that lead to this decision are added to the Project Manual as deletion conditions in chapter 3. Overview (marked "BT").

    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
    Figure T.2: Application of the Tailoring

    T.2.1.1 Consideration of the Minimum Set

    When selecting the project-specific activities, it is expected that a certain minimum set of activities and products is taken so the corresponding activities and products cannot, in general, be deleted by the tailoring. In case the required products by an activity are already available, the activity may be deleted without violating 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.

    Table T.1: Minimum Set of Activities in Submodel SD

    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.

    Table T.2: Minimum Set of Activities in the Sub-Models QA, CM and PM.

    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

    This approach is based on the idea that projects with similar characteristics can be combined into project classes.

    The following project classes are defined:

    In order to get the appropriate classification for the standardized pre-tailoring it is necessary for the first two classes to be differentiated with regard to the size of the project.

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

    These project types are explained and described in section T.3 IT Project Types .

    The following figure illustrates the structure:

    Figure T.3
    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.
    Additional regulations have been listed in the forms for the individual additions. By selecting the project type and the required additions, a first version of the Project Manual can be generated.

    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

    Based on the number of deletion conditions set up on the basis of experience, the tailoring of activities and products can be realized. Further deletion conditions may be added at any time. The selection of activities and products must be justified. A deletion condition may consist of:

    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:

    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

    The V-Model makes it possible to use a number of development strategies (see manual Scenarios). The development strategy has an impact on the repeated realization of activities and thus on the increased completion of products. However, it has little impact on the selection of activities. If, based on the selection of a development strategy, an activity is realized repeatedly then this activity must only be added to the Project Manual once. The repeated realization of the activity must be considered in the planning activities of sub-model Project Management (PM), though.

    Figure T.4
    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

    To generate the project-specific V-Model odelby applying the tailoring procedure, the following procedure is recommended:

    1. Definition of Project Class
      It must be determined to which of the three project types the project belongs: 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:

    Figure T.5
    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
    Figure T.6: Illustration of the different Tailoring Procedures

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

    The assessment of the project-specific V-Model comprises several steps:

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

    A project-specific V-Model is described and documented by: The following sections give more information.

    T.2.3.1 Activity and Product Descriptions

    Two possibilities are offered with regard to the documentation of activities and products: The following regulations have to be observed for the adjustment of text and the description of activities:

    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:

    Figure T.7
    Figure T.7: Example for the Adjustment of Activities

    T.2.3.2 Recordings of Deletion Conditions for the Project

    The decision about the project selection and the deletion conditions to be applied for that project must be included in the chapter 3. Overview of the Project Manual.

    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

    Table T.3: Deletion Conditions BT, TT

    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

    Mail 0628 - Re: Tailoring / Individuelle Anpassungen (628)
    Mail 0260 - Re: Midestanforderungen (260)
    Mail 0256 - Re: Midestanforderungen (256)
    Mail 0251 - Midestanforderungen (251)

    Note:

    (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.

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