|T.2 Project-Specific Adjustments of the 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:
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.
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.
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
In case the description text is adopted from the V-Model, the text can be adjusted.
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,
are described more closely in the following. This method demands that the minimum set is taken into consideration.
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.
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.
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.
The following project classes are defined:
This results in the following project types for which, at present, a standardized pre-tailoring exists:
The following figure illustrates the structure:
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):
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.
|Example: Bid-Relevant Deletion Condition|
|Example: Technical Deletion Conditions|
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:
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.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.
Next, the effects of the development strategy on the selection of activities required by the minimum set are briefly explained:
|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.|
|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.
The procedure is illustrated in Figure T.5 In this connection, the following has to be observed:
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.
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.
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).
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:
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:
3. Overview of the Project Manual.
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 .
|This page online GDPA Online Last Updated 03.Mar.2004 by C. Freericks|