|3 General Regulations|
The definition of the project-specific V-Model is supported by two adjustment tasks:
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:
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.
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.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".
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:
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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:
|GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster|