Previous Next V-Model Official Homepage by IABG  
3 General Regulations  

  3 Allgemeine Regelungen

Contents  
  • 3.1 Project-Specific V-Model and Tailoring
  • 3.2 Project Organization and Roles
  • 3.3 Applying the Scenarios
  • 3.4 Operative Modules
  • 3.5 Handling Products to be Updated
  •      

    3.1 Project-Specific V-Model and Tailoring

    The activities and products described in the submodels are intended to be applied both in small and in large IT system development projects or maintenance and modification projects. According to the object to be developed, its functionality requirements, complexity of functions and data and to the quality characteristics, e. g. maintainability, the availability of a (sub-) product and the realization of a (sub-) activity have to be defined in the actual project. With regard to the generic V-Model, products and activities may be omitted in certain projects. The result of this planning stage is called "project-specific V-Model".

    The definition of the project-specific V-Model is supported by two adjustment tasks:

    The tender-relevant and the technical tailoring function have been described in Part 3 Collection of Manuals (Tailoring and Project-Specific V-Model manual). Part 3 also contains examples for possible deletion conditions as well as various tailored project types.

    3.2 Project Organization and Roles

    The staff organization plan, i. e. the allocation of tasks to individual staff members in the project, is done by means of roles. The V-Model lists a set of roles for each submodel in which those taking over particular roles carry out activities according to defined roles/activity allocations. It must be differentiated between different process types: "responsible (in the sense of the realization)", "cooperating" and "advising". Know-how and abilities required for processing the allocated activities are mentioned for each role.

    The staff organization plan also comprises the selection of staff members or other organizational units for the activities via the definition of roles. A role may be given to one or to several staff members. The staff member must have the appropriate know-how and abilities for that role; after that he can be included in the plan for the realization of activities allocated to that role, according to the participation types. Example: one person may be allocated several roles in a small project although certain rules have to be observed. For example, no developer is allowed to assess his results himself within the scope of QA.

    Based on this concept of roles, with regard to the organization, the V-Model is impartial. A general allocation of existing jobs in an organization to roles may simplify the organization for each individual project and is therefore recommended. However, this is not mandatory in the V-Model.

    A successful development requires that the following agreement processes are regulated:

    The V-Model roles and their participation in activities are described in Part 3 Collection of Manuals (Concept of Roles in the V-Model ).

    3.3 Applying the Scenarios

    The V-Model describes the system development in the Regulations part (section 4ff.) as a logical network of activities and products. The interdependencies are given because minutely defined input products have to be available in a defined state for processing a given activity. In a real project realization, all development activities have to be mapped to a lifecycle model to be integrated in a chronological sequence. Hereby, the selected development strategy and the resulting static dependencies, i. e. the dependence of each activity on the availability of the required input products, is the basis of the sequence planning.

    In real life, a system development is handled in upgrades. While doing so, an entire System is planned, but only realized in parts. The functionality grows continually. Normally, a first system version is to be handed to the user as soon as possible; this system version should include the basic functionality by maintaining the basic quality requirements. Later system parts essentially expand this functionality.

    This step-by-step approach is referred to as incremental development. It represents the normal use of the V-Model.

    In order to use the V-Model, upgrades have to be planned. For each upgrade, the functionality to be realized must be defined, including the corresponding quality requirements. The activities and products of an upgrade must be chronologically planned according to the logical conditions defined in the product flows. Products that based on incremental development are subject to dynamic processing (e. g. User Requirements), must be established for each upgrade according to the planned state of the products.

    In Part 3 Collection of Manuals (Scenarios manual) the various uses of the V-Model during the development of systems has been illustrated on the basis of the following scenarios:

    The scenarios "Use of Off-the-Shelf Products", "Object-Oriented Development", and "Development of Knowledge-Based Systems" are based on the incremental development strategy. The traditional procedure of linear, phase-oriented system development (grand design) is a special case of the incremental development (realization in one upgrade).

    Figure 3.1
    (daVinci Graph Visualization Tool v2.0)

    Figure 3.1: Planning a System Development

    Figure 3.1: Planning a System Development illustrates the planning phase of the development of an IT system. The planning of activities and their corresponding products is realized according to the development strategy defined in the Project Manual and also according to the project-specific V-Model. The scenarios in the collection of manuals offer support when defining the development strategy by specifying selection criteria.

    Different strategies can be selected for different system portions. This may result in the necessity of different versions of the project-specific V-Model.

    3.4 Operative Modules

    Apart from the submodels mentioned in the Regulations part of the V-Model (Part 1, section 4ff.), Part 3 Collection of Manuals includes different supplements or replacements of the submodels, which are referred to as "operative modules". Their use depends on the object to be developed.

    If on top of the development of the SW Units, the development of the planned IT system also requires the development of HW Units, then submodel SD must be supplemented by the hardware generation. The operative module "Hardware Generation" is concerned with the development of HW Units (activities SD 4-HW: HW Preliminary Design to SD 7-HW: HW Integration).

    In case it is a reverse engineering project, the entire submodel SD can be exchanged by the operative module "Reverse Engineering".

    3.5 Handling Products to be Updated

    Normally, the V-Model handles products as follows: This procedure is applied for most of the products regulated in the V-Model, in particular for SD and QA products.

    Yet the particularities of an IT system development require a deviating procedure for some products: Versions may (e. g. within the scope of an incremental procedure) change into state "submitted" even though they are only complete with regard to the planned version.

    Among the products possibly belonging to this modified update procedure are:

    1. User Requirements,
    2. System Architecture,
    3. Technical Requirements,
    4. Operational Information,
      (User Manual, Diagnosis Manual, Operator Manual, Other Application Information)
    5. Interface Overview and Interface Description,
    6. Data-Dictionary,
    7. Configuration Identification Document (CID),
    8. Change Status List and Project History,
    9. Project Plan and
    10. Integration Plan.
    1. "User Requirements"

      The update of product User Requirements is specially handled with regard to an incremental procedure.

      The preliminary system description includes the core and the overall horizon for the system functionality. The fields are realized at different time intervals and are identified based on a prioritization. To do so it must be defined in which (field-related) upgrades the system is to be developed and which overall functionality is to be covered in the final version. For this purpose, milestones (if necessary as baseline with time and range of function) have to be specified. This also requires that all relevant technical fields are identified and that they must be separated with regard to their range of function. The first version of User Requirements can be completed after the complete description of at least one field. This is subject to QA.

      The further updates of the User Requirements are based on the level of refinement of the identified fields. Prior to further improving a new field, the User Requirements for this field have to be specified and their quality assessed. QA must take care that the updates do not contradict any existing User Requirements. Changing the agreed overall horizon for the functionality during the development has to be realized via activity CM3 - Change Management (Configuration Control). Subdevelopments may also be concerned which, because of contractual reasons, may cause problems.

    2. "System Architecture"

      The System Architecture describes the decomposition of the System, up to the SW/HW Unit level. While being generated, it is in activity SD2 - System Design in the state "b. proc.". In spite of this fact it is practical to have QA assess any new parts, right after each design step.

    3. "Technical Requirements"

      Product "Technical Requirements" contains technical requirements for the overall System, Segments and SW Units/HW Units. Therefore, while it is realized in activities SD2 - System Design and SD3 - SW/HW Requirements Analysis, the product is in state "b. proc.". In spite of this fact it is practical to have the new incoming parts assessed by QA with regard to individual elements of the System Architecture after every addition to the technical requirements.

      Because of the size of this product (reference object: System) a physical division into several product components, e. g. into SW Units or Segments, might become necessary.

    4. "Operational Information"

      The products here described, "Information for the User Manual", "Information for the Diagnosis Manual", "Information for the Operator Manual", and "Other Application Information" contain information about the user documentation which are derived, generated and continually collected in the course of system development from the SD products and then completed in activity SD8 - System Integration. Therefore, a QA assessment only takes place after completion of the development activities, i. e. after activity SD 8. Because of the size of this product (reference object: System) a physical division into several product components, e. g. into SW Units or Segments, might become necessary; these can also be assessed by QA individually and possibly sooner.

    5. "Interface Overview" and "Interface Description"

      The Interface Overview is a product that results from the considerations and decisions with regard to the System Architecture and the SW Architecture. When it is developed in activities SD 2 and SD4 - Preliminary SW Design, it is therefore in the state "b. proc.". After that it is handed over to QA. In spite of this fact it might be practical for Systems where interface complexity is high to have QA assess any new parts, right after each design step. Basically, the same is true with regard to the Interface Description. However, since in this case the object is a product having a decisive impact on all subsequent design steps, a QA assessment is recommended after every activity (activities SD2 - System Design, SD4 - Preliminary SW Design). All new or changed parts must be assessed.

    6. "Data Dictionary"

      The project-specific Data-Dictionary is initialized via the general data administration of the CM (if available) on the basis of a general Data-Dictionary (if available). Since the Data Dictionary with activity SD5.1 - Description of SW Component/Module/Database is a general document, it is successively upgraded by contents that must be approved by the general data administration. The QA assessment right after activity SD5 - Detailed SW Design handles these additions.

    7. "Configuration Identification Document" (CID)

      The CID is a product realized by activity CM2 - Product and Configuration Management. Activity CM 2 is a secondary/attended project activity, i. e. it is permanently "active" simultaneously to the SD activities. The products created in a project initiate an activity. A CID refers to a System, a SW Unit or a HW Unit. Depending on the referenced object in question, the CID must remain in state "b. proc." until the referenced object also is in this state.

    8. "Change Status List" and "Project History"

      These are products, Change Status List and Project History, that have to be updated during the entire course of the project, possibly even during the course of continuation projects as well. Since they predominantly are used for internal project documentation a QA assessment is not required.

    9. "Project Plan"

      During the entire project, the Project Plan has the state "b. proc.". Mandatory QA assessments at certain intervals during the project development would impede planning and steering of the project management. Yet the Project Plan must be assessed, which might take place in the course of phase reviews. (See also product flow of activity PM4 - Detailed Planning.)

    10. "Integration Plan"

      The Integration Plan describes the integration of the system, based on SW Modules, SW Components, SW Units/HW Units, and Segments. During the generation in activity SD2 - System Design and SD4 - Preliminary SW Design it is in state "b. proc.". In spite of this fact it is practical to let QA assess the additions after every refinement step.

    To complete the picture, here are some further special product cases:

    Recommendation:

    In order to back up the results of the development activities, products should be subject to a QA (sub-) assessment prior to the final project assessment demanded in the V-Model. This method should be always applied when In order to handle such interim assessments or subproduct assessments with regard to QA and CM, the product in question must be physically separated into subproducts which, from the point of view of QA and CM, have to be handled like individual products, i. e. with separate product assessments, separate product states-associated with the separate product assessments-and attributes as well as references in the CID.

    This measure is a good solution, e. g., for an Interface Description per interface or for manuals per Segment or SW Unit or HW Unit.

    Previous Next GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster